Date: October 7, 2008
IETF 72 panel discusses IPv6 deployment
During the IETF 72 technical plenary, the Internet Architecture Board (IAB) hosted a panel on the subject of IPv6 deployment. The five-member panel was composed of Internet community members who have firsthand experience with operational IPv6 deployments. They represent the perspectives of Regional Internet Registries, or RIRs; network operations teams; broadband services; content delivery services; and host applications. The panelists communicated their IPv6 adoption successes and hurdles, as well as their IPv4-depletion contingency plans, including carrier-grade network address translations (NATs), or CGNs, a concept that is currently under debate.
Motivation and Background
Studies suggest that the completion of IPv4 address allocations by IANA to the RIRs could occur as early as 2011 (seehttp://www.potaroo.net/tools/ipv4/). Regardless of the exact date, the idea of an empty storehouse will, without question, change the networking landscape. In an effort to prepare for that eventuality, various players are working toward widening and hastening IPv6 deployment.
Some content providers are planning ahead by readying their content for IPv6 endpoint hits. Some of the service providers and broadband providers that saw the need started their efforts some time ago, and they’re now moving toward infrastructure and service delivery that can and will run on IPv6. Both face a bit of a chicken-and-egg problem: the content providers would move faster if they knew the operators had the services fully baked to deliver IPv6 eyeballs to the content. And the operators would invest more in their IPv6 services and infrastructure deployments if the content the end customer demanded were available and abundant.
Enterprises are, in some way, the swing votes. Objectively, few enterprises have moved toward wide-scale deployments of IPv6. Some have IPv6 pilots; and a few have partial deployments, yet they may hit the v4 allocation cliff harder than either of the other two, aforementioned communities. This will leave enterprises in a costly scurry to rectify the situation at the last minute.
IPv6 deployment in operational networks across the Internet is a work in progress. Transition mechanisms have existed and been deployed for years, including dual stacks and various translation and tunnelling mechanisms. Over time, more hosts and networks are moving to native IPv6 operations. Collectively, we now have several years of experience with both.
The IAB established this plenary topic to provide background and input from those experienced with deployments and issues in order to empower the IETF community to do its part to encourage and facilitate the universal deployment of IPv6.
View from the RIRs
Mark Kosters, Chief Technology Officer, ARIN
Currently there are 39 IPv4 “/8″ address blocks (2^24, or 16,777,216 addresses) remaining in the IANA free pool that can be allocated by IANA to RIRs. In turn, the five RIRs that together cover the globe assign portions of the /8s to ISPs in their regions according to their local policies and practices. To give a sense of the allocation pace, in December 2004 there were 76 /8s remaining; in December 2005 there were 65; in December 2006 there were 55; in December 2007 there were 42; and in June 2008 there were 39. While the absolute number of allocations per year has remained somewhat constant, the percentage of remaining /8s being allocated is growing steadily each year.
If, as one model predicts (http://www.potaroo.net/tools/ipv4/), the IANA free pool runs dry in December 2011, then IP address blocks that have never been allocated to RIRs will be allocated. That won’t mean end users or corporations will no longer be able to get IPv4 public addresses from their ISPs. It means the currently defined IANA free pool allocations will be completed. Rather than receiving this news as Chicken Little would-as an indication that the sky is falling-Mark urged us to look at it like the westward expansion of the United States in the 1800s. At that time it was possible to go out and get land from the government for only a small registration fee-land that had not been previously farmed. Today, you can still acquire a farm or a large piece of land; it just costs a lot more, and it will have been owned by others-whether or not they used it-thereby giving it a definite market value. And today there exists a complex and robust market for titling, brokering, and owning the land. Likewise, the days of IPv4 address “homesteading” are coming to an end, and many more stringent policies, and, perhaps, markets, will emerge for dealing with IP address use and propriety.
The IPv6 address space, on the other hand, is a 128-bit space, of which IANA has given out very little. The homesteading of IPv6 has barely begun. The RIRs have been fairly active in the past few years in assigning IPv6 address blocks to their Local Internet Registries (LIRs) and ISPs, with RIPE NCC and APNIC being by far the most active. ARIN and APNIC were making similarly sized allocations since 2003-around the 40 to 50 mark per year-until 2007, when ARIN handled over a hundred IPv6 allocations. To date, RIPE NCC has dealt almost half of all of the IPv6 allocations-1,208-which equates to 33,041 /32s. The next closest is APNIC, with 580, accounting for 23,233 /32s, followed by ARIN with 496, LACNIC with 97, and AfriNIC with 47. These allocations are from the RIRs to providers. However, only ARIN, APNIC, and AfriNIC have actually assigned provider-independent (PI) address blocks to end sites directly. The RIPE NCC and LACNIC have not yet assigned PI IPv6 addresses; both have policy proposals in the works for doing so. PI address grants are held in tension because backbone routing for IPv6 has not yet reached the same scale and stability as those present in IPv4 BGP, and the community questions how much route bloat from PIs can be reasonably handled.
RIR Policy Development
With IPv4 allocation completion on the horizon, the volume of policy work by RIRs on this subject has ballooned. Fourteen policy proposals-almost half of the open proposals-concern IPv4 depletion policies. One of the proposals concerns global policy, which states that as IANA’s free allocations of /8s approach exhaustion, every RIR will get a /8. Another proposal deals with liberalizing the transfer policy for moving blocks of addresses between RIRs and LIRs and ISPs and organizations. In the IPv6 policy realm, proposals exist to make it easier to transition to and use IPv6. In the autonomous-system (AS) realm, the RIRs currently allocate a lot of 2-byte AS numbers. These would be exhausted in 2011 as well if the current allocation rate continues. There are 4-byte AS numbers available, but many parties have returned them because the network as a whole does not support them very well (e.g., BGP implementations and OSS systems). We need to encourage our vendors and ISPs to better support 4-byte ASs, because this is another hole-like the IPv4 depletion-looming on the Internet highway.
In addition to policy and allocations, the RIRs conduct a fair amount of awareness and promotion work for IPv6. The RIRs have taken an aggressive stance on trying to move IPv6 adoption forward. They have issued position statements, delivered awareness-raising and educational workshops, conducted research on IPv4 allocations and IPv6 deployment, provided education and advice for governments and nongovernmental organizations, and hosted IPv6 networks during meetings, such as those of the IETF-all to help drive IPv6 adoption.
“This is an important time of transition, and people need to participate,” Mark said in closing. “The registries’ policy development process is very bottom-up. So come join the effort.”
Lessons Learned from IPv6 Deployment
Alain Durand, Director of Internet Governance and IPv6 Architecture, Comcast
Comcast, a large cable operator in the United States, began its IPv6 deployments several years ago with a two-phase approach. First, it is readying the infrastructure by using IPv6 for management of cable modem devices and network infrastructure. This paves the way for the second phase, wherein Comcast will offer home users IPv6 service to their endpoints. That second phase is now in planning stages, with some lab trials under way.
The cable industry’s Data over Cable Service Interface Specification (DOCSIS) model assigns an IP address to each customer’s cable modem. This differs from DSL, wherein an individual modem does not have its own IP address. Cable operators thus use a lot of IP addresses and are very involved in allocation policy. Their move to IPv6 was somewhat motivated by the depleting IPv4 address space. They foresaw that in a few years an organization requesting a few IPv4 addresses for Web and mail servers might still easily get them, whereas a request to IANA for a large-scale allocation is likely to be turned down much sooner. Moving the modems’ management interfaces to IPv6 means that they each get a globally unique and routable IP address, thereby avoiding messy address overlaps or NATs.
The company learned important lessons from its initial experiments with IPv6 deployment. The first lesson taught that starting early saves money. For example, including IPv6 early in the DOC-SIS 3.0 specifications in early 2005 ensured that products rolling out today include IPv6 at no extra cost. The second lesson was that the network buildout for IPv6 was easier than expected. Comcast started by adding IPv6 addresses on router interfaces-and nothing else. To its surprise, nothing bad happened. So Comcast left the network like that for several months. Next, it enabled IPv6 routing, ISIS, and BGP. Again, nothing bad happened. Not one outage occurred that was traced back to the IPv6 pieces. This was a critical step in building the confidence of the operations team, proving that IPv6 could run stably in a production dual stack network. Currently, IPv6 exists in both Comcast’s access and backbone networks.
Photo by Peter Lötberg
For Comcast the problem with IPv6 was not in the networking layers but in the application and services ecosystem around the layers, like their operations and support, management, billing, and third-party systems. Not only do many of those systems lack the required IPv6 support, but getting that support is not high on most vendors’ priority lists. Adapting the code doesn’t happen overnight. It takes implementation, testing, debugging, deploying, scaling, and stabilizing. It’s a linear process that can be accelerated only so much by applying additional resources. “Nine women can’t make a baby in one month,” quipped Alain, urging application vendors to get moving. Hosted or out-sourced services from third-party vendors are in a spot similar to applications, wherein many do not yet support IPv6.
Seeing the IPv4 depletion ahead, the Comcast team is plotting a transition course that includes IPv4 access for quite some time. Once scarcity hits, the team imagines, a wide range of IPv4-only computers, devices, and operating systems will still exist in customers’ homes (e.g., Win95, 98, XP, PlayStations, Xboxes, and some consumer devices). Though more and more IPv6-ready equipment is entering homes, customers will not jettison the old IPv4-only equipment; they keep using the older devices. Also, the content on the Internet is almost exclusively IPv4. Recently, thanks to Google, we have some IPv6 content to look at, but not much. IPv4 hosts and content will need reachability for some time yet.
Comcast’s plan therefore involves a dual-stack core, which Alain says should work well-at least until it’s no longer possible to get any more IPv4 addresses. “Following IPv4 completion, if you give all new customers IPv6 only, with no IPv4 support, then the IPv4-only devices can’t get out of the home, and new, IPv6-only devices can’t get to the predominant IPv4-only content on the Internet.” To counter that hitch, one might add the practice of NATing new customers with overlays of private addresses from the RFC 1918 blocks. This brings undesirable results, though, such as NATs piled one on top of the other, with multiple overlapping addresses to customers. While not impossible, NATing creates a lot of complexity-especially in management-and it makes the troubleshooting of customer issues much more difficult. In addition, traffic-engineering gyrations, such as source-based routing, might be necessary to handle the overlaps. Outages are usually linked to complexity in the network, so this increased complexity in the network is less than desirable.
The Comcast team is looking at using tunnels and provisioning IPv6 to customers’ home gateways. This would enable Comcast to offer both IPv6 and IPv4 services to endpoints behind those gateways. IPv6 would run natively from hosts to IPv6 targets. IPv4 is delivered by first having the gateway speak IPv4 internally, and second, by transporting the IPv4 packet over the IPv6 infrastructure network via a tunnel. The IPv4 packet would be detunnelled inside the ISP network at a large v4-to-v4 NAT box, a CGN. That box translates the IPv4 packet to a globally routable IPv4 address and sends it off to the IPv4 target. Alain refers to this as a dualstack-lite service. (Work on this is occurring in the Softwire working group.) The advantage is that the infrastructure itself requires only IPv6 addresses for operated devices while allowing either IPv4-only or dual-stack hosts to reach IPv4-only content on the Internet. “This dual-stack-lite concept makes IPv6 services incrementally deployable,” claims Alain. “You don’t have to wait for the rest of the Internet-the content and applications-to move to IPv6 in order to roll out the service. You can deploy IPv6 in your own world and get some immediate benefit out of it.” The IETF’s most successful protocols over the past 15 years have been incrementally deployable, and that is Alain’s goal for networks transitioning to IPv6.
A Step-by-Step Transition Plan
Shin Miyakawa, Director of IP Technology Development at NTT Communications
While sharing much of Alain’s view of the need for incremental deployment of IPv6 in the face of depleted IPv4 space, Shin cautioned against accepting a common misunderstanding about carrier-grade NAT. “Please do not get comfortable with the idea that a carrier-grade NAT will “˜solve’ our problems,” he warned. “Do not believe that if we have a CGN, we need not move to IPv6.” On the contrary: according to Shin, the CGN concept has significant and serious restrictions as well as implications for the Internet’s end-to-end design principle. “The last thing we would want is the existence of a CGN to slow IPv6 adoption,” he said. Instead, Shin suggests employing CGN as a backward-compatible mechanism for the purpose of speeding along IPv6 adoption. “It will do so by ensuring an incremental deployability mechanism that does not exclude or alienate v4 hosts [nor v4 content] once deployed,” he said. Once such a model is supported, network operators will be able to see a clear transition path to IPv6 that contains neither product cliffs nor flagship upgrades.
Shin warned that the dual-stack lite’s CGN component may necessarily limit each customer’s number of concurrent sessions. TCP and UDP allow for only 65,535 total source ports per single IP address. As IPv4 addresses become scarce, a single public IPv4 address must support many CPE routers, each with several hosts behind it. How many hosts can be supported by one IPv4 address depends on the number of concurrent TCP and UDP connections being made by the average host.
Figure 1: When concurrent connections are reduced, an image may not be able to load appropriately
To illustrate that point, Shin offered the example of browser connections to a Google Maps display of San Francisco International Airport, an application that employs AJAX technology. One characteristic of AJAX is that it simultaneously makes many discreet HTTP connections from the host to the server in order to pull down different small “pieces” of the content all at the same time (see Figure 1). As Shin demonstrated, if the session count is limited to 30 concurrent connections, the map loads appropriately. If it is limited to 20, one block of the picture is missing. If it is limited to 15, only 35 percent of the picture’s blocks are successfully received. At a limit of 5 connections, the browser throws an error message. If each user needs only one such application connection at a time, then one IPv4 address would serve approximately 2,100 hosts. This 30-concurrent-connections number is for Google Maps only. The NTT Communications research team has observed iTunes opening 230-270, Amazon grabbing 90, YouTube pulling 90, and OCN’s Photo Friend consuming 170-200.
If one estimates an average of 500 open connections from a host-allowing for no safety buffer-one could infer for a CGN deployment a user-to-IPv4-address ratio of about 130:1. An 8:1 ratio would allow for a worst case, of about 8,200 simultaneous per-user connections. And for a case where multiple computers are all connecting from the same customer premise, a 20:1 ratio would allow for a worst case of about 3,300. What is the right ratio to use?
After warning of the CGN issues, Shin proceeded to offer a graphical, time-lapsed, step-by-step progression of how an operator might transition to an IPv6 network by using a dual-stack-lite ser-vice architecture. This transition plan offers incremental deployment and IPv4 backward compatibility. The operator starts by enabling IPv6 on its peering routers and backbone. Then the CGN element/function is added, which logically sits north of the operator’s access concentrator in the POP. The operator may then place a private IPv4 address on the CPE router’s provider-edge-facing (PE) interface. This IP will be NAT’ed by the CGN sitting in the operator infrastructure. This step addresses the decreasing availability of routable IPv4 addresses.
Step two introduces IPv6 on the customer side of the CPE, a client-based Softwire tunnelling solution from the customer’s hosts, and a tunnelling concentrator in the POP. This solution encapsulates IPv6 over IPv4 by using L2TP as the encapsulating protocol. A client-side software component sits on the customer’s host, and a networking device sitting north of the CGN terminates the L2TP tunnel in the operator’s network. At this point, the deployed network supports dual-stack customer hosts and delivers to those hosts connectivity to both v4 and v6 content.
As new customer deployments occur, Step 3 involves moving the Softwire v6-in-L2TP-over-v4 client function off the hosts and into the CPE router. This allows the clients sitting on the CPE’s private side to contain any or all of IPv4-only, IPv6-only, or IPv4/IPv6 dual-stack hosts while still providing access to either native v4 or native v6 Internet content.
Step 4 upgrades the provider edge (PE) access concentrator to be IPv4/IPv6 dual stack. Note that the Softwire tunnelling mechanism is required only until such time as both the PE access concentrator and the CPE support v4/v6 dual stack. Once both can run IPv6 natively, the operator has no further need for the tunnelling mechanism. This captures the attractiveness of the proposed transition plan: any of the key pieces-PE access concentrator, CPE router, or end-host system-can be combined in any combination of their v4-only or dual-stack support, and still, the operator will be able to deliver a v4/v6 service. This provides true incremental deployability for operators, saving them from costly forklift upgrades (for end hosts, CPE gear, or access concentrators) and providing them with a grow-as-you-go transition. The CGN remains in the network until the provider was prepared to end the life of the IPv4 service.
NTT is considering putting in place by spring 2010 a service as described earlier-before the IPv4 address completion. NTT is working with other ISPs on the same architecture, and such was discussed extensively at a recent Internet Area interim meeting on the v4-to-v6 topic. In the assistance of various enterprises, application service providers, schools, and governmental agencies with dual-stack deployments, Shin notes, externally facing systems (e.g., Web, e-mail, and DNS) must be IPv6 capable first; then the customers’ other, internal systems follow.
In addition to the aforementioned dual-stack proposal, the NTT group in Japan has already deployed a commercialized IPv6 service to over 5 million customers. This solution uses a highly controlled (i.e., walled garden), all-IPv6 network, including endpoints, to deliver specialized value-based services to end users.
What can the IETF do to hasten IPv6 adoption? According to Shin, first is an additional IPv4 private address space allocation for carrier/operator access network equipment that sits in the IETF’s internal infrastructure devices, behind a CGN. Next would be defining a simple security scheme for IPv6 (see page 23). Implementations of IPv6 DNS deployments need wider dispersion. Multiprotocol label switching (MPLS) with IPv6 support must exist in the network devices. Though commercially available IPv6 supporting firewalls have been available since NetScreen (now Juniper) released its in the early 2000s, other security devices-like IDP, IPS, and Web filtering-are still awaited, as are load balancers.
A Simple Call to Action
Lorenzo Colitti, Network Engineer and Researcher, Google
Google has one of the only large content sites deploying IPv6 today. Explaining why the company made the investment, Lorenzo stated, “When the day comes that users have only IPv6, they will need to be able to get to Google. That’s the long-term view.” He identified several shorter-term reasons for the deployment, including lower latency and packet loss, AJAX applications breaking behind excessive NAT (as described in detail by Shin), and the irritation of NAT traversal mechanisms, such as STUN. The year 2011 is when Google foresees the RIR IPv4 address pool exhaustion to their ISPs and PIs, and they point to IPv6 as the only sensible solution. Starting as early as possible will ensure deployment is ready in time, if not well before. The Google IPv6 effort began as a side (20 percent) project on the part of a few employees. Once others caught wind of ipv6.google.com, they jumped in alongside Lorenzo and team, and now Gmail and News are IPv6 enabled too. They built a pilot network and ran the infrastructure at an IPv6 conference, proving that it worked.
As more and more people wanted to get IPv6 running for their applications, the team grew and they scaled up the pilot. Even though it was a pilot, they dispelled the notion that it was experimental, which could lead to skimping on quality. The key lay in incremental growth. A pilot IPv6 network doesn’t have to be as scalable or as capable as an IPv4 network on day one, but it does need the same types of production services as soon as possible, as are found in IPv4 networks, including monitoring, support, documentation, written quality standards, and audits.
Start small, and make steady progress. In addition, Lorenzo urged that, whenever possible, one should design the IPv6 deployment to be as similar as possible to one’s IPv4 network. “Every time I made a design decision that wasn’t the same as IPv4, it turned out to bite me down the road,” he said.
Lorenzo counselled against the use of tunnels in interdomain routing, citing increased latency and difficulty in debugging. Also, today most IPv6 operators are indiscriminately giving transit to any other IPv6 operator, which slows convergence, increases round-trip times, and creates partial visibility for yours and others’ networks. Some transit providers have incomplete IPv6 routing tables that cause black holes for those routes. The solution is direct peering with quality IPv6 networks, yielding direct contacts by which to address and improve routing and connectivity issues. “Don’t assume the current IPv6 Internet works,” he said. “On the other hand, get involved. The only way to accelerate the progress is to accelerate the involvement.”
Lorenzo’s IPv6 product feature/capability wish list included MPLS traffic engineering, mature load balancing, IPv4-style multihoming, and hardware processing for both 6to4 and extension header filtering. Lorenzo notes that today they have to drop at the edge of their network every IPv6 packet that is not clearly TCP, UDP or ICMP due to a lack of hardware filtering for extension headers. IPv6-style multiple-address multihoming has not worked well. Failovers break TCP connections. Lorenzo says HIP and SHIM6 do support failovers, but then new connections see timeouts; both lack load balancing or traffic engineering from the network side, which are features present in v4. Without those features it’s tough to make large-scale applications deployable. Lorenzo also says multihoming ought to be allowed using /48 prefixes. He expressed the need for /127′s on point-to-point links (currently prohibited by RFC 4291) to help avoid denial-of-service attacks, and VRRP for v6 because neighbor unreachability is not fast enough.
NAT-PT is another item big on Lorenzo’s list because, he says, it will lead to an all-IPv6 network more quickly than dual-stack lite will. He argues that once IPv4 address allocations slow significantly, parts of the network will be able to serve hosts an IPv6 address only. Of course, all IPv4 content will not be served immediately on v6, so v6-only hosts will, for some time, still need to reach v4-only sites. Using something like NAT-PT transforms the content deployment problem into an application porting problem. However, NAT-PT is deprecated in RFC 4966. “All of the draw-backs of RFC 4966 are really drawbacks of NAT, and they are all present in v4 NAT too,” said Lorenzo. Like Shin, Lorenzo doesn’t like NATs-or the NAT mechanisms in NAT-PT. However, being an IPv6 champion, he feels that incremental transition mechanisms are key to hastened adoption. “If we want to reclaim the end-to-end principle, then we must do it with IPv6.” And in order to do that, Lorenzo called for a barebones standard that addresses a v6 host connecting to a v4 server. This would require a DNS application layer gateway. The focus should be on network-based translation scenarios, not on a host-based solution. “[End-to-end connectivity] can happen in v6 but not while we still have v4 around.” Lorenzo thinks NAT-PT’s presence will lower the value of IPv4 on hosts, and operators and users will opt for IPv6 hosts, with NAT-PT fronting the v4 applications. As soon as the content is v6, the NAT-PT function will be removed, and it’s pure v6 from there.
First Impressions Are Everything
Stuart Cheshire, Wizard without Portfolio at Apple
Apple chose IPv6 link local addressing for the AirPort Express wireless base station because of the auto configuration features that require the user to do nothing to get LAN-based printing, streaming music, and network administration running. The solution has been more reliable and works better than IPv4 in a single-network home. The Internet, as Stuart pointed out, is a different story. Five elements interact to make an IPv6 solution work for the customer across the Internet: the operating system, application software (such as a Web browser), home network, ISP, and content (such as Web sites).
Without any one piece, the solution fails. Content is the key. Without IPv6 content, ISPs have no incentive to carry IPv6. As Stuart said, if a customer cannot get IPv6 from the ISP, then there’s no reason for content accessible via IPv6. If the browser is not IPv6 enabled, then the customer will not be able to access IPv6 content and therefore will not purchase IPv6 connectivity. If the OS is not v6 ready, then apps can’t be either. Incentives must exist for all of the players. Apple’s incentive was the so-called coolness factor of IPv6, so now Apple’s OS, Apple’s browser, and most of Apple’s networking apps support it. “Now we must find compelling incentives for the other three pieces to support v6,” encouraged Stuart. “Or, at the very least, make sure there are no disincentives.”
To drive home the point, Stuart described an application-level issue that Apple faced with regard to its Safari Web browser and certain performance delays associated with dual-stack clients. When a dual-stack-capable Web browser connects to the Internet, it first conducts an AAAA record lookup, then it does an A (Address) record lookup and tries an IPv6 connection. If that fails, it tries an IPv4 connection. Everything works as long as this series of events occurs quickly, including any failures. Unfortunately, lack of AAAA responses and IPv6 connection failures are common.
Apple faced an issue regarding a big-name Web site. Customers complained that the site was really slow. Upon investigation, Apple discovered that the site’s DNS servers did not send valid responses to AAAA queries. Either such sites do not respond to an AAAA query, or they send back a mangled, malformed response. The connection sequence blocks are waiting for an answer that isn’t coming. The user perceives this as application slowness, which started occurring when the user’s computer first got an IPv6 address.
The root issue is the getaddrinfo() API, which blocks waiting for an IPv6 address query that may never be answered. Because the problems first appeared when the ISP started offering IPv6 service, the issue landed in the ISPs’ laps. This is bad for the industry because both the customer and the ISP get a bad impression about IPv6. These thorny disincentives must be removed if we are to hasten deployment.
Apple’s implementation now disassociates the IPv4 and IPv6 tracks. The tracks perform the AAAA and A queries in parallel, and they try the IPv4 and IPv6 http connections in parallel, taking the first response and resetting the second. Failures or hangs at either step, on either track, no longer hang the user experience.
The getaddrinfo() API was the problem because it exposes addresses to the application when it shouldn’t. Applications don’t need to know about Ethernet addresses, and they don’t need to map IP addresses to Ethernet addresses; the kernel ought to do that for them with ARP. Likewise, an app should not be involved in mapping DNS names to addresses. The app should just tell the system, “Here are a name and an application/service. Please connect me to it.” Apple uses a connect-by-name API so that applications don’t even have to know or care whether the underlying connection is IPv4 or IPv6. Both Java and Windows have similar APIs.
The moral, according to Stuart, is that as we move toward IPv6, when you build an app, avoid getaddrinfo() and such APIs. Instead, use concurrency and asynchrony. Yes, these new mechanisms will send extra packets and initially open more connections than will actually be used. The first one that succeeds will proceed, while the others will be reset. This is the right design decision for IPv6. “We are trading off a few extra packets and connections to vastly improve the user experience,” said Stuart. “And that’s the point: let’s make sure to remove the barriers to transition that might otherwise make people regret their first tentative steps into IPv6 deployment and use.”
IPv6 Panel Takes Questions from the Floor
What are the biggest operational issues percolating up from the network administration staff?
IPv6 addresses are difficult to type. I often ask people to write down an IPv6 address and read it back over the phone. Of all the attempts, only one person has succeeded in repeating the address correctly. So we must avoid IPv6 addresses as much as possible, and we must be more ardent DNS users.
It’s not technical, but the lack of education of the customer-facing support staff. We don’t want the front-line staff answering support calls by saying, “What is IPv6? I don’t know anything about it.” Getting IPv6 into all the training manuals and achieving a basic level of familiarity across all levels of staff are the hardest things NTT has faced.
Failure to follow familiar IPv4 design principles. There is muscle memory there, and so people just naturally try to do an operation the v4 way, but then something breaks, or it doesn’t work. They don’t know why, and they don’t know where to find the answer. Training everyone that something must be done differently in this situation is a challenge and takes time. Putting safeguards in place, like deployment templates, helps keep people from such mistakes.
Are you able to get the equipment you need? What are the equipment gaps?
The back-office applications are the most difficult.
The RIRs are putting our money where our mouths are by making our services available on IPv6. Some of the middle boxes such as load balancers are not really ready yet with their IPv6 support. Also, their technical support and best practices are not mature, so we do not get as much consultative assistance as we would expect.
Are you driving IPv6 to your customers, or are your customers driving you to IPv6?
We are pushing customers to use IPv6. We need IPv6 because we have a lack of resources from which to offer customers advanced services.
Many customers want to access their e-mail, browse the Web, and download a video from YouTube. I don’t think they care whether this gets accomplished over IPv4, IPv6, or avian carrier [RFC 1149]. What matters is that we can keep the services of the Internet growing regardless of whether we have IPv4 or are out of v4 and need IPv6.
The research is pretty conclusive that people see that IPv4 works now, and so they feel no need for IPv6. They see IPv6 as a capital cost for them. The question arises: Where does the money come from that will help us solve a problem that we don’t have right now?
It appears unanimous that we are driving IPv6, not the customers, because we need to produce new services that customers do want, and we do not have enough IPv4 addresses going forward to accomplish the task. We need IPv6 as an enabler. If customers are not begging us for IPv6, then the stakes are very high for us to make its presence very transparent to users-or risk its rejection. It has to be invisible and usable by the “grandmother living in the countryside,” as Shin says.
NATs in the middle can break things and create walled gardens. Is it possible to demand that DOCSIS put NATs at the ends?
DOCSIS is layer 2, not layer 3. We are not talking about centralized carrier NAT. The question is, Where is this divide in the network? I agree that this is bad and that it could provide a single point of failure and that NATs need to get close to the customer. I suggest talking to the application developers.
Is it possible to do some analysis to figure out how much it will cost an end user to have a public IPv4 address? Could this be an incentive for using IPv6?
NTT is currently that kind of research.
There is a new policy proposal that is related to IPv4 address transfers. One aspect of transfer is market-based transfer, which currently is not allowed by RIR policy. ARIN asked a lawyer to look into this, and the answer is that an open market would be best.
What is the state of readiness of IPv6 DHCP [Dynamic Host Configuration Protocol]?
The DHCP community has worked quite a bit with vendors recently, and the results are quite promising. (Editor’s note: See articles on IPv6 DHCP back-offs in recent editions of the IETF Journal).
Applications developers are waiting for the peer-to-peer readiness of IPv6. Do you see inbound connectivity to the home as compelling-enough motivation?
Stuart: I agree that inbound connectivity is the only compelling reason to use IPv6. Everything else is currently also available on IPv4. So, the only reason is that it gives me unhindered peer-to-peer connectivity.
- Introduction Email from the IAB
- IAB’s follow up email
- Audio stream archive
The IPv6 panel starts at time 01:13:00 on the stream.
Q&A (only 1/3 appears in the article) at 02:29:00
- Presentation archive:
- One hypothetical model of an address allocation timeline
- Related drafts: