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 <jmai...@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 > >