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
