draft-ietf-roll-unaware-leaves-20.txt   draft-ietf-roll-unaware-leaves-21.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: 28 March 2021 24 September 2020 Expires: 3 April 2021 30 September 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-20 draft-ietf-roll-unaware-leaves-21
Abstract Abstract
This specification extends RFC6550 and RFC8505 to provide routing This specification extends RFC6550 and RFC8505 to provide routing
services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND
but do not participate in RPL. This specification also enables the but do not participate in RPL. This specification also enables the
RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG. RPL Root to proxy the 6LoWPAN keep-alive flows 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 28 March 2021. This Internet-Draft will expire on 3 April 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 4, line 27 skipping to change at page 4, line 27
request that the 6LR injects a Host route for the Registered Address request that the 6LR injects a Host route for the Registered Address
in the RPL routing on its behalf. A RUL may be unable to participate in the RPL routing on its behalf. A RUL may be unable to participate
because it is very energy-constrained, or because it is unsafe to let because it is very energy-constrained, or because it is unsafe to let
it inject routes in RPL, in which case using 6LowPAN ND as the it inject routes in RPL, in which case using 6LowPAN ND as the
interface for the RUL limits the surface of the possible attacks and interface for the RUL limits the surface of the possible attacks and
optionally protects the address ownership. optionally protects the address ownership.
The RPL Non-Storing Mode mechanism is used to extend the routing The RPL Non-Storing Mode mechanism is used to extend the routing
state with connectivity to the RULs even when the DODAG is operated state with connectivity to the RULs even when the DODAG is operated
in Storing Mode. The unicast packet forwarding operation by the 6LR in Storing Mode. The unicast packet forwarding operation by the 6LR
serving a RUL, as described in section 4.1 of [USEofRPLinfo]. serving a RUL is described in section 4.1 of [USEofRPLinfo].
Examples of possible RULs include lightly powered sensors such as Examples of possible RULs include lightly powered sensors such as
window smash sensor (alarm system), and kinetically powered light window smash sensor (alarm system), and kinetically powered light
switches. Other applications of this specification may include a switches. Other applications of this specification may include a
smart grid network that controls appliances - such as washing smart grid network that controls appliances - such as washing
machines or the heating system - in the home. Appliances may not machines or the heating system - in the home. Appliances may not
participate to the RPL protocol operated in the Smartgrid network but participate to the RPL protocol operated in the Smartgrid network but
can still interact with the Smartgrid for control and/or metering. can still interact with the Smartgrid for control and/or metering.
This document is organized as follows: This document is organized as follows:
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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]. Unless configured otherwise, the border Router MUST [RFC8138]. Unless configured otherwise, the border Router MUST
restore the outgoing packet before forwarding over an external route, restore the outgoing packet before forwarding over an external route,
even if it is not the destination of the incoming packet, and even even if it is not the destination of the incoming packet, and even
when delivering to a RUL. when delivering to a RUL.
4. 6LoWPAN Neighbor Discovery 4. 6LoWPAN Neighbor Discovery
4.1. RFC 6775 Address Registration 4.1. RFC 6775 Address Registration
The classic "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861]
[RFC4862] was defined for serial links and transit media such as [RFC4862] was defined for serial links and transit media such as
Ethernet. It is a reactive protocol that relies heavily on multicast Ethernet. It is a reactive protocol that relies heavily on multicast
operations for address discovery (aka lookup) and duplicate address operations for address discovery (aka lookup) and duplicate address
detection (DAD). detection (DAD).
"Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]
adapts IPv6 ND for operations over energy-constrained LLNs. The main adapts IPv6 ND for operations over energy-constrained LLNs. The main
functions of [RFC6775] are to proactively establish the Neighbor functions of [RFC6775] are to proactively establish the Neighbor
Cache Entry (NCE) in the 6LR and to prevent address duplication. To Cache Entry (NCE) in the 6LR and to prevent address duplication. To
that effect, [RFC6775] introduces a new unicast Address Registration that effect, [RFC6775] introduces a new unicast Address Registration
skipping to change at page 11, line 38 skipping to change at page 11, line 38
that provide routing services. The RUL needs to register to all the that provide routing services. The RUL needs to register to all the
6LRs from which it desires routing services. 6LRs from which it desires routing services.
Parallel Address Registrations to several 6LRs should be performed in Parallel Address Registrations to several 6LRs should be performed in
an rapid sequence, using the exact same EARO for the same Address. an rapid sequence, using the exact same EARO for the same Address.
Gaps between the Address Registrations will invalidate some of the Gaps between the Address Registrations will invalidate some of the
routes till the Address Registration finally shows on those routes. routes till the Address Registration finally shows on those routes.
[RFC8505] introduces error Status values in the NA(EARO) which can be [RFC8505] introduces error Status values in the NA(EARO) which can be
received synchronously upon an NS(EARO) or asynchronously. The RUL received synchronously upon an NS(EARO) or asynchronously. The RUL
MUST support both cases and MUST refrain from using the address when needs to support both cases and should refrain from using the address
the Status Value indicates a rejection. when the Status Value indicates a rejection.
5.2. Support of IPv6 Encapsulation 5.2. Support of IPv6 Encapsulation
Section 2.1 of [USEofRPLinfo] defines the rules for tunneling either Section 2.1 of [USEofRPLinfo] defines the rules for tunneling either
to the final destination (e.g., a RUL) or to its attachment Router to the final destination (e.g., a RUL) or to its attachment Router
(designated as 6LR). To terminate the IP-in-IP tunnel, the RUL, as (designated as 6LR). To terminate the IP-in-IP tunnel, the RUL, as
an IPv6 Host, must be able to decapsulate the tunneled packet and an IPv6 Host, must be able to decapsulate the tunneled packet and
either drop the inner packet if it is not the final destination, or either drop the inner packet if it is not the final destination, or
pass it to the upper layer for further processing. Unless it is pass it to the upper layer for further processing. Unless it is
aware by other means that the RUL can handle IP-in-IP properly, which aware by other means that the RUL can handle IP-in-IP properly, which
skipping to change at page 14, line 22 skipping to change at page 14, line 22
information affecting the construction and maintenance of the DODAG, information affecting the construction and maintenance of the DODAG,
as well as operational parameters for RPL on the DODAG, through the as well as operational parameters for RPL on the DODAG, through the
DODAG. As shown in Figure 4, the Option was originally designed with DODAG. As shown in Figure 4, the Option was originally designed with
4 bit positions reserved for future use as Flags. 4 bit positions reserved for future use as Flags.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14| |P| | |A| ... | | Type = 0x04 |Opt Length = 14| |P| | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
<- Flags ->
Figure 4: DODAG Configuration Option (Partial View) Figure 4: DODAG Configuration Option (Partial View)
This specification defines a new flag "Root Proxies EDAR/EDAC" (P). This specification defines a new flag "Root Proxies EDAR/EDAC" (P).
The "P" flag is set to indicate support for this specification at the The "P" flag is set to indicate support for this specification at the
Root within the DODAG. The "P" flag is encoded in position 1 of the Root within the DODAG. The "P" flag is encoded in position 1 of the
reserved Flags in the DODAG Configuration Option (counting from bit 0 reserved Flags in the DODAG Configuration Option (counting from bit 0
as the most significant bit) and set to 0 in legacy implementations as the most significant bit) and set to 0 in legacy implementations
as specified respectively in Sections 20.14 and 6.7.6 of [RFC6550]. as specified respectively in Sections 20.14 and 6.7.6 of [RFC6550].
The "P" flag is set to indicate that the Root performs the proxy The "P" flag is set to indicate that the Root performs the proxy
operation, which implies that it supports the Updated RPL Target operation, which implies that it supports the Updated RPL Target
Option (see Section 6.1). Option (see Section 6.1).
Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
definition of the Flags applies to Mode of Operation (MOP) values definition of the Flags applies to Mode of Operation (MOP) values
zero (0) to six (6) only, leaving the flags reserved for MOP value zero (0) to six (6) only. For a MOP value of 7, the Root is expected
seven (7). For a MOP value of 7, the bit in position 1 is considered to perform the proxy operation by default.
unallocated and the Root is expected to perform the proxy operation
by default.
The RPL DODAG Configuration Option is typically placed in a DODAG The RPL DODAG Configuration Option is typically placed in a DODAG
Information Object (DIO) message. The DIO message propagates down Information Object (DIO) message. The DIO message propagates down
the DODAG to form and then maintain its structure. The DODAG the DODAG to form and then maintain its structure. The DODAG
Configuration Option is copied unmodified from parents to children. Configuration Option is copied unmodified from parents to children.
[RFC6550] states that "Nodes other than the DODAG Root MUST NOT [RFC6550] states that "Nodes other than the DODAG Root MUST NOT
modify this information when propagating the DODAG Configuration modify this information when propagating the DODAG Configuration
option". Therefore, a legacy parent propagates the "T" flag as set option". Therefore, a legacy parent propagates the "T" flag as set
by the Root, and when the "T" flag is set, it is transparently by the Root, and when the "T" flag is set, it is transparently
flooded to all the nodes in the DODAG. flooded to all the nodes in the DODAG.
 End of changes. 8 change blocks. 
11 lines changed or deleted 10 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/