2010-07-23

IPv6 and the enterprise of tomorrow(ish)

One of the great promises of IPv6 has been to get rid of NAT, no more will IT do RFC1918 and NAPT to single public IP. But how is IPv6 going to accomplish this, what is the magical toggle for it? Let's get disappointed.

Some devices, like Cisco IOS allow you to configure IPv6 prefix as 'macro', so you could tell that macro 'ME' is 2001:db8::/32 and everywhere where you write IPv6 address, you use macro 'ME'instead. So in theory, when your prefix changes, you simply change the macro. So the great renumbering benefit is ability to always get same size network. But of course this was true for IPv4 too, you got the network size you needed. Why isn't this utilized? Because enterprises don't have one Cisco IOS devices, they have plethora of devices from different vendors, firewalls, slb, ips, ids, servers, OSS systems and so forth, you'd still need to go in all of these to change the 'macro', not all devices even have the concept and quite frankly no enterprise of non-trivial size will even know without months of work _where_ and _what_ will need to be changed for renumbering to be successful. I know industry professionals who've done renumbering costing MEURs in single company. So in practice IPv6 gives you no benefit in renumbering, renumbering always was easy for trivial network and always hard for non-trivial network and will continue to be so.

So how will enterprises run IPv6? Getting PI/ASN is actually bit harder, as you MUST be dual-homed, while many enterprises just want PI/ASN to have ability to change operator. There has also been visibility problems with /48's, but these will be remedied in due time, when even rest of the people realize there will not be magical new protocol in IPv6 for address mobility. I'm quite certain that IPv6 will be deployed exactly like IPv4, instead of RFC1918 you will use RFC4193, but with the twist that most companies will find that PRNG always returns '0', so that they will get beautiful short fd::/48 block, and lot of cursing in M&A, as with RFC1918.

Companies will NAT this RFC4193 to external provider provided IP block, no renumbering needed, you can still change operator without complex and expensive renumbering. But there is something we will win, we can easily do 1:1 NAT, instead of NAPT, which has great many benefits, no more will you need session logging to comply with legal requirements, you will also get mostly working end-to-end connectivity, apart from protocols which carry address in payload.

For those few who have been bitten by RFC1918 in M&A and who view that IPv6 address memorability and beauty is less valuable than the many hours of pain RFC1918 in M&A causes, here is one-liner to generate random RFC4193:

# ruby -e 'p ("fd"+rand(2**40).to_s(16)).scan(/.{1,4}/).join(":")+"::/48"' "fdbf:49be:e67d::/48" #
Maybe it should tuned with RFC2777 with NASDAQ as seed, so that your client can be sure you didn't give preferential treatment to another client to whom you issued much more beautiful network. Blaming the stock market can be very satisfying.

No comments:

Post a comment