12. Operational Considerations
Dieses Dokument aktualisiert IPv6 Neighbor Discovery sowie zugehoerige 6LoWPAN/RPL-Spezifikationen, damit ein Knoten ein IPv6 prefix bei benachbarten Routern registrieren kann. Wichtige Protokolldetails bleiben unten aus dem RFC-Text erhalten.
12. Operational Considerations
12.1. Partially Upgraded Networks
Devices may coexist while providing different support (i.e., only
[RFC8505], both [RFC8505] and [RFC9685], or those two as well as this
specification). The following cases may occur:
* A legacy 6LN will not register prefixes, and the service will be
the same when the network is upgraded.
* A legacy 6LR will not set the F flag in the 6CIO and an upgraded
6LN will not register prefixes with that router, though it may
with other 6LRs that do support this specification.
* Upon an EDAR message, a legacy 6LBR may not realize that the
address being registered comes with a whole prefix, and return
that it is duplicate in the EDAC status. The 6LR MUST ignore a
duplicate status in the EDAR for prefixes.
12.2. Application to RPL-Based Route-Over LLNs
This specification also updates [RFC6550] and [RFC9010] in the case
of a route-over multilink subnet based on the RPL routing protocol,
to add multicast ingress replication in Non-Storing Mode and anycast
support in both Storing and Non-Storing modes. A 6LR that implements
the RPL extensions specified therein MUST also implement [RFC9010].
Figure 5 illustrates the classical situation of an LLN as a single
IPv6 subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root
for RPL operations and as Address Registrar for 6LoWPAN ND.
.- -- .
.-( ).
( Internet )
(___.________.___)
|
---+-------+--
|
+--------+
| 6LBR |
| (Root) |
+--------+
o o o o
o o o
o o o o o o
o o o LLN o +-------+
o o o | 6LR | RPL Router
o o o o +-------+
o o o o +-------+ RPL
o | 6LN | leaf
+-------+ L
o : LLN node
Figure 5: RPL-Based Route-Over LLN
A RPL leaf L acting as a 6LN registers its addresses and prefixes to
a RPL router acting as a 6LR, using a L2 unicast NS message with an
EARO as specified in [RFC8505] and [RFC9685]. Note that a RPL leaf
acting as 6LN may still be a border router for another routing
protocol, an access router for an IP link, or a virtual Router
serving virtual machines or applications within the same physical
node. Note also that a RPL-aware Leaf would preferably leverage RPL
directly to inject routes, to fully leverage the routing protocol.
The registration state is periodically renewed by the Registering
Node (the 6LN), before the lifetime indicated in the EARO expires (at
the 6LR). As for unicast IPv6 addresses, the 6LR uses an Extended
Duplicate Address Request/Confirmation (EDAR/EDAC) exchange with the
6LBR to notify the 6LBR of the presence of the listeners. With this
specification, a router that owns a prefix or provides reachability
to an external prefix but is not a RPL router can also register those
prefixes with the R flag set, to enable reachability to the prefix
within the RPL domain.
12.3. Application to a Shared Link
A shared link is a situation where more than one prefix is deployed
over an L2 link (say, a switched Ethernet fabric or a Wi-Fi Extended
Service Set (ESS) federating multiple Access Points (APs)), and not
necessarily all nodes are aware of all prefixes. Figure 6 depicts
such a situation, with two routers 6LR1 and 6LR2 that own respective
prefixes P1:: and P2:: and expose those in their RA messages over the
same link. Note that the shared link maybe operated with any
combination of NDP and SND as discussed in Section 7 of
[IPv6-over-NBMA].
.- -- .
.-( ).
( Internet )
(___.________.___)
|
+----+--+ +-------+
| P1::a | | P2::b |
| 6LR1 | | 6LR2 |
+---+---+ +---+---+
| |
----+--+------+---------+-+-------+---------+----
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|P1::c| |P2::d| |P2::e| |P1::f| |P1::g|
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 6: Shared Link
Say that 6LR1 is the router providing access to the outside, and 6LR2
is aware of 6LR1 as its default gateway. With this specification,
6LR2 registers P2:: to 6LR1, and 6LR1 installs a route to P2:: via
6LR2. This way, addresses that derive from P2:: can still be reached
via 6LR1 and then 6LR2. 6LR2 may then leverage ICMP Redirect
messages [RFC4861] to shorten the path between 6LR1 and the nodes
that own those addresses.
If P2 were delegated by 6LR1, e.g., using DHCPv6 [RFC9915], then the
expectation is that 6LR1 aggregates P1:: and P2:: in its
advertisements to the outside, and there is no need to set the R
flag. However, unless 6LR2 knows about such a situation, e.g.,
through configuration, 6LR2 SHOULD set the R flag requesting 6LR1 to
advertise P2:: so as to obtain reachability.
12.4. Application to a Hub Link with Stub Spokes
A hub link is a situation where stub links are deployed around a
backbone and interconnected by routers. Figure 7 depicts such a
situation, with one router 6LR1 serving the hub link and at least one
router like 6LR2 and 6LR3 providing connectivity from the stub links
to the hub link. In this example, say that there is one prefix on
each link -- P1:: on the hub link, and P2:: and P3:: on the stub
links.
+-----+ +-----+ +-----+ +-----+
|P2::s| |P2::d| |P2::e| |P2::f|
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
----+----+----+---------+--STUB-LINK--+-----
|
+---+---+ +-------+
| P2::r | | | .- --..
| 6LR2 | | 6LR1 +---- .-( ).
| P1::b | | P1::a | ( Internet )
+---+---+ +---+---+ (___._______.___)
| | |
-------+-+---------+--HUB-LINK--+-----+-- |
| | | |
+---+---+ +--+--+ +---+---+ |
| P1::c | |P1::n| | P1::q | |
| 6LR3 | +-----+ | 6LR4 +----+
| P3::m | | P3::a |
+---+---+ +---+---+
| |
----+--+------+---------+--STUB-LINK--+-+-----
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
|P3::h| |P3::i| |P3::j| |P3::k|
+-----+ +-----+ +-----+ +-----+
Figure 7: Hub and Stubs
As before, say that 6LR1 is the router providing access to the
outside, and 6LR2 is aware of 6LR1 as its default gateway. With this
specification, 6LR2 registers P2:: to 6LR1, and 6LR1 installs a route
to P2:: via 6LR2. This way, nodes on the stub link behind 6LR2 that
derive their addresses from P2:: can still be reached via 6LR1 and
then 6LR2. The same goes for 6LR3 and any other routers serving stub
links.
If P2 were delegated by 6LR1, then the expectation is that 6LR1
aggregates P1:: and P2:: in its advertisements to the outside, and
there is no need to set the R flag. However, unless 6LR2 knows about
such a situation, e.g., through configuration, 6LR2 SHOULD set the R
flag requesting 6LR1 to advertise P2:: so as to obtain reachability.
In this example, routers 6LR3 and 6LR4 both connect to the same stub
link where subnet P3 is installed. They may both register P3 to
6LR1, and 6LR1 will apply its own load-balancing logic to use either
of the routers.