Internet Edge Router replacement - IPv6 route tablesizeconsiderations

Hammer bhmccie at gmail.com
Mon Mar 14 14:30:04 UTC 2011


Nice article relating to the original subject of the post. I didn't see if
it had be previously posted.

http://ccie-in-3-months.blogspot.com/2011/03/trying-to-calculate-ipv6-bgp-table-in.html


 -Hammer-

"I was a normal American nerd."
-Jack Herer





On Sat, Mar 12, 2011 at 9:13 PM, Joe Maimon <jmaimon at ttec.com> wrote:

>
>
> 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
> compatible.
>
> 1)
>
> Listen to RA, discover subnet size and whether to perform
> autoconfiguration, for backwards compatibility, assume /64 size if not
> included in RA.
>
> 2a)
>
> 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.
>
> 2b)
>
> 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.
>
> 3)
>
> Perform DAD
>
> 4a)
>
> 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.
>
> 4b)
>
> No collision, happy surfing.
>
> 5)
>
> 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.
>
> Joe
>
>



More information about the NANOG mailing list