[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] Fwd: Tunnel MTU
Hi Brian,
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Tuesday, September 25, 2007 7:54 PM
> To: Templin, Fred L
> Cc: rrg@psg.com
> Subject: Re: [RRG] Fwd: Tunnel MTU
>
> On 2007-09-25 09:33, Templin, Fred L wrote:
> > Brian,
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> >> Sent: Sunday, September 23, 2007 4:35 PM
> >> To: Templin, Fred L
> >> Cc: rrg@psg.com
> >> Subject: Re: [RRG] Fwd: Tunnel MTU
> >>
> >> I must confess that I don't like loading up tunnel end-points
> >> with this kind of complexity.
> >
> > Ideally, the tunnel endpoint (TE) could simply set an MTU
> > of (64KB - ENCAPS) and admit all packets smaller than that
> > size. But, that would result in excessive in-the-network
> > fragmentation and/or silent loss due to path MTU restrictions.
> > Also, the tunnel must be made capable of passing packets as
> > large as 1280 bytes (for IPv6) and should be made capable of
> > passing packets up to 1500 bytes or larger (for all tunnels).
> >
> >> Architecturally, I much prefer
> >> the e2e RFC 4821 approach. That isn't exclusive to TCP.
> >
> > I agree that the e2e RFC 4821 approach is desireable, but
> > the tunnel cannot control the e2e use of RFC 4821 and
> > cannot even detect when RFC4821 is being used. So, the
> > tunnel has to provide consistent handling of packets
> > of various sizes independent of RFC821.
>
> That's where we differ. I'm arguing that the tunnel shouldn't
> worry about it. MTU is an e2e problem and we should focus on
> solving it e2e. Solving it specifically for tunnels still
> leaves the problem open at Internet level.
By that argument, I guess we should just set the MTU of all
tunnels to (64KB-ENCAPS)? It would be nice, but its not quite
that simple. IMHO, existing tunneling mechanisms have MTU
issues in need of a solution independent of any e2e solutions,
and the e2e and tunneling solutions should be complimentary.
> >> In fact there's a fairly simple approach to MTU discovery for
> >> UDP based protocols that have any kind of feedback from destination
> >> to source (i.e. start small and increase the packet size until
> >> the far end detects fragmentation or loss). 4821 does discuss this
> >> briefly.
> >
> > RFC4821 also discusses the use of IP fragmentation as a
> > packetization layer in Section 10.3.
>
> Yes, but that struck me as ugly.
Well, for a tunnel configured over all-1500 links, the
principle of least surprise would seem to say that the tunnel
should try to accommodate all packets 1500 bytes or smaller
(i.e., using IP fragmentation) rather than drop and send back
a PTB with MTU=(1500-ENCAPS). But, maybe we should just draw
the line at 1500 bytes or smaller, and let bigger packets take
care of themselves?
> >> One could also think about a generic non-ICMP UDP echo process
> >> for PLPMTUD, although that does raise DoS and firewall issues.
> >
> > AFAICT, a simple mitigation for the DoS issue exists. Also
> > AFAICT, the firewall issue should not come into play if the
> > echos are made to look like ordinary tunneled data. Please
> > let me know if I am missing something.
>
> The UDP port concerned has to be open in the firewall, since the
> echo process is playing the role of a server. That's probably
> less awkward than getting ICCMP through, but it still means
> convincing the corporate or campus security people to allow
> the port. I'm sure they'd like to know how the DoS threat is
> mitigated...
But, it would be the same UDP port opened for the tunnel itself,
i.e., the probing is in-band with ordinary tunneled data. Or,
maybe I'm still missing the point...
Thanks - Fred
fred.l.templin@boeing.com
> Brian
>
> >
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> >> Regards
> >> Brian Carpenter
> >> University of Auckland
> >>
> >>
> >> On 2007-09-21 09:50, Templin, Fred L wrote:
> >>> (Fwd'd from 'int-area'):
> >>> Please see below for a proposal that addresses the MTU issues
> >>> for *-in-IPv4 tunnels. It also addresses the multi-mtu subnet
> >>> issue, since it does not rely on ICMP "packet too big" messages
> >>> from the last-hop router. Elements of the proposal include:
> >>>
> >>> - trailing "footer" and data as part of encapsulation
> >>> - tiny echo requests wrapped in encapsulation headers
> >>> and trailing padding - used as probes to elicit tiny
> >>> echo replies
> >>> - tunnel endpoint discovers tunnel far end EMTU_R and
> >>> reassemby timeout values in initial probes=20
> >>> - periodic probing to discover the tunnel path MTU,
> >>> plus EMTU_R; reassembly timeout fluctuations
> >>> - inner fragmentation to create inner packets no larger
> >>> than EMTU_R
> >>> - outer fragmentation to create outer packets no larger
> >>> than the tunnel path MTU
> >>> - coservative use of fragmentation to avoid packet loss
> >>> within the tunnel
> >>> - TE drops unfragmentable packets larger than EMTU_R
> >>> and sends ICMP PTB w/o wasting tunnel resources
> >>> - protection against fragment misassociations
> >>> - protection against off-path attacks
> >>> - protection against wrapped ip_id
> >>> - backwards compatibility
> >>> - incremental deployment
> >>> - NAT traversal
> >>>
> >>> Please review and send comments.
> >>>
> >>> Thanks - Fred
> >>> fred.l.templin@boeing.com
> >>>
> >>> ------_=_NextPart_002_01C7FA2B.91342580
> >>> Content-Type: text/plain;
> >>> charset="iso-8859-1"
> >>> Content-Transfer-Encoding: quoted-printable
> >>>
> >>> A New Internet-Draft is available from the on-line
> >> Internet-Drafts=20
> >>> directories.
> >>>
> >>>
> >>> Title : Packetization Layer Path MTU Discovery for=20
> >>> IP/*/IPv4 Tunnels
> >>> Author(s) : F. Templin
> >>> Filename : draft-templin-inetmtu-00.txt
> >>> Pages : 20
> >>> Date : 2007-9-18
> >>>
> >>> The nominal Maximum Transmission Unit (MTU) MTU of the
> >> Internet has
> >>> become 1500 bytes, but existing IP/*/IPv4 tunneling
> >> mechanisms impose
> >>> an encapsulation overhead that can reduce the effective
> >> path MTU to
> >>> smaller values. Additionally, existing IP/*/IPv4 tunneling
> >>> mechanisms are limited in their ability to discover and utilize
> >>> larger MTUs. This document specifies new mechanisms for
> >> conveying
> >>> packets over IP/*/IPv4 tunnels that address these issues.
> >>>
> >>> A URL for this Internet-Draft is:
> >>> http://www.ietf.org/internet-drafts/draft-templin-inetmtu-00.txt
> >>>
> >>> --
> >>> 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