nanog mailing list archives

RE: Using /126 for IPv6 router links


From: "TJ" <trejrco () gmail com>
Date: Mon, 25 Jan 2010 09:10:11 -0500

Good Morning!

-----Original Message-----
From: Richard A Steenbergen [mailto:ras () e-gerbil net]
Sent: Monday, January 25, 2010 05:45
To: Andy Davidson
Cc: nanog () 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).



Current thread: