ietf
[Top] [All Lists]

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

2017-02-15 15:32:58
Hi, Brian,


On 2/15/2017 1:26 PM, Brian E Carpenter wrote:
On 16/02/2017 10:12, Joe Touch wrote:
Brian (et al.),


On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
practice the
Internet breaks the mechanism. However it breaks it is a way that seems
disruptive to some user traffic. The document is really guidance
one how hosts might use  ICMP for optimization, and arguable need
not be a standard at all.
I think that's a mischaracterisation of the mechanism (and the draft).
PMTUD is not an optimisation. Without it, you get black holes
PMTUD is an optimization to avoid fragmentation.

Without it, you use fragmentation (which has overheads and other
consequences, notably for IPv4).
In IPv6, you don't even know you *need* fragmentation without PMTUD,
since only the source is allowed to fragment. (That was one of the
many failure modes for 6to4, which is why the only safe approach was
to use 1280 always.) 
A compliant IPv6 source can send 1500 byte packets that a source without
PMTUD, which would need to be fragmented based on the assumption that
the path MTU is at its required minimum of 1280.

A compliant IPv6 source can send larger packets, which would work if the
receiver supported larger reassembly limits than 1500. There is no
currently standard mechanism to determine the receiver reassembly limit
in IPv6, but this IS supported in TCP.

Joe