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

From: "Christian Huitema" <[email-masked]>
Date: Mon, 2 Sep 2002 11:35:57 -0700

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

The current crop of small routers (the $100 variation) is severely
constrained in terms of memory & CPU. It is also a prime target for 6to4
-- think of upgrading your Nat to a 6to4 router function, and providing
IPv6 connectivity to your home network.

I believe the solution is to involve the 6to4 receiver (the receiving
end of the 6to4 tunnel) in PMTU discovery. It would require a special
handling of IPv4 fragmentation errors, but would solve a large part of
the problem, as follow:

* The receiving 6to4 router reassembles the first segments of an
incoming packet, until it has received at least 40 bytes of payload.

* For packets of protocol type 41, after receiving at least 40 bytes of
payload, the router examines the IPv6 payload length parameter in the
payload.

* If the payload length is larger than the locally configure MTU, the
receiving router formats an IPv6 ICMP "MTU exceeded" packet and sends it
back to its IPv4 origin.

An alternative implementation is to perform this test upon a
fragmentation error, but this is problematic as fragmentation errors are
sometime decided by a timeout.

By the way, if we must pick a value, I vote for 1280.

-- Christian Huitema

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 2 Sep 2002 13:44:40 -0500

----- Original Message ----- 
From: "Christian Huitema" <[email-masked]>
> IPv6 connectivity to your home network.

NG does not imply IPv6....NAT is an integral part of the transition strategy...

Top 10...IPv8 Compatible Dynamic DNS Services
Vote Early and Often...
http://www.kvtek.com/ddnsservices.asp

1. DynDNS
2. No-IP
3. HN
4. ZoneEdit
5. ChangeIP
6. Yi
7. DHS
8. DtDNS
9. DyNS
10. DNS2GO

Other links...

      DynDNS www.dyndns.org 
      Yi www.yi.org 
      DtDNS www.dtdns.com 
      HammerNode www.hn.org 
      EyeP www.eyep.net 
      DynU www.dynu.com 
      easyDNS www.easydns.com 
      No-IP www.no-ip.com 
      dyns.cx www.dyns.cx 
      dnsQ.org www.dnsq.org 
      myIP.org www.myip.org 
      ns1.net www.ns1.net 
      ZoneEdit www.zoneedit.com 
      dyn.ee www.dyn.ee 
      www.centralinfo.net 
      NOLS www.nols.com 
      dhs.org www.dhs.org 
      YYweb.com www.yyweb.com 
      dyn.ca www.dyn.ca 
      DDNS.nu www.ddns.nu 
      miniDNS www.minidns.net 
      DynDNS.dk www.dyndns.dk 
      changeIP www.changeip.com 
      dnsArt www.dnsart.com 
      DSL Reports www.dslreports.com 
      GetmyIP.com www.getmyip.com 
      Domain monger www.domainmonger.com 
      WaffullTechSystems www.waffulltechsystems.com 
      DNSMadeEasy www.dnsmadeeasy.com 
      Gradwell.com www.gradwell.com 
      DNSD.be www.dnsd.be
      ODS.org www.ods.org 
      ULimit.com  www.ulimit.com 
      orgDns.org www.orgdns.org 
      DNIP.net www.DNIP.net 
      CJB.net www.cjb.net 

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Sep 2002 15:09:13 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Christian" == Christian Huitema <[email-masked]> writes:
    Christian> The current crop of small routers (the $100 variation) is
    Christian> severely constrained in terms of memory & CPU. It is also a
    Christian> prime target for 6to4 -- think of upgrading your Nat to a 6to4
    Christian> router function, and providing IPv6 connectivity to your home
    Christian> network.

    Christian> I believe the solution is to involve the 6to4 receiver (the
    Christian> receiving end of the 6to4 tunnel) in PMTU discovery. It would
    Christian> require a special handling of IPv4 fragmentation errors, but
    Christian> would solve a large part of the problem, as follow:

    Christian> * The receiving 6to4 router reassembles the first segments of
    Christian> an incoming packet, until it has received at least 40 bytes of
    Christian> payload.

    Christian> * For packets of protocol type 41, after receiving at least 40
    Christian> bytes of payload, the router examines the IPv6 payload length
    Christian> parameter in the payload.

  Before anyone complains that this is a horrible layering violation, please
be aware that to avoid fragmentation DoS attacks against IKEv2, similar 
such things may be desireable for UDP port 500. 
  So, I am generally in favour of such things.

  I proposed a similar thing for discovering the PMTU for IPsec tunnels.
I simply required that the size of the largest fragment received be recorded,
not worrying that we might never assemble an entire datagram.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: [email-masked]
Date: Tue, 03 Sep 2002 07:00:08 +0900

>receiving router formats an IPv6 ICMP "MTU exceeded" packet and sends it

	"locally configure MTU" for which interface?  if it is for 6to4
	interfacde, shouldn't it be MRU instead of MTU? (then it becomes a
	bit hairy to send ICMPv6 too big for MRU exceeded...)

>By the way, if we must pick a value, I vote for 1280.

	i prefer to pick a value, 1280.

itojun

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 2 Sep 2002 17:17:15 -0500

----- Original Message ----- 
From: <[email-masked]>
> i prefer to pick a value, 1280.

2002 is a really good value...next year, 2003 may be better...

There is also the 2911 and 3911  approach...YMDD....

Setting the MTU via the 128-bit DNS may catch on if the bits are not all used...
...in theory, one could take the 128 bits and blindly drop them into the 160-bit IPv4 header...
...it is handy to have 16 of the bits to set the UDP|TCP Port # which is not in that header...
...that only leaves 112 bits left...maybe the popular MTU sizes could be selected from a table of values...

Jim Fleming
http://ipv8.dyns.cx
http://ipv8.no-ip.com

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Sep 2002 08:54:58 +0200

>         i prefer to pick a value, 1280.

To be clear, are these votes for minimum MRU?

   Brian

---

From: Robert Elz <[email-masked]>
Date: Tue, 03 Sep 2002 16:41:49 +0700

Date:        Tue, 03 Sep 2002 07:00:08 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	"locally configure MTU" for which interface?  if it is for 6to4
  | 	interfacde, shouldn't it be MRU instead of MTU? (then it becomes a
  | 	bit hairy to send ICMPv6 too big for MRU exceeded...)

Actually, if we were to do it this way, it doesn't matter.   It looks
ugly, but the returning ICMP doesn't say which interface, just "to
send this packet along its path, you must reduce the size to less than N".

