[126423] in North American Network Operators' Group

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

Re: ipv6 transit over tunneled connection

daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri May 14 18:54:53 2010

From: Owen DeLong <owen@delong.com>
In-Reply-To: <AANLkTik_rbGbwaLCV4QR-K0C2ADQLRReY4qM_ZlYxGFW@mail.gmail.com>
Date: Fri, 14 May 2010 15:50:28 -0700
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On May 14, 2010, at 11:57 AM, Christopher Morrow wrote:

> On Fri, May 14, 2010 at 2:29 PM, Franck Martin <franck@genius.com> =
wrote:
>> I said somewhere in here... wierd quoting happened.
>> On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy =
<mulitskiy@acedsl.com>
>> wrote:
>>> Hello,
>>>=20
>>> We're in the early stage of planning ipv6 deployment -
>>> learning/labbing/experimenting/etc. We've got to the point when =
we're
>>> also planning to request initial ipv6 allocation from ARIN.
>>> So I wonder what ipv6 transit options I have if my upstreams do not
>>> support native ipv6 connectivity?
>>> I see Hurricane Electric tunnel broker BGP tunnel. Is there anything
>>> else? Either free or commercial?
>>=20
>> 1) see gblx/ntt/sprint/twt/vzb for transit-v6
>> 2) tunnel inside your domain (your control, your MTU issues, your
>> alternate pathing of tunnels vs pipe)
>> 3) don't tunnel beyond your borders, really just don't
>>=20
>> tunnels are bad, always.
>> -chris
>>=20
>> I see so many times, that tunnels are bad for IPv6, but this is the =
way IPv6 has been designed to work when you
>> cannot get direct IPv6. So I would not say tunnels are bad, but =
direct IPv6 is better (OECD document on IPv6
>> states the use of tunnels).
>=20
> Tunnels promote poor paths, they bring along LOTS of issues wrt PMTUD,
> asymmetry of paths, improper/inefficient paths (see example paths from
> several ripe preso's by jereon/others), longer latency. If the tunnel
> exits your border you can't control what happens and you can't affect
> that tunnels performance characteristics. it's 2010, get native v6.
>=20
I will point out that most of these issues apply to 6to4 and Teredo =
auto-
tunnels and not as much to GRE or 6in4 statically configured tunnels.

There is a juniper bug which makes PMTU-D a problem if your tunnel
is Juniper<->Juniper.

>> If the issue with tunnel is MTU, then a non-negligible part of IPv4 =
does not work well with MTU different of 1500.
>> With IPv6 we bring the concept of jumbo packets, with large MTU. If =
we cannot work with non standard MTUs in
>> IPv6 tunnels, how will we work with jumbo packets?
>=20
> a non-negligible part of the ipv6 internet doesn't work at all with
>> 1280 mtu... due to tunnels and some other hackery :( jumbo packets
> are a fiction, everyone should stop 10 years ago believing they will
> ever work end-to-end between random sites.
>=20
Jumbo packets do work end to end in some random cases and PMTU-D
works in most others. All of the tunnels I am using have at least a 1280 =
MTU,
so, I'm not sure why you would think a tunnel wouldn't support 1280.

Owen



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