IPv6 Everywhere

In a recent, rather unscientific poll on Reddit, IPv6 advocates were asked how much IPv6 address space did their respective ISPs give them. It looks like ISPs are getting it, and on average giving out a /56 to home users, which should be plenty for most.

The results

• U.S.
  • Comcast /60
  • TWC/Spcturm /64 (with “hint” /56)
  • AT&T Uverse /60
  • Cox /56 (with “hint”)
  • Charter /64
  • Frontier (no IPv6 support)
• Canada
  • Rogers /56
  • TekSavvy /56 (DSL-0nly)
  • Telus /56
• UK
  • Sky /56
  • BT /56
  • IDNet /56
• Germany
  • Deutsche Telecom /56
  • 1&1 /56
  • Unitymedia /56
• France
  • Free (5 /64s)
• Norway Telenor NO xDSL /48
• Denmark Kviknet /48
• Europe  Orange /56
• Austrailia
  • Internode /56 (static, tied to account, nice!)
  • Australian WISP /56
• New Zealand  2degrees /56 static (or /48 dynamic)

The good and bad

Of course, this is the good news. The less good news is that there are still ISPs out there which provide no IPv6 support for their customers. But it is a good start, and those who are supporting IPv6 have realized that one /64 at the home isn’t enough networks for the future (think: /64 for IoT, /64 for appliances, /64 for HVAC (such as Nest), /64 for your kids, etc, all with different traffic rules). Keep up the good work.

It has felt funny telling people that IPv6 is the new internet protocol, since it is almost 20 years old. But now with RFC 8200, I can honestly say, IPv6 is the new internet protocol which will replace the old creeky-nat-ridden IPv4 protocol.

RFC 8200, if you haven’t seen it, obsoletes RFC 2460 penned in 1998. The title says it all, “Internet Protocol, Version 6 (IPv6) Specification”. It is not a rewrite of the protocol, but rather an encapsulation of the many errata and clarification RFCs. The authors have conveniently put the differences/changes from RFC 2460 in Appendix B, to help people already familiar with IPv6 get up to speed with the new specification.

So go out and honestly tell everyone, there’s a new protocol on the block, and it is IPv6.

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

13.25 years ago, in January 2004, the University Of Hawaii hosted the Techs In Paradise conference in Honolulu. During that conference we provided IPv6 connectivity to Japan, via our STM-1 to APAN Tokyo, and NICT operated a demonstration involving radio controlled model cars with tiny cameras aboard, where drivers at JGN Tokyo could operate cars in Honolulu, and vice versa. It was the beginning of operational IPv6 networking in Hawaii. Sure, for several years after, an IPv6 outage didn’t cause any users to call the help desk, but the operational core was there.

CRL (now NICT) researcher operates the system from the Honolulu end.

In late 2008, we obtained our own IPv6 addresses from ARIN (previously,  we had an allocation from Internet2), and began to operate our dual-stack university network in earnest.  At the time, IPv6 clients were somewhat sparse, but were present in increasing numbers. Windows Vista had IPv6 features built in and turned on the previous year, and was actually more popular than anybody admitted, and even Windows XP had limited, but usable IPv6 support. Mac OS X Leopard also supported IPv6, as did Linux. Cisco, Juniper, Foundry, and other vendors were including IPv6 features in routers. (Of course the 2017 perspective might lead you to ask about smart phones, but smart phones and PDAs were only then beginning to affect the way people accessed the Internet. iPhone 1, out that year did not originally support IPv6. )

In mid 2009, we turned on IPv6 peerings with TW Telecom, giving us IPv6 connectivity on all sides, no longer exclusively with Internet2. In the 8 years since, we have operated an operational dual-stack IPv6/IPv4 network, and the team mantra became “IPv6 is not an experiment – there is no IPv6 guy, we are all IPv6 guys.” IPv6 operations have gone smoothly. New staff receive no IPv6 training beyond OJT. And like staff at other organizations who have deployed IPv6, the common impression is that it’s pretty much like operating an IPv4 network, with longer addresses. There are a couple of new concepts to assimilate, with addressing plans, address assignment and tracking, but the operation of a dual-stack network does not require your staff to learn anything that they’re not already required to learn about advancing technology on a weekly basis.

