Using IPv6 with prefixes shorter than a /64 on a LAN

Owen DeLong owen at delong.com
Sat Feb 5 00:06:03 UTC 2011


On Feb 4, 2011, at 8:50 AM, bmanning at vacation.karoshi.com wrote:

> On Fri, Feb 04, 2011 at 08:28:53AM -0600, Jack Bates wrote:
>> 
>> 
>> On 2/4/2011 5:03 AM, Eugen Leitl wrote:
>> 
>>> Given 
>>> http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/
>>> it is pretty clear the allocation algorithms have to change, or the 
>>> resource
>>> is just as finite as the one we ran out yesterday.
>> 
>> That's not what the author says. It says, IPv6 is only somewherein the 
>> range of 16 million to 17 billion times larger than IPv4.
> 
> 	presuming you don't adhere to the guidelines that
> 	insist on the bottom 64 bits being used as a "MAC" address
> 	and the top 32 bits being used as an RIR identifier.
> 
1.	The top 12 bits identify the RIR, not the top 32.
2.	The bits somewhere between 12 and 32 identify the LIR or ISP.
3.	Those facts do not reduce the available number of network numbers.

Yes, EUI-64 could be argued to impinge on that, except that EUI-64
only addresses the lower 64 bits. The upper 64 bits provide about
17 billion times as many network numbers as there are host numbers
in IPv4. That's without accounting for the fact that ~25% of the IPv4
addresses are unusable as unicast host addresses.

> 	in reality, IPv6 (as specified by many IETF RFCs and as implemented
> 	in lots of codes bases) only has 32 usable bits... just like IPv4.
> 
Um, in reality, no, that is NOT the case.

>> Let's be realistic. A /32 (standard small ISP) is equiv to an IPv4 
>> single IP. A /28 (medium ISP) is equiv to an IPv4 /28. A /24 (high 
>> medium, large ISP) is equiv to an IPv4 /24. A /16 (a huge ISP) is equiv 
>> to an IPv4 /16. Get the picture?
> 
> 	sho'huff.  the real question is, how will you manage your own 32bits
> 	of space?  this is a change from the old v4 world, when the question
> 	was, how will you manage your (pre CIDR) 8bits (or 16bits, or 24bits) 
> 	of space?

Among others.

Owen





More information about the NANOG mailing list