RFC 2491

IPv6 over Non-Broadcast Multiple Access (NBMA) networks

📅 published January 1999, from ietf

RFC 2491: IPv6 over Non-Broadcast Multiple Access (NBMA) networks ✨

Okay bestie, let's get the basics down first 🎀 This one is from the Network Working Group and it's on the Standards Track, dated January 1999. The authors are G. Armitage (Lucent Technologies), P. Schulter (Bright Tiger Technologies), M. Jork (Digital Equipment GmbH), and G. Harter (Compaq). It's all about running IPv6 over NBMA networks, and yes, the whole doc is about that topic 💅

Status of this Memo 🌸

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 💖

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🧚

This document lays out a general architecture for IPv6 over NBMA networks, and it's the foundation for companion documents that get into the details for specific NBMA technologies (like ATM or Frame Relay) 🌈 The architecture lets hosts use the IPv6 Neighbor Discovery protocol in the normal, conventional way, and it also supports 'shortcut' NBMA forwarding paths whenever dynamically signaled NBMA links are available ✨ It also covers operations over administratively configured Point to Point NBMA links.

Dynamic NBMA shortcuts happen through IPv6 Neighbor Discovery operation inside Logical Links, plus inter-router NHRP for finding off-Link NBMA destinations. Both flow-triggered and explicitly source-triggered shortcuts are supported, so you get options 🔥

1. Introduction. ✨

Non Broadcast Multiple Access (NBMA) networks can be used in a bunch of different ways 💅 On one end, they can just give you administratively configurable point to point service, which is enough to connect IPv6 routers (and even IPv6 hosts, in certain situations). On the other end, NBMA networks that support dynamic setup and teardown of Virtual Circuits (or functional equivalents) can copy the service that conventional broadcast media like Ethernet give the IPv6 layer. The catch is that this usually takes complex convergence protocols, especially to support IPv6 multicast 😭

This document lays out a general architecture for IPv6 over NBMA networks 🦋 It's the basis for companion documents with details for specific NBMA technologies (ATM [17] or Frame Relay, for example). The architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, and it also supports the establishment of 'shortcut' NBMA forwarding paths (when dynamically signaled NBMA links are available).

Most of this doc focuses on dynamically managed point to point and point to multipoint calls between interfaces on an NBMA network. These get called "SVCs" for the rest of the document. Administratively configured point to point calls are discussed too, and those get called "PVCs". Depending on context, either one may be shortened to "VC" 🎀

Some NBMA networks offer a form of connectionless service (SMDS, for example). In those cases, a "call" or "VC" shall be considered to implicitly exist if the sender has an NBMA destination address it can transmit packets to whenever it wants 🌸

1.1 Neighbor Discovery.

This is the big difference between this architecture and earlier IP over NBMA protocols: how it supports IPv6 Neighbor Discovery 💖

The IPv4 world came up with an address resolution approach that relied on an auxiliary protocol running at the 'link layer', starting with Ethernet ARP (RFC 826 [14]). In the NBMA world, ARP has been used for IPv4 over SMDS (RFC 1209 [13]) and IPv4 over ATM (RFC 1577 [3]). More recently, the ION working group developed NHRP (Next Hop Resolution Protocol [8]), a general protocol for doing intra-subnet and inter-subnet address resolution across a range of NBMA network technologies 🧚

IPv6 developers chose to move away from a link layer specific approach. Instead, they combined a bunch of tasks into a protocol called Neighbor Discovery [7], which is meant to be non-specific across link layer technologies. A key assumption in Neighbor Discovery's actual protocol is that the link technology under a given IP interface can do native multicasting. That's not really true for most NBMA network services, which usually need convergence protocols to fake the service they want (the MARS protocol, RFC 2022 [5], is an example of one of these) 😭 This document augments and optimizes the MARS protocol so it works for IPv6 Neighbor Discovery, which makes RFC 2022 usable beyond ATM networks 👑

1.2 NBMA Shortcuts.

A shortcut is an NBMA level call (VC) that directly connects two IP endpoints that are logically separated by one or more routers at the IP level. IPv6 packets going over this VC are said to 'shortcut' the routers that sit in the logical IPv6 path between the VC's endpoints 🦋

NBMA shortcuts help minimize how many resources get used inside an IP over NBMA cloud (things like router hops and NBMA VCs) ✨

It's really important that NBMA shortcuts are supported whenever IP is deployed across NBMA networks that can handle dynamic call establishment (SVCs or a functional equivalent). For IPv6 over NBMA, shortcut discovery and management happen through a mix of Neighbor Discovery and NHRP 💅

1.3 Key components of the IPv6 over NBMA architecture.

1.3.1 NBMA networks providing PVC support.

When the NBMA network is used in PVC mode, each PVC connects exactly two nodes, and the use of Neighbor Discovery and other IPv6 features is limited 🙈 IPv6/NBMA interfaces only have one neighbor on each Link. The MARS and NHRP protocols are NOT necessary, since multicast and broadcast operations collapse down to an NBMA level unicast operation. Dynamically discovered shortcuts are not supported in this mode.

The actual details of encapsulations and link token generation SHALL be covered by companion documents for specific NBMA technology. Those companion documents SHALL conform to the following guidelines 🎀

  • Both unicast and multicast IPv6 packets SHALL be transmitted over PVC links using the encapsulation described in section 4.4.1.
  • Interface tokens for PVC links SHALL be constructed as described in section 5. Interface tokens need only be unique between the two nodes on the PVC link.
  • This use of PVC links does not mandate, nor does it prohibit the use of extensions to the Neighbor Discovery protocol which may be developed for either general use of for use in PVC connections (for example, Inverse Neighbor Discovery).

NBMA-specific companion documents MAY additionally specify the concatenation of IPv6 over PPP and PPP over NBMA mechanisms as an OPTIONAL approach to point to point IPv6 🌈

Except where noted above, the rest of this document focuses on the SVC case 💜

1.3.2 NBMA networks providing SVC support.

When the NBMA network is used in SVC mode, the key components are 👑

  • The IPv6 Neighbor model, where neighbors are discovered through messages multicast to members of an IPv6 interface's local IPv6 Link.
  • The MARS model, which allows emulation of general multicast using multipoint calls provided by the underlying NBMA network.
  • The NHRP service for seeking out the NBMA identities of IP interfaces that are logically distant in an IP topological sense.
  • The modeling of IP traffic as 'flows', and optionally using the existence of a flow as the basis for attempting to set up a shortcut link level connection.

In summary 🫶

  • The IPv6 "Link" is generalized to "Logical Link" (LL) in NBMA environments. This is analogous to how IPv4 IP Subnet was generalized to Logical IP Subnet in RFC 1209 and later RFC 1577.
  • IPv6/NBMA interfaces use RFC 2022 (MARS) for general intra-Logical Link multicasting. The MARS itself is used to optimally distribute discovery messages within the Logical Link.
  • For destinations not currently considered to be Neighbors, a host sends the packets to one of its default routers.
  • When appropriately configured, the egress router from a Logical Link is responsible for detecting the existence of an IP packet flow through it that might benefit from a shortcut connection. The router then does the following 🔥
    • While continuing to conventionally forward the flow's packets, the router initiates an NHRP query for the flow's destination IP address.
    • The last router/NHS before the target of the NHRP query ascertains the target interface's preferred NBMA address.
    • The originally querying router then issues a Redirect to the IP source, identifying the flow's destination as a transient Neighbor.
  • Host-initiated triggering of shortcut discovery, regardless of the existence of a packet flow, is also supported through specific Neighbor Solicitations sent to a source host's default router.

A number of key advantages are claimed for this approach. These are 💖

  • The IPv6 stacks on hosts do not implement separate ND protocols for each link layer technology.
  • When the destination of a flow is solicited as a transient neighbor, the returned NBMA address will be the one chosen by the destination when the flow was originally established through hop-by-hop processing. This supports the existing ND ability for IPv6 destinations to perform their own dynamic interface load sharing 🌸

1.4 Terminology.

The bit-pattern or numeric value used to identify a particular NBMA interface at the NBMA level is referred to as an "NBMA address". (An example would be an ATM End System Address, AESA, when applying this architecture to ATM networks, or an E.164 number when applying this architecture to SMDS networks.) 🦋

The call that, once established, is used to transfer IP packets from one NBMA interface to another is referred to as an SVC or PVC, depending on whether the call is dynamically established through some signaling mechanism or administratively established. The specific signaling mechanisms used to establish or tear down an SVC will be defined in the NBMA-specific companion specifications. Certain NBMA networks may provide a form of connectionless service (e.g. SMDS). In these cases, a "call" or "SVC" shall be considered to implicitly exist if the sender has an NBMA destination address to which it can transmit packets whenever it desires 🎀

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 [16] 🫶

1.5. Document Structure ✨

