On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: > In a message written on Fri, Mar 11, 2011 at 01:07:15PM -0500, > valdis.kletni...@vt.edu wrote: >> On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: >>> rfc3927 does not require 64 bits and works sufficiently well wherever it >>> is employed. SLAAC should be redesigned to be configurable to work with >>> however many bits are available to it and it should be a standard >>> feature to turn that knob all the way from on - off with 128 bit stops >>> in between. >> >> Feel free to explain how SLAAC should work on a /96 with 32 bits of host >> address >> (or any amount smaller than the 48 bits most MAC addresses provide). >> Remember >> in your answer to deal with collisions. > > 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?
> That said, ND has built into it DAD - Duplicate Address Detection. > There is already an expectation that there will be collisions, and > the protocols to detect them are already in place. I see little > to no reason you couldn't use a different length subnet (like the > /96 in your example), randomly select an address and do DAD to see > if it is in use. Indeed, this is pretty much how AppleTalk back > in the day worked (with a 16 bit number space). > Detect, yes. Mitigate, no. DAD on the link-local results in Interface shutdown. In an environment where there's a very low probability of collision, that's an acceptable risk that is easily mitigated in most cases. In an environment where you create a much higher risk of collision, such as 1/2^32 or less, vs. 1/2^48 or more, I think that's a rather ill advised approach. > The probability of collision is pretty low, and the penalty/recovery > (picking a new address and trying again) is rather quick and cheap. > IPv6 does not try to pick a new address and try again in SLAAC, at least not what it's supposed to do. > If a service provider is going to end up giving me a /64 at home (I > know, a whole different argument) I'd vastly prefer to use /80 or /96 > subnets with either of these methods, and still be able to subnet the > space. I suspect if /64's are given out one or both will come to be > "standard". > If a service provider attempts to give ma a /64 at home, I'd opt for a new provider instead. Owen