IPv6 over Non-Broadcast Multiple Access (NBMA) networks
updated by
- rfc-8064 — Recommendation on Stable IPv6 Interface Identifiers
Extracted elements (28)
Flow detection is restricted to IPv6 packets with FlowID of zero because non-zero FlowIDs indicate that the source has already set up explicit QoS or traffic-class state; triggering shortcuts on such flows could interfere with that existing mapping. The rationale is discussed in Appendix C.
IPv6 Neighbor Discovery was designed assuming native multicast at the link layer, which NBMA networks do not provide. This document augments MARS (RFC 2022) to emulate multicast for ND, generalizing its applicability beyond ATM to all NBMA technologies.
NBMA shortcuts use ND Redirect messages to inform a source host of a better first hop, retaining the standard IPv6 host stack without per-link-layer modifications. This design allows destination interfaces to perform their own dynamic load sharing since NHRP returns the NBMA address chosen by the target when it first accepted the flow.
The architecture uses augmented MARS behavior (section 3.1.1) rather than MARS 'as is' because the sparse Solicited Node multicast address space causes excessive short-lived pt-mpt VCs in connection-oriented NBMA environments. Aggregating ND traffic via the MARS reduces VC consumption at the cost of the original sparseness benefit.
An IPv6/NBMA driver does not need to consider establishing a shortcut VC directly to a driver attached to a different type of NBMA network (e.g., an ATM driver need not interwork with an FR driver), as it can assume both ends are attached to the same NBMA technology.
IPv6 stacks on hosts require no separate ND protocol implementations per link-layer technology when using this architecture. The NBMA-specific details are confined to companion documents (e.g., RFC 2492 for ATM), keeping the host IPv6 stack uniform.
Redirects are unidirectional: after a source host reacts to a Redirect and sets up a new VC, the destination continues to send back on the old path, having no way to determine the caller identity from the new VC in the absence of Neighbor Discovery. Both endpoints only use the new VC symmetrically if the destination also receives a Redirect.
A router performing flow-triggered redirection SHALL only track flows originating from directly attached hosts, SHALL NOT use packets from other routers to trigger Redirects, and SHALL only consider IPv6 packets with FlowID of zero for flow detection purposes.
All interface tokens MUST be 64 bits in length and formatted as EUI-64 identifiers. Where two nodes on the same LL produce the same interface token, one MUST choose another token. All implementations MUST support manual configuration of interface tokens.
An IPv6/NBMA driver SHALL establish a pt-pt VC to the MARS associated with its Logical Link and register as a Cluster Member before the node can send or receive IPv6 datagrams. Hosts and routers SHALL issue MARS_JOIN for solicited-node addresses, all-nodes, and other configured multicast groups; routers additionally SHALL join all-routers and block ranges for promiscuous reception.
An IPv6/NBMA driver SHALL release any VC that has been idle for 20 minutes. This limit MAY be reduced by configuration or companion document. VCs associated with purged or STALE Neighbor/Destination cache entries SHOULD be released.
Any Redirect message sent by a router MUST conform to all rules in RFC 2461 [7]. If the shortcut target is the destination host, the ICMP Target Address MUST equal the ICMP Destination Address. If the target is an egress router, the ICMP Target Address MUST be a link-local address unique to the NBMA cloud.
For host-triggered NHRP resolution requests, the ar$hopcnt field MUST be smaller than the shortcut limit value in the triggering NS message, ensuring hosts control the reach of their shortcut request.
IPv6/NBMA drivers SHALL implement NBMA-specific mechanisms to negotiate acceptable MTUs at the VC level, as specified in companion documents, because a driver cannot know whether the remote end of a VC is in the same LL.
On PVC links, both unicast and multicast IPv6 packets SHALL be transmitted using the LLC/SNAP encapsulation defined in section 4.4.1. Interface tokens for PVC links SHALL be constructed as described in section 5 and need only be unique between the two nodes on the PVC link.
On receive, multicast-encapsulated packets SHALL have their pkt$cmi field compared to the local CMI; if they match the packet SHALL be silently dropped (loop prevention). The driver SHALL NOT attempt to filter out multicast packets arriving with unicast encapsulation or vice versa.
Routers SHALL keep track of NHRP cache entries for which they issued Neighbor Advertisements or Redirects; upon receiving a NHRP Purge invalidating previously issued information, the router SHALL issue a Redirect identifying itself as the new best next-hop. Routers SHALL also track Neighbor cache entries used to generate NHRP Replies, and expiry of such entries SHALL trigger a NHRP Purge.
Specific multicast addresses (solicited-node link-local, all-nodes link-local, all-routers link-local, DHCPv6 relay/server) SHALL be sent over the IPv6/NBMA driver's direct pt-pt VC to the MARS, which redistributes them per section 3.1.1. If the MARS VC has been idle-timed out, it MUST be re-established before forwarding.
The MARS SHALL re-transmit received IPv6 packets by checking group membership: if all group members have open pt-pt VCs to the MARS, the packet is sent over those VCs; if any member lacks an open VC or no members exist, the packet is sent over ClusterControlVC only.
When shortcut discovery is not supported by a router, the router SHALL construct a Redirect identifying itself as the best shortcut and return it to the soliciting host. If supported, the router SHALL use NHRP, then construct and transmit a Redirect from the NHRP Reply; if a NHRP NAK is received, the router SHALL similarly redirect to itself.
A Logical Link (LL) is the IPv6 analog to the IPv4 Logical IP Subnet (LIS): an administratively configured set of nodes that are 'on link' with respect to each other. Members of an LL form an interface's initial neighbor set, and link-local addresses need only be unique within the LL.
A Transient Neighbor is an off-LL neighbor discovered through unsolicited messages such as Router Redirects. Three possible relationships exist between any two IPv6 interfaces: On-LL Neighbor, Off-LL Neighbor (shortcut), or Off-LL non-Neighbor.
NHRP/ND translation maps a successful NHRP resolution reply for a host-triggered shortcut into an IPv6 Redirect: source address is the router's link-local address, destination is the IPv6 source of the triggering NS, hop limit 255, ICMP Target Address is the NHRP Client Protocol Address, Target link-layer address is the NHRP Client NBMA Address.
This architecture introduces no new protocols and therefore no additional security threats beyond those inherent in NHRP, IPv6, ND, and MARS. It should not be deployed where any of the base protocols are considered unacceptably insecure. All IPv6 security mechanisms (authentication, encryption for ND and data) work without modification over NBMA.
Multicast IPv6 packets over NBMA networks using LLC/SNAP encapsulation SHALL use: [0xAA-AA-03 (LLC)][0x00-00-5E (OUI)][0x00-01 (PID)][pkt$cmi (2 octets, Cluster Member ID)][0x86DD][IPv6 packet]. The driver's CMI SHALL be copied into the 2-octet pkt$cmi field.
The IPv6 link-local address is formed by appending the 64-bit Interface Token to the prefix FE80::/64, yielding a 128-bit address with 10-bit prefix 1111111010, 54 zero bits, and the Interface Token.
The Link Layer Address Option for Neighbor Discovery between IPv6/NBMA interfaces is: [Type 1 octet][Length 1 octet][NTL 1 octet][STL 1 octet][NBMA Number variable][NBMA Subaddress variable, optional], padded to a multiple of 8 octets. Type 1 = source, Type 2 = target link-layer address.
Unicast IPv6 packets over NBMA networks using LLC/SNAP encapsulation SHALL use the header: [0xAA-AA-03 (LLC)][0x00-00-00 (OUI)][0x86-DD (PID)][IPv6 packet]. The IPv6 next-hop identifies the pt-pt VC on which to forward.