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.
ULAs
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.
Application perspective
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.
Security perspective
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.
Thorsten on (mostly) Tech 
I’m guessing that the proponents if IPv6 haven’t been in this game long enough to have worked on pre NAT-router LANs.
NAT didn’t just solve the address-pool limits, it eliminated a lot of very awkward situations which arose when internal addresses HAD to be public. Frankly, I don’t see how ipv6 is going to be any less awkward than all-public ipv4 in this respect. In some ways it could be a darn sight more awkward.
It’s the same old story; allow enough time for a bad idea and a lesson learned from it to be forgotten, and you can bet that someone somewhere reinvents it.
The awkwardness I am familiar with is that of NAT breaking protocols which, for better or worse, embed layer 3 information in layer 7. I just had a case this last week: H.323 VoIP, NATed, and H.323 Video, un-NATed, going through the same Cisco firewall. VoIP only functions with H.323 fixup (ALG), because of NAT; Video breaks with H.323 fixup because the Cisco ALG did not play well with this particular vendor’s H.323 implementation. For protocol and application support reasons, I would much prefer a network without NAT.
That said, I am interested to hear what challenges you anticipate this will bring. What is the “awkwardness” you refer to?
And don’t forget that while the use of an ALG may have worked for you, it sometimes fails miserably and breaks the protocol more than it fixes it. And what about TLS? Once it sees widespread use, no ALG will be able to intercept the traffic and fix it. Say hello to incredibly complicated NAT traversal techniques and hence low interoperability.
i want to know how i do configration for renumbering router in ipv6
can any one help me please……….
i need configration for renumbering router in ipv6
help me please
Renumbering happens automatically – in theory. You configure the new IP address on the router, and the router sends advertisements to all the computers on your network.
However, this only works if you use SLAAC. That was a good idea, but it doesn’t integrate with anything else (no DDNS, in particular), so today many people recommend not to use SLAAC outside of the SOHO market, but rather stateful DHCPv6 or, for servers, static IP addresses.
When you use DHCPv6 or static IP addresses, renumbering works exactly as it did with IPv4; you have to manually change the DHCP server or the static IPs.
No matter which mechanism you use, you always have to update all the network infrastructure that may reference these IP addresses:
– Firewall rules
– DNS
– inventory databases
– Any applications that don’t use DNS but IP addresses.
In the end, the automatic renumbering was a nice idea, but it just doesn’t work well enough to be of practical use in the very settings it was created for.
The other option you have is to use NAT. Yes, I know most IPv6 people frown upon it, but it does make sure you never have to renumber your network. Sometimes, practicality trumps purity.
Thankfully, the market has responded to the demand for NAT, and there are at least two solutions available that I know of (probably many more than that by now).
I disagree with you that NAT is not a security solution. It wasn’t invented for that purpose – true enough. But a firewall that *automatically* blocks incoming traffic is inherently a security solution. As you say, firewall rules of the type:
Internal-LAN to Any on http/https/ping : Allow
Any to Internal-LAN on Any : Deny
Will do the same thing. But those rules must be maintained. And you must *have* a firewall in place. With NAT, you get them automatically, and you have to work hard to poke holes into the firewall. It’s virtually impossible to accidentally expose a whole computer on the Internet. In IPv6, it’s trivial to replace a firewall with a router (“just to test if this is a firewall issue”). For instance, in Linux all it would take is the command “service ip6tables stop” – and then it’s just as trivial to forget to put things back.
With NAT, that’s not going to happen. Without the firewall in place, nothing works, so you leave it untouched.
In fact, the credit-card industry has recognized this. They explicitly require NAT in their PCI security standards (and thus implicitly prohibit using IPv6).
Agreed on all the nightmares NAT causes, though.
Well, in the environments I am used to, firewalls are network devices, and maintained with change control. I have a hard time recognizing many-to-one NAT as a security solution, on the strength of the argument that a system without change control is less secure than one with (no contention on that part). One does not seem to follow from the other.
As for PCI DSS 2.0: Yes, I think their insistence on NAT is a bit silly. I’ve seen one-to-one static NAT implemented, and that meets the letter of PCI DSS 2.0: And does absolutely nothing for security. When IPv6 becomes more widespread, I expect that we will see DSS evolve again.
One thing that’s changed from when I wrote this article, though, is: There is NAT in IPv6, now. It’s called NPT, Network Prefix Translation, and came out of the NAT66 efforts. It takes one /48 and translates it 1:1 to another /48. There are legitimate uses for this, a network with multiple (think on the order of 15) geographically diverse exit points (data centers) being one of them.