Hi JP, The approach is good, we however still need to solve the ICMP message being sent to the source not the edge of the RPL network.
We can probably use the addr[0] approach which was discussed earlier. Thanks, Vishwas On Thu, Jun 3, 2010 at 10:35 PM, JP Vasseur <j...@cisco.com> wrote: > Thanks again for the feed-back. Does the WG support this approach ? > > Thanks. > > JP. > > On Jun 4, 2010, at 6:30 AM, Jonathan Hui wrote: > >> >> Hi Erik, >> >> On Jun 3, 2010, at 2:10 AM, Erik Nordmark wrote: >> >>> On 06/ 3/10 01:03 AM, JP Vasseur wrote: >>> >>> We can use the outlined approach as long as we can require such media to >>> support a MTU for IP packets that is slightly larger than 1280. >>> Thus we'd need a maximum size for the amount the ROLL ingress would add >>> to the packet (RH4 and the HBH), and then require that the ROLL links >>> support at least 1280 plus that max. Essentially a ROLL_MIN_MTU. >>> >>> That would ensure that the ROLL ingress would never need to fragment a >>> 1280 byte packet. And for packets larger than 1280, the rewriting of the >>> ICMP errors at the ROLL boundary would make path MTU discovery work. >>> >>> But if we can't mandate such a ROLL_MIN_MTU, then the sensible approach >>> would seem to be to do IP in IP encapsulation at the ROLL ingress. >> >> >> Thanks for all your thoughts on this subject. The two options are clear. >> >> Of the two choices, I prefer to specify a ROLL_MIN_MTU and avoid IP in IP >> encapsulation just to support routing. The former approach seems to be less >> onerous on resource constrained nodes that are expected within a RPL >> network. It avoids one possible source of IP-layer fragmentation. Of >> course, as you noted, the edge router must not allow any side effects of RH4 >> to escape the RPL network, which is really the intended use of RH4 anyway. >> >> It's also important that we include the rpl-option overhead in >> ROLL_MIN_MTU, so we'll have to specify a maximum for both the rpl-option and >> rpl-routing-header (as you noted in the Anaheim meeting). >> >> In 6LoWPAN networks, while RFC 4944 indicates a MTU of 1280 bytes, the >> fragmentation mechanism does support up to 2048 bytes so that is comforting. >> So far, I'm not aware of any existing links intended for use with RPL that >> cannot support an MTU that is a bit larger than 1280 bytes. >> >> If people think specifying a ROLL_MIN_MTU is reasonable, we'll submit an >> update to the rpl-routing-header draft that incorporates these changes and >> the several other ones brought up over the past week. >> >> -- >> Jonathan Hui >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
