[arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it

[Blake Dunlap]

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


Yes, double the work is security. Screen doors and such on a Vault.


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

I like 1-1 NAT, it is the one case that makes sense, provided it is
complete, but you are speciously excluding the requirement of external
advertisement needing change either way, you still have to update all
external services to use the new external addressing. Also, the goal with
this is multiple addressing in IPv6, not external NAT with a single address
pool. Different, not gone.


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

This does *not* require full NAT. There are a great many services that do
this, look into load balancing for a start.


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

You double posted this one point, to try to make it look like NAT has more
usefulness. See above point on 1-1 NAT

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

It's not all about you. This is standards development, not your network
development. All needs must be considered. It is much less work for you to
do things properly, than to force the rest of the world to do a lot of work
so you can be lazy.


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

Actually, that is what protocol designers and stewards do. They design
standard protocols for intercommunication. It's part of the job description.


>
> FWIW, I'm still waiting for some-one to explain exactly how any of this has
> jack-all to do with number resource policy?
>
>
How doesn't a protocol designed for number resource (and only number
resource) over-subscription not have anything to do with number resource
policy?


> Christopher Engel
> (representing only my own views)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110517/39ad5b6b/attachment.htm>