Shim6, was: Re: filtering /48 is going to be necessary

Mon Mar 12 19:30:32 UTC 2012

On Mar 12, 2012, at 11:53 AM, Seth Mos wrote:

> Hi,
> 
> Op 12 mrt 2012, om 18:09 heeft Owen DeLong het volgende geschreven:
> 
>>> +
>>> Cheap End Users
>>> =
>>> IPv6 NPt (IPv6 Prefix Translation)
>>> 
>>> Cheers,
>>> 
>>> Seth
>> 
>> 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?
> 
> Well, to explain cheap here I would like to explain it as following:
> 
> - 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.
> 

Right.

> - Requires no cooperation from the ISP. This gets excessively worse where n > 1. Some have 8 or more for added bandwidth.
> 

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.
> 

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.
> 

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.
> 

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:
> 
> - 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.
> 

Yep.

> - People balk at the idea of NAT66, not to underestimate a very focal group here. All for solutions here. :-)
> 

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.
> 

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