>> if link MTUs are not stable enough, there will be more ICMP too big
>> than we desire.
>Please provide an analysis. I don't think this is the case.
there was some research paper on IPv4 PMTU from aist-nara.ac.jp,
i don't have a reference now.
>The point is that I don't see why there should be anything
>new here for tunneling.
>The tradeoffs for path MTU discovery are:
> - downside of ICMP error packets
> - downside of additional roundtrip times due to the data packets being
> lost when the packet is to big
> - the benefit of making the retransmission unit the same as the loss
> unit, while being able to with larger packets
>If this tradeoff comes up with PMTUD makes sense when there is no
>tunneling, then I don't see why the same conclusion doesn't hold
>for the case of nested PMTUD using tunnels.
>So I'm looking forward to your performance analysis.
i think i have answered this (partially) in other emails.
we are from very different assumption.
>> with the cost of complexity in tunnel endpoint implementations (needs
>> to maintain IPv4 path MTU and reflect it to IPv6 tunnel link MTU).
>Yes. And there is additional complexity to implement PMTUD in the non-tunneling
>case. Thus I think your arguments about performance and implementation
>complexity can also be used to argue that we shouldn't do PMTUD at all and
>instead send with 1280 bytes.
requiring and maintaining PMTU for IPv4 for tunnel egress/ingress
is different from requirement for PMTU for IPv6. i disagree with
the above logic.
>FWIW The Solaris implementation doesn't have soft state in the tunneling
>pseudo-device driver. It is all reflected in the conceptual neighbor cache
>for the "upper IP layer" when an ICMP too big arrives from the "lower IP
>layer".
then what is the IPv6 link MTU for tunnel interface, when you don't
have IPv4 PMTU information? (like for the very first packet to go out
from the path)
>> i would really like to know how many of existing implementations follow
>> this part of RFC2983.
>Solaris does.
*BSD and derived implementations don't (MacOS X at least, and probably
JunOS and ExtremeWare).
itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