As of right now, Google, YouTube, Netflix, FaceBook, Akamai, and other big content providers all provide our users with content over IPv6. Within our State-wide network, IPv6 deployment is still elective for departments and institutes that operate their own LANs, but ITS administered networks include IPv6. Most of our institutional content is not yet offered over IPv6, part of a national condition, where IPv6 connectivity is deployed in 111 different Internet2 Member university’s networks,  but not in most of their data centers.

Dissent

In the process of meeting various people at gatherings around the country, and reading various articles and posts on the Internet, I’ve come to appreciate that there is a lot of loose, non-sequitur rationalization afoot, and little is being done to counter it, or address it. To fill that void, I want to address a series of prevalent rationalizations people offer as to why they’re not doing IPv6.

Rationalization #1: “IPv6 isn’t ready yet. We’re waiting for it to mature”

I’ve been doing it for 13 years, and I have to say that this excuse doesn’t stand up to scrutiny. IPv6 works as well as IPv4, and it’s no more or less secure or private. Plus, it’s out there, on your network, whether you like it or not, since all modern operating systems include it, and it’s turned on.  If you’re pouring energy into turning off and suppressing IPv6 on your network, you’re wasting more time and energy than you would just including it in your plans.

Rationalization #2: “Our users aren’t requesting it.”

It’s a mystery to me how anyone could offer this as a reason, and not immediately realize how silly it sounds, but somehow people manage to. Of course your users aren’t requesting it, why would they? Furthermore, you could use it as a selling point, in the tradition of printing the words “Field Effect Transistor Technology” on a stereo receiver, or offering Internet connections with “Fiber”.  Users don’t care what layer 3 protocol they’re getting, they don’t care if their fast connection arrives over fiber or coax or WiMax, until you tell them it’s a premium feature. Bottom line is: deploying IPv6 is positioning your network to provide better experience to your users, a better experience for which your users will call you to account when you don’t provide it, or more likely, they’ll vote with their feet. Early, pervasive IPv6 deployment is competitive. Compete or perish.

Rationalization #3: “IPv6 is unfamiliar and we can’t afford to prioritize training for it.”

As I said, at the University Of Hawaii, these last 8 years:

• All of our staff are IPv6 capable
• Our only IPv6 training is on-the-job

It’s really not unfamiliar in practice, those who have deployed it usually say that it’s like managing IPv4, with longer addresses. The difference between organizations that deploy IPv6 and those who don’t is simply rationale.

Rationalization #4: “IPv6 addressing reduces user privacy”

Stop reading old articles. With the inclusion of RFC 4941 privacy addressing in modern OSes, as well as RFC 3972 cryptographically generated addresses, IPv6 offers more privacy and security than IPv4 does.  (ISOC post on this)

Rationalization #5: “The IETF messed up. They got it wrong.”

If you’ve ever been to an IETF meeting, you know that the IETF does not lack for:

• people as insightful and sophisticated as you
• people willing to belabor a point

The IETF is not a software vendor. You are part of the process by which IPv6 will fill your future needs. If there are things about IPv6 operations that you want to effect change in, become part of the process.

Furthermore, the IETF got a great deal right, after MUCH rumination and discussion. They envisioned a future for the Internet, they considered whether it was better to make IPv6 backward compatible or not, they came up with what we have now. The next step is to deploy it, and discover the details in practice.

Who’s Accountable?

In most layer-3-protocol-change-denial rationalizations, there is a tacit insinuation that someone, somewhere is negligent, and that deployment can only reasonably occur when that someone-who-is-ultimately-responsible for IPv6 gets their act together. What the world needs now is for enough networks to deploy so that the global Internet reaches the tipping point, where those who face problems from IPv4 address exhaustion can begin to use IPv6 as a solution. In order for that tipping point to be realized, a majority of networks must deploy IPv6, both by providing user connectivity and by providing services and content over IPv6.

