User: Password:
|
|
Subscribe / Log in / New account

IPv6 NAT

IPv6 NAT

Posted Jul 21, 2011 21:14 UTC (Thu) by mstefani (guest, #31644)
In reply to: IPv6 NAT by akumria
Parent article: IPv6 NAT

How often have you renumbered networks?
It is a *pain*. Even on the network side which is the easiest part it is a lot of work (globally update your route filters, your firewalls, intrusion detection, monitoring). Even if you use dhcp there will be the odd device or "power user" that has a static address. Or worse there will be that "critical" in house application (of which the IT department doesn't know that it even exists) that has IP addresses hard coded all over the place. And that's only the technical part. The worst thing is that you move from a simple, well understood and local change that you can do in your standard maintenance window to a high impact widespread change. Think project management, business cases and justifications, coordination meetings, ROI discussions, etc. etc.

Oh, and your sales rep with the old provider very well knows those costs of changing IP addresses and will factor that in in his updated quote. And you'll grudgingly have to accept that the $500 that he charges you more per month provides you with the "better value".

So no, changing the IPs with the provider is the worst solution for an enterprise. You want to go either PIR or ULA. But of course for a hotel or coffee place that offers Internet access to their guests changing IP addresses with the providers is a viable solution.


(Log in to post comments)

IPv6 NAT

Posted Jul 23, 2011 13:29 UTC (Sat) by dsommers (subscriber, #55274) [Link]

Fair enough, renumbering networks can really be a pain. Agreed! Been there, done that - several times. But is that the fault of the network numbering? Or the management routines related to the network numbering?

I do consider NAT44 a nasty hack, but is pragmatic enough to see that David S. Miller is right. NAT won't go away. But sometimes I wonder why many prefers hacks to solve their issues, rather than to target the root issue. Make the tools you need/use tackle network renumbering better, instead of adding yet another layer of complexity in your core network. Tools will only have effect and do the job when you do the change. NAT66 can impact the network efficiency over a long time.

Regarding 'power users' or 'that "critical" in house application of which IT doesn't know about" ... for me this is just lame excuses why not to aim for a better solution. Yes, these things happens. But that those services or persons outside the IT dep. can be able to keep the IT dep. hostage like this, is just absurd in my eyes.

However, renumbering IPv6 addresses cannot be that easily compared to renumbering IPv4 nets. With IPv4, your netmask might be reduced, or you might have a /27 net which is moved and so on. So with IPv4 addresses you might need to change your addressing scheme, sometimes that's a very big change - *this* is painful. But with IPv6 only the prefix should change, where you most likely will have /48, /56 or /64 subnets. Which means you can keep the same IPv6 addressing scheme, you just need to change the prefix you have been assigned. In other word, this is be *less* painful.

And if I've understood NAT66 correctly, it is not really comparable to NAT44, as *port* NATing is not part of NAT66. NAT66 will just modify the IPv6 prefix. But I've not looked deep into the changes nfnat66 does. If it stays compliant to the RFC6296, I struggle to see the real effect of this "infrastructure hiding" which is claimed as the reason why to use NAT.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds