[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] Ivip's fix for tunnel o-head, PMTUD & fragmentation problems
Robin,
Please check the new draft version, which has been awaiting
submission approval since 10/15. It has also been delayed
for several days in the I-D submission process somehow, but
I am hoping it will be taken into the repository soon. For
now, you can view the new draft version at:
http://ipvlx.org/spritemtu-05.txt
This version asserts that there is nothing fundamentaly wrong
in the normative tunnel MTU handling specifications (RFCs 2003;
4213) - only that they are incomplete. All that is needed for
completion is:
1) a means for avoiding MTU-related black holes
2) a means for avoiding corruption in reassembly buffers
Anything else (like improved convergence and efficiency)
might be considered as just a "nice to have" bonus. Again,
please re-check with the new version, but IMHO this is more
of an engineering-oriented document and should perhaps be
taken up on the IETF lists.
Fred
fred.l.templin@boeing.com
> -----Original Message-----
> From: Robin Whittle [mailto:rw@firstpr.com.au]
> Sent: Tuesday, October 16, 2007 10:55 AM
> To: Routing Research Group list
> Subject: [RRG] Ivip's fix for tunnel o-head, PMTUD &
> fragmentation problems
>
> 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
>
--
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