Categories
IPv6 Measuring the Internet

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 Internet’s reach, reliability and resilience, as well as ensuring that the network of networks remains open, globally connected, secure, and trustworthy.

But how do we assess whether our efforts – and the efforts of the global ecosystem of organizations that facilitate the smooth functioning of the Internet – are working? How can we see where protocols, such as IPv6, are being deployed and at what rate so we can better understand where more education on the benefits of such technologies might be helpful? Where can policy makers find a comprehensive set of data from various sources to help show decision makers that Internet Showdowns damage local economies and potentially harm citizens?

A Single Platform

There are many people, projects and organizations that are collecting data on various facets of the Internet, but there’s no single site that provides a curated set of insights. So, to help everyone gain deeper, data-driven insight into the Internet, the Internet Society is building a tool that consolidates trusted third-party Internet measurement data from various sources into a single platform – insights.internetsociety.org

We’ll use the data presented on the Insights platform to examine Internet trends, generate reports, and tell data-driven stories so that policymakers, researchers, journalists, network operators, civil society groups and others can better understand the health, availability and evolution of the Internet. 

Data Partners

It’s important to note that the Internet Society is not collecting data or performing measurements itself. Instead, we’re collating and curating publicly available data and making it available in one place so that users do not have to go to many individual sites to get the multiple sources of information they need. Our data sources include Internet Society Organization Members Facebook, Google and Oracle, among others. 

We’ve also put in place agreements and partnerships with several other organizations in the Internet measurement community and are continuing these outreach efforts to secure access to more data. These key strategic relationships will enable us to present and use Internet measurement data that is currently not publicly available and data that might have limited public availability. And, as the Insights platform develops, these relationships will also facilitate collaboration with industry leaders on other aspects of data collection and Internet measurements.

Strategic Relationships 

One such relationship is with Internet Society Organization Member, AFRINIC, the Regional Internet Registry (RIR) for Africa. Signed on 23 July 2020, the agreement builds upon a strategic, long-term partnership agreement held between both organizations aimed at strengthening collaboration throughout Africa. The primary goal of this partnership is to drive the development of the Internet in the region through projects and research related to Internet measurements, Internet resilience, routing security, open Internet standards, and Internet Exchange Points (IXPs). 

An agreement has also been signed with the Center for Applied Internet Data Analysis (CAIDA). CAIDA’s long-standing work on monitoring the Internet in near-real time to identify macroscopic Internet outages will further strengthen the Insights platform’s focus on Internet Shutdowns and Internet Resilience. 

Making Progress  

We’ve been working on the Insights platform as part of our Measuring the Internet project since the beginning of 2020 and are making good progress. Development work is already under way and we plan to launch by the end of the 2020. As we want to make Insights available as soon as possible, we’ll initially launch with two focus areas, Internet Shutdowns and Enabling Technologies. Meanwhile, work will continue on finalizing metrics and data sources for our other two focus areas, Internet Resilience and the Internet Way of Networking (IWN), as well as on outreach and partnership development.

Stay Informed

Categories
Domain Name System Security Extensions (DNSSEC) IPv6 Open Standards Everywhere Transport Layer Security (TLS)

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 goals? What are some of the challenges web server operators face? How can we work together to make web servers more secure and available?

Recently Russ White and his team interviewed me on The Hedge Podcast Episode 39 to discuss all these questions and much more. I’ve known Russ for a good number of years and it was fun to talk with him and his co-hosts Eyvonne Sharp and Tom Ammon about all things related to the OSE project. I hope you enjoy listening to the episode as much as we enjoyed having the conversation!

Listen now

I would encourage you to listen to some of the other Hedge podcast episodes, too, as they have some great content. A few I personally enjoyed included: episode 37 about DNS privacy; episode 31 about network operator groups (NOGs); and episode 30 with Ethan Banks from the Packet Pushers Network about why understanding the fundamentals of networking is so important.

Thank you to Russ, Eyvonne, and Tom for having me on the show!

