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

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 11 Sep 2002 09:35:49 -0700

Robert,

I pretty much understand and agree with everything you're saying here.
One point for further discussion, however:

>   | 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.
> 
> That's basically Christian's idea, and is fine - but requires that
> the 6to4 implementation can get inside the IPv4 fragmentation code,
> which isn't always going to be possible.

I'm not sure that this won't always be possible, and it doesn't
seem to me that implementations will always need to instrument the
IPv4 reassembly code. 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
allowing smart decisions to be made about when the corresponding
IPv4 packets are too big. Can you think of instances where this
would not work? (Even if there are such instances, instrumenting
the IPv4 reassmbly code is still an option.)

Fred
[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 12 Sep 2002 14:08:12 +0700

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

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 12 Sep 2002 11:23:31 -0700

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 13 Sep 2002 01:53:14 +0700

Date:        Thu, 12 Sep 2002 11:23:31 -0700
    From:        "Tony Hain" <[email-masked]>
    Message-ID:  <01ae01c25a89$7f65c2b0$011aa8c0@eagleswings>

  | Am I detecting convergence???

Your formulation isn't the way I'd write it (or rather, I'd make
the 1480 bigger...)    The "SHOULD" part is really just common sense,
but it probably doesn't hurt to say it.    But whether the
implementation does that or not is largely irrelevant, as soon as
you require no more than 1480, that becomes the maximum MTU that
any sender can ever use (without specific configuration).

But if everyone else is happy with forever condemning 6to4 to never
be able to use bigger packets (in any non-configured circumstances)
then it is clearly pointless me trying to get it to be bigger.

kre

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 12 Sep 2002 12:22:22 -0700

kre wrote:
> implementation does that or not is largely irrelevant, as 
> soon as you require no more than 1480, that becomes the 
> maximum MTU that any sender can ever use (without specific 
> configuration).
> 
> But if everyone else is happy with forever condemning 6to4 to 
> never be able to use bigger packets (in any non-configured 
> circumstances) then it is clearly pointless me trying to get 
> it to be bigger.

I agree bigger would be better, and hopefully all but the most
constrained nodes will implement the MTU exceeded message. The only way
this would condem 6to4 to small packets would be if all the nat/routers
refused to implement the message, and the OS vendors refused to tie a
black-hole detector to their PMTU discovery engine. Granted both of
those are quite possible.

In some ways this would not be a bad thing since it would provide
motivation to move onto a native IPv6 service for those that want high
performance. I am not arguing that we should intentionally hamper 6to4,
so much as pointing out that there is an alternative available.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 12 Sep 2002 15:38:30 -0400

>...and the OS vendors refused to tie a
>black-hole detector to their PMTU discovery engine.

Is the concept of a "black-hole detector" for PMTU documented
somewhere?

Thanks,
Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 16 Sep 2002 16:39:57 +0200 (CEST)

> Is the concept of a "black-hole detector" for PMTU documented

RFC 2923

  Erik