IPV6 Addressing

[Lee Smitherman]

Hi,

Does anybody have any good links to documents/or an  explanation to explain why we shouldn't use ULA addressing in the enterprise? With RFC 1918 addresses I sleep better at night knowing that even without a firewall, no one on the internet can route to my 10/8 network(unless there is a NAT of course). 

Now with IPV6, were talking about obtaining a /32 address range.  However why not use ULA instead of Global Unicast?  We will still have a DMZ/Internet services zone which will use Global Unicast addresses, but why would I want my office or Dev environments ROUTABLE to the internet? I don't see any benefit.  If any device needed access to the internet in these zones it would use a proxy or talk via a service on the Internet Services zone.

Thanks all, Lee

[sylvain.munaut · Accepted solution]

Well, there is no down sides to having global IPs.

I assume you want your machines to have internet ipv6 connectivity. So if you want to not have public IPs locally you have two choices :

 - You use NAT-PT to translate an entire prefix to and ULA prefix. But then whatever global prefix you use, any one on the internet can use the global prefix + the last 64 bits of the local address to address any of the local machines

 - You use some kind of overloading like on IPv4 to have a single outgoing IPv6.

In both cases for best practice, you still need a stateful firewall that will keep track of the sessions and work independently of what's described above.

But in either case:

 - There is no real security benefit. The stateful firewall will ensure the same level in both cases

 - There is additional load on the router, because the router needs to rewrite the packet header (and update checksum) rather than just forward it.

 - If any protocol (like SIP / IPSec or whatever) has some hidden IPs inside the packet payload, then you'll need the same kind of workaround and hacks as IPv4 NAT needs ...

So I'd say : embrace global IPs and let firewall ensure security and don't rely on some NAT for this.

[Lee Smitherman]

Thanks for the reply,

but Im still wondering..... why would I want internal devices that are NOT on a DMZ to be internet addressable, by design they will not talk directly to the internet?  I would`nt have to nat anyway as my DMZ devices, such as proxy servers, mail servers etc will have Global IP`s.

With IPv4 RFC1918, some silly person adds a firewall rule by mistake, and allows partial or all traffic on the firewalls(seen this done), my internal network is still safe as no one can route, but if that was IPv6 the world is a hackers oyster.

 Lee.

[sylvain.munaut]

By "Not talk directly to the internet" ? You mean no outgoing connections to the internet either ? Because yeah sure, if they don't need to access the internet at all, it doesn't matter much.

But if they have outgoing connections, you'll need one of the two solutions above.

 - NAT-PT being stateless, if you screw up your firewall, you'll have the same issue as with global IPs.
 - IPv6 NAT overloading : Does that even exist at all ? I've never looked ...

But as a side note, you shouldn't let silly person manage your firewall :p  Because without a good rule, if your ISP is nasty (or compromised), it could very well send you packet with a RFC1918 destination IP and the stateful firewall is the only thing protecting you there.

[James Leinweber · Accepted solution]

On the bright side, the whole reason that the site-local fec0::/10 IPv6 addresses which were like RFC-1918 style IPv6 addresses were deprecated in favor of the unique local fc00::/7 IPv6 addresses was in the expectation that people would want to use them.  Your scenario of hosts with almost all communications being internal and talking out only via application proxy servers is the main one they are designed for.  Surprisingly, the PCI-DSS people haven't noticed the existence of IPv6 yet; I have to wonder if they will want servers on ULA when they do.

However!  There is not, officially, any standardized NAT66, and the IETF is strongly resistant to defining any, as they are hoping to reclaim the end-to-end character of the 1980's Arpanet, see e.g. RFC-5902 for a discussion of the pro's and con's.  The mere existence of 500M IPv4 NAT devices in the middle of the Internet is a horrible drag on protocol innovation, and the ability to scale the IPv6 internet to cope with billions more devices and thousands of times the current traffic loads demands an ability to do protocol innovation.   The implication is that users of ULA's need to be really sure that the hosts don't need global connectivity; this is likely for factory floors and backend servers, but wrong for office desktops.

Cisco, of course, has experimental IPv6 prefix translation (RFC-6296), but that's mostly aimed at making it easier to connect an IPv6 PA subnet to multiple ISP's without having to give client hosts multiple global addresses from different prefixes simultaneously.  In multivendor environments you can't assume all the devices will cooperate with this sort of thing, and it's still likely to break all of the stuff that a regular NAT would break, as described in RFC-4966 moving NAT-PT (the main NAT46 proposal) to historic status.

