[arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it
cengel at conxeo.com
Tue May 17 14:33:59 EDT 2011
> > NAT isn't up to a matter of opinion. It is a matter of what the
> > Internet's design architecture is, and whether NAT can fit within
> > architecture. NAT breaks end-to-end reachability and transparency
> > between the edges of the Internet, which is why it doesn't fit the
> > Internet's design architecture.
> The same can be said of firewalls and spam filters and proxy servers.
> Guess what, VERY few people actually want "end-to-end reachability and
> transparency". The survey is out, privacy wins overwhelmingly. I don't WANT
> the inside of my network reachable and transparent to external users.
> Neither do the vast majority of endpoint network operators or individual
> users. We want to expose what we CHOOSE to advertise to the outside
> world....and keep everything else private....and we are willing to accept extra
> cost and complexity involved in running certain types of applications in order
> to do that.
> On the Enterprise side of things, of which I am very familiar, most
> don't tend to WANT decentralized application models (i.e. peer-to-peer).
> They want to mandate that applications have to go through a central known
> point in order to be able to function properly. That facilitates better
> monitoring and application of policy on said applications, as well as easier
> support, in many cases.
> I know EXACTLY what NAT does. It does EXACTLY what I INTEND it to
> do. That's true for most network admins I'm familiar with as well as with
> most private individuals. I work and am friends with alot of other folks in
> various positions in IT. Not a single one of the people I know DOESN'T run
> RFC-1918 space on their home networks....and address availability has very
> little to do with that. The internet isn't one completely homogenous
> entity....it's thousands upon thousands of individual networks.... each of
> them has their own rules that they play by. If you don't like the rules that an
> individual network plays by....guess what...don't go there...chances are you
> aren't welcome.
> Christopher Engel
> (representing only my own views)
> None of what you just said you want, has anything to do with NAT. This is
> what leads people to believe you don't know what NAT does, even while you
> yell that you do.
Let's see NAT allows me to abstract the internal architecture of my network from it's externally advertised presence....
- With many:1 NAT, I can have any number of devices appear to come from a single IP address. None of those devices are addressable externally, unless they've created an entry in the NAT devices state table to an external address. Thus none of those devices are reachable from external sources even if filtering rules would otherwise allow such traffic.
- With 1:1 NAT, I can advertise a particular IP on the external interface of the NAT device regardless what device(s) are actually providing that service, where they are located in the topology of my network or my internal addressing scheme. I can change any of that around internally at any time without needing to do anything with that address on my internal infrastructure and such change will be entirely invisible to the external advertisement of that service.
- With 1:1 NAT with PAT, I can even have entirely separate devices provide different services on the same external IP without an external source needing to know any of the details about that (i.e. server A provides SMTP, Server B provides HTTP..... to the outside world they both sit on the same IP).
- With NAT I can change ISP's at will without needing to renumber anything internally. Conversely I can change internal addressing schemes without needing to worry about messing around with external advertisement of services.
Have I missed anything significant about NAT's function?
The fact that NAT also makes it much more difficult for certain peer-to-peer apps to function doesn't happen to mean squat to me, since I have no desire to use those apps in the first place....and the fact that I may need to take some extra steps to allow them to function is nothing but a bonus to me.
As far as CGN, that's a discussion that belongs between the service provider and their customers. If the vendor want to provide it and the customer wants to buy it and is happy with the service it provides them....it REALLY is no-one else's business to tell them they shouldn't. If that makes an application vendors life more difficult....well no-one is holding a gun to their head telling them they have to support their applications functioning through NAT. You can tell your customers that you don't support NAT if you want....just like a website author can refuse to support certain browsers. If your customers are choosing NAT over your application....well that's your problem....welcome to the free market.
FWIW, I'm still waiting for some-one to explain exactly how any of this has jack-all to do with number resource policy?
(representing only my own views)
More information about the ARIN-PPML