Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Geoff Huston's talk at NANOG53



On Sat, May 11, 2013 at 2:41 PM, Chuck Anderson <cra at wpi.edu> wrote:
> On Sat, May 11, 2013 at 02:48:26AM -0400, Tom Metro wrote:
>> He lost me, though, we he started to describe how they would use the
>> IPv4 to IPv6 transition points like a toll bridge and extract money from
>> content providers. Doesn't tunneling provide a bypass to reach
>> competitors who can provide that transition point?
>
> Tunneling isn't really a viable solution, since it will always perform
> worse than native connectivity.  You need "rendez-vous" points outside
> of the NATs in order to work around the fact than NATs break the
> end-to-end model of the Internet.  If those rendez-vous points and
> tunnel endpoints aren't co-located along the native traffic route, you
> are introducing latency and possible bottlenecks in the path.

I think one can see tunneling as a form of
encapsulation/de-encapsulation and that is certainly going to add
additional latency.   However, I think any bottleneck/throughput
issues are because when people do the kind of tunneling we are
talking about here (IPv6 in IPv4 for example); they are just doing it
wrong.   As I see it, virtually all IP packets are "tunneled" inside
of Ethernet packets for at least part of their flight time and I've
yet to hear people complain about it.   We even connect routers (in
campus environments) with Ethernet cabling/protocols and everything
seems to work fine.   I would argue that is because we have spent the
modest amount of silicon required to do IP<->Ethernet "tunneling"
well, but IP* in IP* tunneling hasn't gotten that kind of treatment.
I think that if it did, the throughput issues would quickly disappear.

> You are
> also lowering the MTU when tunneling which can cause blackholes when
> combined with PMTUd failure.

When can we actually stop worrying about people running obsolete
networks?   If an ISP told you that they could only use class-based
IPv4 routing with their equipment, would you redesign your network in
order to allow them to peer with you?
Why should we care anymore if somebody's network is so bad that it
can't do PMTU correctly.   This feels kind of like the "all the world
is a VAX" from the early days of Unix programming.  It's past time to
give it up.

Bill Bogstad



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org