In the Future of Networking with Fred Baker Fred mentioned an interesting IPv6 deployment scenario: give a /64 prefix to every server to support container deployment, and run routing protocols between servers and ToR switches to advertise the /64 prefix to the data center fabric preferably using link-local addresses.
A month ago I told you how dr. Olivier Bonaventure starts his networking course with IPv6. But there’s more: the full textbook for the undergraduate course (Computer Networking: Principles, Protocols and Practice) is open-sourced and available (in source form) on GitHub.
You might wonder why I’m so enthusiastic, so let me tell you another story…
In mid-July dr. Olivier Bonaventure (one of the unsung networking heroes who’s always trying to address real-life problems instead of inventing unicorn solutions in search of a problem) sent an email to v6ops mailing list describing how they teach networking.
Short summary for differently-attentive:
You wouldn’t believe it – after almost 22 years (yeah, it’s been that long since RFC 1883 was published), IPv6 became an Internet standard (RFC8200/STD86). No wonder some people claim IETF moves at glacial speed ;)
Speaking of IPv6, IETF and glacial speeds – there’s been a hilarious thread before Prague IETF meeting heatedly arguing whether the default WLAN SSID should be IPv6-only (+NAT64). Definitely worth reading (for the entertainment value) over a beer or two.
One of my readers sent me an email that’s easiest paraphrased into: “Why can’t I have a different IPv6 link-local address (LLA) on every access port connected to a VLAN interface?”
There’s probably nothing stopping someone from implementing such an approach, but it would go against the usual understanding of how bridging and routing interact in L2+L3 switches.
An engineer watching my IPv6 Transition Mechanisms webinar sent me this question:
We would appreciate any insight you might have as to which transitional mechanisms the ISPs are actually deploying.
All of them ;)
A blog post by Russ White pointed me to an article describing how IPv6 services tend to be less protected than IPv4 services. No surprise there, people like Eric Vyncke and I were telling anyone who was willing to listen that operating two-protocol networks isn’t the same thing as operating a single-protocol one (see also RFC 1925 rule 4).
Tore Anderson has been talking about IPv6-only data centers (and running a production one) for years. We know Facebook decided to go down that same path… but how hard would it be to start from scratch?
Not too hard if you want to do it, know what you're doing, and are willing to do more than buy boxes from established vendors. Donatas Abraitis documented one such approach, and he's not working for a startup but a 12-year-old company. So, don't claim it's impossible ;)
Few years ago a bunch of engineers agreed that the customers need a comprehensive “IPv6 Buyer’s Guide” and thus RIPE-554 was born. There are also IPv6 certification labs, US Government IPv6 profile and other initiatives. The common problem: all these things are complex.
However, it’s extremely easy to get what you want as Ron Broersma explained during his presentation at recent Slovenian IPv6 meeting. All it takes is a single paragraph in the RFP saying something along these lines:
The equipment must have the required functionality and performance in IPv6-only environment.
Problem solved (the proof is left as an exercise for the reader… or you could cheat and watch Ron’s presentation, which you should do anyway ;).
Luka Manojlovič, a networking engineer with strong focus on Windows and IPv6 sent me a short status update on an enterprise IPv6 deployment:
Moved a whole enterprise network (central location + 17 remote locations) to dual-stack today. So far everything works.
While that sounds pretty easy, there was a lot of work going on behind the scenes. Here are some of the highlights:
Continuing the IPv6 address selection discussion we have a few days ago, Luka Manojlovič sent me a seemingly workable proposal:
I think we were discussing a borderline problem. In a server environment there won’t be any SLAAC, and we could turn off DHCPv6 client on servers with fixed IP addresses.
Sounds great, but as always, the reality tends to be a bit harsher.
The proponents of microsegmentation solutions would love you to believe that it takes no more than somewhat-stateful packet filters sitting in front of the VMs to get rid of traditional subnets. As I explained in my IPv6 Microsegmentation talk (links below), you need more if you want to have machines from multiple security domains sitting in the same subnet – from RA guard to DHCPv6 and ND inspection.
The breadth of address allocation options available in IPv6 world confuses many engineers thoroughly fluent in IPv4, but it also gives operating system developers way too many options… and it turns out that different operating systems behave way differently when faced with the same environment.
2016-01-21: In the meantime, Luka got further details on Windows behavior, and Enno Rey provided a few additional links.
If you’re a host running on an IPv6-only network, you might want to detect the IPv6 prefix used for NAT64 (for example, to transform IPv4 literals a clueless idiot embedded into a URL into IPv6 addresses).
In an amazing turn of events, at least one IETF working group recognized we have serious problems with IPv6 multihoming. According to the email Fred Baker sent to a number of relevant IETF working groups:
PI multihoming demonstrably works, but PA multihoming when the upstreams implement BCP 38 filtering requires the deployment of some form of egress routing - source/destination routing in which the traffic using a stated PA source prefix and directed to a remote destination is routed to the provider that allocated the prefix. The IETF currently has no such recommendation, or consensus that it should have.
Here are a few really old blog posts just in case you don’t know what I’m talking about (and make sure you read the comments as well):