7. Updating RFC 8505
Ce document met a jour IPv6 Neighbor Discovery et les specifications 6LoWPAN/RPL associees afin qu'un noeud puisse enregistrer un IPv6 prefix aupres de routeurs voisins. Les details de protocole essentiels sont conserves ci-dessous depuis le texte RFC.
7. Updating RFC 8505
This specification updates the EARO and EDAR messages to enable the
registration of prefixes and updates the registration operation in
the case of a prefix, in particular from the standpoint of the 6LR,
e.g., to enable the registration of overlapping prefixes.
7.1. New P-Field Value
[RFC9685] defines a 2-bit P-Field with values 0 through 2 and
reserves the value 3 for future use. This specification defines the
semantics of P-Field value 3.
When the P-Field is set to 3, it indicates that the Registered
Address represents a prefix rather than a single address. Upon
receiving an NS(EARO) message with the P-Field set to 3, the receiver
MUST install a route to the indicated prefix via the source address
of the NS(EARO) message.
This specification assigns the value 3 to the P-Field, resulting in
the following complete set of defined values:
+=======+======================================+
| Value | Meaning |
+=======+======================================+
| 0 | Registration for a Unicast Address |
+-------+--------------------------------------+
| 1 | Registration for a Multicast Address |
+-------+--------------------------------------+
| 2 | Registration for an Anycast Address |
+-------+--------------------------------------+
| 3 | Registration for a Unicast Prefix |
+-------+--------------------------------------+
Table 1: P-Field Values
7.2. New EARO Prefix Length Field and F flag
Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO
option defined in [RFC6775].
The Status field is used only when the EARO is placed in an NA
message. This specification repurposes that field to carry the
prefix length when the EARO is placed in an NS message as illustrated
in Figure 2. The prefix length is expressed as 7 bits, and the most
significant bit of the field is reserved. A 7-bit value of 0 is
understood as a truncated 128, meaning that this registration is for
an address as opposed to a prefix. This approach is backward
compatible with [RFC8505] and spans both addresses and prefixes.
This specification adds a new F flag to signal that the Registered
Prefix is topologically correct through the Registering Node. This
means that the Registering Node relays packets that are sourced in
the Registered Prefix to the outside, in accordance with "Network
Ingress Filtering: Defeating Denial of Service Attacks which employ
IP Source Address Spoofing" [BCP38]. The receiver forwards packets
to the Registering Node address when the source address of the
packets derives from the Registered Prefix. Note that to avoid
loops, the receiver must be in the inside so packets sent by the
sender towards the outside may never reach the receiver. The notion
of "inside" and "outside" are administratively defined, e.g.,
"inside" is a particular L2 network such as an Ethernet fabric.
When the F flag is not set, the Registering Node owns the prefix and
will deliver packets to the destination if the destination address
derives from the prefix. Conversely, if the F flag is set, the
Registering Node will forward traffic whose source address derives
from the Registered Prefix into a network location (e.g., to an ISP
Provider Edge) where this source address is topologically correct
(e.g., derives from a prefix assigned by that ISP). The F flag is
encoded in the most significant bit of the EARO Status field when the
Status field is used to transport a Prefix Length as shown in
Figure 2.
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|Prefix Length| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|C| P | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ROVR ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EARO Format for Use in NS Messages
New and updated Option Fields:
F: (Forwarding Flag) A 1-bit flag. When set to 1, it indicates that
the sender expects other routers to forward packets to the sender
when those packets are sourced from within the registered prefix.
Prefix Length: A 7-bit unsigned integer. When the P-Field is set to
3 and the EARO is included in an NS message, this field MUST
contain a prefix length expressed in bits, with a value in the
inclusive range of 16 to 120. When the EARO is included in an NA
message, this field MUST carry a status value, regardless of the
setting of the P-Field. In all other cases, this field is
reserved; it MUST be set to zero by the sender and MUST be ignored
by the receiver.
r (reserved): A 1-bit reserved field. It MUST be set to zero by the
sender and MUST be ignored by the receiver.
7.3. New EDAR Prefix Length Field
This specification adds the new value of 3 to the P-Field to signal
that the Registered Address is a prefix. When that is the case, the
prefix is assumed to be at most 120 bits long, padded with zeros up
to 120 bits, and the remaining byte is dedicated to one reserved bit
and the Prefix Length.
Figure 3 illustrates the EDAR message when the value of the P-Field
is 3. Figure 4 shows the response EDAC message, with the Status
field and the echoed Prefix.
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 |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P=3| Reserved | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ROVR ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix +
| |
+ (up to 120 bits, padded with zeros) +
| |
+ +-+-+-+-+-+-+-+-+
| |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: EDAR Message Format with P == 3
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 |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ROVR ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix +
| |
+ (up to 120 bits, padded with zeros) +
| |
+ +-+-+-+-+-+-+-+-+
| |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: EDAC Message Format
New and updated EDAR/EDAC Message Fields:
Prefix: A 15-byte field that carries up to 120 bits of the prefix.
If the prefix is shorter than 120 bits, the remaining bits MUST be
padded with zeros. The receiver MUST treat the padding as zeroed
and MUST overwrite any unused bits with zeros before using the
prefix.
r (reserved): A 1-bit reserved field. It MUST be set to zero by the
sender and MUST be ignored by the receiver.
Prefix Length: A 7-bit unsigned integer indicating the length of the
prefix in bits. The value MUST be in the inclusive range of 16 to
120.
The capability to place the P-Field and the contiguous "Reserved"
field in the EDAR message is specified in Section 7.2 of [RFC9685].
The capability to append ND options to the EDAR and EDAC messages is
introduced in Section 3.1 of [RFC8929].
All other fields follow the same definition as specified in
[RFC8505]. The values for these fields and RFC references are
maintained by IANA under the "Internet Control Message Protocol
version 6 (ICMPv6) Parameters" [IANA.ICMP] registry group.
7.4. Updating the Registration Operation
With [RFC8505]:
* A router that expects to reboot may send a final RA message, upon
which nodes should register elsewhere or redo the registration to
the same router upon reboot. In all other cases, a node reboot is
silent. When the node comes back to life, existing registration
state might be lost if it was not safely stored, e.g., in
persistent memory.
* Only unicast addresses can be registered.
* The 6LN must register all its Unique Local Addresses (ULAs) and
Global Unicast Addresses (GUAs) with a NS(EARO).
* The 6LN may set the R flag in the EARO to obtain return
reachability services from the 6LR, e.g., through ND proxy
operations or by injecting the route in a route-over subnet.
* The 6LR maintains a registration state per Registered Address,
including an NCE with the Link Layer Address (LLA) of the
Registered Node (the 6LN here).
The operation for registering prefixes is similar to that for
addresses from the perspective of the 6LN, but shows important
differences on the router side, which maintains a separate state for
each origin and merges them in its own advertisements. This
specification adds the following behavior, similar to that introduced
by [RFC9685] for multicast addresses:
* The EARO status indicating a "Registration Refresh Request"
applies to prefixes as well.
This status is used in asynchronous NA(EARO) messages to indicate
to peer 6LNs that they are requested to reregister all addresses
and prefixes that were previously registered to the originating
node. The NA message MAY be sent to a unicast or a multicast
link-scope address and SHOULD be contained within the L2 range
where nodes may effectively have registered/subscribed to this
router, e.g., a radio broadcast domain to preserve energy and
spectrum.
A device that wishes to refresh its state, e.g., upon reboot if it
may have lost some registration state, SHOULD send an asynchronous
NA(EARO) with this new status value. That asynchronous NA(EARO)
SHOULD be sent to the all-nodes link-scope multicast address
(ff02::1), and Target MUST be set to the link-local address that
was exposed previously by this node to accept registrations, and
the TID MUST be set to 0; the ROVR field MUST be set to all zeros
and ignored by the receiver.
In an environment with unreliable transmissions, the multicast
NA(EARO) message may be resent in a fast sequence, in which case
the TID is incremented each time. A 6LN that has recently
processed the NA(EARO) indicating a "Registration Refresh Request"
ignores the additional NA(EARO) also indicating a "Registration
Refresh Request" within the duration of the fast sequence. That
duration depends on the environment and has to be configured. By
default, it is 10 seconds.
* Registration for prefixes is now supported. The value of 3 in the
P-Field of the EARO and the EDAR message signals when the
registration is for a prefix as opposed to an address. DAD for
prefixes and addresses becomes a prefix overlap match. Whether
overlapping addresses and prefixes may be registered is a network
policy decision and out of scope. The same prefix may be injected
twice (multiple routes) as long as they use the same value of the
ROVR.
Overlaps may be desirable. For instance, it may happen that a
router or a proxy (see Section 10) registers a prefix or an
aggregation while a host using an address from that prefix or a
prefix from that aggregation also registers its piece.
In case of an overlapping registration, the longest prefix match
wins, meaning that if the network policy allows for overlapping
registrations, then the routes for the registered prefixes are
installed towards the node that registered with the longest prefix
match, all the way to /128.
* If the 6LR acts as a border router to external prefixes or owns
the prefixes entirely, it SHOULD register all those prefixes on
all interfaces from which it might be needed to relay traffic to
that prefix. It MUST set the P-Field in the EARO to 3 for those
prefixes and set the R flag to receive the traffic associated to
the prefixes. It MAY refrain from registering a prefix on one
interface if that prefix is already successfully registered on
another interface, or the router handled the EDAR/EDAC flow by
itself, to ensure that the prefix ownership is known and validated
by the 6LBR. Additionally, if the router expects to receive
traffic for that prefix on that interface, it needs to ensure that
the prefix is advertised some other way, e.g., over a routing
protocol such as RPL.
* The 6LN MAY set the R flag in the EARO to request the 6LR to
redistribute the prefix on other links using a routing protocol.
The 6LR MUST NOT reregister that prefix to yet another router
unless loops are avoided some way, e.g., following a tree
structure.
* The 6LR and the 6LBR are extended to accept more than one
registration for the same prefix, since multiple 6LNs may register
it. The ROVR in the EARO identifies uniquely a registration
within the namespace of the Registered Prefix.
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix,
prefix length, ROVR) for all registered prefixes. It SHOULD
notify the 6LBR with an EDAR message, unless it determined that
the 6LBR is legacy and does not support this specification (see
Section 5). In turn, the 6LBR MUST maintain a registration state
per tuple (IPv6 prefix, ROVR) for all prefixes.