Category: IPv6

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.

Till a few weeks ago, you could get provider-independent (PI) IPv6 address space in RIPE region only if you “demonstrated that you’ll be multihomed”, which usually required having nothing more than an AS number. With the recent policy change, anyone can get PI address space (and this is why you should get it) as long as they have a sponsoring LIR, and the yearly fee for an independent resource (RIPE-to-LIR) is €50.

A while ago I described the pre-standard way Cisco IOS used to get delegated IPv6 prefixes from a RADIUS server. Cisco’s documentation always claimed that Cisco IOS implements RFC 4818, but you simply couldn’t get it to work in IOS releases 12.4T or 15.0M. In December I wrote about the progress Cisco is making on the DHCPv6 front and [email protected] commented that IOS 15.1S does support RFC 4818. You know I absolutely had to test that claim ... and it’s true!

IPv6 hosts can use stateless or stateful autoconfiguration. Stateless address autoconfiguration (SLAAC) uses IPv6 prefixes from Router Advertisement (RA) messages; stateful autoconfiguration uses DHCPv6. The routers can use two flags in RA messages to tell the attached end hosts which method to use:

• Managed-Config-Flag tells the end-host to use DHCPv6 exclusively;
• Other-Config-Flag tells the end-host to use SLAAC to get IPv6 address and DHCPv6 to get other parameters (DNS server address, for example).
• Absence of both flags tells the end-host to use only SLAAC.

One might assume that setting managed-config-flag in RA messages forces IPv6 hosts to use DHCPv6. Wrong, the two flags are just a polite suggestion.

I got a follow-up question to the Should I use 6PE or native IPv6 post:

Am I remembering correctly that if you run IPv6 native throughout the network you need to enable BGP on all routers, even P routers? Why is that?

I wrote about BGP-free core before, but evidently wasn’t clear enough, so I’ll try to fix that error.

Imagine a small ISP with a customer-facing PE-router (A), two PE-routers providing upstream connectivity (B and D), a core router (C), and a route reflector (R). The ISP is running IPv4 and IPv6 natively (no MPLS).

One of my students was watching the Building IPv6 Service Provider Core webinar and wondered whether he should use 6PE or native IPv6 transport:

Could you explain further why it is better to choose 6PE over running IPv6 in the core? I have to implement IPv6 where I work (a small ISP) and need to fully understand why I should choose a certain implementation.

Here’s a short decision tree that should help you make that decision:

Aleksej sent me an intriguing question: “Can the /48 PI block that a global company is assigned be attached to any region, or it is region-specific?”, or, more specifically:

Imagine a company with major DC with public services in EMEA. Centralized internet break-out in Europe fails and this DC must be reachable from Asia or America - but with the same IPv6 address? That would require Asia or America's ISPs to accept injection of this same subnet in their region. Do they do that?

In theory, the answer is yes. In practice, some global organizations are hedging their bets.