[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