Category: IPv6

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.

Supposedly it’s a good idea to be able to identify which one of your users had a particular IP address at the time when that source IP address created significant havoc. We have a definitive solution for the IPv4 world: DHCP server logs combined with DHCP snooping, IP source guard and dynamic ARP inspection. IPv6 world is a mess: read this e-mail message from v6ops mailing list and watch Eric Vyncke’s RIPE65 presentation for excruciating details.

Enabling IPv6 on a server LAN with the ipv6 address interface configuration without taking additional precautions might be a bad idea. All modern operating systems have IPv6 enabled by default, and the moment someone starts sending Router Advertisement (RA) messages, they’ll auto-configure their LAN interfaces.

I’m positive most of you are way too busy dealing with operational issues to start thinking about IPv6 deployment (particularly if you’re working in the enterprise world; European service providers using the same “strategy” just got a rude wake-up call). Bad idea – if you ignore IPv6, it will eventually blow up in your face. Here’s how:

Last week I had the privilege of attending RIPE65, meeting a bunch of extremely bright SP engineers, and listening to a few fantastic presentations (full meeting report @ RIPE65 web site).

I knew Geoff Huston would have a great presentation, but his QoS presentation was even better than I expected. I don’t necessarily agree with everything he said, but every vendor peddling QoS should be forced to listen to his explanation of the underlying problems and kludgy solutions first.

Beatrice Ghorra (@beebux) was kind enough to share the results of her IPv6-over-PPPoE tests with me.

Short summary: everything works as expected on ASR 1K running IOS XE 3.7.