draft-ietf-roll-unaware-leaves-25.txt   draft-ietf-roll-unaware-leaves-26.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 6775, 8505 (if approved) M. Richardson Updates: 6550, 6775, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 18 June 2021 15 December 2020 Expires: 19 June 2021 16 December 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-25 draft-ietf-roll-unaware-leaves-26
Abstract Abstract
This specification updates RFC6550, RFC6775, and RFC8505, to provide This specification updates RFC6550, RFC6775, and RFC8505. It
routing services to IPv6 Nodes that implement RFC6775, RFC8505, and provides a mechanism for a host that implements a routing-agnostic
their extensions therein, but do not support RFC6550. interface based on 6LoWPAN Neighbor Discovery to obtain reachability
services across a network that leverages RFC6550 for its routing
operations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 18 June 2021. This Internet-Draft will expire on 19 June 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 8, line 46 skipping to change at page 8, line 46
In Non-Storing Mode, packets going down carry a Source Routing Header In Non-Storing Mode, packets going down carry a Source Routing Header
(SRH). The IPv6-in-IPv6 encapsulation, the RPI and the SRH are (SRH). The IPv6-in-IPv6 encapsulation, the RPI and the SRH are
collectively called the "RPL artifacts" and can be compressed using collectively called the "RPL artifacts" and can be compressed using
[RFC8138]. Appendix A presents an example compressed format for a [RFC8138]. Appendix A presents an example compressed format for a
packet forwarded by the Root to a RUL in a Storing Mode DODAG. packet forwarded by the Root to a RUL in a Storing Mode DODAG.
The inner packet that is forwarded to the RUL may carry some RPL The inner packet that is forwarded to the RUL may carry some RPL
artifacts, e.g., an RPI if the original packet was generated with it, artifacts, e.g., an RPI if the original packet was generated with it,
and an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] expects the and an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] expects the
RUL to support the basic "IPv6 Node Requirements" [RFC8504]. In RUL to support the basic "IPv6 Node Requirements" [RFC8504] and in
particular the RUL is expected to ignore the RPL artifacts that are particular the mandates in Sections 4.2 and 4.4 of [RFC8200]. As
either consumed or not applicable to a host. such, the RUL is expected to ignore the RPL artifacts that may be
left over, either an SRH with zero Segments Left or a RPL Option in
the Hop-by-Hop Header, which can be skipped when not recognized, see
Section 5 for more.
A RUL is not expected to support the compression method defined in A RUL is not expected to support the compression method defined in
[RFC8138]. For that reason, the border router uncompresses the [RFC8138]. For that reason, the border router uncompresses the
packet before forwarding it over an external route to a RUL packet before forwarding it over an external route to a RUL
[USEofRPLinfo]. [USEofRPLinfo].
4. 6LoWPAN Neighbor Discovery 4. 6LoWPAN Neighbor Discovery
This section goes through the 6LoWPAN ND mechanisms that this This section goes through the 6LoWPAN ND mechanisms that this
specification leverages, as a non-normative reference to the reader. specification leverages, as a non-normative reference to the reader.
skipping to change at page 16, line 8 skipping to change at page 16, line 8
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier (ROVR) ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Updated Target Option Figure 4: Updated Target Option
New fields: New fields:
ROVRsz (ROVR Size): Indicates the Size of the ROVR. It SHOULD be 1, ROVRsz (ROVR Size): Indicates the Size of the ROVR. It MUST be set
2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits, to 1, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256
respectively. If a legacy Target Option is used, then the value bits, respectively. If a legacy Target Option is used, then the
must remain 0, as specified in [RFC6550]. In case of a value value must remain 0, as specified in [RFC6550]. In case of a
above 4, the size of the ROVR is undetermined and this node cannot value above 4, the size of the ROVR is undetermined and this node
validate the ROVR; an implementation SHOULD propagate the whole cannot validate the ROVR; an implementation SHOULD propagate the
Target Option upwards as received to enable the verification by an whole Target Option upwards as received to enable the verification
ancestor that would support the upgraded ROVR. by an ancestor that would support the upgraded ROVR.
F: 1-bit flag. Set to 1 to indicate that Target Prefix field F: 1-bit flag. Set to 1 to indicate that Target Prefix field
contains the complete (128 bit) IPv6 address of the advertising contains the complete (128 bit) IPv6 address of the advertising
node. node.
Flags: The 3 bits remaining unused in the Flags field are reserved Flags: The 3 bits remaining unused in the Flags field are reserved
for flags. The field MUST be initialized to zero by the sender for flags. The field MUST be initialized to zero by the sender
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
Registration Ownership Verifier (ROVR): This is the same field as in Registration Ownership Verifier (ROVR): This is the same field as in
skipping to change at page 33, line 31 skipping to change at page 33, line 31
cryptographic identifier (Crypto-ID), and use it with one or more of cryptographic identifier (Crypto-ID), and use it with one or more of
their Registered Addresses. The Crypto-ID identifies the owner of their Registered Addresses. The Crypto-ID identifies the owner of
the Registered Address and can be used to provide proof of ownership the Registered Address and can be used to provide proof of ownership
of the Registered Addresses. Once an address is registered with the of the Registered Addresses. Once an address is registered with the
Crypto-ID and a proof of ownership is provided, only the owner of Crypto-ID and a proof of ownership is provided, only the owner of
that address can modify the registration information, thereby that address can modify the registration information, thereby
enforcing Source Address Validation. [RFC8928] reduces even more the enforcing Source Address Validation. [RFC8928] reduces even more the
attack perimeter that is available to the edge nodes and its use is attack perimeter that is available to the edge nodes and its use is
suggested in this specification. suggested in this specification.
Additionally, the trust model could include a role validation to Additionally, the trust model could include a role validation (e.g.,
ensure that the node that claims to be a 6LBR or a RPL Root is using a role-based authorization) to ensure that the node that claims
entitled to do so. to be a 6LBR or a RPL Root is entitled to do so.
The Opaque field in the EARO enables the RUL to suggest a The Opaque field in the EARO enables the RUL to suggest a
RPLInstanceID where its traffic is placed. It is also possible for RPLInstanceID where its traffic is placed. It is also possible for
an attacker RUL to include an RPI in the packet. This opens to an attacker RUL to include an RPI in the packet. This opens to
attacks where a RPL instance would be reserved for critical traffic, attacks where a RPL instance would be reserved for critical traffic,
e.g., with a specific bandwidth reservation, that the additional e.g., with a specific bandwidth reservation, that the additional
traffic generated by a rogue may disrupt. The attack may be traffic generated by a rogue may disrupt. The attack may be
alleviated by traditional access control and traffic shaping alleviated by traditional access control and traffic shaping
mechanisms where the 6LR controls the incoming traffic from the 6LN. mechanisms where the 6LR controls the incoming traffic from the 6LN.
More importantly, the 6LR is the node that injects the traffic in the More importantly, the 6LR is the node that injects the traffic in the
skipping to change at page 40, line 16 skipping to change at page 40, line 16
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
November 2020, <https://www.rfc-editor.org/info/rfc8929>. November 2020, <https://www.rfc-editor.org/info/rfc8929>.
Appendix A. Example Compression Appendix A. Example Compression
Figure 13 illustrates the case in Storing Mode where the packet is Figure 13 illustrates the case in Storing Mode where the packet is
received from the Internet, then the Root encapsulates the packet to received from the Internet, then the Root encapsulates the packet to
insert the RPI and deliver to the 6LR that is the parent and last hop insert the RPI and deliver to the 6LR that is the parent and last hop
to the final destination, which is not known to support [RFC8138]. to the final destination, which is not known to support [RFC8138].
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- |IPv6-in-IPv6| 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
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-4 bytes-> <- RFC 6282 -> <-4 bytes-> <- RFC 6282 ->
<- No RPL artifact ... <- No RPL artifact ...
Figure 13: Encapsulation to Parent 6LR in Storing Mode Figure 13: Encapsulation to Parent 6LR in Storing Mode
The difference with the example presented in Figure 19 of [RFC8138] The difference with the example presented in Figure 19 of [RFC8138]
is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the
compressed address of the 6LR as the destination address of the outer compressed address of the 6LR as the destination address of the outer
IPv6 header. In the [RFC8138] example the destination IP of the IPv6 header. In the [RFC8138] example the destination IP of the
outer header was elided and was implicitly the same address as the outer header was elided and was implicitly the same address as the
destination of the inner header. Type 1 was arbitrarily chosen, and destination of the inner header. Type 1 was arbitrarily chosen, and
the size of 0 denotes a single address in the SRH. the size of 0 denotes a single address in the SRH.
In Figure 13, the source of the IPv6-in-IPv6 encapsulation is the In Figure 13, the source of the IPv6-in-IPv6 encapsulation is the
 End of changes. 9 change blocks. 
27 lines changed or deleted 32 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/