Want to be more involved with the Open Standards Everywhere project?

Thank you for your help in getting open standards deployed everywhere!

Categories
IPv6 Open Standards Everywhere

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 Launch to permanently enable IPv6 for their websites and networks.

Today, we can see the success! If you visit the World IPv6 Launch measurements site, you can see some amazing numbers:

  • Reliance Jio’s network in India has over 90% IPv6 deployment!
  • Comcast’s huge network in the US is at 73% IPv6.
  • The combined US wireless carriers are over 85% IPv6.
  • Deutsche Telekom is over 68% IPv6.
  • Claro in Brazil is at 62% IPv6.

Another major source of info, Google’s IPv6 statistics, show that over 30% of all traffic to Googles sites globally is now over IPv6. If you look at Google’s per-country IPv6 adoption, some countries are seeing up around 50% of all traffic to Google’s properties going over IPv6.

This is all fantastic to see. But of course, we want more IPv6 deployment!

Specifically, we want more web sites and services available over IPv6. Increasing numbers of IPv6-only mobile networks are being deployed around the world. To ensure that people can reach websites that are still only available over IPv4, many IPv6-only networks use IPv6-to-IPv4 gateways. But we want everyone to be able to reach every website as fast as possible, without having to go through gateways, which can slow down access. So, we need more sites to have native IPv6 connections.

To do this, we need your help!

Is your site IPv6-ready? First, you can test your own web site(s) with the Internet.nl test site.

If Internet.nl says your site already supports IPv6, then congratulations! You are all set to have people connect over IPv6 to your site.

If your site does not support IPv6 yet, as part of our Open Standards Everywhere project in 2020, we are providing documentation to help people operating web servers make their sites available over IPv6.

We would like your feedback on the documents we have so far.

If you operate your own web server running on an actual server or a virtual machine, we have instructions for Apache or NGINX web servers.

If you are using a content delivery network (CDN) in front of your web server, the reality is that many CDNs already support IPv6 by default. We have a list of CDNs we know support IPv6. If your CDN is not on the list, please let us know! And if your CDN does not support IPv6, please let them know that these other CDNs do – and perhaps that you might consider switching. 😉

If you host your web site with a web hosting provider, we are looking to build a list of web hosting providers who do and do not support IPv6 for websites. We have an open issue on GitHub where we are seeking input.

In all of these cases, we would appreciate your feedback. If you use GitHub, you can open a new issue (or reply to a current one). Alternatively, you can send me email or contact me on Twitter.)

With your help, we can create even stronger documentation that can help even more people make their sites available over IPv6!

Want to be more involved with the Open Standards Everywhere project?

Categories
IPv6

On the 7th World IPv6 Launchiversary, How About Listening to a Podcast About IPv6?

On this 7th “launchiversary” of World IPv6 Launch, I thought I’d share a way I’ve enjoyed learning more about IPv6 over the past year. I like listening to podcasts while I’m running or driving, and a show that’s in my playlist is “IPv6 Buzz” where IPv6 veterans Ed Horley, Scott Hogg, and Tom Coffeen “dive into the 128-bit address space wormhole.

IPv6 buzz podcast logo

Anyone working with IPv6 for any amount of time, and particularly IPv6 advocacy, has probably read or heard something from Ed, Scott, or Tom. They’ve been explaining and promoting IPv6 for a long time in their own individual endeavors.

This podcast, which launched one year ago today, brings the three of them together with a wide range of guests from across the industry. Even with all my own years of IPv6 activity, I’ve learned a great amount about IPv6 security, recent drivers of deployment (including state task forces), tools and suggestions for promoting IPv6 growth. They dove deeply into IPv6 inside the IETF with Fred Baker, talked about going IPv6-only with Veronika McKillop of Microsoft, got into Happy Eyeballs with Dan Wing, and most recently explored enterprise IPv6 issues with Enno Rey.