The main difficulty with using ULA's in practice is that many IPv6 software stacks are buggy with regard to address selection in the presence of both ULA and global unicast addresses on the same interface.  So the ULA-only hosts are OK, but the rest of your network breaks.  Plan on needing RFC-6724 compliant OS's, i.e. really recent ones, and having to tune your prefix policy tables if you are going to be mixing them.

-- Jim Leinweber, WI State Lab of Hygiene

[Lee Smitherman]

Thanks all,

Some food for thought there.  It seems we maybe have to think differently with how we deploy IPv6 forgetting quite of bit of what we have learned over the years with IPv4.  It also stikes me IPv6 is still maturing with a long journey in front of it, and as you mentioned it still seems procol stacks may also need time to develope in the handling of all these different address types.

Still quite a lot to think about. But I guess Sylvain is correct.  We should embrace Global IPs with the different way of thinking, however still think there are alot of people out there still unsure which way to go.

Lee.

[James Leinweber]

On the WAN side, both IPv4 and IPv6 are packet-switched, next-hop routed, best effort delivery designs, so the main differences are fairly small ones: that v6 uses bigger addresses, doesn't fragment at intermediate routers, and uses extension headers instead of options.  On the LAN side, the replacement of ARP by ND and new DHCPv6/RA entwining makes things noticeably different.  But threat models, countermeasures, and operations aren't changed all that much, except for firewall and network monitoring tweaks to cope with all those transition technologies which want to tunnel stuff.

In terms of network design, the hardest thing for me was getting out of the scarcity mindset, and designing my v6 subnets and routing from scratch, without regard to existing v4 subnets, vlan tags, and other such ephemera. In the 1980's class A v4 terms, having the usual v6 /48 (or larger) is like being MIT.  The key takeaways were to design for resilience against expected changes like new sites or increased segmentation, and align on 4 bit nibbles for easy documentation and reverse DNS.  The standard advice to start numbering subnets in the middle and work outwards in both directions is also good.  It turned out that after 3 iterations of v6 design got me to something I actually liked - routing /52's, firewall boundaries on /60's, everything /64 at the vlans - that it fed back into my v4 design, where I was able to make some corresponding improvements which significantly simplified my v4 NAT and IPsec issues.

I'm with Sylvain - get on natively routed, globally scoped v6 addresses as soon as possible, and don't look back.  Facebook is going to be nearly 100% v6 internally by the end of the year, because it's so much easier for them to manage it in large scale deployments than legacy v4.  The rest of us should take note!

-- Jim Leinweber, WI State Lab of Hygiene

[irfan1729]

Hi jeleinweber, 

Everywhere I read that using ULA in enterprise along with NAT66 is not recommended. I accept that. But what is the solution for multihoming without ULA or Provide Independent address ? 

[James Leinweber]

Unfortunately v6 has no magic bullet to solve the multihoming challenge, and with the desire to avoid NAT66 it may be even worse than in v4.  You have 4 or 5 main options, all with different disadvantages.

* find an ISP that offers you redundant paths for its PA prefixes.   This may not offer the level of uplink redundancy and traffic engineering you desire, but it is simple.

* Be big enough and complicated enough to get and run PI prefixes.  This isn't much help to small organizations that need high availability and don't have BGP expertise.

* Let clients have two global addresses per interface, one from each ISP.  This makes the traffic engineering way more challenging, since it distributes it to all of the clients.  Plus it may require tuning the prefix policy tables on those clients to stabilize your internal communication on a single preferred prefix.  But it uses only standard technologies and only global addresses.

* Grit your teeth and use a native global prefix with ISP A, but use Cisco experimental prefix subtitution to rewrite to global prefix B with ISP B.  This limits the traffic engineering issue to your border, but brings back all the protocol breakage and asymmetric path hassles you'd find with any NAT66-style solution, plus it mortgages your future to a technology which isn't standardized.

* Use a single global prefix with ISP A, and use an overlay routing protocol such as the experimental LISP to have ISP B provide a backup route.  In effect, you are converting PA space into PI space.  This could be pretty good solution, but only if your gear and ISP B both support it and you are willing live with nonstandardized stuff in your critical paths.

Two of the biggest IPv6 challenges are the lack of interoperability with the legacy v4 internet in a era of v4 address exhaustion, and multihoming.  These are not perfectly solved.

-- Jim Leinweber, WI State Lab of Hygiene