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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Sep 2002 10:42:49 +0200

Tony Hain wrote:
> 
> kre wrote:
> > Actually, no it isn't, and this is the point.   Packets
> > exceeding the MRU
> > generally just get dropped (unless something implements the
> > idea that Christian suggested, which currently, I know of
> > nothing that does). No ICMP gets sent back.
> >
> > That is, PMTUD doesn't find this problem, what happens is a
> > black hole.
> 
> An apparently false assumption on my part was that implementations had a
> black-hole detector tied to their PMTU discovery process. At least for
> TCP the stack should know that the small packets through SYN-ACK worked,
> so if large ones are failing, it would seem logical to shrink them
> before trying again, then try to grow them over time.
> 
> Short of that, I agree it makes the most sense to require a 6to4
> receiver to send an IPv6 MTU exceeded message when reassembly fails due
> to size. It will have the necessary information, and as a router its job
> is to inform the upstream node when a link capacity is being exceded.
> The unusual aspect of this case is that the link is a logical one inside
> the router between IPv4 and IPv6, and the failure notice is coming from
> the inbound IPv6 interface rather than an outbound one. The more I think
> about it, this would be a reasonable requirement for all inbound IPv6
> interfaces, because we may end up with the same kinds of MTU/MRU
> mismatch issues we found with FDDI-Ethernet bridges as we move into gigE
> ...

Exactly. There is nothing special about a 6to4 interface in this respect.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Sep 2002 09:10:34 +0200

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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Robert Elz
> > Sent: Thursday, September 12, 2002 12:08 AM
> > To: Fred L. Templin
> > Cc: [email-masked]
> > 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" <[email-masked]>
> >     Message-ID:  <[email-masked]>
> >
> >   | 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
> >