Part of the excellent “Packet Pushers” network of podcasts, I’ve found it a great way to stay up on what is happening in the world of IPv6. If you listen to podcasts and are interested in IPv6, do check it out!

P.S. And if you have not yet started deploying IPv6, you can begin by exploring some of our Deploy360 resources.


Image Credit: Boris Smokrovic on Unsplash

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Frequently Asked Questions (FAQ)

The Internet Society recognises that global deployment of the IPv6 protocol is paramount to accommodating the growth of the Internet. Given the scale at which IPv6 must be deployed, it is also important that the possible security implications of IPv6 are well understood and considered during the design and deployment of IPv6 networks, rather than as an afterthought.

We are therefore publishing our IPv6 Security Frequently Asked Questions (FAQ), which highlights and provides answers to the most important aspects of IPv6 security.

Be sure also to check our IPv6 Security page as well!

Further Information

Categories
Deploy360 IETF IPv6

How IPv6 SLAAC Responds to Renumbering Events

If you follow the IPv6 Maintenance (6man) Working Group of the Internet Engineering Task Force (IETF), you may have noticed the 300+ message email thread on an Internet Draft that was recently published on the “Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events”. This was prompted by the experiences of developing Best Current Operational Practice on IPv6 prefix assignment for end-users, an activity led by ISOC’s Jan Žorž and published as ripe-690.

SLAAC is used to automatically assign an IPv6 address to a host, but there are a number of scenario where hosts may end up using stale configuration information and thereby leading to interoperability problems.

For example, a typical IPv6 deployment scenario is when a CPE (Customer Premises Equipment) router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of the leased prefix on the LAN-side via SLAAC.

In such scenarios, if the CPE router crashes and reboots, it may lose all information about the previously leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems.

ripe-690 had tried to address this problem by recommending that operators lease stable IPv6 prefixes to CPE routers, but for various reasons, ISP may not be able or willing to do this, and may instead lease dynamic prefixes. In fact, a recent survey of ISPs indicates that 37% of the surveyed ISPs lease dynamic IPv6 prefixes to their customers, as opposed to the stable prefixes recommended by ripe-690.

Most of the input on the 6man mailing list fell into one of the following camps:

  • “ISPs should be leasing stable prefixes — if they don’t, they are asking for trouble!”
  • “CPE routers should record leased prefixes on stable storage, such that they can deprecate such prefixes upon restart — if they don’t, they are asking for trouble!”
  • “No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments”

This Internet Draft therefore tries to improve the current state of affairs through the following improvements:

  • Allow hosts to gracefully recover from stale network configuration information — i.e. detect and discard stale network configuration information.
  • Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner; unless it is actively refreshed by Router Advertisement messages.
  • Specify the interaction between DHCPv6-PD and SLAAC — which was rather under-specified.
  • Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart.

Based on the mailing list discussions, there would seem to be consensus this is a problem that needs to be addressed by the 6man Working Group.

The topic is therefore likely to be on the working group agenda at the IETF 104 Meeting at the end of this month in Prague, Czech Republic. So if you’re a network operator, vendor or otherwise have operational experience of this issue, you’re strongly encouraged to contribute to the discussion.

Further Information

Categories
Deploy360 DNS Privacy Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IPv6

DNS Privacy & IPv6 Security @ APTLD 75

The Internet Society will be actively contributing to the APTLD 75 meeting on 20-21 February 2019 in Dubai, United Arab Emirates.

Our colleague Jan Žorž will not only be presenting on DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) during the DNS Operations, Security, and Privacy session (20 February, 11.30-12.30 UTC+4), but will then be presenting on IPv6 connectivity issues during the Security in IPv6-enabled TLDs session (20 February, 14.30-15.30 UTC+4).

He’ll be in good company in what’s shaping up to be a great programme featuring a number of DNS luminaries covering technical, policy, internationalisation and data protection issues, as well as abuse handling and registry and registrar training. Other sessions of particular interest include 5G mobile networks, the implications of Alternative DNS Root Servers, and emerging trends in the DNS.

