Author: Craig Miller

There are still people who are uncomfortable with the decision to not include variable subnet masking in IPv6, and making every end-user subnet a /64.

The latest is a drift before the IETF entitled “IPv6 is Classless” which if adopted would allow differing prefix lengths out to /128. But I would ask why? If you want to see what breaks when deviating from the /64, I recommend reading RFC 7421.

How NOT to have people use IPv6 on your Corporate Guest Network

But I have seen corporate guest networks that were /119? I had to think about that one. The line of thinking is that a /119 is like a /23 in IPv4-land, allowing 512 host addresses. But why? When I asked about SLAAC support, the IT guy replied that they don’t support SLAAC (sure, because you need a /64 to support SLAAC). So therefore every Android phone which joins the corporate guest network will not be able to use IPv6. That is an 80% market-share of phones or 4 out of 5, that won’t be using IPv6 on the guest network.

Simplify the network

The /64 network has a certain simplicity to it that hearkens back to when I worked for UH (University of Hawaii) in the early 90’s when the entire campus was (IPv4) /24s, even the point to point links. There was a certain simplicity to it that made the network easy to understand.

Move beyond the address-scarcity mentality

There are those who would argue that it is a crime against the internet to waste all that address space for a point to point link by using a /64. But I would argue that is IPv4-thinking. An analogy I give is that address space is like breaths of air. When you are scuba diving, every breath counts, that tank on your back only holds so much air and when it is out, it is out. Where as, when we get up in the morning, we don’t think “how many breaths have I taken since I brushed my teeth?” After all, even with air pollution, the Earth’s atmosphere is vast! The scuba tank is IPv4, and the Earth’s atmosphere is IPv6.

Go ahead, take a deep breath, it will be OK to use /64s everywhere.

• this is a re-occurring theme, discussed earlier

One of the messages that was clear at this year’s North American IPv6 Summit is that Dual-Stack is only halfway there. We don’t really want to maintain two networks (IPv4 and IPv6) forever. We want to get to IPv6-Only networks.

Moving to IPv6-Only

The good news is that major corporations, such as Cisco, Microsoft, and Comcast, are moving in this direction. With them in the lead, we don’t have to reinvent the wheel when transitioning our own networks for IPv6-Only.

However, another key message at the conference was that there will be a Long-Tail of IPv4 use. We don’t have the luxury of abandoning IPv4 just because it is simpler to manage a single protocol IPv6 network.

Transition: MAP-T

Therefore we need to create transition mechanisms which allow older IPv4-only devices to gain access to the legacy IPv4 Internet. One of the transitions mechanisms which has potential is MAP-T (Mapping of Address and Port using Translation). Think of MAP-T as IPv6 quasi-tunneling in reverse. Rather than how we have been stitching the IPv6 network together with tunnels over IPv4, it is the reverse, carrying IPv4 over an IPv6-Only network.

RFC 7599 explains in detail how MAP-T operates, but here are the highlights

• The CE uses stateless NAT64 creating an algorithmic IPv4-IPv6 address mapping codified as MAP Rules
• A MAP IPv6 address identifier MAP-T includes the IPv4 destination address and a 16 bit PSID (Port Set ID) in the last 64 bits (IID) of the IPv6 address.
• CE IPv4-IPv6 forwarding behavior where IPv6 packets arrive from the BR, and are subject to NAT44 and translated to the private address Dual-Stack network.

MAP is bit more complex in that a CE and BR are required than standard stateful NAT64. However, it utilized stateless NAT64, which is expected to scale better.

Trying it out in a Virtual Lab

OpenWrt/LEDE both have MAP-T CE packages, and you can start exploring this transition mechanism now. In fact, Cisco has a very nice KVM Lab page, running everything (CE, DHCPv6 server, BR) in VMs, where no hardware is required.

I still see stateful NAT64 being useful for smaller networks, but MAP-T takes great strides at solving the scale problems of NAT64. So start thinking about IPv6-Only network, it is closer than you think.

The North American IPv6 Summit was held in Sunnyvale last month. It is always a pleasure to be in a large room with people who get it. There is no convincing that we need to give up our comfortable Linus-blanket of IPv4 for something new and different. No, everyone in the room is a convert, and many are outspoken advocates.

The conference was organized by the regional IPv6 Task Forces on the mainland: California IPv6 Task Force, Rocky Mountain IPv6 Task Force, Texas IPv6 Task Force, and Mexico IPv6 Task Force.

Speakers, shakers and movers

Some of the speakers were:

• Tony Scott, the former CIO of the Unitied States of America
• John Curran, the President and CEO of ARIN (American Registry for Internet Numbers)
• Kevin Jones, Chair for IPv6 transition at NASA
• John Brzozowski, Chief Architect, IPv6 and Fellow,  at Comcast

Major Points

Missed it? Here’s the presentations

Thanks to all the volunteers of the regional task forces, and Linked-in for hosting the conference. The presentations are posted online, in case you didn’t make it down to Sunnyvale last week. Hope to see you there next time.

This post previously appeared on ipv6-net.blogspot.ca

Microsoft released the Creator Update last month (11 April 2017) with lots of interesting stuff. But the most interesting for IPv6 is support for the RDNSS field in the RA (Router Advertisement). The RDNSS field is the one that carries DNS server information in the RA.

In order to run an IPv6-only SLAAC-based network the host must need 2 things: an address, and the address of a DNS server. Without DNS, IPv4 or IPv6 is pretty useless.

The fact that MS is now supporting SLAAC-only networks is a huge shift from their previous DHCPv6 only stance. Why is this important? Because there are use-cases for SLAAC-only networks, and now not only can you use your Android devices (which don’t do DHCPv6) but also your Windows 10 machines as well.

Windows continues to dominate the PC market with about 85%. Now with Windows 10 Creator Update, there is no excuse to not deploy IPv6 in your network now.