Rough Guide to IETF 101: IPv6 Thumbnail
IPv6 14 March 2018

Rough Guide to IETF 101: IPv6

By Kevin MeynellFormer Senior Manager, Technical and Operational Engagement

In this post for the Internet Society Rough Guide to IETF 101, I’m reviewing what’ll be happening at the IETF in London next week.

IPv6 global adoption rates continue to rise (to approximately 22% according to Google), although at a slightly slower overall rate since the last IETF. Nevertheless, there’s still substantial growth in IPv6 capability in large markets such as the United States, India and Germany, with Belgium still leading the world. There has also been significant progress in Greece, Brazil, Malaysia, Finland, Switzerland and Uruguay recently, whilst Japan, the UK and France continue to show consistent growth. The amounts of native IPv6 traffic seen on the Internet still does not entirely reflect global IPv6 capabilities, but with most major content and cloud providers now supporting IPv6, and mobile networks increasingly preferring IPv6, this gap will continue to close.

IPv6 is an important focus for the IETF, particularly with respect to the standardisation work related to the Internet-of-Things. And it’s straight into the IPv6 work on Monday, with both the IPv6 Operations (v6ops) and IPv6 Maintenance (6man) Working Groups being held that day, along with three other IoT-related Working Groups.

The IPv6 Operations (v6ops) Working Group is one of the key groups, but has a relatively light agenda this time as since the last meeting it’s published two RFCs. RFC 8273 ( outlines the assignment of unique IPv6 prefixes to hosts instead of from a shared IPv6, which allows unique service provider addresses to be used to improve host isolation and enhance subscriber management on shared networks. RFC 8305 ( provides an update to the Happy Eyeballs algorithm to reduce delays to users whilst preferring IPv6 on dual-stack networks.

The meeting kicks off first thing Monday morning with a discussion on implementing IPv6-preferred data centres. There’s then a couple of new drafts that include Requirements for IPv6 Routers ( that defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; plus Using Conditional Router Advertisements for Enterprise Multihoming ( that proposes a solution to the problem of enterprise multihoming without address translation by using Router Advertisements to influence the host source address.

There’s also five other existing drafts for which comment is still being requested. NAT64 Deployment Guidelines in Operator and Enterprise Networks ( describes how NAT64 can be deployed in an IPv6 operator or enterprise network when there is only an IPv6 access link; IPv6 Point-to-Point Links ( describes different alternatives for configuring IPv6 point-to-point links, considering the prefix size, numbering choices and prefix pool to be used; whilst Transition Requirements for IPv6 Customer Edge Routers to support IPv4 ( extends RFC 7084 in order to allow the provisioning of IPv6 transition services for the support of IPv4 as a Service (IPv4aaS) by means of new mechanisms that were not available when RFC 7084 was published. IPv6 Performance Measurement with Alternate Marking Method ( describes a passive performance measurement method in an IPv6 domain, with IP Fragmentation Considered Fragile ( discusses how IP fragmentation reduces the reliability of Internet communication and provides recommendations for application developers and network operators.

The IP Wireless Access in Vehicular Environments (ipwave) Working Group is running in parallel with v6ops. It is currently focused on a couple of working group-sponsored drafts including a specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicle-to-Internet and Vehicle-to-Infrastructure communications (; and defining the use cases for IP-based vehicular networks ( The group will also be discussing re-chartering, with a problem statement and associated security and privacy considerations due to the IESG in May 2018.

The IPv6 Maintenance (6man) Working Group is another key group, and since the last meeting has published RFC 8319 ( that updates the IPv6 Neighbor Discovery Protocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime. The meeting is being held on Monday afternoon and has a busy agenda with 2 working group-sponsored drafts, 2 existing drafts, and 3 new drafts, as well as an update on multi-vendor interoperability testing results.

IPv6 Node Requirements ( specifies the minimum requirements for enabling effective IPv6 functionality and interoperability on nodes; whilst IPv6 Segment Routing Header ( specifies how a node can steer a packet through a controlled set of instructions (segments) by prepending an SR header to the packet. ICMPv6 errors for discarding packets due to processing limits ( defines how nodes can signal the discard of packets if they are unable to process the protocol headers; and IPv6 Router Advertisement IPv4 Unavailable Flag ( specifies a flag to indicate to hosts there’s no IPv4 service on the advertising default IPv6 router, updating RFC 5175 (

The new drafts up for discussion include Privacy Extensions for Stateless Address Autoconfiguration in IPv6 ( that describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; Recommendation on Temporary IPv6 Interface Identifiers ( specifies a set of requirements for generating temporary addresses and clarifies the stability requirements for IPv6 addresses; with Unified Identifier in IPv6 Segment Routing Networks ( extending the use of IPv6 Segment Routing Headers to segment identifiers encoded as MPLS labels and IPv4 addresses.

If you fancy staying later, the Dynamic Host Configuration (dhc) Working Group is meeting on Monday evening and has three IPv6-related drafts on the agenda. DHCPv4 over DHCPv6 Source Address Option ( defines a DHCPv6 option to convey parameters for communicating a source tunnel IPv6 address between an DHCP 4o6 client and server, in conjunction with the IPv4 address allocation process. YANG Data Model for DHCPv6 Configuration ( aims to support the configuration and management of DHCPv6 servers, relays, and clients; whereas Link Layer Addresses Assignment Mechanism for DHCPv6 ( proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments.

There doesn’t seem to be lot happening IPv6-wise on Tuesday, but if you’re feeling IPv6 withdrawal symptoms, then the Measurement and Analysis for Protocols Research Group (maprg) on Tuesday morning has three IPv6-specific agenda items. These are a discussion on measuring IPv6 performance, visualising IPv6 space, and an update on IPv6 client adoption.

The Low Power Wide-Area Networks (lpwan) Working Group meets on Wednesday morning. This is working on enabling IPv6 connectivity with very low wireless transmission rates between battery-powered devices spread across multiple kilometres, and whilst the agenda has yet to be published, there are three current working group-sponsored drafts. The overview of the set of LPWAN technologies under consideration by the IETF has now been sent to the IESG for publication (, whilst the other relevant draft deals with LPWAN header compression and fragmentation for IPv6 (

The IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Working Group then meets on Wednesday afternoon. TSCH is the emerging standard for automation and control over low-power and lossy wireless networks, and this group is working on how to utilise IPv6 in industrial standards. There’s a very full agenda, with the 6top protocol that enables distributed scheduling ( now being targeted for an IESG Last Call, and the security functionality ( and being prepared for Working Group Last Calls.

Thursday is another quiet day with just the IPv6 over Networks of Resource Constrained Nodes (6lo) Working Group meeting on Thursday afternoon. It nonetheless has a fairly busy agenda with Registration Extensions for 6LoWPAN Neighbor Discovery ( and Address Protected Neighbor Discovery for Low-power and Lossy Networks ( having received feedback from the IESG. The drafts related to IPv6 Backbone Router ( that proposes proxy operations for IPv6 Neighbor Discovery on behalf of devices located on broadcast-inefficient wireless networks; and Packet Delivery Deadline time in 6LoWPAN Routing Header ( are being prepared for Working Group Last Calls. There will also be updates on the 6LO applicability and use cases (, and from the fragmentation design team ( and Finally, there’s a proposed update to RFCs 6550 and 6775 where 6LoWPAN ND nodes in a RPL domain do not participate in the routing protocol.

The week concludes with the Homenet Working Group (homenet) on Friday morning. This develops protocols for residential networks based on IPv6 and currently has Special Use Domain ‘’ awaiting publication as an RFC, with the Homenet profile of the Babel routing protocol ( currently in IETF Last Call. The Simple Homenet Naming and Service Discovery Architecture ( describes how names are published and resolved homenets, and how hosts are configured to use these names to discover services on homenets. The remainder of the agenda will be a discussion about Homenet security in relation to the home perimeter, HNCP and Babel, as well as appropriate trust models and how to establish trust.

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.

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 101 posts.

IPv6-related Working Groups at IETF 101:

V6OPS (IPv6 Operations) Working Group
Monday, 18 March 2018 09.30-12.00 UTC, Viscount

IPWAVE (IP Wireless Access in Vehicular Environments)
Monday, 18 March 2018 09.30-12.00 UTC, Sandingham

6MAN (IPv6 Maintenance) WG
Monday, 18 March 2018 13.30-15.30 UTC, Viscount

DHC (Dynamic Host Configuation) WG
Monday, 18 March 2018 17.30-18.40 UTC, Viscount

LPWAN (IPv6 over Low Power Wide-Area Networks)
Wednesday, 20 March 2018 09.30-12.00 UTC, Viscount

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e)
Wednesday, 20 March 2018 13.30-15.00 UTC, Viscount

6LO (IPv6 over Networks of Resource Constrained Nodes) WG
Thursday, 21 March 2018 13.30-15.30 UTC, Buckingham

Homenet (Home Networking) WG
Friday, 22 March 2018 09.30-11.00 UTC, Sandringham<

Follow Us

It will be a busy week in London, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 101 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF101 to keep up with the latest news.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Measuring the Internet 10 August 2020

Measuring the Internet – Mid Year Project Update

Here at the Internet Society, we believe that the Internet is for everyone. Our work centers on increasing the...

Open Standards Everywhere 11 June 2020

Listen to the Hedge Podcast 39 to Learn about the Open Standards Everywhere Project

What is our Open Standards Everywhere (OSE) project all about? How did it get started? What are the project...

Open Standards Everywhere 6 June 2020

On This 8th World IPv6 Launchiversary, Help Us Get More Websites Available Over IPv6

Eight years ago, on June 6, 2012, thousands of companies and organizations came together as part of World IPv6...