Category: IPv6

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.

The usual claim that “IPv6 has better security because it includes mandatory IPsec support” is evidently creating some confusion, at least based on a set of questions I received from one of my readers.

Can IPv6 work without IPsec?

Absolutely. Most IPv6 deployments don’t use IPsec (unless you’re building IPsec-based VPNs over IPv6 transport infrastructure).

Straight from the rumor mill (source, translated):

One of German ISPs is actually quite busy rolling out IPv6 after their CFO got a call from a stock analyst right during the RIPE meeting, asking questions “so what are your IPv6 plans?” – “none, what is IPv6?” – “oh, this is not so good”… full panic down the management chain…

Proves the everlasting wisdom from Martin Levy (source, the rest of article is not worth reading):

You can either do a planned, careful migration, or you can do it in a panic. And you should know full well that panicking is more expensive.

Just in case you’ll be pushed into the panic mode: my webinars include intro for enterprises, intro for service providers and in-depth design/deployment webinar.

In case the industry press hasn’t told you yet, tomorrow is the World IPv6 Launch day. While the obstinate naysayers will still claim IPv6 doesn’t matter (but then there are people believing in flat Earth being ~6000 years old and riding on a stack of turtles), the rest of us should be prepared to enable IPv6 when needed … and it all starts with the networking equipment that supports IPv6 and has IPv6 performance that has at least the same order of magnitude as the IPv4 performance.

When I mentioned the uselessness of stateless NAT64, I got in nice discussion with Tore Anderson who wanted to use stateless NAT64 in reverse direction (stateless NAT46) to build an IPv6-only data center. Some background information first (to define the context of his thinking before we jump into the technical details):

Stumbled across this marvel while updating my IPv6 presentations for a 2-day seminar in Milano and Rome (straight from 15.2M&T command reference):

With IPv6 support added in Cisco IOS Release 12.2(2)T, the ip http server command simultaneously enables and disables both IP and IPv6 access to the HTTP server. However, an access list configured with the ip http access-class command will only be applied to IPv4 traffic. IPv6 traffic filtering is not supported.

Wait ... WHAT? I cannot control who can access the HTTP(S) server running in Cisco IOS over IPv6 (apart from kludges like ingress ACLs on all interfaces or CoPP), and this stupidity has been left unfixed for nine(9) years?. Are we really in 2012, less than a month away from World IPv6 Launch or have I been transported to 1990’s?

The proponents of Network Prefix Translation for IPv6 (NPT66) usually claim it’s required for one of the two reasons: to implement multihoming without BGP (valid) and to avoid renumbering inside network(s) when the ISP assigns you a new IPv6 prefix. Let’s focus on the renumbering claim today.

Trevor Pott wrote an interesting article in The Register (linking to my IPv6 multihoming post – thank you!) explaining how, in his opinion, IPv6 sucks for small and medium businesses. I wholeheartedly agree with some of his conclusions (actually, agreed with them for the last three years), but unfortunately the article contains several factual errors that simply have to be corrected (I doubt many of Trevor’s readers will actually find their way to this article, but one can always hope).

Instead of drinking beer and lab-testing vodka during the PLNOG party I enjoyed DHCPv6 discussions with Tomasz Mrugalski, the “master-of-last-resort” for the ISC’s DHCPv6 server. I mentioned my favorite DHCPv6 relay problem (relay redundancy) and while we immediately agreed I’m right (from the academic perspective), he brought up an interesting question – is this really an operational problem?

One of the few presentations I could understand @ PLNOG meeting yesterday (most of them were in Polish) was the fantastic “Guide To Building Secure Network Infrastructures” by Merike Kaeo, during which she revealed an obvious but oft forgotten fact: by deploying IPv6 in your router, you’ve actually created a parallel entry into the management plane that has to be secured using the same (or similar) mechanisms as its IPv4 counterpart.