RFC 8273

Unique IPv6 Prefix per Host

📅 published December 2017, from ietf

RFC 8273: Unique IPv6 Prefix per Host 🎀

okay bestie, let's get into it ✨ this one is an Informational doc (so not a Standards Track thing, just vibes and best practices 💅) from the IETF, written by J. Brzozowski of Comcast Cable and G. Van de Velde of Nokia. It came out in December 2017 and it's ISSN 2070-1721. It doesn't obsolete or update any other RFCs, so it's a clean slate 🫶

Here's the whole pitch: instead of every device sharing one IPv6 prefix, give each host its own unique prefix 🦋 that way, the devices on a shared network get better isolation, and providers get way better subscriber management. no cap, it's iconic 🔥

Abstract ✨

Okay so the abstract is like the TL;DR 🍓 It says this doc lays out a way to use IPv6 protocols that already exist so hosts can each get a unique IPv6 prefix (instead of a unique address from a prefix everybody shares). The perks? Better host isolation and easier subscriber management on shared network segments. literally the main character energy of IPv6 🌸

Status of This Memo 💜

Lowkey the most boring section, but we still gotta keep it 😭 This document is not an Internet Standards Track spec. It's published for informational purposes only 🧚

It is a product of the IETF, which means it reflects the consensus of the IETF community 🌈 It got public review and was approved for publication by the IESG (Internet Engineering Steering Group). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 if you're curious about that 🙈

If you want the current status, errata, or a way to give feedback, go to https://www.rfc-editor.org/info/rfc8273 ✨

Copyright (c) 2017 IETF Trust and the people listed as the document authors. All rights reserved 💅

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date. Read those carefully, because they spell out your rights and restrictions 📜 Any code pulled out of this doc has to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and it comes with no warranty, as described in that same license 🫶

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  Motivation and Scope of Applicability . . . . . . . . . . . .   3
3.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   4
4.  Assignment of IPv6 Unique Prefixes  . . . . . . . . . . . . .   4
5.  Best Practices for IPv6 Neighbor Discovery  . . . . . . . . .   6
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction 🦋

So the origin story: these ideas were first built as part of a huge production rollout of IPv6 support for a network service that a provider manages and that's shared by lots of people 💖

A shared-access network service is when one Layer 2 (L2) access network, like Wi-Fi, gets shared with a bunch of visiting devices (aka subscribers) 📶 A lot of providers either have legal requirements or just think it's good practice to keep those visitor devices isolated from each other, so nobody can cause trouble on the shared network 🛡️

A network that gives each host a unique IPv6 prefix can just make sure devices can't send packets to each other except through the first-hop router 🌸 This automatically protects against attacks between devices that depend on link-local ICMPv6 packets, like Duplicate Address Detection (DAD) reply spoofing, Neighbor Discovery (ND) cache exhaustion, malicious redirects, and rogue Router Advertisements (RAs) 😈 It's way more scalable and robust than the other options, like DAD proxying, forced forwarding, or ND snooping 💅

IPv6 support doesn't rule out IPv4 here 🌈 The main goal, though, was to let user equipment (UE) have an IPv6-only experience from the network operator's point of view ✨ In this doc, UE can be regular end-user gear, or a server in a data center, as long as there's a shared network (wired or wireless) 🖥️

IPv4 details are out of scope for this doc 🙈 It will also outline the requirements that UE has to satisfy to get that IPv6-only experience 🎀

Most current deployments assign UE IPv6 addresses using IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] and/or DHCP IA_NA (Identity Association - Non-temporary Address) [RFC3315] 💖 Back when this approach was being developed and rolled out, people noticed some operating systems didn't support getting IA_NA over DHCPv6 per [RFC7934] 😬 To avoid leaving out any known IPv6 implementations, IPv6-SLAAC-based subscriber and address management is the recommended tech for reaching the most connected IPv6 devices on a provider-managed shared-access network 🧚 Also, an IA_NA-only network is NOT RECOMMENDED per Section 8 of [RFC7934] 🙅‍♀️ This doc will walk through the mechanics of IPv6-SLAAC-based address and subscriber management paired with stateless DHCPv6, where it helps 🍓

This doc focuses on how UE gets a unique IPv6 prefix 💜

1.1. Requirements Language 💅

Okay, the key words, the ones with the official meaning, are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 🫶 They're interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS like shown here 📣

2. Motivation and Scope of Applicability ✨

The motivation for this work breaks into these categories 🌈

  • Give deployment advice for IPv6 that allows a stable and secure IPv6-only experience, even when IPv4 support is there too 🔥
  • Make sure IPv6 support is efficient and doesn't hurt the performance of the underlying network, and by extension the customer experience 💖
  • Allow the most flexibility across host implementations, so the widest range of addressing and configuration mechanisms can be used 🦋 Make sure the widest population of UE implementations can take advantage of IPv6 🌸
  • Lay the groundwork for future work on using IPv6 over shared media, which needs optimized subscriber management 🧚
  • Make sure two devices (subscribers/hosts), both on the same provider-managed shared-access network, can only talk to each other through the provider-managed first-hop router 🛡️ Providers often have legal requirements or think it's good practice to keep visitor devices isolated, to control potential abuse of the shared-access network 😤
  • Provide guidelines on best common practices around IPv6 ND [RFC4861] and IPv6-address-management settings between the first-hop router and directly connected hosts/subscribers 💅

