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 IETF IPv6

Deploy360@IETF99, Day 1: IoT, IPv6 & SIDR

It’s another busy week at IETF 99 in Prague, and we’ll be bringing you daily blog posts that highlight what Deploy360 will be focused on during that day. And Monday sees a packed agenda with three working groups on the Internet-of-Things, a couple on routing, one on encryption, and an important IPv6 Maintenance WG session.

The day kicks off at 09.30 CEST/UTC+2 with 6MAN, and the big development is the move of the IPv6 specification to Internet Standard Status, as despite being widely deployed, IPv6 has remained a ‘Draft Standard’ since its original publication in 1998. There are also two working group drafts on updating the IPv6 Addressing Architecture as currently defined in RFC 4291, and on IPv6 Node Requirements as currently defined in RFC 6434. Other existing drafts up for discussion include recommendations on IPv6 address usage and on Route Information Options in Redirect Messages.

There are three new drafts being proposed, including one that covers scenarios when IPv6 hosts might not be able to properly detect that a network has changed IPv6 addressing and proposes changes to the Default Address Selection algorithm defined in RFC6724; another that proposes a mechanism for IPv6 hosts to retrieve additional information about network access through multiple interfaces; whilst the remaining draft defines the AERO address for use by mobile networks with a tethered network of IoT devices requiring a unique link-local address after receiving a delegated prefix.


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


Running in parallel is ACE which is developing authentication and authorization mechanisms for accessing resources on network nodes with limited CPU, memory and power. Amongst the ten drafts on the agenda, there’s one proposing a DTLS profile for ACE.

Also at the same time is CURDLE which is chartered to add cryptographic mechanisms to some IETF protocols, and to make implementation requirements including deprecation of old algorithms. The agenda isn’t very comprehensive at the moment, but nine drafts were recently submitted to the IESG for publication, and what will certainly be discussed today is a draft on key change methods for SSH.

In the afternoon, Homenet is meeting from 13.30 CEST/UTC+2. This is developing protocols for residential networks based on IPv6, and will continue to discuss updated drafts relating to a name resolution and service discovery architecture for homenetshow the Babel routing protocol can be used in conjunction with the HNCP protocol in a Homenet scenario, and the use of .homenet as a special use top-level domain to replace .home. There are also three new drafts relating to the service discovery and registration aspects of Homenet.

Running in parallel is 6TiSCH. There will be summaries of the 1st F-Interop 6TiSCH Interoperability Event and OpenWSN Hackathon, followed by discussions on the updated drafts related to the 6top protocol that enables distributed scheduling, as well as a draft related to security functionality.

The later afternoon session sees SIDROPS meeting from 15.50 CEST/UTC+2. This is taking the technology developed by SIDR and is developing guidelines for the operation of SIDR-aware networks, as well as providing operational guidance on how to deploy and operate SIDR technologies in existing and new networks. One particularly interesting draft proposes to use blockchain technology to validate IP address delegation, whilst another describes an approach to validate the content of the RPKI certificate tree. A couple of other drafts aim to clarify existing approaches to RPKI validation.

Concluding the day is GROW during the evening session. This group looks at the operational problems associated with the IPv4 and IPv6 global routing systems, and whilst theres’s no agenda for this meeting yet, four new and updated drafts were recently published on more graceful shutting down of BGP sessions, how to minimise the impact of maintenance on BGP sessions, and extensions to the BGP monitoring protocol.

For more background, please read the Rough Guide to IETF 99 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups

Categories
Deploy360 IETF

Deploy360@IETF98, Day 4: IPv6, IoT & ACME

Thursday at week IETF 98 in Chicago is another mix of IPv6, the Internet-of-Things and TLS-related working groups. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

The first session of the day is 6MAN which has a last call on updates to the IPv6 specification as currently defined in RFC 2460, RFC 4291, and RFC 1981. There are also two new drafts under discussion related to recommendations on IPv6 address usage  and temporary IPv6 interface identifiers, plus a draft describing how a Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) client can send a message over a congested network by tagging outgoing IPv6 packets in order to reach a DOTS server.

Three current drafts include a description of common functionality that should be required on all IPv6 hosts and routers that has been collected from other published IETF Standards Track documents, definition of a new control bit in an IPv6 router advertisement indicating that a receiving node is the exclusive receiver of all traffic destined to any address with that prefix, and providing a backward-compatible extension to the Redirect function in the IPv6 Neighbour Discovery protocol to allow routers to include information that a recipient can associate with the next hop.


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


The afternoon sees ACME which has been developing a standards-based REST API allowing agent software to authenticate that a server controls a domain, request a certificate, and then install it on a server without human intervention. This session is discussing some changes to the ACME specification, as well as the next steps for the group with a view to re-chartering.

Finally, there are two working groups of interest during the evening session. DHC has three DHCPv6 related drafts on the agenda, whilst ROLL continues development of  several routing protocols for resource constrained nodes.

For more background, please read the Rough Guide to IETF 98 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF IPv6 Transport Layer Security (TLS)

Deploy360@IETF97, Day 2: DNS, TLS & More IPv6

Seoul SkylineTuesday at IETF 97 in Seoul represents something of a mixed bag, with sessions on IPv6 DNS and TLS. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

First up is 6MAN on Tuesday morning at 09.30 KST (UTC+9). On the agenda are several updates to the IPv6 specification as currently defined in RFC 2460RFC 4291 and RFC 1981. Other drafts being discussed outline 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; 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.


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


There’s a clash between the Domain Name System Operations (dnsop) and Privacy Enhanced RTP Conferencing (perc) Working Groups on Tuesday afternoon at 13.30 KST (UTC+9). So we’ll be having to split our efforts between those, before heading to the Transport Layer Security (tls) Working Group for the evening session starting at 15.50 KST (UTC+9).

DNSOP is currently discussing several DNSSEC-related drafts. One recently submitted draft suggests an approach to managing Reverse DNS in IPv6 for Internet Service Providers, as the common practice of providing in.addr.arpa information using one PTR record for every IPv4 address does not scale with IPv6. There’s also a trance of other updates, including Signaling Trust Anchor Knowledge in DNSSEC which specifies two different ways validating resolvers to signal which keys are being used in their chain-of-trust; Managing DS records from parent via CDS/CDNSKEY which describe policies for signalling changes when undertaking key rollovers, and on Aggressive use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a particular range as well as positive answers
from wildcards.

PERC will be discussing just a couple of Deploy360 relevant drafts. The first defines a DTLS tunneling protocol that enables a Media Distribution Device (MDD) to facilitate key exchange between an endpoint and a Key Management Function (KMF); whilst SRTP Double Encryption Procedures defines procedures to allow an intermediary node to manipulate RTP parameters while still providing strong end-to-end security.

That just leaves the first session of TLS which has several issues on the agenda. One is whether to rebrand the forthcoming TLS 1.3 to TLS 2.0 given the significant changes in the specification. Another is the ongoing draft defining a new TLS extension to allow clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. Finally, Delegated Credentials for TLS describes a mechanism to allow TLS servers to make delegated changes to certificates or cryptographic algorithms without breaking compatibility with clients.

For more background, please read the Rough Guide to IETF 97 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups: