rfc9008v1.txt   rfc9008.txt 
skipping to change at line 125 skipping to change at line 125
13. References 13. References
13.1. Normative References 13.1. Normative References
13.2. Informative References 13.2. Informative References
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
[RFC6550] is a routing protocol for constrained networks. [RFC6553] [RFC6550] is a routing protocol for constrained networks. [RFC6553]
defines the RPL Option carried within the IPv6 Hop-by-Hop header to defines the RPL Option carried within the IPv6 Hop-by-Hop Options
carry the RPLInstanceID and quickly identify inconsistencies (loops) header to carry the RPLInstanceID and quickly identify
in the routing topology. The RPL Option is commonly referred to as inconsistencies (loops) in the routing topology. The RPL Option is
the RPL Packet Information (RPI), although the RPI is the routing commonly referred to as the RPL Packet Information (RPI), although
information that is defined in [RFC6550] and transported in the RPL the RPI is the routing information that is defined in [RFC6550] and
Option. RFC 6554 [RFC6554] defines the "RPL Source Route Header" transported in the RPL Option. RFC 6554 [RFC6554] defines the "RPL
(RH3), an IPv6 extension header to deliver datagrams within a RPL Source Route Header" (RH3), an IPv6 extension header to deliver
routing domain, particularly in Non-Storing mode. datagrams within a RPL routing domain, particularly in Non-Storing
mode.
These various items are referred to as RPL artifacts, and they are These various items are referred to as RPL artifacts, and they are
seen on all of the data plane traffic that occurs in RPL-routed seen on all of the data plane traffic that occurs in RPL-routed
networks; they do not, in general, appear on the RPL control plane at networks; they do not, in general, appear on the RPL control plane at
all, which is mostly hop-by-hop traffic (one exception being all, which is mostly hop-by-hop traffic (one exception being
Destination Advertisement Object (DAO) messages in Non-Storing mode). Destination Advertisement Object (DAO) messages in Non-Storing mode).
It has become clear from attempts to do multi-vendor It has become clear from attempts to do multi-vendor
interoperability, and from a desire to compress as many of the above interoperability, and from a desire to compress as many of the above
artifacts as possible, that not all implementers agree when artifacts artifacts as possible, that not all implementers agree when artifacts
skipping to change at line 207 skipping to change at line 208
Consumed: A Routing Header is consumed when the Segments Left field Consumed: A Routing Header is consumed when the Segments Left field
is zero, which indicates that the destination in the IPv6 header is zero, which indicates that the destination in the IPv6 header
is the final destination of the packet and that the hops in the is the final destination of the packet and that the hops in the
Routing Header have been traversed. Routing Header have been traversed.
RPL Leaf: An IPv6 host that is attached to a RPL router and obtains RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
connectivity through a RPL Destination-Oriented Directed Acyclic connectivity through a RPL Destination-Oriented Directed Acyclic
Graph (DODAG). As an IPv6 node, a RPL leaf is expected to ignore Graph (DODAG). As an IPv6 node, a RPL leaf is expected to ignore
a consumed Routing Header, and as an IPv6 host, it is expected to a consumed Routing Header, and as an IPv6 host, it is expected to
ignore a Hop-by-Hop header. Thus, a RPL leaf can correctly ignore a Hop-by-Hop Options header. Thus, a RPL leaf can
receive a packet with RPL artifacts. On the other hand, a RPL correctly receive a packet with RPL artifacts. On the other hand,
leaf is not expected to generate RPL artifacts or to support IP- a RPL leaf is not expected to generate RPL artifacts or to support
in-IP encapsulation. For simplification, this document uses the IP-in-IP encapsulation. For simplification, this document uses
standalone term leaf to mean a RPL leaf. the standalone term leaf to mean a RPL leaf.
RPL Packet Information (RPI): The information defined abstractly in RPL Packet Information (RPI): The information defined abstractly in
[RFC6550] to be placed in IP packets. The term is commonly used, [RFC6550] to be placed in IP packets. The term is commonly used,
including in this document, to refer to the RPL Option [RFC6553] including in this document, to refer to the RPL Option [RFC6553]
that transports that abstract information in an IPv6 Hop-by-Hop that transports that abstract information in an IPv6 Hop-by-Hop
header. [RFC8138] provides an alternate (more compressed) Options header. [RFC8138] provides an alternate (more compressed)
formatting for the same abstract information. formatting for the same abstract information.
RPL-Aware Node (RAN): A device that implements RPL. Please note RPL-Aware Node (RAN): A device that implements RPL. Please note
that the device can be found inside the LLN or outside LLN. that the device can be found inside the LLN or outside LLN.
RPL-Aware Leaf (RAL): A RPL-aware node that is also a RPL leaf. RPL-Aware Leaf (RAL): A RPL-aware node that is also a RPL leaf.
RPL-Unaware Node: A device that does not implement RPL, thus the RPL-Unaware Node: A device that does not implement RPL, thus the
device is RPL unaware. Please note that the device can be found device is RPL unaware. Please note that the device can be found
inside the LLN. inside the LLN.
skipping to change at line 332 skipping to change at line 333
has been learned through an alternate protocol, for instance, a route has been learned through an alternate protocol, for instance, a route
to a prefix that is outside the RPL domain but reachable via a 6LR. to a prefix that is outside the RPL domain but reachable via a 6LR.
Being outside of the RPL domain, a node that is reached via an Being outside of the RPL domain, a node that is reached via an
external target cannot be guaranteed to ignore the RPL artifacts and external target cannot be guaranteed to ignore the RPL artifacts and
cannot be expected to process the compression defined in [RFC8138] cannot be expected to process the compression defined in [RFC8138]
correctly. This means that the RPL artifacts should be contained in correctly. This means that the RPL artifacts should be contained in
an IP-in-IP encapsulation that is removed by the 6LR, and that any an IP-in-IP encapsulation that is removed by the 6LR, and that any
remaining compression should be expanded by the 6LR before it remaining compression should be expanded by the 6LR before it
forwards a packet outside the RPL domain. forwards a packet outside the RPL domain.
This specification updates [RFC6550] to RECOMMEND that external This specification updates [RFC6550] to say that advertising external
targets are advertised using Non-Storing mode DAO messaging even in a targets using Non-Storing mode DAO messaging even in a Storing mode
Storing mode network. This way, external routes are not advertised network is RECOMMENDED. This way, external routes are not advertised
within the DODAG, and all packets to an external target reach the within the DODAG, and all packets to an external target reach the
root like normal Non-Storing mode traffic. The Non-Storing mode DAO root like normal Non-Storing mode traffic. The Non-Storing mode DAO
informs the root of the address of the 6LR that injects the external informs the root of the address of the 6LR that injects the external
route, and the root uses IP-in-IP encapsulation to that 6LR, which route, and the root uses IP-in-IP encapsulation to that 6LR, which
terminates the IP-in-IP tunnel and forwards the original packet terminates the IP-in-IP tunnel and forwards the original packet
outside the RPL domain free of RPL artifacts. outside the RPL domain free of RPL artifacts.
In the other direction, for traffic coming from an external target In the other direction, for traffic coming from an external target
into the LLN, the parent (6LR) that injects the traffic always into the LLN, the parent (6LR) that injects the traffic always
encapsulates to the root. This whole operation is transparent to encapsulates to the root. This whole operation is transparent to
intermediate routers that only see traffic between the 6LR and the intermediate routers that only see traffic between the 6LR and the
root, and only the root and the 6LRs that inject external routes in root, and only the root and the 6LRs that inject external routes in
the network need to be upgraded to add this function to the network. the network need to be upgraded to add this function to the network.
A RUL is a special case of external target when the target is A RUL is a special case of external target when the target is
actually a host, and it is known to support a consumed Routing Header actually a host, and it is known to support a consumed Routing Header
and to ignore a Hop-by-Hop header as prescribed by [RFC8200]. The and to ignore a Hop-by-Hop Options header as prescribed by [RFC8200].
target may have been learned through an external routing protocol or The target may have been learned through an external routing protocol
may have been registered to the 6LR using [RFC8505]. or may have been registered to the 6LR using [RFC8505].
In order to enable IP-in-IP all the way to a 6LN, it is beneficial In order to enable IP-in-IP all the way to a 6LN, it is beneficial
that the 6LN supports decapsulating IP-in-IP, but that is not assumed that the 6LN supports decapsulating IP-in-IP, but that is not assumed
by [RFC8504]. If the 6LN is a RUL, the root that encapsulates a by [RFC8504]. If the 6LN is a RUL, the root that encapsulates a
packet SHOULD terminate the tunnel at a parent 6LR unless it is aware packet SHOULD terminate the tunnel at a parent 6LR unless it is aware
that the RUL supports IP-in-IP decapsulation. that the RUL supports IP-in-IP decapsulation.
A node that is reachable over an external route is not expected to A node that is reachable over an external route is not expected to
support [RFC8138]. Whether a decapsulation took place or not and support [RFC8138]. Whether a decapsulation took place or not and
even when the 6LR is delivering the packet to a RUL, the 6LR that even when the 6LR is delivering the packet to a RUL, the 6LR that
skipping to change at line 387 skipping to change at line 388
[RFC6550], Section 6.3.1. [RFC6550], Section 6.3.1.
In addition, this document reserves MOP value 7 for future expansion. In addition, this document reserves MOP value 7 for future expansion.
See Sections 11.2 and 11.3. See Sections 11.2 and 11.3.
4.1.3. Indicating the New RPI in the DODAG Configuration Option Flag 4.1.3. Indicating the New RPI in the DODAG Configuration Option Flag
In order to avoid a flag day caused by lack of interoperation between In order to avoid a flag day caused by lack of interoperation between
nodes of the new RPI Option Type (0x23) and old RPI Option Type nodes of the new RPI Option Type (0x23) and old RPI Option Type
(0x63), this section defines a flag in the DIO Configuration option, (0x63), this section defines a flag in the DODAG Configuration
to indicate when the new RPI Option Type can be safely used. This option, to indicate when the new RPI Option Type can be safely used.
means that the flag is going to indicate the value of Option Type This means that the flag is going to indicate the value of Option
that the network will be using for the RPL Option. Thus, when a node Type that the network will be using for the RPL Option. Thus, when a
joins to a network, it will know which value to use. With this, RPL- node joins to a network, it will know which value to use. With this,
capable nodes know if it is safe to use 0x23 when creating a new RPL RPL-capable nodes know if it is safe to use 0x23 when creating a new
Option. A node that forwards a packet with an RPI MUST NOT modify RPL Option. A node that forwards a packet with an RPI MUST NOT
the Option Type of the RPL Option. modify the Option Type of the RPL Option.
This is done using a DODAG Configuration option flag that will signal This is done using a DODAG Configuration option flag that will signal
"RPI 0x23 enable" and propagate through the network. Section 6.3.1 "RPI 0x23 enable" and propagate through the network. Section 6.3.1
of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base
Object. The flag is defined only for MOP value between 0 to 6. Object. The flag is defined only for MOP value between 0 to 6.
For a MOP value of 7, a node MUST use the RPI 0x23 option. For a MOP value of 7, a node MUST use the RPI 0x23 option.
As stated in [RFC6550], the DODAG Configuration option is present in As stated in [RFC6550], the DODAG Configuration option is present in
DIO messages. The DODAG Configuration option distributes DIO messages. The DODAG Configuration option distributes
skipping to change at line 467 skipping to change at line 468
+===========+=====+=====+=======+=============+===========+ +===========+=====+=====+=======+=============+===========+
| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] |
+-----------+-----+-----+-------+-------------+-----------+ +-----------+-----+-----+-------+-------------+-----------+
Table 2: Option Type in RPL Option Table 2: Option Type in RPL Option
This document illustrates that it is not always possible to know for This document illustrates that it is not always possible to know for
sure at the source whether a packet will travel only within the RPL sure at the source whether a packet will travel only within the RPL
domain or whether it will leave it. domain or whether it will leave it.
At the time [RFC6553] was published, leaking a Hop-by-Hop header in At the time [RFC6553] was published, leaking a Hop-by-Hop Options
the outer IPv6 header chain could potentially impact core routers in header in the outer IPv6 header chain could potentially impact core
the Internet. So at that time, it was decided to encapsulate any routers in the Internet. So at that time, it was decided to
packet with a RPL Option using IPv6-in-IPv6 in all cases where it was encapsulate any packet with a RPL Option using IPv6-in-IPv6 in all
unclear whether the packet would remain within the RPL domain. In cases where it was unclear whether the packet would remain within the
the exception case where a packet would still leak, the Option Type RPL domain. In the exception case where a packet would still leak,
would ensure that the first router in the Internet that does not the Option Type would ensure that the first router in the Internet
recognize the option would drop the packet and protect the rest of that does not recognize the option would drop the packet and protect
the network. the rest of the network.
Even with [RFC8138], where the IPv6-in-IPv6 header is compressed, Even with [RFC8138], where the IPv6-in-IPv6 header is compressed,
this approach yields extra bytes in a packet; this means consuming this approach yields extra bytes in a packet; this means consuming
more energy and more bandwidth, incurring higher chances of loss, and more energy and more bandwidth, incurring higher chances of loss, and
possibly causing a fragmentation at the 6LoWPAN level. This impacts possibly causing a fragmentation at the 6LoWPAN level. This impacts
the daily operation of constrained devices for a case that generally the daily operation of constrained devices for a case that generally
does not happen and would not heavily impact the core anyway. does not happen and would not heavily impact the core anyway.
While the intention was and remains that the Hop-by-Hop header with a While the intention was and remains that the Hop-by-Hop Options
RPL Option should be confined within the RPL domain, this header with a RPL Option should be confined within the RPL domain,
specification modifies this behavior in order to reduce the this specification modifies this behavior in order to reduce the
dependency on IPv6-in-IPv6 and protect the constrained devices. dependency on IPv6-in-IPv6 and protect the constrained devices.
Section 4 of [RFC8200] clarifies the behavior of routers in the Section 4 of [RFC8200] clarifies the behavior of routers in the
Internet as follows: "it is now expected that nodes along a packet's Internet as follows: "it is now expected that nodes along a packet's
delivery path only examine and process the Hop-by-Hop Options header delivery path only examine and process the Hop-by-Hop Options header
if explicitly configured to do so." if explicitly configured to do so."
When unclear about the travel of a packet, it becomes preferable for When unclear about the travel of a packet, it becomes preferable for
a source not to encapsulate, accepting the fact that the packet may a source not to encapsulate, accepting the fact that the packet may
leave the RPL domain on its way to its destination. In that event, leave the RPL domain on its way to its destination. In that event,
the packet should reach its destination and should not be discarded the packet should reach its destination and should not be discarded
by the first node that does not recognize the RPL Option. However, by the first node that does not recognize the RPL Option. However,
with the current value of the Option Type, if a node in the Internet with the current value of the Option Type, if a node in the Internet
is configured to process the Hop-by-Hop header, and if such a node is configured to process the Hop-by-Hop Options header, and if such a
encounters an Option Type with the first two bits set to 01 and the node encounters an Option Type with the first two bits set to 01 and
node conforms to [RFC8200], it will drop the packet. Host systems the node conforms to [RFC8200], it will drop the packet. Host
should do the same, irrespective of the configuration. systems should do the same, irrespective of the configuration.
Thus, this document updates the Option Type of the RPL Option Thus, this document updates the Option Type of the RPL Option
[RFC6553], naming it RPI Option Type for simplicity (Table 3): the [RFC6553], naming it RPI Option Type for simplicity (Table 3): the
two high order bits MUST be set to '00', and the third bit is equal two high order bits MUST be set to '00', and the third bit is equal
to '1'. The first two bits indicate that the IPv6 node MUST skip to '1'. The first two bits indicate that the IPv6 node MUST skip
over this option and continue processing the header ([RFC8200], over this option and continue processing the header ([RFC8200],
Section 4.2) if it doesn't recognize the Option Type, and the third Section 4.2) if it doesn't recognize the Option Type, and the third
bit continues to be set to indicate that the Option Data may change bit continues to be set to indicate that the Option Data may change
en route. The rightmost five bits remain at 0x3(00011). This en route. The rightmost five bits remain at 0x3(00011). This
ensures that a packet that leaves the RPL domain of an LLN (or that ensures that a packet that leaves the RPL domain of an LLN (or that
skipping to change at line 550 skipping to change at line 551
header. header.
When forwarding packets, implementations SHOULD use the same value of When forwarding packets, implementations SHOULD use the same value of
RPI Type as was received. This is required because the RPI Option RPI Type as was received. This is required because the RPI Option
Type does not change en route ([RFC8200], Section 4.2). It allows Type does not change en route ([RFC8200], Section 4.2). It allows
the network to be incrementally upgraded and allows the DODAG root to the network to be incrementally upgraded and allows the DODAG root to
know which parts of the network have been upgraded. know which parts of the network have been upgraded.
When originating new packets, implementations should have an option When originating new packets, implementations should have an option
to determine which value to originate with. This option is to determine which value to originate with. This option is
controlled by the DIO Configuration option (Section 4.1.3). controlled by the DODAG Configuration option (Section 4.1.3).
The change of RPI Option Type from 0x63 to 0x23 makes all nodes that The change of RPI Option Type from 0x63 to 0x23 makes all nodes that
are compliant with Section 4.2 of [RFC8200] tolerant of the RPL are compliant with Section 4.2 of [RFC8200] tolerant of the RPL
artifacts. There is no longer a need to remove the artifacts when artifacts. There is no longer a need to remove the artifacts when
sending traffic to the Internet. This change clarifies when to use sending traffic to the Internet. This change clarifies when to use
IPv6-in-IPv6 headers and how to address them: the Hop-by-Hop Options IPv6-in-IPv6 headers and how to address them: the Hop-by-Hop Options
header containing the RPI MUST always be added when 6LRs originate header containing the RPI MUST always be added when 6LRs originate
packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST
always be added when a 6LR finds that it needs to insert a Hop-by-Hop always be added when a 6LR finds that it needs to insert a Hop-by-Hop
Options header containing the RPL Option. The IPv6-in-IPv6 header is Options header containing the RPL Option. The IPv6-in-IPv6 header is
skipping to change at line 602 skipping to change at line 603
Section 7 of [RFC8138] documents how to compress the IPv6-in-IPv6 Section 7 of [RFC8138] documents how to compress the IPv6-in-IPv6
header. header.
There are potential significant advantages to having a single code There are potential significant advantages to having a single code
path that always processes IPv6-in-IPv6 headers with no conditional path that always processes IPv6-in-IPv6 headers with no conditional
branches. branches.
In Storing mode, the scenarios where the flow goes from RAL to RUL In Storing mode, the scenarios where the flow goes from RAL to RUL
and RUL to RUL include compression of the IPv6-in-IPv6 and RPI and RUL to RUL include compression of the IPv6-in-IPv6 and RPI
headers. The use of the IPv6-in-IPv6 header is MANDATORY in this headers. The IPv6-in-IPv6 header MUST be used in this case, and it
case, and it SHOULD be compressed with [RFC8138], Section 7. SHOULD be compressed as specified in [RFC8138], Section 7. Figure 2
Figure 2 illustrates the case in Storing mode where the packet is illustrates the case in Storing mode where the packet is received
received from the Internet, then the root encapsulates the packet to from the Internet, then the root encapsulates the packet to insert
insert the RPI. In that example, the leaf is not known to support the RPI. In that example, the leaf is not known to support RFC 8138,
RFC 8138, and the packet is encapsulated to the 6LR that is the and the packet is encapsulated to the 6LR that is the parent and last
parent and last hop to the final destination. hop to the final destination.
+-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-... +-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-...
|11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld |Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-...
<-4bytes-> <- RFC 6282 -> <-4bytes-> <- RFC 6282 ->
No RPL artifact No RPL artifact
Figure 2: RPI Inserted by the Root in Storing Mode Figure 2: RPI Inserted by the Root in Storing Mode
skipping to change at line 758 skipping to change at line 759
RUL to RAL RUL to RAL
RUL to RUL RUL to RUL
This document is consistent with the rule that a header cannot be This document is consistent with the rule that a header cannot be
inserted or removed on the fly inside an IPv6 packet that is being inserted or removed on the fly inside an IPv6 packet that is being
routed. This is a fundamental precept of the IPv6 architecture as routed. This is a fundamental precept of the IPv6 architecture as
outlined in [RFC8200]. outlined in [RFC8200].
As the rank information in the RPI artifact is changed at each hop, As the Rank information in the RPI artifact is changed at each hop,
it will typically be zero when it arrives at the DODAG root. The it will typically be zero when it arrives at the DODAG root. The
DODAG root MUST force it to zero when passing the packet out to the DODAG root MUST force it to zero when passing the packet out to the
Internet. The Internet will therefore not see any SenderRank Internet. The Internet will therefore not see any SenderRank
information. information.
Despite being legal to leave the RPI artifact in place, an Despite being legal to leave the RPI artifact in place, an
intermediate router that needs to add an extension header (e.g., RH3 intermediate router that needs to add an extension header (e.g., RH3
or RPL Option) MUST still encapsulate the packet in an (additional) or RPL Option) MUST still encapsulate the packet in an (additional)
outer IP header. The new header is placed after this new outer IP outer IP header. The new header is placed after this new outer IP
header. header.
A corollary is that an intermediate router can remove an RH3 or RPL A corollary is that an intermediate router can remove an RH3 or RPL
Option only if it is placed in an encapsulating IPv6 header that is Option only if it is placed in an encapsulating IPv6 header that is
addressed _to_ this intermediate router. When doing the above, the addressed _to_ this intermediate router. When doing the above, the
whole encapsulating header must be removed. (A replacement may be whole encapsulating header must be removed. (A replacement may be
added.) This sometimes can result in outer IP headers being added.)
addressed to the next-hop router using a link-local address.
Both the RPL Option and the RH3 headers may be modified in very Both the RPL Option and the RH3 headers may be modified in very
specific ways by routers on the path of the packet without the need specific ways by routers on the path of the packet without the need
to add and remove an encapsulating header. Both headers were to add and remove an encapsulating header. Both headers were
designed with this modification in mind, and both the RPL RH3 and the designed with this modification in mind, and both the RPL RH3 and the
RPL Option are marked mutable but recoverable: so an IPsec RPL Option are marked mutable but recoverable: so an IPsec
Authentication Header (AH) can be applied across these headers, but Authentication Header (AH) can be applied across these headers, but
it cannot secure the values that mutate. it cannot secure the values that mutate.
The RPI MUST be present in every single RPL data packet. The RPI MUST be present in every single RPL data packet.
Prior to [RFC8138], there was significant interest in creating an Prior to [RFC8138], there was significant interest in creating an
exception to this rule and removing the RPI for Downward flows in exception to this rule and removing the RPI for Downward flows in
Non-Storing mode. This exception covered a very small number of Non-Storing mode. This exception covered a very small number of
cases, and caused significant interoperability challenges while cases, and caused significant interoperability challenges while
adding significant interest in the code and tests. The ability to adding significant interest in the code and tests. The ability to
compress the RPI down to three bytes or less removes much of the compress the RPI down to three bytes or less removes much of the
pressure to optimize this any further [ACP]. pressure to optimize this any further.
Throughout the following subsections, the examples are described in Throughout the following subsections, the examples are described in
more detail in the first subsections, and more concisely in the later more detail in the first subsections, and more concisely in the later
ones. ones.
The use cases are delineated based on the following IPV6 and RPL The use cases are delineated based on the following IPV6 and RPL
mandates: mandates:
The RPI has to be in every packet that traverses the LLN. The RPI has to be in every packet that traverses the LLN.
skipping to change at line 945 skipping to change at line 945
root to RAL root to RAL
RUL to root RUL to root
root to RUL root to RUL
7.1.1. SM: Example of Flow from RAL to Root 7.1.1. SM: Example of Flow from RAL to Root
In Storing mode, RPI [RFC6553] is used to send the RPLInstanceID and In Storing mode, RPI [RFC6553] is used to send the RPLInstanceID and
rank information. Rank information.
In this case, the flow comprises: In this case, the flow comprises:
RAL (6LN) --> 6LR_i --> root (6LBR) RAL (6LN) --> 6LR_i --> root (6LBR)
For example, a communication flow could be: Node F (6LN) --> Node D For example, a communication flow could be: Node F (6LN) --> Node D
(6LR_i) --> Node B (6LR_i) --> Node A root (6LBR) (6LR_i) --> Node B (6LR_i) --> Node A root (6LBR)
The RAL (Node F) inserts the RPI, and sends the packet to the 6LR The RAL (Node F) inserts the RPI, and sends the packet to the 6LR
(Node D), which decrements the rank in the RPI and sends the packet (Node D), which decrements the Rank in the RPI and sends the packet
up. When the packet arrives at the 6LBR (Node A), the RPI is removed up. When the packet arrives at the 6LBR (Node A), the RPI is removed
and the packet is processed. and the packet is processed.
No IPv6-in-IPv6 header is required. No IPv6-in-IPv6 header is required.
The RPI can be removed by the 6LBR because the packet is addressed to The RPI can be removed by the 6LBR because the packet is addressed to
the 6LBR. The RAL must know that it is communicating with the 6LBR the 6LBR. The RAL must know that it is communicating with the 6LBR
to make use of this scenario. The RAL can know the address of the to make use of this scenario. The RAL can know the address of the
6LBR because it knows the address of the root via the DODAGID in the 6LBR because it knows the address of the root via the DODAGID in the
DIO messages. DIO messages.
skipping to change at line 994 skipping to change at line 994
7.1.2. SM: Example of Flow from Root to RAL 7.1.2. SM: Example of Flow from Root to RAL
In this case, the flow comprises: In this case, the flow comprises:
root (6LBR) --> 6LR_i --> RAL (6LN) root (6LBR) --> 6LR_i --> RAL (6LN)
For example, a communication flow could be: Node A root (6LBR) --> For example, a communication flow could be: Node A root (6LBR) -->
Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN) Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN)
In this case, the 6LBR inserts RPI and sends the packet down. The In this case, the 6LBR inserts RPI and sends the packet down. The
6LR increments the rank in the RPI (it examines the RPLInstanceID to 6LR increments the Rank in the RPI (it examines the RPLInstanceID to
identify the right forwarding table). The packet is processed in the identify the right forwarding table). The packet is processed in the
RAL, and the RPI is removed. RAL, and the RPI is removed.
No IPv6-in-IPv6 header is required. No IPv6-in-IPv6 header is required.
Table 6 summarizes which headers are needed for this use case. Table 6 summarizes which headers are needed for this use case.
+===================+==========+=======+=========+ +===================+==========+=======+=========+
| Header | 6LBR src | 6LR_i | RAL dst | | Header | 6LBR src | 6LR_i | RAL dst |
+===================+==========+=======+=========+ +===================+==========+=======+=========+
skipping to change at line 1038 skipping to change at line 1038
total number of routers (6LR) that the packet goes through, from the total number of routers (6LR) that the packet goes through, from the
6LBR (Node A) to the RUL (Node G). 6LBR (Node A) to the RUL (Node G).
The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header and The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header and
prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR prepend an RPI. The IPv6-in-IPv6 header is addressed to the 6LR
parent of the RUL (6LR_n). The 6LR parent of the RUL removes the parent of the RUL (6LR_n). The 6LR parent of the RUL removes the
header and sends the packet to the RUL. header and sends the packet to the RUL.
Table 7 summarizes which headers are needed for this use case. Table 7 summarizes which headers are needed for this use case.
+===================+=============+=========+=============+=========+ +==================+===============+=========+=========+=========+
| Header | 6LBR src | 6LR_i | 6LR_n | RUL dst | | Header | 6LBR src | 6LR_i | 6LR_n | RUL dst |
+===================+=============+=========+=============+=========+ +==================+===============+=========+=========+=========+
| Added headers | IP6-IP6 RPI | -- | -- | -- | | Added headers | IP6-IP6 (RPI) | -- | -- | -- |
+===================+-------------+---------+-------------+---------+ +==================+---------------+---------+---------+---------+
| Modified headers | -- | RPI | -- | -- | | Modified headers | -- | RPI | -- | -- |
+===================+-------------+---------+-------------+---------+ +==================+---------------+---------+---------+---------+
| Removed headers | -- | -- | IP6-IP6 RPI | -- | | Removed headers | -- | -- | IP6-IP6 | -- |
+===================+-------------+---------+-------------+---------+ | | | | (RPI) | |
| Untouched | -- | IP6-IP6 | -- | -- | +==================+---------------+---------+---------+---------+
| headers | | | | | | Untouched | -- | IP6-IP6 | -- | -- |
+===================+-------------+---------+-------------+---------+ | headers | | | | |
+==================+---------------+---------+---------+---------+
Table 7: SM: Summary of the Use of Headers from Root to RUL Table 7: SM: Summary of the Use of Headers from Root to RUL
IP-in-IP encapsulation may be avoided for root-to-RUL communication. IP-in-IP encapsulation may be avoided for root-to-RUL communication.
In SM, it can be replaced by a loose RH3 header that indicates the In SM, it can be replaced by a loose RH3 header that indicates the
RUL. In which case, the packet is routed to the 6LR as a normal SM RUL. In which case, the packet is routed to the 6LR as a normal SM
operation, then the 6LR forwards to the RUL based on the RH3, and the operation, then the 6LR forwards to the RUL based on the RH3, and the
RUL ignores both the consumed RH3 and the RPI, as in Non-Storing RUL ignores both the consumed RH3 and the RPI, as in Non-Storing
mode. mode.
Table 8 summarizes which headers are needed for this scenario. Table 8 summarizes which headers are needed for this scenario.
skipping to change at line 1104 skipping to change at line 1105
6LBR. 6LBR.
When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the When the packet arrives from the RUL (Node G) to 6LR_1 (Node E), the
6LR_1 will encapsulate the packet in an IPv6-in-IPv6 header with an 6LR_1 will encapsulate the packet in an IPv6-in-IPv6 header with an
RPI. The IPv6-in-IPv6 header is addressed to the root (Node A). The RPI. The IPv6-in-IPv6 header is addressed to the root (Node A). The
root removes the header and processes the packet. root removes the header and processes the packet.
Table 9 summarizes which headers are needed for this use case where Table 9 summarizes which headers are needed for this use case where
the IPv6-in-IPv6 header is addressed to the root (Node A). the IPv6-in-IPv6 header is addressed to the root (Node A).
+===================+=========+=============+=========+=============+ +==================+=========+===============+=========+==========+
| Header | RUL src | 6LR_1 | 6LR_i | 6LBR dst | | Header | RUL src | 6LR_1 | 6LR_i | 6LBR dst |
+===================+=========+=============+=========+=============+ +==================+=========+===============+=========+==========+
| Added headers | -- | IP6-IP6 RPI | -- | -- | | Added headers | -- | IP6-IP6 (RPI) | -- | -- |
+===================+---------+-------------+---------+-------------+ +==================+---------+---------------+---------+----------+
| Modified headers | -- | -- | RPI | -- | | Modified headers | -- | -- | RPI | -- |
+===================+---------+-------------+---------+-------------+ +==================+---------+---------------+---------+----------+
| Removed headers | -- | -- | -- | IP6-IP6 RPI | | Removed headers | -- | -- | -- | IP6-IP6 |
+===================+---------+-------------+---------+-------------+ | | | | | (RPI) |
| Untouched | -- | -- | IP6-IP6 | -- | +==================+---------+---------------+---------+----------+
| headers | | | | | | Untouched | -- | -- | IP6-IP6 | -- |
+===================+---------+-------------+---------+-------------+ | headers | | | | |
+==================+---------+---------------+---------+----------+
Table 9: SM: Summary of the Use of Headers from RUL to Root Table 9: SM: Summary of the Use of Headers from RUL to Root
7.2. SM: Interaction between Leaf and Internet 7.2. SM: Interaction between Leaf and Internet
This section describes the communication flow in Storing mode (SM) This section describes the communication flow in Storing mode (SM)
between the following: between the following:
RAL to Internet RAL to Internet
skipping to change at line 1153 skipping to change at line 1155
routers (6LR) that the packet goes through, from the RAL to the 6LBR. routers (6LR) that the packet goes through, from the RAL to the 6LBR.
RPL information from RFC 6553 may go out to Internet as it will be RPL information from RFC 6553 may go out to Internet as it will be
ignored by nodes that have not been configured to be RPL aware. No ignored by nodes that have not been configured to be RPL aware. No
IPv6-in-IPv6 header is required. IPv6-in-IPv6 header is required.
On the other hand, the RAL may insert the RPI encapsulated in an On the other hand, the RAL may insert the RPI encapsulated in an
IPv6-in-IPv6 header to the root. Thus, the root removes the RPI and IPv6-in-IPv6 header to the root. Thus, the root removes the RPI and
sends the packet to the Internet. sends the packet to the Internet.
| Note: In this use case, it is used a node as a leaf, but this | Note: In this use case, a leaf node is used, but this use case
| use case can be also applicable to any RPL-aware node type | can also be applicable to any RPL-aware node type (e.g., 6LR).
| (e.g., 6LR).
Table 10 summarizes which headers are needed for this use case when Table 10 summarizes which headers are needed for this use case when
there is no encapsulation. Note that the RPI is modified by 6LBR to there is no encapsulation. Note that the RPI is modified by 6LBR to
set the SenderRank to zero in the case that it is not already zero. set the SenderRank to zero in the case that it is not already zero.
Table 11 summarizes which headers are needed when encapsulation to Table 11 summarizes which headers are needed when encapsulation to
the root takes place. the root takes place.
+===================+=========+=======+======+===============+ +===================+=========+=======+======+===============+
| Header | RAL src | 6LR_i | 6LBR | Internet dst | | Header | RAL src | 6LR_i | 6LBR | Internet dst |
+===================+=========+=======+======+===============+ +===================+=========+=======+======+===============+
skipping to change at line 1178 skipping to change at line 1179
| Modified headers | -- | RPI | RPI | -- | | Modified headers | -- | RPI | RPI | -- |
+===================+---------+-------+------+---------------+ +===================+---------+-------+------+---------------+
| Removed headers | -- | -- | -- | -- | | Removed headers | -- | -- | -- | -- |
+===================+---------+-------+------+---------------+ +===================+---------+-------+------+---------------+
| Untouched headers | -- | -- | -- | RPI (Ignored) | | Untouched headers | -- | -- | -- | RPI (Ignored) |
+===================+---------+-------+------+---------------+ +===================+---------+-------+------+---------------+
Table 10: SM: Summary of the Use of Headers from RAL to Table 10: SM: Summary of the Use of Headers from RAL to
Internet with No Encapsulation Internet with No Encapsulation
+==================+=============+=========+=========+==============+ +===============+===============+=========+=========+==============+
| Header | RAL src | 6LR_i | 6LBR | Internet dst | | Header | RAL src | 6LR_i | 6LBR | Internet dst |
+==================+=============+=========+=========+==============+ +===============+===============+=========+=========+==============+
| Added headers | IP6-IP6 RPI | -- | -- | -- | | Added headers | IP6-IP6 (RPI) | -- | -- | -- |
+==================+-------------+---------+---------+--------------+ +===============+---------------+---------+---------+--------------+
| Modified | -- | RPI | -- | -- | | Modified | -- | RPI | -- | -- |
| headers | | | | | | headers | | | | |
+==================+-------------+---------+---------+--------------+ +===============+---------------+---------+---------+--------------+
| Removed | -- | -- | IP6-IP6 | -- | | Removed | -- | -- | IP6-IP6 | -- |
| headers | | | RPI | | | headers | | | (RPI) | |
+==================+-------------+---------+---------+--------------+ +===============+---------------+---------+---------+--------------+
| Untouched | -- | IP6-IP6 | -- | -- | | Untouched | -- | IP6-IP6 | -- | -- |
| headers | | | | | | headers | | | | |
+==================+-------------+---------+---------+--------------+ +===============+---------------+---------+---------+--------------+
Table 11: SM: Summary of the Use of Headers from RAL to Internet with Table 11: SM: Summary of the Use of Headers from RAL to Internet
Encapsulation to the Root (6LBR) with Encapsulation to the Root (6LBR)
7.2.2. SM: Example of Flow from Internet to RAL 7.2.2. SM: Example of Flow from Internet to RAL
In this case, the flow comprises: In this case, the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) Internet --> root (6LBR) --> 6LR_i --> RAL (6LN)
For example, a communication flow could be: Internet --> Node A root For example, a communication flow could be: Internet --> Node A root
(6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL) (6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL)
When the packet arrives from Internet to 6LBR, the RPI is added in a When the packet arrives from Internet to 6LBR, the RPI is added in a
outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address
set to the RAL) and sent to the 6LR, which modifies the rank in the set to the RAL) and sent to the 6LR, which modifies the Rank in the
RPI. When the packet arrives at the RAL, the packet is decapsulated, RPI. When the packet arrives at the RAL, the packet is decapsulated,
which removes the RPI before the packet is processed. which removes the RPI before the packet is processed.
Table 12 summarizes which headers are needed for this use case. Table 12 summarizes which headers are needed for this use case.
+==================+==============+===============+=======+=========+ +==================+==============+===============+=======+=========+
| Header | Internet src | 6LBR | 6LR_i | RAL dst | | Header | Internet src | 6LBR | 6LR_i | RAL dst |
+==================+==============+===============+=======+=========+ +==================+==============+===============+=======+=========+
| Added headers | -- | IP6-IP6 (RPI) | -- | -- | | Added headers | -- | IP6-IP6 (RPI) | -- | -- |
+==================+--------------+---------------+-------+---------+ +==================+--------------+---------------+-------+---------+
skipping to change at line 1241 skipping to change at line 1242
In this case, the flow comprises: In this case, the flow comprises:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) --> Internet RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) --> Internet
For example, a communication flow could be: Node G (RUL) --> Node E For example, a communication flow could be: Node G (RUL) --> Node E
(6LR_1) --> Node B (6lR_i) --> Node A root (6LBR) --> Internet (6LR_1) --> Node B (6lR_i) --> Node A root (6LBR) --> Internet
The node 6LR_1 (i=1) will add an IPv6-in-IPv6 (RPI) header addressed The node 6LR_1 (i=1) will add an IPv6-in-IPv6 (RPI) header addressed
to the root such that the root can remove the RPI before passing to the root such that the root can remove the RPI before passing
upwards. In the intermediate 6LR, the rank in the RPI is modified. upwards. In the intermediate 6LR, the Rank in the RPI is modified.
The originating node will ideally leave the IPv6 flow label as zero The originating node will ideally leave the IPv6 flow label as zero
so that the packet can be better compressed through the LLN. The so that the packet can be better compressed through the LLN. The
6LBR will set the flow label of the packet to a non-zero value when 6LBR will set the flow label of the packet to a non-zero value when
sending to the Internet. For details, check [RFC6437]. sending to the Internet. For details, check [RFC6437].
Table 13 summarizes which headers are needed for this use case. Table 13 summarizes which headers are needed for this use case.
+===========+==========+=========+=============+=========+==========+ +===========+=======+=========+==============+=========+==========+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet | | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet |
| | src | | [i=2,...,n] | | dst | | | src | | i=(1,..,n-1) | | dst |
| | (RUL) | | | | | | | (RUL) | | | | |
+===========+==========+=========+=============+=========+==========+ +===========+=======+=========+==============+=========+==========+
| Added | -- | IP6-IP6 | -- | -- | -- | | Added | -- | IP6-IP6 | -- | -- | -- |
| headers | | (RPI) | | | | | headers | | (RPI) | | | |
+===========+----------+---------+-------------+---------+----------+ +===========+-------+---------+--------------+---------+----------+
| Modified | -- | -- | RPI | -- | -- | | Modified | -- | -- | RPI | -- | -- |
| headers | | | | | | | headers | | | | | |
+===========+----------+---------+-------------+---------+----------+ +===========+-------+---------+--------------+---------+----------+
| Removed | -- | -- | -- | IP6-IP6 | -- | | Removed | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | (RPI) | | | headers | | | | (RPI) | |
+===========+----------+---------+-------------+---------+----------+ +===========+-------+---------+--------------+---------+----------+
| Untouched | -- | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+===========+----------+---------+-------------+---------+----------+ +===========+-------+---------+--------------+---------+----------+
Table 13: SM: Summary of the Use of Headers from RUL to Internet Table 13: SM: Summary of the Use of Headers from RUL to Internet
7.2.4. SM: Example of Flow from Internet to RUL 7.2.4. SM: Example of Flow from Internet to RUL
In this case, the flow comprises: In this case, the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
For example, a communication flow could be: Internet --> Node A root For example, a communication flow could be: Internet --> Node A root
(6LBR) --> Node B (6LR_i) --> Node E (6LR_n) --> Node G (RUL) (6LBR) --> Node B (6LR_i) --> Node E (6LR_n) --> Node G (RUL)
The 6LBR will have to add an RPI within an IPv6-in-IPv6 header. The The 6LBR will have to add an RPI within an IPv6-in-IPv6 header. The
IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL. IPv6-in-IPv6 encapsulating header is addressed to the 6LR parent of
the RUL.
Further details about this are mentioned in [RFC9010], which Further details about this are mentioned in [RFC9010], which
specifies RPL routing for a 6LN acting as a plain host and being specifies RPL routing for a 6LN acting as a plain host and being
unaware of RPL. unaware of RPL.
The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to
zero in order to aid in compression [RFC8138] [RFC6437]. zero in order to aid in compression [RFC8138] [RFC6437].
Table 14 summarizes which headers are needed for this use case. Table 14 summarizes which headers are needed for this use case.
+===========+==============+=========+==============+=========+=====+ +===========+==============+=========+==============+=========+=====+
| Header | Internet | 6LBR | 6LR_i | 6LR_n | RUL | | Header | Internet | 6LBR | 6LR_i | 6LR_n | RUL |
| | src | | [i=1,..,n-1] | | dst | | | src | | i=(1,..,n-1) | | dst |
+===========+==============+=========+==============+=========+=====+ +===========+==============+=========+==============+=========+=====+
| Inserted | -- | IP6-IP6 | -- | -- | -- | | Added | -- | IP6-IP6 | -- | -- | -- |
| headers | | (RPI) | | | | | headers | | (RPI) | | | |
+===========+--------------+---------+--------------+---------+-----+ +===========+--------------+---------+--------------+---------+-----+
| Modified | -- | -- | RPI | -- | -- | | Modified | -- | -- | RPI | -- | -- |
| headers | | | | | | | headers | | | | | |
+===========+--------------+---------+--------------+---------+-----+ +===========+--------------+---------+--------------+---------+-----+
| Removed | -- | -- | -- | IP6-IP6 | -- | | Removed | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | (RPI) | | | headers | | | | (RPI) | |
+===========+--------------+---------+--------------+---------+-----+ +===========+--------------+---------+--------------+---------+-----+
| Untouched | -- | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
skipping to change at line 1495 skipping to change at line 1497
router from the RUL source (Node G) to the root (6LBR) (Node A). In router from the RUL source (Node G) to the root (6LBR) (Node A). In
this case, 1 <= ia <= n, where n is the total number of routers (6LR) this case, 1 <= ia <= n, where n is the total number of routers (6LR)
that the packet goes through, from the RUL to the root. 6LR_1 applies that the packet goes through, from the RUL to the root. 6LR_1 applies
when ia=1. when ia=1.
6LR_id (Node C) represents the intermediate routers from the root 6LR_id (Node C) represents the intermediate routers from the root
(Node A) to the destination RUL (Node J). In this case, 1 <= id <= (Node A) to the destination RUL (Node J). In this case, 1 <= id <=
m, where m is the total number of routers (6LR) that the packet goes m, where m is the total number of routers (6LR) that the packet goes
through, from the root to the destination RUL. through, from the root to the destination RUL.
The 6LR_1 (Node E) receives the packet from the RUL (Node G) and The 6LR_1 (Node E) receives the packet from the RUL (Node G) and adds
inserts the RPI (RPI1), encapsulated in an IPv6-in-IPv6 header the RPI (RPI1) in an IPv6-in-IPv6 encapsulation directed to the root.
directed to the root. The root removes the outer header including The root removes the outer header including the RPI (RPI1) and
the RPI (RPI1) and inserts a new RPI (RPI2) addressed to the 6LR inserts a new RPI (RPI2) addressed to the 6LR parent of the RUL.
parent of the RUL.
Table 18 summarizes which headers are needed for this use case. Table 18 summarizes which headers are needed for this use case.
+===========+===+=========+========+=========+========+=========+===+ +===========+===+=========+========+=========+========+=========+===+
| Header |RUL| 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LR_n |RUL| | Header |RUL| 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LR_n |RUL|
| |src| | | | | |dst| | |src| | | | | |dst|
+===========+===+=========+========+=========+========+=========+===+ +===========+===+=========+========+=========+========+=========+===+
| Added | --| IP6-IP6 | -- | IP6-IP6 | -- | -- | --| | Added | --| IP6-IP6 | -- | IP6-IP6 | -- | -- | --|
| headers | | (RPI1) | | (RPI1) | | | | | headers | | (RPI1) | | (RPI1) | | | |
+===========+---+---------+--------+---------+--------+---------+---+ +===========+---+---------+--------+---------+--------+---------+---+
skipping to change at line 1615 skipping to change at line 1616
root to RAL root to RAL
RUL to root RUL to root
root to RUL root to RUL
8.1.1. Non-SM: Example of Flow from RAL to Root 8.1.1. Non-SM: Example of Flow from RAL to Root
In Non-Storing mode, the leaf node uses default routing to send In Non-Storing mode, the leaf node uses default routing to send
traffic to the root. The RPI must be included since it contains the traffic to the root. The RPI must be included since it contains the
rank information, which is used to avoid and/or detect loops. Rank information, which is used to avoid and/or detect loops.
RAL (6LN) --> 6LR_i --> root(6LBR) RAL (6LN) --> 6LR_i --> root(6LBR)
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F --> Node D -->
Node B --> Node A (root) Node B --> Node A (root)
6LR_i represents the intermediate routers from the source to the 6LR_i represents the intermediate routers from the source to the
destination. In this case, 1 <= i <= n, where n is the total number destination. In this case, 1 <= i <= n, where n is the total number
of routers (6LR) that the packet goes through, from the source (RAL) of routers (6LR) that the packet goes through, from the source (RAL)
to the destination (6LBR). to the destination (6LBR).
skipping to change at line 1900 skipping to change at line 1901
6LBR, e.g., 6LR_1 (i=1). 6LBR, e.g., 6LR_1 (i=1).
In this case, the flow label is recommended to be zero in the RUL. In this case, the flow label is recommended to be zero in the RUL.
As the RUL parent adds RPL headers in the RUL packet, the first 6LR As the RUL parent adds RPL headers in the RUL packet, the first 6LR
(6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The IPv6- (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header. The IPv6-
in-IPv6 header will be addressed to the root. This case is identical in-IPv6 header will be addressed to the root. This case is identical
to the Storing mode case (see Section 7.2.3). to the Storing mode case (see Section 7.2.3).
Table 27 summarizes which headers are needed for this use case. Table 27 summarizes which headers are needed for this use case.
+===========+=========+=========+============+=========+==========+ +===========+=========+=========+==============+=========+==========+
| Header | RUL src | 6LR_1 | 6LR_i | 6LBR | Internet | | Header | RUL | 6LR_1 | 6LR_i | 6LBR | Internet |
| | | | [i=2,..,n] | | dst | | | src | | i=(1,..,n-1) | | dst |
+===========+=========+=========+============+=========+==========+ +===========+=========+=========+==============+=========+==========+
| Added | -- | IP6-IP6 | -- | -- | -- | | Added | -- | IP6-IP6 | -- | -- | -- |
| headers | | (RPI) | | | | | headers | | (RPI) | | | |
+===========+---------+---------+------------+---------+----------+ +===========+---------+---------+--------------+---------+----------+
| Modified | -- | -- | RPI | -- | -- | | Modified | -- | -- | RPI | -- | -- |
| headers | | | | | | | headers | | | | | |
+===========+---------+---------+------------+---------+----------+ +===========+---------+---------+--------------+---------+----------+
| Removed | -- | -- | -- | IP6-IP6 | -- | | Removed | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | (RPI) | | | headers | | | | (RPI) | |
+===========+---------+---------+------------+---------+----------+ +===========+---------+---------+--------------+---------+----------+
| Untouched | -- | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+===========+---------+---------+------------+---------+----------+ +===========+---------+---------+--------------+---------+----------+
Table 27: Non-SM: Summary of the Use of Headers from RUL to Table 27: Non-SM: Summary of the Use of Headers from RUL to Internet
Internet
8.2.4. Non-SM: Example of Flow from Internet to RUL 8.2.4. Non-SM: Example of Flow from Internet to RUL
In this case, the flow comprises: In this case, the flow comprises:
Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node) Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
For example, a communication flow could be: Internet --> Node A For example, a communication flow could be: Internet --> Node A
(root) --> Node B --> Node E --> Node G (root) --> Node B --> Node E --> Node G
skipping to change at line 2047 skipping to change at line 2047
| headers | | | | | | | headers | | | | | |
+===========+---------+--------+---------------+---------+---------+ +===========+---------+--------+---------------+---------+---------+
Table 29: Non-SM: Summary of the Use of Headers from RAL to RAL with Table 29: Non-SM: Summary of the Use of Headers from RAL to RAL with
Encapsulation to the Root Encapsulation to the Root
+===========+======+========+=============+=============+===========+ +===========+======+========+=============+=============+===========+
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL dst | | Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL dst |
| | src | | | | | | | src | | | | |
+===========+======+========+=============+=============+===========+ +===========+======+========+=============+=============+===========+
| Inserted | RPI1 | -- | IP6-IP6 | -- | -- | | Added | RPI1 | -- | IP6-IP6 | -- | -- |
| headers | | | (RH3, RPI2) | | | | headers | | | (RH3, RPI2) | | |
+===========+------+--------+-------------+-------------+-----------+ +===========+------+--------+-------------+-------------+-----------+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- | | Modified | -- | RPI1 | -- | IP6-IP6 | -- |
| headers | | | | (RH3, | | | headers | | | | (RH3, | |
| | | | | RPI2) | | | | | | | RPI2) | |
+===========+------+--------+-------------+-------------+-----------+ +===========+------+--------+-------------+-------------+-----------+
| Removed | -- | -- | -- | -- | IP6-IP6 | | Removed | -- | -- | -- | -- | IP6-IP6 |
| headers | | | | | (RH3, | | headers | | | | | (RH3, |
| | | | | | RPI2) | | | | | | | RPI2) |
+===========+------+--------+-------------+-------------+-----------+ +===========+------+--------+-------------+-------------+-----------+
skipping to change at line 2124 skipping to change at line 2124
| headers | | | | | | | | headers | | | | | | |
+===========+---------+--------+---------+---------+---------+-----+ +===========+---------+--------+---------+---------+---------+-----+
Table 31: Non-SM: Summary of the Use of Headers from RAL to RUL with Table 31: Non-SM: Summary of the Use of Headers from RAL to RUL with
Encapsulation to the Root Encapsulation to the Root
+===========+====+========+=========+=========+=========+===========+ +===========+====+========+=========+=========+=========+===========+
| Header |RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL dst | | Header |RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL dst |
| |src | | | | | | | |src | | | | | |
+===========+====+========+=========+=========+=========+===========+ +===========+====+========+=========+=========+=========+===========+
| Inserted |RPI1| -- | IP6-IP6 | -- | -- | -- | | Added |RPI1| -- | IP6-IP6 | -- | -- | -- |
| headers | | | (RH3, | | | | | headers | | | (RH3, | | | |
| | | | RPI2) | | | | | | | | RPI2) | | | |
+===========+----+--------+---------+---------+---------+-----------+ +===========+----+--------+---------+---------+---------+-----------+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- | | Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- |
| headers | | | | (RH3, | | | | headers | | | | (RH3, | | |
| | | | | RPI2) | | | | | | | | RPI2) | | |
+===========+----+--------+---------+---------+---------+-----------+ +===========+----+--------+---------+---------+---------+-----------+
| Removed | -- | -- | -- | -- | IP6-IP6 | -- | | Removed | -- | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | | (RH3, | | | headers | | | | | (RH3, | |
| | | | | | RPI2) | | | | | | | | RPI2) | |
skipping to change at line 2243 skipping to change at line 2243
9. Operational Considerations of Supporting RULs 9. Operational Considerations of Supporting RULs
Roughly half of the situations described in this document involve Roughly half of the situations described in this document involve
leaf ("host") nodes that do not speak RPL. These nodes fall into two leaf ("host") nodes that do not speak RPL. These nodes fall into two
further categories: ones that drop a packet that have RPI or RH3 further categories: ones that drop a packet that have RPI or RH3
headers, and ones that continue to process a packet that has RPI and/ headers, and ones that continue to process a packet that has RPI and/
or RH3 headers. or RH3 headers.
[RFC8200] provides for new rules that suggest that nodes that have [RFC8200] provides for new rules that suggest that nodes that have
not been configured (explicitly) to examine Hop-by-Hop headers should not been configured (explicitly) to examine Hop-by-Hop Options
ignore those headers and continue processing the packet. Despite headers should ignore those headers and continue processing the
this, and despite the switch from 0x63 to 0x23, there may be nodes packet. Despite this, and despite the switch from 0x63 to 0x23,
that predate RFC 8200 or are simply intolerant. Those nodes will there may be nodes that predate RFC 8200 or are simply intolerant.
drop packets that continue to have RPL artifacts in them. In Those nodes will drop packets that continue to have RPL artifacts in
general, such nodes cannot be easily supported in RPL LLNs. them. In general, such nodes cannot be easily supported in RPL LLNs.
There are some specific cases where it is possible to remove the RPL There are some specific cases where it is possible to remove the RPL
artifacts prior to forwarding the packet to the leaf host. The artifacts prior to forwarding the packet to the leaf host. The
critical thing is that the artifacts have been inserted by the RPL critical thing is that the artifacts have been inserted by the RPL
root inside an IPv6-in-IPv6 header, and that the header has been root inside an IPv6-in-IPv6 header, and that the header has been
addressed to the 6LR immediately prior to the leaf node. In that addressed to the 6LR immediately prior to the leaf node. In that
case, in the process of removing the IPv6-in-IPv6 header, the case, in the process of removing the IPv6-in-IPv6 header, the
artifacts can also be removed. artifacts can also be removed.
The above case occurs whenever traffic originates from the outside The above case occurs whenever traffic originates from the outside
skipping to change at line 2290 skipping to change at line 2290
intolerant leaf nodes, which drop packets with RPL artifacts, cannot intolerant leaf nodes, which drop packets with RPL artifacts, cannot
be supported. be supported.
10. Operational Considerations of Introducing 0x23 10. Operational Considerations of Introducing 0x23
This section describes the operational considerations of introducing This section describes the operational considerations of introducing
the new RPI Option Type of 0x23. the new RPI Option Type of 0x23.
During bootstrapping, the node receives the DIO with the information During bootstrapping, the node receives the DIO with the information
of RPI Option Type, indicating the new RPI in the DODAG Configuration of RPI Option Type, indicating the new RPI in the DODAG Configuration
option flag. The DODAG root is in charge to configure the current option flag. The DODAG root is in charge of configuring the current
network with the new value, through DIO messages, and determines when network with the new value, through DIO messages, and determining
all the nodes are set with the new value. The DODAG should change to when all the nodes have been set with the new value. The DODAG
a new DODAG version. In case of rebooting, the node does not should change to a new DODAG version. In case of rebooting, the node
remember the RPI Option Type. Thus, the DIO is sent with a flag does not remember the RPI Option Type. Thus, the DIO is sent with a
indicating the new RPI Option Type. flag indicating the new RPI Option Type.
The DODAG Configuration option is contained in a RPL DIO message, The DODAG Configuration option is contained in a RPL DIO message,
which contains a unique Destination Advertisement Trigger Sequence which contains a unique Destination Advertisement Trigger Sequence
Number (DTSN) counter. The leaf nodes respond to this message with Number (DTSN) counter. The leaf nodes respond to this message with
DAO messages containing the same DTSN. This is a normal part of RPL DAO messages containing the same DTSN. This is a normal part of RPL
routing; the RPL root therefore knows when the updated DODAG routing; the RPL root therefore knows when the updated DODAG
Configuration option has been seen by all nodes. Configuration option has been seen by all nodes.
Before the migration happens, all the RPL-aware nodes should support Before the migration happens, all the RPL-aware nodes should support
both values. The migration procedure is triggered when the DIO is both values. The migration procedure is triggered when the DIO is
skipping to change at line 2389 skipping to change at line 2389
While a typical LLN may be a very poor origin for attack traffic (as While a typical LLN may be a very poor origin for attack traffic (as
the networks tend to be very slow, and the nodes often have very low the networks tend to be very slow, and the nodes often have very low
duty cycles), given enough nodes, LLNs could still have a significant duty cycles), given enough nodes, LLNs could still have a significant
impact, particularly if the attack is targeting another LLN. impact, particularly if the attack is targeting another LLN.
Additionally, some uses of RPL involve large-backbone, ISP-scale Additionally, some uses of RPL involve large-backbone, ISP-scale
equipment [ACP], which may be equipped with multiple 100 Gb/s equipment [ACP], which may be equipped with multiple 100 Gb/s
interfaces. interfaces.
Blocking or careful filtering of IPv6-in-IPv6 traffic entering the Blocking or careful filtering of IPv6-in-IPv6 traffic entering the
LLN as described above will make sure that any attack that is mounted LLN as described above will make sure that any attack that is mounted
must originate from compromised nodes within the LLN. The use of BCP must originate from compromised nodes within the LLN. The use of
38 [BCP38] filtering at the RPL root on egress traffic will both network ingress filtering [BCP38] on egress traffic at the RPL root
alert the operator to the existence of the attack, as well as drop will alert the operator to the existence of the attack as well as
the attack traffic. As the RPL network is typically numbered from a drop the attack traffic. As the RPL network is typically numbered
single prefix, which is itself assigned by RPL, BCP38 filtering from a single prefix, which is itself assigned by RPL, network
involves a single prefix comparison and should be trivial to ingress filtering [BCP38] involves a single prefix comparison and
automatically configure. should be trivial to automatically configure.
There are some scenarios where IPv6-in-IPv6 traffic should be allowed There are some scenarios where IPv6-in-IPv6 traffic should be allowed
to pass through the RPL root, such as the IPv6-in-IPv6 mediated to pass through the RPL root, such as the IPv6-in-IPv6 mediated
communications between a new pledge and the Join Registrar/ communications between a new pledge and the Join Registrar/
Coordinator (JRC) when using [BRSKI] and [ZEROTOUCH-JOIN]. This is Coordinator (JRC) when using [BRSKI] and [ZEROTOUCH-JOIN]. This is
the case for the RPL root to do careful filtering: it occurs only the case for the RPL root to do careful filtering: it occurs only
when the Join Coordinator is not co-located inside the RPL root. when the Join Coordinator is not co-located inside the RPL root.
With the above precautions, an attack using IPv6-in-IPv6 tunnels can With the above precautions, an attack using IPv6-in-IPv6 tunnels can
only be by a node within the LLN on another node within the LLN. only be by a node within the LLN on another node within the LLN.
Such an attack could, of course, be done directly. An attack of this Such an attack could, of course, be done directly. An attack of this
kind is meaningful only if the source addresses are either fake or if kind is meaningful only if the source addresses are either fake or if
the point is to amplify return traffic. Such an attack could also be the point is to amplify return traffic. Such an attack could also be
done without the use of IPv6-in-IPv6 headers using forged source done without the use of IPv6-in-IPv6 headers, by using forged source
addresses. If the attack requires bidirectional communication, then addresses instead. If the attack requires bidirectional
IPv6-in-IPv6 provides no advantages. communication, then IPv6-in-IPv6 provides no advantages.
Whenever IPv6-in-IPv6 headers are being proposed, there is a concern Whenever IPv6-in-IPv6 headers are being proposed, there is a concern
about creating security issues. In the Security Considerations about creating security issues. In the Security Considerations
section of [RFC2473] (Section 9), it was suggested that tunnel entry section of [RFC2473] (Section 9), it was suggested that tunnel entry
and exit points can be secured by securing the IPv6 path between and exit points can be secured by securing the IPv6 path between
them. This recommendation is not practical for RPL networks. them. This recommendation is not practical for RPL networks.
[RFC5406] goes into some detail on what additional details would be [RFC5406] provides guidance on what on what additional details are
needed in order to "Use IPsec". Use of Encapsulating Security nedded in order to "Use IPsec". While the use of Encapsulating
Payload (ESP) would prevent as defined in [RFC8138] (compression must Security Payload (ESP) would prevent source address forgeries, in
occur before encryption), and [RFC8138] compression is lossy in a way order to use it with [RFC8138], compression would have to occur
that prevents use of AH. These are minor issues. The major issue is before encryption, as the [RFC8138] compression is lossy. Once
how to establish trust enough such that Internet Key Exchange encrypted, there would be no further redundancy to compress. These
Protocol Version 2 (IKEv2) could be used. This would require a are minor issues. The major issue is how to establish trust enough
system of certificates to be present in every single node, including such that Internet Key Exchange Protocol Version 2 (IKEv2) could be
any Internet nodes that might need to communicate with the LLN. used. This would require a system of certificates to be present in
Thus, using IPsec requires a global PKI in the general case. every single node, including any Internet nodes that might need to
communicate with the LLN. Thus, using IPsec requires a global PKI in
the general case.
More significantly, the use of IPsec tunnels to protect the IPv6-in- More significantly, the use of IPsec tunnels to protect the IPv6-in-
IPv6 headers would, in the general case, scale with the square of the IPv6 headers would, in the general case, scale with the square of the
number of nodes. This is a lot of resources for a constrained nodes number of nodes. This is a lot of resources for a constrained nodes
on a constrained network. In the end, the IPsec tunnels would be on a constrained network. In the end, the IPsec tunnels would be
providing only BCP38-like origin authentication! That is, IPsec providing only BCP38-like origin authentication! That is, IPsec
provides a transitive guarantee to the tunnel exit point that the provides a transitive guarantee to the tunnel exit point that the
tunnel entry point did BCP38 on traffic going in. Just doing origin tunnel entry point did network ingress filtering [BCP38] on traffic
filtering per BCP 38 at the entry and exit of the LLN provides a going in. Just doing origin filtering per BCP 38 at the entry and
similar level of security without all the scaling and trust problems exit of the LLN provides a similar level of security without all the
related to IPv6 tunnels as discussed in [RFC2473]. IPsec is not scaling and trust problems related to IPv6 tunnels as discussed in
recommended. [RFC2473]. IPsec is not recommended.
An LLN with hostile nodes within it would not be protected against An LLN with hostile nodes within it would not be protected against
impersonation within the LLN by entry/exit filtering. impersonation within the LLN by entry/exit filtering.
The RH3 header usage described here can be abused in equivalent ways. The RH3 header usage described here can be abused in equivalent ways.
An external attacker may form a packet with an RH3 that is not fully An external attacker may form a packet with an RH3 that is not fully
consumed and encapsulate it to hide the RH3 from intermediate nodes consumed and encapsulate it to hide the RH3 from intermediate nodes
and disguise the origin of traffic. As such, the attacker's RH3 and disguise the origin of traffic. As such, the attacker's RH3
header will not be seen by the network until it reaches the header will not be seen by the network until it reaches the
destination, which will decapsulate it. As indicated in Section 4.2 destination, which will decapsulate it. As indicated in Section 4.2
skipping to change at line 2483 skipping to change at line 2485
It could also be that not all nodes are reachable in an LLN using the It could also be that not all nodes are reachable in an LLN using the
default RPLInstanceID, but a change of RPLInstanceID would permit an default RPLInstanceID, but a change of RPLInstanceID would permit an
attacker to bypass such filtering. Like the RH3, an RPI is to be attacker to bypass such filtering. Like the RH3, an RPI is to be
inserted by the RPL root on traffic entering the LLN by first inserted by the RPL root on traffic entering the LLN by first
inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will
not be seen by the network. Upon reaching the destination node, the not be seen by the network. Upon reaching the destination node, the
RPI has no further meaning and is just skipped; the presence of a RPI has no further meaning and is just skipped; the presence of a
second RPI will have no meaning to the end node as the packet has second RPI will have no meaning to the end node as the packet has
already been identified as being at its final destination. already been identified as being at its final destination.
For traffic leaving a RUL, if the RUL adds an opaque RPI, then the For traffic leaving a RUL, if the RUL adds an uninitialized RPI
6LR as a RPL Border Router SHOULD rewrite the RPI to indicate the (e.g., with a value of zero), then the 6LR as a RPL Border Router
selected Instance and set the flags. This is done in order to avoid SHOULD rewrite the RPI to indicate the selected Instance and set the
the following scenarios: 1) The leaf is an external router that flags. This is done in order to avoid the following scenarios: 1)
passes a packet that it did not generate and that carries an The leaf is an external router that passes a packet that it did not
unrelated RPI, and 2) The leaf is an attacker or presents generate and that carries an unrelated RPI, and 2) The leaf is an
misconfiguration and tries to inject traffic in a protected Instance. attacker or presents misconfiguration and tries to inject traffic in
Also, this applies to the case where the leaf is aware of the RPL a protected Instance. Also, this applies to the case where the leaf
Instance and passes a correct RPI; the 6LR needs a configuration that is aware of the RPL Instance and passes a correct RPI; the 6LR needs
allows that leaf to inject in that instance. a configuration that allows that leaf to inject in that instance.
The RH3 and RPIs could be abused by an attacker inside of the network The RH3 and RPIs could be abused by an attacker inside of the network
to route packets in nonobvious ways, perhaps eluding observation. to route packets in nonobvious ways, perhaps eluding observation.
This usage appears consistent with a normal operation of [RFC6997] This usage appears consistent with a normal operation of [RFC6997]
and cannot be restricted at all. This is a feature, not a bug. and cannot be restricted at all. This is a feature, not a bug.
[RFC7416] deals with many other threats to LLNs not directly related [RFC7416] deals with many other threats to LLNs not directly related
to the use of IPv6-in-IPv6 headers, and this document does not change to the use of IPv6-in-IPv6 headers, and this document does not change
that analysis. that analysis.
skipping to change at line 2527 skipping to change at line 2529
LLN, IPv6-in-IPv6 can be used to hide inner routing headers, but by LLN, IPv6-in-IPv6 can be used to hide inner routing headers, but by
construction, the RH3 can typically only address nodes within the construction, the RH3 can typically only address nodes within the
LLN. That is, an RH3 with a CmprI less than 8 should be considered LLN. That is, an RH3 with a CmprI less than 8 should be considered
an attack (see Section 3 of [RFC6554]). an attack (see Section 3 of [RFC6554]).
Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic
through the RPL root to perform this attack. To counter, the RPL through the RPL root to perform this attack. To counter, the RPL
root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the
simpler solution), or it SHOULD walk the IP header extension chain simpler solution), or it SHOULD walk the IP header extension chain
until it can inspect the upper-layer payload as described in until it can inspect the upper-layer payload as described in
[RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing [RFC7045]. In particular, the RPL root SHOULD do network ingress
on the source addresses of all IP headers that it examines in both filtering [BCP38] on the source addresses of all IP headers that it
directions. examines in both directions.
Note: there are some situations where a prefix will spread across Note: there are some situations where a prefix will spread across
multiple LLNs via mechanisms such as the one described in [RFC8929]. multiple LLNs via mechanisms such as the one described in [RFC8929].
In this case, the BCP38 filtering needs to take this into account, In this case, the network ingress filtering [BCP38] needs to take
either by exchanging detailed routing information on each LLN or by this into account, either by exchanging detailed routing information
moving the BCP38 filtering further towards the Internet, so that the on each LLN or by moving the network ingress filtering [BCP38]
details of the multiple LLNs do not matter. further towards the Internet, so that the details of the multiple
LLNs do not matter.
13. References 13. References
13.1. Normative References 13.1. Normative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
<https://rfc-editor.org/info/bcp38> <https://rfc-editor.org/info/bcp38>
skipping to change at line 2724 skipping to change at line 2727
dtsecurity-zerotouch-join-04, 8 July 2019, dtsecurity-zerotouch-join-04, 8 July 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity- <https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-
zerotouch-join-04>. zerotouch-join-04>.
Acknowledgments Acknowledgments
This work is done thanks to the grant given by the StandICT.eu This work is done thanks to the grant given by the StandICT.eu
project. project.
A special BIG thanks to C. M. Heard for the help with Section 4. A special BIG thanks to C. M. Heard for the help with Section 4.
Much of the redaction in that section is based on his comments. Much of the editing in that section is based on his comments.
Additionally, the authors would like to acknowledge the review, Additionally, the authors would like to acknowledge the review,
feedback, and comments of the following (in alphabetical order): feedback, and comments of the following (in alphabetical order):
Dominique Barthel, Robert Cragie, Ralph Droms, Simon Duquennoy, Cenk Dominique Barthel, Robert Cragie, Ralph Droms, Simon Duquennoy, Cenk
Guendogan, Rahul Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo Guendogan, Rahul Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo
Mercado, Subramanian Moonesamy, Marcela Orbiscay, Cristian Perez, Mercado, Subramanian Moonesamy, Marcela Orbiscay, Cristian Perez,
Charlie Perkins, Alvaro Retana, Peter van der Stok, Xavier Charlie Perkins, Alvaro Retana, Peter van der Stok, Xavier
Vilajosana, Éric Vyncke, and Thomas Watteyne. Vilajosana, Éric Vyncke, and Thomas Watteyne.
Authors' Addresses Authors' Addresses
 End of changes. 45 change blocks. 
206 lines changed or deleted 209 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/