draft-ietf-roll-unaware-leaves-10.txt   draft-ietf-roll-unaware-leaves-11.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 8505 (if approved) M. Richardson Updates: 6550, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 13 September 2020 12 March 2020 Expires: 14 September 2020 13 March 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-10 draft-ietf-roll-unaware-leaves-11
Abstract Abstract
This specification extends RFC6550 and RFC8505 to provide unicast and This specification extends RFC6550 and RFC8505 to provide unicast and
multicast routing services in a RPL domain to 6LNs that are plain multicast routing services in a RPL domain to 6LNs that are plain
Hosts and do not participate to RPL, and enables the RPL Root to Hosts and do not participate to RPL, and enables the RPL Root to
proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG. proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 13 September 2020. This Internet-Draft will expire on 14 September 2020.
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 12, line 10 skipping to change at page 12, line 10
the Status value indicates a rejection. the Status value indicates a rejection.
A RUL SHOULD support [AP-ND] to protect the ownership of its A RUL SHOULD support [AP-ND] to protect the ownership of its
addresses. addresses.
6.2. External Routes and RPL Artifacts 6.2. External Routes and RPL Artifacts
Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be
followed for the routing operations to a RUL. followed for the routing operations to a RUL.
Non-Storing Mode DAO messages are used to signal external routes to A 6LR that is upgraded to act as a border router for external routes
the Root, even if the DODAG is operated in Storing Mode. A RUL is an advertises them using Non-Storing Mode DAO messages that are unicast
example of a destination that is reachable via an external route directly to the Root, even if the DODAG is operated in Storing Mode.
which happens to be a Host route. Non-Storing Mode routes are not visible inside the RPL domain and all
packets are routed via the Root. An upgraded Root tunnels the
The Non-Storing Mode DAO messaging enables to advertise the 6LR that packets directly to the 6LR that advertised the external route which
serves the RUL and injects the route to the Root. It also forces all decapsulates and forwards the original (inner) packet.
packets to the RUL to be routed via the Root since the path to the
RUL is not known inside the RPL domain, even in Storing Mode.
The use of Non-Storing Mode signaling in Storing Mode and the The RPL Non-Storing Mode signaling and the associated IP-in-IP
associated IP-in-IP encapsulation are transparent to intermediate encapsulated packets are normal traffic for the intermediate Routers.
Routers that only see packets back and forth between the Root and the The support of external routes only impacts the Root and the 6LR. It
6LR and do not need a special support for external routes, so the can be operated with legacy intermediate routers and does not add to
mmechanism is backward compatible. the amount of state that must be maintained in those routers. A RUL
is an example of a destination that is reachable via an external
route which happens to be a Host route.
The RPL data packets from/to a RUL are encapsulated using an IP-in-IP The RPL data packets always carry a Hop-by-Hop Header to transport a
tunnel between the Root and the 6LR that serves the RUL, except for RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates
packets from the RUL to a RAN in the RPL domain. The RPL data its packets with an RPI, the 6LR needs to tunnel them to the Root to
packets also carry a Hop-by-Hop Header to transport a RPL Packet add the RPI. As a rule of a thumb and except the very special case
Information (RPI) [RFC6550]. In Non-Storing Mode, packets going down above, the packets from and to a RUL are always encapsulated using an
carry a Source Routing Header (SRH). These headers are called the IP-in-IP tunnel between the Root and the 6LR that serves the RUL.
"RPL artifacts" and can be compressed with [RFC8138].
RPL data packets going down to the RUL (see Figure 12 for the In Non-Storing Mode, packets going down carry a Source Routing Header
compressed format in Storing Mode) are decapsulated by the 6LR that (SRH). The IP-in-IP encapsulation, the RPI and the SRH are
serves the RUL. The inner packet that is forwarded to the RUL is collectively called the "RPL artifacts" and can be compressed using
free of RPL artifacts, except for an RPI if the packet was generated [RFC8138]. Figure 12 presents an example compressed format for a
by a RAN in the same RPL domain as the RUL and reencapsulated with packet forwarded by the Root to a RUL in a Storing Mode DODAG.
the original RPI still present in the inner header by the Root.
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
and encapsulated by the Root with that RPI still present in the inner
header, and possibly an SRH in a Non-Storing Mode DODAG.
[USEofRPLinfo] expects the RUL to support the basic "IPv6 Node [USEofRPLinfo] expects the RUL to support the basic "IPv6 Node
Requirements" [RFC8504], in particular to ignore the RPL artifacts Requirements" [RFC8504], in particular to ignore the RPL artifacts
that are either consumed or not applicable to a Host, which is the that are either consumed or not applicable to a Host, but not
case of the RPI. necessarily IP-in-IP encapsulation, more in the next sections.
Additionally, the RUL is not expected to support the compression A RUL is not expected to support the compression method defined in
method defined in [RFC8138]. The 6LR that injected the route MUST [RFC8138]. Unless configured otherwise, the border router MUST
uncompress the packet before forwarding over an external route, even uncompress the outgoing packet before forwarding over an external
when delivering to a RUL, even when it is not the destination in the route, and if it is not the destination of the incoming packet, and
outer header of the incoming packet, unless configured to do even when delivering to a RUL.
otherwise.
6.2.1. Support of IPv6 Encapsulation 6.2.1. Support of IPv6 Encapsulation
Section 2.1 of [USEofRPLinfo] sets the rules for forwarding IP-in-IP Section 2.1 of [USEofRPLinfo] sets the rules for forwarding IP-in-IP
either to the final 6LN or to a parent 6LR. In order to enable IP- either to the final 6LN or to a parent 6LR. In order to enable IP-
in-IP to the 6LN in Non-Storing Mode, the 6LN must be able to in-IP to the 6LN in Non-Storing Mode, the 6LN must be able to
decapsulate the tunneled packet and either drop the inner packet if decapsulate the tunneled packet and either drop the inner packet if
it is not the final destination, or pass it to the upper layer for it is not the final destination, or pass it to the upper layer for
further processing. Unless it is aware that the RUL can handle IP- further processing. Unless it is aware that the RUL can handle IP-
in-IP properly, the Root that encapsulates a packet to a RUL in-IP properly, the Root that encapsulates a packet to a RUL
skipping to change at page 13, line 29 skipping to change at page 13, line 29
A RUL is expected to process an unknown Option Type in a Hop-by-Hop A RUL is expected to process an unknown Option Type in a Hop-by-Hop
Header as prescribed by section 4.2 of [RFC8200]. This means in Header as prescribed by section 4.2 of [RFC8200]. This means in
particular that an RPI with an Option Type of 0x23 [USEofRPLinfo] is particular that an RPI with an Option Type of 0x23 [USEofRPLinfo] is
ignored when not understood. ignored when not understood.
6.2.3. Support of the Routing Header 6.2.3. Support of the Routing Header
A RUL is expected to process an unknown Routing Header Type as A RUL is expected to process an unknown Routing Header Type as
prescribed by section 4.4 of [RFC8200]. This means in particular prescribed by section 4.4 of [RFC8200]. This means in particular
that Routing Header with a Routing Type of 3 [RFC6553] is ignored that Routing Header with a Routing Type of 3 [RFC6553] is ignored
when the Segments Left is zero, and dropped otherwise. when the Segments Left is zero, and the packet is dropped otherwise.
7. Updated RPL Status 7. Updated RPL Status
The RPL Status is defined in section 6.5.1. of [RFC6550] for use in The RPL Status is defined in section 6.5.1. of [RFC6550] for use in
the DAO-Ack message and values are assigned as follows: the DAO-Ack message and values are assigned as follows:
+---------+--------------------------------+ +---------+--------------------------------+
| Range | Meaning | | Range | Meaning |
+=========+================================+ +=========+================================+
| 0 | Success/Unqualified acceptance | | 0 | Success/Unqualified acceptance |
 End of changes. 11 change blocks. 
39 lines changed or deleted 40 lines changed or added

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