[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
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
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg