Hi Brian,
I'm still not sure that I get the point of any of this.
Well, let's try to fix that.
The Internet architecture says that end-systems are
responsible for e2e issues, and PMTU sure seems like
an e2e issue.
Except that it's not. For PMTUD discovery to operate, the network MUST
respond with ICMP messages and those messages MUST make it through to
the source. Now, theoretically, the host would simply back down its MTU
if there is a packet loss, but pragmatically, not enough implementations
do that correctly for this to be a truly adequate solution. [Aside: if
you feel that we should move that direction, we should deprecate the
ICMP messages.]
Thus, it's not an e2e issue, it has the network involved in it, up to
the elbows.
It's a blot on the architecture that
IPv4 permits fragmentation en route; imagine a world
in which DF is set in every IPv4 packet - hosts would
end up discovering (or configuring) a suitable MTU.
That's also how IPv6 works.
Correction: doesn't work.
Even with correctly implemented hosts and routers, there are two major
problems:
Problem 1) ICMP filtering
Thanks to the prevalence of DoS attacks, many end-sites filter out ICMP
messages. While most static filters are capable of being configured to
pass ICMP PTB messages, most site administrators have not been so
careful as to be that specific and instead simply drop all inbound
ICMP. This effectively breaks PMTUD. Even if administrators did pass
PTB messages, they'd simply get DoSed that way too, or MTU'ed down to
576. [Aside: In an insecure environment, the network CANNOT effectively
signal to the host. This is a major architectural issue.]
Problem 2) Tunneling
If a packet is tunneled, then the source address on the tunneled packet
is that of the router that performed the encapsulation, NOT the original
source host. Thus, if there is an MTU issue in the middle of the tunnel
span, the PTB message is sent to the encapsulating router that cannot
effectively do anything about the issue. This problem is aggravated
because the tunnel itself detracts from the MTU as seen by the source.
I think it's another blot on the architecture for
a map-and-encap solution to even touch this problem -
except for a SHOULD statement about the MTU to be provided
by every tunnel, which should obviously be a bit bigger
than the required IPv6 Internet MTU.
The blot on the architecture is that PMTUD doesn't work and folks seem
to continue to be in denial about it. We need to fix it, completely
independently of RRG issues. Further, if we want to want to use any
kind of tunneling in our solution, we need to address this problem head on.
Tony