Subject: IPv6 MTU for tunnel pseudo interfaces

From: [email-masked]
Date: Thu, 08 Aug 2002 14:39:22 +0900

many of existing implementations abstract IPv6-over-IPv4 tunnels, like
	following, as pseudo interfaces:
	- configured tunnels (RFC2893 section 4) - gif(4) in KAME
	- 6to4 tunnels (RFC3056) - stf(4) in KAME
	- isatap

	none of the above document specify what IPv6 MTU to use for these
	interfaces.  (RFC3056 has a pointer to RFC2893, but RFC2893 has nothing
	about IPv6 MTU)

	the lack of standard IPv6 MTU could lead to interoperability problem.
	consider the following scenario:
	- node A is using MTU X for tunnel interface (X >= 1280)
	- node B is using MTU Y for tunnel interface (Y > X >= 1280)

	now, if B transmits packets larger than X, A may drop it as it is
	larger than MTU (assuming MRU == MTU), causing blackhole.
	also, MTU mismatch could have some impact to PMTUD if A and B are
	routers.

	with configured tunnels, the issue is not that serious as we only need
	two party to agree on what MTU to use (so if operators are
	clever/careful enough, we are okay).  for 6to4 and isatap, the issue
	is serious as there are multiple nodes sharing the same virtual link.

	we actually have experienced interoperability problem between KAME and
	JunOS for configured tunnels, as KAME is using 1280 as MTU and JunOS
	is using infinity (so PMTUD does not occur).

	therefore, I propose:
	- to specify default IPv6 MTU of RFC2893 tunnel interface be 1280,
	  in RFC2893bis (so, 6to4 MTU will become 1280).  of course operators
	  can override if they wish to, specifically for configured tunnel case.
	- add reference from isatap document to 2893bis to follow it.

	any comments?

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Aug 2002 09:24:22 +0300 (EEST)

> 	also, MTU mismatch could have some impact to PMTUD if A and B are

MRU == MTU seems an invalid assumption (in practise).

Nodes must be able to receive packets with at least 1500 bytes (I tried 
looking up where this was stated but couldn't remember where).

But what is the problem here?  If node A drops the packet, it sends packet 
too big message back, and the sources adjust?
 
> 	is using infinity (so PMTUD does not occur).

Every node must be capable of at least being a recipient to PTMUD (that 
is, adjusting the sending MTU based on packet too big messages).  Else we 
have way too many problems.
 
> 	- add reference from isatap document to 2893bis to follow it.

Operationally, the 1280 default for configured tunnels seems very 
unoptimal.  Source nodes which use a larger MTU, like 1500, need to 
initiate PMTUD if they use links with tunnels; not good.

For automatic tunnels (incl. 6to4 etc.) 1280 might be a safe choice.

-- 
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: Thu, 08 Aug 2002 15:28:41 +0900

>too big message back, and the sources adjust?

	i know of no nodes that transmit packet too big messgages, when
	incoming packets exceed MRU.  too big messages are generated
	when outgoing packets exceed MTU.

itojun

---

From: [email-masked]
Date: Thu, 08 Aug 2002 15:33:58 +0900

>>looking up where this was stated but couldn't remember where).

	the above statement is about the packet size after reassembly,
	not about the link MRU.

itojun

---

From: [email-masked]
Date: Thu, 08 Aug 2002 15:39:12 +0900

>have way too many problems.

	let me annotate.  we experienced troubles under the following
	configuration.  MTU mismatch occured between routers, and caused
	troubles to the end nodes that are served by these routers.

end node --- KAME ============== Juniper --- end node
		  1280     infty

itoju

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Aug 2002 09:41:37 +0300 (EEST)

On Thu, 8 Aug 2002 [email-masked] wrote:
> 	incoming packets exceed MRU.  

No nodes do; but I know of no nodes that drop packets they're able to 
receive based on some configured maximum value either.

> too big messages are generated

But if a node X is able to send packet on a medium (in case of tunneling,
nothing physical though), and node Y is able to receive it, why should it
check MRU?

---

From: [email-masked]
Date: Thu, 08 Aug 2002 15:49:49 +0900

>nothing physical though), and node Y is able to receive it, why should it

	since there's no standard, some implementation can be picky and
	assume MRU == MTU.  maybe RFC2893 should talk more about MRU and MTU.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Aug 2002 10:01:04 +0300 (EEST)

