Internet Edge Router replacement - IPv6 route tablesizeconsiderations

Joe Maimon jmaimon at
Sat Mar 12 21:13:55 CST 2011

Leo Bicknell wrote:
> In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong wrote:
>> On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote:
>>> Well, I at least think an option should be a /80, using the 48 bits
>>> of MAC directly.  This generates exactly the same collision potential
>>> as today we have with a /64 and an EUI-64 constructed from an EUI-48
>>> ethernet address.  The router is already sending RA's for SLAAC to
>>> work, sending along one of a well-known set of masks would be a
>>> relatively minor modification.
>> How would you use that on a Firewire netowrk or FDDI or any of the
>> other media that uses 64-bit MAC addresses?
> It wouldn't.

Yes it would. It works for any size subnet that can fit both the RA node 
and the auto configuring one, from /0 - /127. And it is even backwards 


Listen to RA, discover subnet size and whether to perform 
autoconfiguration, for backwards compatibility, assume /64 size if not 
included in RA.


Generate address using phy bits, right aligned up to the lesser of 
subnet/phy size. Use 1fff as leftmost host bits if the subnet size is 64 
and the phy is 48.


Use any other algorithm that may be more desirable, such as one that 
helps preserves privacy and that contains /dev/random as one of its 
inputs. The randomness can be optionally initially confined to the 
subnet bits that exceed the phy bits, if any.


Perform DAD


Collision, goto 2b, remembering the previous values and avoiding them. 
Retry 2a and forget all avoided values when they total up to (subnet 
size ** 2) - 3.


No collision, happy surfing.


RA values change/expire, goto 1

Why is the ability to blindly embed the phy L2 into an auto-configured 
L3 address considered a prerequisite, let alone a universally good idea?

> I'm not proposing a solution for everything, just a useful case for
> some things.  I don't want to change say, RIR policy that you can
> allocate a /64, just allow operators to use /80's, or /96's in a
> more useful way if they find that useful.
> Basically I think the IETF and IPv6 propoents went a bit too far
> down the "one size fits all" route.  It has nothing to do with how
> many numbers may or may not be used, but everything to do with the
> fact that you often have to fit inside what's been given to you.
> If you're stuck with a monopoly provider who gives you a /64 to
> your cable modem there should be easy options to split it up and
> get some subnets.

Leaving scarcity behind should not mean kicking flexibility to the curb 
as well.

Just because SLAAC may work best with /64 should not mean that it must 
only work with a /64.

And failing with an unconfigurable stack when DAD detects a collision 
means that SLAAC is not a guaranteed safe general use option, contrasted 
with DHCP and the possibility of conflict detection and reaction.

Using bad design choices as justification for requiring additional ones 
simply means that SLAAC is broken as designed. It also means attempts to 
fix it are going to run up against entrenched opposition. Which is 
readily apparent.

DHCPv6 needs to be fixed with address and router options and then all 
DHCPv6 servers/helpers should be configurable to disable all RA on a 
segment by way of beaconing their own poison-reverse RA.


More information about the NANOG mailing list