< draft-ietf-6lo-multicast-registration-02.txt   draft-ietf-6lo-multicast-registration-03.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 6553, 8505, 9010 (if approved) 8 November 2021 Updates: 6550, 6553, 8505, 9010 (if approved) 13 December 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 12 May 2022 Expires: 16 June 2022
IPv6 Neighbor Discovery Multicast Address Listener Registration IPv6 Neighbor Discovery Multicast Address Listener Registration
draft-ietf-6lo-multicast-registration-02 draft-ietf-6lo-multicast-registration-03
Abstract Abstract
This document updates RFC 8505 to enable a listener to register an This document updates RFC 8505 to enable a listener to register an
IPv6 anycast or and subscribe to an IPv6 multicast address; the draft IPv6 anycast or and subscribe to an IPv6 multicast address; the draft
updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
new support for anycast addresses in Storing and Non-Storing Modes. new support for anycast addresses in Storing and Non-Storing Modes.
This document extends RFC 9010 to enable the 6LR to inject the This document extends RFC 9010 to enable the 6LR to inject the
anycast and multicast addresses in RPL. anycast and multicast addresses in RPL.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 May 2022. This Internet-Draft will expire on 16 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 9 4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 9
5. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10 5. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Updating MOP 3 . . . . . . . . . . . . . . . . . . . . . 10 5.1. Updating MOP 3 . . . . . . . . . . . . . . . . . . . . . 10
5.2. New Non-Storing Multicast MOP . . . . . . . . . . . . . . 10 5.2. New Non-Storing Multicast MOP . . . . . . . . . . . . . . 10
5.3. RPL Anycast Operation . . . . . . . . . . . . . . . . . . 11 5.3. RPL Anycast Operation . . . . . . . . . . . . . . . . . . 11
5.4. New RPL Target Option Flags . . . . . . . . . . . . . . . 12 5.4. New RPL Target Option Flags . . . . . . . . . . . . . . . 12
6. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 12 6. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 12
6.1. New EARO flag . . . . . . . . . . . . . . . . . . . . . . 13 6.1. New EARO flag . . . . . . . . . . . . . . . . . . . . . . 13
6.2. New EDAR Message Flag field . . . . . . . . . . . . . . . 14 6.2. New EDAR Message Flag field . . . . . . . . . . . . . . . 14
6.3. Registering Extensions . . . . . . . . . . . . . . . . . 15 6.3. Registering Extensions . . . . . . . . . . . . . . . . . 15
7. Updating RFC 9010 . . . . . . . . . . . . . . . . . . . . . . 16 7. Updating RFC 9010 . . . . . . . . . . . . . . . . . . . . . . 16
8. Deployment considerations . . . . . . . . . . . . . . . . . . 17 8. Leveraging RFC 8929 . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Deployment considerations . . . . . . . . . . . . . . . . . . 17
10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19
11.1. New EDAR Message Flags Subregistry . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11.2. New EARO flags . . . . . . . . . . . . . . . . . . . . . 20 12.1. New EDAR Message Flags Subregistry . . . . . . . . . . . 20
11.3. New RTO flags . . . . . . . . . . . . . . . . . . . . . 20 12.2. New EARO flags . . . . . . . . . . . . . . . . . . . . . 21
11.4. New RPL Mode of Operation . . . . . . . . . . . . . . . 21 12.3. New RTO flags . . . . . . . . . . . . . . . . . . . . . 21
11.5. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 21 12.4. New RPL Mode of Operation . . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12.5. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . 22
13. Normative References . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
14. Informative References . . . . . . . . . . . . . . . . . . . 23 14. Normative References . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 15. Informative References . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions, duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern. The radio (both transmitting or derive from that primary concern. The radio (both transmitting or
simply listening) is a major energy drain and the LLN protocols must simply listening) is a major energy drain and the LLN protocols must
be adapted to allow the nodes to remain sleeping with the radio be adapted to allow the nodes to remain sleeping with the radio
skipping to change at page 8, line 39 skipping to change at page 8, line 39
both Storing and Non-Storing modes. In Storing Mode the RPL router both Storing and Non-Storing modes. In Storing Mode the RPL router
accepts DAO from multiple children for the same anycast address, but accepts DAO from multiple children for the same anycast address, but
only forwards a packet to one of the children. In Non-Storing Mode, only forwards a packet to one of the children. In Non-Storing Mode,
the Root maintains the list of all the RPL nodes that announced the the Root maintains the list of all the RPL nodes that announced the
anycast address as Target, but forwards a given packet to only one of anycast address as Target, but forwards a given packet to only one of
them. them.
For backward compatibility, this specification allows to build a For backward compatibility, this specification allows to build a
single DODAG signaled as MOP 1, that conveys anycast, unicast and single DODAG signaled as MOP 1, that conveys anycast, unicast and
multicast packets using the same source routing mechanism, more in multicast packets using the same source routing mechanism, more in
Section 8. Section 9.
It is also possible to leverage this specification between the 6LN It is also possible to leverage this specification between the 6LN
and the 6LR for the registration of unicast, anycast and multicast and the 6LR for the registration of unicast, anycast and multicast
IPv6 addresses in networks that are not necessarily LLNs, and/or IPv6 addresses in networks that are not necessarily LLNs, and/or
where the routing protocol between the 6LR and above is not where the routing protocol between the 6LR and above is not
necessarily RPL. In that case, the distribution of packets between necessarily RPL. In that case, the distribution of packets between
the 6LR and the 6LNs may effectively rely on a broadcast or multicast the 6LR and the 6LNs may effectively rely on a broadcast or multicast
support at the lower layer. support at the lower layer.
For instance, it is possible to operate a RPL Instance in the new For instance, it is possible to operate a RPL Instance in the new
skipping to change at page 10, line 27 skipping to change at page 10, line 27
MOP 3 is a storing Mode of Operation. This operation builds a MOP 3 is a storing Mode of Operation. This operation builds a
multicast tree within the RPL DODAG for each multicast address. This multicast tree within the RPL DODAG for each multicast address. This
specification provides additional details for the MOP 3 operation. specification provides additional details for the MOP 3 operation.
The expectation in MOP 3 is that the unicast traffic also follows the The expectation in MOP 3 is that the unicast traffic also follows the
Storing Mode of Operation. But this is rarely the case in LLN Storing Mode of Operation. But this is rarely the case in LLN
deployments of RPL where the "Non-Storing Mode of Operation" (MOP 1) deployments of RPL where the "Non-Storing Mode of Operation" (MOP 1)
is the norm. Though it is preferred to build separate RPL Instances, is the norm. Though it is preferred to build separate RPL Instances,
one in MOP 1 and one in MOP 3, this specification allows to hybrid one in MOP 1 and one in MOP 3, this specification allows to hybrid
the Storing Mode for multicast and Non-Storing Mode for unicast in the Storing Mode for multicast and Non-Storing Mode for unicast in
the same RPL Instance, more in Section 8. the same RPL Instance, more in Section 9.
5.2. New Non-Storing Multicast MOP 5.2. New Non-Storing Multicast MOP
This specification adds a "Non-Storing Mode of Operation with This specification adds a "Non-Storing Mode of Operation with
multicast support" (MOP to be assigned by IANA) whereby the non- multicast support" (MOP to be assigned by IANA) whereby the non-
storing Mode DAO to the Root may contain multicast addresses in the storing Mode DAO to the Root may contain multicast addresses in the
RPL Target Option (RTO), whereas the Transit Information Option (TIO) RPL Target Option (RTO), whereas the Transit Information Option (TIO)
cannot. cannot.
In that mode, the RPL Root performs an ingress replication (IR) In that mode, the RPL Root performs an ingress replication (IR)
skipping to change at page 11, line 9 skipping to change at page 11, line 9
For a packet that is generated by the Root, this means that the Root For a packet that is generated by the Root, this means that the Root
builds a source routing header as shown in section 8.1.3 of builds a source routing header as shown in section 8.1.3 of
[RFC9008], but for which the last and only the last address is [RFC9008], but for which the last and only the last address is
multicast. For a packet that is not generated by the Root, the Root multicast. For a packet that is not generated by the Root, the Root
encapsulates the multicast packet as per section 8.2.4 of [RFC9008]. encapsulates the multicast packet as per section 8.2.4 of [RFC9008].
In that case, the outer header is purely unicast, and the In that case, the outer header is purely unicast, and the
encapsulated packet is purely multicast. encapsulated packet is purely multicast.
For this new mode as well, this specification allows to enable the For this new mode as well, this specification allows to enable the
operation in a MOP 1 brown field, more in Section 8. operation in a MOP 1 brown field, more in Section 9.
5.3. RPL Anycast Operation 5.3. RPL Anycast Operation
With multicast, the address has a recognizable format, and a With multicast, the address has a recognizable format, and a
multicast packet is to be delivered to all the active subscribers. multicast packet is to be delivered to all the active subscribers.
In contrast with anycast, the format of the address is not In contrast with anycast, the format of the address is not
distinguishable from that of unicast. A legacy node may issue a DAO distinguishable from that of unicast. A legacy node may issue a DAO
message without setting the A flag, the unicast behaviour may apply message without setting the A flag, the unicast behaviour may apply
to anycast traffic in a subDAGs. A target is routed as anycast by a to anycast traffic in a subDAGs. A target is routed as anycast by a
parent (or the Root) that received at least one DAO message for that parent (or the Root) that received at least one DAO message for that
skipping to change at page 17, line 5 skipping to change at page 16, line 47
* Upon receiving a packet directed to a multicast address for which * Upon receiving a packet directed to a multicast address for which
it has at least one registration, the 6LR delivers a copy of the it has at least one registration, the 6LR delivers a copy of the
packet as a unicast layer-2 frame to the LLA of each of the nodes packet as a unicast layer-2 frame to the LLA of each of the nodes
that registered to that multicast address. that registered to that multicast address.
* Upon receiving a packet directed to a multicast address for which * Upon receiving a packet directed to a multicast address for which
it has at least one registration, the 6LR delivers a copy of the it has at least one registration, the 6LR delivers a copy of the
packet as a unicast layer-2 frame to the LLA of exactly one of the packet as a unicast layer-2 frame to the LLA of exactly one of the
nodes that registered to that multicast address. nodes that registered to that multicast address.
8. Deployment considerations 8. Leveraging RFC 8929
Address-Protected Neighbor Discovery for Low-Power and Lossy Networks
[RFC8928] was defined to protect the ownership of unicast IPv6
addresses that are registered with [RFC8505].
With [RFC8928], it is possible for a node to autoconfigure a pair of
public and private keys and use them to sign the registration of
addresses that are either autoconfigured or obtained through other
methods.
The first hop router (the 6LR) may then validate a registration and
perform source address validation on packets coming from the sender
node (the 6LN).
Anycast and multicast addresses are not owned by one node. Multiple
nodes may subscribe to the same address. Also, anycast and multicast
addresses are not used to source traffic. In that context, the
method specified in [RFC8928] cannot be used with autoconfigured
keypairs to protect a single ownership.
For an anycast or a multicast address, it is still possible to
leverage [RFC8928] to enforce the right to subscribe. A keypair MUST
be associated with the address before it is deployed, and a ROVR MUST
be generated from that keypair as specified in [RFC8928]. The
address and the ROVR MUST then be installed in the 6LBR so it can
recognize the address and compare the ROVR on the first registration.
The keypair MUST then be provisioned in each node that needs to
subscribe to the anycast or multicast address, so the node can follow
the steps in [RFC8928] to register the address.
9. Deployment considerations
With this specification, a RPL DODAG forms a realm, and multiple RPL With this specification, a RPL DODAG forms a realm, and multiple RPL
DODAGs may federated in a single RPL Instance administratively. This DODAGs may federated in a single RPL Instance administratively. This
means that a multicast address that needs to span a RPL DODAG MUST means that a multicast address that needs to span a RPL DODAG MUST
use a scope of Realm-Local whereas a multicast address that needs to use a scope of Realm-Local whereas a multicast address that needs to
span a RPL Instance MUST use a scope of Admin-Local as discussed in span a RPL Instance MUST use a scope of Admin-Local as discussed in
section 3 of "IPv6 Multicast Address Scopes" [RFC7346]. section 3 of "IPv6 Multicast Address Scopes" [RFC7346].
"IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] enables to embed "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] enables to embed
IPv4 addresses in IPv6 addresses. The Root of a DODAG may leverage IPv4 addresses in IPv6 addresses. The Root of a DODAG may leverage
skipping to change at page 19, line 5 skipping to change at page 19, line 26
* The support of multicast and/or anycast in the RPL Instance SHOULD * The support of multicast and/or anycast in the RPL Instance SHOULD
be signaled by the 6LRs to the 6LN using a 6CIO, see Section 4. be signaled by the 6LRs to the 6LN using a 6CIO, see Section 4.
* Alternatively, the support of multicast in the RPL domain can be * Alternatively, the support of multicast in the RPL domain can be
globally known by other means such as configuration or external globally known by other means such as configuration or external
information such as support of a version of an industry standard information such as support of a version of an industry standard
that mandates it. In that case, all the routers MUST support the that mandates it. In that case, all the routers MUST support the
mixed mode. mixed mode.
9. Security Considerations 10. Security Considerations
This specification extends [RFC8505], and the security section of This specification extends [RFC8505], and the security section of
that document also applies to this document. In particular, the link that document also applies to this document. In particular, the link
layer SHOULD be sufficiently protected to prevent rogue access. layer SHOULD be sufficiently protected to prevent rogue access.
10. Backward Compatibility Section 8 leverages [RFC8928] to prevent an unwanted subscriber to
register for an anycast of a multicast address. This mechanism comes
with a keypair that is shared between all subscribers. A shared key
is prone to be stolen and the level of protection can only go down
with time.
It is possible to update the keys associated to an address in all the
6LNs, but the flow is not clearly documented and may not complete in
due time for all nodes in LLN use cases. It may be simpler to
install a all-new address with new keys over a period of time, and
switch the traffic to that address when the migreaiton is complete.
11. Backward Compatibility
A legacy 6LN will not register multicast addresses and the service A legacy 6LN will not register multicast addresses and the service
will be the same when the network is upgraded. A legacy 6LR will not will be the same when the network is upgraded. A legacy 6LR will not
set the M flag in the 6CIO and an upgraded 6LN will not register set the M flag in the 6CIO and an upgraded 6LN will not register
multicast addresses. multicast addresses.
Upon an EDAR message, a legacy 6LBR may not realize that the address Upon an EDAR message, a legacy 6LBR may not realize that the address
being registered is anycast or multicast, and return that it is being registered is anycast or multicast, and return that it is
duplicate in the EDAC status. The 6LR MUST ignore a duplicate status duplicate in the EDAC status. The 6LR MUST ignore a duplicate status
in the EDAR for anycast and multicast addresses. in the EDAR for anycast and multicast addresses.
As detailed in Section 8, it is possible to add multicast on an As detailed in Section 9, it is possible to add multicast on an
existing MOP 1 deployment. existing MOP 1 deployment.
The combination of a multicast address and the M flag set to 0 in an The combination of a multicast address and the M flag set to 0 in an
RTO in a MOP 3 RPL Instance is understood by the receiver that RTO in a MOP 3 RPL Instance is understood by the receiver that
supports this specification (the parent) as an indication that the supports this specification (the parent) as an indication that the
sender (child) does not support this specification, but the RTO is sender (child) does not support this specification, but the RTO is
accepted and processed as if the M flag was set for backward accepted and processed as if the M flag was set for backward
compatibility. compatibility.
When the DODAG is operated in MOP 3, a legacy node will not set the M When the DODAG is operated in MOP 3, a legacy node will not set the M
flag and still expect multicast service as specified in section 12 of flag and still expect multicast service as specified in section 12 of
[RFC6550]. In MOP 3 an RTO that is received with a target that is [RFC6550]. In MOP 3 an RTO that is received with a target that is
multicast and the M bit set to 0 MUST be considered as multicast and multicast and the M bit set to 0 MUST be considered as multicast and
MUST be processed as if the M flag is set. MUST be processed as if the M flag is set.
11. IANA Considerations 12. IANA Considerations
Note to RFC Editor, to be removed: please replace "This RFC" Note to RFC Editor, to be removed: please replace "This RFC"
throughout this document by the RFC number for this specification throughout this document by the RFC number for this specification
once it is allocated. Also, the I Field is defined in [RFC9010] but once it is allocated. Also, the I Field is defined in [RFC9010] but
is missing from the subregistry, so the bit positions must be added is missing from the subregistry, so the bit positions must be added
for completeness. for completeness.
IANA is requested to make changes under the "Internet Control Message IANA is requested to make changes under the "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing
Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL] Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL]
registries, as follows: registries, as follows:
11.1. New EDAR Message Flags Subregistry 12.1. New EDAR Message Flags Subregistry
IANA is requested to create a new "EDAR Message Flags" subregistry of IANA is requested to create a new "EDAR Message Flags" subregistry of
the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" the "Internet Control Message Protocol version 6 (ICMPv6) Parameters"
registry as indicated in Table 1: registry as indicated in Table 1:
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| Bit Number | Meaning | Reference | | Bit Number | Meaning | Reference |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| 0 (suggested) | A flag: Registered | This RFC | | 0 (suggested) | A flag: Registered | This RFC |
| | Address is Anycast | | | | Address is Anycast | |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| 1 (suggested) | M flag: Registered | This RFC | | 1 (suggested) | M flag: Registered | This RFC |
| | Address is Multicast | | | | Address is Multicast | |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
Table 1: EDAR Message flags Table 1: EDAR Message flags
11.2. New EARO flags 12.2. New EARO flags
IANA is requested to make additions to the "Address Registration IANA is requested to make additions to the "Address Registration
Option Flags" [IANA.ICMP.ARO.FLG] of the "Internet Control Message Option Flags" [IANA.ICMP.ARO.FLG] of the "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" registry as indicated in Protocol version 6 (ICMPv6) Parameters" registry as indicated in
Table 2: Table 2:
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| ARO flag | Meaning | Reference | | ARO flag | Meaning | Reference |
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| 2 (suggested) | A flag: Registration | This RFC | | 2 (suggested) | A flag: Registration | This RFC |
| | for Anycast Address | | | | for Anycast Address | |
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| 3 (suggested) | M flag: Registration | This RFC | | 3 (suggested) | M flag: Registration | This RFC |
| | for Multicast Address | | | | for Multicast Address | |
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| 4 and 5 | "I" Field | RFC 8505 | | 4 and 5 | "I" Field | RFC 8505 |
+---------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
Table 2: New ARO flags Table 2: New ARO flags
11.3. New RTO flags 12.3. New RTO flags
IANA is requested to make additions to the "RPL Target Option Flags" IANA is requested to make additions to the "RPL Target Option Flags"
[IANA.RPL.RTO.FLG] subregistry of the "Routing Protocol for Low Power [IANA.RPL.RTO.FLG] subregistry of the "Routing Protocol for Low Power
and Lossy Networks (RPL)" registry as indicated in Table 3: and Lossy Networks (RPL)" registry as indicated in Table 3:
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| Bit Number | Meaning | Reference | | Bit Number | Meaning | Reference |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| 2 (suggested) | A flag: Registered | This RFC | | 2 (suggested) | A flag: Registered | This RFC |
| | Address is Anycast | | | | Address is Anycast | |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
| 3 (suggested) | M flag: Registered | This RFC | | 3 (suggested) | M flag: Registered | This RFC |
| | Address is Multicast | | | | Address is Multicast | |
+---------------+---------------------------------------+-----------+ +---------------+---------------------------------------+-----------+
Table 3: New RTO flags Table 3: New RTO flags
11.4. New RPL Mode of Operation 12.4. New RPL Mode of Operation
IANA is requested to make an addition to the "Mode of Operation" IANA is requested to make an addition to the "Mode of Operation"
[IANA.RPL.MOP] subregistry of the "Routing Protocol for Low Power and [IANA.RPL.MOP] subregistry of the "Routing Protocol for Low Power and
Lossy Networks (RPL)" registry as indicated in Table 4: Lossy Networks (RPL)" registry as indicated in Table 4:
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
| Value | Description | Reference | | Value | Description | Reference |
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
| 5 (suggested) | Non-Storing Mode of Operation | This RFC | | 5 (suggested) | Non-Storing Mode of Operation | This RFC |
| | with multicast support | | | | with multicast support | |
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
Table 4: New RPL Mode of Operation Table 4: New RPL Mode of Operation
11.5. New 6LoWPAN Capability Bits 12.5. New 6LoWPAN Capability Bits
IANA is requested to make an addition to the "6LoWPAN Capability IANA is requested to make an addition to the "6LoWPAN Capability
Bits" [IANA.ICMP.6CIO] subregistry subregistry of the "Internet Bits" [IANA.ICMP.6CIO] subregistry subregistry of the "Internet
Control Message Protocol version 6 (ICMPv6) Parameters" registry as Control Message Protocol version 6 (ICMPv6) Parameters" registry as
indicated in Table 5: indicated in Table 5:
+----------------+------------------------------------+-----------+ +----------------+------------------------------------+-----------+
| Capability Bit | Meaning | Reference | | Capability Bit | Meaning | Reference |
+----------------+------------------------------------+-----------+ +----------------+------------------------------------+-----------+
| 8 (suggested) | M flag: Registration for Multicast | This RFC | | 8 (suggested) | M flag: Registration for Multicast | This RFC |
| | and Anycast Addresses Supported | | | | and Anycast Addresses Supported | |
+----------------+------------------------------------+-----------+ +----------------+------------------------------------+-----------+
Table 5: New 6LoWPAN Capability Bits Table 5: New 6LoWPAN Capability Bits
12. Acknowledgments 13. Acknowledgments
13. Normative References 14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
August 2002, <https://www.rfc-editor.org/info/rfc3306>. August 2002, <https://www.rfc-editor.org/info/rfc3306>.
skipping to change at page 23, line 16 skipping to change at page 24, line 16
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks) (Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>. <https://www.rfc-editor.org/info/rfc9010>.
[IANA.ICMP] [IANA.ICMP]
IANA, "IANA Registry for ICMPv6", IANA, IANA, "IANA Registry for ICMPv6", IANA,
https://www.iana.org/assignments/icmpv6-parameters/ https://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml. icmpv6-parameters.xhtml.
skipping to change at page 23, line 49 skipping to change at page 25, line 5
[IANA.RPL.RTO.FLG] [IANA.RPL.RTO.FLG]
IANA, "IANA Sub-Registry for the RTO Flags", IANA, IANA, "IANA Sub-Registry for the RTO Flags", IANA,
https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-target- https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-target-
option-flags. option-flags.
[IANA.RPL.MOP] [IANA.RPL.MOP]
IANA, "IANA Sub-Registry for the RPL Mode of Operation", IANA, "IANA Sub-Registry for the RPL Mode of Operation",
IANA, https://www.iana.org/assignments/rpl/rpl.xhtml#mop. IANA, https://www.iana.org/assignments/rpl/rpl.xhtml#mop.
14. Informative References 15. Informative References
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
 End of changes. 23 change blocks. 
36 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/