> 	assume MRU == MTU.  maybe RFC2893 should talk more about MRU and MTU.

I've configured Ethernet MTU to be 1500 on the sender side and 1280 on the
recipient side (MRU is generally unconfigurable); it works without
problems as far as I've noticed.

These issues are not specific to tunnels as far as I can see.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Aug 2002 14:03:19 +0200 (CEST)

> 	interfaces.  (RFC3056 has a pointer to RFC2893, but RFC2893 has nothing

I see these words in RFC 2893 which seem to be relevant to this issue:
   The IPv6 layer in the encapsulating node can
   then view a tunnel as a link layer with an MTU equal to the IPv4 path
   MTU, minus the size of the encapsulating IPv4 header.

This is suggesting that the interface MTU for such a tunnel is dynamic
by being a function of the IPv4 path MTU across the tunnel.
A result of such behavior is that the initial MTU for such a tunnel
interface would be the interface MTUs for the underlying physical
interface for the tunnel, minus 20 bytes for the IPv4 header.

But I take it from your question that you'd like to see a fixed number for
the MTU. Is this really necessary?

> 	larger than MTU (assuming MRU == MTU), causing blackhole.

Such an assumption and the resulting dropping behavior seems like a very
bad idea.   (Are there such implementations?)
If folks make such assumptions I guess we need to make it more clear
what "be liberal in what you accept" in the case of tunnels and explain
what the "T" stands for in "MTU". But it doesn't follow that we need to
pick a fixed MTU number.

> 	also, MTU mismatch could have some impact to PMTUD if A and B are

I don't understand the issue. Care to explain?

> 	is using infinity (so PMTUD does not occur).

Do either of then drop received packets that exceed the configured MTU?

The way you dscribe it it seems like JunOS doesn't follow the text in
section 3.2 in RFC 2893, but that by itself will merely cause inefficient
behavior (IPv4 reassembly at the router = tunnel endpoint instead of e2e 
IPv6 path mtu discovery and IPv6 reassembly at the IPv6 endpoint) and
not interoperability problems.

> 	  can override if they wish to, specifically for configured tunnel case.

Seems like overkill. But perhaps I don't understand the details of the problems
yet.

BTW: Shouldn't we discuss RFC 2893 on the ngtrans list?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Aug 2002 14:10:10 +0200 (CEST)

> 	assume MRU == MTU.  maybe RFC2893 should talk more about MRU and MTU.

How about:
	A node implementing RFC 2893 MUST be able to reassemble IPv4 packets
	of a size up to and including 65353 octets and MUST NOT place
	any limits on the size of the received encapsulated packets.
	In particular, it MUST NOT assume that the maximum size of
	received packets has anything to do with the MTU for the tunnel.

Of course, it might also make sense to add some SHOULD (or MUST?) to
section 3.2 in RFC 2893 to make IPv4 MTU discovery across the tunnel
seem less optional than what the current text says.

 Erik

---

From: [email-masked]
Date: Sat, 10 Aug 2002 00:26:54 +0900

>the MTU. Is this really necessary?

	yes, it definitely needs to be a fixed number.  in other words, IPv6
	link MTU should not be computed based on IPv4 PMTU (which is dynamic).
	PMTUD assumes that link MTUs are stable enough.  by using IPv4 PMTU
	as basis for IPv6 link MTU, IPv6 link MTU will be affected by IPv4
	routing changes.  it will have negative impact to IPv6 PMTUD.

itojun

---

From: Bill Manning <[email-masked]>
Date: Fri, 9 Aug 2002 08:37:20 -0700 (PDT)

% >But I take it from your question that you'd like to see a fixed number for
% >the MTU. Is this really necessary?
% 
% 	yes, it definitely needs to be a fixed number.  in other words, IPv6
% 	link MTU should not be computed based on IPv4 PMTU (which is dynamic).
% 	PMTUD assumes that link MTUs are stable enough.  by using IPv4 PMTU
% 	as basis for IPv6 link MTU, IPv6 link MTU will be affected by IPv4
% 	routing changes.  it will have negative impact to IPv6 PMTUD.
% 
% itojun

	for "cross-talk" to occur, is there a presumption of fate-sharing
	on links?  e.g. do you presume that a single link will always
	support both v4 and v6?

-- 
--bill

---

From: [email-masked]
Date: Sat, 10 Aug 2002 00:39:51 +0900

>	on links?  e.g. do you presume that a single link will always

	no, i do not assume that.  since this is a document about tunnelling,
	IPv4 path could be arbitrary (some of the paths could be IPv4-only
	of course) while IPv6 (over IPv4) is one-hop.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Aug 2002 17:40:38 +0200 (CEST)

> 	PMTUD assumes that link MTUs are stable enough. 

I know of no such assumption.

In fact PMTUD is designed deal with routing using different paths with
different MTU over time (and even at the same time) by taking the minimum
of the reported MTUs. Dealing with an interface which changes MTU
falls out of that design for free.

>       by using IPv4 PMTU

What exactly is the negative impact?
Using a dyanmic MTU for the tunnels has the positive impact of being able
to send larger, thereby fewer, packets when the path supports the larger MTU.

  Erik

---

From: [email-masked]
Date: Sat, 10 Aug 2002 00:58:39 +0900

>falls out of that design for free.

	i haven't seen links that changes MTU (*1) dynamically based on
	dynamic changes from outside (*2).  in this case (*1) is "IPv6 MTU
	on top of tunnel" and (*2) is "IPv4 routing changes".
	maybe my experience is limited, but anyway, i have never seen one.

>What exactly is the negative impact?

	if link MTUs are not stable enough, there will be more ICMP too big
	than we desire.

>to send larger, thereby fewer, packets when the path supports the larger MTU.

	with the cost of complexity in tunnel endpoint implementations (needs
	to maintain IPv4 path MTU and reflect it to IPv6 tunnel link MTU).
	i would really like to know how many of existing implementations follow
	this part of RFC2983.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Aug 2002 18:43:51 +0200 (CEST)

> 	maybe my experience is limited, but anyway, i have never seen one.

I having a hard time parsing this regular expression.

Looking at the definitions in RFC 2460 and 1981 I see it clearly:

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

   link MTU    - the maximum transmission unit, i.e., maximum packet
                 size in octets, that can be conveyed in one piece over
                 a link.

When the link is a tunnel the link MTU is defined to effectively vary based
on the path MTU of that tunnel, since different size packets can
be conveyed in one piece over the tunnel at different points in time.

> 	if link MTUs are not stable enough, there will be more ICMP too big

Please provide an analysis. I don't think this is the case.

The time limit for when an path MTU increase is attempted (10 minutes by
default in RFC 1981) limits this whether the potential for increase is
for a tunnel link (due to IPv4 routing changes) or due to IPv6 routing using
a different set of links.
When the path MTU decreases (for a tunnel link, or due to IPv6 routing using
a different set of links) a single ICMP too big is sufficient. (Of course,
if there is a window full of large packets you might see more than one subject
to ICMP error rate limiting.)

The point is that I don't see why there should be anything
new here for tunneling.

The tradeoffs for path MTU discovery are:
 - downside of ICMP error packets
 - downside of additional roundtrip times due to the data packets being 
   lost when the packet is to big
 - the benefit of making the retransmission unit the same as the loss
   unit, while being able to with larger packets

If this tradeoff comes up with PMTUD makes sense when there is no
tunneling, then I don't see why the same conclusion doesn't hold
for the case of nested PMTUD using tunnels.

So I'm looking forward to your performance analysis.

> 	to maintain IPv4 path MTU and reflect it to IPv6 tunnel link MTU).

