IPv6 for P2P
IPv6 is usually associated with the lack of IPv4 addresses, which the yellow press likes to write about. That from day to day there will be no free addresses and the transition to IPv6 will be inevitable. Skeptics believe that the problem is just as bloated as the “2000 mistake”, when everyone was afraid that after 1999 1900 would come and a man-made disaster would happen.
For most users, there really is no benefit from IPv6. What is the difference, for example, that packet headers are more convenient for the router? But for P2P, the NAT problem (due to which the IPv4 addresses have not yet ended) is real, because for peer-to-peer communication (even to send a file via Jabber or ICQ), at least one of the participants should be accessible from the outside, i.e. had a real IP address or at least forwarded a port to itself. Some providers provide an external address for a fee, some do not, and it is for NAT sufferers that IPv6 will be most useful.
It will also be useful for those whose provider cuts p2p traffic. In Russia, this (so far?) Is not so common, and abroad it is far from rare. IPv6 traffic (more precisely, wrapped in regular UDP packets) is not cut by them. It can also help in a situation where p2p traffic is blocked by a corporate firewall, but you can configure IPv6 through the tunnel.
At the user level, the main difference is that the IP address does not consist of 4 bytes, and is written not in the decimal system through a dot, but 16 bytes, which are written in hexadecimal 4-digit (2 bytes) and separated by a colon. Zeros at the beginning of numbers can be omitted, and the longest chain: 0: 0: 0: 0: in the address can be replaced simply with two colons. In this case, :: is the normal IPv6 address, consisting entirely of zeros. In the browser, if you need to specify the numerical address of the site, it is placed in square brackets, for example, http: // [2001: 4860: a003 :: 68] /
If you are lucky, then your provider provides Native IPv6. Congratulations, you are lucky! The rest remains to transmit IPv6 packets, wrapping them in IPv4 over "old" networks. There are a lot of connection methods, both automatic (such as 6to4 and teredo) and manually created tunnels, and working both with a static external IPv4 address and without it, even for the most cunning NAT.
The easiest way if you have external IPv4. Lift up the 6to4 interface (stf in BSD, sit in Linux), configure yourself an IPv6 address of the form 2002: xxyy: zztt: where xx.yy.zz.tt is your IPv4 address in hexadecimal format, and send all outgoing packets to 192.88.99.1. I don’t write specific actions for specific systems, they are full in Google ( example ).
The advantage of this connection is the ease of configuration. In this case, anyone can direct IPv6 packets over IPv4, you can send them to the nearest gate. 192.88.99.1 is the so-called anycast address, they can be any number on the network, and your provider usually sends them to the nearest one. The flip side of this is that it’s impossible to figure out why any address or subnet was unavailable, because real routes are unpredictable and may change over time. The second point - one machine under FreeBSD at the same time rebooted twice for unknown reasons in two days, and works with a static tunnel. On the other hand, for several friends on Linux this option has long worked without problems.
Automatic configuration option due to NAT. If you have uTorrent 1.8 and higher, the “Install IPv6 / Teredo” button has appeared in its settings - clicking it is enough to configure. To install manually, you need to run two commands from the command line:
The disadvantage of this option is that it does not work with all types of NAT. If after installation your ipv6.google.com does not open , run from the command line
A big plus (as in the case of 6to4) is that you will connect directly to those who are also connected via teredo, the external server will only help to establish a connection using NAT Traversal, and it is possible to ping through yourself. Therefore, the speed will be no worse than in the case of a direct connection (the loss of "wrapping" IPv6 packets into UDPv4 packets is minimal).
If automatic configuration didn’t help (symmetric NAT), or you want predictable packet routing, there are many free “ Tunnel Brokers ”. His choice should be taken very carefully, as well as the choice of proxy server, as both ping and speed will depend on this (this is also true for teredo - you can change the default server to teredo.remlab.net, it is closer to Russia). The main tools are ping and traceroute. See who your provider’s overseas traffic goes through. Look at the route to 192.88.99.1 (for many, it will go to Hurricane Electric - .he.net).
The easiest to install - go6.netIt is enough to download the program from their website, if you wish - register, install (it will swear on the “unsigned driver” - you need to confirm the installation), and that’s it. It works with all types of NAT (except that outgoing port 3653 must be allowed in the firewall). Although there are problems too, both with the built-in firewall and due to its absence, it worked for me only when teredo was enabled (but not working due to Symmetric NAT).
The downside is that go6 is located in Canada, and, as I understand it, all traffic passes through itself. Because of this ping from 300 ms and higher, low speed. Somewhere I came across information that hexago-hexago and ayiya-ayiya can establish “direct” tunnels with each other if it succeeds (NAT Traversal), but I can neither confirm nor deny this.
Official site - www.tunnelbroker.net Minus: provide only static tunnels, i.e. external IPv4 address required. The site needs registration. Plus: they have many “access points” through which you can connect, in many countries, so you can choose close enough to yourself, and the speed will be almost no worse than direct IPv4.
Official website: www.sixxs.net They have the most difficult registration (data is checked manually, from several hours to days), but also the widest range of possible connection methods and access points , so there is a high chance of finding within 10 “jumps” (by traceroute) from myself. I settled on this option, I recommend.
After registration, you need to order the AYIYA tunnel. At the same time, they let me choose one of the access points (we check trace and ping; the closest to me was sesto in Sweden). The order is also checked manually (hours, days), while taking internal "conditional units" for this, so the type of tunnel must first be ordered correctly. Then - download software, and there are pitfalls. The Tap32 driver and client are downloaded and installed separately. unpack tap901, run addtap.bat once - each time it starts, it creates a new interface, if you accidentally create unnecessary ones - deltapall.bat deletes everything at once. There are two clients (AICCU), with and without a GUI, but the GUI is not compatible with the latest driver. It is better to download both, run the GUI once, enter the username / password, get the settings from the server, and by clicking the icon select Save Configuration. No more GUI needed. If you now start the client from the command line - everything should work. If you're lucky, of course. In order for IPv6 to start when the computer boots, you need the instsrv and srvany utilities, which allow you to register this client as a Windows service (service). A very detailed description of the setting is in English .
To connect to someone over IPv6, you need to find out his address. Naturally, IPv6 must be supported by the torrent client. This is uTorrent since 1.8 (and the corresponding version of official BitTorrent), Azureus since 4.1.0.0 (the old ones swore at “error 16”), Transmission from version 1.50, I don’t know about others.
You can find each other by DHT. There are 2 implementations of them. Azureus has its own, no longer compatible with anyone, but IPv6 supports. In uTorrent and everyone else - not yet, but planned in the future. But IPv6 is supported by PEX. But all this only works on open trackers, without the private flag in the torrent.
Best if IPv6 supports tracker. According to the documentation, for this, the peers6 field is added to the response protocol (“compact”, to which almost everyone switched), where a list of addresses is transmitted in binary form, 18 bytes each (16 - address, 2 - port). In addition, the client can transmit the & ipv6 = parameter and, in principle, the tracker can transmit each other's IPv6 addresses to clients, even if it cannot accept IPv6 connections. The disadvantage of this approach is that through this parameter you can transfer “left” addresses, thus littering the tracker.
If the tracker itself is accessible via IPv6, then it will see the real addresses of the person who accesses it. But if both the A record and the AAAA are registered on the domain name of the tracker, then the clients will only connect via IPv6, and the tracker will not know their IPv4 addresses (the arguments & ip = and & ipv4 = also allow you to “litter”, and no one really sends them , uTorrent is the only one to pass & ipv6 =). It turns out, ideally, in the torrent file, you need to register 2 addresses for both protocols.
IPv6-enabled trackers are few. There is www.sixxs.net/tools/tracker/catalog but there is practically nothing there, it is more for tests and demos. The Pirate Bay announced support for IPv6 in January (only a tracker, their site is not available on IPv6). In RuNet in February, IPv6 support appeared on ipv6.nnm-club.ru (registration is either opened there or closed only by invite, but it is always open when entering via IPv6).
But for all this to make sense, there must be a sufficient number of customers. On the TPB main page, the last time was statistics on the number of peers, according to which only 0.12% were IPv6 (at the moment, for some reason, by zeros). This roughly corresponds to my personal experience - for a hundred peers, at best, 1-2 over IPv6. According to the statistics of nnm-club, 14% of clients transmit & ipv6 = or connect via IPv6 to the tracker. Actually, some of them transmit the “local” addresses of fe80: i.e. IPv6 is not configured for them, but somewhere in 12% the address is real.
And a few words and programming, or rather - porting ready-made applications for IPv6. I highly recommend Jun-ichiro itojun Hagino's “IPv6 Network Programming” book about this. The best part is that almost all the functions - socket, connect, listen, send, recv - support IPv6, and you won’t have to touch them at all.
The first main point is that you need to abandon the use of the sockaddr_in structure (and especially not store the IP address in int and functions like inet_addr). Instead, there is a universal structure sockaddr_storage, if desired, its ss_family field can be checked for AF_INET and converted to sockaddr_in, or, if it is equal to AF_INET6 - sockaddr_in6.
The second point is working with DNS and string representation of addresses. It must be translated into the universal functions getaddrinfo and getnameinfo. It should be borne in mind that getaddrinfo can return several addresses, while the server needs to listen (bind, listen) everything, the client should try to connect in turn, until it works out with one of the addresses.
In php, the main thing that you should pay attention to is that in $ _SERVER ['REMOTE_ADDR'] there may be not only an IPv4 address, but also IPv6, if it is supported by your web server.
For most users, there really is no benefit from IPv6. What is the difference, for example, that packet headers are more convenient for the router? But for P2P, the NAT problem (due to which the IPv4 addresses have not yet ended) is real, because for peer-to-peer communication (even to send a file via Jabber or ICQ), at least one of the participants should be accessible from the outside, i.e. had a real IP address or at least forwarded a port to itself. Some providers provide an external address for a fee, some do not, and it is for NAT sufferers that IPv6 will be most useful.
It will also be useful for those whose provider cuts p2p traffic. In Russia, this (so far?) Is not so common, and abroad it is far from rare. IPv6 traffic (more precisely, wrapped in regular UDP packets) is not cut by them. It can also help in a situation where p2p traffic is blocked by a corporate firewall, but you can configure IPv6 through the tunnel.
At the user level, the main difference is that the IP address does not consist of 4 bytes, and is written not in the decimal system through a dot, but 16 bytes, which are written in hexadecimal 4-digit (2 bytes) and separated by a colon. Zeros at the beginning of numbers can be omitted, and the longest chain: 0: 0: 0: 0: in the address can be replaced simply with two colons. In this case, :: is the normal IPv6 address, consisting entirely of zeros. In the browser, if you need to specify the numerical address of the site, it is placed in square brackets, for example, http: // [2001: 4860: a003 :: 68] /
Connection Methods
If you are lucky, then your provider provides Native IPv6. Congratulations, you are lucky! The rest remains to transmit IPv6 packets, wrapping them in IPv4 over "old" networks. There are a lot of connection methods, both automatic (such as 6to4 and teredo) and manually created tunnels, and working both with a static external IPv4 address and without it, even for the most cunning NAT.
6to4
The easiest way if you have external IPv4. Lift up the 6to4 interface (stf in BSD, sit in Linux), configure yourself an IPv6 address of the form 2002: xxyy: zztt: where xx.yy.zz.tt is your IPv4 address in hexadecimal format, and send all outgoing packets to 192.88.99.1. I don’t write specific actions for specific systems, they are full in Google ( example ).
The advantage of this connection is the ease of configuration. In this case, anyone can direct IPv6 packets over IPv4, you can send them to the nearest gate. 192.88.99.1 is the so-called anycast address, they can be any number on the network, and your provider usually sends them to the nearest one. The flip side of this is that it’s impossible to figure out why any address or subnet was unavailable, because real routes are unpredictable and may change over time. The second point - one machine under FreeBSD at the same time rebooted twice for unknown reasons in two days, and works with a static tunnel. On the other hand, for several friends on Linux this option has long worked without problems.
Teredo
Automatic configuration option due to NAT. If you have uTorrent 1.8 and higher, the “Install IPv6 / Teredo” button has appeared in its settings - clicking it is enough to configure. To install manually, you need to run two commands from the command line:
ipv6 install netsh int ipv6 set teredo clientIn * nyx systems, it is enough to install miredo, for example, with the command:
sudo apt-get install miredoIn Vista, it is enabled by default.
The disadvantage of this option is that it does not work with all types of NAT. If after installation your ipv6.google.com does not open , run from the command line
netsh int ipv6 show teredoif it says “Error: client behind symmetric NAT” - you're out of luck. In any case, it is very desirable to install the latest service packs, for example, XP SP2 created an address with the prefix 3ffe: not 2001: This is fixed in SP3, you can put KB922819 in SP2 or correct / add \ HKLM \ System \ CurrentControlSet \ Services \ Tcpip6 \ in regedit Parameters \ GlobalParams \ TeredoPrefix at 0x120 (288). The second minus is that in spite of the seeming simplicity of configuration, far from always everything is simple. For some, everything only works when the firewall built-in to Windows is turned off, for someone, on the contrary, only when it is turned on. And to describe in advance all the possible problems, conflicts, and methods for solving them is simply impossible.
A big plus (as in the case of 6to4) is that you will connect directly to those who are also connected via teredo, the external server will only help to establish a connection using NAT Traversal, and it is possible to ping through yourself. Therefore, the speed will be no worse than in the case of a direct connection (the loss of "wrapping" IPv6 packets into UDPv4 packets is minimal).
Hexago (go6)
If automatic configuration didn’t help (symmetric NAT), or you want predictable packet routing, there are many free “ Tunnel Brokers ”. His choice should be taken very carefully, as well as the choice of proxy server, as both ping and speed will depend on this (this is also true for teredo - you can change the default server to teredo.remlab.net, it is closer to Russia). The main tools are ping and traceroute. See who your provider’s overseas traffic goes through. Look at the route to 192.88.99.1 (for many, it will go to Hurricane Electric - .he.net).
The easiest to install - go6.netIt is enough to download the program from their website, if you wish - register, install (it will swear on the “unsigned driver” - you need to confirm the installation), and that’s it. It works with all types of NAT (except that outgoing port 3653 must be allowed in the firewall). Although there are problems too, both with the built-in firewall and due to its absence, it worked for me only when teredo was enabled (but not working due to Symmetric NAT).
The downside is that go6 is located in Canada, and, as I understand it, all traffic passes through itself. Because of this ping from 300 ms and higher, low speed. Somewhere I came across information that hexago-hexago and ayiya-ayiya can establish “direct” tunnels with each other if it succeeds (NAT Traversal), but I can neither confirm nor deny this.
Hurricane electric
Official site - www.tunnelbroker.net Minus: provide only static tunnels, i.e. external IPv4 address required. The site needs registration. Plus: they have many “access points” through which you can connect, in many countries, so you can choose close enough to yourself, and the speed will be almost no worse than direct IPv4.
Sixxs
Official website: www.sixxs.net They have the most difficult registration (data is checked manually, from several hours to days), but also the widest range of possible connection methods and access points , so there is a high chance of finding within 10 “jumps” (by traceroute) from myself. I settled on this option, I recommend.
After registration, you need to order the AYIYA tunnel. At the same time, they let me choose one of the access points (we check trace and ping; the closest to me was sesto in Sweden). The order is also checked manually (hours, days), while taking internal "conditional units" for this, so the type of tunnel must first be ordered correctly. Then - download software, and there are pitfalls. The Tap32 driver and client are downloaded and installed separately. unpack tap901, run addtap.bat once - each time it starts, it creates a new interface, if you accidentally create unnecessary ones - deltapall.bat deletes everything at once. There are two clients (AICCU), with and without a GUI, but the GUI is not compatible with the latest driver. It is better to download both, run the GUI once, enter the username / password, get the settings from the server, and by clicking the icon select Save Configuration. No more GUI needed. If you now start the client from the command line - everything should work. If you're lucky, of course. In order for IPv6 to start when the computer boots, you need the instsrv and srvany utilities, which allow you to register this client as a Windows service (service). A very detailed description of the setting is in English .
Bittorrent
To connect to someone over IPv6, you need to find out his address. Naturally, IPv6 must be supported by the torrent client. This is uTorrent since 1.8 (and the corresponding version of official BitTorrent), Azureus since 4.1.0.0 (the old ones swore at “error 16”), Transmission from version 1.50, I don’t know about others.
You can find each other by DHT. There are 2 implementations of them. Azureus has its own, no longer compatible with anyone, but IPv6 supports. In uTorrent and everyone else - not yet, but planned in the future. But IPv6 is supported by PEX. But all this only works on open trackers, without the private flag in the torrent.
Best if IPv6 supports tracker. According to the documentation, for this, the peers6 field is added to the response protocol (“compact”, to which almost everyone switched), where a list of addresses is transmitted in binary form, 18 bytes each (16 - address, 2 - port). In addition, the client can transmit the & ipv6 = parameter and, in principle, the tracker can transmit each other's IPv6 addresses to clients, even if it cannot accept IPv6 connections. The disadvantage of this approach is that through this parameter you can transfer “left” addresses, thus littering the tracker.
If the tracker itself is accessible via IPv6, then it will see the real addresses of the person who accesses it. But if both the A record and the AAAA are registered on the domain name of the tracker, then the clients will only connect via IPv6, and the tracker will not know their IPv4 addresses (the arguments & ip = and & ipv4 = also allow you to “litter”, and no one really sends them , uTorrent is the only one to pass & ipv6 =). It turns out, ideally, in the torrent file, you need to register 2 addresses for both protocols.
Trackers
IPv6-enabled trackers are few. There is www.sixxs.net/tools/tracker/catalog but there is practically nothing there, it is more for tests and demos. The Pirate Bay announced support for IPv6 in January (only a tracker, their site is not available on IPv6). In RuNet in February, IPv6 support appeared on ipv6.nnm-club.ru (registration is either opened there or closed only by invite, but it is always open when entering via IPv6).
But for all this to make sense, there must be a sufficient number of customers. On the TPB main page, the last time was statistics on the number of peers, according to which only 0.12% were IPv6 (at the moment, for some reason, by zeros). This roughly corresponds to my personal experience - for a hundred peers, at best, 1-2 over IPv6. According to the statistics of nnm-club, 14% of clients transmit & ipv6 = or connect via IPv6 to the tracker. Actually, some of them transmit the “local” addresses of fe80: i.e. IPv6 is not configured for them, but somewhere in 12% the address is real.
Programming
And a few words and programming, or rather - porting ready-made applications for IPv6. I highly recommend Jun-ichiro itojun Hagino's “IPv6 Network Programming” book about this. The best part is that almost all the functions - socket, connect, listen, send, recv - support IPv6, and you won’t have to touch them at all.
The first main point is that you need to abandon the use of the sockaddr_in structure (and especially not store the IP address in int and functions like inet_addr). Instead, there is a universal structure sockaddr_storage, if desired, its ss_family field can be checked for AF_INET and converted to sockaddr_in, or, if it is equal to AF_INET6 - sockaddr_in6.
The second point is working with DNS and string representation of addresses. It must be translated into the universal functions getaddrinfo and getnameinfo. It should be borne in mind that getaddrinfo can return several addresses, while the server needs to listen (bind, listen) everything, the client should try to connect in turn, until it works out with one of the addresses.
In php, the main thing that you should pay attention to is that in $ _SERVER ['REMOTE_ADDR'] there may be not only an IPv4 address, but also IPv6, if it is supported by your web server.