3. Design Principles 🎀

The first-hop router in this doc is the L3 Edge router that talks to the devices (hosts and subscribers) directly connected to a provider-managed shared-access network 🖥️ It's also in charge of moving traffic between those directly connected devices, and between them and remote devices 🦋

The work here focuses on best common practices for IPv6 ND and related IPv6-address-management settings between the first-hop router and the directly connected hosts/subscribers 💖 This documented best current practice helps a service provider manage the provider-managed shared-access network on behalf of the connected devices 🧚

This doc RECOMMENDS giving devices on the provider-managed shared-access network a unique IPv6 prefix 🌈 Each unique IPv6 prefix can work as a control-plane anchor point, so every device gets the subscriber policy and service levels it's supposed to get (throughput, QoS, security, parental control, subscriber-mobility management, etc.) 👑

(Part 1 of 3, more on the way bestie 💖 Sections 4 through the references are coming next 🫶)

4. Assignment of IPv6 Unique Prefixes ✨

okay so when a UE connects to the provider-managed shared-access network, it kicks off the IP configuration phase 💅. During this phase, the UE tries to figure out, from an IPv6 point of view, the default IPv6 gateway, the IPv6 prefix info, the DNS info [RFC8106], and everything else it needs for globally routable IPv6 connectivity 🌐. So the subscriber sends an RS (Router Solicitation) message 🦋.

The first-hop router catches that subscriber RS and starts cooking up the reply 🍳. It answers with a solicited RA sent to the subscriber.

When the first-hop router sends a solicited RA response, or periodically sends unsolicited RAs, the RA MUST be sent only to the subscriber that has been assigned the unique IPv6 prefix contained in the RA. 🎀 The way this works is that the solicited RA response or the unsolicited RAs go to the all-nodes group, as described in Sections 6.2.4 and 6.2.6 of [RFC4861]. The twist is that, instead of using the link-layer multicast address for the all-nodes group, the link-layer unicast address of the subscriber that has been assigned the unique IPv6 prefix in the RA MUST be used as the link-layer destination [RFC6085]. Or, optionally in some cases, a solicited RA response could be sent (unicast) to the link-local address of the subscriber, as described in Section 6.2.6 of [RFC4861]. Either way, unsolicited RAs are always sent to the all-nodes group 💜.

This solicited RA carries two important parameters for the subscriber to use: a unique IPv6 prefix (currently a /64 prefix) and some flags 🌸. The unique IPv6 prefix can come from a locally managed pool or an aggregate IPv6 block assigned to the first-hop router, or from a centrally allocated pool. The flags tell the subscriber to use SLAAC and/or DHCPv6 for address assignment. They may also indicate whether the autoconfigured address is on-link or off-link, and whether 'Other' information (e.g., DNS server address) needs to be requested ✨.

The IPv6 RA flags used as best common practice in IPv6-SLAAC-based provider-managed shared-access networks are:

  • M-flag = 0 (The subscriber address is not managed through DHCPv6); this flag may be set to 1 in the future if/when DHCPv6-prefix-delegation support is desired.)
  • O-flag = 1 (DHCPv6 is used to request configuration information, i.e., DNS, NTP information, not for IPv6 addressing.)
  • A-flag = 1 (The subscriber can configure itself using SLAAC.)
  • L-flag = 0 (The prefix is not an on-link prefix, which means that the subscriber will never assume destination addresses that match the prefix are on-link and will always send packets to those addresses to the appropriate gateway according to route selection rules.)

Giving each subscriber a unique IPv6 prefix adds an extra layer of protection and efficiency 🔥. The protection comes from the fact that all external communication from a connected device is directed to the first-hop router, as required by [RFC4861]. The efficiency comes from the fact that the recommended RA flags give the broadest support on connected devices, so they can get a valid IPv6 address (i.e., privacy addresses [RFC4941] or SLAAC [RFC4862]) 🙌.

Designing the RA this way means each subscriber gets its own unique IPv6 prefix 🧚. Each host can then use SLAAC or any other method of choice to select its /128 unique address. To get the IPv6 address of the DNS server, a host can use either stateless DHCPv6 [RFC3736] or IPv6 Router Advertisement Options for DNS Configuration [RFC8106]. If the subscriber wants to send anything external, including traffic towards other subscriber devices (assuming device-to-device communications are enabled and supported), then, because the L-bit is unset, [RFC4861] requires that this traffic be sent to the first-hop router 🚦.

Once the subscriber has received the RA and its flags, it assigns itself a 128-bit IPv6 address using SLAAC 🎉. Since the subscriber device composes the address itself, it needs to verify that the address is unique on the shared network. For that, it performs the DAD algorithm. This happens for each address the UE tries to use on the provider-managed shared-access network 🔍.