Yes. And there is additional complexity to implement PMTUD in the non-tunneling
case. Thus I think your arguments about performance and implementation
complexity can also be used to argue that we shouldn't do PMTUD at all and
instead send with 1280 bytes.

FWIW The Solaris implementation doesn't have soft state in the tunneling
pseudo-device driver. It is all reflected in the conceptual neighbor cache
for the "upper IP layer" when an ICMP too big arrives from the "lower IP
layer".

> 	i would really like to know how many of existing implementations follow

Solaris does.

I might also make sense to ask what folks do that have IPv4 in IPv4 IPsec 
tunnels. I *think* (but am far from certain) that the disadvantage of
doubling the number of packet due to the packets with the IP+ESP headers
being too big means that it is common for such implementions to reflect
PMTU up through the tunnelong pseudo interface.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Aug 2002 18:47:55 +0200 (CEST)

> I having a hard time parsing this regular expression.

I'm also having a hard time writing :-)

I meant to say
	I'm having a hard time parsing this regular expression :-)

  Erik

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 9 Aug 2002 11:54:44 -0500

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
> I'm having a hard time parsing this regular expression :-)

http://www.rebol.com/

C@t will be back...

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 10 Aug 2002 08:55:21 -0400

Hi Erik,

There are many implementations that don't have the ability to 
reassemble a 65,353 byte packet, at least not without allocating
a 64K buffer for this purpose.  So, this seems to be a harsh
restriction to place on RFC 2893 implementations.

