Subject: [Roll] I-D Action: draft-ietf-roll-unaware-leaves-04.txt

From: [email-masked]
Date: Mon, 09 Sep 2019 06:24:28 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF.

        Title           : Routing for RPL Leaves
        Authors         : Pascal Thubert
                          Michael C. Richardson
	Filename        : draft-ietf-roll-unaware-leaves-04.txt
	Pages           : 30
	Date            : 2019-09-09

Abstract:
   This specification extends RFC6550 and RFC8505 to provide unicast and
   multicast routing services in a RPL domain to 6LNs that are plain
   hosts and do not participate to RPL.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-04
https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Sep 2019 14:34:02 +0000

Dear all;

This version syncs with the work in progress on external routes in useofrplinfo, which we extracted from the RFC editor Q.
The proposed change is contained in one new section 4.1 and the proposed operation is as follows 
(candidate change for useofRPLinfo):

"

4.1.  Updates to RFC6550: Advertise External Routes with Non-Storing
      Mode Signaling.

   Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to
   indicate that the 6LR that generates the DAO redistributes external
   targets into the RPL network.  An external Target is a Target that
   has been learned through an alternate protocol, for instance an route
   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
   external target cannot be guaranteed to ignore the RPL artifacts and
   cannot be expected to process the [RFC8138] compression correctly.
   This means that the RPL artifacts and the compression should be
   contained in an IP-in-IP encapsulation that is removed by the 6LR.

   This specification updates RPL [RFC6550] to RECOMMEND that external
   targets are advertised using Non-Storing Mode signaling even in a
   Storing-Mode network.  This way, all packets to an external target
   reach the Root that can encapsulate them, and the Root is informed of
   the address of the 6LR that terminates the IP-in-IP tunnel.  In case
   of an external target, the Root SHOULD use the same IP-in-IP
   encapsulation for packets that it generates or that are originated
   within the RPL domain as if the packets were coming from the
   Internet.

   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
   and to ignore a HbH header as prescribed by [RFC8200].  The target
   may have been learned through as a host route or may have been
   registered to the 6LR using [RFC8505].  IP-in-IP encapsulation MAY be
   avoided for Root to RUL communication if the RUL is known to process
   the packets as forwarded by the parent 6LR without decapsulation.

   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
   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
   that the RUL supports IP-in-IP decapsulation.

   A node that is reachable over an external route is not expected to
   support [RFC8138].  Whether a decapsulation took place or not and
   even when the 6LR is delivering the packet to a RUL, the 6LR that
   injected the external route MUST uncompress the packet before
   forwarding over that external route.

"

Comments welcome;

Pascal

-----Original Message-----
From: Roll <[email-masked]> On Behalf Of [email-masked]
Sent: lundi 9 septembre 2019 15:24
To: [email-masked]
Cc: [email-masked]
Subject: [Roll] I-D Action: draft-ietf-roll-unaware-leaves-04.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll