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