Okay bestie, here's the map of the rest of the doc 🗺️💖 Section 2 explains how an IPv6 Link turns into a "Logical Link" when you're running over NBMA networks, and it introduces the Transient Neighbor 🦋. Section 3 covers the changes to MARS so ND messages get passed around a Logical Link efficiently, plus the rules and mechanisms for finding Transient Neighbors 🔍. Section 4 is the basics: IPv6/NBMA interface initialization, packet and control message encapsulations, and rules for SVC management 🎀. Section 5 covers the general rules for building Interface Tokens, the Link Layer Address Option, and Link Local addresses 🌸. Section 6 wraps up the normative sections, which are the parts with the actual rules 💅.

Appendix A is non-normative, so it's just descriptive text about how Ipv6 Neighbor Discovery works 🧚. Appendix B covers some sub-optimal solutions for emulating the multicasting of Neighbor Discovery messages around a Logical Link 🙈. Appendix C talks about shortcut suppression and briefly reviews how flow detection might relate to mapping flows onto SVCs with different quality-of-service levels in the future 🍓.

IPv6 has the concept of on-link and off-link 👀. Neighbors are the nodes that count as on-link, which means their link-layer addresses can be found using Neighbor Discovery. Borrowing the definitions from the ND text:

on-link   - an address that is assigned to a neighbor's interface on
            a shared link.  A host considers an address to be on-
            link if:
              - it is covered by one of the link's prefixes, or
              - a neighboring router specifies the address as the
                target of a Redirect message, or
              - a Neighbor Advertisement message is received for the
                target address, or
              - a Neighbor Discovery message is received from the
                address.

off-link  - the opposite of "on-link"; an address that is not
            assigned to any interfaces attached to a shared link.

Off-link nodes are considered to only be accessible through one of the routers directly attached to the link 🛣️.

NBMA messes with the meaning of 'link' in pretty much the same way it messed with 'subnet' in IPv4 🙃. For IPv4, that meant defining the Logical IP Subnet (LIS), which is an administratively constructed set of hosts that share the same routing prefixes (network and subnetwork masks).

This document treats the IPv6 version of that idea as a Logical Link (LL) ✨.

An LL consists of nodes administratively configured to be 'on
link' with respect to each other.

The members of an LL are an IPv6 interface's initial set of
neighbors, and each interface's Link Local address only needs to
be unique amongst this set.

Here's a fun detail: members of an LL are IPv6 Neighbors, but Neighbors can also exist that aren't administratively members of the same LL 🤯.

Neighbor Discovery events can grow an IPv6 interface's set of Neighbors. However, that does not change the set of interfaces that make up its LL 📈. That leaves three possible relationships between any two IPv6 interfaces:

  • On LL, Neighbor.
  • Off LL, Neighbor.
  • Off LL, not Neighbor.

Off LL Neighbors are the 'shortcut' connections 🚀. They're the cases where it's been confirmed that direct connectivity at the NBMA level is possible to a target that isn't a member of the source's LL.

Neighbors discovered through unsolicited messages, such as Redirects, are called 'Transient Neighbors' 🦋.

3. Intra-LL and Inter-LL Discovery 🔎

This document draws a line between discovering neighbors within a Logical Link (intra-LL) and discovering neighbors beyond the LL (inter-LL) 💖. The goal is that both intra- and inter-LL neighbor discovery need zero changes to the host-side IPv6 stack for NBMA interfaces 🙌.

Heads up: section 1.3.1 applies when the NBMA network is only being used to provide configured point to point (PVC) service ⚠️.

3.1. Intra-LL - ND over emulated multicast 📡

The basic model of ND assumes that a link layer interface will do something meaningful with an ICMPv6 packet sent to a multicast IP destination address. (IPv6 assumes that multicasting is an integral part of the Internet service 🌐.) This document assumes multicast support will be provided using the RFC 2022 (MARS) [5] service, generalized for use over other NBMA technologies in addition to ATM. An IPv6 LL maps directly onto an IPv6 MARS Cluster, the same way an IPv4 LIS maps directly onto an IPv4 MARS Cluster 🗺️.

The goal of intra-LL operation is that the IPv6 layer can just pass multicast ICMPv6 packets down to the IPv6/NBMA driver without any special, NBMA-specific processing 🧼. The underlying mechanism for distributing Neighbor Discovery and Router Discovery messages then works as expected ✅.

Section 3.1.1 describes the extra functionality that SHALL be required of any MARS used in conformance with this document 📋. Background discussion of these additions is in Appendix B.

3.1.1. Mandatory augmented MARS and MARS Client behavior 🧩

IPv6/NBMA interfaces SHALL register as MARS Cluster members as described in section 4.1, and SHALL send certain classes of outgoing IPv6 packets directly to their local MARS as described in section 4.4.2 📬.

The MARS itself SHALL then re-transmit these packets according to the following rules:

  • When the MARS receives an IPv6 packet, it scans the group membership database to find the NBMA addresses of the IPv6 destination group's members.
  • The MARS then checks to see if every group member currently has its pt-pt control VC open to the MARS. If so, the MARS sends a copy of the data packet directly to each group member over the existing pt-pt VCs.
  • If one or more of the discovered group members do not have an open pt-pt VC to the MARS, or if there are no group members listed, the packet is sent out ClusterControlVC instead. No copies of the packet are sent over the existing (if any) pt-pt VCs.

3.2. Inter-LL - Redirects, and their generation 🏹

Shortcut connections are justified because demanding flows of IP packets may exist between source/destination pairs that are separated by IP routing boundaries 💥. Shortcuts get created between Transient Neighbors 🦋.

The key to creating transient neighbors is the Redirect message (section 8 [7]) 🔑. IPv6 lets a router tell the members of an LL that there's a better 'first hop' to a given destination (section 8.2 [7]) 👉. The advertisement itself happens through a Router Redirect message, which may carry the link layer address of that better hop 📨.

A transmitting host only listens to Router Redirects from the router that is currently acting as the default router for the IP destination the Redirect refers to 👂. If a Redirect arrives that indicates a better first hop for a given destination, and supplies a link layer (NBMA) address to use as that better first hop, the associated Neighbor Cache entry in the source host gets updated and its reachability set to STALE 🔄. Updating the cache in this context involves building a new VC to the new NBMA address 🛠️. If that works, the old VC only gets torn down if it is no longer required, since the old VC went to the router and may still be needed by other packets from the host that are heading to the router 🧹.

Two mechanisms are provided for triggering the discovery of a better first hop 🎯:

  • Router-based flow identification/detection.
  • Host-initiated shortcut request.

Section 3.2.1 discusses flow-based triggers, section 3.2.2 discusses the host-initiated trigger, and section 3.2.3 discusses using NHRP to discover mappings for IPv6 targets in remote LLs 🧭.

3.2.1. Flow Triggered Redirection 🌊

Changing forwarding paths based on dynamic detection of IP packet flows is at the core of models like the Cell Switch Router [11] and the IP Switch [12] 🔀. Responsibility for detecting flows gets placed into the routers, where packets cross the edges of IP routing boundaries 🚪.

For the purpose of conformance with this document, a router MAY choose to initiate the discovery of a better first hop when it determines that an identifiable flow of IP packets is passing through it 🕵️.

