In your letter dated Wed, 13 Jul 2011 01:47:32 +0200 you wrote: >But EUI-48 itself has a not-very-well-published sub-structure of a >"manufacturer's IEEE-assigned company_id" and a "manufacturer-selected >extension identifier" > >What if SLAAC was (temporarily) redefined to build EUI-64 identifiers >with the manufacturer's IEEE-assigned company_id set to a single well >known value? i.e. EUI-64 was derived from the "manufacturer-selected >extension identifier" only. > >That would effectively mean there'd be 2^24 different possible interface >identifiers per prefix.
With SLAAC you get an IPv6 address that is essentially guaranteed to be unique. There is absolutly no rule for allocating the lower 24 bits in an ehternet address. If every vendor would simply start counting at 1, you can expect a huge number of collisions. >2^24 is approx 17e6 table entries as a maximum, which may not be >excessive for most modern devices, even most embedded ones. Whereas 2^64 >has already been shown to be excessive via the ND vulnerability. There are plenty of embedded devices with a relatively small number of megabytes. There is plenty of hardware that would not support this. >Or can SLAAC and DAD be amended to 'guess and test' a new interface >identifier automatically on detection of a duplicate address [like >Appletalk node ID acquisition on Extended Networks]? > >Would 2^24 interface identifiers be large enough that RFC 4941 (privacy >extension) addresses are still reasonably useful? >[again bearing in mind the limited variation in the first 24 bits of >EUI-48 in practice] I think there is something to be said for this. Add some text that if a router advertises a prefix longer than /64 for SLAAC then the host will generate a series of random numbers, test each of them in sequence and start using one that is collision free. What may be needed is that the host will keep performing duplicate address detection periodically. On a typical home net that might make it possible to go /112. However, I much more prefer to solve the DoS problem for /64s than to just give up. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
