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.
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.
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
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?
/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.
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.
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..."
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...
As for IPv4 address space consideration, which was made over 30 years ago, no one really expected internet to grow beyond a research project :)
I wish I, and some others like Kim, be quoted in 20 years from now...
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...
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.
But #1 (or the falsety of it) is enough to grant a /56 at least, IMHO.
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.
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 ;)
(I too am a IPv6 newbie so I may be completely off).
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 :)
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.
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.
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.
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.
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.
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
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.
With a /56-per-customer that becomes 2M+ customers, which might be reasonable for many ISPs.
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.
A uniquely advertised prefix is only truly necessary if it is going to be dual homed to more than one provider.