rfc-8505

Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery

P. Thubert (Editor), E. Nordmark, S. Chakrabarti, C. Perkins
date2018-11 streamIETF areaint wg6lo statusPROPOSED STANDARD pages47 canonicalhttps://www.rfc-editor.org/rfc/rfc8505 doi10.17487/RFC8505 errataview
This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network.

updated by

updates

Extracted elements (34)

design-rationale §5.6

Link-Local Address uniqueness is only required between the two nodes that directly communicate (e.g., the 6LN and its 6LR), eliminating the EDAR/EDAC exchange for Link-Local Addresses in route-over topologies. This simplification is justified because a Link-Local Address is only meaningful for one-hop communication.

ip, v6ops

design-rationale §5.3

The EUI-64 field of the ARO is renamed to ROVR and generalized to support cryptographic tokens of variable size (64–256 bits). This enables cryptographic proof of address ownership (as in AP-ND) while retaining backward compatibility when the size is constrained to 64 bits.

ip, v6ops, security, crypto

design-rationale §5.1

The Registered Address is placed in the Target Address field of NS messages rather than the Source Address field (as in RFC 6775) to enable proxy registrations: the 6LBR can register a 6LN's address to a Routing Registrar without the Registered Node participating, and a node avoids using an address as Source before it is registered.

ip, v6ops

interoperability-note §6.3

An updated 6LN registering with an RFC 6775-only 6LR MUST use a 64-bit ROVR and MUST behave in a backward-compatible manner per RFC 6775. An updated 6LBR communicating with an RFC 6775-only 6LR MUST use only the 64 leftmost bits of the ROVR in EDAR messages.

ip, v6ops

interoperability-note §6.2

An updated 6LR MUST accept registrations from RFC 6775-only 6LNs (which use Source Address instead of Target Address for the Registered Address) and MUST use RFC 6775-only DAR/DAC messages to the 6LBR to indicate TID absence. The 6LR MUST still reply with an NA(EARO).

ip, v6ops

interoperability-note §5.1

The EARO is backward compatible with the RFC 6775 ARO if and only if the option Length is set to 2 (64-bit ROVR). The T flag and TID field occupy fields reserved in RFC 6775 and are ignored by RFC 6775-only routers.

ip, v6ops

normative-requirement §5.1 MUST

A 6LN acting only as a host MUST set the R flag in the EARO to indicate it is not a router and will not handle its own reachability. A 6LR that manages its own reachability SHOULD NOT set the R flag, as doing so may cause conflicting routes to be installed.

ip, v6ops

normative-requirement §5.7 SHOULD

A node ceasing to use an address SHOULD attempt to de-register by sending NS(EARO) with Registration Lifetime of 0. The 6LR MUST report a lifetime-0 registration to the 6LBR via an EDAR exchange, conveying the latest TID known to the 6LR.

ip, v6ops

normative-requirement §5.7 MUST

A node that moves SHOULD de-register from the old 6LR and register to a new 6LR with an incremented TID. An asynchronous NA(EARO) or EDAC with status 'Moved' SHOULD be used to clean up state at the previous location; the receiver MUST clean up said state.

ip, v6ops, mobility

normative-requirement §5.1 MUST

A node that supports this specification MUST provide a TID field in the EARO and set the T flag to indicate the presence of the TID. An updated 6LN MUST use an EARO (with T flag set) regardless of whether the 6LR is RFC 6775-only or updated.

ip, v6ops

normative-requirement §6.1 MUST

The 6CIO MUST be present in both RS and RA messages unless already shared in recent exchanges or pre-configured. A 6CIO MUST be placed in an RA sent in response to an RS that carried a 6CIO.

ip, v6ops

normative-requirement §3 MUST

The number of registrations supported by a 6LR or 6LBR MUST be clearly documented by the vendor, and the dynamic use of associated resources SHOULD be made available to the network operator.

ip, v6ops

normative-requirement §5.5 MUST

The Registered Address MUST be placed in the Target Address field of NS/NA messages, not the Source Address field as specified in RFC 6775. This enables proxy registrations and avoids using an address as Source Address before it is registered.

ip, v6ops

normative-requirement §5.3 MUST NOT

The ROVR MUST NOT be used to correlate registrations of different IPv6 Addresses; its scope is solely to verify that the node updating a registration for a specific address is the same node that made the original registration. When the ROVR is not an EUI-64 address, it MUST NOT be used as the Interface Identifier of the Registered Address.

ip, v6ops, security, privacy

normative-requirement §5.6 MUST

When sending an NS(EARO) to a 6LR, a 6LN MUST use a Link-Local Address as the Source Address, whether the registered address is link-local or global. That Link-Local Address MUST be either already registered to the 6LR or the address being registered.

ip, v6ops

privacy-consideration §8

The protocol does not limit the number of IPv6 Addresses a device may form and register; hosts SHOULD conform to RFC 7934 host address availability recommendations. Implementations and deployments must consider privacy addresses (RFC 4941) in their environments.

privacy, ip, v6ops

privacy-consideration §8

Using EUI-64 to form the Link-Local Address Interface Identifier is discouraged because it prevents the use of SEND, CGAs, and other address privacy techniques. Implementations SHOULD follow RFC 8064 and use the RFC 7217 mechanism for generating semantically opaque Interface Identifiers.

privacy, ip, v6ops

protocol-element §4.1

EARO Status Codes extend the three values from RFC 6775 with: 3 (Moved), 4 (Removed), 5 (Validation Requested), 6 (Duplicate Source Address), 7 (Invalid Source Address), 8 (Registered Address Topologically Incorrect), 9 (6LBR Registry Saturated), and 10 (Validation Failed).

