Category: IPv6

Every time someone throws me an IPv6 curveball, I’m surprised when I discover another huge can of worms (I guess I should have learned by now). This time it started pretty innocently with a seemingly simple PPPoE question:

What happens if an ISP decides to assign dynamic IPv6 subnets? With static assignment, the whole stuff is pretty straight-forward due to ND, RA & DHCPv6, but if dynamic addresses are used, what happens if the subnet changes - how will the change be propagated to the end-user devices? The whole thing is no problem today due to the usage of NAT / PAT...

LAN address allocation with changing DHCPv6 prefix is definitely a major problem, but didn’t seem insurmountable. After all, you can tweak RA timers on the LAN interface, so even though the prefix delegated through DHCPv6 would change, the LAN clients would pick up the change pretty quickly. WRONG ... at least if you use Cisco IOS.

During my last Building IPv6 Service Provider Core webinar I got a lot of questions about IPv6 over PPPoE (obviously we’re close to widespread IPv6 implementation; I never got PPPoE questions before). I wanted to test various scenarios in my IPv6 lab and thus enabled PPPoE on an Ethernet link between CE and PE routers.

This time I wanted to test multiple configurations in parallel ... no problem thanks versatile PPPoE implementation in Cisco.

The attendees of my Building IPv6 Service Provider Core webinar get several sets of complete router configurations for a six router lab that emulates a typical Service Provider network with a residential customer and an enterprise BGP customer. The configurations can be used on any hardware (real or otherwise) supporting recent Cisco IOS software, allowing you to test and modify the design scenarios discussed in the webinar.

IT World Canada has recently published an interesting “Disband the ITU's IPv6 Group, says expert” article. I can’t agree more with the title or the first message of the article: there is no reason for the IPv6 ITU group to exist. However, as my long-time readers know, that’s old news ... and the article is unfortunately so full of technical misinformation and myths and that I hardly know where to begin. Trying to be constructive, let’s start with the points I agree with.

IPv6 was designed to meet the operational needs that existed 20 years ago. Absolutely true. See my IPv6 myths for more details.

ITU-T has spun up two groups that are needlessly consuming international institutional resources. Absolutely in agreement (but still old news). I also deeply agree with all the subsequent remarks about ITU-T and needless politics (not to mention the dire need of most of ITU-T to find some reason to continue existing). That part of the article should become a required reading for any standardization body.

And now for (some of) the points I disagree with:

2019-09-01: Stumbled upon this old blog post and fixed the "IAB adoption of CLNP" part. Would love to know more about what was going on, but couldn't find any details apart from a few vague mentions.

We all know that IPv6 deployment is a chicken-and-egg problem: Service Providers are slow to adopt IPv6 because they can’t charge for it and the content providers don’t care because there are no IPv6 customers.

My good friend Jan Žorž got a great idea during the Google IPv6 Implementers Conference and finally managed to write it down: all we need is a slight search engine preference for sites reachable over IPv4 and IPv6. A small well-publicized tweak in Google’s scoring algorithm would push the content providers toward IPv6 and force web hosting companies to roll out IPv6 support immediately.

The CFO magazine has recently published a FUDful article “Trouble Looms for Company Websites” (read it to see what CFOs have to deal with). Obviously, some people think it’s a good idea to throw FUD at CFOs to get the budget to implement IPv6. Long term, it’s a losing strategy; your CFO will become immune to anything coming from the IT department and ignore the real warnings.

Yes, it's time to make your content reachable over IPv4 and IPv6, more so if you’re in the eyeballs business. Google knows that. So does Facebook. Twitter doesn’t seem to care. Maybe because they’re not selling ads?

Following my “Transition to IPv6” articles, Jessica Scarpati from SearchTelecom.com wrote a series of articles covering the telecom transition plans and the problems they’re experiencing with the vendors and content providers.

In the second article of the series, “Deploying IPv6? Demand responsiveness from vendors, content providers”, she’s quoting John Jason Brzozowski from Comcast, John Curran from ARIN, Matt Sewell from Global Crossing and myself. My key message: vote with your money and take your business elsewhere if the vendors don’t get their act together.

One of the biggest hurdles Internet Service Providers will face in the near future is access to legacy IPv4 content once we run out of globally routable IPv4 addresses. Although it’s easy to offer your content over IPv6 (assuming you have a properly designed network using load balancers from a company that understands the need for IPv6 in Data Center), a lot of the “long tail” content will remain reachable only over IPv4.

A while ago I’ve published a presentation I’d delivered at the Slovenian IPv6 summit; a few days ago SearchTelecom.com has published my article describing various transition solutions in more details. In the first part, “IPv4 address exhaustion: Making the IPv6 transition work”, I’m describing the grim facts we’re facing and the NAT-PT fiasco. In the second part, “Comparing IPv6 to IPv4 address translation solutions”, you’ll find brief descriptions of LSN (also known as CGN – Carrier-Grade NAT), NAT444, DS-Lite, A+P and NAT64.

