Hi Richard, On Nov 10, 2011, at 8:14 AM, Richard Kelsey wrote:
> In section 4, "Router Behavior" draft-ietf-6man-rpl-option > says: > > Routers MUST use IPv6-in-IPv6 tunneling, as specified in > [RFC2473] to include a new RPL Option in datagrams that > are sourced by other nodes. > > What destination should be used for the tunnel header? The > router adding the RPL option may not know if the original > destination is inside or outside the RPL domain. And if the > original destination is outside the RPL domain, the router > may not know the address of the border router that will > forward the datagram outside. The tunnel header's destination should be the next RPL router along the path towards the destination. If, for example, a router only knows the next-hop destination (i.e. the DODAG Parent), then the tunnel header's destination will be the DODAG Parent itself. Note that the original packet may traverse multiple such tunnels within the same RPL domain in order to reach its destination. Let me propose the following update to Section 4: 4. RPL Router Behavior To deliver an IPv6 datagram to its destination, a router may need to insert a new RPL Option. Routers MUST use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a new RPL Option in datagrams that are sourced by other nodes. Using IPv6-in-IPv6 tunneling ensures that the delivered datagram remains unmodified and that ICMPv6 errors generated by inserting the RPL Option are sent back to the router that generated the routing header. A RPL router chooses the next RPL router that should process the original packet as the tunnel exit-point. In some cases, the tunnel exit-point will be the final RPL router along a path towards the original packet's destination and the original packet will only traverse a single tunnel. One example is when the final destination or the destination's attachment router is known to be within the same RPL domain. In other cases, the tunnel exit-point will not be the final RPL router along a path and the original packet may traverse multiple tunnels to reach the destination. One example is when a RPL router is simply forwarding a packet to one of its DODAG Parents. In this case, the RPL router sets the tunnel exit-point to a DODAG Parent. When forwarding the original packet hop-by-hop, the RPL router only makes a determination on the next hop towards the destination. A RPL router receiving an IPv6-in-IPv6 packet destined to it processes the tunnel packet as described in Section 3. of [RFC2473]. Before IPv6 decapsulation, the RPL router MUST process the RPL Option if one exists. If the router determines that it should forward the original packet to another RPL router, it MUST encapsulate the packet again using IPv6-in-IPv6 tunneling to include the RPL Option. Note that fields within the RPL Option that do not change hop-by-hop MUST remain the same as those received from the prior tunnel. To avoid fragmentation, it is desirable to employ MTU sizes that allow for the header expansion (i.e. at least 1280 + 40 (outer IP header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the maximum RPL Option header size for a given RPL network. To take advantage of this, however, the communicating endpoints need to be aware of the MTU along the path (i.e. through Path MTU Discovery). Unfortunately, the larger MTU size may not be available on all links (e.g. 1280 octets on 6LoWPAN links). However, it is expected that much of the traffic on these types of networks consists of much smaller messages than the MTU, so performance degradation through fragmentation would be limited. > Also, there are normative statements which use the term "RPL > domain", such as > > Datagrams sent between nodes within a RPL domain MUST include > a RPL Option or RPL Source Route Header (SRH) and MAY include > both. > > but "RPL domain" is not defined. In particular, if a RPL > router has a non-RPL-aware host, is the host inside the RPL > domain? Or is the router then a border router and messages > to the host need to be tunnelled to it? I agree that "RPL domain" is not well defined. But after some thought, I think replacing with "RPL Instance" may be more appropriate. In particular, we really want to limit the use of these RPL options/headers to a RPL Instance, not just a collection of routers that are all operating RPL. If you agree to the above, I'll make the changes in my updates to address the LC comments. Thanks. -- Jonathan Hui -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
