Hi Erik,
Sorry for the late response.
One thing I wanted to clarify was that not everytime we add data do we
change the source address. IPsec transport mode is a case in point. I
guess others have pointed out other cases. Can you explain your views
on the same?
Here is how ESP is done:
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------>|
>> The first thing is IPv6 MTU discovery is optional and the only
>> requirement is that the Minimum MTU is satisfied.
>
> Yes, but 1280 plus a routing header will exceed 1280.
> Thus the minimum MTU by itself doesn't save you.
One thing to consider is 802.15.4 has an MTU of only 127 octets. There
is a fragmentation and reassembly layer below the IP layer to satisfy
the MTU at each IP hop (just read RFC 4944). Once that is present in
my view it is not a problem to reassemble a larger packet. 802.15.4
experts would however be better suited to answer the question.
>> Also in cases like LLN the Routing paths may change so even after
>> discovery the Packet too big may come anyway. Besides PMTU issues you
>> mention are no different than a lot of cases such as tunnelling and
>> transition mechanisms.
> There is a very big difference.
> Tunneling means that the entity which added the tunneling headers is
> in the source IP address field in the outer header. Thus ICMP errors
> will be sent packet to the tunnel entry point. It can then compensate
> for the added headers by sending an ICMP packet too big with a
> smaller MTU back to the original source. This how IPvx in IPvy
> tunneling is done. See for instance RFC 4213 and RFC 2473.
You seem to take things literally. Can you explain the behavior in the
case of IPsec transport mode where no new IP header is added and how
it is different?
> The big difference is that when a router does something to grow the size of
> the packet (for instance, inserting a routing header) and it does not add an
> outer IP header with its source address, then the ICMP errors will go back
> to the original sender without being adjusted for the added header.
Thanks,
Vishwas
>> Thanks,
>> Vishwas
>>
>> On Sun, May 30, 2010 at 7:56 AM, Erik Nordmark<[email protected]>
>> wrote:
>>>
>>> The draft says:
>>> A RPL Router MAY insert a Type 4 Routing header if one does not
>>> already exist. The conditions for inserting a Type 4 Routing header
>>> are out of scope of this document.
>>>
>>> Having routers insert headers in packets they forward is know to be
>>> problematic in general, since it breaks path MTU discovery.
>>> Taking an example of a host which sends a packet which is 1500 bytes, and
>>> then receives an ICMP packet too big error saying "please limit packets
>>> to
>>> 1500 bytes", will not change the host's behavior. But that can happen if
>>> some router grows the packet to be more than 1500 bytes.
>>>
>>> Thus in general, the only safe way to insert headers in a packet is to
>>> have
>>> the "inserter" put an extra IP header, with itself as a source, then the
>>> inserted header, and then the original packet.
>>> That extra IP header ensures that any ICMP error go back to the
>>> "inserter",
>>> which can then compensate for its insertion before sending the ICMP error
>>> towards the sender of the original packet.
>>>
>>> Thus I think there is a question for 6man whether we think the
>>> constrained
>>> environment of ROLL is such that we can relax this. But it does require
>>> that
>>> all the routers at the edge of the ROLL network adjust the ICMP errors
>>> they
>>> forward to compensate for any inserted RH4 headers.
>>>
>>> Erik
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [email protected]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