The router can pretend it has an interface, that it just happened to be
going to use to transmit the packet, which just happens to have an MTU
equal to the MRU it desires on incoming packets, if you want to want to
keep up the fiction (that interface might be some internal loopback
through which it sends all packets before transmitting them...)

Or, since it has the header of the packet in Christian's scheme, and
thus knows how big it will be, and more importantly, the dest addr
(and hence, which path the packet would use), it can use the MTU of the
interface it would be going to send the packet on, had it been small
enough to receive (unless that is larger than the MRU it is prepared
to handle on the tunnel, but that would be a bit of a dumb implementation).

If this scheme looks OK, I have no problem with it.

But if we want to set a fixed number, I'd still prefer a bigger one.

Even baby embedded processors (the $5 variety) have 32KB or more of
ram in them mostly these days.   For this, that's enough (in the
immediate future, the presence of ethernet on just about every path
is going to limit the packet size to 1500 (probably 1480) anyway).
That is, even if a larger packet is received, this baby box is just
going to send a "too big" back, because its outgoing link is
almost certainly ethernet.   Given that, it doesn't actually have to
reassemble any more than the first 1500 bytes in any circumstances,
because it isn't going to be able to transmit them, or do anything
else with them either.   Anything past that it can simply discard,
all the while keeping up the pretense (undetectably to the outside
world) that it really would be prepared to forward larger packets,
if only the MTU of the outgoing link allowed it...

So, I don't really think the baby cheap router argument really matters,
even if these things really can't handle the buffering that might seem
to be required.

kre

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 03 Sep 2002 10:00:45 -0700

Since the "link layer" in question here is IPv4, isn't it true that the
maximum-sized packet for that link layer is 64KB? (I believe somewhere in
RFC 791 the IPv4 length field is defined as 16bits). We can place artificial
restrictions on the MTU for a specific IPv6-over-IPv4 tunnel driver, but we
cannot excuse the fact that a receiver must be prepared to deal with IPv4
packets up to 64KB.

By "deal with", I mean that even if the receiver is memory-constrained, it MUST
be prepared to cache enough information in IPv4 reassembly to discard fragments
of a packet so large that it wouldn't fit into a host's receive buffer. Even if
a particular receiver will drop *all* packets over N bytes in length (N < 64KB),
it implements the standard IFF it is prepared to deal with packets up to 64KB.
So, why should it not be the case the MRU = 64KB for IPv4?

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 03 Sep 2002 14:23:51 -0700

> sometime decided by a timeout.

Christian's proposal above gives a nice proposal for a set of decapsulator
actions. There are also some details to discuss regarding the encapsulator:

General encapsulator actions:
*****************************
1) The encapsulator stores PMTU estimates for each *active* destination
in the destination cache. (The cache contains soft-state, and presumably
uses some sort of LRU replacement rule to place upper bound on cache size.)
The original PMTU estimate for a new destination is MIN of the MTU of the
physical interface for the destination (as told via IPv4 routing lookup)
and the artificial MTU limit placed on the specific IPv6-over-IPv4 driver.

2) The encapsulator sends *all* packets WITHOUT SETTING the IP_DF bit
in the IPv4 header; the decapsulator performs the actions described
by Christian above.

3) As an optimization, since the MTU of the IPv4 path may vary due to
IPv4 routing fluctuations, the encapsulator SHOULD periodically probe
the path in the following way:

   a) Periodically, capture an IPv6 packet flowing toward a particular
      destination and artificially inflate it in order to test the
      PMTU. To do this:

      - NULL pad the IPv6 packet to a size determined by the periodic
        polling scheme
      - Adjust the IPv4 length field to reflect the padded packet
        length, but leave the IPv6 length field at its original value
      - send the packet

   b) Add an extension to the decapsulator to notice packets in which
      the IPv4 length has been so padded:

      - If the packet arrives without incurring fragmentation, send some
        sort of indication of the successful probe by reverse-tunneling
        back to the encapsulator to indicate "probe succeeded". (This needs
        to be specified.) The IPv6 packet is "clipped out" of the probe packet
        and forwarded to the final destination with no "pkt too big's" generated.
      - If the packet arrives with fragmentation, send IPv6 "pkt too big"
        as per Christian's proposal

   c) When the encapsulator receives "probe succeeded", it adjusts the
      PMTU estimate upward to the length indicated. The "probe succeeded"
      MUST come back through the tunnel; not general IPv6 routing since routing
      may be asymmetric. Thus the need for the encapsulator's action of
      reverse-tunneling.

With a reasonable probing strategy, this will often result in the
inflated probes reaching the decapsulator without fragmentation, thus
reducing unnecessary packet loss and packet too big indications.

Actions when encapsulator is an IPv6 router:
********************************************
When the encapsulator is an IPv6 router, actions are as above except
that the router and the originating source MUST BOTH process the same
ICMPv6 "Pkt too big". One way to do this it to have the encapsulating
router intercept the ICMPv6 "Pkt too bigs" travelling along the reverse
path toward the sender and make the PMTU estimate adjustment locally
before forwarding the packet back to the sender.

But, the intercepted ICMPv6's will be commenting on the packet sent by
the *originating source*, which is NOT the router. This may make some folks
nervous, so the router could alternatively perform IPv6-in-IPv6-in-IPv4
encapsulation. This will force the decapsulator to send ICMPv6 "packet
too big" directly to the *router* instead of to the original source.
The router will thus receive and process the packet too big without
having to do any risky "snooping" and more safely re-adjust the PMTU
estimate to the destination. The router then creates a brand-new ICMPv6
"packet too big" based on info in the innermost IPv6 packet and sends
it back to the original source.

Questions:
**********
Does anyone see any problems with the scheme proposed by Christian and
my messages? Does anyone know of any similar proposals that have appeared
elsewhere? Other comments?

Fred Templin
[email-masked]

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 04 Sep 2002 08:53:14 +0900

>actions. There are also some details to discuss regarding the encapsulator:

	i don't think it a good strategy for encapsulator/decapsulator to
	keep state (incl. PMTU info) on their peers.  here's much more
	simple one:

	IPv6 tunnel link MTU: 1280
	IPv6 tunnel link MRU: 1480 (minimum required supported value)
	for configured tunnels, peers can pre-negotiate for larger (constant)
	value.

	encapsulator action
	- encapsulate into IPv4 packet, ip_p = 41, DF bit = 0.

	decapsulator action
	- receive IPv4 fragments, reassemble (if there are fragments),
	  remove IPv4 header, and send the packet up to IPv6 layer.
	- decapsulator must be able to reassembe IPv4 packet up to minimum
	  IPv6 tunnel MRU (1480) + 20.

	this do impose IPv4 stack additional requirement to be able to
	reassemble up to 1500 bytes (rather than 576 bytes).

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 03 Sep 2002 17:13:00 -0700

