How much IPv6 address space should a residential customer get?

A while ago I wrote about IPv6 addressing challenges some ISPs face and recommended what I thought was agreed-upon practice of giving residential customers a /64 or a /56. Not long after, I received an e-mail from an IPv6 guru saying:

[Worse] is when people start claiming to have expertise in IPv6 and promulgate this idea of residential /56s and /64s as immutable fact. The reality is that it is becoming more and more apparent that /56s and especially /64s to residential customers are going to be harmful to future innovation in IPv6.

I can’t possibly track all the emerging technologies in the world and I am delighted when people point out my weak spots (as Petr Lapukhov, Dmitri Kalintsev and a few others are doing on a regular basis) as that’s a wonderful opportunity to learn something new, so I asked about the reasons why someone might want to give a residential user a /48 ... and never got a reply.

Still perplexed, I asked the same question at the Slovenian IPv6 summit’s roundtable with Daniel Karrenberg and Patrik Fältström ... and figured out that while it’s still quite possible I’m totally ignorant, at least I'm in a very respectable company.

As I’m running another session of the Building IPv6 Service Provider Core webinar next week (register here or buy a recording) and it includes a short section on IPv6 addressing best practices, please help me out: if you think there are good reasons to give residential users /48s, write a comment.

34 comments:

  1. I can think of no earthly reason why a normal residential customer should be handed out /48s as a matter of course. By special -- justified -- request, yes, but it should never be the default.

    On the other hand, however, I'd be wary of giving out anything smaller than a /64, as that's the size required for autoconfiguration to work (working on the basis that sensible CPE will run some kind of route-advertisement service for the prefix). If DHCPv6 ever becomes prevalent, this might change, but I wouldn't want to rely on that any time in the next few years.

    ReplyDelete
  2. "[...]so I asked about the reasons why someone might want to give a residential user a /48 [...]"
    Let's ask the question the other way around : Why NOT give residential users /48 ?

    Sure, /64 may be enough for *today* typical uses. Can you tell if it will still be enough in ten years ?
    Are IPv6 "expensive" enough that it's worth taking the risk of having to entirely rework your IP allocation scheme in a few years ?

    It seems to me that planning to provide residential users with /64 is a result of 3 totally wrong hypotheses :
    1) Residential users will never need more than a /64. Ever.
    2) It's more expensive to hand out 48/ than it is to hand out /64
    3) If statements 1 turns out to be wrong, It's easy to move to /48

    ReplyDelete
  3. Honest IPv6 newbie question: why wouldn't it be easy to move from a /64 to a /48 for a typical residential user?

    ReplyDelete
  4. The real question is: why not? Why you don't want to give out /48 to residential costumers?

    The only reason I can think of is address wasting, but I *really* don't mind. Providers will waste a whole lot more addresses giving a /64 to point-to-point networks anyway. After that logic, it boils down to "it's designed that way". So the final question is: why not?

    ReplyDelete
  5. In my mind, why give a /64? We obviously don't have any address shortages in v6 world in the near or short term future.

    /64 is a LAN size. No need to segment further than that, and in fact, things break when you do, as Ivan has pointed out in previous blogs.

    We should assume that residential users will want to have more than one LAN in the future. Especially in the sense that service providers will want to offer triple-play type services over the same link and CPE device. Home automation networks, guest wireless networks, etc. These are all things being done today, and who knows what might come in the future.

    A /48 allows for plenty of future uses, and it's not that much of a stretch for providers to be assigning them a /48. At the bare minimum, give them a /56, which gives them 256 /64's to work with. Things like DHCP6-PD will make this really easy.

    ReplyDelete
  6. I should also add, do we really want things like NAT66 to become prevalent in the residential market?

    ReplyDelete
  7. The only technical argument I'm aware of would be to make NAT66 work, but NAT66 is changing and the whole purpose of giving ample address space was to avoid NATs in the first place.

    A /64 could only be recommended in cases where you know there is a single link / single host. If a router is connected a shorter prefix length must be used. It is convenient for the purpose of reverse delegation that this is on a nibble boundary. Some service providers will assign a fixed prefix size to all their customers e.g. a /56 others will delegate on a documented need basis. e.g. 4 /64s for most residential customers.

    ReplyDelete
  8. Hey guys, remember when IPv4 was new and they were handing out huge address blocks to companies thinking there were totally enough addresses available that it wouldn't be a problem?

    Now sure, a 128-bit address space is huge and I can't for the life of me imagine it ever running out, but wouldn't it be funny if 15 years from now we looked back at this time and thought "If only we hadn't decided to give everyone /48's, we wouldn't be running out of addresses now..."

    ReplyDelete
  9. I think Kim Johnsson has an important aspect, because this are probably the same considerations which some people did during the design & implementation of IPv4 some decades ago...

    In my personal opinion, /64 should be sufficient for the average residential customer which just uses the internet access.
    But there are also customers with more advanced skills like us networking guys - I've currently several private /24 networks in use (wired LAN, wireless LAN, home lab, ...), so if I had to move to IPv6, /64 would not be sufficient, /56 should be...

    I think the best way would be assigning a /64 by default and expand it to /whatever if the customer requests it (and maybe charge it if more than /48 is needed f.e.).

    NAT66 with ULA could also be an option...

    ReplyDelete
  10. RFC3177 provides good reasoning on why go with /48 for everyone. It discusses Kim's "explosive address exhaustion" counter-argument as well. There is no "killer" reason to go with either /64 or /48 for residential customers though, I believe.

    As for IPv4 address space consideration, which was made over 30 years ago, no one really expected internet to grow beyond a research project :)

    ReplyDelete
  11. That's exactly what I keep telling everyone, the fact we're loaded up with zillions of ipv6 addresses doesn't mean we need to start deliberately wasting them right away just for the laziness of not dealing with it too much, I'd like to believe my children and grand children won't have to go through the painful process we're going now, making the v4 world's transition to v6, so wouldn't we prefer to manage it right, thinking also about what's going to be in 20 years from now instead of just doing what's best for us here and now?
    I wish I, and some others like Kim, be quoted in 20 years from now...

    ReplyDelete
  12. That's exactly the point!
    Nobody now can possibly expect what's going to be in 20-30 years, so why not start cautiously?
    if in 20 years from now, after being cautious, we find out there are no more reasons to be tight about ip allocations as we still will have trillions of available ip ranges, then there's never too late to start wasting...

    ReplyDelete
  13. /64 is generally accepted as a bad idea (except for 6rd, where a /32 plus 32 bits of v4 address give a /64, but that's a special case for transition technology). /56 and /48 are both reasonable, but there is a reason you might want a /48 even if you're not likely to have >256 networks in a home: easy automated hierarchical delegation in a routed home. If you delegate a /48 to the ISP-facing CPE, it can then delegate (for instance) a /56 to each routing device connected to it, and each of those devices can have multiple interfaces and possibly more devices behind them.

    The 8 bit boundary (/48 to /56) is arbitrary, it could as easily be 4, 5, or 6 bits. The point is that with 16 bits to work with, you can have a lot of flexibility in delegation, allowing for both plenty of levels of depth and plenty of devices at each level, but with only 8 bits those tradeoffs become much more acute. So, without a pressing reason to assign less than a /48, just use /48.

    ReplyDelete
  14. #2 is not wrong by face value so to say: There are a finite number of nets in v6 and you have less /48s than /64s, so the former are more expensive in any sound cost assignment.

    But #1 (or the falsety of it) is enough to grant a /56 at least, IMHO.

    ReplyDelete
  15. On a related issue that I'm investigating, RIRs also have a very stringent policy to give address space to ISPs. You need a .94 occupancy HD ratio to get a second /32, and that seems to be really packed.
    No wonder they treat v6 address space as premium, and want to assign even /128s :)

    It boils down to an old saying we have: he who ever got burned with milk sees a cow and cries.

    ReplyDelete
  16. RFC3177 explains it really well... true. Just two thoughts on the topic:
    for "really big networks" RFC3177 recommends to assign a /47 or several /48 prefixes... I assume, really big networks will be multihomed anyway and will need to have their own IP range - the regional registrar will decide how big the range gets.
    The multihoming topic is an interesting topic. I don't think that using more than one prefix on your hosts (one from each upstream provider) is a valuable solution. This leads either to NAT66 or own IP range (usually /48). I really don't want to implement NAT for multihoming and using provider independent address space leads to a big routing table.

    /48 for customers makes complete sense. It's easy to understand, the customer can use /56 for his subnetworks and /64 for his segments. Service Provider wise, you'll only have /48 and /64 networks (and /128 for loopbacks) in your own routing table. Pretty neat. Makes the subnet calculation easier ;)

    ReplyDelete
  17. I think it's because other portions of that /48 that your /64 resides in would have been assigned to others, and not still be free to give to you.

    (I too am a IPv6 newbie so I may be completely off).

    ReplyDelete
  18. Guillaume Leclanche13 December, 2010 17:57

    The 6rd deployments that I know of target a /60 for each customer, which should be ok for the transition time.

    I still believe the /56 would be better as well. Because with a /48 you can fit only 65k customers in a /32, whereas with a /56 you can fit 16M, which is enough for most ISPs in most countries.
    But probably a lot of people can justify why we need 65k subnets @home (sure we don't talk about small businesses here).
    In the end, I don't really care, and as I've already read somewhere, if we burn too fast the 2000::/3, we can still change the policy for 4000::/3 :)

    ReplyDelete
  19. My favourite reason is "16 bits for customer for networks". In this case customer have full field between consecutive ":" to use for whatever subnetworking schema he might come up with. It just makes sense. With /56 customer needs to calculate the boundary... Addressing-schematic-wise it is a good choice, maybe your customer needs subnetworks that makes sense to him, maybe building number/floor/room or maybe postal address of the location where network is - this is freedom of IPv6, don't get this away from them...

    ReplyDelete
  20. .94 HD isn't that packed... If you're assigning /48s out of a /32, you only need to assign about 24k of them to get .94 HD. That's just over a third of the space; if you can't do that you probably shouldn't be getting more space.

    That said, only the smallest ISPs should have a /32. It's the minimum allocation, not the recommended one. Take your existing customer numbers and addressing plans to your RIR and get a block big enough to hold all your customers for the next two years.

    ReplyDelete
  21. .94 HD isn't that packed... If you're assigning /48s out of a /32, you only need to assign about 24k of them to get .94 HD. That's just over a third of the space; if you can't do that you probably shouldn't be getting more space.

    That said, only the smallest ISPs should have a /32. It's the minimum allocation, not the recommended one. Take your existing customer numbers and addressing plans to your RIR and get a block big enough to hold all your customers for the next two years.

    ReplyDelete
  22. Guillaume Leclanche15 December, 2010 18:09

    Jan, but the question was more about small end-users. I think everybody agrees that even a small company should get a /48 (65k * /64). But residential users (by far representing the highest number of allocations) could probably live very well with a /56 (256 * /64). And any ISP could offer as a premium to get a /48 if required...
    As I was saying earlier, in a /32, you can fit 16M /56 but only 65k /48. Even though we have tons of space in v6 (see http://goo.gl/RCrHk for graphical view), these numbers look quite reasonable.

    ReplyDelete
  23. I just read RFC3177. I am so confused regarding the /64 subnet rule in IPv6. That is 18 Quintilian unique addresses right? If each bit of RAM in all my PCs and Servers at home had their own IPv6 address I still wouldn't need a network that big. What gives?

    ReplyDelete
  24. Don't read RFC3177. Read http://tools.ietf.org/html/draft-ietf-v6ops-3177bis-end-sites-00

    ReplyDelete
  25. One of the basic goals of IPv6 was to have stateless autoconfiguration and they decided to implement it by appending 64 bits of host ID to 64 bits of subnet. Of course there are all sorts of better ways of doing it (not to mention that you have to explode 48-bit MAC address into 64 bit host ID first) and a number of nasty consequences of having globally-unique host ids (think about cookieless user tracking), but that's life ...

    ReplyDelete
  26. Ben,
    the math involved is not that hard but it's not obvious.
    My numbers show that for a .94 HD you need 33.690 assignments out of 65.536, i.e.,
    more than half.
    Also, the "aditional space requirements" should not be different from initial greater than /32
    space, IMHO, or you get a singularity at start which I don't understand the reason that would
    support it.

    If clients can grow, ISPs should be able to reserve space for them. With .94 that is basically impossible, so we are bound to have either to move (renumber) or to fragment.

    ReplyDelete
  27. As the /64 is smallest prefix in V6 world if people adopt relevant RFCs, multiple /64 should be reserved for new services serving residential users in future, such as VOIP, IPTV or whatever will happen ---- "IP everything" is a goal of networking technology?

    Yes we definitely can install all different services endpoints in one /64 but why don't we use separate IP spaces for different services to make life easier? Take Australia NBN as an example, there is now only one fibre into the house but with a TDM multiplexer, if in future only one router can serve all required services with IP, the ISP then need some smart classifier to classify traffics among the endpoints in one /64.

    We do need multiple /64 for residential users but a /48 will be too big, even we "maybe" have enough IPV6 address for all the creatures on the earth, while waste is always a demerit from the administrative perspective.

    ReplyDelete
  28. To be a devils advocate, is there any reason we're skipping over smaller (yes, uneven) allocations like /63, etc. Additionally, short of the autoconfig caveat, whats stopping home users from subnetting deeper on their own if they were assigned a /64.

    ReplyDelete
  29. Mark van Winsen06 March, 2011 08:14

    Hi Ivan,

    I doubt a /56 to be harmful. A /64 has the disadvantage of not being able to route into the users network. Personally I don't see the need for a /48 for consumers. Some people say it is easier for people to switch provider when every provider would use a /48 because they only have to change the prefix.

    Kind regards,

    Mark

    ReplyDelete
  30. Ivan Pepelnjak06 March, 2011 08:34

    Personally I don't have a problem with a /56 per user. As the relevant authorities have decided to waste just one part of the address space, it's feasible to experiment with a /48 per user ... but then the default LIR allocation has to change to be significantly bigger than /32, otherwise the address space will get way too fragmented.

    The real problem is that there is no consensus. Various entities in the allocation chain are doing what they think is best, not necessarily leading to an optimum solution.

    ReplyDelete
  31. Mark van Winsen06 March, 2011 08:41

    A second /32 next in order to the first /32 is reserved. So if an ISP runs out of his /32 it will become a /31.

    ReplyDelete
  32. Mark van Winsen06 March, 2011 08:43

    So just to be more clear, my advice is an /56 or /48, not a /64. Our policy is /56 for everyone, when the customer tells us he wants more, he gets a /48 from a different pool no questions asked.

    ReplyDelete
  33. Ivan Pepelnjak06 March, 2011 08:58

    With a /48-per-customer you've just given ISP an option of having 120K customers without fragmentation. Not much, I would guess.

    With a /56-per-customer that becomes 2M+ customers, which might be reasonable for many ISPs.

    ReplyDelete
  34. Mark van Winsen06 March, 2011 09:14

    Unofficially RIPE reserve a /29 per ISP, but I agree using /56's would give us much more space as the consumer doesn't need more then a /56 imho. 256 subnets of 18 quadrillion addresses will be enough.

    The main problem is the lack of the RFC describing a /56 to be adviced (RFC3177bis is still a draft). I also see DSL-router vendors to first support a /48.

    Other values like a /63, /60 or other values are not advised to be used as there is no RFC to support them and no vendor who will test their low-end CPE with these values.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.