Moving the C Flag in EARO

Introduction The classical Neighbor Discovery (IPv6 ND) Protocol was defined for serial links and shared transit media such as Ethernet at a time when broadcast was cheap on those media while memory for neighbor cache was expensive. It was thus designed as a reactive protocol that relies on caching and multicast operations for the Address Resolution (AR, aka Address Discovery or Address Lookup) and Duplicate Address Detection (DAD) of IPv6 unicast addresses. Those multicast operations typically impact every node on-link when at most one is really targeted, which is a waste of energy, and imply that all nodes are awake to hear the request, which is inconsistent with power saving (sleeping) modes. Low-Power Personal Area Networks (LoWPANs) require an optimized IPv6 Neighbor Discovery due to resource constraints and high multicast overhead. To address this, 6LoWPAN ND , , , , introduces a unicast, anycast, and multicast Address Registration (AR) mechanism as well as a Prefix Registration (PR) mechanism. Staring with , the registration mechanism uses the Extended Address Registration Option (EARO), significantly reducing reliance on multicast for Duplicate Address Detection (DAD). In these networks, the 6LoWPAN Border Router (6LBR) serves as a central repository for registered addresses. 6LoWPAN ND is being generalized to NBMA networks as Subnet Neighbor Discovery (SND), see . For enhanced security, introduces a Registration Ownership Verifier (ROVR) in the EARO. Building on this, the "Address-Protected Neighbor Discovery for LLNs", protects the ownership of unicast IPv6 addresses registered with . In this framework, a node auto-configures a public/private key pair and signs its address registrations, enabling the first-hop router (6LoWPAN Router (6LR)) to validate registrations and perform source address verification. However, the “Address-Protected Neighbor Discovery for Low-Power and Lossy Networks” (AP-ND), initially defined the “C” flag in EARO, later on defined the P-Field in bits 2 and 3 of the EARO flags with proper IANA registration, causing an overlap with Figure 1 of which depicts the location of the “C” flag. This specification updates by repositioning the “C” flag as bit 1 of the EARO flag avoiding conflicts.

Terminology

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

References This document uses terms and concepts that are discussed in:

Neighbor Discovery for IP version 6
IPv6 Stateless Address Autoconfiguration
Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
IPv6 Backbone Router
Address-Protected Neighbor Discovery for Low-Power and Lossy Networks
Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses

Acronyms This document uses the following abbreviations:

6LN:: 6LoWPAN Node
6LBR:: 6LoWPAN Border Router
6LR:: 6LoWPAN Router
AP-ND:: Address-Protected Neighbor Discovery
ARO:: Address Registration Option
DAD:: Duplicate Address Detection
EARO:: Extended Address Registration Option
LLN:: Low-Power and Lossy Network
LoWPAN:: Low-Rate Personal Area Network (IEEE Std. 802.15.4)
NDP:: Neighbor Discovery Protocol
ROVR:: Registration Ownership Verifier
SND:: Subnet Neighbor Discovery
TID:: Transaction ID

Updating RFC 8928 The "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" was defined to protect the ownership of unicast IPv6 addresses that are registered with . In , the "C" flag is shown in the EARO flags field at bit position 3 (as depicted in Figure 1 of ); however, it does not explicitly specify the bit number and fails to register its position with IANA. Later, defined the P-Field in bits 2 and 3 of the EARO flags field and obtained proper IANA registration, but this introduced an overlap with the representation in . To resolve the conflict, this specification updates by repositioning the "C" flag to bit 1 of the EARO flags field, thereby avoiding the overlapping definitions.

Extended Address Registration Option (EARO) Format in NS messages 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 |F|PrefixLength | Opaque | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|C| P | I |R|T| TID | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... Registration Ownership Verifier ... | (64, 128, 192, or 256 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Fields of interest for this specification:

Type:: 33
Length:: Defined in and copied in the "EARO Length" field in the associated Crypto-ID Parameters Option (CIPO).
Status:: Defined in .
Opaque:: Defined in .
R (Reserved):: 1-bit unsigned integer. It MUST be set to zero by the sender and MUST be ignored by the receiver.
C:: 1-bit flag, moved from its position in Figure 1 of . It is set to indicate that the ROVR field contains a Crypto-ID and that the 6LN MAY be challenged for ownership.
P:: 2-bit P-Field
I, R, T:: Defined in .
TID and Registration Lifetime:: Defined in .
Registration Ownership Verifier (ROVR):: When the "C" flag is set, this field contains a Crypto-ID.

IANA Considerations

Bit Position of the "C" Flag This specification updates the location of the "C" flag introduced in to position it as bit 1 in the EARO flags. IANA is requested to make an addition to the "Address Registration Option Flags" registry under the heading "Internet Control Message Protocol version 6 (ICMPv6) Parameters" as indicated in : Bit Position of the "C" Flag

ARO flag	Meaning	Reference
1 (suggested)	"C" Flag	RFC 8928

Many thanks to Dave Thaler and Dan Romascanu for their early INT-DIR review.