Fred L. Templin wrote:
>        and forwarded to the final destination with no "pkt too big's"
 >        needed.

I'm sorry, but the above needs to be revised ever so slightly:

        - If the packet arrives without incurring fragmentation, OR if
          the packet is fragmented and the IPv6 packet is properly
          contained in the first fragment, send some sort of indication
          of the successful probe...

>        as per Christian's proposal

Similarly, the above is better re-worded as:

        - If the IPv6 packet is not properly contained in the first fragment
          of an IPv4 packet, send IPv6 "pkt too big"...

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 03 Sep 2002 17:23:49 -0700

> 	keep state (incl. PMTU info) on their peers.  here's much more

Disagree - there is no more state involved than for standard IPv6 neighbor
discovery, i.e., the IPv6 destination cache is used. This is soft state that
does not suffer from catastrophic loss due to failure and can be bounded to
an amount that is acceptable for the encapsulator's H/W architecture. No
IPv4 PMTU state is needed at all, as per your "fundamental design
requirements" from 8/18/2002.

> 	for configured tunnels, peers can pre-negotiate for larger (constant)

Why would you place such an artificial limit on automatic tunnel interfaces
that may benefit from larger values? (See my comments on the state issue above...)

Fred
[email-masked]

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 04 Sep 2002 09:19:17 +0900

>requirements" from 8/18/2002.

	you do require two things:
	- isatap/6to4 interface be treated differently from other interfaces
	  by IPv6 stack.
	- intermediate router (encapsulator/decapsulatro) to maintain IPv6 MTU
	  information for traffic of others.  normal IPv6 node maintain
	  IPv6 MTU information for its own traffic only.

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 03 Sep 2002 17:43:16 -0700

> 	- isatap/6to4 interface be treated differently from other interfaces

This would be a nice (and simple!) optimization, but it is not required.
An alternative is to have the isatap/6to4 interface pick the maximum MTU
of all physical devices attached to the system as the (static) ifp->if_mtu
value for the interface. (This information is available to the driver in
system configuration data structures; there is no need to consult IPv4
routing at all.) Result is locally-generated ICMPv6 packet too bigs, but
the application will adapt.

> 	  IPv6 MTU information for its own traffic only.

If the intermediate router is doing IPv6-IPv6-IPv4 encapsulation, it is
essentially maintaining information for it's *own* traffic. (Routers are
allowed to source traffic themselves, so it is not at all unusual for
them to have state for their own traffic.)

Fred
[email-masked]

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 04 Sep 2002 09:43:37 +0900

>them to have state for their own traffic.)

	the encapsulator is doing IPv6-in-IPv4 encapsulation.  therefore, it is
	probably reasonable to ask the encapsulating node to perform IPv4 PMTUD
	(which is not happy solution for me), but it is unreasonable to ask
	the node to do IPv6 PMTUD.

itojun

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Sep 2002 17:48:13 +0700

Date:        Wed, 04 Sep 2002 09:43:37 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	the encapsulator is doing IPv6-in-IPv4 encapsulation.  therefore, it is
  | 	probably reasonable to ask the encapsulating node to perform IPv4 PMTUD
  | 	(which is not happy solution for me),

It would be perhaps, but I don't think it is needed.   It can't be used
if the result would be < 1280 (or rather, it gains almost nothing in that
case), so the only advantage would be to know when larger packets need
to be fragmented, and when they don't, which in practical terms isn't almost
ever going to matter, as I'm not sure I have ever seen a link with an
MTU between 1280 and 1500, and once we reach 1500, we're pretty certain
that we are going to need to fragment, today anyway).

So, unless PMTU information just happened to be available, I don't think
I'd be bothering to use it (ie: just send with DF==0 as your algorithm
suggested).

  |     but it is unreasonable to ask the node to do IPv6 PMTUD.

Yes, but I don't think anyone is requesting that.   The source node
needs to be doing it however (in all cases, unless it sends packets
no greater than 1280 bytes, for those packets this whole discussion
is irrelevant).

A couple of other points though ... there is nothing in IPv6 or IPv4
that assumes that an interface has a constant MTU (or there shouldn't
be).   I know that some implementations assume that.   It is entirely
reasonable to have a link level interface where the MTU is a per destination
quantity (a link level that creates circuits is quite likely to have a
property like that).

So, having a varying MTU for the 6to4 interface isn't altering anything
in the spec, nor in the design (PMTU's are a per destination number).

Also note that nothing has suggested that any implementation be
required to have such a design - in all the suggestions I have seen,
a 6to4 encapsulator that simply had a fixed MTU, and sent back "too big"
whenever it is sent a packet bigger than that would be perfectly fine.

All of the issues are what should happen at the decapsulator when it
receives a packet it thinks is too big.   Now clearly, if the "too big"
is because of the next link the packet would be sent on, there's no issue,
that's another "too big" case - just send the ICMP.

If the "too big" is because the decapsulator doesn't have enough memory
that's when we have the issue.  There we can simply define a fixed size,
and require encapsulators (without explicit knowledge of the decapsulator)
not send bigger.   That's easy, and I don't mind that, provided the
fixed size is big enough (in particular, I'd like to be able to send
through an FDDI network, with IPv4 only routers, without causing packets
to get fragmented smaller than they need to be).

Or, we can be more flexible, and use Christian's suggestion, and just
allow the source node to receive a "too big" in this case as well (which
is really no different than if it received it from the encapsulator
because of a smaller MTU limit there, or if it received it from the
decapsulator because of a MTU limit on its outgoing interface).

If we could just believe that Christian's method is possible everywhere,
then I'd be all for not having a specified MRU (make it 64K) and just
allow that method to limit the sizes that the sources send.

However, because it is a fiddle into the IPv4 stack, for IPv6 purposes
(6to4 is almost an application, though it will generally be kernel
implemented) I'm not sure that all nodes (all stacks) are going to be
able to allow the 6to4 code to play in the IPv4 fragmentation queues.
And if nodes simply discard packets they see as being too big, which is
what happens to fragmented packets that can't be reassembled (the IPv4
too big for reassembly, which I think exists, is no use, it would be
sent to the encapsulator, which doesn't want to keep state) then black
holes develop (the same kind we see now when ICMP messages are filtered).

So, for that reason I think we do need to set a MRU.   But I doubt that
"baby embedded devices" are going to have the "keep your fingers out of
my data structure" problems that can exist in others - that kind of
device should have no trouble implementing Christian's algorithm.

So, I once again suggest a required MRU for 6to4 receivers of 4664 bytes.

And, in the doc, place something about Christian's device, so anyone who
can't find a way (and doesn't need to find a way) to reassemble 4664 byte
packets (plus IP header) can see how they can avoid breaking IPv6 completely.
It only needs to be a "here's the problem to be avoided, and here's a way
you can do that, without requiring that packets bigger than you want be
reassembled".

