[151135] in North American Network Operators' Group
Re: Shim6, was: Re: filtering /48 is going to be necessary
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Mar 12 15:33:22 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl>
Date: Mon, 12 Mar 2012 12:30:32 -0700
To: Seth Mos <seth.mos@dds.nl>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 12, 2012, at 11:53 AM, Seth Mos wrote:
> Hi,
>=20
> Op 12 mrt 2012, om 18:09 heeft Owen DeLong het volgende geschreven:
>=20
>>> +
>>> Cheap End Users
>>> =3D
>>> IPv6 NPt (IPv6 Prefix Translation)
>>>=20
>>> Cheers,
>>>=20
>>> Seth
>>=20
>> I don't get the association between cheap end users and NPT. Can you =
explain how one relates to the other, given the added costs of =
unnecessarily translating prefixes?
>=20
> Well, to explain cheap here I would like to explain it as following:
>=20
> - The existing yumcha plastic soap box that you can buy at your local =
electronics store is powerful enough. About as fast in v6 as it does v4 =
since it is all software anyhow. It only gets faster from there.
>=20
Right.
> - Requires no cooperation from the ISP. This gets excessively worse =
where n > 1. Some have 8 or more for added bandwidth.
>=20
This one doesn't really parse for me. I'm not sure I understand what you =
are saying.
> - The excessive cost associated by current ISP practices that demand =
you use a business connection (at reduced bandwidth and increased cost). =
Somehow there was a decision that you can't have PI on "consumer" =
connections.
>=20
There's a big gap between PA without NPT and NPT, however. At the =
consumer level, I'd rather go PA than NPT.
For a business, it's a different story, but, for a business, PI seems =
feasible and I would think that the business connection is sort of a =
given.
> - Traffic engineering is a cinch, since it is all controlled by the =
single box. For example round robin the connections for increased =
download speed. Similar to how we do it in v4 land.
>=20
With all the same dysfunction. Further, in v4 land this depends a great =
deal on support built into applications and ALGs and a lot of other =
bloat and hacking to glue the broken little pieces back together and =
make it all work. I'm truly hoping that we can move away from that in =
IPv6.
I'd really like to see application developers free to develop robust =
networking code in their applications instead of having to focus all =
their resources on dealing with the perils and pitfalls of NAT =
environments.
> - It is mighty cheap to implement in current software, a number of =
Cisco and Jumiper releases support it. The various *bsd platforms do and =
linux is in development.
Well, I guess that depends on how and where you measure cost. Sure, if =
you only count the cost of making the capability available in the =
feature set on the router, it's cheap and easy. If you count the cost =
and overhead of the application bloat and complexity and the support =
costs, the security costs, etc. it adds up pretty quickly.
Sort of like it doesn't cost much to send spam, but, the cost of dealing =
with the never ending onslaught of unwanted email seems to go up every =
year. (Yes, I just compared people using NPT to spammers).
> - Not to underestimate the failover capabilities when almost all =
routers support 3G dongles for backup internet these days.
>=20
If you care that much about failover, PI is a much better solution.
I know my view is unpopular, but, I really would rather see PI made =
inexpensive and readily available than see NAT brought into the IPv6 =
mainstream. However, in my experience, very few residential customers =
make use of that 3G backup port.
> There are considerable drawbacks ofcourse:
>=20
> - Rewriting prefixes breaks voip/ftp again although without the port =
rewriting the impact is less, but significant. I'd really wish that =
h323, ftp and voip would go away. Or other protocols the embed local IP =
information inside the datagram. But I digress.
>=20
Yep.
> - People balk at the idea of NAT66, not to underestimate a very focal =
group here. All for solutions here. :-)
>=20
For good reason!
> - It requires keeping state, so no graceful failover. This means =
dropping sessions ofcourse but the people that want this likely won't =
care for the price they are paying.
>=20
True.
> Probably missed a bunch of arguments the people will complain about. =
It is probably best explained in the current experimental draft for NPt.
> http://tools.ietf.org/html/rfc6296
More than likely. Hopefully we can stop trying so hard to break the =
internet and start working on ways to make it better soon.
Owen
