[Roll] Terminating IP in IP at the 6LR

["Pascal Thubert (pthubert)" <[e-mail]>]

Makes sense Michael:

 we cannot expect that by default the RUL is able to terminate IP in IP. So unless configured otherwise we must terminate at the 6LR. Which is only known in non storing. So we need non storing signaling for 'E' routes. OK...
about updating usefrplinfo, unsure. If you think so you have the pen. I 'dd like to publish this early next week if that's OK for you.

I added text:

"
6.2.3.  Support of IPv6 Encapsulation

   A RUL may support IPv6-in-IPv6 decapsulation when it is the
   destination of the outer header but that is not assumed by [RFC8504].
   If the 6LN is a RUL, it may be able to drop the inner packet if it is
   not the destination of the inner header.  By default the IP-in-IP
   tunnel should terminate at the parent 6LR so supporting this
   capability in a RUL is secondary.
"

Which seeds in the new text below:

"
6.2.  External Routes and RPL Artifacts

   RPL data packets are often encapsulated using IP-in-IP and in Non-
   Storing Mode, packets going down will carry an SRH as well.  RPL data
   packets also typically carry a Hop-by-Hop Header to transport a RPL
   Packet Information (RPI) [RFC6550].  These additional headers are
   called RPL artifacts.  When IP-in-IP is used and the outer headers
   terminate at a 6LR down the path (see Figure 7 for the format in
   Storing Mode), then the 6LR decapsulates the IP-in-IP and the packet
   that is forwarded to the external destination is free of RPL
   artifacts.

   IP-in-IP to the 6LR MUST be used if the final destination cannot
   handle or ignore the RPL artifacts or the way they are compressed
   [RFC8138].  An External route indicates by default a node or a prefix
   that is not known to handle or ignore the RPL artifacts.  The
   RECOMMENDED behaviour when using IP-in-IP to an External route is
   that the outer headers terminate at the 6LR that injected the
   External route.  Non-Storing Mode signaling MUST be used to inject
   External routes to the Root in order to advertise the 6LR that is
   associated to a RUL.

   In order to save the IP-in-IP encapsulation and to support Storing
   Mode of operation, it is preferred that the 6LN can ignore an RPI and
   consume a routing header in both the native and [RFC8138]-compressed
   forms.  In order to enable IP-in-IP to a 6LN in Non-Storing Mode, it
   is also of interest that the 6LN supports decapsulating IP-in-IP in
   both forms.
"


All the best,

Pascal

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Michael Richardson
> Sent: jeudi 29 août 2019 15:24
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] UNaware leaves
> 
> 
> Pascal Thubert (pthubert) <[e-mail]> wrote:
>     >> >   This specification does not alter the operation of a 6LoWPAN ND-
>     >> >   compliant 6LN, which is expected to operate as follows:
>     >>
>     >> really... I thought that we were making it able to deal with RPL artifacts,
> as
>     >> specified in section 6!!!
> 
>     > Which is as should already be. That's not even 6LoWPAN ND, that's IPv6
> if you look at it.
> 
> Well, I tried to push for 6man's host requirements bis (RFC8504) to include
> processing of IP(dst=me)IP(dst=me) to be included, but it was a hard push,
> and I didn't have the energy.
> 
> So, we are making requirements which go beyond 8504.
> 
>     >> What is the specific signal that the 6LR can use to know that the host is
> an RAN
>     >> rather than a RUL?
> 
>     > Yes we have text, maybe even repeated with terminology; e.g.,
> 
>     > "
>     > The 6LR advertises the
>     > Registered Address in DAO messages, if and only if it is triggered by
>     > an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a
>     > RUL.  If the 'R' flag is not set, then the Registering Node is
>     > expected to be a RAN that handles the reachability of the Registered
>     > Address by itself.
>     > "
> 
> got it.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-