Internet Edge Router replacement - IPv6 route tablesizeconsiderations
bhmccie at gmail.com
Mon Mar 14 09:30:04 CDT 2011
Nice article relating to the original subject of the post. I didn't see if
it had be previously posted.
"I was a normal American nerd."
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
>>> 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
> 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
> 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