If we need to choose one or the other, I'd prefer limiting the
MTU of these tunnels to 1280.

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Sat, 10 Aug 2002 16:49:54 +0300 (EEST)

> MTU of these tunnels to 1280.

Do such implementations which have problems with 64KB packets need to be 
able to use tunneling?

Doesn't seem harsh to me (e.g. small devices like LCNA's should not have
to do this), though we need analysis whether this is really a problem.

---

From: [email-masked]
Date: Sat, 10 Aug 2002 22:53:06 +0900

>Do such implementations which have problems with 64KB packets need to be 

	yes.  think of small devices like DSL routers at home.  they terminate
	tunnels, and have severe memory limitations.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Sat, 10 Aug 2002 16:58:19 +0300 (EEST)

> 	tunnels, and have severe memory limitations.

At least some of those I know have like 2 .. 8 MB of memory, of which 64KB 
isn't really all that much.  Do you have better knowledge of such DSL 
routers' capabilities?

And nothing says you have to be able to defragment more than one packet at
the time; further, especially if such devices use confg'd tunneling, it's
most probable such packets would never be sent (except in a DoS attack).

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 10 Aug 2002 10:07:55 -0400

>Do such implementations which have problems with 64KB packets need to be 

I'm not sure -- do you think that home gateways, cable modems, DSL 
modems, etc. will need to use tunneling?

>to do this), though we need analysis whether this is really a problem.

I agree that a home security system or a car radio isn't likely to start
tunneling any time soon.  But, most home gateways and SOHO routers are closed 
embedded system with no disk and/or virtual memory.  Do you expect that
they will need to use tunneling?

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Sat, 10 Aug 2002 17:13:06 +0300 (EEST)

> they will need to use tunneling?

They probably need to be able to use tunneling, at least some of them.

But if they're designed so that they have problems with allocating 64 KB 
of memory, there's something about the design that's wrong IMO.

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 10 Aug 2002 10:25:16 -0400

>of memory, there's something about the design that's wrong IMO.

It's not really a design issue, it is a cost issue... 

