Subject: Re: (ngtrans) Re: 6to4/isatap MTU

From: Robert Elz <[email-masked]>
Date: Mon, 02 Sep 2002 15:21:41 +0700

Date:        Fri, 30 Aug 2002 11:56:34 -0700
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220800b9956e37ba3a@[10.34.255.54]>

  | I just dropped into the middle of this thread, so am missing much of
  | the context, but 1500 (excluding IP4 tunnel overhead) would seem the
  | natural number to use for the above, given that all IPv6 nodes are
  | already required to be able to handle packets of that size, but not
  | necessarily any larger.  (1500 is IPv6's minimum reassembly buffer
  | size; see top of page 25 in RFC 2460.)

It is certainly a possible choice.   However, IPv6's reassembly buffer
isn't really relevant for this, it is IPv4 reassembly that is being
done (or might be being done), and the guaranteed reassembly buffer for
IPv4 is just 576 bytes - which is clearly not big enough to be the IPv6 MTU.

What this means, is that to be the end-point of (any kind of) IPv6 over
IPv4 tunnel, the node can't be a minimum IPv4 implementation, it needs
to be able to handle larger packets than the minimum required for IPv4.

The only question then, is just how much more.   1500 would seem to
actually be a poor choice - it has almost no advantage over (say 1480)
but is going to guarantee IPv4 fragmentation over almost any path that
exists in the Internet today.   But for that cost it gains almost nothing,
if you're going to pay for fragments anyway (in terms of higher overall
loss that would otherwise exist, which is the biggest cost) you may as
well get some kind of benefit, and allow the packets to be more like twice
the typical IPv4 PMTU - or even 3 times or more.

1280 is clearly the smallest we can do, and is quite possibly (currently
anyway, that is, with the MTUs we see on current links) the best to use.
Whether that will always be so, I don't know - 10 (or maybe 15) years ago,
a path with an MTU of 1500 would most likely have meant that the whole thing
was run over local LANs.   That isn't true any more.   As connection speeds
increase, the MTU tends to increase as well (though at a slower rate), to
help eliminate some of the overheads.   I'm no link level expert, but I
believe that GB eth (can) allow larger than 1500 MTU for example.

To me, that suggests that while the sender might (very sensibly) decide
to limit the MTU of one of these tunnels to something that should avoid
fragmentation (or at least much of it), receivers should set their MRU
rather higher, so they don't simply discard packets from senders that
know they can safely use a larger MTU (perhaps using the results of IPv4
PMTUD, and perhaps just from knowledge about the state of the internet
and its common MTUs changing over time).

Christian's message about loss probabilities explains why senders should be
conservative, even though he made a typo and because of that underestimated
the worst case he presented, but he said nothing at all about what receivers
should be prepared to receive, which isn't the same question at all.

I still believe that specifying a minimum MRU of 4554 would be a good choice.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 02 Sep 2002 16:36:25 +0700

Date:        Mon, 02 Sep 2002 15:21:41 +0700
    From:        Robert Elz <[email-masked]>
    Message-ID:  <[email-masked]>

  | I still believe that specifying a minimum MRU of 4554 would be a good choice

To reply to my own mail...

Actually, for completely non-technical reasons, 4664 just might be nicer
to pick.   I don't see it doing any harm, and it has that nice memorable
"6 in 4" quality to it...

kre

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 02 Sep 2002 20:22:26 +0900

>"6 in 4" quality to it...

	i do see it doing harm, as it imposes more requirement to IPv4
	implementation underneath.  think embedded devices.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Sep 2002 14:29:14 +0300 (EEST)

> 	implementation underneath.  think embedded devices.

It could be argued why an embedded device needs to do any tunneling at 
all.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: [email-masked]
Date: Mon, 02 Sep 2002 20:33:59 +0900

>It could be argued why an embedded device needs to do any tunneling at 

	small routers at home are qualified to be called as an embedded
	devices, IMHO.

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 02 Sep 2002 18:38:32 +0700

Date:        Mon, 02 Sep 2002 20:22:26 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	i do see it doing harm, as it imposes more requirement to IPv4
  | 	implementation underneath.

That's true.   But remember we're mostly concerned with 6to4 tunnel
endpoints here (ISATAP perhaps as well, but I'm afraid I haven't read
enough about that to know if this is appropriate there or not).

So... (as Pekka just said)

  | think embedded devices.

do you really need to put your 6to4 tunnel endpoints on embedded devices?
Or more particularly, on ones unable to receive and reassemble a 4664 byte
datagram?   The "receive and reassemble" part is required already, just
to handle the 1280 that is required of IPv6, the only issue left is the
buffer size.   Running IPv6 in nodes with tiny buffers should be possible,
but I don't think we need to make those things into 6to4 routers, do we?

Configured tunnels, aren't a problem, as your initial e-mail pointing
out the issue said - there the two ends can agree on anything that they
like.   It's just the automatic ones that need to be able to rely upon
something.

kre

---

From: [email-masked]
Date: Mon, 02 Sep 2002 20:56:07 +0900

