Category: IPv6

During the IPv6 Security webinar, Eric Vyncke explained the intricate details of IPv6 Security Neighbor Discovery (SEND) and the reasons it will probably never take off.

Numerous residential access technologies face path MTU discovery issues. PPPoE connections (with MTU = 1492 bytes instead of 1500 bytes) is the best-known example, and we’ll see more of them as various tunneling-based IPv4-to-IPv6 transition mechanisms (6rd, DS-Lite, MAP-E) become more popular.

Obviously you could use the same old MSS clamping tricks in the brave new IPv6 world or decide (like DS-Lite) to deal with IP fragmentation in underlay access networks ... but there’s another option in the IPv6 world: reduce client-side MTU with router advertisement messages.

Cassidy Larson from InfoWest sent me an interesting challenge: using the sample configurations I provided in the Building Large IPv6 Service Provider Networks webinar he was getting weird DHCPv6 errors when a residential CPE device requested a delegated prefix from the BRAS router (before moving forward, have to mention how nice it is to see an US ISP deploying IPv6 ;).

Justin asked an interesting question in a comment to my IPv6 On-Link Determination post: do we need HSRP for IPv6 as the routers already send out RA messages? Pavel quickly pointed out that my friend @packetlife already wrote about it, concluding that you could use RAs unless you need deterministic sub-second failover.

However, there are (as always) a few more gotchas:

A while ago I wrote a blog post about remote ND attacks, which included the idea of having /120 prefixes on server LANs. As it turns out, it was a bad idea, and as nosx pointed out in his comment: “there is quite a long list of caveats in all vendor camps regarding hardware in the last 6-8 years that has some potentially painful hardware issues regarding prefix length. Classic issues include ACL construction and TCAM specificity.”

One would hope that the newly-release data center switches fare better. Fat chance!

When an IPv4/IPv6 host wants to send a packet to another host, it has to answer the following simple questions:

• Can I reach the destination IP address directly (is the destination on the same LAN/subnet)?
• If not, who will help me forward the packet (who is the first-hop router)?

In IPv4 world, the host can get all the information it needs through DHCP. In IPv6 world, things are way more complex (but also way more correct if you’re a theoretician).

In the introductory part of the IPv6 security webinar, Eric Vyncke explained how the huge IPv6 subnet sizes won’t stop a determined attacker, but will make the task of network or security engineers trying to take host inventory much harder.

I’m constantly getting questions about the intricate interworking of various flags present in IPv6 Router Advertisement messages. Here’s a (hopefully comprehensive) summary taken primarily from RFC 4861.

An incredible amount of IPv6 deployment documents has been published as IETF drafts recently, amongst them:

• Operational security considerations for IPv6 networks
• Design guidelines for IPv6 networks
• Stateless IP/ICMP Translation in IPv6 Data Centre Environments (aka IPv6-only data centers)
• Enterprise IPv6 Deployment Guidelines

Enjoy ... and don’t forget to join the v6ops mailing list ;)

The murky details of IPv6 implementations never crop up till you start deploying it (or, as Randy Bush recently wrote: “it is cheering to see that the ipv6 ivory tower still stands despite years of attack by reality”).

Here’s another one: in theory the prefixes delegated through DHCPv6 should be static and permanently assigned to the customers for long periods of time.

Jernej Horvat sent me the following question:

I know DHCPv6-based prefix delegation should be as stable as possible, so I plan to include the delegated prefix in my RADIUS database. However, for legacy reasons each username can have up to four concurrent PPPoE sessions. How will that work with DHCPv6 IA_PD?

Short answer: worst case, DHCPv6 prefix delegation will be royally broken.

Similar to Data Center and DMVPN trilogy, I bundled the core IPv6 webinars into IPv6 trilogy. Following the great example set by Douglas Adams, the trilogy has four webinars (the real reason: it’s not likely someone would need both Enterprise and Service Provider introductory webinar).

Somehow I got involved in an IPv6 RADIUS accounting discussion. This is what I found to work in Cisco IOS release 15.2(4)S:

Last week’s IPv6 summit organized by Jan Žorž was probably one of the best events to attend for engineers interested in real-life IPv6 deployment experience. Some of the highlights included:

• IPv6: Past, Present and Future by Robert Hinden, one of the creators of IPv6;
• Cisco’s IPv6 deployment experiences by Andrew Yourtchenko, technical leader @ Cisco;
• IPv6 deployment in Yahoo by Jason Fesler, distinguished architect @ Yahoo;
• Lessons learned while deploying IPv6 in US Government by Ron Broersma, Network Security Manager @ SPAWAR;
• IPv6 implementation in Time Warner Cable by their director of technology development: Lee Howard of the CGN-is-too-expensive fame.

Enjoy! ... and thank you, Jan, for an excellent event.

During last week’s IPv6 Summit I presented an interesting idea first proposed by Tore Anderson: let’s skip all the transition steps and implement IPv6-only data centers.

You can view the presentation or watch the video; for more details (including the description of routing tricks to get this idea working with vanilla NAT64), watch Tore’s RIPE64 presentation.