IPv6 for home networks
In this article we will try to describe the current state of support and options for implementing IPv6 in home networks. The article was written in the fall of 2012, it is quite possible that in a year it will be completely irrelevant, but still we will describe the status of IPv6 today. The information is primarily focused on home network providers, respectively, the definition of "provider" in this article, the lines do not fall.
Not so long ago, the free distribution of IPv4 addresses ended, so the number of IPv6 issues is increasing every day. But the questions themselves most often show the gap between the concept of IPv6 in the heads of the questioners and the real state of things.
')
Among the most frequent questions are: “Does your billing support IPv6 addresses?”. At the same time, the answer: “Is all your equipment ready for its introduction?” Is surprising: “And what should be prepared there?”.
I do not want to rewrite the basics of IPv6 from rfc ( http://tools.ietf.org/html/rfc2460 ) or Wikipedia ( http://ru.wikipedia.org/wiki/Ipv6 ), so we will answer this fundamental question with two sentences. IPv4 and IPv6 are two different protocols, completely different. Like, for example, AppleTalk or IPX - completely different. Therefore, IPv6 is not just “other addresses”, it is a completely different protocol.
The above must be realized first of all by Ukrainian providers: there are no UA-IXs in IPv6 networks, the protocol contains routing elements already in the header of the IPv6 packet ( http://tools.ietf.org/html/rfc3587 ), networks are aggregated by default, IPv6 full -view cannot exceed 8K prefixes. Accordingly, providers will have to answer a wave of questions from subscribers: “Why do I not have 100M for UA-IX?”.
Also, currently no billing system supports full IPv6 management. Some systems have declared support for IPv6, but in practice this “support” is only a modified IP address field. And according to the standard, the end user is not allocated an address, the end user should be allocated a network, according to the old recommendations - / 48 network ( http://tools.ietf.org/html/rfc6177 ), according to the new RIPE recommendations - already / 56 network, t . 256 networks with 18446744073709551616 addresses. Repeat - each subscriber. None of the known billing systems currently supports these standards.
However, the inability to obtain IPv4 addresses and the steady rise in the cost of their lease makes us think about using the IPv6 protocol.
We will look at two IPv6 deployment options: Dual-Stack, and “pure” IPv6.
Dual-Stack is the parallel use of IPv6 and IPv4. The user receives both variants of addresses. Obviously, no one is going to give out the real IPv4 address, since then there is no sense in IPv6 for the provider, the task is to save IPv4 addresses.
Currently, all client equipment supports the receipt of addresses and routes for both protocols in a good and high-quality manner; it doesn’t cause problems from Dual-Stack users. However, on the part of the provider, everything is somewhat sadder.
Let's start with access switches. The well-proven dhcp snooping + opt82 bundle is out of the box in the IPv6 protocol, it is only called opt37 ( http://tools.ietf.org/html/rfc4649 ), but the switch itself must support the IPv6 protocol, at least be able to block “foreign” RAs, filter ND, etc. Otherwise, the situation will be similar to a network with DHCP on “stupid” switches, where any client router will distribute addresses.
To date, similar support for IPv6 is known only from the latest D-Link, starting with DES-3200, and more extreme options such as SNR switches from the reputable nag.ru, acquiring which the provider subscribes to perpetual beta testers of firmware glitches for their own money. But, we must pay tribute to DCN ( http://www.dcnglobal.com ): and this is SNR, and Edge-Core, and many other brands - buying D-Link switches, too, will be spent a lot of time by administrators on beta. testing and catching bugs.
Also, it should be noted that testing of the required IPv6 functionality under real load was not particularly carried out, the vast majority of IPv6 providers exist only in a test form, so who risked introducing IPv6 into operation may well become a pioneer in this field.
Using VPN (PPTP, PPPoE) for issuing addresses undoubtedly reduces requests to access switches, but increases the amount of negative among subscribers.
Total: at present, only a small number of new models of “unstable” manufacturers have support for the necessary IPv6 network protection functions.
Not better things in the center of the network. We will not carefully consider the option where the center of the network is a FreeBSD / Linux server, such networks are usually small, and their existing / 22 or even / 23 IPv4 addresses are head-on and will last for all users for a long time. We only recall that for FreeBSD dummynet has not yet learned how to use multiple kernels.
The "middle" provider in the center has some Cisco / Juniper / Extreme from the middle range of equipment. We had a Cisco 3750G for testing, which is a fairly common solution among similar-sized providers. We include support for IPv6, and we see that the resources are not even cut in half:
Recall the numbers for IPv4:
One and a half thousand subscribers are already suitable for very few people, but a maximum of 1,200 routs is a disaster, at present even small Russian traffic exchange points send 2,000 prefixes each, not to mention DTEL-IX, UA-IX, or Moreover, MSK-IX.
But the main problem is that users need to NAT under the real IPv4. Under the conditions of the “medium” network, this is quite an easy task. The need to drive a couple of gigabits through the servers will lead to low quality traffic, high latency, complaints and outflow of subscribers.
It turns out that with a traffic volume of a few gigabits, it is no longer possible to return to the “soft” shapers based on FreeBSD / Linux / Mikrotik, and it is unrealistically expensive to buy equipment of the Cisco ASR1000 level.
And what to do with IPv6 traffic itself is also a question. Give uplink? Almost all uplinks separately charge for the transit of IPv6 traffic. Wrap IPv6 to IPv4? Then the use of IPv6 does not make sense at all. Raise tunnel peering with someone like Hurricane Electric ( http://www.tunnelbroker.net/new_tunnel.php?type=bgp )? Firstly, the traffic will go through the “world” (who has such a separation), and secondly, upon reaching certain limits, Hurricane Electric will also start to take money for transit. It turns out that apart from the increase in overhead costs, the introduction of IPv6 will not give anything positive. If you still use NAT, then you can simply NAT-it gray IPv4 addresses, that's all. Users will not notice the difference.
Total: typical for an “average” provider, the equipment is either completely impossible to use for users in Dual-Stack, or it will be loaded several times more (separate routing plus NAT).
Taking into account the inexpediency of Dual-Stack deployment in home networks, providers have a quite logical question: “What if we transfer only one network segment to“ pure ”IPv6, and let the rest work as before?”. In theory, this scheme looks good: put a separate piece of hardware for IPv6, distribute IPv6 addresses to users, purchase additional IPv6 transit from uplinks - and let them work. Let us take a closer look at how things are going with the support of “clean” IPv6 at the moment.
This time, we’ll skip the analysis of access switches - everything is similar to that described in the section on Dual-Stack, unless it is necessary to note that D-Link switches do not see the proposed routs when receiving IPv6 by autoconfiguration, so you need to be prepared for what the default gateway is will prescribe manually.
As an example of the “center” of the network, we again used Cisco equipment, IOS version 15.1. There are no claims to the “real” cisco: IPv6 addresses and routes both by autoconfiguration and by DHCPv6 are received correctly; Itself in the role of the router acts correctly; options for working with RA, ND, etc., are many, everything functions according to the documentation; distributes addresses both by autoconfiguration and by DHCPv6 is also correct. Here, home network providers can only envy the backbones, who especially have no problems with launching IPv6.
Let us turn to the client equipment. This has been written many times, for example, by the IETF itself ( http://tools.ietf.org/html/rfc6586 ), but the hope that IPv6 support is actively developed by manufacturers has forced them to run over the main options for user connections. Namely, we tested the performance of a “clean” IPv6 connection for a Wi-Fi Cisco router (Linksys), as well as computers running Debian / Ubuntu, Mac OS X, Windows 7. All of the above had the latest software / updates / patches / firmware.
Wi-Fi router. For testing, we used a fairly new Cisco SB RV110W router. This router is no longer tagged with Linksys, it is released by the Cisco Small Business division. Full IPv6 support is claimed, both on the WAN and the LAN port. Indeed, the menu has a selection of various IPv4 and IPv6 combinations for these ports. We chose a “clean” IPv6 for both, the router rebooted, tried to connect. The computer connected to the wi-fi network, received a “gray” IPv6 address from the fc00 :: ( http://tools.ietf.org/html/rfc4193 range), and we were able to log in to the admin panel of the router, but no further - Internet access on the computer was not. On the router, we saw the following picture:
Total: the IPv6 support declared by the manufacturer exists, but to set it up requires knowledge two to three orders of magnitude higher than the average user level, while the possibility of successful setting up by phone with the support of the provider seems very unlikely. With the equipment of less well-known brands, you can be sure that the situation is at least no better.
Debian / Ubuntu. Testing was done with the latest software versions: Debian Wheezy and Ubuntu 12.10. Given the same behavior, we will later combine them under the definition of Debian. Here the situation is better:
Total: on the one hand, there is no full-fledged bug-free support for “clean” IPv6 in Debian, on the other hand, the very choice of Debian as the OS implies the user's ability to manually register the route to the gateway without any problems.
Mac OS X. Despite the fact that we expected full support for IPv6, in fact we received the following:
Total: there is no full-fledged bug-free support for “clean” IPv6 on Mac OS X, and given the complete lack of knowledge of this OS with typical provider support, you can expect negative and reduced loyalty from Apple users.
Windows 7. To our surprise, this OS, which “out of the box” organizes IPv6 support via Teredo ( http://technet.microsoft.com/en-us/network/cc917486.aspx ), showed the following features of using the IPv6 protocol:
Total: there is no full-fledged bug-free support for “clean” IPv6 in Windows 7, it is possible to configure IPv6, but this requires knowledge of the average Windows administrator level, which is not possible in a home network environment.
However, even if we overcome technical difficulties in obtaining and configuring IPv6 by the user, what is awaiting him today in this “network of the future”? Unfortunately, almost nothing is waiting for him there. Running through popular sites, we see that:
Even microsoft.com does not have AAAA records. Yes, and other Microsoft services are deprived of IPv6 support, so, for example, the OS can be installed and launched, but it is no longer possible to upgrade it. Additionally, Microsoft Security Essentials, which cannot update signatures, will stop working.
Yes, and the declared performance, for example, youtube, is also relative: the resource itself fully supports IPv6, but to use it you need the Adobe Flash Player, which cannot be downloaded and installed, because all Adobe resources are not available over IPv6.
The solution is still the same NAT, but in a different direction, and the only known software solution is TAYGA, NAT64 for Linux ( http://www.litech.org/tayga ), the latest changes in which are dated 10.06.2011, and which are not Included in any common distribution. And it is obvious that more than 90% of client traffic will go to the IPv4 network, and the issues of the required capacity for the Dual-Stack were discussed above.
Summing up, we can draw the following conclusions:
UPD: I apologize to andrewsh for not having noticed the tayga package he assembled for Debian Wheezy.
Not so long ago, the free distribution of IPv4 addresses ended, so the number of IPv6 issues is increasing every day. But the questions themselves most often show the gap between the concept of IPv6 in the heads of the questioners and the real state of things.
')
Among the most frequent questions are: “Does your billing support IPv6 addresses?”. At the same time, the answer: “Is all your equipment ready for its introduction?” Is surprising: “And what should be prepared there?”.
I do not want to rewrite the basics of IPv6 from rfc ( http://tools.ietf.org/html/rfc2460 ) or Wikipedia ( http://ru.wikipedia.org/wiki/Ipv6 ), so we will answer this fundamental question with two sentences. IPv4 and IPv6 are two different protocols, completely different. Like, for example, AppleTalk or IPX - completely different. Therefore, IPv6 is not just “other addresses”, it is a completely different protocol.
The above must be realized first of all by Ukrainian providers: there are no UA-IXs in IPv6 networks, the protocol contains routing elements already in the header of the IPv6 packet ( http://tools.ietf.org/html/rfc3587 ), networks are aggregated by default, IPv6 full -view cannot exceed 8K prefixes. Accordingly, providers will have to answer a wave of questions from subscribers: “Why do I not have 100M for UA-IX?”.
Also, currently no billing system supports full IPv6 management. Some systems have declared support for IPv6, but in practice this “support” is only a modified IP address field. And according to the standard, the end user is not allocated an address, the end user should be allocated a network, according to the old recommendations - / 48 network ( http://tools.ietf.org/html/rfc6177 ), according to the new RIPE recommendations - already / 56 network, t . 256 networks with 18446744073709551616 addresses. Repeat - each subscriber. None of the known billing systems currently supports these standards.
However, the inability to obtain IPv4 addresses and the steady rise in the cost of their lease makes us think about using the IPv6 protocol.
We will look at two IPv6 deployment options: Dual-Stack, and “pure” IPv6.
Using IPv6 in Dual-Stack
Dual-Stack is the parallel use of IPv6 and IPv4. The user receives both variants of addresses. Obviously, no one is going to give out the real IPv4 address, since then there is no sense in IPv6 for the provider, the task is to save IPv4 addresses.
Currently, all client equipment supports the receipt of addresses and routes for both protocols in a good and high-quality manner; it doesn’t cause problems from Dual-Stack users. However, on the part of the provider, everything is somewhat sadder.
Let's start with access switches. The well-proven dhcp snooping + opt82 bundle is out of the box in the IPv6 protocol, it is only called opt37 ( http://tools.ietf.org/html/rfc4649 ), but the switch itself must support the IPv6 protocol, at least be able to block “foreign” RAs, filter ND, etc. Otherwise, the situation will be similar to a network with DHCP on “stupid” switches, where any client router will distribute addresses.
To date, similar support for IPv6 is known only from the latest D-Link, starting with DES-3200, and more extreme options such as SNR switches from the reputable nag.ru, acquiring which the provider subscribes to perpetual beta testers of firmware glitches for their own money. But, we must pay tribute to DCN ( http://www.dcnglobal.com ): and this is SNR, and Edge-Core, and many other brands - buying D-Link switches, too, will be spent a lot of time by administrators on beta. testing and catching bugs.
Also, it should be noted that testing of the required IPv6 functionality under real load was not particularly carried out, the vast majority of IPv6 providers exist only in a test form, so who risked introducing IPv6 into operation may well become a pioneer in this field.
Using VPN (PPTP, PPPoE) for issuing addresses undoubtedly reduces requests to access switches, but increases the amount of negative among subscribers.
Total: at present, only a small number of new models of “unstable” manufacturers have support for the necessary IPv6 network protection functions.
Not better things in the center of the network. We will not carefully consider the option where the center of the network is a FreeBSD / Linux server, such networks are usually small, and their existing / 22 or even / 23 IPv4 addresses are head-on and will last for all users for a long time. We only recall that for FreeBSD dummynet has not yet learned how to use multiple kernels.
The "middle" provider in the center has some Cisco / Juniper / Extreme from the middle range of equipment. We had a Cisco 3750G for testing, which is a fairly common solution among similar-sized providers. We include support for IPv6, and we see that the resources are not even cut in half:
- number of unicast mac addresses: 1.5K
- number of IPv4 unicast routes: 2.75K
- number of directly-connected IPv4 hosts: 1.5K
- number of indirect IPv4 routes: 1.25K
- number of directly-connected IPv6 addresses: 1.5K
- number of indirect IPv6 unicast routes: 1.25K
Recall the numbers for IPv4:
- number of unicast mac addresses: 3K
- number of IPv4 unicast routes: 11K
- number of directly-connected IPv4 hosts: 3K
- number of indirect IPv4 routes: 8K
One and a half thousand subscribers are already suitable for very few people, but a maximum of 1,200 routs is a disaster, at present even small Russian traffic exchange points send 2,000 prefixes each, not to mention DTEL-IX, UA-IX, or Moreover, MSK-IX.
But the main problem is that users need to NAT under the real IPv4. Under the conditions of the “medium” network, this is quite an easy task. The need to drive a couple of gigabits through the servers will lead to low quality traffic, high latency, complaints and outflow of subscribers.
It turns out that with a traffic volume of a few gigabits, it is no longer possible to return to the “soft” shapers based on FreeBSD / Linux / Mikrotik, and it is unrealistically expensive to buy equipment of the Cisco ASR1000 level.
And what to do with IPv6 traffic itself is also a question. Give uplink? Almost all uplinks separately charge for the transit of IPv6 traffic. Wrap IPv6 to IPv4? Then the use of IPv6 does not make sense at all. Raise tunnel peering with someone like Hurricane Electric ( http://www.tunnelbroker.net/new_tunnel.php?type=bgp )? Firstly, the traffic will go through the “world” (who has such a separation), and secondly, upon reaching certain limits, Hurricane Electric will also start to take money for transit. It turns out that apart from the increase in overhead costs, the introduction of IPv6 will not give anything positive. If you still use NAT, then you can simply NAT-it gray IPv4 addresses, that's all. Users will not notice the difference.
Total: typical for an “average” provider, the equipment is either completely impossible to use for users in Dual-Stack, or it will be loaded several times more (separate routing plus NAT).
Use of "pure" IPv6
Taking into account the inexpediency of Dual-Stack deployment in home networks, providers have a quite logical question: “What if we transfer only one network segment to“ pure ”IPv6, and let the rest work as before?”. In theory, this scheme looks good: put a separate piece of hardware for IPv6, distribute IPv6 addresses to users, purchase additional IPv6 transit from uplinks - and let them work. Let us take a closer look at how things are going with the support of “clean” IPv6 at the moment.
This time, we’ll skip the analysis of access switches - everything is similar to that described in the section on Dual-Stack, unless it is necessary to note that D-Link switches do not see the proposed routs when receiving IPv6 by autoconfiguration, so you need to be prepared for what the default gateway is will prescribe manually.
As an example of the “center” of the network, we again used Cisco equipment, IOS version 15.1. There are no claims to the “real” cisco: IPv6 addresses and routes both by autoconfiguration and by DHCPv6 are received correctly; Itself in the role of the router acts correctly; options for working with RA, ND, etc., are many, everything functions according to the documentation; distributes addresses both by autoconfiguration and by DHCPv6 is also correct. Here, home network providers can only envy the backbones, who especially have no problems with launching IPv6.
Let us turn to the client equipment. This has been written many times, for example, by the IETF itself ( http://tools.ietf.org/html/rfc6586 ), but the hope that IPv6 support is actively developed by manufacturers has forced them to run over the main options for user connections. Namely, we tested the performance of a “clean” IPv6 connection for a Wi-Fi Cisco router (Linksys), as well as computers running Debian / Ubuntu, Mac OS X, Windows 7. All of the above had the latest software / updates / patches / firmware.
Wi-Fi router. For testing, we used a fairly new Cisco SB RV110W router. This router is no longer tagged with Linksys, it is released by the Cisco Small Business division. Full IPv6 support is claimed, both on the WAN and the LAN port. Indeed, the menu has a selection of various IPv4 and IPv6 combinations for these ports. We chose a “clean” IPv6 for both, the router rebooted, tried to connect. The computer connected to the wi-fi network, received a “gray” IPv6 address from the fc00 :: ( http://tools.ietf.org/html/rfc4193 range), and we were able to log in to the admin panel of the router, but no further - Internet access on the computer was not. On the router, we saw the following picture:
- On the WAN port, the router correctly received the IPv6 address and routes, but did not catch the DNS. Manually spelled DNS correctly earned.
- Even with IPv4 support disabled, the router tries to use it, for example, pinging on 2a00: 1450: 400d: 804 :: 1009 works, but pinging on google.com says that it cannot find the A record. The same applies to NTP: you can enter an IPv6 address in the server's input field, but the router tries to cut the A record and goes to sleep with the corresponding errors.
- The router does not know how to do IPv6 NAT. It was not possible to set up Internet access from LAN with the use of "gray" addresses. The only solution is to set the real IPv6 network for the LAN in the DHCPv6 settings on the router and set the corresponding routes in the IPv6 routing section.
Total: the IPv6 support declared by the manufacturer exists, but to set it up requires knowledge two to three orders of magnitude higher than the average user level, while the possibility of successful setting up by phone with the support of the provider seems very unlikely. With the equipment of less well-known brands, you can be sure that the situation is at least no better.
Debian / Ubuntu. Testing was done with the latest software versions: Debian Wheezy and Ubuntu 12.10. Given the same behavior, we will later combine them under the definition of Debian. Here the situation is better:
- When installing, Debian correctly obtains an IPv6 address by autoconfiguration, routes and DNS work correctly, but if the address is recieved, all routes are lost, including the default gateway. Accordingly, Internet access disappears, which can lead to a halt of the installation with a short timeout of DHCP lease.
- When starting the installed IPv6 system, the address and DNS Debian receives correctly both by autoconfiguration and by DHCPv6, however, the default gateway is persistently missing, it needs to be registered manually. Pleases only that in the future it does not overwrite when re-obtaining the address.
Total: on the one hand, there is no full-fledged bug-free support for “clean” IPv6 in Debian, on the other hand, the very choice of Debian as the OS implies the user's ability to manually register the route to the gateway without any problems.
Mac OS X. Despite the fact that we expected full support for IPv6, in fact we received the following:
- The IPv6 address and routes are received correctly both by autoconfiguration and by DHCPv6, however DNS is not picked up. When manually prescribing DNS, everything works correctly.
- Although the network is fully functional, an error icon with an exclamation point is displayed for network connections. To remove it, you need to go to the network settings, select the receipt of the address manually, and register any IPv4 address.
Total: there is no full-fledged bug-free support for “clean” IPv6 on Mac OS X, and given the complete lack of knowledge of this OS with typical provider support, you can expect negative and reduced loyalty from Apple users.
Windows 7. To our surprise, this OS, which “out of the box” organizes IPv6 support via Teredo ( http://technet.microsoft.com/en-us/network/cc917486.aspx ), showed the following features of using the IPv6 protocol:
- The IPv6 address is obtained both by autoconfiguration and by DHCPv6, however, the mask is set to / 48, regardless of what the server issues. Recall the recommendations of RIPE about issuing / 56 networks, it turns out that in the case of Windows, automatic distribution of addresses is impossible.
- DNS is not picked up. When you manually assign the DNS, its settings are saved.
- The proposed routes are entered into the routing table, but with a priority lower than the Teredo tunnels. In order for the IPv6 connection to work, you need to stop and disable the tunnel-related services and settings, of which most require administrative privileges. Moreover, some operations can be performed only (!) Via the command line using the netsh utility.
- Even after the above operations, the “clean” IPv6 does not function in this OS, the error icon “Connection is limited or absent” is displayed. It is necessary to register any IPv4 address, without a gateway and DNS, after which the IPv6 network begins to fully function.
Total: there is no full-fledged bug-free support for “clean” IPv6 in Windows 7, it is possible to configure IPv6, but this requires knowledge of the average Windows administrator level, which is not possible in a home network environment.
However, even if we overcome technical difficulties in obtaining and configuring IPv6 by the user, what is awaiting him today in this “network of the future”? Unfortunately, almost nothing is waiting for him there. Running through popular sites, we see that:
- IPv6 work: google, youtube, facebook, vkontakte
- IPv6 does not work: skype, icq, yandex, odnoklassniki, steam, ex.ua and almost everything else, including news, entertainment and game resources.
Even microsoft.com does not have AAAA records. Yes, and other Microsoft services are deprived of IPv6 support, so, for example, the OS can be installed and launched, but it is no longer possible to upgrade it. Additionally, Microsoft Security Essentials, which cannot update signatures, will stop working.
Yes, and the declared performance, for example, youtube, is also relative: the resource itself fully supports IPv6, but to use it you need the Adobe Flash Player, which cannot be downloaded and installed, because all Adobe resources are not available over IPv6.
The solution is still the same NAT, but in a different direction, and the only known software solution is TAYGA, NAT64 for Linux ( http://www.litech.org/tayga ), the latest changes in which are dated 10.06.2011, and which are not Included in any common distribution. And it is obvious that more than 90% of client traffic will go to the IPv4 network, and the issues of the required capacity for the Dual-Stack were discussed above.
Results
Summing up, we can draw the following conclusions:
- At present, IPv6 can be considered as an auxiliary provider of home networks; it does not make sense to expect an early transition to IPv6 in the world due to the fact that the IPv6 network is not very wide in user resources.
- It is not practically possible to deploy a “clean” IPv6 network: neither the access equipment nor the subscriber equipment does not support a full-fledged network without an IPv4 protocol.
- Using Dual-Stack does not make sense, because it is all the same NAT, but burdened with the need to upgrade all access equipment and the center to supporting IPv6, as well as separately acquire the band for transit of IPv6 traffic.
- In fact, currently only google services and torrents will use the IPv6 network, the rest of the traffic will go to IPv4. Question: Do I change all the access equipment for the sake of improved support for torrents? - I suppose, for providers has only one answer.
UPD: I apologize to andrewsh for not having noticed the tayga package he assembled for Debian Wheezy.
Source: https://habr.com/ru/post/159775/
All Articles