IPv6 Addressing: How Wrong Can You Get It?

Mike was wondering whether his ISP is giving him what he needs to start an IPv6 pilot within his enterprise network. He wrote:

So I got an IPv6 assignment with a /120 mask (basically our IPv4/24 network mapped to IPv6) and two smaller networks to use for links between our external router and the ISP.

Believe it or not, I’m not making this up. I was as amazed as you probably are.

Dear Mike’s ISP: where were you when the rest of the world was preparing to deploy IPv6? Did you read IPv6 Unicast Address Assignment Considerations (RFC 5375) or IPv6 Address Allocation and Assignment Policy from RIPE or your regional registry?

Let’s start with prefix lengths. RFC 5375 is very explicit (section 3):

Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others.

It’s therefore highly recommended to use a /64 prefix on every subnet. The use of longer prefixes on point-to-point inter-router links is debatable (some people recommend /126 or /127, others /112). Properly implemented network devices have no problem with shorter subnets; after all, IPv6 is classless. However, to ensure you won’t get a hiccup from a just-good-enough-too-cheap-to-pass box someone will eventually connect to your network, be conservative and use /64 everywhere.

Summary: assigning someone a public /120 prefix is ... let’s be diplomatic ... out of touch with reality.

So, Mike got a /120 and tried to make sense out of it. He needs to allocate IPv6 addresses to the whole network and somehow can’t do that with a /120. Here is the next bit of wisdom passed to him by a helpful colleague (I’m not making this up either):

I asked someone more familiar (but no hands-on-experience) about this, and got the answer that I should use a link-local or unique-local addresses beginning with fe08 or fd for all computers within the company, the same way we use RFC1918 addresses today, and then just NAT them to the /120 network I got assigned from the ISP.

We were all confused by the plethora of different types of IPv6 addresses (Packet Pushers IPv6 podcast has a lively debate on that topic), but they are really not that hard to grasp. Let’s over-simplify them a bit:

  • Link-local addresses are a better solution for unnumbered interfaces and other communication needs before you get a real IPv6 address (for example, DHCPv6 request packets are sent from a link-local address);
  • Unique local addresses (ULA) can be used for intra-network connectivity (for example, for those hosts and servers that never communicate with the Internet). Your host could have an ULA and a global IPv6 address (or even more than one global address) and use one or the other as needed.
  • In most cases, your hosts should have a globally unique IPv6 address.

Regardless of whether you decide to use ULA or not, remember that there is no NAT in IPv6 (although some people are seriously longing for NAT66). Let me repeat that: there is no NAT in IPv6.

Of course that’s not true. You need NAT for load balancing, and you need NPT66 for small site multihoming… but I’m digressing.

Mike is thus stuck: he needs a /64 on every subnet in his network and got a meager /120 from the ISP. What’s wrong? The ISP’s IPv6 address allocation policy.

A minimum allocation an ISP has to give to a residential end-user is a /64. If a residential end-user needs multiple subnets, he should get a /56. Minimum end-site allocation is /48 (Mike should thus get a /48, not a /120). Minimum provider-independent allocation assigned by RIPE or ARIN is /48.

Mike could get 65000 /64 prefixes from the /48 prefix he should have got from the ISP, probably more than enough to number his entire network. If you have a larger network, it’s not hard to get a larger allocation; you just have to provide the paperwork documenting your needs.

Summary: If you are an enterprise customer and your ISP is giving you anything less than a /48, it’s time to consider changing the ISP.

For more information, check out ipSpace.net IPv6 webinars.

