Using /126 for IPv6 router links

Owen DeLong owen at
Tue Jan 26 00:43:34 UTC 2010

On Jan 25, 2010, at 9:07 AM, Richard A Steenbergen wrote:

> On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote:
>> While I agree with parts of what you are saying - that using the "simple
>> 2^128" math can be misleading, let's be clear on a few things:
>> *) 2^61 is still very, very big.  That is the number of IPv6 network
>> segments available within 2000::/3.  
>> *) An end-user should get something between a /48 and a /56, _maybe_ as low
>> as a /60 ... hopefully never a /64.  Really.
>> **) Let's call the /48s enterprise assignments, and the /56s home
>> assignments ... ?
>> **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments.
> It is if we are to follow the "always use a /64 as a single IP" 
> guidelines. Not that I'm encouraging this, I'm just saying this is what 
> we're told to do with the space. I for one have this little protocol 
> called DHCP that does IP assignments along with a bunch of other things 
> that I need anyways, so I'm more than happy to take a single /64 for 
> house as a single lan segment (well, never minding the fact that my 
> house has a /48).
I'm not sure where you're getting that.  I've always heard use a /64
as a single segment, not as a single host. 

>> **) And, using the expected /48-/56, the numbers are really 256-64k subnets.
> ...
>> Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at
>> every level of allocation space"
>> *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal??
> I'm not saying that 8-16 bits isn't an improvement, but it's a far cry
> from the bazillions of numbers everyone makes IPv6 out to be. By the
> time you figure in the overhead of autoconfiguration, restrictive
> initial deployments, and the "now that the space is much bigger, we
> should be reallocating bigger blocks" logic at every layer of
> redistribution, that is what you're left with. So far all we've really
> done with v6 is created a flashback to the days when every end user
> could get a /24 just by asking, every enterprise could get a /16 just by
> asking, and every big network could get a /8 just by asking, just bit 
> shifted a little bit. That's all well and good, but it isn't a 
> bazillion. :)
Yeah, but, that wasn't inherently bad, and, in this version of the flashback,
we actually have enough addresses to do it and still have 7/8ths
of the address space held in reserve.  

The biggest problems with the "flashback" days were:
	1.	Not enough addresses to do that on an ongoing basis.
	2.	No accountability or reclamation ability.

Problem 1 is solved by the larger number of bits at each level of the
hierarchy (/12 instead of /8 to the RIRs, /32 instead of /[12-20] to ISPs,
/48 (or /56) to end users instead of /24, and, no worries about
trying to pack 8 hosts into a /28 and dreading the day they become
15 hosts.

Problem 2 is solved by the RIR system and their respective RSAs.
As much as people grumble about paying RIR fees for their addresses,
there is definite value to the community from the RIR system.

So, to sum up...

In the current /3 IANA is using, there are enough delegations for
512 /12s to be given to RIRs.  In each /12, there's 1024k /32s.
Even if we figure that 1/4 of all ISPs need a /28, that's support
for a lot of ISPs in each RIR. (65536 if ALL ISPs needed a /28).

In each /32, an ISP can handle 65,536 customers (so a /28
supports 256k customers all at /48).  A residential ISP
can probably stretch that /48 quite a bit further by giving each
residential customer a /56 unless they specifically ask for
a /48.  In a /32, there are 16,777,216 /56s.  That still
gives the household room for 256 separate /64 networks,
which, admittedly would be sufficient even for my relatively
more intense than average network at home. (yes, I have
a /48, but, I could easily live within a /56 if such were
available when I requested my space.)


More information about the NANOG mailing list