Hi nanog,
We are little behind in our IPv6 rollout are pushing to make big strides by the end of Q2. We have all of our core network and primary infrastructure dual-stack enabled at this point and our next step will be to move to dual-stack on our CMTSs. For those retail operators that have enabled dual-stack can you comment on behavior that you observed from customer CPE equipment after flipping the switch? Are most CPE devices generally not IPv6 capable in the first place? For those that are capable are they usually still configured with IPv6 disabled, requiring the customer to enable it? For those CPE that are capable and enabled, is there a common configuration such as full blown DHCPv6 with PD?
For those that are responding I am primarily concerned about customer routers. I have followed the many discussions about Android phones that don't perform DHCPv6, and I am really concerned about these kind of issues as these devices basically won't be seen at the edge of the customer's network.
If you have something else that you think is noteworthy, I'm all ears.
Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnstong@westmancom.com<mailto:johnstong@westmancom.com>
P think green; don't print this email.
hey,
Are most CPE devices generally not IPv6 capable in the first place? For those that are capable are they usually still configured with IPv6 disabled, requiring the customer to enable it? For those CPE that are capable and enabled, is there a common configuration such as full blown DHCPv6 with PD?
In my experience, IPv6 is mostly disabled. But this will vary from region to region due to different vendors on the market.
When IPv6 is already enabled, it mostly is DHCPv6 PD, otherways it'll not really make sense as CPE. Some routers will also need M-bit set in the RA, others will just blindly do DHCPv6.
But it tends to be PD _and_ NA, NA can or can not be annoying depending on your network setup.
We have also seen issues with DHCP timers, make sure you have a way to protect your DHCP servers and relays when CPE starts sending out request every millisecond.
I can’t speak regarding “most CPE devices” but for CPE = Apple Airport Extreme
• At least since the AirPort Extreme 802.11n (AirPort5,117) was released in 2011, the hardware has supported native IPv6 routing and acceptance of PD from the WAN.
• The default configuration for firmware 7.7.3 is automatic WAN IPv6 configuration, native IPv6 routing, and, acceptance of PD from the WAN. End systems on the single LAN receive a /64.
• No DHCPv6 is provided to the LAN through firmware up to the current version 7.7.3.
For all recent Windows, OS X, and. IOS versions, IPv6 “just works” with the Airport default IPv6 configuration. Most users can not tell the difference.
For those connected to ISPs that still can’t spell IPv6, I do manually set Internet Options to Configure IPv6: Link-local only. This should not make any difference, but it makes me and some eyeballs happier.
James R. Cutler
James.cutler@consultant.com
PGP keys at http://pgp.mit.edu
Are most CPE devices generally not IPv6 capable in the first place? For those that are capable are they usually still configured with IPv6 disabled, requiring the customer to enable it? For those CPE that are capable and enabled, is there a common configuration such as full blown DHCPv6 with PD?
I can’t speak regarding “most CPE devices” but for CPE = Apple Airport Extreme
• At least since the AirPort Extreme 802.11n (AirPort5,117) was released in 2011, the hardware has supported native IPv6 routing and acceptance of PD from the WAN.
• The default configuration for firmware 7.7.3 is automatic WAN IPv6 configuration, native IPv6 routing, and, acceptance of PD from the WAN. End systems on the single LAN receive a /64.
To be more clear… The LAN receives a /64 from which end systems are able to construct one or more end system addresses using SLAAC.
• No DHCPv6 is provided to the LAN through firmware up to the current version 7.7.3.
The good news is that RDNSS is allegedly supported in recent firmware releases.
Owen
Are most CPE devices generally not IPv6 capable in the first place? For those that are capable are they usually still configured with IPv6 disabled, requiring the customer to enable it? For those CPE that are capable and enabled, is there a common configuration such as full blown DHCPv6 with PD?
I can’t speak regarding “most CPE devices” but for CPE = Apple Airport Extreme
• At least since the AirPort Extreme 802.11n (AirPort5,117) was released in 2011, the hardware has supported native IPv6 routing and acceptance of PD from the WAN.
• The default configuration for firmware 7.7.3 is automatic WAN IPv6 configuration, native IPv6 routing, and, acceptance of PD from the WAN. End systems on the single LAN receive a /64.
To be more clear… The LAN receives a /64 from which end systems are able to construct one or more end system addresses using SLAAC.
I tried to keep it simple - my original draft said “All end systems on the LAN receive the same /64 prefix in RAs, even if the ISP has delegated a /56, for example. It was altogether too wordy so I excised about half of the original text. Maybe I went too far.
• No DHCPv6 is provided to the LAN through firmware up to the current version 7.7.3.
The good news is that RDNSS is allegedly supported in recent firmware releases.
I have found no documentation from Apple or in the Airport Utility GUI that mentions it. I have figured out some of IPv6 entries in .baseconfig files, but none for RDNSS.
The bad news is that I have yet to really understand RDNSS in the context of OS X. I don’t find any recognizable mention in sysctl inet6 parameters. OS X El Capitan systems autoconfigure the LAN/64:EUI-64 address of the Airport Extreme along with the IPv4 nnn.nnn.nnn..1 address as DNS server addresses. Windows 10 appears to do the same. (I haven’t bothered to look into Windows internals. I don’t get paid to do that anymore.) I keep IPv6 disabled on my Snow Leopard Server instances, both because no IPv6 DNS server address is ever autoconfigured and because none of those instances should ever get incoming IPv6 traffic.
Owen
Thanks for your comments.
James R. Cutler
James.cutler@consultant.com
PGP keys at http://pgp.mit.edu