In reviewing IPv6 end user allocation policies, I can find little
agreement on what prefix length is appropriate for residential end
users. /64 and /56 seem to be the favorite candidates, with /56 being
slightly preferred.
I am most curious as to why a /60 prefix is not considered when trying
to address this problem. It provides 16 /64 subnetworks, which seems
like an adequate amount for an end user.
Does anyone have opinions on the BCP for end user addressing in IPv6?
In reviewing IPv6 end user allocation policies, I can find little
agreement on what prefix length is appropriate for residential end
users. /64 and /56 seem to be the favorite candidates, with /56 being
slightly preferred.
Not slightly preferred, very much preferred. /56 is future proof and works for "everybody". /64 is short sighted and doesn't allow for multiple networks in the home.
I am most curious as to why a /60 prefix is not considered when trying
to address this problem. It provides 16 /64 subnetworks, which seems
like an adequate amount for an end user.
Why save on addresses, you can just get more IPv6 addresses if you need them. /56 is allowed per user from all the RIRs afaik.
Does anyone have opinions on the BCP for end user addressing in IPv6?
Yes, there are plenty of people with opinions.
This has been hashed over and over and over again, please check the archives for lots of discussions on pros an cons. If you want to do it right, go for /56, it works.
Basically, the thinking was a /56 is still "cheap" as far as allocating space,
so if you need more than a /64, might as well go to /56 and avoid the mess if a
user needs a 17th subnet. This isn't IPv4, where you have to actually worry
about burning through your IP allocation doling it out to customers. Even a
single /32 will service a *lot* of /56's, and I don't think *anybody* is big
enough to actually burn through a /24 allocation (feel free to prove me wrong..
Never doubt the ability of certain Asian countries to burn through IP space at blistering speed when their citizens can't even directly access the internet without going through a massive firewall and proxy system. 
/56 is definitely preferable to /64, but, /48 really is a better choice.
/56 is very limiting for autonomous hierarchical deployments.
It's not about number of subnets. It's about the ability to provide some flexibility
in the breadth and depth of bit fields used for creating hierarchical topologies
automatically.
Owen
In reviewing IPv6 end user allocation policies, I can find little
agreement on what prefix length is appropriate for residential end
users. /64 and /56 seem to be the favorite candidates, with /56 being
slightly preferred.Not slightly preferred, very much preferred. /56 is future proof and works for "everybody". /64 is short sighted and doesn't allow for multiple networks in the home.
I would say /56 is slightly preferred and that /48 is very much preferred.
I am most curious as to why a /60 prefix is not considered when trying
to address this problem. It provides 16 /64 subnetworks, which seems
like an adequate amount for an end user.Why save on addresses, you can just get more IPv6 addresses if you need them. /56 is allowed per user from all the RIRs afaik.
All RIRs allow /48s actually. Some policies measure in increments of /56, BUT, even those policies
consider issuing a customer a /48 to be a valid use of 256 /56s for measurement purposes.
Does anyone have opinions on the BCP for end user addressing in IPv6?
Yes, there are plenty of people with opinions.
This has been hashed over and over and over again, please check the archives for lots of discussions on pros an cons. If you want to do it right, go for /56, it works.
If you really want to do it right, go for /48… It works better.
Owen
Those cases are probably best handled as a /16 delegation from a regional RIR
to a national RIR or similar. And they can just ULA themselves a /16 for inside
the country if they really feel the need
And yes, I know a single /24 won't quite cover all of Comcast's customers if
they give them all a /48. They're welcome to prove me wrong by turning up
enough customers on IPv6 to need a second /24.
You've had a lot of good opinions already, but here's one more vote for
/56 being the absolute minimum.
That said, the strategy I've suggested in the past is to reserve for
each customer the largest block that your RIR will recognize as
reasonable (note, that's reasonable, not theoretically justifiable) for
end user assignment. Then if down the road it turns out that you need
more space and for some unimaginable reason you can't get more from the
RIR you can go back and start bifurcating the blocks you've reserved.
For example, if you reserve a /48 per customer but actually use the
first /56 out of it, you are safe if _you_ need the other /56 for some
reason, or if the customer needs to expand into the full /48.
hth,
Doug
Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
zeroing in on a /56 for production. Though some ISPs are using /64 for
their trials.
Frank
Hi,
Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
zeroing in on a /56 for production. Though some ISPs are using /64 for
their trials.
IIRC, there's RfC6177 - covering almost exactly what the original poster asked for.
Not sure if it was mentioned already.
/48 is what IPv6 was designed for, /48 per customer (or even per customer-site some might say) is supported by the RIR policies,
and there are close to zero reasons not to use a /48. It also eases your administration
processes and also operational things.
Of course, if you only have John Average residential customers or whatever, use a /56 or /60.
It's your choice. You know your customers best. We're not in a classful world again 
But do your math, there is no address shortage, handing out a /48 to every type of customer
as a single assignment size should be the sane choice.
You waste precious time thinking too much about it.
At least don't make your life miserable by experimenting with too many different assignment sizes,
or advocate /64s or something, that's considered a design fault which will come back to you some day.
Read the RfCs and RIR policy discussions in the archives some years ago.
I'm not the only person who prefers /48 and hopefully most ISPs will eventually
come around and realize that /56s don't really benefit anyone vs. /48s.
Hurricane Electric has been handing out /48s upon request to our customers and
users of our IPv6 tunnel services. We do not anticipate changing that policy.
Owen
Hi,
Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
zeroing in on a /56 for production. Though some ISPs are using /64 for
their trials.IIRC, there's RfC6177 - covering almost exactly what the original poster asked for.
Not sure if it was mentioned already.
RFC6177 sort of appears to recommend /56 if you don't look at it too closely.
What it really says is essentially "The IETF throws its hands up in the air and
refuses to make any recommendations in this arena leaving the entire thing
to RIRs and service providers where we probably should have put it in the
first place."
/48 is what IPv6 was designed for, /48 per customer (or even per customer-site some might say) is supported by the RIR policies,
and there are close to zero reasons not to use a /48. It also eases your administration
processes and also operational things.
AMEN, Brother! 
Of course, if you only have John Average residential customers or whatever, use a /56 or /60.
It's your choice. You know your customers best. We're not in a classful world again
But do your math, there is no address shortage, handing out a /48 to every type of customer
as a single assignment size should be the sane choice.
You waste precious time thinking too much about it.
Yep. Even if you only have John Average residential customer. Residential customers today are
not going to be the same as residential customers in 5, 15, or 25 years. Giving them /48s will save
you (and them) a lot of heartache down the road. (and yes, I mean a /48 per end site structure or
per tenant in a multi-tenant structure).
At least don't make your life miserable by experimenting with too many different assignment sizes,
or advocate /64s or something, that's considered a design fault which will come back to you some day.
Read the RfCs and RIR policy discussions in the archives some years ago.
Also, please don't make your life miserable by trying to align things on odd bit boundaries. Stick
to nibbles.
Owen
Note that in this thread, you advocate three things that are a little
tough to make work together:
* hierarchical addressing plan / routing
* nibble-aligned addressing plan
* minimum /48 per customer
If I were, for example, a hosting company with IPv6 terminated at the
layer-3 ToR switch, I would then use a /40 per rack of typical
"dedicated servers." If you then want some bits to be a POP-locator
field for your hierarchical routing scheme, you are already forced to
request more than a /32. The number of customers per layer-3 device
for typical end-user access networks was around the same into the
late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever
box of choice for terminating dial-up.
Densities have changed, but this doesn't necessarily win you an
advantage when combining those three properties. This is especially
true if you consider that density may change in a difficult-to-predict
manner in the future -- a BRAS box with a couple thousand customers
today might have three times as many in a couple of years (IPv6 is
supposed to help us avoid renumbering or injecting additional routes
into our network, right?) As an access provider, if I shared your
view, I would be reserving a /36 or /32 per BRAS box. If I then want
some additional bits for hierarchical routing ... I'm going to need a
pretty large address block for perhaps a pretty small number of
customers. After all, my scheme, applying your logic, dictates that I
should use a /32 or perhaps a /28 per each POP or city (I need to plan
for several BRAS each), even if I don't have a lot of customers today!
I think /56 is more sensible than /48, given the above, for most
end-users. Either way, the users will be gaining a lot more
flexibility than they have with IPv4 today, where they probably get
just one IP address and have to pay a fee for any extras. Giving the
typical end-user 8 fewer bits worth of address space allows the ISP
network more flexibility for hierarchical routing before they have to
go to their RIR and figure out how to justify an out-sized allocation.
Also, if folks would stop thinking that every subnet should be a /64,
they will see that end-users, makers of set-top-gateways, or whatever,
can certainly address a whole lot of devices in a whole lot of subnets
even if the user is only given a /64. Do we think DHCPv6 won't be the
most common way of assigning addresses on SOHO LANs, and that SLAAC
will be essential? I, for one, think that some ISPs will be sick and
twisted enough to hand out /128s so they can continue charging for
more IP addresses; but certainly the makers of IPv6-enabled devices
will foresee that end-user LANs might not be /64 and include the
necessary functionality to work correctly with smaller subnets.
Before you beat me to it, yes, we seem to have completely opposing
views on this subject. I will change my mind when I can go to the RIR
and get a IPv6 /24 for a small ISP with a few POPs and a few tens of
thousands of customers. Should RIR policy permit that sort of thing?
+1. Be generous in planning and then assign what makes operational
sense. Be sure to make sure that as you dole out smaller than blocks
to customers that requested from your RIR, you preserve your ability
to give a client a second block from the same aggregatable range.
I'm not the only person who prefers /48 and hopefully most ISPs will
eventually
come around and realize that /56s don't really benefit anyone vs. /48s.
Hurricane Electric has been handing out /48s upon request to our customers
and
users of our IPv6 tunnel services. We do not anticipate changing that
policy.
Owen
A lot of good that /48 will do while HE rides out their on going peering war
and customers are missing a wide swath of the ipv6 routing table.
Cb
At least don't make your life miserable by experimenting with too many different assignment sizes,
or advocate /64s or something, that's considered a design fault which will come back to you some day.
Read the RfCs and RIR policy discussions in the archives some years ago.Note that in this thread, you advocate three things that are a little
tough to make work together:
* hierarchical addressing plan / routing
* nibble-aligned addressing plan
* minimum /48 per customer
Hasn't been hard so far.
If I were, for example, a hosting company with IPv6 terminated at the
layer-3 ToR switch, I would then use a /40 per rack of typical
"dedicated servers." If you then want some bits to be a POP-locator
field for your hierarchical routing scheme, you are already forced to
request more than a /32. The number of customers per layer-3 device
for typical end-user access networks was around the same into the
late-1990s/early-2000s, as ISPs had racks of Portmasters or whatever
box of choice for terminating dial-up.
I think we were talking about access customers. I don't see giving /48s
to individual dedicated servers as I don't see them having hierarchy
behind them. I would think that a /48 per TOR switch would be
reasonable in that case.
However, requesting more than a /32 is perfectly reasonable. In
the ARIN region, policy 2011-3.
Densities have changed, but this doesn't necessarily win you an
advantage when combining those three properties. This is especially
true if you consider that density may change in a difficult-to-predict
manner in the future -- a BRAS box with a couple thousand customers
today might have three times as many in a couple of years (IPv6 is
supposed to help us avoid renumbering or injecting additional routes
into our network, right?) As an access provider, if I shared your
view, I would be reserving a /36 or /32 per BRAS box. If I then want
some additional bits for hierarchical routing ... I'm going to need a
pretty large address block for perhaps a pretty small number of
customers. After all, my scheme, applying your logic, dictates that I
should use a /32 or perhaps a /28 per each POP or city (I need to plan
for several BRAS each), even if I don't have a lot of customers today!
Correct… I think a /36 per BRAS seems about right, but if you want
to put more than 3072 customers on a single BRAS and expect
technology to eventually support that, sure, go for a /32 per BRAS.
If you want to isolate your routing down to per BRAS (most providers
I'm aware of that have multiple BRAS have it set up so any customer
in a given POP may connect to any BRAS and they carry the
customer prefixes within the POP's routing table), then, I think a
/36 per BRAS is probably OK (up to 3072 customers at 75%
utilization, 4096 max), but, if you really think you will have 6,000
customer BRAS units, then, yes, a /32 would be correct.
However, I would be more likely to assign hierarchy per POP
instead. Figure out how many customers are likely in my
largest POP and allocate based on /48 per customer+growth
in that POP. For example, if my largest POP would serve 2,000
customer end-sites, I'd be looking at a /36 per POP. If the largest
POP served 3,073 customer end-sites or even 49,000 customer
end-sites, I'd plan on a /32 per POP.
Basically take the number of customer end-sites in your largest
POP, divide by 0.75 (keep 25% headroom minimum) and then
round up to the nearest nibble.
If you really think you will have more than 786,432 customer
sites served from your largest POP, then, I suppose a /28 per
POP is a reasonable request. That seems like pretty unlikely
density, even in 20 years. I realize that customer density in
urban areas does tend to increase, but, assuming a maximum
50% market penetration, serving a city the size of Philadelphia
out of a single POP still seems unlikely to me.
I think /56 is more sensible than /48, given the above, for most
end-users. Either way, the users will be gaining a lot more
flexibility than they have with IPv4 today, where they probably get
just one IP address and have to pay a fee for any extras. Giving the
typical end-user 8 fewer bits worth of address space allows the ISP
network more flexibility for hierarchical routing before they have to
go to their RIR and figure out how to justify an out-sized allocation.
Why? You point out that giving out /48s would require larger IPv6
allocations than /32, but, you don't give any reason to think this is
bad.
Let's look at the math. Let's assume a moderately large provider
expects to serve 45,000 customer end-sites out of their largest
POP (does anyone actually expect numbers this large in a
single POP)?
Now, let's say you have 50 POPs across your service region
and expect to triple in size over the next 5 years. That's 150
total POPs planned.
45,000 customer end sites with 25% minfree is 60,000
which, when rounded up to a nibble is 16 bits for 65,536.
150 POPs with 25% minfree is 200 which, when rounded
up to a nibble is 8 bits for 256 total POPs possible.
16+8 = 24, so, such a provider would need a /24 for their
access network.
There are 512 /24s in each of the /12s (what the IANA issues
to RIRs).
Also, if folks would stop thinking that every subnet should be a /64,
they will see that end-users, makers of set-top-gateways, or whatever,
can certainly address a whole lot of devices in a whole lot of subnets
even if the user is only given a /64. Do we think DHCPv6 won't be the
most common way of assigning addresses on SOHO LANs, and that SLAAC
will be essential? I, for one, think that some ISPs will be sick and
Yes.
twisted enough to hand out /128s so they can continue charging for
more IP addresses; but certainly the makers of IPv6-enabled devices
will foresee that end-user LANs might not be /64 and include the
necessary functionality to work correctly with smaller subnets.
I think natural selection in the market will solve that problem relatively
quickly.
Before you beat me to it, yes, we seem to have completely opposing
views on this subject. I will change my mind when I can go to the RIR
and get a IPv6 /24 for a small ISP with a few POPs and a few tens of
thousands of customers. Should RIR policy permit that sort of thing?
OK… Start changing your mind… Read 2011-3. It's been adopted
in the ARIN region. I'd also like to suggest you consider supporting
APNIC proposal 98 which is essentially the same policy and will be
discussed at the Busan meeting.
Owen
The way to address this better is to use allocation by bisection to your
customers rather than giving them /56s.
If you give a site a /48, it is very unlikely they will ever need an additional
prefix for that site. Of course if you're talking about a customer that is
using a single connection to you to feed multiple sites, that's a different
issue and will require additional planning.
For anyone that already understands allocation by bisection, you can
skip the rest of this message.
What I mean by allocation by bisection is simply issuing prefixes such
that each issued prefix has the largest possible contiguous aligned
space available for expansion. Let's assume 2001:db8::/32 as our
starting point and that we are assigning /48s to 50 end sites from it.
(I'm skipping the whole hierarchy to fit inside a /32 and keep the example
simple).
We'd assign 2001:db8::/48 for our own infrastructure and support machines.
The first customer would get 2001:db8:8000::/48.
The next customer would get 2001:db8:4000::/48, then 2001:db8:c000::/48.
In the next round, we'd assign 2001:db8:2000::/48, 2001:db8:6000::/48,
2001:db8:a000::/48 and 2001:db8:e000::/48
This would be followed by …1000::/48, …3000::/48, …5000::/48, …7000::/48,
…9000::/48, …b000::/48, …d000::/48, and …f000::/48.
At this point, we've assigned 15 customers, and each of them could be
expanded from /48 to /36 without invading any of our existing assignments.
Continuing, we would assign the next 16 customers as:
2001:db8:0800::/48, 2001:db8:1800::/48, 2001:db8:2800::/48,
2001:db8:3800::/48, 2001:db8:4800::/48, 2001:db8:5800::/48,
2001:db8:6800::/48, 2001:db8:7800::/48, 2001:db8:8800::/48,
2001:db8:9800::/48, 2001:db8:a800::/48, 2001:db8:b800::/48,
2001:db8:c800::/48, 2001:db8:d800::/48, 2001:dbu:e800::/48,
2001:db8:f800::/48
That brings us to 31 customers all of whom have room to expand
their /48 up to a /37 (though I wouldn't recommend doing /37s
as they are not nibble-aligned, so, outside of exceptional circumstances,
you would be unlikely to expand in place beyond /40 at this point.)
The next 32 customers would fill in the 2001:db8:?400::/48 ranges
and the 2001:db8:?c00::/48 ranges. This limits those customers
now to /38s.
Owen
Let's clarify -- /48 is much preferred by Owen,
It's is also supported by RIR policy, and the RFC series. It would unfair to characterize owen as the only holder of that preference.
In reviewing IPv6 end user allocation policies, I can find little
agreement on what prefix length is appropriate for residential end
users. /64 and /56 seem to be the favorite candidates, with /56 being
slightly preferred.
Hi Brian,
/64 is *strongly* discouraged. I'd go so far as to say that when we
look back 3 years from now, anybody who assigned /64's to end user
networks will be considered short-sighted bordering on foolish. Assign
a /128 if you know the downstream is exactly 1 host (not a LAN, not a
PC with virtual machines, exactly one computer) or else assign at
least a /60.
I am most curious as to why a /60 prefix is not considered when trying
to address this problem. It provides 16 /64 subnetworks, which seems
like an adequate amount for an end user.
Every time someone needs more than the standard assignment, you have
to make a custom assignment with the manpower cost to make it and
maintain it. This will happen often with /64, occasionally with /60
and rarely with /56.
On the flip side, /56 allows for 16M end-users in your /32 ISP
allocation. After which you can trivially get as many additional /32's
as you want. Is there any reason you want to super-optimize to get
268M end-users squashed in that /32?
Regards,
Bill Herrin
Arguably, if you only have one /32, and you ever get 65,536 customers
each with a /48, getting as many /32s as you need should be no problem,
also.
But you might want to give them /56s, so you have more bits to logically
divide those customers by region, or some other criteria to enable
more efficient aggregation.
That's the problem with the RIR's choice of issuing only /32s from which
/48s are to be assigned.
The customer has 80 bits to work with in organizing their hosts.
But the ISP has only 16 bits in a /32 to work with.