IPv6 at NANOG 64

tcoffeen

By Tom Coffeen, Chief IPv6 Evangelist, Infoblox

 

Last week I attended (along with 1200 of my closest friends) the 64th meeting of North American Network Operator’s Group. NANOG 64 was held at the lovely and historic Westin St Francis right on Union Square near downtown San Francisco. Given that the first meeting was held way back in June of 1994, NANOG is easily the oldest as well as biggest and best-known of the vendor-independent internetworking technology conferences in North America.

 

The highlight of the conference in terms of IPv6 was Tuesday's panel discussion titled “The Benefits of Deploying IPv6 Only.” Presided over by none other than Dr. Geoff Huston, APNIC’s chief scientist (and an arguably nonpareil interpreter of Internet trends), the panel included participants from Comcast, T-Mobile, and Facebook. After some introductory slides from Dr. Huston, each gave a very brief presentation highlighting their perspectives on IPv6-only in the context of their current deployments.

 

Comcast’s Chief IPv6 Architect and Fellow John Jason Brzozowski went first. Comcast is of course known for their pioneering and unceasing IPv6 adoption efforts in the fixed broadband Internet space. Comcast’s efforts in this space (led by Brzozowski) have advanced technologies critical to cable Internet providers everywhere (technologies like DOCSIS 3.0 and improved CPE support for IPv6 being just two examples). 

 

Brzozowski revealed additional details regarding Comcast’s IPv6 deployment. For instance, they directly provide around 60% of the cable modems to their subscriber base. Such a significant percentage suggests at least one way in which Comcast has managed to accomplish their impressive degree of IPv6 adoption. CPE readiness in general for IPv6 is arguably the biggest impediment to its deployment by ISPs.

 

Regular readers are likely already familiar with the measurements offered on the World IPv6 Launch site as well as Comcast’s impressive showing of IPv6 as a percentage of overall traffic (Figure 1).

 

Figure 1: Comcast IPv6 traffic

 

Brzozowski suggested that the 37% figure might that 60-65% of the Comcast infrastructure is natively provisioned for IPv6 and that that percentage will rise to 80-85% in the next two years. He also remarked that a persistent 10-15% of cable modems with no IPv6 support will keep IPv6 adoption below 100% on the Comcast network for some time to come.

 

Also mentioned were Comcast’s future plans for their X1 network to move to IPv6-only as well as the possibility of IPv4 as a Service (IPv4aaS) running on an IPv6 underlay network (this was detailed in a separate presentation covered briefly below).

 

Guarav Madan from T-Mobile spoke next. He briefly reviewed T-Mobile’s key participation in the development and deployment of the 464XLAT standard. 464XLAT provides a lightweight mechanism on the mobile device to support apps that had no IPv6 support; e.g., WhatsApp, Skype, Spotify, etc (see Figure 2).

 

Figure 2: 464XLAT example

 

Madan pointed out that, as a result of the adoption of this approach, the T-Mobile US network has more IPv6 users than IPv4, and that T-Mobile’s future growth trends favor IPv6. The percentage of T-Mobile traffic over IPv6 is good evidence of the benefit of their approach (Figure 3).

 

Figure 3: T-Mobile IPv6 traffic

 

Paul Saab, the face of IPv6 at Facebook, spoke next and offered perhaps the most surprising information of the entire presentation: where the Facebook mobile app is concerned IPv6 way outperforms IPv4 (Figure 4).

 

 

Figure 4: US mobile performance, dual-stack iOS 

 

While all the details and conditions of the test were not revealed or discussed, Mr. Saab offered more evidence that, for at least some applications, IPv6 may offer better performance than IPv4. The reader may recall that Facebook’s internal production architecture is close to 100% IPv6-only.

 

At the end of his time Mr. Saab made a somewhat oblique (if very welcome) appeal to corporate America, and by extension enterprise IT. His appeal fell along the lines of "Let’s all use IPv6. It’s easier to deploy than you might think!” Couldn’t agree more, Paul! The only thing I might add to such an important sentiment is that IPv6 is already running (in various states of manage or unmanage) on corporate America's internal networks. 

 

Dr. Huston wrapped things up with another warning, ostensibly aimed at enterprise IT: "“Stupid DNS tricks are not going keep IPv4 alive forever” and "You will be buying IPv6 cloud services."

 

You can watch the presentation here.

 

On Wednesday, Comcast engineer Brian Field offered an interesting IPv6 presentation titled: Motivation, Analysis, and Architecture for IPv4aaS.

 

In the presentation, Brian explored one of the ongoing challenges of running both IPv6 and IPv4 for service provider networks: Additional FIB memory utilization is required by IPv6 where FIB is already scarce thanks to the growth of the global routing table. FIB memory is getting squeezed even more thanks to the ongoing and increasing deaggregation of IPv4.

 

Yet Mr. Field showed that, according to his research, out of the 575K total IPv4 prefixes, 549K of them receive only 1% of the overall traffic. As a result, an IPv4aaS overlay (on an IPv6 underlay network) could dramatically decrease the size of the FIB as well as easily carry the requisite IPv4 traffic.

 

The rest of the presentation covered the proposed architecture, which used a combination of Locator/Identifier Separation Protocol (LISP) for translation at the edge of the overlay network and BGP as JSON with a LISP header (Figure 5).

 

Figure 5: BGP as JSON with a LISP header

 

While the proposed design appears aspirational at this point in time, it is interesting to see how service providers are arriving at similar architectural solutions given the additional operational and capital costs of maintaining two protocols (something I have long argued will result in explicit or implicit additional costs for their customers; i.e., an "IPv4 tax”). Deutsche Telekom’s TeraStream initiative proposed SDN solution leads to the need for things like DHCPv4 over IPv6.

 

You can watch Brian’s presentation here.

 

With any luck, I’ll be at NANOG 65 being held in Montreal, Quebec. Hopefully, I’ll see you there! Thanks for reading.