Re: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - need WG consensus]

[Brian E Carpenter <brian@hursley.ibm.com>]

Having read the subsequent discussion, I'm of the view that this (and
not a larger MRU) is the appropriate thing to specify.

I suspect we are begining to need a 6to4 operational BCP, where this
could fit. But we'd need someone with cycles to work on it.

And I've switched this to v6ops.

   Brian

Tony Hain wrote:
> 
> Am I detecting convergence???
> 
> All 6to4 implementations SHOULD send IPv6 PMTU exceeded messages
> whenever the wrapping IPv4 packet is discarded due to excessive size. In
> addition, all 6to4 implementations MUST configure a 6to4 MRU of at least
> 1480, but SHOULD have an MRU at least as large as the IPv4 physical
> interface MTU.
> 
> If that text is acceptable, which document does it belong in? Logically
> it would belong in a rev to 3056, but if we open that document is this
> the only pending change? I assume we want to get this out in RFC form
> quickly, so I wouldn't want it to get stuck because it was part of a
> lengthy document.
> 
> Tony
> 
> > -----Original Message-----
> > From: owner-ngtrans@sunroof.eng.sun.com
> > [mailto:owner-ngtrans@sunroof.eng.sun.com] On Behalf Of Robert Elz
> > Sent: Thursday, September 12, 2002 12:08 AM
> > To: Fred L. Templin
> > Cc: ngtrans@sunroof.eng.sun.com
> > Subject: Re: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU -
> > need WG consensus]
> >
> >
> >     Date:        Wed, 11 Sep 2002 09:35:49 -0700
> >     From:        "Fred L. Templin" <ftemplin@iprg.nokia.com>
> >     Message-ID:  <3D7F70E5.2080604@iprg.nokia.com>
> >
> >   | Don't most modern systems support a socket
> >   | abstraction similar to the Berkeley Packet Filter (bpf)? If so,
> >   | an application can write a simple filter to receive IPv4
> > fragments [...]
> >
> > Yes, other than for embedded systems, where nothing new is
> > ever going get added (but where a 6to4 implementation could
> > probably get slotted into the frag code with no issues),
> > you're probably right.
> >
> > If everyone could implement Christian's idea, that's great.
> > My point was
> > more that we don't have to prove that they can, as long as we
> > don't set the required MTU too high.
> >
> > And that's OK, we don't need the 64K that was suggested (by
> > you?) - packets to be transmitted by 6to4 can't be bigger
> > than the PMTU anyway (or at least the PMTU up to the 6to4
> > box), and that's truly unlikely to get huge anytime soon (and
> > even if it did, because the 6to4 box is very close to the
> > source, the packets would only get blocked soon after
> > emerging). I certainly don't think we should be promoting
> > 6to4 as an end to end protocol that sources can use to
> > transmit directly to recipients, just so they can get an IPv6
> > MTU that's huge, that they wouldn't be able to use on any
> > real links they have available.
> >
> > All we need is an MRU big enough to cope with paths that
> > might reasonably
> > be achieved in the reasonable lifetime of the IPv4 net.   In
> > the past 15
> > years, the achievable MTU over typical paths has about
> > tripled (not in small
> > increments of course, but in big jumps).   So, assuming that over the
> > next 15 years it might triple again seems reasonable to me
> > (if we're off by a bit, who cares - if it doesn't get that
> > big, the harm is almost irrelevant, if it gets bigger then we
> > won't be able to use all that is available, but at least we
> > shouldn't still be sending tinygrams, which 1280 would be).
> >
> > So, I think 4664 is big enough, while also being small enough
> > that we don't have to care whether or not there's some
> > implementation that can't implement Christian's idea (or
> > can't do it reasonably) and for which the specified MRU is
> > too big to handle.
> >
> > kre
> >