RFC 5942

IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes

📅 published July 2010, from ietf

okay bestie, let's get the basics first 💅 this is a Standards Track doc from the IETF, published in July 2010. It's by H. Singh and W. Beebee of Cisco Systems, Inc. and E. Nordmark of Oracle, Inc. 💜

  • It updates RFC 4861 🔥 (it doesn't list anything it obsoletes)
  • ISSN: 2070-1721
  • Status: Internet Standards Track, approved by the IESG after public review 🦋

Abstract ✨

okay so IPv6 has its own model of a subnet, and it's NOT the same as the IPv4 one 👀 the differences are subtle, and that subtlety has led to implementations that just don't interoperate 😭 this doc spells out the biggest difference: an IPv6 address isn't automatically tied to an IPv6 on-link prefix 🫶 it also updates part of the definition of "on-link" from RFC 4861, partly because of security problems caused by buggy implementations 🔐

Status of This Memo 📝

this is an Internet Standards Track doc 🎀

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 ✨

info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5942 💖

Copyright (c) 2010 IETF Trust and the persons identified 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 (http://trustee.ietf.org/license-info) as they stood on the publication date. read those carefully, bestie, because they explain your rights and restrictions for this document 🧐 any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 💅

this doc might include material from IETF Documents or IETF Contributions published or publicly available before November 10, 2008 🕰️ the people who control the copyright on some of that stuff might not have let the IETF Trust allow modifications outside the IETF Standards Process 😬 so unless you get an adequate license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸

Table of Contents 📖

1. Introduction ....................................................2
2. Requirements Language ...........................................4
3. Host Behavior ...................................................4
4. Host Rules ......................................................7
5. Observed Incorrect Implementation Behavior ......................8
6. Updates to RFC 4861 .............................................9
7. Conclusion ......................................................9
8. Security Considerations .........................................9
9. Contributors ....................................................9
10. Acknowledgements ...............................................9
11. References ....................................................10
   11.1. Normative References .....................................10
   11.2. Informative References ...................................10

1. Introduction 🧚

okay so IPv4 implementations usually attach a netmask to an address when that address gets assigned to an interface 🍓 the netmask plus the IPv4 address designates an on-link prefix ✨ nodes treat any address covered by an on-link prefix as directly attached to the same link as the sender, which means they send traffic straight to it instead of going through a router. see Section 3.3.1 of [RFC1122] 💜

back before subnetting [RFC0950] and Classless Inter-Domain Routing (CIDR) [RFC4632] existed, you could figure out an address's netmask just by checking whether it was a Class A, B, or C address 🙈 these days, assigning an address to an interface also means specifying which netmask to use. if you don't specify a netmask when assigning, some implementations would fall back to deriving it from the address's class 💀

IPv6 is a whole different vibe 🦋 its behavior, as specified in Neighbor Discovery (ND) [RFC4861], is quite different. on-link determination is separate from address assignment. a host can have IPv6 addresses with no related on-link prefixes, or it can have on-link prefixes that aren't related to any IPv6 addresses assigned to it 🌈 any assigned address on an interface should initially be considered as having no internal structure, as shown in [RFC4291] ✨

by default, a host in IPv6 only treats the link-local prefix as on-link 🎀

when a host gets a Prefix Information Option (PIO) with the L-bit set [RFC4861] and a non-zero valid lifetime, it creates (or updates) an entry in the Prefix List 💖 every prefix on that Prefix List (meaning the ones that haven't timed out yet) counts as on-link for that host 🫶

the on-link definition in the Terminology section of [RFC4861], as modified by this doc, is the complete list of cases where a host considers an address to be on-link 👑 individual address entries can get expired by the Neighbor Unreachability Detection mechanism 💅

IPv6 packets sent using the Conceptual Sending Algorithm from [RFC4861] only trigger address resolution for addresses the sender considers on-link 🔥 packets to any other address go to a default router. if there's no default router, the node should send an ICMPv6 Destination Unreachable indication, as specified in [RFC4861] -- more details are in the "Host Behavior" and "Host Rules" sections of this doc 🙌 (quick note: [RFC4861] changed the behavior when the Default Router List is empty. in the old version of Neighbor Discovery [RFC2461], if the Default Router List was empty, instead of sending the ICMPv6 Destination Unreachable indication, the [RFC2461] node assumed the destination was on-link. 😭) also, ND is scoped to a single link 🧭 all Neighbor Solicitation (NS) responses are assumed to go out the same interface the query came in on, without using the Conceptual Sending Algorithm ✨

if host implementations don't correctly implement the IPv6 subnet model, you can end up with no IPv6 connectivity at all 😩 check the "Observed Incorrect Implementation Behavior" section for the details 🔍

this doc deprecates the last two bullets from the definition of "on-link" in [RFC4861] 🚫 the reason is security concerns from particular ND implementations 🔐

host behavior gets clarified in the "Host Behavior" and "Host Rules" sections 🎀

2. Requirements Language 💅

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🦋 when you see them in caps, that's the official language, so read them literally, bestie 🫶

to be continued in part 2 🌸✨

3. Host Behavior ✨

  1. Okay so the original Neighbor Discovery (ND) spec [RFC4861] was kinda unclear about the term "on-link" in a few places 🙈. In IPv6, an address is on-link (with respect to a specific link) if the address has been assigned to an interface attached to that link. Any node attached to the link can send a datagram directly to an on-link address without forwarding it through a router. But for a node to know that a destination is on-link, it has to get configuration info to that effect 💅. There are two main ways IPv6 keeps track of on-link destinations. First, a host keeps a Prefix List that identifies ranges of addresses that count as on-link. Second, Redirects can identify individual destinations that are on-link, and they update the Destination Cache.

The Prefix List gets populated in these ways:

  • Receiving a valid Router Advertisement (RA) that specifies a prefix with the L-bit set. That prefix is considered on-link for a period specified in the Valid Lifetime and gets added to the Prefix List. (The link-local prefix is effectively considered a permanent entry on the Prefix List 🔒.)
  • Indicating an on-link prefix (which may be a /128) via manual configuration, or some other yet-to-be-specified configuration mechanism.

A Redirect can also signal whether an address is on-link. If a host originates a packet, but the first-hop router routes the received packet back out onto the same link, the router also sends the host a Redirect. If the Target and Destination Address of the Redirect are the same, the Target Address is to be treated as on-link as specified in Section 8 of [RFC4861]. That means the host updates its Destination Cache (but not its Prefix List -- though the impact is similar) 🦋.

  1. It should be noted that ND does not have a way to indicate a destination is "off-link" 🙃. Instead, a destination is assumed to be off-link unless there is explicit information saying it's on-link. That info may later expire or be changed, in which case a destination may go back to being considered off-link. That's different from there being an explicit mechanism for signaling that a destination is off-link, though. Redirect messages do not contain enough information to signal that an address is off-link. Instead, Redirect messages indicate a preferred next hop that is a better choice than the originator of the Redirect 🧚.
  2. IPv6 also defines the term "neighbor" to refer to nodes attached to the same link that can send packets directly to each other 🫶. Received ND packets that pass the required validation tests can only come from a neighbor attached to the link on which the ND packet was received. Unfortunately, [RFC4861] is imprecise in its definition of "on-link" and says a node considers an address to be on-link if:
    • a Neighbor Advertisement (NA) message is received for the (target) address, or
    • any Neighbor Discovery message is received from the address.

Neither of these tests is an acceptable definition for an address to be considered on-link as defined above. This document deprecates and removes both of them from the formal definition of "on-link" 😤. Neither test should be used as justification for modifying the Prefix List or Destination Cache for an address.

The conceptual sending algorithm of [RFC4861] defines a Prefix List, Destination Cache, and Default Router List. Together, those three form what many implementations consider the IP data forwarding table for a host 📋. The Neighbor Cache is a separate data structure referenced by the Destination Cache, but entries in the Neighbor Cache are not necessarily in the Destination Cache. It is quite possible (and intentional) that entries get added to the Neighbor Cache for addresses that would not be considered on-link as defined above. For example, upon receipt of a valid NS, Section 7.2.3 of [RFC4861] states:

If an entry does not already exist, the node SHOULD create a new one and set its reachability state to STALE as specified in Section 7.3.3. If an entry already exists, and the cached link-layer address differs from the one in the received Source Link-Layer option, the cached address should be replaced by the received address, and the entry's reachability state MUST be set to STALE.

The point of this feature is to add an address to the Neighbor Cache even though it might not be considered on-link per the Prefix List. The benefit is that the receiver gets its Neighbor Cache populated with an address it will almost certainly be sending packets to shortly, which avoids needing another round of ND for address resolution 🚀. But because there's no validation of the address being added to the Neighbor Cache, an intruder could spoof the address and make a receiver add an address for a remote site to its Neighbor Cache. This vulnerability is one specific instance of the broad set of attacks that are possible by an on-link neighbor [RFC3756] 😱. This causes no problems in practice, so long as the entry only exists in the Neighbor Cache and the address is not considered on-link by the IP forwarding code (i.e., the address is not added to the Prefix List and is not marked as on-link in the Destination Cache).

  1. Okay, so after the update to the on-link definition in [RFC4861], some text from Section 7.2.3 of [RFC4861] might look inconsistent with the updated definition at first glance 👀. That's because the text doesn't make sure the source address is already deemed on-link through other methods:
If the Source Address is not the unspecified address and, on link layers that have addresses, the solicitation includes a Source Link-Layer Address option, then the recipient SHOULD create or update the Neighbor Cache entry for the IP Source Address of the solicitation.

The following text from Section 6.2.6 of [RFC4861] might also seem inconsistent:

If there is no existing Neighbor Cache entry for the solicitation's sender, the router creates one, installs the link-layer address and sets its reachability state to STALE as specified in Section 7.3.3.

But if you look closer, the text in those sections of [RFC4861] is actually consistent with deprecating the last two bullets of the on-link definition 🤓. That's because on-link determination can affect the state of ND in two different ways: by updating the Prefix List or by updating the Destination Cache. By deprecating the last two bullets, the Prefix List is explicitly not to be changed when a node receives an NS, NA, or Router Solicitation (RS). The Neighbor Cache can still be updated through receipt of an NS, NA, or RS 💖.

  1. [RFC4861] is written from the perspective of a host with a single interface on which Neighbor Discovery is run. All ND traffic, whether sent or received, traverses that single interface. On hosts with multiple interfaces, you have to take care that the scope of ND processing from one link stays local to that link 🎀. That means when responding to an NS, the NA would be sent out on the same link on which it was received. Likewise, a host would not respond to a received NS for an address that's only assigned to an interface on a different link. Implementations may choose to implement Neighbor Discovery using a single data structure that merges the Neighbor Caches of all interfaces, but an implementation's behavior must be consistent with the above model 🌈.

4. Host Rules 👑

A correctly implemented IPv6 host MUST adhere to the following rules:

  1. The assignment of an IPv6 address, whether through IPv6 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual configuration, MUST NOT implicitly cause a prefix derived from that address to be treated as on-link and added to the Prefix List. A host considers a prefix to be on-link only through explicit means, such as those specified in the on-link definition in the Terminology section of [RFC4861] (as modified by this document) or via manual configuration. Note that the requirement for manually configured addresses is not explicitly mentioned in [RFC4861] 🙌.
  2. In the absence of other sources of on-link information, including Redirects, if the RA advertises a prefix with the on-link (L) bit set and the Valid Lifetime later expires, the host MUST then consider addresses of the prefix to be off-link, as specified by the PIO paragraph of Section 6.3.4 of [RFC4861] ⏰.
  3. In the absence of other sources of on-link information, including Redirects, if the RA advertises a prefix with the on-link (L) bit set and the Valid Lifetime later expires, the host MUST then update its Prefix List with respect to the entry. In most cases, this results in the addresses covered by the prefix defaulting back to being considered off-link, as specified by the PIO paragraph of Section 6.3.4 of [RFC4861]. However, there are cases where an address could be covered by multiple entries in the Prefix List, and expiring one prefix would mean destinations are then covered by a different entry 🧩.
  4. Implementations compliant with [RFC4861] MUST adhere to the following rules. If the Default Router List is empty and there is no other source of on-link information about any address or prefix:
    • a. The host MUST NOT assume that all destinations are on-link. 🚫
    • b. The host MUST NOT perform address resolution for non-link-local addresses. 🚫
    • c. Since the host cannot assume the destination is on-link, and off-link traffic cannot be sent to a default router (since the Default Router List is empty), address resolution cannot be performed. This case is specified in the last paragraph of Section 4 of [RFC4943]: when there is no route to the destination, the host should send an ICMPv6 Destination Unreachable indication (for example, a locally delivered error message) as specified in the Terminology section of [RFC4861] 💀.

On-link information concerning particular addresses and prefixes can make those specific addresses and prefixes on-link, but it does not change the default behavior mentioned above for addresses and prefixes not specified. [RFC4943] provides justification for these rules 💜.

5. Observed Incorrect Implementation Behavior 💀

okay so this one is a real horror story 😭 One incorrect implementation behavior shows how bad things get when the IPv6 subnet model isn't understood by the implementers of several popular host operating systems 🫠. Picture an access concentrator network ([RFC4388]) where a host gets a Router Advertisement message with no on-link prefix advertised 🙈. The host can still end up with an address, either from the DHCPv6 identity association for non-temporary addresses (IA_NA) option from [RFC3315] (which does not include a prefix length), or from manual configuration (if no prefix length is specified). But then the host incorrectly assumes an invented prefix is on-link 🚩.

This invented prefix is typically a /64, written by the developer of the operating system network module API as a "default" prefix length for any IPv6 application when a length isn't specified. ngl, it's giving "helpful default" but it's actually a trap 🪤. It can make the API seem to work when a network interface starts stateless address autoconfiguration (SLAAC) ✨, but it can cause connectivity problems in Non-Broadcast Multi-Access (NBMA) networks 😩.

Here's where it gets dramatic: having wrongly assumed that invented prefix, the host performs address resolution when the host should send all non-link-local traffic to a default router. Neither the router nor any other host will respond to that address resolution, so this host is literally blocked from sending IPv6 traffic 😭🫥. Not okay 💔.

6. Updates to RFC 4861 🦋

bestie, this section is the glow-up 💅. This document deprecates the following two bullets from the on-link definition in Section 2.1 of [RFC4861]:

  • a Neighbor Advertisement message is received for the (target) address, or
  • any Neighbor Discovery message is received from the address.

So those two bullets are officially on their way out 👋🌸.

7. Conclusion 🎀

okay wrapping this up with a bow 🎀. This document clarifies and summarizes the relationship between links and subnet prefixes described in [RFC4861] 🧠. The main vibe check: configuring an IPv6 address does not imply that a corresponding on-link prefix exists ✨. If you want more on prefix length in the API, go read the last paragraph of Section 4.2 of [RFC4903], because it's giving important 📚. This document also updates the definition of "on-link" from [RFC4861] by deprecating the last two bullets 💜.

8. Security Considerations 🚨

this part is not a joke, bestie 😤🚨. This document addresses a security concern present in [RFC4861]. Because of that, the last two bullets of the on-link definition in [RFC4861] have been deprecated, and that's a big deal 💀. US-CERT Vulnerability Note VU#472363 lists the implementations affected 🔥, so go check it if you run any of them 🫶.

9. Contributors 🧚

shoutout to Thomas Narten, who contributed significant text and provided substantial guidance to the production of this document 🫶💖. Iconic behavior 👑.

10. Acknowledgements 🌈

big thank-you energy 💖. Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh Krishnan, Josh Littlefield, Bert Manfredi, David Miles, Madhu Sudan, Jinmei Tatuya, Dave Thaler, Bernie Volz, and Vlad Yasevich for their consistent input, ideas, and review during the production of this document ✨🙌. The security problem related to an NS message that provides one reason for invalidating a part of the on-link definition was found by David Miles 🕵️‍♀️. Jinmei Tatuya found the security problem to also exist with an RS message 🔍.

11. References 📚

11.1. Normative References

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4861]   Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
            "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
            September 2007.

11.2. Informative References

[RFC0950]   Mogul, J. and J. Postel, "Internet Standard Subnetting
            Procedure", STD 5, RFC 950, August 1985.

[RFC1122]   Braden, R., "Requirements for Internet Hosts -
            Communication Layers", STD 3, RFC 1122, October 1989.

[RFC2461]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor
            Discovery for IP Version 6 (IPv6)", RFC 2461,
            December 1998.

[RFC3315]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
            and M. Carney, "Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3756]   Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
            Discovery (ND) Trust Models and Threats", RFC 3756,
            May 2004.

[RFC4291]   Hinden, R. and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 4291, February 2006.

[RFC4388]   Woundy, R. and K. Kinnear, "Dynamic Host Configuration
            Protocol (DHCP) Leasequery", RFC 4388, February 2006.

[RFC4632]   Fuller, V. and T. Li, "Classless Inter-domain Routing
            (CIDR): The Internet Address Assignment and Aggregation
            Plan", BCP 122, RFC 4632, August 2006.

[RFC4862]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
            Address Autoconfiguration", RFC 4862, September 2007.

[RFC4903]   Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
            June 2007.

[RFC4943]   Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
            Discovery On-Link Assumption Considered Harmful",
            RFC 4943, September 2007.

Authors' Addresses 🫶

the crew who made this happen 💜✨

Hemant Singh
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

Phone: +1 978 936 1622
EMail: shemant@cisco.com
URI:   http://www.cisco.com/


Wes Beebee
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

Phone: +1 978 936 2030
EMail: wbeebee@cisco.com
URI:   http://www.cisco.com/

Erik Nordmark
Oracle, Inc.
17 Network Circle
Menlo Park, CA 94025
USA

Phone: +1 650 786 2921
EMail: erik.nordmark@oracle.com
📦 where this page comes from