[RRG] Ivip's fix for tunnel o-head, PMTUD & fragmentation problems

[Robin Whittle <rw@firstpr.com.au>]

I would appreciate feedback on an extension to Ivip I am planning.
Depending on how it fares in discussion on this list, I will add it
to a future version of the Ivip ID.  It will be some months before I
write a new version, because I want to develop some better ideas for
the Replicator system, and because I can't spend much time on this
at present.

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

This is IPv4-centric at present.

I propose the ITR use a TCP link, UDP probe packets and a simple new
protocol (together with traditional RFC1911 PMTUD) to determine the
MTU of the path to the ETR.  While it does this, it fragments longer
packets which it tunnels to the ETR, even if the sending host set
the DF bit.  After the ITR has a reliable estimate of the MTU, it
does not fragment packets, but rejects (with an ICMP Packet too Big
message) those packets which, when encapsulated, would be too long
for the estimated MTU of the path to the ETR.

Since Ivip uses the sending host's address for the outer header, I
suggest that Traceroute can be made to work for all routers,
including those in the tunnel, as long as the sending host uses a
somewhat modified Traceroute program, which is looking for the ICMP
packets generated by routers in the tunneled part of the path.  Such
a program could display the identity of the ITR and ETR in the path too.

Am I correct in thinking that the Traceroute program and principles
of operation are only used for diagnostic purposes?  That no other
protocol or application relies on Traceroute?  I would have to check
whether this is true of tricky protocols - STUN comes to mind.


As far as I know, no other ITR-ETR proposal currently has a method
of dealing with the problems of tunneling overhead and failure of
traditional RFC1191 Path MTU Discovery leading to fragmentation
(IPv4) or maybe dropped packets with no proper message getting to
the sending host (IPv6).  The closest is Bill Herrin's TRRP-via-02
proposal:

  http://bill.herrin.us/network/trrp-via02.html

but this relies on option headers, which are regarded as unsuitable
for most BGP routers:

  http://psg.com/lists/rrg/2007/msg00350.html


The new page also contains a critique of Fred Templin's sprite-mtu
proposal (draft-templin-inetmtu-04) - that it drops the first long
packets to ETR which is new to any one ITR, and that the sending
host will initially be forced to send lots of very short packets.

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/#sprite_critique

    - Robin



--
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