Such a router:

  • SHALL only track flows that originate from a directly attached host (a host that is within the LL-local scope of one of the router's interfaces).
  • SHALL NOT use IP packets arriving from another router to trigger the generation of a Router Redirect.
  • SHALL only consider IPv6 packets with FlowID of zero for the purposes of flow detection as defined in this section.
  • SHALL utilize NHRP as described in section 3.2.3 to ascertain a better first hop when a suitable flow is detected, and advertise the information in a Router Redirect.

IPv6 routers that support the OPTIONAL flow detection behavior described above SHALL support administrative mechanisms to switch off flow-detection 🔧. They MAY provide mechanisms for adding additional constraints to the categories of IPv6 packets that constitute a 'flow' 🎛️.

The actual algorithms for deciding what sequence of IPv6 packets constitutes a 'flow' are outside the scope of this document 🤷‍♀️. Appendix C discusses the rationale behind using a non-zero FlowID to suppress flow detection 💜.

3.2.2 Host Triggered Redirection 🦋

okay so a source host MAY also trigger a redirection to a transient neighbor 💅 which means the host can be the one who kicks off the whole shortcut thing 🫶 to make that work, routers that follow this document SHALL recognize certain Neighbor Solicitation messages sent by hosts as requests to resolve off-link addresses 🔥

to do a host-triggered redirect, a source host SHALL:

  • Create a Neighbor Solicitation message that refers to the off-LL destination (target) it wants a shortcut to ✨
  • Address the NS message to the router that would be the next hop for traffic heading toward the off-LL target (instead of the target's solicited node multicast address) 🎀
  • Use the standard ND hop limit of 255 so the router won't discard the NS 🧚
  • Include the shortcut limit option defined in appendix D. The value of this option should equal the hop limit of the data flow this trigger is being sent for, so the router can keep the shortcut attempt from going past the reach of that flow 💜
  • Forward the NS packet to the router that would be the next hop for traffic heading toward the off-LL target 🌸

Routers SHALL consider a unicast NS with shortcut limit option as a request for a host-triggered redirect. However, actual shortcut discovery is OPTIONAL for IPv6 routers 🙈

when shortcut discovery is not supported, the router SHALL construct a Redirect message identifying the router itself as the best 'shortcut', and return it to the soliciting host 💀

if shortcut discovery is supported, the router's response SHALL be:

  • A suitable NHRP Request is constructed and sent as described in section 3.2.3. The original NS message SHOULD be discarded.
  • Once the NHRP Reply is received by the originating router, the router SHALL construct a Redirect message containing the IPv6 address of the transient neighbor, and the NBMA link layer address returned by the NHRP resolution process.
  • The resulting Redirect message SHALL then be transmitted back to the source host. When the Redirect message is received, the source host SHALL update its Neighbor and Destination caches.
  • The off-LL target is now considered a Transient Neighbor. The next packet sent to the Transient Neighbor will result in the creation of the direct, shortcut VC (to the off-LL target itself, or to the best egress router towards that neighbor as determined by NHRP) ⭐
  • If a NHRP NAK or error indication is received for a host-triggered shortcut attempt, the requesting router SHALL construct a Redirect message identifying the router itself as the best 'shortcut', and return it to the soliciting host.

3.2.3 Use of NHRP between routers. 🌈

once flow detection has happened, or a host trigger has been detected, routers SHALL use NHRP in an NHS to NHS mode to establish the IPv6 to link level address mapping of a better first hop 🦋

IPv6/NBMA routers supporting shortcut discovery will need to perform some or all of the following functions:

  • Construct NHRP Requests and Replies.
  • Parse incoming NHRP Requests and Replies from other NHSes (routers).
  • Forward NHRP Requests towards an NHS that is topologically closer to the IPv6 target.
  • Forward NHRP Replies towards an NHS that is topologically closer to the requester.
  • Perform syntax translation between Neighbor Solicitations and outbound NHRP Requests.
  • Perform syntax translation between inbound NHRP Replies and Redirects.

the destination of the flow that caused the trigger (or the target of the host initiated trigger) is used as the target for resolution in a NHRP Request. The router then forwards this NHRP Request to the next closest NHS. The process continues (as it would for normal NHRP) until the Request reaches an NHS that believes the IP target is within link-local scope of one of its interfaces. (This may potentially occur within a single router.) 🧚

as NHRP resolution requests always follow the routed path for a given target protocol address, the scope of a shortcut request will be automatically bounded to the scope of the IPv6 target address. (e.g. resolution requests for site-local addresses will not be forwarded across site boundaries.) 🔒

the last hop router SHALL resolve the NHRP Request from mapping information contained in its neighbor cache for the interface on which the specified target is reachable. If there is no appropriate entry in the Neighbor cache, or the destination is currently considered unreachable, the last hop router SHALL perform Neighbor Discovery on the local interface, and build the NHRP Reply from the resulting answer. (Note, in the case where the NHRP Request originated due to flow detection, there must already be a hop-by-hop flow of packets going through the last hop router towards the target. In this typical case the Neighbor cache will already have the desired information.) 💅

the NHRP Reply is propagated back to the source of the NHRP Request, using a hop-by-hop path as it would for normal NHRP.

if the discovery process was triggered through flow detection at the originating router, the return of the NHRP Reply results in the following events:

  • A Redirect is constructed using the IPv6/NBMA mapping carried in the NHRP Reply.
  • The Redirect is unicast to the IP packet flow's source (using the VC on which the flow is arriving at the router, if it is a bi-directional pt-pt VC).
  • Any Redirect message sent by a router MUST conform to all the rules described in [7] so that the packet is properly validated by the receiving host. Specifically, if the target of the resulting short-cut is the destination host then the ICMP Target Address MUST be the same as the ICMP Destination Address in the original message. If the target of the short-cut is an egress router then the ICMP Target Address MUST be a Link Local address of the egress router that is unique to the NBMA cloud to which the router's NBMA interface is attached.
  • Also note that egress routers may subsequently redirect the source host. To do so, the Link Local ICMP Source Address of the Redirect message MUST be the same as the Link Local ICMP Target Address of the original Redirect message.

note that the router constructing the NHRP Reply does so using the NBMA address returned by the target host when the target host first accepted the flow of IP traffic. This retains a useful feature of Neighbor Discovery - destination interface load sharing. ✨

upon receipt of a NHRP NAK reply or error indication for a flow-triggered shortcut attempt, no indication is sent to the source of the flow. 🫶

3.2.3.1 NHRP/ND packet translation rules. 🎀

the following translation rules are meant to augment the packet format specification in section 5 of the NHRP specification [8], covering those packet fields specifically utilized by the IPv6/NBMA architecture.

NHRP messages are constructed and sent according to the rules in [8]. The value of the NBMA technology specific fields such as ar$afn, ar$pro.type, ar$pro.snap and link layer address format are defined in NBMA-specific companion documents. Source, destination or client protocol addresses in the common header or CIE of a NHRP message are always IPv6 addresses of length 16. 🌸

when constructing a host-triggered NHRP resolution request in response to a Neighbor Solicitation:

  • The ar$hopcnt field MUST be smaller than the shortcut limit value specified in the shortcut limit option included in the triggering NS message. This ensures that hosts have control over the reach of their shortcut request. Note that the shortcut limit given in the option is relative to the requesting host, thus the requirement of ar$hopcnt being smaller than the given shortcut limit.
  • The Flags field in the common header of the NHRP resolution request SHOULD have the Q and S bits set.
  • The U bit SHOULD be set. NBMA and protocol source addresses are those of the router constructing the request.
  • The target address from the NS message is used as the NHRP destination protocol address. A CIE SHALL NOT be specified.

when constructing a NHRP resolution request as a result of flow detection, the choice of values is configuration dependent.

a NHRP resolution reply is build according to the rules in [8].

  • For each CIE returned, the holding time is 10 minutes.
  • The MTU may be 0 or a value specified in the NBMA-specific companion document.

a successful NHRP resolution reply for a host-triggered shortcut attempt is translated into an IPv6 Redirect message as follows:

IP Fields:

  • Source Address: The link-local address assigned to the router's interface from which this message is sent.
  • Destination Address: IPv6 Source Address of the triggering NS
  • Hop Limit: 255

ICMP Fields:

  • Target Address: NHRP Client Protocol Address
  • Destination Address: Target of triggering NS (this is equivalent to the NHRP Destination Protocol Address)
  • Target link-layer address: NHRP Client NBMA Address

all NHRP extensions currently defined in [8] have no effect on NHRP/ND translation and MAY be used in NHRP messages for IPv6. 🌈

3.2.3.2 NHRP Purge rules. 💜

purges are generated by NHRP when changes are detected that invalidate a previously issued NHRP Reply (this may include topology changes, or a target host going down or changing identity). Any IPv6 shortcut previously established on the basis of newly purged information SHOULD be torn down. 💀

Routers SHALL keep track of NHRP cache entries for which they have issued Neighbor Advertisements or Router Redirects. If a NHRP Purge is received that invalidates information previously issued to local host, the router SHALL issue a Router Redirect specifying the router itself as the new best next-hop for the affected IPv6 target. 🦋

Routers SHALL keep track of Neighbor cache entries that have previously been used to generate an NHRP Reply. The expiry of any such Neighbor cache entry SHALL result in a NHRP Purge being sent towards the router that originally requested the NHRP Reply. ✨

3.3. Neighbor Unreachability Detection. 🧚

Neighbor Solicitations sent for the purposes of Neighbor Unreachability Detection (NUD) are unicast to the Neighbor in question, using the VC that is already open to that Neighbor. This suggests that as far as NUD is concerned, the Transient Neighbor is indistinguishable from an On-LL Neighbor. 👑

3.4. Duplicate Address Detection. 🫶

Duplicate Address Detection is only required within the link-local scope, which in this case is the LL-local scope. Transient Neighbors are outside the scope of the LL. No particular interaction is required between the mechanism for establishing shortcuts and the mechanism for detection of duplicate link local addresses. 🌸

4. Node Operation Concepts ✨

okay bestie, this section is all about the basic moves a node makes on a Logical Link, like sending and receiving data 📬 How all of this gets used by IPv6 stuff like Neighbor Discovery is in Appendix A 🧚

heads up: most of this section is only for NBMA networks being used to give you point to point and point to multipoint SVCs 🦋 If your NBMA network is only handing you point to point PVCs, that's covered in Section 7 💅

before a node can send or receive IPv6 datagrams, its underlying IPv6/NBMA interface(s) have to join a Logical Link first 🎀

An IPv6/NBMA driver SHALL set up a pt-pt VC to the MARS for its Logical Link and sign up as a Cluster Member [5] 🫶 Once that's done, the node's IPv6/NBMA interface is officially a member of the LL, gets a Cluster Member ID (CMI), and can start supporting IPv6 and IPv6 ND operations 🔥

If the node is a host or router that's just starting up, it SHALL send a single group MARS_JOIN for these groups:

  • Its derived Solicited-node address(es) with link-local scope.
  • The All-nodes address with link-local scope.
  • Other configured multicast groups with at least link-local scope.

If the node is a router, it SHALL additionally issue:

  • A single group MARS_JOIN for the All-routers address with link-local scope.
  • A block MARS_JOIN for the range(s) of IPv6 multicast addresses (with greater than link-local scope) for which promiscuous reception is required.

The encapsulation mechanism for, and key field values of, MARS control messages SHALL be defined in companion documents specific to particular NBMA network technologies 📚

4.2. Joining a Multicast Group.

this section describes what the node does when it gets a JoinLocalGroup request from the IPv6 Layer 🧩 How that actually happens is up to each implementation 🛠️

If a JoinLocalGroup for a node-local address is received, the IPv6/NBMA driver SHALL return a success indication to the caller and take no additional action. (Packets sent to node-local addresses never reach the IPv6/NBMA driver. 🙈)

If a JoinLocalGroup is received for an address with greater than node-local scope, the IPv6/NBMA driver SHALL send an appropriate single group MARS_JOIN request to register this address with the MARS 💌

4.3. Leaving a Multicast Group.

this one is the mirror image of joining 🪞 It describes what the node does when it gets a LeaveLocalGroup request from the IPv6 Layer, and the details are implementation specific 🌸

If a LeaveLocalGroup for a node-local address is received, the IPv6/NBMA driver SHALL return a success indication to the caller and take no additional action. (Packets sent to node-local addresses never reach the IPv6/NBMA driver. 🙈)

If a LeaveLocalGroup is received for an address with greater than node-local scope, the IPv6/NBMA driver SHALL send an appropriate single group MARS_LEAVE request to deregister this address with the MARS 👋

4.4. Sending Data.

unicast and multicast packets get different processing and encapsulation rules, so we're splitting them up 💕

4.4.1. Sending Unicast Data.

the IP level 'next hop' for each outbound unicast IPv6 packet is what picks out the pt-pt VC to forward the packet on 🦋

for NBMA networks where LLC/SNAP encapsulation is typically used (e.g. ATM or SMDS), the IPv6 packet SHALL be encapsulated with the following LLC/SNAP header and sent over the VC ✨

[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
    (LLC)       (OUI)     (PID)

for NBMA networks that don't use LLC/SNAP encapsulation, an alternative rule SHALL be specified in the NBMA-specific companion document 📖

if there's no pt-pt VC for the next hop address, the node SHALL place a call to set up a VC to that next hop destination 📞 Every time the IPv6/NBMA driver gets a unicast packet to send, the IPv6 layer has already figured out the link-layer (NBMA) address of the next hop, so all the info needed to place that NBMA call is ready to go 🙌

the sending node SHOULD queue the packet that triggered the call request and send it once the call is established 🍓

if the call to the next hop destination node fails, the sending node SHALL discard the packet that triggered the call setup 💀 Persistent failure to create a VC to the next hop destination gets caught and handled at the IPv6 Network Layer through NUD 🕵️‍♀️

at this time, no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address 🤷‍♀️

4.4.2. Sending Multicast Data.

the IP level 'next hop' for each outbound multicast IPv6 packet is what picks out a pt-pt or pt-mpt VC to forward the packet on 🌈

for NBMA networks where LLC/SNAP encapsulation is typically used (e.g. ATM or SMDS), multicast packets SHALL be encapsulated like this 🎀

[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6
packet]
    (LLC)       (OUI)     (PID)    (mars encaps)

the IPv6/NBMA driver's Cluster Member ID SHALL be copied into the 2 octet pkt$cmi field before it gets sent 🫧

for NBMA networks that don't use LLC/SNAP encapsulation, an alternative rule SHALL be specified in the NBMA-specific companion document. Some mechanism for carrying the IPv6/NBMA driver's Cluster Member ID SHALL be provided 🧠

if the packet's destination is one of these multicast addresses, it SHALL be sent over the IPv6/NBMA driver's direct pt-pt VC to the MARS 📮

  • A Solicited-node address with link-local scope.
  • The All-nodes address with link-local scope.
  • The All-routers address with link-local scope.
  • A DHCP-v6 relay or server multicast address.

The MARS SHALL then redistribute the IPv6 packet as described in section 3.1.1. (If the VC to the MARS has been idle timed out for some reason, it MUST be re-established before forwarding the packet to the MARS. ⏰)

if the packet's destination is any other address, the usual MARS client mechanisms are used by the IPv6/NBMA driver to select and/or establish a pt-mpt VC for the packet 🌟

at this time, no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address 💅

4.5. Receiving Data.

okay, receiving time 📥 Packets that come in using the unicast encapsulation from section 4.4.1 SHALL be de-encapsulated and passed up to the IPv6 layer, and then the IPv6 layer decides what to do with them 👑

packets that come in using the multicast encapsulation from section 4.4.2 SHALL have their pkt$cmi field compared to the local IPv6/NBMA driver's own CMI 🔍 If the pkt$cmi in the header matches the local CMI, the packet SHALL be silently dropped 🤫 Otherwise, the packet SHALL be de-encapsulated and passed to the IPv6 layer, which then decides how to handle it 💖

for NBMA networks that don't use LLC/SNAP encapsulation, alternative rules SHALL be specified in the NBMA-specific companion document 📚

the IPv6/NBMA driver SHALL NOT attempt to filter out multicast IPv6 packets that arrive with the encapsulation defined for unicast packets, and it SHALL NOT attempt to filter out unicast IPv6 packets that arrive with the encapsulation defined for multicast packets 🙅‍♀️

4.6. VC Setup and release for unicast data.

unicast VCs are kept separate from multicast VCs 🦋 The MARS client in each IPv6/NBMA driver [5] handles setting up and maintaining the multicast VCs, so here we only cover pt-pt VCs for unicast IPv6 traffic 🎀 Only best effort unicast VCs are considered, and making VCs for other classes of service is outside the scope of this document 🌸

before sending a packet to a new destination within the same LL, a node will first do a Neighbor Discovery on the intra-LL target 🔎 That's how the IPv6 destination address gets resolved into a link-layer address the sender can use to send unicast packets ✨

Appendix A.1.1 has non-normative, descriptive text covering the Neighbor Solicitation/Advertisement exchange and how a new SVC eventually gets set up 💫

a Redirect message (whether it points to a node on the same LL or is a shortcut redirect to a node outside the LL) makes the sending (redirected) node create a new pt-pt VC to a new receiving node 🦋 The Redirect message SHALL contain the link layer (NBMA) address of the new receiving IPv6/NBMA interface 📬 The redirected node doesn't care where the new receiving node sits on the NBMA network 🙃 If a pt-pt VC to the new node doesn't already exist, the redirected node sets one up, and then uses the new VC to send data instead of whatever VC it was using before 🚀

Redirects are unidirectional, bestie 🙈 Even after the source reacts to a redirect, the destination keeps sending IPv6 packets back to the redirected node on the old path. That's because the destination node has no way of figuring out the IPv6 address of the other end of a new VC without Neighbor Discovery. So redirects will not result in both ends of a connection using the new VC. IPv6 redirects aren't meant to give you symmetrical redirection 😭 If the non-redirected node eventually gets a redirect, it MAY discover the existing VC to the target node and use that instead of creating a new VC 🧚

it's desirable that VCs get released when they're no longer needed 🧹

  • An IPv6/NBMA driver SHALL release any VC that has been idle for 20 minutes.

This time limit MAY be reduced through configuration or as specified in companion documents for specific NBMA networks ⚙️

if a Neighbor or Destination cache entry gets purged, any VCs associated with the purged entry SHOULD be released 🗑️

if the state of an entry in the Neighbor cache is set to STALE, any VCs associated with the stale entry SHOULD be released 💜

4.7. NBMA SVC Signaling Support and MTU issues.

mechanisms for signaling the setup and teardown of pt-pt and pt-mpt SVCs for different NBMA networks SHALL be specified in companion documents 📣

since any given IPv6/NBMA driver won't know whether the remote end of a VC is in the same LL, drivers SHALL implement NBMA-specific mechanisms to negotiate acceptable MTUs at the VC level. These mechanisms SHALL be specified in companion documents 📏

that said, IPv6/NBMA drivers can assume they'll always be talking to another driver attached to the same type of NBMA network 🤝 (For example, an IPv6/NBMA driver doesn't need to consider the possibility of establishing a shortcut VC directly to an IPv6/FR driver. 🙃)

5.1 Interface Tokens 🎀

Okay bestie, every IPv6 interface has to have an interface token so it can build its autoconfigured addresses 💅. That token has to be unique within a Logical Link, or you end up with duplicate addresses when stateless address configuration is in use 😭.

If two nodes on the same LL come up with the same interface token, one of them MUST choose another host-token 🙈. All implementations MUST support manual configuration of interface tokens, so operators can change an interface token by hand on a per-LL basis ✨. Operators may choose to set tokens manually for reasons other than getting rid of duplicate addresses 🦋.

All interface tokens MUST be 64 bits long and formatted the way the following sections describe 🌸. Host tokens are based on the format of an EUI-64 identifier [10]. Check out [19 - Appendix A] for how to create IPv6 EUI-64 based interface identifiers 🧚.

Physical NBMA interfaces usually have some local identifier that can be used to build a unique IPv6/NBMA interface token 🍓. The exact way to generate those tokens SHALL be specified in companion documents for each NBMA network 💜.

Okay so, a physical NBMA interface MAY be used to provide multiple logical NBMA interfaces 🌈. Since each logical NBMA interface MAY support an independent IPv6 interface, there are two possible scenarios 👑:

  • A single host with separate IPv6/NBMA interfaces onto a number of independent Logical Links.
  • A set of 2 or more 'virtual hosts' (vhosts) sharing a common NBMA driver. Each vhost is free to set up IPv6/NBMA interfaces tied to different or shared LLs. However, vhosts are held to the same rule as normal hosts: no two interfaces to the same LL can share the same interface token 🔥.

In the first scenario, every IPv6/NBMA interface belongs to a different LL, so each one's external identity can be told apart by the LL's routing prefix ✨. That means the host can reuse one unique interface token across all of its IPv6/NBMA interfaces 🫶. (Internally, the host will tag received packets in some locally specific way so it knows which IPv6/NBMA interface they came in on. That's a generic IPv6 thing, though, so this document doesn't need to cover it 💅.)

The second scenario is more complicated, but probably rarer 🙈.

When a physical NBMA interface is supporting multiple logical NBMA interfaces, independent and unique identifiers SHALL be generated for each virtual NBMA interface, so unique IPv6/NBMA interface tokens can be built 🦋. The exact way to generate those tokens SHALL be specified in companion documents for each NBMA network 💖.

Neighbor Discovery defines two option fields for carrying link-layer specific source and target addresses 🧚.

Between IPv6/NBMA interfaces, the format of these two options is adapted from the MARS [5] and NHRP [8] specs 🎀. It SHALL look like this:

          [Type][Length][NTL][STL][..NBMA Number..][..NBMA
          Subaddress..]
          |   Fixed    ||            Link layer address
          |

[Type] is a one octet field 🍓.

          1 for Source link-layer address.
          2 for Target link-layer address.

[Length] is a one octet field 💜.

The total length of the option, in multiples of 8 octets. Zeroed bytes get added to the end of the option so its length is a multiple of 8 octets 🌈.

[NTL] is a one octet 'Number Type & Length' field 👑.

[STL] is a one octet 'SubAddress Type & Length' field 🔥.

[NBMA Number] is a variable length field, and it is always present ✨. It holds the primary NBMA address 🫶.

[NBMA Subaddress] is a variable length field, and it may or may not be present 🦋. It holds any NBMA subaddress that might be needed 🌸.

If the [NBMA Subaddress] isn't present, the option ends right after the [NBMA Number] (plus any extra padding for 8 byte alignment) 💅.

The contents and interpretation of the [NTL], [STL], [NBMA Number], and [NBMA Subaddress] fields are specific to each NBMA network, and they SHALL be specified in companion documents 💖.

The IPv6 link-local address is formed by appending the interface token, as defined above, to the prefix FE80::/64 ✨.

          10 bits            54 bits                  64 bits
      +----------+-----------------------+----------------------------+
      |1111111010|         (zeros)       |      Interface Token       |
      +----------+-----------------------+----------------------------+

6. Conclusion and Open Issues 🦋

This document describes a general architecture for IPv6 over NBMA networks 🌸. It's the foundation for companion documents that give the details for specific NBMA technologies (like ATM or Frame Relay) 💅. The IPv6 over NBMA architecture keeps conventional host-side operation of the IPv6 Neighbor Discovery protocol, and it also supports setting up 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available 🔥.

The IPv6 "Link" is generalized to "Logical Link" in a way that's analogous to the IPv4 "Logical IP Subnet" 🧚. The MARS protocol is extended and used to give relatively efficient intra Logical Link multicasting of IPv6 packets, plus distribution of Discovery messages 🎀. Shortcut NBMA level paths are supported either through router based flow detection or host originated explicit requests 🌈. Neighbor Discovery is used without modification for all intra-LL control, including starting NBMA shortcut discovery 👑. Router to router NHRP is used to get the IPv6/NBMA address mappings for shortcut targets outside a source's Logical Link 💖.

7. Security Considerations 🔥

This architecture doesn't introduce any new protocols. It depends on existing protocols (NHRP, IPv6, ND, MARS), so it's subject to all the security threats that come with those protocols 😭. This architecture should not be used in a domain where any of the base protocols are considered unacceptably insecure 🚨. Still, this protocol itself doesn't add any extra security threats ✨.

While this proposal doesn't bring in any new security mechanisms, all current IPv6 security mechanisms will work for NBMA without modification 🫶. That includes authentication and encryption, for both the Neighbor Discovery protocols and the exchange of IPv6 data packets 🔐. The MARS protocol is modified in a way that doesn't affect or add to the security offered by RFC 2022 💅.

Acknowledgments 💜

Eric Nordmark confirmed the usefulness of ND Redirect messages in private email during the March 1996 IETF 🌸. The discussions with various ION WG members during the June and December 1996 IETFs helped solidify the architecture described here 🧚. Grenville Armitage's original work on IPv6/NBMA happened while he was employed at Bellcore 👑. Elements of section 5 were borrowed from Matt Crawford's memo on IPv6 over Ethernet 🎀.

Authors' Addresses ✨

Grenville Armitage
Bell Laboratories, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
USA

EMail: gja@lucent.com
Peter Schulter
Bright Tiger Technologies
125 Nagog Park
Acton, MA 01720

EMail: paschulter@acm.org
Markus Jork
European Applied Research Center
Digital Equipment GmbH
CEC Karlsruhe
Vincenz-Priessnitz-Str. 1
D-76131 Karlsruhe
Germany

EMail: jork@kar.dec.com
Geraldine Harter
Digital UNIX Networking
Compaq Computer Corporation
110 Spit Brook Road
Nashua, NH 03062

EMail: harter@zk3.dec.com

References 📚

[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[2] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995.

[3] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996.

[4] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.

[5] Armitage, G., "Support for Multicast over UNI 3.1 based ATM Networks", RFC 2022, November 1996.

[6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.

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

[8] Luciani, J., Katz, D., Piscitello, D. Cole B and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

[9] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.

[10] "64-Bit Global Identifier Format Tutorial", http://standards.ieee.org/db/oui/tutorials/EUI64.html.

[11] Katsube, Y., Nagami, K. and H. Esaki, "Toshiba's Router Architecture Extensions for ATM : Overview", RFC 2098, February 1997.

[12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM under IP", Proceedings of INFOCOM'96, San Francisco, March 1996, pp.1251-1260

[13] Piscitello, D. and J. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, March 1991.

[14] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.

[15] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

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

[17] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.

[18] C. Perkins, J. Bound, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress.

[19] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.

Appendix A. IPv6 Protocol Operation Description 🧚

The IPv6 over NBMA model described in this document keeps the complete semantics of the IPv6 protocols 💖. No changes need to be made to the IPv6 Network Layer 🌈. Since the concept of the security association isn't changing for NBMA, this framework keeps full IPv6 security semantics and features 🔐. That lets IPv6 nodes choose their responses to solicitations based on security information, the same way they do with other datalinks 🫶. It also keeps the semantics of Neighbor Discovery intact, since it's always the solicited node that decides what (and even whether) to reply to a solicitation 👑. So NBMA stays transparent to the network layer, except where extra services (such as QoS VCs) are offered ✨.

The rest of this Appendix describes how the core IPv6 protocols will operate within the model described here 🌸.

A.1 Neighbor Discovery Operations 🎀

Before doing any sort of Neighbor discovery operation, each node must first join the all-node multicast group, and its solicited node multicast address (how this address is used with DAD is described in A.1.4) 💅. The IPv6 network layer will join these multicast groups as described in 4.2 🦋.

A.1.1 Performing Address Resolution ✨

okay so an IPv6 host does address resolution by sending a Neighbor Solicitation to the solicited-node multicast address of the target host, as described in [7] 💌 The Neighbor Solicitation message will contain a Source Link-Layer Address Option set to the soliciting node's NBMA address on the LL. the main character energy here is obvious 💅

when the local node's IPv6/NBMA driver gets the Neighbor Solicitation from the IPv6 network layer, it follows the steps in section 4.4.2 Sending Multicast Data 🦋

one or more nodes will receive the Neighbor Solicitation. they process the data as described in section 4.5 and pass the de-encapsulated packets up to the IPv6 network layer 🫶

if the receiving node is the target of the Neighbor Solicitation, it updates its Neighbor cache with the soliciting node's NBMA address. that address comes from the Source Link-Layer Address Option in the Neighbor Solicitation, as described in [7] 🌸

the solicited IPv6 host responds to the Neighbor Solicitation with a Neighbor Advertisement sent to the IPv6 unicast address of the soliciting node 💖 the Neighbor Advertisement will contain a Target Link-Layer Address Option set to the solicited node's NBMA address on the LL. it's giving response era ✨

the solicited node's IPv6/NBMA driver is passed the Neighbor Advertisement along with the soliciting node's link-layer address from the IPv6 network layer. it then follows the steps in section 4.4.1 to send the NA message to the soliciting node. this creates a pt-pt VC between the solicited node and the soliciting node, if one didn't already exist 🧚

the soliciting node then receives the Neighbor Advertisement over the new PtP VC, de-encapsulates it, and passes it to the IPv6 network layer for processing as described in section 4.5. after that it makes the right entries in its Neighbor cache, including caching the NBMA link-layer address of the solicited node as described in [7] 🎀

at this point each system has a complete Neighbor cache entry for the other one 🥹 they can exchange data over the pt-pt VC that the solicited node made when it returned the Neighbor Advertisement, or they can create a new VC. iconic behaviour, honestly 👑

an IPv6 host can also send an Unsolicited Neighbor Advertisement to the all-nodes multicast address 📣 when the local node's IPv6/NBMA driver gets the Neighbor Advertisement from the IPv6 network layer, it follows the steps in section 4.4.2 to send the NA to the all-nodes multicast address. every node processes the incoming packet as described in section 4.5, then passes it up to the IPv6 network layer, where it's processed as described in [7] 🌈

A.1.2 Performing Router Discovery 🧭

Router Discovery is described in [7]. to support it, an IPv6 router joins the IPv6 all-routers multicast group address 🌟 when the IPv6/NBMA driver gets the JoinLocalGroup request from the IPv6 Network Layer, it follows the process in section 4.2.

IPv6 routers periodically send unsolicited Router Advertisements to announce that they're available on the LL 📢 when a router sends one, it sends a data packet addressed to the IPv6 all-nodes multicast address. when the local node's IPv6/NBMA driver gets the Router Advertisement from the IPv6 network layer, it transmits the message by following the steps in section 4.4.2. the MARS transmits the packet on the LL's ClusterControlVC, which sends it to all nodes on the LL 🦋 each node then processes the incoming packet as described in section 4.5 and passes the received packet to the IPv6 Network layer for processing as appropriate 💅

to perform Router Discovery, an IPv6 host sends a Router Solicitation message to the all-routers multicast address 🫶 when the local node's IPv6/NBMA driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps in section 4.4.2. the RS message is sent either to the nodes that have joined the all-routers multicast group or to all nodes. the nodes that receive the RA message process it as described in section 4.5 and pass it up to the IPv6 layer for processing. only the nodes that are routers process the message and respond to it 🙈

an IPv6 router responds to a Router Solicitation by sending a Router Advertisement addressed to the IPv6 all-nodes multicast address, but only if the source address of the Router Solicitation was the unspecified address 🌸 if the source address in the Router Solicitation is not the unspecified address, the router unicasts the Router Advertisement to the soliciting node instead. if the router sends the Router Advertisement to the all-nodes multicast address, it follows the steps described above for unsolicited Router Advertisements 💜

if the Router Advertisement is going to be unicast to the soliciting node, the IPv6 network layer gives the node's IPv6/NBMA driver the Router Advertisement and the soliciting node's link-layer address. that address is obtained through Address Resolution if necessary. the driver then sends the packet according to the steps in section 4.4.1 🍓 this results in a new pt-pt VC being created between the router and the soliciting node, if one didn't already exist 🧚‍♀️

the soliciting node receives and processes the Router Advertisement as described in section 4.5 and passes the RA message to the IPv6 network layer. depending on the state of the Neighbor cache entry, the IPv6 network layer may update the Neighbor cache with the router's NBMA address, which is contained in the Source Link-Layer Address Option of the Router Advertisement message ✨

if a pt-pt VC is set up during Router Discovery, subsequent IPv6 best effort unicast data between the soliciting node and the router is transmitted over the new PtP VC 🌈

A.1.3 Performing Neighbor Unreachability Detection (NUD) 🔍

Neighbor Unreachability Detection (NUD) is the process by which an IPv6 host figures out that a neighbor is no longer reachable, as described in [7] 😭 each Neighbor cache entry holds the info that the NUD algorithm uses to detect reachability failures. a neighbor's reachability gets confirmed either by upper-layer protocol indications that data recently sent to it was received, or by receiving a Neighbor Advertisement in response to a Neighbor Solicitation probe 💖

connectivity failures at the node's IPv6/NBMA driver, like released VCs (see section 4.6) and not being able to create a VC to a neighbor (see section 4.4.1), are detected and handled at the IPv6 network layer, through Neighbor Unreachability Detection 💀 the node's IPv6/NBMA driver doesn't try to detect or recover from these conditions. not its job, bestie 🙅‍♀️

a persistent failure to create a VC from the IPv6 host to one of its IPv6 neighbors gets detected and handled through NUD 🔥 every time the IPv6 host tries to send data to that neighbor, the node's IPv6/NBMA driver tries to set up a VC to the neighbor. if that fails, it drops the packet. the IPv6 reachability confirmation timers eventually expire, and the neighbor's Neighbor cache entry enters the PROBE state. the PROBE state makes the IPv6 host unicast Neighbor Solicitations to the neighbor, but the local node's IPv6/NBMA driver drops them after failing to set up the VC again 😩 so the IPv6 host never gets the solicited Neighbor Advertisements it needs to confirm reachability, and the neighbor's entry gets deleted from the Neighbor cache. the next time the IPv6 host tries to send data to that neighbor, address resolution is performed. depending on why the previous failure happened, connectivity to the neighbor could come back (for example, if the VC setup failed because of an obsolete link-layer address in the Neighbor cache) 🦋

in the event that a VC from an IPv6 neighbor is released, the next time a packet is sent from the IPv6 host to that neighbor, the node's IPv6/NBMA driver notices it no longer has a VC to the neighbor and tries to set up a new one 🌟 if the node can't create a VC to the neighbor on the first try or on any later tries, NUD detects and handles the failure as described earlier (in the handling of a persistent failure to create a VC from the IPv6 host to one of its IPv6 neighbors) 🫠 depending on why the previous failure happened, connectivity to the neighbor may or may not come back 🤷‍♀️

A.1.4 Performing Duplicate Address Detection (DAD) 🔍

okay so before a host starts using an address, it has to check that nobody else already has it 🫶 That check is Duplicate Address Detection (DAD), and it's described in [9] and [7]. It's giving "trust but verify" energy 💅 DAD happens for every address the host wants to use, no matter how it got configured. Until DAD finishes, the address is only tentative.

Before DAD starts, the host joins the all-nodes multicast address and the solicited-node multicast address that matches its tentative address (see 4.2. Joining a Multicast Group) 🧚 Then it sends a Neighbor Solicitation to that solicited-node multicast address, with the tentative address as the target 📨 When the local node's IPv6/NBMA driver gets the Neighbor Solicitation from the IPv6 network layer, it follows the steps in section 4.4.2. The NS goes to the nodes that joined that target solicited-node multicast group, or to all nodes. One or more nodes on the LL receive the DAD NS, and each one processes it as described in section 4.5.

Quick sidebar 🙈 the MARS client of the sending node filters out the message, so the sender's own IPv6 network layer never sees it. And any node that isn't a member of the target solicited-node multicast group just discards the Neighbor Solicitation at the IPv6 network layer.

If nobody else has joined the solicited-node multicast address for that tentative address, the host won't get a Neighbor Advertisement with its tentative address as the target 🎉 So it runs the retransmission logic from [9], ends DAD, and assigns the tentative address to its NBMA interface. slay.

Otherwise, the other hosts on the LL that joined that solicited-node multicast address process the Neighbor Solicitation. What happens next depends on whether the receiving host also considers the target address to be tentative 👀

If the receiving host's address is not tentative, it responds with a Neighbor Advertisement containing the target address. Because the source of the Neighbor Solicitation is the unspecified address, the host sends the Neighbor Advertisement to the all-nodes multicast address, following the steps in section 4.4.2. The DAD NA gets received and processed by the MARS clients on all nodes in the LL, as described in section 4.5. The sending node filters the incoming message, since the CMI in the message header matches its own. All other nodes de-encapsulate the message and pass it to the IPv6 network layer. The host doing DAD notices that its tentative address is the target of the Neighbor Advertisement, so it decides the address isn't unique and can't be assigned to its NBMA interface 💔

If the receiving host's address is tentative, then both hosts are doing DAD with the same tentative address. The receiving host figures out that the address isn't unique and can't be assigned to its NBMA interface 🙅‍♀️

A.1.5 Processing Redirects 🗺️

An IPv6 router uses a Redirect Message to tell a host about a better first hop for reaching a particular destination, as described in [7] ✨ This can point hosts to a better first hop router, another host on the same LL, or a transient neighbor on another LL. The router unicasts the Redirect to the IPv6 source address that triggered it. Its IPv6/NBMA driver sends the Redirect using the procedure in section 4.4.1, which creates a VC between the router and the redirected host if one didn't already exist 🔗

The IPv6/NBMA driver of the host that triggered the Redirect receives the encapsulated Redirect over one of its pt-pt VCs. It then de-encapsulates the packet and passes the Redirect message up to the IPv6 network layer, as described in section 4.5.

Subsequent data goes to the next-hop address in the Redirect Message 🚀 For NBMA networks, the Redirect should contain the link-layer address option described in [7] and section 5.2. That way the redirected node doesn't have to do a Neighbor Solicitation to learn the link-layer address of the node it was redirected to. So the redirect can go to any node on the NBMA network, no matter its LL membership. This lets NBMA hosts get redirected off their LL to get a shortcut, using standard IPv6 protocols 💖

Once redirected, the IPv6 network layer hands the node's IPv6/NBMA driver the IPv6 packet and the link-layer address of the next-hop node whenever it sends data to the redirected destination. The driver checks whether a VC to the next-hop destination exists. If there's no pt-pt VC, the driver queues the data packet and starts setting up a VC to the destination. When the VC is created, or if one already exists, the node encapsulates the outgoing data packet and sends it on the VC.

Redirects are unidirectional 😤 The redirected host creates a VC to the next-hop destination named in the Redirect message, but the next hop doesn't get redirected back to the source host. Since no Neighbor Discovery takes place, the next-hop destination has no way to tell who is calling when it receives the new VC. Also, since ND doesn't happen on redirects, the next hop gets no event that would make it update its neighbor or destination caches. It keeps transmitting data back to the redirected host along the former path. The next-hop node should be able to use the new VC from the redirected destination if it also receives a redirect pointing it to the redirected node. This behavior is consistent with [7].

A.2 Address Configuration 🎀

IPv6 addresses are auto-configured using the stateless or stateful address auto-configuration mechanisms, as described in [9] and [18]. The process involves creating a link-local address on an LL and verifying that it's unique, deciding whether to use stateless and/or stateful configuration mechanisms to get addresses, and deciding if other (non-address) information gets auto-configured too. Addresses can also be configured manually if, for example, auto-configuration fails because the auto-configured link-local address isn't unique. An LL administrator specifies the type of auto-configuration to use, and the hosts on an LL receive this info through Router Advertisement messages 📻

The following sections describe how stateless, stateful and manual address configuration work in an IPv6/NBMA environment 🌸

A.2.1 Stateless Address Configuration 🦋

Stateless address configuration is the process where an IPv6 host auto-configures its interfaces, as described in [IPV6-ADDRCONF] 🧚

When an IPv6 host first starts up, it generates a link-local address for the interface attached to the Logical Link. Then it verifies that the link-local address is unique using Duplicate Address Detection (DAD). If the host detects that the link-local address isn't unique, the auto-configuration process terminates, and the host must then be manually configured 😭

Once the host determines the link-local address is unique and has assigned it to the interface on the Logical Link, it performs Router Discovery to get auto-configuration info ✨ It sends out a Router Solicitation and either receives a Router Advertisement or waits for an unsolicited Router Advertisement. It processes the M and O bits of the Router Advertisement as described in [9], and as a result may invoke stateful auto-configuration 🧠

If there are no routers on the Logical Link, the host can still talk to other IPv6 hosts on that link using link-local addresses 💜 It gets a neighbor's link-layer address using Address Resolution. It will also attempt to invoke stateful auto-configuration, unless it has been explicitly configured not to do so.

A.2.2 Stateful Address Configuration (DHCP) 💌

okay so IPv6 hosts use DHCPv6 (the Dynamic Host Configuration Protocol) for stateful address auto-configuration 🎀, as described in [18]. it's giving organized ✨

A DHCPv6 server or relay agent lives on a Logical Link that's been set up with manual or stateful auto-configuration 🏠. The server or relay agent joins the IPv6 DHCPv6 Server/Relay-Agent multicast group on that link. When the node's IPv6/NBMA driver gets the JoinLocalGroup request from the IPv6 network layer, it follows the process in section 4.2 💅.

An IPv6 host kicks off stateful auto-configuration if the M and O bits in Router Advertisements say it should 👑. It may also start it if it notices that no routers are on the Logical Link 🫶. A host that gets its config through the stateful mechanism is from then on called a DHCPv6 client 🦋.

A DHCPv6 client sends a DHCPv6 Solicit message to the DHCPv6 Server/Relay-Agent multicast address to find a DHCPv6 Agent 🔍. When the soliciting node's IPv6/NBMA driver gets the request from the IPv6 Network Layer to send the packet, it follows the steps in section 4.4.2 ✨. That means one or more nodes on the LL will receive the message. Each node that gets the solicitation processes it as described in section 4.5 💜. Only the IPv6 network layer of the DHCPv6 server/relay-agent accepts the packet and processes it 🙈.

A DHCPv6 Server or Relay Agent on the Logical Link unicasts a DHCPv6 Advertisement back to the DHCPv6 client 💖. The IPv6 network layer hands the node's IPv6/NBMA driver the packet and the link-layer address of the DHCPv6 client, which is found through Neighbor Discovery if needed 🌸. The driver then transmits the packet as described in section 4.4.1. This can create a brand new pt-pt VC between the server and the client, if one didn't already exist 🦋.

On the client side, the DHCP client's IPv6/NBMA driver receives the encapsulated packet from the DHCP Server or Relay Agent, as described in section 4.5 🧚. The node de-encapsulates the multicast packet and passes it up to the IPv6 Network Layer for processing. Then the IPv6 network layer delivers the DHCPv6 Advertise message to the DHCPv6 client 🎀.

The other DHCPv6 messages (Request, Reply, Release and Reconfigure) are unicast between the DHCPv6 client and the DHCPv6 Server 📮. Depending on whether the DHCPv6 client's address is reachable, messages between a client and a server on another LL go either through a router or through a DHCPv6 Relay-Agent 🌈. Before sending the DHCPv6 message, the IPv6 network layer does Neighbor Discovery (if needed) to get the link-layer address for the packet's next-hop 🧠. Then a pt-pt VC gets set up between the sender and the next hop, and the encapsulated packet goes over it, as described in 4.4. Sending Data 🚀.

A.2.3 Manual Address Configuration 🛠️

an IPv6 host gets manually configured if DAD finds out that its link-local address isn't unique 😭. Once the host has a unique interface token, the auto-configuration mechanisms can be invoked 💅.

A.3 Internet Group Management Protocol (IGMP) 🌷

IPv6 multicast routers use the IGMPv6 protocol to regularly figure out which groups their local hosts belong to 🔎. In the framework described here, IGMPv6 works without any special changes for NBMA. These protocols might not be the most efficient in this environment, but they'll still work the way they're described below 🫠. However, IPv6 multicast routers connected to an NBMA LL could optionally optimize the IGMP functions. They do this by sending MARS_GROUPLIST_REQUEST messages to the MARS serving the LL, then figuring out group memberships from the MARS_GROUPLIST_REPLY messages 🧩. Asking the MARS about multicast group membership is an optional enhancement, and it's not required for routers to work out IPv6 multicast group membership on an LL. Totally a bonus, not a must 🎁.

There are three ICMPv6 message types that carry group membership info: the Group Membership Query, Group Membership Report and Group Membership Reduction messages 📦. IGMPv6 keeps working unmodified over the IPv6/NBMA architecture in this document 💜.

An IPv6 multicast router gets all IPv6 multicast packets on the LL by joining all multicast groups in promiscuous mode [5] 👀. The MARS server then adds the multicast router to all existing and future multicast VCs 🌟. From then on, the router receives every IPv6 multicast packet sent within the Logical Link 🥰.

An IPv6 multicast router finds out which multicast groups have members in the Logical Link by periodically sending Group Membership Query messages to the IPv6 all-nodes multicast address 📡. When the local node's IPv6/NBMA driver gets the request from the IPv6 network layer to send the Group Membership Query packet, it follows the steps in 4.4.2. The node sees that the destination is the all-nodes multicast address, so it passes the packet to the node's MARS client. There it gets encapsulated and sent directly to the MARS. The MARS then relays it to all nodes in the LL 💫. Each node's IPv6/NBMA driver receives the packet, de-encapsulates it and passes it up to the IPv6 Network layer 🙌. If the originating node gets its own encapsulated packet back, the MARS client filters it out, because the Cluster Member ID of the receiving node matches the CMI in the packet's MARS encapsulation header 🙅‍♀️.

IPv6 hosts on the Logical Link answer a Group Membership Query with a Group Membership Report for each IPv6 multicast group they've joined 🗣️. Hosts can also send a Group Membership Report when they join a new IPv6 multicast group 🎉. The Group Membership Report goes to the multicast group whose address is being reported. When the local node's IPv6/NBMA driver gets the request from the IPv6 network layer to send the packet, it follows the steps in 4.4.2. The node sees that the packet is headed to a multicast address, so it forwards it to the node's MARS client to go out on the right VC 🦋.

Group Membership Report packets reach every node that's a member of the group being reported, over one of the VCs attached to each node's MARS client 💌. The MARS client de-encapsulates the incoming packet and passes it up to the IPv6 network layer for processing. The MARS client of the sending node filters the packet out when it receives it 🫣.

An IPv6 host sends a Group Membership Reduction message when it leaves an IPv6 multicast group 👋. The Group Membership Reduction goes to the multicast group the host is leaving. Group Membership Reduction messages get sent and received the same way as Group Membership Reports 🍓.

Appendix B. Alternative models of MARS support for Intra-LL ND 🌈

B.1 Simplistic approach - Use MARS 'as is'. 🪄

The IPv6/NBMA driver uses the standard MARS protocol to set up a VC forwarding path out of the interface it can transmit all multicast IPv6 packets on, ICMPv6 packets included 💅. The IPv6 packets are then sent and received by the intended destination set, using separate pt-mpt VCs for each destination group 🛣️.

In this approach, every protocol element in [5] gets used 'as is' ✨. Still, SVC resource consumption has to be taken into account 😬. The thing is, ND assumes that link-level multicast resources are best saved by generating a sparsely spread set of Solicited Node multicast addresses (where discovery queries are first sent) 🌬️. The original goal was to keep the number of innocent nodes that got discovery messages meant for someone else as low as possible 🙃.

But in connection-oriented NBMA environments, it becomes just as important (or even more) to keep down the number of independent VCs a given NBMA interface has to originate or terminate 🚨. If we treat the MARS service as a 'black box', that sparse Solicited Node address space can lead to lots of short-use (but longer-lived) pt-mpt VCs. Those get created whenever a node transmits Neighbor Solicitations 😩. Even more annoying, these VCs only help with extra packets going to their own Solicited Node multicast address. A new pt-pt VC is still needed to carry the actual unicast IPv6 traffic that triggered the Neighbor Solicitation 🫠.

The inefficiency from the sparse Solicited Node address space is orthogonal to the VC mesh vs Multicast Server tradeoff 📐. Normally a multicast server squishes traffic for one multicast group onto a single VC. To cut down on VC consumption for ND, we'd need to aggregate across the Solicited Node address space, grouping by what a packet is for rather than its explicit IPv6 destination 🧃. The catch is that this aggregation gets rid of the original benefit of spreading nodes sparsely across the Solicited Node space. It's the price of the mismatch between ND and connection-oriented networks 💔.

One possible aggregation mechanism: every node's IPv6/NBMA driver traps multicast ICMPv6 packets carrying multicast ND or RD messages, then logically remaps their destinations to the All Nodes group (link-local scope) 🗺️. By making sure the All Nodes group is supported by an MCS, the resulting VC load within the LL drops a lot 📉.

A further optimization: every node's IPv6/NBMA driver traps those same multicast ICMPv6 packets and sends them to the MARS itself, which retransmits them on ClusterControlVC (this involves a trivial extension to the MARS itself) 🧁. This approach works because, in any LL where IPv6 multicasting is supported:

  • Nodes already have a pt-pt VC to their MARS.
  • The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster members (LL members registered for multicast support).

Since the VCs between a MARS and its MARS clients carry LLC/SNAP encapsulated packets, ICMP packets can be multiplexed with normal MARS control messages 🎀. Basically, the MARS acts as a multicast server for non-MARS packets it receives from around the LL 🌟.

A MARS client isn't required to accept only MARS control messages on ClusterControlVC. So ICMP packets received this way may be passed to every node's IP layer without further comment 🤷‍♀️. Inside the IP layer, filtering happens based on the packet's actual destination IP address, and only the targeted node ends up responding 🎯.

Honestly, this approach does mean the entire Cluster's membership has to receive a bunch of ICMPv6 messages that they will always throw away 😭🗑️.

Appendix C. Flow detection 🦋

The relationship between IPv6 packet flows, Quality of Service guarantees, and optimal use of underlying IP and NBMA network resources is still being researched by the IETF 🔬 (specifically in the ISSLL, RSVP, IPNG, and ION working groups). For now, this document only describes using flow detection to optimize NBMA network resources by setting up inter-LL shortcuts ⚡.

Appendix C. Flow detection (continued) 🌊

C.1. The use of non-zero FlowID to suppress flow detection 🎀

okay so bestie, first up: what counts as a "flow" for this IPv6/NBMA setup? 💅 A flow is a related sequence of IPv6 packets that the first hop router is allowed to run flow-detection on, so it can trigger shortcut discovery. How the packets count as related (like matching IPv6 destination addresses) is totally up to local configuration. 🧚

The flow-detection rule is that only packets with a zero FlowID can count as flows that might trigger shortcut discovery. Here's why it's giving logic 🧠✨

  • NBMA shortcuts exist to help "the network" optimize how it forwards IPv6 packets when the host hasn't given any other guidance.
  • It's important for an IPv6/NBMA host to have some way to override the network's attempts to optimize its internal forwarding path. 👑
  • A zero FlowID means, in IPv6 terms, "the source lets the network use its own judgment to provide best-effort forwarding for packets with a zero FlowID." 🦋
  • That lines up with this document's flow-detection rule: "if the FlowID is zero, we are free to optimize the forwarding path using shortcuts." 💖
  • A non-zero FlowID means, in IPv6 terms, "the source has already set up some preferred, end to end hop by hop forwarding behaviour for packets with this FlowID." 🫶
  • That also lines up with the flow-detection rule here: "if the FlowID is non-zero, do not attempt to impose a shortcut." 🙈

A non-zero FlowID might get assigned by the source host after it negotiates a preferred forwarding mechanism with "the network" (through dynamic means like RSVP, or administrative means). 🌸 Or the host can just pick one at random, and the network will give default best-effort forwarding. (An IPv6 router defaults to best-effort forwarding for packets whose FlowID/source-address pair it doesn't recognize.) 😭

So the modes of operation this document supports are:

Zero FlowID Best effort forwarding, with optional shortcut discovery triggered through flow-detection. ✨

Non-zero FlowID Best effort forwarding if the routers along the path have not been otherwise configured with alternative processing rules for this FlowID/source-address pair. Flow detection relating to shortcut discovery is suspended.

If the routers along the path have been configured with particular processing rules for this FlowID/source-address pair, the flow is handled according to those rules. Flow detection relating to shortcut discovery is suspended. 🔥

Mechanisms for setting up particular per-hop processing rules for packets with a non-zero FlowID are neither constrained nor implied by this document. 💅

C.2. Future directions for Flow Detection 🔮

Okay, looking ahead 👀: accurately mapping IPv6 flows onto NBMA VCs might someday need more info exchanged during Neighbor Discovery than ND packets can carry today. If that happens, the IPv6 Neighbor Discovery protocols can be extended with new TLV options (see section 4.6 of RFC 1970 [7]). But if new options are needed, their spec has to be co-ordinated with the IPNG working group. 🤝 RFC 1970 says nodes must silently ignore options they don't understand, so new options can be added at any time without breaking backward compatibility with existing implementations. That's the best part, honestly 🥹💜

NHRP also has ways to add optional TLVs to NHRP Requests and NHRP Replies. Future versions of this architecture will need consistent QoS extensions to both ND and NHRP so they stay semantically equivalent. (Syntactic differences are not ideal, but they can be tolerated. 🙃)

QoS on IPv6 unicast flows won't need any more extensions to the existing MARS protocol. 🌈 Future QoS support for IPv6 multicast flows might need extensions, though. MARS control messages share the same TLV extension mechanism as NHRP, so QoS extensions can be developed whenever they're needed. ⭐

Appendix D. Shortcut Limit Option 🍓

Real quick: for NS messages sent as a shortcut trigger, we need a new type of ND option so the information about the data flow hop limit can get from the host to the router. Section 3.2.2 of this specification defines how this ND option is used. Its binary layout follows the rules of section 4.6 of RFC 1970: 🧩

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     | Shortcut Limit|   Reserved1   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Reserved2                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

    Type            6

    Length          1

    Shortcut Limit  8-bit unsigned integer. Hop limit for shortcut
                    attempt.

    Reserved1       This field is unused. It MUST be initialized to
                    zero by the sender and MUST be ignored by the
                    receiver.

    Reserved2       This field is unused. It MUST be initialized to
                    zero by the sender and MUST be ignored by the
                    receiver.

Description 📝

The shortcut limit option is used by a host in a Neighbor Solicitation message sent as a shortcut trigger to a default router. It restricts the router's shortcut query to targets reachable via the specified number of hops. The shortcut limit is measured relative to the host requesting the shortcut. NS messages with shortcut limit values of 0 or 1 MUST be silently ignored.

⚠️ Heads up, bestie: NS messages with a shortcut limit of 0 or 1 get silently ignored. No error, no reply, just gone. 💀

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌷

This document and translations of it may be copied and furnished to others. Derivative works that comment on or explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The only exceptions are for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or for translating it into languages other than English. 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 💜

This document and the information contained herein is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫶

📦 where this page comes from