During the last Google IPv6 Implementors Conference Donn Lee from Facebook showed how easy it is to make your content available over IPv6 and LISP ... if you happen to have the right load balancer that supports IPv6 (to view his presentation, click the slides link next to his name in the conference agenda). I would say all the excuses why your content cannot be possibly made available over IPv6 are gone (and one can only hope that a certain vendor I’m often mentioning will finally realize IPv6 is needed on more boxes than just routers and switches).

Hat tip to Andrej Kobal who sent me the link to the FB presentation.

It’s amazing what people would try to patent ... and it’s even more amazing what gets past the examiners. IBM has managed to patent passing ipv6 or dhcp argument to indicate an IP host should network-boot over IPv6 or using DHCP. The idea is so trivial it’s almost not worth mentioning and goes along the lines of: “usually we use BOOTP and TFTP to get network boot parameters, but imagine we could pass DHCP as the argument to the boot routine and then it would use DHCP instead of BOOTP”.

The patent supposedly covers a very specific case, but (to my untrained eye) the claims are written in a way that could cover almost any IPv6- or DHCP-assisted network boot (or at least give lawyers plenty of stuff to charge for) ... exactly what we needed with all the other roadblocks and stumbling stones to IPv6 deployment.

Hat tip to John Curran for bringing this one to my attention.

IS-IS has “forever” (at least since RFC 1195) supported multiple layer-3 protocols, but always with a nasty side-effect: if a link in your network did not support one of them, you could get hard-to-diagnose black holes.

The problem is illustrated in the left-hand column of the following diagram. Due to a single IS-IS topology, the shortest path between A and B is the direct link, and since IPv6 is not enabled on that link (click on the diagram to get an enlarged version where you'll be able to see the link colors), A and B cannot exchange IPv6 traffic even though there’s an alternate path between them.

Andrej Kobal from Astec shared a few interesting facts during the 3rd Slovenian IPv6 summit: they were deploying a pilot IPv6 subnet in a large network and wanted to retain tight control over the IPv6 address assignment (some people don’t consider random address chasing embraced by Windows the best use of their time), so they’ve decided to use DHCPv6. Bad luck: DHCPv6 can’t tell you the IPv6 address of the default router (like DHCP does). You need ICMPv6 RA (part of IPv6 Neighbor Discovery) to figure out who the router is.

If you want to protect the integrity of your network, you need to deploy SeND or RA guard as well as DHCPv6 guard on your switches. These features are not yet available on many L2 switches ... Catalyst 4500 and Catalyst 6500 are a notable exception. Catalyst 3750 also supports IPv6 port access lists.

Jan Žorž from go6.si is obviously a very successful IPv6 evangelist: not only did he manage to organize numerous IPv6 summits in Slovenia (which is probably one of the reasons Slovenia is the leading European country on the RIPEness scale); he’s also helped persuade the mobile industry to roll out pilot IPv6 services. Right now we have two mobile operators piloting IPv6; both dual-stack (with two PDP contexts) and IPv6 roaming are working flawlessly.

BTW, Jan still doesn’t understand the need to blog in English, so you all the links to his web site I’m including in this post are converted into English-resembling form by Google Translate.

Not surprisingly, such feats did not go unnoticed: Jan has been invited to present at the Google IPv6 Implementors Conference and managed to persuade Google to include an engineer from our local CPE manufacturer in the IPv6 CPE vendor panel.

I have nothing more to say than: CONGRATULATIONS & GOOD LUCK!

Quick summary for the differently attentive: Even without the DNS processing, NAT-PT and NAT64 differ from the perspective of peer-to-peer applications. The differences don’t matter for IPv6 clients connecting to IPv4 servers.

Whenever I’m talking about NAT64, someone would say “we’re already using it”. As it turns out, they’re usually using NAT-PT, which looks a lot like NAT64 from afar (after all, they both allow IPv6-only clients to connect to IPv4-only servers). However, there are significant differences between the two, the most important one being DNS64, which handles DNS processing completely outside of the forwarding path (NAT-PT has embedded DNS Application Level Gateway, which was one of the major reasons NAT-PT was declared broken beyond hope).

In another interesting timing coincidence, the documentation for IOS-XR release 3.9.1 appeared at approximately the same time (probably a little bit later) as I started to research the viability of CGv6 during the preparation for my NAT64/DNS64 presentation.

A kind guest has provided links to configuration guide and command reference in a comment to my blog post. Thank you!

Looking at the release notes, the CGSE blade currently supports only CGN (large-scale NAT44), the interesting parts (NAT64 or DS-lite AFTR) are still in the pipeline.