Nodes that can't implement that are most often running on bigger systems,
if they have software coming from multiple sources such that the 6to4
can't get inside IPv4 fragmentation (KAME on *BSD probably qualifies for
this, though it probably could be done if someone really wanted to), and
receiving 4664 (+20) byte packets is no real problem for them.

Finally, I'm afraid I don't buy the "this is just a transition mechanism,
so who cares if its inefficient" line of argument.   I might, if this was
a transition which we expected to be completed in 6 months, by which time
everyone who mattered would have upgraded.   The IPv4 to IPv6 transition
isn't like that however, it is going to take years (many years).   Quite
a long enough period that we want the transition mechanisms to actually
be usable and reasonable - they're going to get a LOT of use.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Sep 2002 13:16:10 +0200

"Fred L. Templin" wrote:
... 
> So, why should it not be the case the MRU = 64KB for IPv4?

Because that would make IPv4 fragmentation probable. We should
choose a default minimum MRU that makes IPv4 fragmentation 
improbable. That means less than 1500 for sure.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Sep 2002 15:03:10 +0200

> improbable. That means less than 1500 for sure.

Silly me. A friend points out that this argument is true of the
MTU, but not of the MRU. I think I will line up with kre on
a minimum MRU in the 4k range.

  Brian

---

From: [email-masked]
Date: Wed, 04 Sep 2002 22:09:21 +0900

>no greater than 1280 bytes, for those packets this whole discussion

	if i understand correctly, fred's proposal asks for it.

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 06:49:56 -0700

