Using /126 for IPv6 router links

Mon Jan 25 14:10:11 UTC 2010

Good Morning!

> -----Original Message-----
> From: Richard A Steenbergen [mailto:ras at e-gerbil.net]
> Sent: Monday, January 25, 2010 05:45
> To: Andy Davidson
> Cc: nanog at nanog.org
> Subject: Re: Using /126 for IPv6 router links
> 
> On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote:
> > There are 4,294,967,296 /64s in my own /32 allocation.  If we only ever
> > use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952
> > /64s.  This is enough to fill over seven Lake Eries.  The total amount
> > of ipv6 address space is exponentially larger still - I have just looked
> > at 2000::/3 in these maths.
> >
> > THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.
> 
> Don't get carried away with all of that "IPv6 is huge" math, it quickly
> deteriorates when you start digging into it. Auto-configuration reduces
> it from 340282366920938463463374607431768211456 to 18446744073709551616
> (that's 0.000000000000000005% of the original 128 bit space). Now as an
> end user you might get anything ranging from a /56 to a /64, that's only
> between 1 - 256 IPs, barely a significant increase at all if you were to
> actually use a /64 for each routed IP rather than as each routed subnet.
> As a small network you might get a /48, so that even if you gave out
> /64s to everyone it would be only 16 bits of space for you (the
> equivalent of getting a class B back in IPv4 land), something like a
> 8-16 bit improvement over what a similar sized network would have gotten
> in IPv4.  As a bigger ISP you might get a /32, but it's the same thing,
> only 16 bits of space when you have to give out /48s. All we've really
> done is buy ourselves an 8 to 16 bit improvement at every level of
> allocation space (and a lot of prefix bloat for when we start using more
> than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we
> can give every molecule an IPv6 address" math of the popular
> imagination. :)

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.
**) And, using the expected /48-/56, the numbers are really 256-64k subnets.
**) Each segment supporting as many hosts as you want it to.  Probably
nowhere near 2^64, but that isn't the point :).
*) _Any_ ISP gets a /32 by default, a "bigger ISP" can readily get more.

So, actually, we have 'bought' ourselves much more space.  
*) The standard registry allocation is a /12.  So within the /3 we have 512
of those.  Note: We currently have 5 RIRs.
*) A /12 yields 20 bits of /32s.  So within any given /12, we have ~1M ISPs.
*) The "standard ISP /32" can support 64K Enterprises or 16.7M Homes.  
**) Oh, and if you need more = just ask.
*) Even allowing for inefficiency / room to grow / summarization - I think
we are good for quite some time.
*) And this is just the first /3.

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??
**) Remembering that the original address space was 'only' 32bits.
**) I guess only supporting 256-64k more registries, each of which can
support 256-64k more ISPs, each of which can support 256-64k more customers
just isn't that useful to you?
*) Additionally - the number of IPs per segment, which is not the same as
the number of hosts per segment, is much vaster.  The quite common IPv4 /24
being analogous to an IPv6 /64 ...

/TJ
PS - We also get much more multicast space, Which Is Nice(TM).