RE: 6MAN WG Last Call:draft-ietf-6man-rpl-option

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

Hi again Brian:

I'm taking one thing back though. Unless I miss something, there's
probably no need to recomputed any checksum even in transport mode,
since the next header is that of the ULP...

Pascal
http://www.xtranormal.com/watch/7011357/


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Pascal Thubert (pthubert)
> Sent: Tuesday, November 16, 2010 3:58 PM
> To: Brian Haberman; IPv6 WG Mailing List
> Cc: Bob Hinden
> Subject: RE: 6MAN WG Last Call:draft-ietf-6man-rpl-option
> 
> Hi Brian:
> 
> RPL made a pass to clean up the interface with the HbH spec whereby:
> 
> - RPL defines the bits and bytes that need to be transported, and when
the
> information needs to be transported in a packet
> - HbH (this spec) defines how the RPL packet information is placed in
and
> obtained from the packet
> 
> Considering that the specs are homogeneous at this time, it is mostly
> editorial, but I'd rather that:
> 
> 1)  section 3 does not redefine O, R, F, Rank and instance.
> IMHO, it should simply say that those fields are defined in RPL as
part of the
> RPL Packet Information.
> Eg;
> 
>   SenderRank:  16-bit field set to zero by the source and to
>          DAGRank(rank) by a router that forwards inside the RPL
network.
> ->
>   SenderRank:  16-bit field as defined in [RPL] section 11.2. Loop
Avoidance
> and Detection
> 
> 2)  section 4 does not mandate when the HbH is used. RPL does that.
> 
>    Routers MUST include a RPL Option when forwarding datagrams that do
>    not already contain a RPL Option. If one does not already exist,
>    routers MUST use IPv6-in-IPv6 tunneling, as specified in [RFC2473]
to
> ->
>    RPL controls when and which information is to be placed in a
packet.
>    If RPL requires to place RPL Packet Information in a packet that
does not
>    already contain a RPL Option, the router MUST insert the Option
using
>    IPv6-in-IPv6 tunneling, as specified in [RFC2473] to
> 
> 
> Also, it is unclear when looking at a packet within the RPL domain
whether IP
> in IP was used or not. A RPL node may use a "transport"
> without IP in IP when it generates a packet, whereas a packet coming
from
> the outside will have IP in IP.
> I'd suggest to use a bit out of the 5 spare to indicate tunnel vs.
> transport. Based on the bit, we can have a crisper text in section 5,
indicating
> how to strip the packet from the Option.
> - if the bit is on indicating the tunnel mode, then the router will
decapsulate
> the packet
> - if the bit is off indicating the transport mode, then the router
removes the
> Option and recomputes the upper layer checksum.
> 
> Finally, I'd suggest that we make the MUST use IP in IP a SHOULD,
allowing
> for extreme cases that IP in IP is not used and referencing
draft-hui-6man-
> rpl-headers for the risks involved.
> 
> What do you think?
> 
> Pascal
> http://www.xtranormal.com/watch/7011357/
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> > Brian Haberman
> > Sent: Monday, November 15, 2010 10:53 PM
> > To: IPv6 WG Mailing List
> > Cc: Bob Hinden
> > Subject: 6MAN WG Last Call:draft-ietf-6man-rpl-option
> >
> > All,
> >      This starts a 6MAN WG Last Call on advancing:
> >
> > Title     : RPL Option for Carrying RPL Information in
> >             Data-Plane Datagrams
> > Author(s) : J. Hui, J. Vasseur
> > Filename  : draft-ietf-6man-rpl-option-01.txt
> > Pages     : 16
> > Date      : 2010-10-22
> >
> > as a Proposed Standard.  Substantive comments should be sent to the
> > mailing list and/or the WG co-chairs.  Editorial comments can be
> directed to
> > the document authors.  This last call will end on December 6, 2010.
> >
> > Regards,
> > Brian & Bob
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------