The Asia-Pacific Top-Level Domain (APTLD) Association is a non-profit organisation of ccTLD (Country Code Top-Level Domains) registries in the Asia-Pacific region that was founded in 1998. It organises two meetings each year for its members, with APTLD 75 being held in conjunction with the 6th Middle East DNS Forum.

If you’re interested in attending then you can register at http://www.aptld75.ae/reg/end.php

Further Information

Categories
Deploy360 Improving Technical Security IPv6

NAT64Check Version 2 is launched!

With the New Year comes the launch of NAT64Check version 2 from the Internet Society. The first version of NAT64Check was introduced a couple of years ago and has proved very popular and successful, so for the past year we’ve been working on a number of enhancements in response to feedback and requests. And we’re very happy to be able to make the new version available as we welcome in 2019.

NAT64Check is a tool developed by the Internet Society in collaboration with Stichting IPv6 NederlandGo6, SJM Steffann, Internetbureau Max and Simply Understand. This allows you to enter the URL of a particular website, and then run tests over IPv4, IPv6 and NAT64 in order to check whether the website is actually reachable in each case, whether identical web pages are returned, and whether all the resources such as images, stylesheets and scripts load correctly. It also compares responsiveness using the different protocols, therefore  allowing network and system administrators to easily identify anything is ‘broken’, to pinpoint where any non-IPv6 compatible elements need to be fixed.

The original version of NAT64Check though, ran on two separate servers at Go6 and the IPv6 Lab which each had a limited view of the Internet from a topological perspective, and did not allow results to be easily aggregated. This was because it was put together quickly as a proof-of-concept using scripting tools, but its popularity encouraged us to develop something that was more scalable and adaptable for the future.

Version 2 therefore introduces a distributed concept that allows for different test locations, and indeed allows people to easily install their own test instances. However, results can be aggregated from any or all of these test locations and queried via a central web interface. Other improvements include better error detection and feedback when problems are experienced with particular sites, and as well as extendability for additional tests.

The new modular based design is based around three core elements. Marvin is a module based on Chromium that can run as separate instances on servers in different geographical locations for testing services over IPv4, IPv6 and NAT64. Trillian is a module that can collect, compare and output these test results based on different user profiles, whilst the Zaphod module undertakes the aggregation and provides the centralised web interface. Students of “The Hitchhiker’s Guide to the Galaxy” will of course recognise from where the codenames were derived!

The tool is very easy to use – simply go to https://www.nat64check.org, type the URL you wish to check into the box at the top of the page, and the result should be returned within a few seconds. It’s simple and easy, and will help you identify what needs to be done to make your website accessible with IPv6.

We’re also calling out for volunteers to help improve the usefulness of this tool by installing their own test instances. This requires a KVM, a VM running Ubuntu 18.04, a login, sudoers file, separate IPv4 and IPv6 addresses and a static /64 routed to the VM.

Deploy360 also wants to help you deploy IPv6, so please take a look at our Start Here page to learn more.

Acknowledgements

NAT64Check was developed by our colleague Jan Žorž, Sander Steffann, Corinne Pritchard, Max Dammers, and Musa Stephen Honlue.

Categories
Building Trust Deploy360 Events IETF Internet of Things (IoT) IPv6 Transport Layer Security (TLS)

IETF 103, Day 4: Trusted Systems, IoT & IPv6

This week is IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Thursday actually represents the last day of the meeting this time, although there’s still several sessions to draw attention to.

SUIT is meeting first thing at 09.00 UTC+9. This is considering how the firmware of IoT devices can securely updated, and the architecture and information models for this will be discussed. There are three other drafts relating to manifest formats that are the meta-data describing the firmware images.


NOTE: If you are unable to attend IETF 103 in person, there are multiple ways to participate remotely.


