[arin-ppml] IPv4 Depletion as an ARIN policy concern

[Chris Grundemann]

On Wed, Oct 28, 2009 at 10:50, Chris Engel <cengel at sponsordirect.com> wrote:
> Owen,
>
> Only addressing the portion of your post that deals with NAT....
>
>
> "First, I'm not really sure why you think NAT is necessary in IPv6.  It
> really isn't,
> and, it really isn't a good idea.  This isn't FUD, it's fact.  There's
> really nothing
> in NAT that helps anything except address conservation. Many people
> mistake
> the fact that NAT requires a stateful inspection gateway to function for
> security being provided by NAT.  The security is not provided by NAT, it
> is provided by stateful inspection"
>
>
> NAT is an EXTREMELY usefull tool to Network/System Admins. While it is certainly possible to function without it...the utility of it should not be underestimated. Here are examples of it's utility....
>

Just for fun; I have not worked on an enterprise network in a while
but a lot of this sounds a bit flimsy, even to me...

>
> 1) It acts as an insurance policy against FW misconfigurations.  Simply put for most businesses/organizations, the majority of devices on your network you do NOT want reachable by external traffic. While it is certainly possible to do that with assigning each device a public address and using FW rules to deny external access.... in the real world we know that FW misconfigurations are not that uncommon...particularly when you have complex series of rules at multiple individuals responsible for the creation and maintenance of them. NAT allows you to utilize private network addresses for ALL your internal devices.... which makes them unaccessable to external traffic BY DEFAULT...and then allows you to assign public IP's to ONLY those devices which are intended to be externaly accessible. Simply screw that up (i.e. purposefully taking action to NAT something that shouldn't be) then it is to make sure that NONE of your (possibly several hundred) FW rules inadvertantly opens a hole
>  to a device that it shouldn't.
>

Create a default rule in your firewall to deny all inbound
non-established connections to all internal devices and then poke
holes just to devices that need to be accessed externally.  This still
requires an active change to allow access and all internal devices are
unaccessible by default.

>
> 2) NAT allows Network Admins the flexability to organize thier own private address space and the assignment of IP's in ways that logicaly make sense to them. For example, on my own network.... by looking at the IP address I can instantly tell not only what network segment a device is on but what TYPE of address it is as well (Server, Workstation, Printer, etc). I don't believe I would be able to achieve the same results if I had to limit my assignments to the public address range that was provided by my ISP (even if they gave me as many addresses as I wanted).
>

If you can do this with 32 bits I do not see how you would be unable
to do it with 80 bits.

>
> 3) NAT allows you to abstract your internal infrastructure from the external services you present. This has alot of utility. For example, lets say I provide a service to external users on  (external IP) x.x.x.28   If I want to upgrade or change the device that provides that service NAT makes it very easy. I simply bring up the new device on it's own internal IP.... seperate from the internal IP assigned to the existing device.... and when I want to bring the new device into service all I need to do is switch the NATing on the FW and the new device is now instantly providing that service for external users. Nothing needs to change about how the external users access the device.... they may not even be aware that there was a change of device providing the service.... however all my internal references for both devices remain intact and distinct... which can be very important.  Without NAT, I would either have to bring the new device up on a new public IP and inform all external
>  users of how to access it (which may not even be possible) OR I would have to assign the device the existing devices IP address (and presumably give the existing device a new one) so that external access remained the same. However in that case I'd have to CHANGE ALL MY INTERNAL REFERENCES to the devices to make sure they were pointing at the right machines. That method would be far, far less efficient the utilizing NAT.
>

I would use a different three letters for that: DNS

>
> 4) Conservation of addresses has utility beyond just the sparcity/difficulty in acquiring the resource. It saves time and effort. Simply put, it is far easier to manage 12 public IP addresses then 300. I only need to worry about doing DNS/RDNS/FW Rules/Usage Tracking, etc for those 12. Without NAT I'm doomed to either do it for all 300 or constantly shuffling around the IP addresses assigned to individual NIC's..... either way spells doing alot more work then would be truely neccesary otherwise.
>

I don't understand this argument at all.  If you only have 12 IPs that
need external access, then you only have 12 IPs that need DNS/RDNS/FW
Rules/Usage Tracking, etc - whether the other 288 are rfc1918 IPv4
addresses or globally unique IPv6 addresses... ???

>
> These are just a few of the uses NAT has for me. I don't think I'm alone among Network Admins in saying it's a very usefull tool....regardless of how many IP's we were able to get assigned to us.
>
>

You are used to using it, habits are not all good.

with a smile,
~Chris

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Christopher Engel
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org