26 comments:

  1. Unfortunately NAT66 might be needed when more companies do what German Telekom plans to do: You'll get a /56 for your DSL which might change when e.g. the router reboots or T-* decides to give you a new prefix. :-(
  2. I have several v6 connected boxes and have seen both extremes - one provider gave me a single address (/128) another gave me a whole /48. In both cases I only have a single box connected and no need for more than one address. I do have to wonder which is really more crazy...

    Also - there are implementations of NAT66 in existence already openBSD PF being one.
  3. I have several v6 connected boxes and have seen both extremes - one provider gave me a single address (/128) another gave me a whole /48. In both cases I only have a single box connected and no need for more than one address. I do have to wonder which is really more crazy...

    Also - there are implementations of NAT66 in existence already openBSD PF being one.
  4. Flaming wars typically ensue when someone advocates NAT for IPv6. :-D

    Jens Link's point is probably one of the most technically valid reasons for NAT66. Auto-renumbering of IPv6 networks is not a current reality, and it's not clear if will ever materialize. If you look at the IETF and informational drafts its clear that there's a lot of implementation details in relation to IPv6 that are being worked out, but the good news is that people are working hard at it.
  5. "people are working hard at it" ... and like every good engineer they ignored the problems when there was plenty of time and started working on them just before the looming deadline ;)
  6. They'll get so many support calls they'll have to change their mind. Their approach is simply not supportable - you have to reload the router and all the hosts whenever the prefix changes (or wait for hours to get the lolcats back).
  7. Unfortunately, the minimum they can give you if you're on a separate subnet (for example, PPPoE connection) is a /64, otherwise SLAAC won't work. You can get a /128 on a shared LAN (Carrier Ethernet, for example).
  8. Well duh. If they worked on it before it was a problem and solved it then, nobody would have know they did the work and they would be looked upon as an unnecessary expense. If they instead wait until it's almost too late, then they look like heroes and get pay raises and nice offices. ;)
  9. The lack of automatic renumbering in IPv6 is a reason to provide static addresses to end sites that require them. It is not a reason to implement NAT66 and certainly not a reason to deploy overloaded NAPT66 (what most people refer to as NAT in IPv4).

    More disconcerting to me is the idea that residential users should some how be treated as second-class end-sites and be given /56s or worse, /64s. There is no good reason not to give residential customers /48s like any other end site. There are MANY good reasons to give them /48s, not the least of which is to support likely innovation in the area of automatic prefix delegation and self-determining network hierarchies within the home.

    Sometimes it's not just about the number of possible end subnets. Sometimes it's about the number of bits available for topology and hierarchy.

    There are approximately 7 billion people on the planet with an average household being 3.2 people per household. As such, there is need for approximately 2 billion /48s to support every existing residence. Even if the population doubles, that's still only 4 billion households. All of that could be contained within a single /16 of IPv6 space, giving every household a /48. Really, if we can support double the current number of households with /48s using only 1/65,536 or 0.001% of the total address space, i don't see the problem with being that generous with addresses.
    Replies
    1. The time was wise. NAT66 is here to stay.

      Even Cisco ( the buys that published (RFC 6296).

      NAT 66 is needed:
      a) Security. NAT is a deny first policy.
      b) Management. Organize you internal networks as you like, not limited by the public networks delivered to you.
      c) Multi-home. Try to switch IPv& after a fail of your ISP in just 2 min. Try to renumber your ENTIRE internal IPv6. Yeah, right!
  10. Which is the key point - not all networks want or need SLAAC. Several things about SLAAC are really undesirable in some situations, particularly the way microsoft decided to use random interface identifiers instead of EUI-64.

    I'm not particularly advocating NAT66 - just saying that to claim 'there is no NAT in IPv6' is a bit of an exaggeration. Of course this argument has been done to death hundreds of times already, unfortunately it's not always the best solution that wins out. I guess we'll only find out if it'll become widespread or not once CPE vendors finally get round to implementing IPv6.

    (sorry for the triple post btw - the javascript actually told me it had retried 3 times and failed all of them?)
  11. Existence of NAT66: my fault, I was not as precise as I would be if I would have been writing a research paper. However, apart from you mentioning the BSD implementation, I haven't heard of any NAT66 production-grade solution, which from the down-to-earth perspective of an engineer trying to start an IPv6 pilot means "there is no NAT in IPv6".

    As for SLAAC and Microsoft - this time they did the right thing for the residential customers (but of course every enterprise network engineer hates them when he has to troubleshoot the network).
  12. Owen, I will not go into the religious debate along the lines of "how much does a residential customer deserve" ... I will just mention the fact that we've easily thrown away half of the IPv6 address (nobody will ever persuade me that you truly need a /64 for every subnet) and that it looks like we're ready to part with another 16 bits. Obviously the 128-bit address is too mind boggling ;) and we have to cut it down to manageable size.

    As for "MANY good reasons to give them /48", I would kindly ask you to give me a few - I always love to reduce my ignorance.

    Last but not least, I'm somewhat tired of hearing how this-or-that is stifling innovation. There are many things that have that effect, but 8 bits in IPv6 address is definitely not on my list of those things. Even the numerous broken NAT implementations were not able to stifle innovation when people really wanted to roll out exciting new products or services.
  13. This ISP surely shows he does not know anything about IPv6. I think the coming years we will hear many of these "growing up" stories.
  14. You can change how M$ behaves when selecting host-id. Default is random (Temp and permanent addr.) but you can switch to EUI-64 somehow.
  15. According to http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p he could address some inter-router links... and that's it :)
  16. Owen: I have to agree with the part about static IPs. If they had a set assignments, no need to re-IP or have NAT66.

    Frank
  17. Windows by default generate random interface IDs for non-temporary autoconfigured IPv6 addresses. To change this type:

    netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
  18. I assume this is for W7. Is there a simular command for XP that gives the same result?
    "'randomizeidentifiers' is not a valid argument for this command."
  19. It's for Vista and "better"

    XP lacks "full" IPv6 support.
  20. Why NAT66? To meet it sounded like a method to sell more network devices, break DNSSEC, IPSec and generally place the IPv6 Internet back 20 years.
  21. Don't forget the need to effectively implement the standard either. /64 was a compromise (all standards unfortunately are), partly due to the concern of designing a cost-effective IPv6 router to do line-rate longest-prefix-match at the time (worst-case O(128) for a trie, or O(1) if you have the extra TCAM).
    As a comparison, look at CLNP. CLNP is a nice protocol, but how do you optimize an implementation for a loosely defined address space? Look what router vendors ended up doing.
  22. One pont I will make on IPv6 NAT,

    One of my many interests is in embedded Linux. Just about all run-from-rom devices that use it these days (whether they admit it or not, and most do) are built around Linux, particularly modified Debian 2.4 kernels with various hacked up versions of busybox, wrapped in a webinterface. And not just router CPEs I'm talking, also NASs and a whole lot of other stuff out there. (tv sets, cable modems, DSL modems, etc.) The SOHO router stuff hitting the market today is more and more 2.6 kernels now but all of them chintz enormously on the amount of flash. 4MB is still almost always used but some of the better gear uses 8MB. And 32MB of ram is usually a max also.

    Anyway, with all due respect to the OpenBSD pf NAT66 implementation, you simply aren't going to see NAT66 in these inexpensive SOHO CPE devices until it's integrated into iptables, into the standard distro. And the only alpha-quality NAT66 implementation out there for iptables is http://map66.sourceforge.net/ That one was written more from a "prove it can be done" than anything else, and the developer has already said he's not going to do anything more on it for now.

    These manufactures - and you can include Cisco with it's Linksys and "SOHO Business Routers" like the RVS4000 - simply aren't going to put in experimental modules into iptables for their devices. The chance of an undetected memory leak is high and it's not like your running on a PC with 4GB of ram where a few bytes of leakage can go for months if not years before it becomes a problem. And they aren't going to sink development dollars into it either - the entire point of using Linux on these devices in the first place is to leverage other people's work, particularly the Linux developers. Besides that they have enough problems with dealing with the chip vendors like Broadcom, Intel, Atheros, and so on, removing bugs from their hardware drivers and integrating them into the embedded linux code they are using.

    So, in summary you might possibly see a NAT66 implementation in a Cisco or Juniper $10,000.00 router or a $5K firewall from Checkpoint or some such, but you won't see it in Ma and Pa Kettle's home cable modem until the major Linux distros adopt it - and the iptables developers won't accept anything like that until the IETF has agreed on a standard and a lot of people in the community have put time into beating on someone's set of patches. And that would be years from now even if a solid set of patches adding NAT66 into iptables existed today.
  23. Well, throwing away only half of the IPv6 addresses would be more than excellent. But unfortunately this is no place for logarithmic thinking! Assuming there is a sense for 16 bits for the host in a subnet (probably it isn't, but ...), we have thrown away (2^48-1)/2^48 of addresses. That is more than 99.999999999999 % of them. Neglecting those puny 0.000000000001 % of addresses we have actually thrown away the whole IPv6 Internet. :-(
  24. Well, to be honest you can run IPv6 with low lifetimes in your prefix announcements, so your hosts will forget it quickly when they don't hear news from your residential DSL router. And, as far as I heard, it's not supposed to change every night, but it's not a contractually guaranteed fixed prefix. So yeah, when they decide to renumber in an area, you need to adjust. (After all, the assignment part is dynamic thanks to DHCPv6-PD.)
Add comment
Sidebar