Re: [Roll] UNaware leaves (4)

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

Hello Michael

The rest below:

> 
> I want to get rid of the IPIP headers not because they take space, but because
> the represent code paths not frequently taken. In particular, the hop-by-hop
> IPIP header just pisses me off.

Yes;

By definition a RPL aware leaf applies useofrplinfo and a RUL does not know RPL. We're on a fine line. 
I've added text that I wish you e

 
> >   From then on, the 6LN periodically sends a new NS(EARO) to refresh
> >   the NCE state before the lifetime indicated in the EARO expires, with
> >   TID that is incremented each time till it wraps in a lollipop
> >   fashion.  As long as the 'R' flag is set and this router can still
> 
> lollipop fashion probably needs a reference.  What does TID start with?
> (what's the stick of the lollipop?  I guess this is in 8505, but reviewers
> probably won't know this unless we tell them)

Added references to section 5.2.1 of RFC 8505.

> 
> I think that "is left to zero" is a bit awkward.
> I think that "is zero" is better?
> I think that the Opaque field isn't zero, but is empty?

OK
 



> >   o  the External 'E' flag in the Transit Information Option (TIO)
> >      associated to the Target Option is set to indicate that the 6LR
> >      redistributes an external target into the RPL network.  This is
> >      how the Root knows in Non-Storing Mode to use IP-in-IP and
> >      terminate the outters headers at the 6LR that generated the DAO.
> 
> There are a lot of other circumstances in which the root has to use an IPIP.  I
> think that it would be better to say:
> 
> }   o  the External 'E' flag in the Transit Information Option (TIO)
> }      associated to the Target Option is set to indicate that the 6LR
> }      redistributes an external target into the RPL network.  When
> }      the Root has to use an IP-in-IP [useofrplinfo], then this flag
> }      indicates the IP-in-IP should be addressed to this node.
> 

Picked. 
*Important Note:*  that for a basic RUL the tunnel must terminate at the parent, which must be known to do the encaps. Only non storing signaling allows that. S I propose that for external routes, we use non-storing signaling even in a storing mode DODAG.

Proposed text


   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)
   <xref target="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,
   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
   <xref target="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 outter 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.

> I think that traffic from the Root to the RAN will not need an IP-IP,
> just the RH3/RPI, which the RAN will skip.   Traffic from elsewhere
> will have an IPIP in for that Root to add the RH3/RPI.  But, since the RAN will
> skip IPIP, the Root could address traffic.
> 
> Are there projected DAO interactions where the Root arranges for traffic to
> go laterally across the DODAG that might need some consideration here?

I do not see that, need more thoughts

> 
> ASIDE: should this document effectively Update UseofRPLINFO?

Not sure, please reviews the new text above on using non storing signaling etc..

> Security Considerations will probably need another page.

Yes.

Michael: the ball is yours now. Can you please proofread and if we agree I'll publish and raise attention on the changes we just discussed here.

Many thanks 

Pascal