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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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 > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
