[153297] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: IPv6 day and tunnels

daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jun 4 18:11:02 2012

From: Owen DeLong <owen@delong.com>
In-Reply-To: <4FCD2803.9070206@ttec.com>
Date: Mon, 4 Jun 2012 15:08:02 -0700
To: Joe Maimon <jmaimon@ttec.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Jun 4, 2012, at 2:26 PM, Joe Maimon wrote:

>=20
>=20
> Jeroen Massar wrote:
>=20
>>=20
>> Tunnels therefor only should exist at the edge where native IPv6 =
cannot
>> be made possible without significant investments in hardware and or
>> other resources. Of course every tunnel should at one point in time =
be
>> replaced by native where possible, thus hopefully the folks planning
>> expenses and hardware upgrades have finally realized that they cannot
>> get around it any more and have put this "ipv6" feature on the list =
for
>> the next round of upgrades.
>=20
>=20
> IPv4 is pretty mature. Are there more or less tunnels on it?
>=20

There are dramatically fewer IPv4 tunnels than IPv6 tunnels to the best =
of my knowledge.

> Why do you think a maturing IPv6 means less tunnels as opposed to =
more?
>=20

Because a maturing IPv6 eliminates many of the present day needs for =
IPv6 tunnels which
is to span IPv4-only areas of the network when connecting IPv6 end =
points.

> Does IPv6 contain elegant solutions to all the issues one would resort =
to tunnels with IPv4?

Many of the issues I would resort to tunnels for involve working around =
NAT, so, yes, IPv6
provides a much more elegant solution -- End-to-end addressing.

However, for some of the other cases, no, tunnels will remain valuable =
in IPv6. However, as
IPv6 end-to-end native connectivity becomes more prevalent, much of the =
current need for
IPv6 over IPv4 tunnels will become deprecated.

> Does successful IPv6 deployment require obsoleting tunneling?

No, it does not, but, it will naturally obsolete many of the tunnels =
which exist today.

> Fail.
>=20

What, exactly are you saying is a failure? The single word here even in =
context is
very ambiguous.

> Today, most people cant even get IPv6 without tunnels.

Anyone can get IPv6 without a tunnel if they are willing to bring a =
circuit to the right place.
As IPv6 gets more ubiquitously deployed, the number of right places will =
grow and the cost
of getting a circuit to one of them will thus decrease.

> And tunnels are far from the only cause of MTU lower than what has =
become the only valid MTU of 1500, thanks in no small part to people who =
refuse to acknowledge operational reality and are quite satisfied with =
the state of things once they find a "them" to blame it on.

Meh... Sour grapes really don't add anything useful to the discussion.

Breaking PMTU-D is bad. People should stop doing so.

Blocking PTB messages is bad in IPv4 and worse in IPv6.

This has been well known for many years. If you're breaking PMTU-D, then =
stop that. If not, then you're not part of them.

If you have a useful alternative solution to propose, put it forth and =
let's discuss the merits.

> I just want to know if we can expect IPv6 to devolve into 1280 =
standard mtu and at what gigabit rates.

I hope not. I hope that IPv6 will cause people to actually re-evaluate =
their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D =
allows not only 1500, but also 1280, and 9000 and >9000 octet datagrams =
to be possible and segments that support <1500 work almost as well as =
segments that support jumbo frames. Where jumbo frames offer an =
end-to-end advantage, that advantage can be realized. Where there is a =
segment with a 1280 MTU, that can also work with a relatively small =
performance penalty.

Where PMTU-D is broken, nothing works unless the MTU end-to-end happens =
to coincide with the smallest MTU.

For links that carry tunnels and clear traffic, life gets interesting if =
one of them is the one with the smallest MTU regardless of the MTU value =
chosen.

Owen

>=20
>=20
> Joe



home help back first fref pref prev next nref lref last post