5. Best Practices for IPv6 Neighbor Discovery 🫶

An operational consideration when using IPv6 address assignment with IPv6 SLAAC is that, after onboarding, the subscriber has a prefix with certain preferred and valid lifetimes ⏰. The first-hop router extends these lifetimes by sending an unsolicited RA, so the applicable MaxRtrAdvInterval on the first-hop router MUST, therefore, be lower than the preferred lifetime. One consequence is that the first-hop router never knows when a subscriber stops using addresses from a prefix, so additional procedures are required to help it learn this 😭. When using stateful DHCPv6 IA_NA for IPv6 subscriber address assignment, this uncertainty on the first-hop router has no impact, thanks to the stateful nature of DHCPv6 IA_NA address assignment 💅.

Here's the reference table of the key IPv6 router and neighbor discovery timers for provider-managed shared-access networks 📋:

  • Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) = 300 s (or when battery consumption is a concern 686 s, see note below)
  • IPv6 Router Lifetime = 3600 s (see note below)
  • Reachable time = 30 s
  • IPv6 Valid Lifetime = 3600 s
  • IPv6 Preferred Lifetime = 1800 s
  • Retransmit timer = 0 s
Note: When servicing large numbers of battery powered devices, [RFC7772] suggests a maximum of seven RAs per hour and a 45-90 minute IPv6 Router Lifetime. To achieve a maximum of seven RAs per hour, the Minimum IPv6 Router Advertisement Interval (MinRtrAdvInterval) is the important parameter, and it MUST be greater than or equal to 514 seconds (1/7 of an hour). Further, as discussed in Section 6.2.1. of [RFC4861], MinRtrAdvInterval <=0.75 * MaxRtrAdvInterval; therefore, MaxRtrAdvInterval MUST additionally be greater than or equal to 686 seconds. As for the recommended IPv6 Router Lifetime, since this technique requires that RAs be sent using the link-layer unicast address of the subscriber, the concerns over multicast delivery discussed in [RFC7772] are already mitigated; therefore, the above suggestion of 3600 seconds (an hour) seems sufficient for this use case.

IPv6 SLAAC requires the router to maintain neighbor state, and that comes with costs in memory, power, message exchanges, and message processing 🔋. Stale entries can be an unnecessary burden, especially on Wi-Fi interfaces 📶. It is RECOMMENDED that stale neighbor state be removed quickly 🧹.

When using stateless IPv6 address assignment, a number of widely deployed operating systems will try to use [RFC4941] temporary 'private' addresses 🕶️.

Similarly, when this technology is used in a data center, the UE server may need several addresses from the same unique IPv6 prefix, for example because it is running multiple virtual hosts, containers, etc., in the bridged-virtual switch 🐳. This can result in a UE having multiple /128 addresses from the same IPv6 prefix. The first-hop router MUST be able to handle the presence and use of multiple globally routable IPv6 addresses 🍓.

6. IANA Considerations

This document does not require any IANA actions 🌷.

7. Security Considerations 🔐

The mechanics of IPv6 privacy extensions [RFC4941] are compatible with assigning a unique IPv6 prefix per host. However, when you combine IPv6 privacy extensions with a unique IPv6 prefix per host, the subscriber gets a reduced privacy experience 😬. That's because a prefix may be associated with a subscriber even when the subscriber has implemented IPv6 privacy extensions [RFC4941]. If the operator assigns the same unique prefix to the same link-layer address every time a host connects, any remote party who knows this can easily track a host just by tracking its assigned prefix. This nullifies the benefit that privacy addresses [RFC4941] provide 💀. If a host wants to keep its privacy on such networks, it SHOULD ensure that its link-layer address is periodically changed or randomized 🙈.

No other additional security considerations are made in this document.

8. Normative References 📚

Acknowledgements 🫶

okay bestie, the authors wanted to give a big shoutout to David Farmer and Lorenzo Colitti 👑. They didn't just show up, they made extended contributions and suggested text, which is seriously iconic.

The authors also wanted to thank everyone else who helped out 💜. The list is in alphabetical order, so nobody gets to be the main character 🙈:

  • Fred Baker
  • Ben Campbell
  • Brian Carpenter
  • Tim Chown
  • Killian Desmedt
  • Wim Henderickx
  • Brad Hilgenfeld
  • Erik Kline
  • Suresh Krishnan
  • Warren Kumari
  • Thomas Lynn
  • Jordi Palet
  • Phil Sanderson
  • Colleen Szymanik
  • Jinmei Tatuya
  • Eric Vyncke
  • Sanjay Wadhwa

Authors' Addresses 🦋

Here's where you can find the two authors 💖

John Jason Brzozowski
Comcast Cable
1701 John F. Kennedy Blvd.
Philadelphia, PA
United States of America

Email: john_brzozowski@cable.comcast.com
Gunter Van de Velde
Nokia
Antwerp
Belgium

Email: gunter.van_de_velde@nokia.com
📦 where this page comes from