Assigning IPv6 /48's to CPE's?

michael.dillon at bt.com michael.dillon at bt.com
Thu Jan 3 12:25:39 UTC 2008


> > No, it gives them 16 bits for subnetting. Everybody gets
> > 64 bits for addressing because everybody (except oddballs and 
> > enevelope pushers) uses a /64 subnet size. Since 64 bits 
> are more than 
> > anyone could ever possibly need for addressing and 16 bits is more 
> > than an end site could ever possibly need for subnetting, 
> the /48 is 
> > an ideal allocation size.
> 
> As should be clear from the previous discussion, there are 
> plenty of us who disagree here, and lean towards /56 for end 
> users (typically residential customers) while business users 
> would get a /48 or more based on need.

I wouldn't say that is a disagreement, more of an extension.
In other words, many of us believe that 16 bits per end site
is an ideal customer allocation, but feel that residential 
customers in their home are not in any way penalized by
reducing this to 8 bits. They still have scope for a significant
amount of subnetting even in extreme cases like constructing an
inlaw suite plus operating a family business out of the home.

I do agree that /56 per residential customer is the ideal allocation
for a mid-sized to large ISP that has a large number of residential
customer sites on its network. I expect that most such ISPs will
implement a model with /48's to business and /56's to residential
addresses. But I also expect that smaller ISPs or those who mainly
supply business access services, will find it simpler to just give
everyone a /48.

The only place in which people have noted that there is a possibility
of running out of bits in the existing IPv6 addressing hierarchy
is when they look at a model where every residential customer gets
a /48. In that scenario there is a possibility that we might runout
in 50 to 100 years from now. If only the ISPs with a large residential
user population go to a /56 per residential site, then we have solved
the problem.

--Michael Dillon



More information about the NANOG mailing list