DMM is the first of the afternoon sessions at 13.50 UTC+7, and there are several IPv6-related drafts under consideration. Proxy Mobile IPv6 extensions for Distributed Mobility Management proposes a solution whereby mobility sessions are anchored at the last IP hop router, whilst Segment Routing IPv6 for Mobile User Plane defines segment routing behaviour and applicability to the mobile user plane behaviour and defines the functions for that. There’s also three updated drafts on 5G implementations which may interest some.

To round off the week, there’s a choice of two sessions starting at 16.10 UTC+7.

ACME will be focusing on the ACME TLS ALPN extension that allows for domain control validation using TLS, and Support for Short-Term, Automatically-Renewed (STAR) Certificates. It will also consider how ACME can support TLS certificates for end-users.

Alternatively, 6TiSCH will be focusing on the specification for a combining a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH). The 6top protocol that enables distributed scheduling is now heading for publication as an RFC, and there are also updates to the description of a scheduling function that defines the behavior of a node when joining a network and to define a security framework for joining a 6TiSCH network. If there’s time, a method to protect network nodes against a selective jamming attack will be discussed.

With that, IETF 103 comes to a close and we say Sà-wàd-dee to Bangkok. Many thanks for reading along this week… please do read our other IETF 103-related posts … and we’ll see you at IETF 104 which is being on 23-29 March 2019 in Prague, Czech Republic.

Relevant Working Groups

Categories
Events IETF Internet of Things (IoT) IPv6 Securing Border Gateway Protocol (BGP)

IETF 103, Day 2: IPv6, NTP, Routing Security & IoT

This week is IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And following on from the previous day, Tuesday also features a packed agenda.

LPWAN will be discussing whether to move to a Working Group Last Call on the Static Context Header Compression (SCHC) framework for IPv6 and UDP, that provides both header compression and fragmentation functionalities. Three other drafts describe similar schemes for SigFox,LoRaWAN and IEEE 802.15.4 type networks.


NOTE: If you are unable to attend IETF 103 in person, there are multiple ways to participate remotely.


Then at 11.20 UTC+7, IPWAVE will be focusing on updates to the specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicular communications, and the use cases for IP-based vehicular networks. There have also been a couple of updates to DNS Name Autoconfiguration for Internet of Things Devices and IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks, so these may also be discussed.

6MAN will be meeting at 13.50 UTC+7 and has nine drafts up for discussion. The couple of working group sponsored drafts relate to specifying a IPv6 Segment Routing Header (SRH) and how this can be used by Segment Routing capable nodes, and specifying a Router Advertisement flag to indicate to hosts that a link is IPv6-only. There are also a couple of new drafts that specify how IOAM (In-situ Operations, Administration and Maintenance) records are encapsulated in IPv6, and defining the building blocks that can be used for OAM in Segment Routing with IPv6.

The other drafts being discussed cover communicating NAT64 prefixes to clients with Router Advertisements, Updates to Requirements for IPv6 Options, Path MTU Discovery solutions, a new Path MTU Hop-by-Hop Option to record minimum Path MTU from source to destination, and IPv6 Packet Truncation procedures.

Running in parallel is SIDROPS that is discussing five drafts. RPKI Validation State Unverified proposes to introduced a new ‘Unverified’ validation state for route prefixes, whilst BGPsec Validation State Unverified proposes a similar validation states for BGPsec routes. Two other drafts introduce and define a digitally signed object into an RPKI  that provides a means of verifying that a Customer Autonomous System holder has authorised a Provider Autonomous System to be its upstream provider. That leaves a draft considering policy for dropping invalid routes – including hijacked and missing or erroneously created ROAs for route prefixes.

To conclude the day, there’s a choice of two sessions at 16.10 UTC+7.

NTP is a working group we’ve decided to cover as (amongst other things), it’s working to improve the security of the Network Time Protocol. There’s no less than 20 drafts on the agenda, although Network Time Security for the NTP specifies a mechanism for using TLS and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of NTP. Following on from this will be a review of the NTS implementations and interoperability testing.

