In this post for the Internet Society Rough Guide to IETF 97, I’ll take a look at some recent IPv6 activity and what’s happening at IETF 97 in Seoul next week.
It’s been a good year for IPv6 with several sources indicating that global IPv6 adoption rates have increased by nearly 50% during 2016, with a number of large ISPs, mobile operators and content providers actively deploying the protocol. Whilst IPv6 has been supported by major operating systems for some time, native IPv6 is also increasingly being supported by applications and networks, thus reducing reliance on transition mechanisms and tunnelling. This in turn is improving the performance and reliability of IPv6, therefore increasing the chances of establishing an IPv6 connection in preference to one using IPv4.
IANA has recently been able to allocate an additional /18 from the recovered pool of IPv4 to each of the Regional Internet Registries, and has further allocations planned every six months until March 2019. However, if no more blocks are returned, then this will be the last allocation of IPv4 addresses. Furthermore, network operators have increasingly been running into limitations with the available size of private IPv4 space, especially for mobile markets and upon acquisition of other operators using overlapping addresses. The complexity this introduces is another reason why more operators are increasingly realising the need to deploy IPv6.
IPv6 therefore continues to be an important aspect of the standardisation work within the IETF, with both the IPv6 Operations (v6ops) and IPv6 Maintenance (6man) Working Groups meeting at IETF 97 in Seoul. We should highlight though, that the Sunsetting IPv4 Working Group will also be meeting on Thursday morning to discuss another new draft proposing that the IETF stops working on IPv4 except to address security issues or facilitate the transition to IPv6. A previous draft by the same author that proposed to move IPv4 to historic status and thereby no longer recommended for use on the Internet did not reach RFC status, although it generated some interesting discussion and thought as to whether the IETF should continue to work on IPv4 technologies.
The IPv6 Operations (v6ops) Working Group is fairly early in the week this time, meeting on Monday afternoon. There are four drafts up for discussion, including two new ones. The draft related to enterprise multihoming aims to define a solution to the problem of connecting an enterprise site to multiple ISPs using provider-assigned addresses without the use of Network Address Translation. The other new draft suggests reserving the IPv6 prefix 64::/16 for use with IPv4/IPv6 translation mechanisms.
An updated existing draft provides advice on routing-related design choices when designing IPv6 networks, and compares IPv4 and IPv6 best practices. Last but not least, there’s an update on the draft relating to unique IPv6 prefixes per host that aims to address certain issues related to IPv6 deployment in community wi-fi scenarios.
The IPv6 Maintenance (6man) Working Group meets on Tuesday morning to once again discuss a number of updates to the IPv6 specification as currently defined in RFC 2460, RFC 4291, and RFC 1981. Another draft outlines an optional mechanism for IPv6 Neighbour Discovery whereby hosts are instructed by routers to use router solicitations rather than multicast advertisements where it’s not desirable for all hosts to be continually woken-up (e.g. when in powered down mode).
Three other individually sponsored drafts define a new control bit in IPv6 RA PIO flags to indicate that the receiving node is the exclusive receiver of traffic destined to any address within a prefix; specify requirements for IPv6 nodes; and specify a packet format for transporting IPv6 payloads to multiple IPv6 destinations using Bit Index Explicit Replication, which is a method of multicasting.
The Homenet (homenet) Working Group develops protocols for residential networks based on IPv6, and will meet on Wednesday afternoon. Although normally one of the more active groups, it has a relatively quiet agenda this time after publishing RFCs 7787 and 7788 earlier in the year.
There’s a couple of new drafts though, one of which proposes an update to the Home Networking Control Protocol (HNCP) specification to eliminate the recommendation for a default top-level name for local name resolution ( https://tools.ietf.org/html/draft-ietf-homenet-redact-00). The other one defines .homenet as a special use top-level domain to replace .home as there is evidence that .home queries frequently leak out of their local environments and reach the root name servers ( https://tools.ietf.org/html/draft-pfister-homenet-dot-00). There’s also an updated draft being discussed ( https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01) on the Homenet Naming and Service Discovery Architecture that covers how services advertise and register themselves both on the homenet and public Internet
The IPv6 over Networks of Resource-Constrained Nodes (6lo) Working Group is meeting on Tuesday afternoon, and has a very full agenda with two new drafts and five updated drafts up for discussion. The two drafts of wider interest are probably those on 6lo Applicability and Use Cases which describe practical deployment scenarios, and on 6lo privacy threats.
The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) Working Group is meeting on Thursday morning, and will consider drafts related to scheduling and security issues. There are particularly interesting drafts on the minimal security framework for 6TiSCH which describes the mechanism required to support secure initial configuration in a device being added to a 6TiSCH network, as well on the Secure Join protocol that defines a standard way of introducing new nodes into a 6tisch network that does not involve any direct manipulation of the nodes themselves.
We don’t often cover the Distributed Mobility Management (dmm) Working Group which focuses on providing solutions for traffic management when mobile hosts or mobile networks change their point of attachment to the Internet. In particular, it has responsibility for maintaining the Mobile IPv6 protocol family, but DMM solutions are not required to support IPv4. This working group will be meeting first thing on Monday morning, and will be discussing five drafts including the mobility needs for 5G wireless ( https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-02), and extensions to the DHCPv6 protocol to enable mobile hosts to indicate the required mobility service type ( https://tools.ietf.org/html/draft-moses-dmm-dhcp-ondemand-mobility-04).
Finally, there are a couple of IPv6-related drafts in the Dynamic Host Configuration (dhc) Working Group on Friday morning. There is a proposed update to DHCPv6 as currently defined in RFC 3315 which adds prefix delegation and stateless DHCPv6. Meanwhile there’s another updated draft on DHCPv4 over DHCPv6 that provides mechanism for dynamically configuring IPv4 over an IPv6-only network.
At the Internet Society, we continue to promote IPv6 deployment. You can check out the World IPv6 Launch measurements for our latest measurements of IPv6 around the globe: http://www.worldipv6launch.org/measurements
You can also check out the Deploy360 online resources for getting started with IPv6 deployment:
And you can read more about other topics of interest to the technology programs of the Internet Society in the rest of our Rough Guide to IETF 97 posts.
IPv6-related Working Groups at IETF 97:
v6ops (IPv6 Operations) WG
Monday, 14 November 1330-1530 UTC+9, Grand Ballroom 2
6man (IPv6 Maintenance ) WG
Tuesday, 15 November 0930-1200 UTC+9, Grand Ballroom 2
Homenet (Home Networking) WG
Wednesday, 16 November 1330-1500 UTC+9, Grand Ballroom 1
6lo (IPv6 over Networks of Resource Constrained Nodes) WG
Tuesday, 15 November 1550-1820 UTC+9, Grand Ballroom 2
6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e)
Thursday, 17 November 0930-1100 UTC+9, Park Ballroom 1
dmm (Distributed Mobility Manager) WG
Monday, 14 November 0930-1200 UTC+9, Studio 4
dhc (Dynamic Host Configuration) WG
Friday, 18 November 1150-1320 UTC+9, Park Ballroom 2
sunset4 (Sunsetting IPv4)
Thursday, 17 November 1110-1210 UTC+9, Studio 2
There’s a lot going on in Seoul, and whether you plan to be there or join remotely, there’s much to monitor. 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 https://dev.internetsociety.org/tag/ietf97/.