The IP over ATM Mailing List Archive by date

[Steve Deering <deering@parc.xerox.com>]

kre,

> The problem that we have with IPv4 addresses now isn't that
> 2^32 numbers (give or take) isn't enough to number all the
> internet devices will have for a long time to come, but that
> so much of the address space is wasted establishing the hierarchy
> that is needed to make the thing routable.
> 
> I am personally not at all worried about IEEE addresses
> running out any time any of us will care a lot about it.

I agree with your basic point, however I'd just like to observe that
IEEE 802/Ethernet addresses do include an administrative hierarchy
(they are divided into 2 flag bits + 22-bit OUI + 24-bit remainder)
which could conceivably lead to premature exhaustion, e.g., if lots
of organization got their own OUI and then failed to use a significant
part of their 24-bit space.  It would be really interesting to see the
OUI consumption curve.

*However*, even if IEEE 802ng comes out with 64 bit addresses, I'd advocate
simply hashing those longer addresses down to 48 bits for use in the lowest-
order field of a statelessly-autoconfigured IPv6 address.  It shouldn't be
difficult to devise a hash from 64 bits to 48 bits that has negligible
probability of collision -- probably just dropping the high-order bits
would do.

That is also what I would suggest for IPv6-over-ATM, if there really is
a case of ATM interfaces without wired-in IEEE 802 addresses -- simply
hash the NSAP address or E.164 address or whatever into 48 bits (or into
the 46-bit non-multicast, non-global IEEE 802 space, if those nodes may
co-exist on links with other ATM nodes that *do* use global IEEE 802
addresses as their v6 tokens).

Regarding duplicate address tokens:

IPv6 Duplicate Address Detection was designed under the assumption that
duplicates would be very rare; it was intended more to catch configuration
errors in human-assigned IPv6 addresses assigned through DHCP or manual
configuration of a node itself, than to catch duplicate Ethernet addresses.
If we create scenarios (like some that have been mentioned here) where
there is a significant probability of duplicate tokens, and depend on DAD
to detect and recover from those duplicates, then we will have to change
ND to specify that the DAD process be run periodically and frequently by all
nodes on a link, to detect possible duplicates that weren't detected at
start-up time due to the link being partitioned or the host being
temporarily disconnected (in an undetectable way) from the link.  I'd rather
not incur all that gratuitous control traffic, just to accomodate sleazy
vendors of spec-violating Ethernet cards, or ATM.

Steve