[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Ivip's fix for tunnel o-head, PMTUD & fragmentation problems
>> ... While it does this, it fragments longer
>> packets which it tunnels to the ETR, even if the sending host set
>> the DF bit.
> As written, that seems to be a direct violation of RFC 791.
Perhaps so. RFC 791 doesn't mention "tunnel".
In redesigning the architecture of the Internet, we may well decide
that our 2008-2009 invention of an ITR-ETR tunnel should contradict
or re-interpret something which was written 27 years earlier.
> I doubt we can anticipate all the unintended consequences.
This is bound to be true when introducing a major architectural
change. In this case, most of the consequences will be limited to
the tunneled part of the path. There will also temporarily be
marginal loss of efficiency, longer time of transit, and/or greater
packet loss - which affects the final arrival of packets at the
> A tunnel, like a link layer, is fully entitled transparently
> to fragment *and reassemble* the packets that it carries, but
> that isn't what you propose.
I specifically propose the ETR reassembles the packet at the end of
the tunnel, before decapsulating the inner packet. I tried to keep
the mailing list message short, so I didn't go into such detail.
In the terse description:
Else (if the encapsulated packet's length is greater than this
If the ITR has not attempted to discover the actual MTU to
this ETR or is in the process of trying to discover it:
The ITR fragments the packet (even if the DF flag on the
original packet was set) and begins an ETR-Path MTU
Discovery phase, which should be complete in a few
I have just added at this point:
***The two fragments are reassembled by the ETR before
the inner packet is decapsulated.***
This was made explicit in the more detailed description which follows:
The ETR's main datapath (FIB) activities are unchanged by this
addition to Ivip, other than that the ETR is assumed to be able to
reassemble a fragmented packet from the ITR before decapsulating
I have named this proposal IPTM - "ITR Probes Tunnel MTU". I think
it is just as applicable to the other ITR-ETR proposals as to Ivip -
but the Traceroute functionality is specific to Ivip, since the
other proposals use the ITR's address as the Source Address for
I have added a section on potentially multiple ITRs being the start
of the tunnel, and given the Traceroute material its own heading.
to unsubscribe send a message to firstname.lastname@example.org 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