On Jun 2, 2010, at 5:38 PM, Erik Nordmark wrote:
On 06/ 2/10 08:15 AM, Vishwas Manral wrote:
Hi Erik,
I agree (again) that the Source address and ICMP part is a problem
and
that needs to be solved. We can discuss this offline like you have
mentioned (maybe over the weekend) and send the conclusions to the
group.
There are two issues that have been identified in this thread:
- MTU-related issues - ICMP packet too big and other errors
- Need to fragment 1280 byte packets as part of adding RH4
It makes sense to think about approaches that would address both.
Yes and thanks to all for the fruitful discussions.
That said I have been trying to think of solutions to actually solve
the issue (instead of finding cases where the same issue may occur
:)), if the ROLL edge node did IP in IP tunnelling to the destination
and always fragmented packets say greater than say 1000 bytes. Would
that solve the issue?
Yes, if you do ROLL edge-to-edge IP in IP tunnels then you can reuse
10+ years of understanding of how to handle MTU, fragmentation etc.
Also I am not sure, if we can do it but if 15.4 said the IPv6 MTU is
1500 instead of 1280, wouldn't that solve the issue too?
No change needed in 15.4. The question is whether it would help if
RFC 4944 was revised to require offering more than 1280 bytes of MTU
to IP.
I think that would help remove the fragmentation issue since a 1280
byte packet would not need to be fragmented any more (assuming
1280+RH4 would be less than the that required MTU.)
But one would still have some way to handle the ICMP error issue.
Requiring that all ROLL edge router rewrite the ICMP errors would be
one way.
Just a clarification, ROLL is not tied to 15.4 and could run on many
other media with various MTU.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