If “critical mass” is the needed milestone, then anybody who’s in a position to deploy IPv6, but doesn’t is the obstacle to it becoming useful.

Who’s accountable? You are. If you’re tempted to pick nits and offer anti-deployment counterpoints, consider that it’s up to you. You’d be arguing with yourself. I don’t offer to account for your talking points, but I do offer to engender a discussion about v4/v6 parity, about developing best practices, and about documenting solutions that will enable you to use IPv6 today to deploy systems that will be ready to engage the future-ready Internet.

Minimal Internet citizenship involves taking the steps to deploy a dual-stack network, with NATed v4 and native v6 if necessary. Call your ISP and complain, pound on the table when your vendors say “probably first quarter next year”. The global community of Internet operators will ultimately determine the Internet’s form, and the best form available is an IPv6 Internet.

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.

DREN has the some of the most extensive enterprise-to-end-user experience around —

Internet Protocol version 4 (IPv4) is nearly thirty years old. This
critical part of the Internet’s infrastructure is approaching its end of
life, as the last five unallocated IPv4 address blocks were delegated to
Regional Internet Registries on February 3, 2011. This won’t have an
immediate impact on the way people use the Internet, but both dwindling
IPv4 address availability and the requirement to start using IPv6 will
impact the way that Federal Agencies and commercial businesses provide
Internet services.

The Defense Research and Engineering Network (DREN) started using IPv6
in 2003. DREN has provided it users with servers, services, and client
applications using IPv6 since then. As the Internet transition from IPv4
to IPv6 plays out, DREN will continue providing a secure,
high-performance infrastructure using both IPv4 and IPv6.

DREN also provides lessons-learned from its years of experience with
IPv6 on an extensive knowledge base. This is publicly available on the
DoD’s High Performance Computing Modernization Program web site
(www.hpcmo.hpc.mil).
1. Click on Networking and Security in the left hand column
2. Click on IPv6 Information in the right hand column
3. Click on IPv6 knowledge base at the bottom of the article.

Or, use this direct link:
http://www.hpcmo.hpc.mil/cms2/index.php/ipv6-knowledge-base-general-info
.

For more information about DREN and IPv6, please contact: John M Baird, HPCMP IPv6 Implementation Manager, (703) 402-9638

It has been a continual surprise to me that, with so many things to do, people who work in IPv6 advocacy have spent so much time arguing about the accuracy of IPv4 depletion predictions, and asking why competing estimates didn’t match.

Since two weeks ago, or so, the guessing stopped, and yesterday, a ceremony/press conference was held in Miami, a joint event among ICANN, NRO, AfriNIC, APNIC, ARIN, LACNIC, RIPE-NCC, IANA, and the Internet Society.

So far, ICANN’s summary page is the most complete that I’ve seen:

http://icann.org/

What happened is this: IANA, the dispenser of all IP addresses, handed out the last of their IPv4 addresses and will dispense no more.

What does this mean? It means that the addresses in the hands of the Regional Internet Registries will be the last that they dispense to end-users, and that alternate means of acquiring addresses will be sought.  People who have addresses will do deals with people who need addresses.

I was tempted to scoff when the assertion was made by NRO that address selling will still occur by the guidelines currently used by RIRs, because I had sort of pictured the post-depletion address market as wild west black market kind of thing. But when you think it through, would you give want to give somebody money for addresses which would not be described as belonging to you in the registry? Probably not.  At the same time, address rentals will become common too, and they may not need to heed RIR procedures. A brave new world, hopefully not a Huxley-esque.

I wax:

“Ending is better than mending. The more stitches, the less riches.”
– Aldous Huxley, Brave New World, Ch. 3

or, if you prefer:

“Cleanliness is next to fordliness.”
– Aldous Huxley, Brave New World, Ch. 7

A good meeting with a primarily open agenda, March 10 benefited from new input from several first-time-attendees.

Brian made a phone-picture-panorama of us in mid-discussion.