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 possible that in a year it will be completely irrelevant, but still we will describe the status of IPv6 today. The information is primarily aimed at home network providers; accordingly, the trunk does not fall under the definition of "provider" in this article.
Not so long ago, the free distribution of IPv4 addresses has ended, so there are more and more questions about IPv6 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 common questions, one can single out: “Does your billing support IPv6 addresses?”. At the same time, the answer: “Is all your equipment ready for implementation?” It is surprising: “What should be prepared there?”.
I don’t 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 AppleTalk or IPX, for example, are completely different. Therefore, IPv6 is not just “other addresses,” it is a completely different protocol.
The above should be understood first of all by Ukrainian providers: there is no UA-IX in IPv6 networks, the protocol includes routing elements in the IPv6 header of the 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 subscribers' questions: “Why do I not have 100M for UA-IX?”.
Also, currently no billing system supports full IPv6 management. Some systems have announced IPv6 support, but in practice this “support” is just a modified IP address field. And according to the standard, the address is not allocated to the end user, the network should be allocated to the end user, according to old recommendations - / 48 network (http://tools.ietf.org/html/rfc6177 ), according to the new RIPE recommendations - already / 56 network, i.e. 256 networks at 18446744073709551616 addresses. We repeat - to each subscriber. None of the known billing systems currently supports these standards.
Nevertheless, the inability to obtain IPv4 addresses and the steady rise in the price of their rent make us think about using the IPv6 protocol.
We’ll look at two options for implementing IPv6: dual-stack and pure IPv6.
Dual-stack is the parallel use of IPv6 and IPv4. The user receives both address options. Obviously, no one is going to issue a real IPv4 address, because then there is no point in IPv6 for the provider, the task is to save IPv4 addresses.
Currently, all client equipment supports receiving addresses and routes for both protocols well and with high quality; there are no problems on the part of Dual-Stack users. However, on the part of the provider, everything is somewhat sadder.
Let's start with access switches. The bundle of dhcp snooping + opt82 that proved to be excellent is available “out of the box” in the IPv6 protocol, it is only called opt37 ( http://tools.ietf.org/html/rfc4649), but at the same time, the switch itself must support the IPv6 protocol, at least be able to block “alien” RAs, filter ND, etc. Otherwise, the situation will be similar to a network with DHCP on “stupid” switches, where any client router distributes addresses.
To date, such support for IPv6 is known only in the latest D-Link, starting with the DES-3200, and more extreme options such as SNR switches from the respected nag.ru, purchasing which the provider subscribes to the eternal beta testers of firmware glitches for their own money. But we must pay tribute to DCN ( http://www.dcnglobal.com ): these are SNR, and Edge-Core, and many other brands - when buying D-Link switches, administrators will also spend a lot of time on beta testing and catching bugs.
Also, it should be noted that testing the necessary IPv6 functionality under real workload was not particularly carried out, the vast majority of IPv6 providers exist only in a test form, so that risking the introduction of IPv6 into operation can very well become a pioneer in this field.
Using a VPN (PPTP, PPPoE) for issuing addresses will undoubtedly reduce requests to access switches, but it will increase the amount of negativity among subscribers.
Total: at present, only a small number of new models of switches of “unstable” manufacturers have support for the necessary IPv6 network protection functions.
Things are not better in the middle of the network. We will not carefully consider the option where the center of the network is a server under FreeBSD / Linux, such networks are usually small, and they have / 22 or even / 23 IPv4 addresses with a head that will last for a long time for all users. Recall only that for FreeBSD, dummynet has not yet learned to use multiple cores.
The “average” provider in the center has some kind of Cisco / Juniper / Extreme from the middle range of equipment. For testing, we had a Cisco 3750G, which is a fairly common solution among similar sized providers. We enable IPv6 support, and we see that the resources were cut not even in half:
Recall the numbers for IPv4:
Fifteen hundred subscribers - this is hardly suitable for anyone, but a maximum of 1200 routes is a disaster, at present even small Russian traffic exchange points send 2,000 prefixes, not to mention points like DTEL-IX, UA-IX, or, especially MSK-IX.
But the main problem is that users need to be NATed under real IPv4. In the conditions of an “average” network this is not an easy task. The need to drive a couple of gigabits through the server will lead to poor traffic quality, high delays, complaints and churn.
It turns out that with a volume of traffic of several gigabits, it is already impossible to return to “soft” shapers based on FreeBSD / Linux / Mikrotik, and it is unrealistic to purchase 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 up IPv6 to IPv4? Then using 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, traffic will go through the “world” (who has a similar separation), and secondly, upon reaching certain limits, Hurricane Electric will also begin to take money for transit. It turns out that in addition to increasing overhead costs, the introduction of IPv6 will not produce anything positive. If you use NAT anyway, you can just NAT gray IPv4 addresses, and that’s it. Users will not notice the difference.
Total: the equipment typical of an “average” provider is either completely impossible to use for users to work in Dual-Stack, or it will be loaded several times more (separate routing plus NAT).
Given the inexpediency of deploying Dual-Stack in home networks, the providers have a logical question: “What if we transfer only one segment of the network to“ clean ”IPv6, and let the rest work as before?” In theory, such a scheme looks good: put a separate piece of hardware under IPv6, distribute IPv6 addresses to users, buy transit from uplink IPv6 - and let them work. Let’s take a closer look at the current state of support for pure IPv6.
This time, let’s omit the analysis of access switches - everything is the same as described in the section on Dual-Stack, except that it should be noted that when receiving IPv6 by auto-configuration, D-Link switches do not see the proposed routes, so you need to be prepared for the default gateway will prescribe manually.
As an example of the “center” of the network, we again used Cisco equipment, IOS version 15.1. There are no complaints about the "real" cisco: IPv6 addresses and routes are received correctly both by auto-configuration and by DHCPv6; itself in the role of a router acts correctly; there are many options for working with RA, ND, etc., everything works according to the documentation; addresses are distributed both by auto-configuration and by DHCPv6, too, correctly. Here, home network providers can only envy highways that have no particular problems with starting IPv6.
Let's move on to the client hardware. This has been written many times, for example, by the IETF itself ( http://tools.ietf.org/html/rfc6586), however, the hope that IPv6 support is being actively developed by manufacturers has forced us to go over the basic options for user connections. Namely, we checked the operability of a “clean” IPv6 connection for a Cisco Wi-Fi 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 labeled Linksys; it has been released by Cisco Small Business. Declared full support for IPv6, both on the WAN and LAN port. Indeed, the menu has a selection of different IPv4 and IPv6 combinations for these ports. We chose “clean” IPv6 for both, the router rebooted, and tried to connect. The computer connected to the wi-fi network, received a “gray” IPv6 address from the fc00 :: range ( http://tools.ietf.org/html/rfc4193 ), and we were able to enter the admin panel of the router, but not further - Internet access there was no computer. On the router, we saw the following picture:
Total: IPv6 support declared by the manufacturer exists, but to configure it, knowledge is required that is two to three orders of magnitude higher than the average user level, while the possibility of successfully setting up the phone by the support of the provider seems very unlikely. With the equipment of lesser-known brands, one 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. Considering the same behavior, in the future we will 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 yet, on the other hand, the very choice of Debian as an OS implies the ability of the user to manually route the gateway without any special problems.
Mac OS X. Despite the fact that we expected full support for IPv6, in fact we got the following:
Total: Mac OS X does not yet have full-fledged, bug-free support for “clean” IPv6, and given the complete lack of knowledge of this OS with typical provider support, one can expect negative and reduced loyalty from users of Apple products.
Windows 7. To our surprise, this OS, which out of the box organizes IPv6 support through Teredo ( http://technet.microsoft.com/en-us/network/cc917486.aspx ), showed the following features of using the IPv6 protocol:
Total: there is no full, bug-free support for “clean” IPv6 in Windows 7, it is possible to configure IPv6, however, this requires knowledge of the average Windows administrator level, which is not possible in a home network.
However, even if you overcome the technical difficulties in obtaining and configuring IPv6 by the user, what awaits him today in this "network of the future"? Unfortunately, almost nothing is expected of him there. Having run through popular sites, we see that:
Even microsoft.com does not have AAAA records. And other Microsoft services are deprived of IPv6 support, therefore, for example, it is possible to install and run the OS, but to update it is already gone. Additionally, Microsoft Security Essentials will stop working, which will not be able to update signatures.
Yes, and the claimed performance, for example, youtube, is also relative: the resource itself fully supports IPv6, however, to use it, you need Adobe Flash Player, which cannot be downloaded and installed, because all Adobe resources are unavailable over IPv6.
The output remains the same NAT, only 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 06/10/2011, and which is not part of any common distribution. Yes, and it is obvious that more than 90% of client traffic will go to the IPv4 network, and the issues of necessary capacities for Dual-Stack were discussed above.
Summing up, we can draw the following conclusions:
UPD: I apologize to andrewsh for not noticing the tayga package he built for Debian Wheezy.
Not so long ago, the free distribution of IPv4 addresses has ended, so there are more and more questions about IPv6 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 common questions, one can single out: “Does your billing support IPv6 addresses?”. At the same time, the answer: “Is all your equipment ready for implementation?” It is surprising: “What should be prepared there?”.
I don’t 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 AppleTalk or IPX, for example, are completely different. Therefore, IPv6 is not just “other addresses,” it is a completely different protocol.
The above should be understood first of all by Ukrainian providers: there is no UA-IX in IPv6 networks, the protocol includes routing elements in the IPv6 header of the 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 subscribers' questions: “Why do I not have 100M for UA-IX?”.
Also, currently no billing system supports full IPv6 management. Some systems have announced IPv6 support, but in practice this “support” is just a modified IP address field. And according to the standard, the address is not allocated to the end user, the network should be allocated to the end user, according to old recommendations - / 48 network (http://tools.ietf.org/html/rfc6177 ), according to the new RIPE recommendations - already / 56 network, i.e. 256 networks at 18446744073709551616 addresses. We repeat - to each subscriber. None of the known billing systems currently supports these standards.
Nevertheless, the inability to obtain IPv4 addresses and the steady rise in the price of their rent make us think about using the IPv6 protocol.
We’ll look at two options for implementing IPv6: dual-stack and pure IPv6.
Using IPv6 in Dual-Stack
Dual-stack is the parallel use of IPv6 and IPv4. The user receives both address options. Obviously, no one is going to issue a real IPv4 address, because then there is no point in IPv6 for the provider, the task is to save IPv4 addresses.
Currently, all client equipment supports receiving addresses and routes for both protocols well and with high quality; there are no problems on the part of Dual-Stack users. However, on the part of the provider, everything is somewhat sadder.
Let's start with access switches. The bundle of dhcp snooping + opt82 that proved to be excellent is available “out of the box” in the IPv6 protocol, it is only called opt37 ( http://tools.ietf.org/html/rfc4649), but at the same time, the switch itself must support the IPv6 protocol, at least be able to block “alien” RAs, filter ND, etc. Otherwise, the situation will be similar to a network with DHCP on “stupid” switches, where any client router distributes addresses.
To date, such support for IPv6 is known only in the latest D-Link, starting with the DES-3200, and more extreme options such as SNR switches from the respected nag.ru, purchasing which the provider subscribes to the eternal beta testers of firmware glitches for their own money. But we must pay tribute to DCN ( http://www.dcnglobal.com ): these are SNR, and Edge-Core, and many other brands - when buying D-Link switches, administrators will also spend a lot of time on beta testing and catching bugs.
Also, it should be noted that testing the necessary IPv6 functionality under real workload was not particularly carried out, the vast majority of IPv6 providers exist only in a test form, so that risking the introduction of IPv6 into operation can very well become a pioneer in this field.
Using a VPN (PPTP, PPPoE) for issuing addresses will undoubtedly reduce requests to access switches, but it will increase the amount of negativity among subscribers.
Total: at present, only a small number of new models of switches of “unstable” manufacturers have support for the necessary IPv6 network protection functions.
Things are not better in the middle of the network. We will not carefully consider the option where the center of the network is a server under FreeBSD / Linux, such networks are usually small, and they have / 22 or even / 23 IPv4 addresses with a head that will last for a long time for all users. Recall only that for FreeBSD, dummynet has not yet learned to use multiple cores.
The “average” provider in the center has some kind of Cisco / Juniper / Extreme from the middle range of equipment. For testing, we had a Cisco 3750G, which is a fairly common solution among similar sized providers. We enable IPv6 support, and we see that the resources were cut not even 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
Fifteen hundred subscribers - this is hardly suitable for anyone, but a maximum of 1200 routes is a disaster, at present even small Russian traffic exchange points send 2,000 prefixes, not to mention points like DTEL-IX, UA-IX, or, especially MSK-IX.
But the main problem is that users need to be NATed under real IPv4. In the conditions of an “average” network this is not an easy task. The need to drive a couple of gigabits through the server will lead to poor traffic quality, high delays, complaints and churn.
It turns out that with a volume of traffic of several gigabits, it is already impossible to return to “soft” shapers based on FreeBSD / Linux / Mikrotik, and it is unrealistic to purchase 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 up IPv6 to IPv4? Then using 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, traffic will go through the “world” (who has a similar separation), and secondly, upon reaching certain limits, Hurricane Electric will also begin to take money for transit. It turns out that in addition to increasing overhead costs, the introduction of IPv6 will not produce anything positive. If you use NAT anyway, you can just NAT gray IPv4 addresses, and that’s it. Users will not notice the difference.
Total: the equipment typical of an “average” provider is either completely impossible to use for users to work in Dual-Stack, or it will be loaded several times more (separate routing plus NAT).
Using Clean IPv6
Given the inexpediency of deploying Dual-Stack in home networks, the providers have a logical question: “What if we transfer only one segment of the network to“ clean ”IPv6, and let the rest work as before?” In theory, such a scheme looks good: put a separate piece of hardware under IPv6, distribute IPv6 addresses to users, buy transit from uplink IPv6 - and let them work. Let’s take a closer look at the current state of support for pure IPv6.
This time, let’s omit the analysis of access switches - everything is the same as described in the section on Dual-Stack, except that it should be noted that when receiving IPv6 by auto-configuration, D-Link switches do not see the proposed routes, so you need to be prepared for the default gateway will prescribe manually.
As an example of the “center” of the network, we again used Cisco equipment, IOS version 15.1. There are no complaints about the "real" cisco: IPv6 addresses and routes are received correctly both by auto-configuration and by DHCPv6; itself in the role of a router acts correctly; there are many options for working with RA, ND, etc., everything works according to the documentation; addresses are distributed both by auto-configuration and by DHCPv6, too, correctly. Here, home network providers can only envy highways that have no particular problems with starting IPv6.
Let's move on to the client hardware. This has been written many times, for example, by the IETF itself ( http://tools.ietf.org/html/rfc6586), however, the hope that IPv6 support is being actively developed by manufacturers has forced us to go over the basic options for user connections. Namely, we checked the operability of a “clean” IPv6 connection for a Cisco Wi-Fi 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 labeled Linksys; it has been released by Cisco Small Business. Declared full support for IPv6, both on the WAN and LAN port. Indeed, the menu has a selection of different IPv4 and IPv6 combinations for these ports. We chose “clean” IPv6 for both, the router rebooted, and tried to connect. The computer connected to the wi-fi network, received a “gray” IPv6 address from the fc00 :: range ( http://tools.ietf.org/html/rfc4193 ), and we were able to enter the admin panel of the router, but not further - Internet access there was no computer. On the router, we saw the following picture:
- On the WAN port, the router correctly received IPv6 address and routes, but did not pick up DNS. Manually registered DNS correctly worked.
- Even with IPv4 support disabled, the router tries to use it, for example, ping on 2a00: 1450: 400d: 804 :: 1009 works, but ping on google.com says that it cannot find A record. This also applies to NTP: you can enter an IPv6 address in the server input field, but the router tries to resolve it A record, and it fills the log with the corresponding errors.
- The router does not know how to do IPv6 NAT. It was not possible to configure access to the Internet from LAN using “gray” addresses. The only solution is to set up a real IPv6 network for LAN in the DHCPv6 settings on the router and set the corresponding routes in the IPv6 routing section.
Total: IPv6 support declared by the manufacturer exists, but to configure it, knowledge is required that is two to three orders of magnitude higher than the average user level, while the possibility of successfully setting up the phone by the support of the provider seems very unlikely. With the equipment of lesser-known brands, one 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. Considering the same behavior, in the future we will combine them under the definition of Debian. Here the situation is better:
- During installation, Debian correctly obtains an IPv6 address for autoconfiguration, routes and DNS work correctly, however, upon receipt of the address, all routes are lost, including the default gateway. Accordingly, Internet access is lost, which can lead to a stop of the installation with a short DHCP lease timeout.
- When starting the installed system, IPv6 addresses and DNS Debian receives correctly both by auto-configuration and by DHCPv6, however default gateway is persistently absent, it must be registered manually. The only good news is that in the future it does not get overwritten when the address is received.
Total: on the one hand, there is no full-fledged bug-free support for “clean” IPv6 in Debian yet, on the other hand, the very choice of Debian as an OS implies the ability of the user to manually route the gateway without any special problems.
Mac OS X. Despite the fact that we expected full support for IPv6, in fact we got the following:
- It receives IPv6 address and routes correctly both by auto-configuration and by DHCPv6, but DNS is not picked up. When registering DNS manually, everything works correctly.
- Although the network is fully operational, an error icon with an exclamation mark is displayed for network connections. To remove it, you need to go into the network settings, choose to obtain the address manually, and register any IPv4 address.
Total: Mac OS X does not yet have full-fledged, bug-free support for “clean” IPv6, and given the complete lack of knowledge of this OS with typical provider support, one can expect negative and reduced loyalty from users of Apple products.
Windows 7. To our surprise, this OS, which out of the box organizes IPv6 support through 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 produces. Let us recall the recommendations of RIPE on issuing / 56 networks; it turns out that in the case of Windows, automatic distribution of addresses is impossible.
- DNS is not picked up. When registering DNS manually, its parameters 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 must stop and disable the tunnel-related services and settings, most of which require administrator rights. Moreover, some operations can only be done (!) Through the command line using the netsh utility.
- Even after the above operations, “pure” IPv6 does not work in this OS, the error icon “Connection is limited or not available” 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, bug-free support for “clean” IPv6 in Windows 7, it is possible to configure IPv6, however, this requires knowledge of the average Windows administrator level, which is not possible in a home network.
However, even if you overcome the technical difficulties in obtaining and configuring IPv6 by the user, what awaits him today in this "network of the future"? Unfortunately, almost nothing is expected of him there. Having run through popular sites, we see that:
- over IPv6 work: google, youtube, facebook, vkontakte
- IPv6 does not work: skype, icq, yandex, odnoklassniki, steam, ex.ua and almost all the others, including news, entertainment and game resources.
Even microsoft.com does not have AAAA records. And other Microsoft services are deprived of IPv6 support, therefore, for example, it is possible to install and run the OS, but to update it is already gone. Additionally, Microsoft Security Essentials will stop working, which will not be able to update signatures.
Yes, and the claimed performance, for example, youtube, is also relative: the resource itself fully supports IPv6, however, to use it, you need Adobe Flash Player, which cannot be downloaded and installed, because all Adobe resources are unavailable over IPv6.
The output remains the same NAT, only 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 06/10/2011, and which is not part of any common distribution. Yes, and it is obvious that more than 90% of client traffic will go to the IPv4 network, and the issues of necessary capacities for Dual-Stack were discussed above.
Summary
Summing up, we can draw the following conclusions:
- At present, IPv6 protocol can be considered auxiliary to home network providers; it does not make sense to expect an early transition to IPv6 in the world due to the not very wide filling of the IPv6 network with user resources.
- It does not seem practically possible to deploy a “clean” IPv6 network: neither access equipment nor subscriber equipment supports a full-fledged network without IPv4 protocol.
- Using Dual-Stack does not make sense, because it is all the same NAT, but weighed down by the need to update all access equipment and the center to support IPv6, as well as separately acquire a band for transit of IPv6 traffic.
- In fact, at present only google services and torrents will use the IPv6 network, the rest of the traffic will go to IPv4. Question: Do I need to change all access equipment for better torrent support? - presumably, for providers has only one answer.
UPD: I apologize to andrewsh for not noticing the tayga package he built for Debian Wheezy.