Rough Guide to IETF 89: All About IPv6

The Internet relies on a single addressing framework to have global reach and integrity. IPv4 address space is insufficient, and the IETF developed IPv6 as its successor many years ago. IPv6 remains an important topic for us at the Internet Society. We were thrilled to see that Google’s IPv6 traffic recently passed the 3% mark and that the deployment rate seems to be accelerating, but there’s still a lot of work to be done. To that end, there are several interesting IPv6-related topics being discussed at IETF 89 in London next week.

While the standard for IPv6 has long-since been finished, there are ongoing discussions in the IETF of maintenance issues in the protocols, IPv6 operational issues and management, and possible uses in home networks and very large-scale networks (of small scale devices). Many of these discussions will happen next week in London.

I call attention first to the discussion in the 6man Working Group of efficient neighbor discovery and of issues around the interface identifier part of the IPv6 address. There has been some ongoing work identifying issues with embedding hardware addresses in the interface id part of the v6 address. The Internet-Draft ietf-6man-address-generation-privacy identifies the ability to use those for correlating network activity, tracking location, address scanning, and identifying specific device types to exploit known vulnerabilities. This draft will be discussed and another Internet-Draft (ietf-6man-default-iids) will be discussed with an alternate proposal for stable interface addresses.

Efficient neighbor discovery is very important, particularly in mobile environments with power sensitive hosts. A number of drafts have been presented describing the problem. These will be discussed and the WG will determine what (if anything) should be done to improve the situation.

The v6ops Working Group discusses operational issues with IPv6 deployment. This time there will be some discussion of the problematic interaction between address configuration using DHCPv6 and SLAAC. The problem mainly occurs because of a lack of specificity in the standards about the normativeness of a set of flags used in neighbor discovery. The WG has a problem statement Internet-Draft (ietf-v6ops-dhcpv6-slaac-problem) that will be discussed and at least one draft that the WG has not yet adopted that intends to provide guidance to minimize the operational impact of this issue.

The main standards-making activity of IPv6 may be done, but the level of energy and effort in the IETF around IPv6 operation continues to grow, reflecting the reality of its increasing use on the global Internet and the importance of IPv6 to the Internet’s continued growth and evolution.

Related Working Groups at IETF 89:

To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see