The implementations used in these boxes are quite configurable -- the person 
who integrates the stack into the box can make all sorts of choices about 
how many buffers are available of what sizes, etc.  This restriction would 
require that the integrator allocate at least one 64K buffer (or enough buffer
space in a chained buffer system) to re-assemble a 64K packet.

These systems are very cost-sensitive, and vendors are very careful
about limiting the memory size, especially the R/W memory size, of these
devices.  They will typically complain about anything that "wastes"
more than ~16K of memory.

What are the major down sides of limiting the MTU on these tunnels?

Margaret

---

From: Tim Chown <[email-masked]>
Date: Sat, 10 Aug 2002 15:22:52 +0100

> modems, etc. will need to use tunneling?

There is a DSL product from 6WIND that runs 6to4; it may use other
tunneling mechanisms, but I don't have the full spec to hand.   This
is quite a nice way to deploy IPv6 to the home until native DSL
solutions arrive.   It's only a niche market right now though.

Tim

---

From: "Robson Lopes Jr. Mbone" <[email-masked]>
Date: Sat, 10 Aug 2002 11:43:20 -0300 (BRT)

Hi, I'm having some problems on configuring a lab linux RH 7.1 - Kernel
2.4.14:
Here is the configuration of a machine with 3 interf.

[root@gateway07 /root]# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:80:5F:31:D9:DC
          inet addr:192.168.74.253  Bcast:192.168.74.255  Mask:255.255.255.0
          inet6 addr: fe80::280:5fff:fe31:d9dc/10 Scope:Link
          inet6 addr: 3ffe:2b00:100:10b::24/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:280 errors:0 dropped:0 overruns:0 frame:0
          TX packets:157 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:9 Base address:0x1040

eth1      Link encap:Ethernet  HWaddr 00:04:AC:25:F5:C8
          inet addr:192.168.75.253  Bcast:192.168.75.255  Mask:255.255.255.0
          inet6 addr: fe80::204:acff:fe25:f5c8/10 Scope:Link
          inet6 addr: 3ffe:2b00:100:10b::25/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:129 errors:0 dropped:0 overruns:111 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:11 Base address:0x9000

eth2      Link encap:Ethernet  HWaddr 00:04:AC:C5:43:49
          inet addr:192.168.76.254  Bcast:192.168.76.255  Mask:255.255.255.0
          inet6 addr: fe80::204:acff:fec5:4349/10 Scope:Link
          inet6 addr: 3ffe:2b00:100:10b::26/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:134 errors:0 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:10 Base address:0xb000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:200 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

---------------
See the tests:
---------------

root@gateway07 /root]# ping6 3ffe:2b00:0100:010b::24

PING 3ffe:2b00:0100:010b::24(3ffe:2b00:100:10b::24) from
3ffe:2b00:100:10b::25 : 56 data bytesFrom ::1: Destination unreachable: Address unreachable
From ::1: Destination unreachable: Address unreachable
From ::1: Destination unreachable: Address unreachable

--- 3ffe:2b00:0100:010b::24 ping statistics ---
5 packets transmitted, 0 packets received, +3 errors, 100% packet loss

[root@gateway07 /root]# ping6 3ffe:2b00:0100:010b::25

PING 3ffe:2b00:0100:010b::25(3ffe:2b00:100:10b::25) from ::1 : 56 data bytes
64 bytes from 3ffe:2b00:100:10b::25: icmp_seq=0 hops=64 time=170 usec
64 bytes from 3ffe:2b00:100:10b::25: icmp_seq=1 hops=64 time=145 usec
64 bytes from 3ffe:2b00:100:10b::25: icmp_seq=2 hops=64 time=143 usec

--- 3ffe:2b00:0100:010b::25 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.143/0.152/0.170/0.018 ms

[root@gateway07 /root]# ping6 3ffe:2b00:0100:010b::26

