Addressing is a big deal with ipv6. For people coming from ipv4, wrapping one’s head around ipv6 addressing can be hard.
This post is a response to the comments discussion in the Standalone Sysadmin blog post urging uptake of ipv6. In the comments, we see people concerned with the fact that ipv6 addressing gives a public, routable address to every last PC, server and printer – and suggestions that this could be resolved by deploying ULA (Unique Local IPv6 Unicast Addresses) per RFC4193 – it’ll be just like your current RFC1918 space!
Actually, it won’t. ULA is not the solution. Every machine that needs access to the Internet will be on a routable, public address. That’s only scary from a management perspective – and that’s the TL;DR. Read on for the justification of that statement.
ULA addressing is addressing per RFC4193. It is different from RFC1918 in some ways, and it shares a few characteristics with RFC1918.
ULA is different from RFC1918 in that the addresses are meant to be unique. This is achieved by using a Pseudo-Randomly derived “Global ID” as part of the site prefix. The RFC goes into detail – at length – as to how that PRNG generation is supposed to work. In practice, you still have a very small chance of collision. ULAs were never meant to be registered in any way – SixXS gives you a registration page anyway, just to avoid that small chance of overlap.
ULA is similar to RFC1918 in that ULA address space is “not expected to be routable on the global Internet”. This translates to a requirement to filter out ULA space at the BGP border router, and for all exterior routing protocols to “ignore receipt of and not advertise” ULA space. See section 4 of the RFC for details.
ULA is different from RFC1918 in that ipv6 does not offer NAT (though arguments are being put forth that ipv6 NAT may be beneficial). Wait, I hear you say, how is that a difference between ULA and RFC1918? That’s a difference between ipv6 and ipv4! To which I say: True enough. That difference impacts how these addresses can be used, would be a better way to put it. You can put a PC on an RFC1918 address, and it can still get to the Internet, through a Many-to-One source NAT. You can put a server on an RFC1918 address, and it will still be reachable through a static one-to-one NAT. You cannot do any such thing with a machine that has only a ULA address. That machine will be unable to get to the Internet, and vice versa.
[Edit 2011-02-03: NAT is with us again, in the form of NAT66. Note that it is designed to translate one /48 prefix into another /48 prefix. I am still not a great fan of this idea, as the application challenges remain. If you’ve ever tried to NAT h.323 or sip and found that your firewall doesn’t _quite_ speak your version of that protocol, you know what I speak of. Designing an IPv6 network without the need for NAT66 is, in my opinion, far preferable]
That doesn’t mean that ULAs are useless. They are meant to allow local machines to communicate locally – combined with the idea of DHCP-PD, this can be a way to handling renumbering. RFC4864 was written specifically to address concerns about manageability of local IPv6 space.
Let me speak to this new ipv6 world where every machine has a routable public address from a few perspectives.
Doug Maxwell says:
1) It’s always routing
2) No NAT is good NAT
3) Sh^t don’t work
NAT is the bane of your applications. If you’ve ever tried getting SMB or VoIP through NAT, you know what I speak of. Any application that references an IP address in L7 – whether that’s a good idea or no, it happens – is going to be hurting. Many-to-one NAT will be hurting P2P applications, which ipv4 proposes to resolve by using port forwards, which don’t scale. It’s a nightmare.
Interestingly enough, the biggest boost to public (as opposed to governmental) ipv6 uptake has been from a popular p2p application starting to support ipv6. Go figure.
No NAT is a good thing from an application perspective. It also helps to make inter-partner VPNs so much easier to set up.
Repeat after me: NAT is not a security solution.
It may be fairer to say: The security gained by many-to-one source NAT is a side effect.
It is your firewalls’ (perimeter and internal, if you have any internally) job to control which traffic may reach your internal network. If your rulebase looks like this:
Internal-LAN to Any on http/https/ping : Allow Any to Internal-LAN on Any : Deny
then your Internal-LAN is going to be just as secure on public space – ipv4 or ipv6 – as on private space. If you can’t get to it, you can’t get to it, no matter whether the address is routable.
You can also think about this from a server perspective: Say you have a web server on 192.168.1.1, and you NAT it to a public address. Your firewall rulebase will look like this:
Any to Public-WWW on http: Allow
Whether this Public-WWW address is now going to be NATed to 192.168.1.1, or just routed to the server, makes absolutely no difference from a security perspective.
Management perspective – “renumbering needs work”
Managing your address space needs considerably more forethought in ipv6 than in ipv4. ipv6 is new now, but it’ll be an “old hat” before you know it – and then you’ll be shopping around for the best deals on ISP connectivity, just as you do now with ipv4. The idea of needing to renumber absolutely everything when you switch ISPs is not pleasant. RFC4864 has a few suggestions on how to handle that – none of which may be really workable in your situation.
There is one “easy” solution to this mess: Get your own site address space(s) assigned to you by your local RIR, whether that’s ARIN or somebody else. Then use that space in perpetuity, regardless of the IPS(s) that provide your bandwidth. Unfortunately, the ipv6 early adopter days are over, and the ipv4-has-run-out days are not yet here. As a result of which, ipv6 eligibility is tied to ipv4 eligibility: You can get your own ipv6 address space if either a) you already own ipv4 space and can show that you use it efficiently or b) you are eligible to receive ipv4 space. As of early 2010 looking at ARIN rules, that means you’d have to be eligible for an ipv4 /22, and currently use a /23 worth of ipv4 public space efficiently. That’s a tough hurdle to jump over.
As a manager, you’ll want to have your people fight tooth and nail for that directly assigned space. It is the by far most cost-effective and most lasting solution to renumbering concerns.
If that is not an option, and you need ipv6, you need to pay a lot of attention to IP Address Management. The old “spreadsheet kept by the IT dept” method will no longer work. What you’re looking for is strong asset management – DHCP, DNS and ACLs populated by a backend asset database. The marketplace will create these solutions as ipv6 uptake gets under way. Infoblox is one company to watch in this space, though they do not tie into ACL generation.
The best advice I can give is to plan for a renumbering scenario if you cannot get your own address space. Evaluate IAM solutions and network management solutions. Have your people run through a dry-run of renumbering to uncover areas that may have been overlooked, such as application settings.
A few basic configuration choices will make renumbering easier:
– Use DHCPv6 to assign addresses to not just workstations, but also servers. Servers will have their address bound by MAC address – this is where your IAM comes in handy
– Use DNS in your configurations wherever possible – avoid the use of static addresses where feasible and where performance allows it
– Use a network management application that allows you to change the addressing and configuration of your routers and switches quickly and easily
I am not a big fan of DHCPv6 prefix delegation, outside of a provider-to-consumer relationship, that is. DHCPv6 prefix delegation is meant to work with stateless auto-configuration, for routers that have one upstream link and one LAN link. Great in a provider environment, not so great in an enterprise environment.
Lastly, let me share some useful resources: A draft RFC proposing a renumbering methodology without the “flag day”, and a whitepaper from January 2009 looking at IPv6 renumbering, the current challenges and options.