Hi Jonathan, I was just thinking and the following came to my mind. What do you do for a packet going out of the RPL domain? You probably have to remove the RH4 header when the packet has to go out of the domain.
If the above is an issue, it is best solved with IP-in-IP tunnels. So the outer IP header with the RH4 header will be removed by the edge node and all will be good. I think you should still consider the solution of IP-in-IP in the RPL domain, even after increasing the MTU size. Thanks, Vishwas On Fri, Jun 4, 2010 at 8:37 AM, Vishwas Manral <vishwas.i...@gmail.com> wrote: > Hi Jonathan, > > I agree changing the MTU to a higher value say 1500 solves the MTU issues. > > The concern I have is any checks on the RH4 header by an intermediate > device fail (for example loop detected), it is not caused by the > source but by the intermediate device (also it means that RH4 header > related information may be propagated outside the domain). > > Another thing we can do is send ICMP to source as well as RPL edge > (but this causes an amplification 1 packet leads to 2 reply messages). > > Thanks, > Vishwas > > On Fri, Jun 4, 2010 at 8:29 AM, Jonathan Hui <j...@archrock.com> wrote: >> >> Hi Vishwas, >> >> But by specifying a RH4_MIN_MTU, we avoid the need for tunnels. Without >> tunnels, I'm not sure there's a good use case for ICMP errors caused by RH4 >> headers to go back to the inserting node rather than the source. If the >> packet can't be delivered because the source route is bad, that's not any >> different than a routing failure. If the packet can't be delivered because >> it is too big, then a packet too big message with MTU set to RH4_MIN_MTU - >> MAX_RH4_SIZE should be sent to the source. Are there specific ICMP errors >> you have in mind that should be sent to the inserting node rather than the >> source? >> >> -- >> Jonathan Hui >> >> On Jun 4, 2010, at 8:21 AM, Vishwas Manral wrote: >> >>> Hi Jonathan, >>> >>> If an intermediate device fiddles with a packet, it should get the >>> ICMP message. So if the ICMP message states error in RH4 header the >>> ingress may not be able to do much. >>> >>> In a tunnel case the following happens: >>> >>> It is possible that one of the routers along the tunnel interior >>> might encounter an error while processing the datagram, causing it to >>> return an ICMP [RFC-792] error message to the encapsulator at the IP >>> Source of the tunnel. Unfortunately, ICMP only requires IP routers >>> to return 8 bytes (64 bits) of the datagram beyond the IP header. >>> This is not enough to include the entire encapsulated header. Thus, >>> it is not generally possible for an encapsulating router to >>> immediately reflect an ICMP message from the interior of a tunnel >>> back to the originating host. >>> >>> However, by carefully maintaining "soft state" about its tunnels, the >>> encapsulator can return accurate ICMP messages in most cases. >>> >>> You can have the same behavior for ICMP in your case too is what I >>> have been trying to say. >>> >>> Thanks, >>> Vishwas >>> >>> On Fri, Jun 4, 2010 at 8:16 AM, Jonathan Hui <j...@archrock.com> wrote: >>>> >>>> Hi Vishwas, >>>> >>>> If we go down the route of specifying a RH4_MIN_MTU, I'm not so sure we >>>> want >>>> to send the ICMP message to any place other than the source. Destination >>>> unreachable messages should go to the source. Packet too big messages >>>> should also go back to the source (after the RPL edge router does its >>>> magic >>>> to remove any side effects of RH4 headers). >>>> >>>> Sending the ICMP message back to the source would maintain the same >>>> prevalent behavior within IP today. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> On Jun 3, 2010, at 10:40 PM, Vishwas Manral wrote: >>>> >>>>> 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 >>>>> -------------------------------------------------------------------- >>>> >>>> >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