ip, v6ops

protocol-element §4.3

The 6LoWPAN Capability Indication Option (6CIO) is extended with five new bits: E (EARO support), P (Routing Registrar capable), B (6LBR capable), L (6LR capable), and D (EDAR/EDAC support by 6LBR). A 6LR that supports this specification MUST set the E flag.

ip, v6ops

protocol-element §4.1

The Extended Address Registration Option (EARO) updates the ARO for use in NS and NA messages. It adds a Transaction ID (TID) for mobility detection, an R flag to request reachability services, a T flag indicating TID presence, an I field for topology selection, an Opaque field, and renames the EUI-64 field to the Registration Ownership Verifier (ROVR).

ip, v6ops

protocol-element §5.3

The Registration Ownership Verifier (ROVR) replaces the EUI-64 field of the ARO. It is 64 bits for backward compatibility, or optionally 128, 192, or 256 bits; it need not be derived from a MAC address and may carry cryptographic tokens. The ROVR's scope is a single IPv6 Address registration and MUST NOT be used to correlate registrations of different addresses.

ip, v6ops, security

protocol-element §5.2

The Transaction ID (TID) is a 1-byte sequence counter in the EARO that the 6LN increments with each re-registration transaction. The network uses the most recent TID to determine the most recent known location of a mobile 6LN; the same TID MUST be used across simultaneous registrations to multiple 6LRs.

ip, v6ops, mobility

protocol-element §5.2.1

TID comparison uses a lollipop sequence number scheme per RFC 1982: values 128–255 form a linear bootstrap region, values 0–127 form a circular sequence space. A SEQUENCE_WINDOW of 16 (2^4) governs comparability; values more than 16 apart in the circular region are deemed not comparable.

ip, v6ops, mobility

registry §9.4

IANA added eight new values to the 'Address Registration Option Status Values' subregistry: 3 (Moved), 4 (Removed), 5 (Validation Requested), 6 (Duplicate Source Address), 7 (Invalid Source Address), 8 (Registered Address Topologically Incorrect), 9 (6LBR Registry Saturated), 10 (Validation Failed).

registry, ip, v6ops

registry §9.5

IANA added five new bits to the '6LoWPAN Capability Bits' subregistry: bit 10 (D — EDA Support), bit 11 (L — 6LR capable), bit 12 (B — 6LBR capable), bit 13 (P — Routing Registrar capable), bit 14 (E — EARO support).

registry, ip, v6ops

registry §9.1

IANA created a new 'Address Registration Option Flags' subregistry under ICMPv6 Parameters (8 bit positions, 0–7). Bit 6 is assigned to the R flag and bit 7 to the T flag by this document; bits 0–5 are unassigned. Registration procedure: IETF Review or IESG Approval.

registry, ip, v6ops

registry §9.2

IANA created a new 'Address Registration Option I-Field' subregistry (values 0–3). Value 0 is assigned to 'Abstract Index for Topology Selection'; values 1–3 are unassigned. Registration procedure: IETF Review or IESG Approval.

registry, ip, v6ops

registry §9.3

IANA created two new subregistries for the Code Suffix of ICMP Types 157 (DAR) and 158 (DAC). Code Suffix 0 = original RFC 6775 message; suffixes 1–4 indicate EDAR/EDAC with 64-, 128-, 192-, or 256-bit ROVR fields respectively; 5–15 unassigned.

registry, ip, v6ops

security-consideration §7

A rogue node may launch a denial-of-service attack against the 6LR or 6LBR registry. Mitigations include: the TID sequence counter to detect and clean up stale registrations, prompt de-registration when addresses are abandoned, individually configurable registration lifetimes, and router-enforced per-node address limits with LRU cleanup.

security, ip, v6ops

security-consideration §7

A trust model MUST be put in place to ensure that only authorized devices act as 6LBR or Routing Registrar, to prevent black-holing or bombing attacks where an impersonated 6LBR destroys registration state using the 'Removed' status code. At a minimum this may be based on Layer 2 access control.

security, ip, v6ops

security-consideration §7

The LLN MAC layer MUST provide secure unicast to/from a Routing Registrar and secure broadcast/multicast from the Routing Registrar to prevent tampering with or replaying ND messages. RFC 6775 relies on lower-layer encryption; this specification inherits and extends that requirement.

security, ip, v6ops

state-machine §5.7

When an address is scheduled for removal, the 6LBR SHOULD keep its NCE in a DELAY state for a configurable period before silently removing it. This prevents premature removal when a mobile node has de-registered from one 6LR but has not yet completed registration to a new one.

ip, v6ops, mobility

wire-format §4.1

EARO format: Type (8-bit, value 33), Length (8-bit, units of 8 bytes), Status (8-bit), Opaque (8-bit), Rsvd (4-bit), I (2-bit), R (1-bit), T (1-bit), TID (8-bit), Registration Lifetime (16-bit, minutes), followed by the ROVR field whose size in bytes is (Length - 1) * 8.

ip, v6ops

wire-format §4.2

The Extended Duplicate Address Request (EDAR) and Confirmation (EDAC) messages split the ICMP Code into a 4-bit Code Prefix (MUST be 0) and 4-bit Code Suffix; Code Suffix values 1–4 indicate 64-, 128-, 192-, or 256-bit ROVR sizes, respectively. A TID field replaces the Reserved field, and a variable-length ROVR and Registered Address follow.

ip, v6ops