T2TRG researches the issues of turning the IoT into reality, and will continue to discuss the State-of-the-Art and Challenges for the Internet of Things Security, the guidance for designing IoT systems using the REST architectural style, and a new data and interaction model called CoRAL (The Constrained RESTful Application Language).

For more background, please read the Rough Guide to IETF 103 from Olaf, DanSteve, and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Events IETF Internet of Things (IoT) IPv6 Transport Layer Security (TLS)

IETF 103, Day 1: IPv6, TLS, DNS Privacy & Other Crypto

The Working Group sessions start tomorrow at IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Only four days have been scheduled for the working groups this time around, which means there’s a lot of pack into each day; with Monday being no exception.

V6OPS is a key group and will be meeting on Monday morning starting at 09.00 UTC+7. It’s published four RFCs since its last meeting, including Happy Eyeballs v2, and this time will kick-off with a presentation on the CERNET2 network which is an IPv6-only research and education in China.

There’s also four drafts to be discussed, including three new ones. IPv6-Ready DNS/DNSSSEC Infrastructure recommends how DNS64 should be deployed as it modifies DNS records which in some circumstances can break DNSSEC. IPv6 Address Assignment to End-Sites obsoletes RFC 6177 with best current operational practice from RIPE-690 that makes recommendations on IPv6 prefix assignments, and reiterates that assignment policy and guidelines belong to the RIR community. Pros and Cons of IPv6 Transition Technologies for IPv4aaS discusses different use case scenarios for the five most prominent IPv4-as-a-service (IPv4aaS) transitional technologies, whilst NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks is an updated draft that describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network.


NOTE: If you are unable to attend IETF 103 in person, there are multiple ways to participate remotely.


Running in parallel on Monday morning is ROLL which focuses on IPv6 routing issues for low-power and lossy networks. This will be discussing an update ton the ROLL-BIER design that extends RPL to support routing based on Bit Index Explicit Replication (BIER) in environments with limited and lossy updates. There are also seven other drafts up for discussion, all related to RPL enhancements.

CFRG will be held during the late morning at 11.20 UTC+7. The group has yet to publish the agenda, but there’s a number of currently active drafts covering issues that include Public Key ExchangeThe Transition from Classical to Post-Quantum Cryptography, Randomness Improvements for Security ProtocolsRe-keying Mechanisms for Symmetric Keys, and Hash-Based Signatures.

There’s a choice of two sessions after lunch, starting at 13.50 UTC+7.

TLS holds the first of its two sessions (the second is on Wednesday afternoon) and has a number of important drafts up for discussion including the proposed DTLS 1.3 specification, and Connection Identifiers for DTLS, to avoid the need for additional handshaking upon NAT rebinding. There is also a proposal to deprecate TLS 1.0 and 1.1 as these versions lack support for current and recommended cipher suites.

Other drafts cover TLS Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates, a TLS 1.3 extension that allows a server to authenticate with a certificate while also providing a pre-shared key (PSK) as an input, and definition of universal PSKs for TLS that use an extra key derivation step to reuse the same secret for all TLS 1.3 KDF hashes. In addition, a revised working group charter has been proposed.

DNSOP meets at the same time, and there’s a couple of interesting drafts worth mentioning. One outlines how run a root server instance on the same server as a recursive resolver in order to decrease access time, and another specifies a way of resolvers telling clients what its associated DNS-over-HTTPS (DoH) servers are.

6LO concludes the day at 16.10 UTC+7. This will be discussing drafts to update RFC 6775 to support registration extensions for simplifying these operations in 6LoWPAN routers, to update Address Protected Neighbor Discovery for Low-power and Lossy Networks, to update RFC 4944 with a simple protocol to recover packet fragments over a mesh network, as well preparing the IPv6 Backbone Router draft for a Working Group Last Call. The session will be rounded-off with a performance report on fragment forwarding and recovery.

For more background, please read the Rough Guide to IETF 103 from Olaf, DanSteve, and myself.

Relevant Working Groups

Categories
IETF IPv6

