<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
    - 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</blockquote>

<div><br>Yes, double the work is security. Screen doors and such on a Vault.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
  - 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.<br>

</blockquote><div> </div><div>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.<br>

 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
   - 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).<br>

</blockquote><div><br>This does *not* require full NAT. There are a great many services that do this, look into load balancing for a start.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


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

</blockquote><div><br>You double posted this one point, to try to make it look like NAT has more usefulness. See above point on 1-1 NAT <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


<br>
Have I missed anything significant about NAT's function <br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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.<br>

</blockquote><div><br>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.<br>

 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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.<br>

</blockquote><div><br>Actually, that is what protocol designers and stewards do. They design standard protocols for intercommunication. It's part of the job description.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


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

 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">
Christopher Engel<br>
(representing only my own views)<br>
</div></div></blockquote></div><br>