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
--------------------------------------------------------------------
