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