PING 3ffe:2b00:0100:010b::26(3ffe:2b00:100:10b::26) from ::1 : 56 data bytes
64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=0 hops=64 time=177 usec
64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=1 hops=64 time=145 usec
64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=2 hops=64 time=144 usec
64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=3 hops=64 time=147 usec

--- 3ffe:2b00:0100:010b::26 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.144/0.153/0.177/0.016 ms

[root@gateway07 /root]# ping6 -I eth0 3ffe:2b00:0100:010b::26

PING 3ffe:2b00:0100:010b::26(3ffe:2b00:100:10b::26) from ::1 eth0: 56 data
bytes64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=0 hops=64 time=190 usec
64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=1 hops=64 time=162 usec
64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=2 hops=64 time=163 usec
64 bytes from 3ffe:2b00:100:10b::26: icmp_seq=3 hops=64 time=164 usec

--- 3ffe:2b00:0100:010b::26 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.162/0.169/0.190/0.019 ms

-------------------------------------------------//---------------------

When I have only 1 interface the reply from the ping is:

"CONNECT: CANNOT ASSIGN REQUESTED ADDRESS"

------------------------------------------------//---------------------
Any idea/suggest of what to do?

Robson Lopes.

---

From: "Jim Fleming" <[email-masked]>
Date: Sat, 10 Aug 2002 09:45:29 -0500

----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
> modems, etc. will need to use tunneling?

You might find that the view on one-side of an IPv4-based DSL modem is
different from the view on the other side. From the consumer side, the DSL
modem gives them access to a large, IPv4, non-TOS, transport, which may
or may not be useful in passing packets from one side of the Next Generation (NG)
Internet, to the other. From inside that transport or cloud, the DSL modem
appears as a source or sink for IPv4 packets, and the goal is to route what
comes from that modem and route to that modem based on a limited number
of bits in the 160-bit IPv4 header. Between the DSL modem and the consumer's
network can grow equipment which is intelligent enough to process more of the
160-bits in the IPv4 header. At some point, the IPv4, non-TOS, transport can
be removed, when less and less traffic flows across that core, and instead is
routed around the edges via the layer of intelligence added between those DSL
modems and the user's network.

Tunneling may be a misnomer, isolation may be a better term. The existing, aging,
32-bit, IPv4, non-TOS, transport, will become more and more isolated and less
used, as usage of more of the bits in the 160-bit IPv4 header allow for packets
to be routed around that core, thus isolating it, and not tunneling thru it.

All this is happening now, the code is expanding and becoming more widely used.
http://www.netfilter.org/
With only 64-bits of the 160-bit IPv4 header used for addressing. There are plenty
of bits available to be used to layer around the legacy transport. That may likely
become the transport-of-last-resort for some devices, which will have direct (wireless)
access to more modern transports. The Next Generation Internet may tunnel back
thru the legacy Internet, but that would be good to avoid, because that is viewed as
a black-hole, with no hope.

Jim Fleming
2002:[IPv4]:000X:03DB

---

From: Robert Elz <[email-masked]>
Date: Sun, 11 Aug 2002 13:11:20 +0700

Date:        Sat, 10 Aug 2002 17:13:06 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | They probably need to be able to use tunneling, at least some of them.

I agree.   They're also one of the more likely users of unconfigured
tunnels (6to4) - they get one IPv4 addr, and offer IPv6 connectivity to
the end user, without requiring any other infrastructure to be operating.

This sounds like a good way to encourage more users of IPv6, so we shouldn't
be doing anything to make it more difficult to achieve.

  | But if they're designed so that they have problems with allocating 64 KB 
  | of memory, there's something about the design that's wrong IMO.

I disagree there.   I also disagree that being able to reassemble one
packet at a time is enough, just a small amount of IPv4 packet reordering
would blow away an implementation tried to reply upon that.