Rough Guide to IETF 103: IPv6

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

IPv6 deployment hit another milestone recently, reaching 25% adoption globally. The almost total depletion of the pool of unallocated IPv4 addresses has seen the cost of an IPv4 address on the transfer market rise from USD 15 to 18 in just a few months, which has encouraged network operators to further step-up their deployment efforts.

There was some good news from the UK with the largest mobile operator EE and the incumbent provider of broadband Internet BT, increasing to nearly 30% and 46% respectively. Other mobile operators deploying IPv6 also saw a boost this month with the release of Apple’s iOS 12 update that adds IPv6 support for cellular data.

Belgium still leads the way, but Germany is rapidly catching up, followed by Greece, the US and India. France, Malaysia, Finland and Australia also seem to have seen a surge in deployment recently.

IPv6 is always an important focus for the IETF, and this meeting will see a lot of work with respect to deployment-related improvements and the Internet-of-Things.

The IPv6 Operations (v6ops) Working Group is a key group and will be meeting on Monday morning. It’s published four RFCs since its last meeting, including Happy Eyeballs v2, and this time will kick-off with a presentation on the CERNET2 network which is an IPv6-only research and education in China.

There’s also four drafts to be discussed, including three new ones. IPv6-Ready DNS/DNSSSEC Infrastructure recommends how DNS64 should be deployed as it modifies DNS records which in some circumstances can break DNSSEC. IPv6 Address Assignment to End-Sites obsoletes RFC 6177 with best current operational practice from RIPE-690 that makes recommendations on IPv6 prefix assignments, and reiterates that assignment policy and guidelines belong to the RIR community. Pros and Cons of IPv6 Transition Technologies for IPv4aaS discusses different use case scenarios for the five most prominent IPv4-as-a-service (IPv4aaS) transitional technologies, whilst NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks is an updated draft that describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network.

The other key group is the IPv6 Maintenance (6man) Working Group that will be meeting on Tuesday afternoon. Since the last meeting this has published just the one RFC on creating an IANA registry for updating the IPv6 Neighbor Discovery Prefix Information Option Flags, but has no less than nine drafts up for discussion.

The couple of working group sponsored drafts relate to specifying a IPv6 Segment Routing Header (SRH) and how this can be used by Segment Routing capable nodes, and specifying a Router Advertisement flag to indicate to hosts that a link is IPv6-only. There are also a couple of new drafts that specify how IOAM (In-situ Operations, Administration and Maintenance) records are encapsulated in IPv6, and defining the building blocks that can be used for OAM in Segment Routing with IPv6.

That leaves five existing drafts to be discussed, covering communicating NAT64 prefixes to clients with Router Advertisements, Updates to Requirements for IPv6 Options, Path MTU Discovery solutions, a new Path MTU Hop-by-Hop Option to record minimum Path MTU from source to destination, and IPv6 Packet Truncation procedures.

On Tuesday morning, the IP Wireless Access in Vehicular Environments (ipwave) Working Group will be meeting. Most of the agenda is focusing on updates to the specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicular communications, and the use cases for IP-based vehicular networks, but there’s recently been a couple of updates to DNS Name Autoconfiguration for Internet of Things Devices and IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks, so these may also be discussed.

The Homenet (homenet) Working Group has previously been quite active, but appears to be focusing on the Homenet Naming and Service Discovery Architecture during its meeting on Wednesday afternoon. There’s also an agenda item for general security questions, and a demonstration of SecureHomeGateway, before moving into discussions on re-chartering the group.

There’s also two IPv6-related working groups on Monday. The Routing Over Low Power and Lossy Networks (roll) Working Group focuses on IPv6 routing issues for these networks. This has a very busy agenda commencing with an update on the ROLL-BIER design that extends RPL to support routing based on Bit Index Explicit Replication (BIER) in environments with limited and lossy updates. There are seven other drafts up for discussion on Efficient Route Invalidation, RPL protocol design issues, route discovery for symmetric and asymmetric point-to-point traffic flows, a packet transmission rate metric for parent node selection, implementing the forwarding of copies of packets over different paths to different RPL parents, a proposal to extend the RPL protocol to install centrally-computed routes, and an update to the unicast routing services in an RPL domain.