>but I don't think we need to make those things into 6to4 routers, do we?

	small routers are surely embedded devices - they have severe cost
	requirements, hence they have limited amount of memory/CPU to spare.

	and it is not only routers which decapsulate 6to4-encapsulated packet,
	it can be a node itself.  therefore i think it is not unreasonable for
	embedded device to terminate 6to4 tunnel for itself.

>like.   It's just the automatic ones that need to be able to rely upon

	IMHO, 2893bis should define default MTU/MRU as well as minimum
	required MRU for configured tunnel.  otherwise implementations
	pick up random value, causing unnecessary operational troubles.

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 02 Sep 2002 20:13:12 +0700

Date:        Mon, 02 Sep 2002 20:56:07 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	small routers are surely embedded devices - they have severe cost
  | 	requirements, hence they have limited amount of memory/CPU to spare.

I really don't think that routers that can't handle a few KB's of
buffering need to be considered for this.

  | 	and it is not only routers which decapsulate 6to4-encapsulated packet,
  | 	it can be a node itself.  therefore i think it is not unreasonable for
  | 	embedded device to terminate 6to4 tunnel for itself.

No, but for them this isn't really an issue.   If the node can't handle
(including reassembling, if it is using 6to4) a 4-5 KB packet, then it
can't - and anyone who wants to send it one is going to lose, regardless
of whether or not the packet is too big for its 6to4 to handle, or if it
is just too big for the node to handle regardless of the tunnel.
The packet can't be received in either case, and is simply lost.

If the sender sends a smaller packet (taking note of Steve's point that
nodes are only required to be able to receive and reassemble packets up
to 1500 bytes for IPv6) and that one can be received, then all will be OK,
whether or not the node is technically violating some required reassembly
MRU requirement (that is, if the node is the recipient of the packet,
and not a router, then clearly the MRU doesn't need to be any bigger than
its maximum receivable (after reassembly) IPv6 packet size).

  | 	IMHO, 2893bis should define default MTU/MRU as well as minimum
  | 	required MRU for configured tunnel.  otherwise implementations
  | 	pick up random value, causing unnecessary operational troubles.

I agree with you about the minimum MRU - what this discussion today has
been about is what value it should be.

On the other hand, it makes no sense to have a default MRU that is any
different than the minimum (in the spec I mean, nodes can have a bigger
one if they want to).   No-one can assume that an unknown foreign node
has implemented anything bigger than the required minimum, so the default
serves no purpose.  If actual knowledge is obtained as to what the MRU
on some other node is, then that's known data, and again, no default is
relevant.

A default MTU might make some sense if we have any good way of deciding
what it should be.   Most of the earlier discussions centered around
this point, with all those discussions that really turned upon what kind
of PMTU information was available to the runnel driver, and so on.
And there looked to be no outcome ever likely to result from that.

I don't think it is actually needed - implementations should be free to
do their own thing here, based upon what information is actually available.
As long as the MTU isn't selected (without some explicit information about
the target) higher than the minimum required MRU, it really shouldn't
matter (for correctness - for efficiency it might).

Suggesting a value that nodes might decide to use if they have absolutely
no information about the path might be a good idea,  so might listing some
of the issues that might influence the choice made by an implementation,
but I don't know that I'd want to go any further than that.

kre

---

From: Steve Deering <[email-masked]>
Date: Wed, 4 Sep 2002 04:23:24 -0700

At 3:21 PM +0700 9/2/02, Robert Elz wrote:
>  | natural number to use for the above,...
>
>...

Sure, but I doubt there are many (any?) IPv4 implementations that can't
handle the Ethernet MTU/MRU of 1500.

>exists in the Internet today.

Oops, yes, allowing room for an IPv4 header or two within the 1500 would
make sense.

>the typical IPv4 PMTU - or even 3 times or more.

Fragmentation in IPv4 is just as undesirable as fragmentation in IPv6.

>anyway, that is, with the MTUs we see on current links) the best to use.

1280 is the smallest, but certainly not the best choice, because we expect
there to be lots of IPv6-in-IPv6 encapsulation happening, possibly
crossing those IPv4 "links", requiring a fudge factor over the 1280
minimum. This is the reason we recommend that point-to-point links
be configured with an MTU that is at least a few hundred bytes greater
than 1280, and the same reasoning ought to apply to an IPv4 "link".

Steve

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Sep 2002 19:16:28 +0700

Date:        Wed, 4 Sep 2002 04:23:24 -0700
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220801b99b93a394b6@[192.168.0.51]>

  | Fragmentation in IPv4 is just as undesirable as fragmentation in IPv6.

Yes, but if there's an MTU < 1280 in the IPv4 path, there's nothing that
can be done to avoid it (for IPv6 in IPv4 tunnels).

  | 1280 is the smallest, but certainly not the best choice,

You won't find me disagreeing with that...   I'd like the required MRU
set much higher (4664 sounds like a good number to me).   If nodes sending
into tunnels don't want to send that much, but prefer to send back a "too big"
instead (to avoid fragmentation, or for any other reason), that's just fine.

But if a node sending into a tunnel decides that it can get away with sending
2K packets (perhaps because it knows the IPv4 PMTU) then I don't want the
receiver discarding them as being "too big to handle".

kre