64K is too big.   I think 1280 is too small.   As I said in a message I
typed yesterday (but which would only have been sent an hour or so ago),
something in the 4K-8K region sounds to me like a size I think would cope
with any reasonable use (as you said, anyone sending 64K tunnelled
packets is probably DoSing you anyway - not certain, but probable) without
causing unnecessary IPv6 fragmentation requirements.

kre

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 11 Aug 2002 01:41:25 -0500

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>
> be doing anything to make it more difficult to achieve.

IP"NG" and IPv6 are not the same thing....

...as for encouraging usage of the Next Generation Internet, one way is to
make sure that address space is readily available, fairly allocated, and low-cost or free.
The I* society does not seem to approach things from that point of view.
Therefore, people are routing around it. That is the Internet way...

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

---

From: Vladimir Ksinant <[email-masked]>
Date: Mon, 12 Aug 2002 10:00:41 +0200

> the end user, without requiring any other infrastructure to be operating.

At the moment, my view is that SOHO routers mostly use tunneling in order to
connect to IPv6 networks (6to4 or configured tunnels). It may not be the
prefered way in the future, but it is often the only solution today.

> causing unnecessary IPv6 fragmentation requirements.

In DSL environments, ATM is often used in the access network. Then, the MTU is
often 9180. I think 9180 should at least be supported.

The MTU processing is tricky to implement today, especially when dealing with
several types of encapsulation. For instance in DSL environments, a SOHO router
may have to deal with PPPoE, IPSEC and 6in4 encapsulation. Having a fixed value
for 6in4 tunnel would make it easier.

Vladimir

---

From: Pekka Savola <[email-masked]>
Date: Mon, 12 Aug 2002 12:38:40 +0300 (EEST)

> would blow away an implementation tried to reply upon that.

If the alternative to reassebling one packet at a time is discarding all 
of those messages, perhaps some would consider it a reasonable tradeoff.

I wouldn't want to rely on it either, but it (kind of) satisfies a 
requirement, even if not properly.

---

From: [email-masked]
Date: Fri, 16 Aug 2002 20:06:02 +0900

>Please provide an analysis. I don't think this is the case.

	there was some research paper on IPv4 PMTU from aist-nara.ac.jp,
	i don't have a reference now.

>So I'm looking forward to your performance analysis.

	i think i have answered this (partially) in other emails.
	we are from very different assumption.

>instead send with 1280 bytes.

	requiring and maintaining PMTU for IPv4 for tunnel egress/ingress
	is different from requirement for PMTU for IPv6.  i disagree with
	the above logic.

>for the "upper IP layer" when an ICMP too big arrives from the "lower IP

	then what is the IPv6 link MTU for tunnel interface, when you don't
	have IPv4 PMTU information? (like for the very first packet to go out
	from the path)

>> 	i would really like to know how many of existing implementations follow

	*BSD and derived implementations don't (MacOS X at least, and probably
	JunOS and ExtremeWare).

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 19 Aug 2002 10:38:33 +0200 (CEST)

> MTU of these tunnels to 1280.

I think the right solution is to strongly recommend path MTU discovery
across the tunnel which would have the effect of only using IPv4 fragmentation
when the IPv4 path MTU is so small that a 1280 byte IPv6 packet can't be
carried without fragmentation.

But at least Itojun seems to think that doing path MTU discovery
for the tunnel case isn't worth while, and I definitely need to better
understand his point.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 19 Aug 2002 11:30:39 +0200 (CEST)

> 	we are from very different assumption.

I'm still looking for the answer.
What I'm trying to understand is why the "fragmentation considered harmful"
arguments (see  http://research.compaq.com/wrl/techreports/abstracts/87.3.html)
don't apply to the tunnel.

> 	have IPv4 PMTU information? (like for the very first packet to go out

You always have IPv4 PMTU information - if there isn't 
information from ICMP "too big" messages, then there is the interface MTU
for the outgoing IPv4 interface to bootstrap the process.
This is robust since the IPv4 path MTU can never exceed this interface MTU.

   Erik