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