The IPv6 over Networks of Resource Constrained Nodes (6lo) Working Group also has a busy agenda. This includes a discussion on the proposed draft that updates RFC 6775 to support registration extensions for simplifying these operations in 6LoWPAN routers, an update on Address Protected Neighbor Discovery for Low-power and Lossy Networks, an update to RFC 4944 with a simple protocol to recover packet fragments over a mesh network, and the IPv6 Backbone Router draft being prepared for a Working Group Last Call.

Other drafts up for review include transmitting IPv6 packets over Near Field Communication (NFC), a new type of 6LoWPAN routing header containing delivery deadlines for data packets, and IPv6 over Power-Line Communication Networks. The session will be rounded-off with a performance report on fragment forwarding and recovery.

Tuesday morning sees the meeting of the Low Power Wide-Area Networks (lpwan) Working Group. There will be another discussion around whether to move to a Working Group Last Call on the Static Context Header Compression (SCHC) framework for IPv6 and UDP, that provides both header compression and fragmentation functionalities. Three other drafts describe similar schemes for SigFox,LoRaWAN and IEEE 802.15.4 type networks.

Rounding off the IPv6-related sessions on Thursday afternoon, the IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Working Group, will focus on the specification for a combining a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH). The 6top protocol that enables distributed scheduling is now heading for publication as an RFC, and there are also updates to the description of a scheduling function that defines the behavior of a node when joining a network and to define a security framework for joining a 6TiSCH network. If there’s time, a method to protect network nodes against a selective jamming attack will be discussed.

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

IPv6-related Working Groups at IETF 103:

V6OPS (IPv6 Operations) Working Group
Monday, 5 November 2018 09.00-11.00 UTC+7, Meeting 1
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-v6ops/

ROLL (Routing Over Low power and Lossy networks) WG
Monday, 5 November 2018 09.00-11.00 UTC+7, Boromphimarn 1/2
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-roll/
Documents: https://datatracker.ietf.org/wg/roll/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-roll/

6LO (IPv6 over Networks of Resource Constrained Nodes) WG
Monday, 5 November 2018 16.10-18.10 UTC+7, Meeting 2
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-6lo/
Documents: https://datatracker.ietf.org/wg/6lo/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6lo/

IPWAVE (IP Wireless Access in Vehicular Environments) WG
Tuesday, 6 November 2018 09.00-11.00 UTC+7, Meeting 2
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-ipwave/
Documents: https://datatracker.ietf.org/wg/ipwave/documents/
Charter: https://datatracker.ietf.org/wg/ipwave/documents/

LPWAN (IPv6 over Low Power Wide-Area Networks) WG
Tuesday, 6 November 2018 09.00-11.00 UTC+7, Meeting 1 Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-lpwan/
Documents: https://datatracker.ietf.org/wg/lpwan/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-lpwan/

6MAN (IPv6 Maintenance) WG
Monday, 16 July 2018 @ 09.30-12.00 UTC-4, Laurier
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-6man/
Documents: https://datatracker.ietf.org/wg/6man/documents/
Charter: https://datatracker.ietf.org/wg/6man/charter/

Homenet (Home Networking) WG
Wednesday, 7 November 2018 13.50-15.20 UTC+8, Chitlada 3
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-homenet/
Documents: https://datatracker.ietf.org/wg/homenet/documents/
Charter: https://datatracker.ietf.org/wg/homenet/charter/

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Thursday, 8 November 2018 16.10-18.10 UTC+7, Boromphimarn 1/2
Agenda: https://datatracker.ietf.org/meeting/103/materials/agenda-103-6tisch/
Documents: https://datatracker.ietf.org/wg/6tisch/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/

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