> in the spec, nor in the design (PMTU's are a per destination number).

I'll give an example of what Robert is talking about. IEEE 802.11 interfaces
in ad-hoc mode create per-neighbor links with QoS metrics that depend on
range, signal strength, S/N ratio, etc. Rarely is it the case that the
link QoS will be the same for any two neighbors, and the QoS will vary
with time as nodes move about. One means for adaptation would be to
provide an interface with per-neighbor (and variable) MTU to optimize
packet size on a per-neighbor basis - exactly the extension we have
been talking about in this thread.

The "variable MTU interface" extension is only an optimization, but
one that any system could easily take advantage of. Plus, I believe
it to be a generalized mechanism that will be needed for other media
types in the future (see example above).

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 07:01:19 -0700

> 	if i understand correctly, fred's proposal asks for it.
                                    ^^^^^^^^^^^^^^^

Itojun,

Stop right there and let me say this LOUDLY and CLEARLY; I claim NO
ORIGINAL CONCEPTS in my message dated 9/03/2002 in which I presented
"General encapsulator actions" and "Actions when encapsulator is an
IPv6 router". I am convinced that everything we are talking about here
is well-known in some circles and has been for a long time. Moreover,
I am convinced that there is an original inventor/inventors out there
who may/may not be taking part in this discussion. I think it high time
the inventors OR ANYONE WHO KNOWS WHO THE INVENTORS ARE disclose the
terms/conditions of any intellectual property rights.

So, this is NOT "fred's proposal" but rather Fred's glimpse into a body
of knowledge almost certainly attributable to other inventors. Bookmark
this message; I'll be referring back to it anytime anyone tries to
implicate me in such a way again.

Fred
[email-masked]

---

From: [email-masked]
Date: Wed, 04 Sep 2002 23:17:51 +0900

>> 	if i understand correctly, fred's proposal asks for it.

	your description on <[email-masked]> does not meet
	up with any of the existing logic (RFC2893, mech-v2-00).
	i don't think it reasonable to call your article "general encapsulator
	actions".  it's your new proposal.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Sep 2002 17:34:20 +0300 (EEST)

> 	actions".  it's your new proposal.

It seems very probable to me that Fred knows other people have already
used this mechanism (for something), and may already have patented or
applied for patents about it -- but cannot say more and is now expecting
to disclose IPR on it.

So we may very well just forget the proposal..

-- 
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: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Sep 2002 17:08:24 +0200

"Fred L. Templin" wrote:
...
> one that any system could easily take advantage of. 

And has nothing specific to do with any particular IPv6 interface type.
I thought we agreed some days ago that there is nothing new to say
about MTUs for 6to4 and Isatap - isn't the only open issue the
minimum MRU?

   Brian

---

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

Date:        Wed, 04 Sep 2002 07:01:19 -0700
    From:        "Fred L. Templin" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Stop right there and let me say this LOUDLY and CLEARLY; I claim NO
  | ORIGINAL CONCEPTS in my message dated 9/03/2002

No need to shout.   We try not to worry about personalities here
(occasionally it is impossible) - it is the idea that matters, not
where it came from originally (due credit and all that is good, if
it gets adopted, but we can discuss it without worrying overly much
about that).

But a method is needed to label the idea, and naming it as "Fred's
proposal" makes it clear what was being meant (that made Itojun's
message, in reply to mine, easy to grasp, where if he had said
"the idea posted in message-id; <xxx>" or something, I would have had
to go do a bunch of hunting...

kre

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 09:17:59 -0700

> 	up with any of the existing logic (RFC2893, mech-v2-00).

Are these documents the sum-total of everything that has ever been written
on the subject of IPv6-in-IPv4 tunneling? I think not.

   > Questions:

Until everyone involved in this discussion to date truthfully responds
to the first two questions in the list above, this is *not* my proposal.

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 13:13:27 -0700

> So we may very well just forget the proposal..

I think the jury is very much still out on this, Pekka.
(Referring to the earlier PMTUD discussions.)

Fred
[email-masked]

---

From: [email-masked]
Date: Thu, 05 Sep 2002 06:32:05 +0900

>to the first two questions in the list above, this is *not* my proposal.

	i see problems in the above "proposal", as stated already.
	i don't think there was similar proposal like this appeared elsewhere.
	(and i don't think what your wrote != what christian wrote)

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 15:01:34 -0700

> 	i see problems in the above "proposal", as stated already.

Sorry - what were the problems? You said something about the above
"proposal" not meeting up with any existing logic in RFC 2893, but
does this really matter?

> 	(and i don't think what your wrote != what christian wrote)

Look again; I said: "...scheme proposed by Christian and my messages"; NOT
"...scheme proposed by Christian and me". As I said before, I am convinced
this is not my original idea and I give full credit to any original inventors.
Perhaps we can refer to the combination of our two messages as the "anonymous
proposal". Or, if Christian wants to claim originality, "Christian's proposal
plus anonymous extensions".

Fred
[email-masked]

---

From: [email-masked]
Date: Thu, 05 Sep 2002 07:15:09 +0900

>"proposal" not meeting up with any existing logic in RFC 2893, but

	encapsulator/decapsulator keeping state.

itojun

Subject: Re: (ngtrans) Re: 6to4/isatap MTU
From: Jun-ichiro itojun Hagino <[email-masked]>
To: "Fred L. Templin" <[email-masked]>
Cc: [email-masked], Christian Huitema <[email-masked]>
Date: Wed, 04 Sep 2002 08:53:14 +0900

	encapsulator action

	decapsulator action

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 15:43:49 -0700

> 	encapsulator/decapsulator keeping state.

Yes, and I responded in kind in two seperate messages
(see the message archives). Were you not satisfied by
my explaination of the state reqt's?

Fred
[email-masked]

---

From: [email-masked]
Date: Thu, 05 Sep 2002 07:34:48 +0900

>"proposal" not meeting up with any existing logic in RFC 2893, but

	another problem i'm seeing is that with your text the tunnel interface
	is not a normal interface to IPv6 layer - IPv6 layer has to know
	the tricks to deal with it (so ip6_{in,out}put.c has to be patched
	to handle this interface).  IMHO tunnel interface has to be handled
	just like other interfaces, and encapsulate any gory details within.

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 15:56:35 -0700

[email-masked] wrote:
> 	to handle this interface).

You'll have to cite the specific text, because I can't recall
writing anything that would indicate this. Even so, this is just
e-mail discussion and not proposed text for any document at this
point.

Fred
[email-masked]

---

From: [email-masked]
Date: Thu, 05 Sep 2002 07:46:54 +0900

>my explaination of the state reqt's?

	i checked again, and (as i have responded) no i'm not satisfied at all. 

	- you are asking for encapsulating router to keep IPv6 state, for which
	  the router is not originating traffic.  this is not a normal
	  requirement to routeres.
	- you are asking for encapsulating/decapsulating router to handle tunnel
	  interface as a special interface, and mandate IPv6 layer to have
	  knowledge about the gory details of the interface.  interfaces
	  has to present the same API to IPv6 layer (like ifp->if_output in
	  BSD terminology)

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 04 Sep 2002 16:13:02 -0700

> 	  has to present the same API to IPv6 layer (like ifp->if_output in

Oh - now I understand your concern. Keep in mind though, *I* am not
asking for anything at all; I am making best-guesses as to what might
be in the "anonymous proposal" and I'm happy to be corrected where I've
guessed wrongly.

I need to leave for the day, but if you have any ideas on how to address
this (or even whether it needs to be addressed) I'd like to hear them.

Thanks,

Fred
[email-masked]

---

From: [email-masked]
Date: Thu, 05 Sep 2002 08:10:07 +0900

>this (or even whether it needs to be addressed) I'd like to hear them.

	my preference/solution is already presented on
	<[email-masked]>.  i don't think it
	necessary to address issues with PMTU, we just need to take a simpler
	(and more robust) route.  you can't use larger PMTU sometimes available,
	it's part of the deal.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Sep 2002 12:36:55 +0200

> So, I once again suggest a required MRU for 6to4 receivers of 4664 bytes.

We've had enough discussion I think. If you object to this proposal
please say so and propose an alternative value.

Let's get this decided before the WG is closed down...

(And please please do not take this new thread into any topic except
the MRU for 6to4.)

   Brian

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 05 Sep 2002 22:23:22 +0900

>(And please please do not take this new thread into any topic except

	yes, i propose required IPv6 link MRU be 1480 (1500 - 20).

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 05 Sep 2002 11:25:18 -0700

> please say so and propose an alternative value.

I disagree; there is still the "anonymous proposal" to consider, and
I don't think we've talked that out fully yet.

> Let's get this decided before the WG is closed down...

Is there a schedule for closing down the WG? Are Alain Durand, Tony Hain
and Margaret Wasserman still the active chairs until the actual closure?
(Have they even been monitoring the recent discussions?)

Fred
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Sep 2002 14:55:08 -0700

> there is still the "anonymous proposal" to consider

<AD hat on>

unless the nature of the subject _requires_ anonymity, if someone
is unwilling to stand for their work, why should we listen to it?
the ietf is a society of individual experts, not fantsies.

randy

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 05 Sep 2002 17:05:32 -0700

Randy,

I truly do not know where the "anonymous proposal" originated,
however I am certain that it is not my original work. I have made
some best-guesses as to what is in the proposal and believe it has
both merits and drawbacks. So, I would like to request that the
original inventor(s) come forward to fill in any details I may
have missed.

I'm leaving for the day today, and will check for further discussion
tomorrow. In the meantime, I would like to ask the community how they
believe the PMTUD problem is solved for configured tunnels (since this
seems to be a widely-held belief)?

Fred
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Sep 2002 16:59:11 -0700

> I truly do not know where the "anonymous proposal" originated,

and i don't care, because there is none.  when there is an internet-
draft, let's continue the discussion.  until then, forget this
noise.  end.

randy

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 05 Sep 2002 17:28:01 -0700

Randy,

Fine - but I still have a question outstanding that I would like to
see addressed by the community:

> In the meantime, I would like to ask the community how they

The community seems to believe generalized PMTUD is solved for configured
tunnels, but I have seen no specification to this effect in any wg drafts
or RFCs. Please enlighten me.

Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 5 Sep 2002 19:29:46 -0700

Fred L. Templin wrote:
> 
> Is there a schedule for closing down the WG? Are Alain 
> Durand, Tony Hain and Margaret Wasserman still the active 
> chairs until the actual closure? (Have they even been 
> monitoring the recent discussions?)
> 

I am back from a month of very intermittent network access and trying to
catch up. I would appear that there were at least two discussions
happening under the MTU thread, but I was having a hard time pulling out
what operational problems itojun was concerned about, what exactly
Christian was proposing, and what the value of Fred's apparent
automation and optimization of that proposal would be. 

I agree with Brian's sentiment that it is time to come to agreement, but
it doesn't sound like we have enough appreciation of the requirement to
really reach consensus. I know itojun said some devices won't have
enough memory to deal with a larger MRU, but I don't believe that should
be a driver in the decision about how the protocol should work, just
like I didn't believe that it was reasonable to leave IPv4 out because a
device was too small. These are simply engineering tradeoffs and the
people that build the devices will have to put enough into them to make
the protocol work as defined.

That said, does it really matter what the value is as long as it is
large enough to accommodate the expected traffic without requiring a
complex scheme to discover a working value? In the short term that would
appear to be 1500 (before anyone jumps on this, there is no reason to
get upset about wasting 20 bytes of receive buffer), but in the longer
term I have to agree with kre that a larger number makes more sense. In
5 years (when 6to4 use should be very common) won't the normal consumer
interface be at least gigE? If that is true, picking 1500 would appear
to be as bad a choice as 576 appears today. If we pick 4664, have we
exceeded some architectural capacity of current appliance devices, or
are we just raising their cost? If it is the former I would be willing
to concede to a lower value, but for the latter it would apply to all
manufacturers so it just doesn't matter.

So to expand on Brian's call of the question, if you object to 4664,
state your prefered value along with a technical justification of why
4664 won't work.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 05 Sep 2002 18:01:16 -0400

>(Have they even been monitoring the recent discussions?)

No, yes and yes (well, at least I am).

Margaret

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 06 Sep 2002 13:24:14 +0900

>state your prefered value along with a technical justification of why

	i still propose 1480 (1500 - 20) as minimum required IPv6 link MRU.

	reasons:
	- with bigger MRU, we will impose implementation hurdles to embedded
	  IPv4 devices/small routers.  here we are talking about minimum
	  required value every node should (or must) support, so engineering
	  tradeoff is important.
	- i don't think 6to4 will be there for that long time.  by the time
	  GigE is everywhere (like to my/your home) we should have native IPv6
	  connectivity and the need to 6to4 is already eliminated (6to4 might
	  still be in use, however, those networks will be using 1500 as MTU).
	  therefore, it is unnecessary to have larger MRU for 6to4 interfaces.

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 06 Sep 2002 13:26:14 +0900

>automation and optimization of that proposal would be. 

	the reason why this topic is raised is interoperability problem
	(we have experienced it for real at IETF52 network setups).

	- for configured tunnels, we need to define IPv6 default link MTU/MRU.
	  peers can make prior agreement to use larger/smaller value, if
	  needed.
	- for 6to4/isatap, we need to define IPv6 default link MTU/MRU
	  for interoperability.  note that with 6to4/isatap you are connected
	  to multiple peers, not just one peer.

itojun

---

From: Alain Durand <[email-masked]>
Date: Thu, 05 Sep 2002 21:37:27 -0700

> No, yes and yes (well, at least I am).

Randy's earlier message made it clear that the Ngtrans wg was
declaring victory and shutting down:

 >From: Randy Bush <[email-masked]>
 >Date: Wed Aug 14, 2002  8:05:11 AM US/Pacific
 >To: NGtrans wg <[email-masked]>
 >Subject: (ngtrans) v6 considered operational
 >Reply-To: Randy Bush <[email-masked]>
 >
 >it is time for ngtrans to declare victory [0].  ngtrans has come
 >up with many tools, even more than were expected.  but, as we saw
 >in yokohama, v6 is here.  wgs don't go on forever.  it is time to
 >declare victory for ngtrans and move forward.

I've been monitoring the discussion on 6to4 MTU/MRU carefully,
I think most of the proposal have been made very clear, and it is
now time to come to a consensus.

As Christian Huitema said, we can invent all kind of complex mechanisms,
but we have to remember that we are talking about a "transition" 
mechanism
that will go away, and it really makes sense to favor simplicity over 
completeness.

	- Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 06 Sep 2002 00:55:44 -0400

Hi Alain,

>but we have to remember that we are talking about a "transition" mechanism
>that will go away, and it really makes sense to favor simplicity over completeness.

I strongly agree with you, Itojun and Christian on this.  Simplicity is
more important than maximal performance for this mechanism, and an MRU of 
1480 is fine with me.

It's not clear to me, though, why it matters whether or not the ngtrans
group establishes consensus on this before we shut down...  If we plan to 
update the 6to4 RFC, we will have to do that within the v6ops WG, anyway.

Margaret

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 6 Sep 2002 00:19:51 -0500

----- Original Message ----- 
From: "Jun-ichiro itojun Hagino" <[email-masked]>
>   connectivity and the need to 6to4 is already eliminated....

If you look at the code for the so-called 6to4, you will see it is broken for
any serious usage. Fixing it for "native" NG advocates makes it more clear
that IPv6, at best, is an extension header for IPv4. Via unified address space
management, IPv4 users are never dis-connected and gracefully migrate
via NAT and other transition techniques to the NG Internet. The IPv4 public
core transport can be used as a non-QoS (TOS=0* or *0) network to carry
traffic that does not route (natively) around that aging core.

The GigE Everywhere (GEE) IPv16 network starts native and ends native...
...end-users do not connect directly to that network...only qualified, robust, 24x7 operations...

NG is not IPv6...Native IPv4 will be around a long long time...

Jim Fleming
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Sep 2002 18:20:59 +0700

Date:        Fri, 06 Sep 2002 00:55:44 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | It's not clear to me, though, why it matters whether or not the ngtrans
  | group establishes consensus on this before we shut down...

yes, please, let's shut this group down ASAP (tomorrow??)  Then we can
be rid of the totally bogus mailing list software that this list is
currently using, which is inserting a totally inappropriate and nonsense
Reply-To header on every message.   Lists that direct replies to the
list itself I understand (even if I don't much like that kind of behaviour).
Lists that direct replies, via a Reply-To to the author (copying the
From: header) are simply broken.   In fact, I don't know that I have ever
experienced one as broken as this before...

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Sep 2002 18:17:26 +0700

Date:        Fri, 06 Sep 2002 13:24:14 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	- with bigger MRU, we will impose implementation hurdles to embedded
  | 	  IPv4 devices/small routers.  here we are talking about minimum
  | 	  required value every node should (or must) support, so engineering
  | 	  tradeoff is important.

Um - only 6to4 routers need implement this, and that's nothing like
"every node".   If a node can't handle it, then it can just not be a
6to4 router, can't it?   If your ADSL gateway is too cheap to cope,
perhaps you'll have to use some other box inside your net as your
6to4 gateway (I believe that XP can cope, it typically runs on
systems with just a little more than 32KB of available ram...)

  | 	- i don't think 6to4 will be there for that long time.  by the time
  | 	  GigE is everywhere (like to my/your home) we should have native IPv6
  | 	  connectivity and the need to 6to4 is already eliminated (6to4 might
  | 	  still be in use, however, those networks will be using 1500 as MTU).
  | 	  therefore, it is unnecessary to have larger MRU for 6to4 interfaces.

I disagree with the "those networks will be using 1500 as MTU" part of this.
That is not at all certain.

Furthermore, how quickly IPv6 will deploy into the backbones, compared with
how quickly they're upgraded to GigE (and greater) bandwidths isn't
knowable.  The two things aren't necessarily related.   Higher bandwidths
get installed when traffic (and hence revenue one hopes) demands it.
IPv6 will appear when customers demand that.   I am fairly sure that at
the minute v4 traffic volumes are still rising.   So, it is entirely
possible that there will be GigE backbones, that only support v4.  Assuming
they will necessarily support v6 is just wishful thinking (I'd like to
believe they will, but I am not prepared to bet upon it).

On the other hand, it is entirely reasonable to assume that some end user
organisations connected to these backbones will be using their own GigE
equipment (or FDDI...) and will want to be running v6.   Those organisations
may easily be using 6to4 addresses, long after all of the cabling can
handle packets bigger than 1500.   And v6 will be being cursed by the
operators if we limit all the v6 traffic to a smaller than necessary MTU.
And we won't like it either, because v4, using the bigger MTU available to
it, will be outperforming v6 all the way - which by itself might be
enough to allow operators who would prefer not to dploy v6 to avoid doing
so.   All they need to do is ask theur end-users to run a test.   Use v4
to copy this data, and at the same time (so net conditions are the same)
allocate yourself a 6to4 address, and use v6 to copy the same data - you'll
see that v6 is much slower than v4 (maybe it is the effect of those bigger
headers...) so just use v4 (and NAT) and you'll be happier...

I think my last words on this topic, since I think I've said enough, will
be to once again point out that while 1500 MTUs are common, specifying
a MRU of 4664 means almost nothing, as IPv6 PMTUD will limit all the
packets to 1500 anyway.   Devices can pretend that they can reassemble
4664 byte packets, and even if they can't, in practice no-one will care.

So, if you believe that 6to4 will be dead before larger MTUs become
practical, then it really does no harm to specify a larger MRU, nothing
will ever actually test that.

On the other hand, if you don't believe that 6to4 will be dead by the
time that larger MTU's start being used, then surely we do need to
define the MRU large enough not to make us all lave looked absurdly
short sighted.

kre

---

From: Steve Deering <[email-masked]>
Date: Fri, 6 Sep 2002 05:09:34 -0700

>	i still propose 1480 (1500 - 20) as minimum required IPv6 link MRU.

We might want to go a little bit shorter than that, e.g., 1440, to
further reduce the probability of IPv4 fragmentation in cases where the
encapsulating IPv4 packet itself crosses an IPv4 tunnel.

Steve

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 06 Sep 2002 21:14:44 +0900

>systems with just a little more than 32KB of available ram...)

	normally you can't terminate 6to4 by other boxes, becuase the cheap
	ADSL gateway is the only device with IPv4 global address.

itojun

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Sep 2002 20:05:45 +0700

Date:        Fri, 06 Sep 2002 21:14:44 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

OK, just one more message...

  | 	normally you can't terminate 6to4 by other boxes, becuase the cheap
  | 	ADSL gateway is the only device with IPv4 global address.

In that case, it has to be doing NAT, and probably ALG's as well, right?
Or it isn't going to be very useful.   So it has sufficient memory for the
NAT state tables, and all of that, but apparently not enough to reassemble
an occasional larger than normal packet?   That sure sounds weird to me.

kre

ps: I don't assume that you can (as you should be able to) configure the
box to add a static mapping, or port translation mapping, to some internal
box - while I don't doubt these boxes could handle that, I do suspect that
their implementors don't want to attempt to explain to their users just how
to configure it and make it work - that's a real cost that wouldn't be cheap.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 06 Sep 2002 22:23:40 +0900

>an occasional larger than normal packet?   That sure sounds weird to me.

	on many of those cheap devices reassemble for the tiny router itself
	and forwarding path (with NAT) are totally different.  i've seen weird
	small router devices that cannot reassemble traffic for itself but can
	do NAT (at ipsec test events).  it's for real.  i'm not dreaming.

itojun

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 6 Sep 2002 08:26:28 -0500

----- Original Message ----- 
From: "Jun-ichiro itojun Hagino" <[email-masked]>
To: "Robert Elz" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 06, 2002 7:14 AM
Subject: Re: (ngtrans) 6to4 MRU - need WG consensus 

> ADSL gateway is the only device with IPv4 global address.

6to4 is flawed. It is not a good end-to-end solution for extended addressing.
It appears to be some university research project or high-school science fair gizmo.

When you build a serious end-to-end network, it is important to make sure that
packets going out have addresses which allow replies to be sent back.

Building broken transition schemes to encourage people to move to a Native NG
that no one now uses, does not seem like a prudent thing to do. When people see
it is broken, they will return to the legacy Internet, because it works. They will not
jump across to a native network and disconnect themselves from the world. If they
do, they fragment the net. That violates the smooth, stable, transparent end-to-end
attributes need in the NG Transition mechanisms.

Jim Fleming

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Sep 2002 20:29:39 +0700

Date:        Fri, 6 Sep 2002 05:09:34 -0700
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220806b99e49a819cf@[192.168.0.51]>

  | We might want to go a little bit shorter than that, e.g., 1440, to
  | further reduce the probability of IPv4 fragmentation in cases where the
  | encapsulating IPv4 packet itself crosses an IPv4 tunnel.

Hmm - another one I just have to answer.

The possibility of IPv4 fragmentation in the path has absolutely
nothing whatever to do with what is being discussed here.

The is controlled (absolutely) by the MTU at the sender into the tunnel.

What is being discussed is the MRU of the recipient.   That is, at
what size should the recipient of a packet (which has arrived, reassembled
if it needed to be - which any (IPv6) MTU > 48 might require in some
absurd environments - and no, I didn't omit any digits there, I mean 48)
just discard the packet rather than processing it - discard it as a
protocol violation.

By all means, set the MTU for the sender to be 1440, or 1480, or 1280,
or any other number in that range, for now, that's a very practical number
to choose, and will minimize the likelihood of IPv4 fragmentation on
today's networks.

But this is something completely unrelated to what the rest of this
discussion has been about.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 06 Sep 2002 20:39:34 +0700

Date:        Fri, 06 Sep 2002 22:23:40 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	on many of those cheap devices reassemble for the tiny router itself
  | 	and forwarding path (with NAT) are totally different.  i've seen weird
  | 	small router devices that cannot reassemble traffic for itself but can
  | 	do NAT (at ipsec test events).  it's for real.  i'm not dreaming.

No, I'm sure you're not.   And what's more, I can understand that as
an implementation completely - I have done an implementation that would
behave just like that.

That is, for the purposes of the device, I could see no point implementing
reassembly at all, it was just a bunch of code I'd have to write, and
attempt to debug, in an evnironment where no fragments would ever really
be addressed to the box at all (I half remember eventually adding the
reassembly code - but only because I decided I should do what the specs
say, or at least pretend to, I have no idea if that code ever worked, I'm
sure it was never exercised in the wild).

To be more explicit, very few things every talk directly to these
devices - and those that do can pretty much be assumed to be on a path
with an MTU > 576, and that's as big as an IPv4 device is required to
be able to receive...   No fragments ever get sent to the box in any
real end-user situation.

But have the boxes like this that you've seen actually implemented 6to4?

I kind of suspect not - and I suspect that if they needed to implement
reassembly for some real purpose, then reassembly could be handled.
It's entirely possible they might decide that Christian's device is
easier, and just do that (which is just fine).   That is, the reason
reassembly isn't being done isn't that they don't have enough RAM to
handle a packet as big as 4K, but they they don't currently have any
reason to bother doing it.

kre

---

From: Alain Durand <[email-masked]>
Date: Fri, 06 Sep 2002 09:08:19 -0700

> update the 6to4 RFC, we will have to do that within the v6ops WG, 

What matters is reaching consensus, not where.

	- Alain.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 6 Sep 2002 10:30:41 -0700

Steve Deering wrote:
> We might want to go a little bit shorter than that, e.g., 
> 1440, to further reduce the probability of IPv4 fragmentation 
> in cases where the encapsulating IPv4 packet itself crosses 
> an IPv4 tunnel.

A shorter MTU might make sense, but the MRU needs to be long enough to
deal with unfragmented packets. If I buy itojun's argument (and I don't
yet), that would mean 1500 makes sense and anything shorter than 1480
does not. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 6 Sep 2002 10:42:49 -0700

> 	  to multiple peers, not just one peer.

What you needed to agree on was that MRU >= MTU, not specific pair
values. I agree the 6to4 mechanism creates a global logical link,
therefore we need to agree on some values here, but I think the
discussion is sidetracked by trying to make the two values the same.
What is really required is that the receiving 6to4 router is able to
reassemble any IPv4 fragments that might occur. While it is nice to pick
an MTU size that makes that less likely, it is not a requirement because
there are still parts of the network that will force fragmentation below
1280.

You are arguing to keep the MRU as small as possible to reduce the
demands on embedded devices, and that will feed back into the MTU, but
as long as the MTU is no larger than the MRU it really doesn't matter
what it is. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 6 Sep 2002 11:00:57 -0700

> 	  required value every node should (or must) support, 

Hurdles I really don't care about, they apply to everyone equally so the
only real question is the bar too high for anyone to get over, or is it
just raising the costs. So far it looks like we are just raising costs
because I haven't heard that there is an architectural constraint (like
all the current embedded devices only address 64kb of ram). If we are
just talking about adding extra memory in the appliance we should pick a
value that will look reasonable 5 years from now and get on with it.

> 	  therefore, it is unnecessary to have larger MRU for 

I know you believe deployment is on a fast track, and I would like to
see that as well. Unfortunately what I do see is that the larger
networks at the core are moving because there is little reason not to,
but the smaller networks with direct consumer touch are very reluctant
to make the change (particularly if they have an extensive installed
base of IPv4 nat based CPE) so native service to the consumer will be
much slower. Also, I was not arguing about the ability to get GigE
service to the home, but that the appliance interface would be GigE with
some large number of Mbps of service behind it. If this is reasonable to
expect over the next 5 years, why shouldn't we be enabling the protocol
to take advantage of it?

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Sep 2002 12:49:11 +0200

> encapsulating IPv4 packet itself crosses an IPv4 tunnel.

Hmm. That's a bit of a corner case for 6to4 don't you think?

Personally, I'm more convinced by Christian's & itojun's arguments than by 
kre's. Although I'd dearly like to see larger packet sizes in use, we've been
waiting many years to get above 1500 and I think we'll wait a lot longer.
And we're only specifying a *minimum* MRU. 

So I'll hum for 1480 as the required minimum MRU for 6to4. I'll 
ignore the efforts to divert this thread back into a debate about 
MTU size, which is not an open issue for 6to4 as far as I know.

  Brian

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Sep 2002 13:01:01 +0200

Change of Subject to correspond to the change of subject.

..
>           to multiple peers, not just one peer.

I have no comment on ISATAP and we have a separate thread on the 6to4 MRU.

Since there is a defined IPv4 MTU (576) surely the default 6to4 MTU is
automatically 556 without any need for further specification? Personally,
I'd recommend configuring it higher in practice, and pulling it back to
556 in case of strange failure. But I don't see why we need to specify that
in a standard. That is why I see no open issue here for the WG.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Sep 2002 13:05:08 +0200

Margaret Wasserman wrote:
...
> update the 6to4 RFC, we will have to do that within the v6ops WG, anyway.

Because otherwise the discussion will meander on for monthgs, and there is 
shipped code out there already. 

I doubt if this point is enough on its own to bother updating the RFC.

   Brian

---

From: [email-masked]
Date: Sun, 08 Sep 2002 23:00:07 +0900

>MTU size, which is not an open issue for 6to4 as far as I know.

	hmm?  if we set required minimum MRU to X (X >= 1280), 6to4 link MTU
	needs to be Y which is X >= Y >= 1280.

itojun

---

From: [email-masked]
Date: Sun, 08 Sep 2002 22:57:47 +0900

>in a standard. That is why I see no open issue here for the WG.

	IPv6 minimum link MTU is 1280, and if we believe MRU >= MTU, 556
	looks strange to me.

itojun

---

From: Randy Bush <[email-masked]>
Date: Sun, 08 Sep 2002 07:08:41 -0700

all this discussion of mtu seems to forget the problems with delivering
v6 or signed dns data.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Sep 2002 09:24:52 +0200

556 looks very strange. I was indeed attempting a *reductio ad absurdum*.
(http://www.dictionary.com/search?q=reductio%20ad%20absurdum)

As you point out we already have an IPv6 MTU definition, which happens
to be compatible with the normal observed IPv4 MTU size, as Christian's data
showed. But if you want to be mathematically strict and strictly avoid
IPv4 fragmentation, the answer would be 556. Which is silly. So let's
just say nothing about the 6to4 MTU. It inherits the MTU from RFC 2460.

  Brian