Addressing plan exercise for our IPv6 course

Owen DeLong owen at delong.com
Sat Jul 24 08:40:19 UTC 2010


On Jul 23, 2010, at 1:26 PM, Matthew Kaufman wrote:

> sthaug at nethelp.no wrote:
>>> It is not about how many devices, it is about how many subnets, because you
>>> may want to keep them isolated, for many reasons.
>>> 
>>> It is not just about devices consuming lots of bandwidth, it is also about
>>> many small sensors, actuators and so.
>>>    
>> 
>> I have no problems with giving the customer several subnets. /56 is
>> just fine for that.
> /56? How about /62? That certainly covers "several"... and if you're really worried they might have too many subnets for that to work, how about /60?

/60 at a bare minimum since you can do RDNS delegation on /x boundaries where x%4==0.

RDNS for a /62 is do-able, but, it requires 4 zone files and 4 sets of parent NS records instead of 1.
/62 for 4 customers ends up requiring 16 zone files and 16 sets of parent NS records instead of 4.

>> I haven't seen any kind of realistic scenarios
>> which require /48 for residential users *and* will actually use lots
>> and lots of subnets - without requiring a similar amount of manual
>> configuration on the part of the customer.
>> 
>> So we end up with /56 for residential users.
>>  
> Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up.
> 
Yes... Overkill is a good thing in IPv6. Even with this level of overkill, fully deploying the current world with a /48 for every house consumes less than 0.1% of the address space.

(Apprximately 4x10^9 households on earth getting a /48 each = roughly one /16 which is 1/65,536th of the total address space and 1/8192nd of 2000::/3)

What is the harm in doing so?

Why not minimize provisioning effort and maximize user flexibility by consuming a very tiny fraction of a plentiful resource which costs virtually nothing?

Owen





More information about the NANOG mailing list