As another side note, this new draft revision creates a situation where the hop limit from the RPL router performing source routing may be one and hence it cannot use SRH (because Segments Left becomes zero and no address can be included). In order to make it appear as if it tried the source routing with one hop, I think the RPL router must forward the packet to the next hop that it should normally pick for a source routing without modifying the original packet (that is, the destination address remains the same as the final destination). I don't think this requires any change to the draft because the RPL router in this case is not using SRH and hence out of scope of this draft.
BR, Kundok ________________________________ From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Park, Kundok Sent: Monday, December 19, 2011 1:18 PM To: ipv6@ietf.org Subject: draft-ietf-6man-rpl-routing-header-07 It seems that the following text on page 10 has some slight oversights: " In order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH MUST set the Segments Left to no greater than the original datagram's IPv6 Hop Limit value upon forwarding. " should have been as follows: " In order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH in an IPv6-in-IPv6 tunnel MUST set the Segments Left to less than the original datagram's IPv6 Hop Limit value upon forwarding. " If the Segments Left is equal to Hop Limit value, the source route includes one more hop than the hop limit, which is not intended here. The other change is to make clear that the above phrase does not apply to the case where the SRH is directly included within the original packet. As a side note, the traceroute application doesn't seem to be able to handle the case with no tunnel use, because the original datagram destination address alters when SRH is added, unless, I guess, traceroute application is re-written to handle source routing in returned ICMPv6 error messages. Perhaps, that recommended direct inclusion of SRH should be removed? Best Regards, Kundok
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
