ipv6 addressing - non-routable equivalents?

[Robert Elz]

    Date:        Sun, 8 Oct 2000 10:30:10 -1000 (HST)
    From:        Antonio Querubin <tony@lava.net>
    Message-ID:  <Pine.BSI.4.10.10010081003340.5739-100000@malasada.lava.net>

  | Working at an ISP that has thousands of
  | customers and IP addresses to manage I see the problems in integrating
  | MAC-based addressing as outweighing the 'potential' benefits for a long
  | time to come.

If on your nets you want to use DHCP (ie: you have someone employed whose
job it is to manage such a thing, which you probably do), then IPv6 lets
you tell all the clients to use DHCP to fetch addresses (DHCPv6 that is,
as they have to ve v6 addresses fetched, obviously).

It was always known and accepted that there would be sites that would want
easy automatic address configuration, and others which prefer centralised
address management - the IPv6 specs support both.   You get to choose when
you configure your routers (and you get to choose per subnet).

  | Bad assumption.  As a multi-homed ISP I do understand the issues.  I just
  | want to drive home the point that while some may think that MAC-based
  | addressing is some kind of holy grail, others may feel otherwise
  | especially when other management issues are taken into consideration.

Yes, so what is the problem supposed to be?  No-one is forcing MAC based
IPv6 addresses upon anyone.

  | The widespread adoption of MAC-based addressing has some serious hurdles
  | to overcome.

You mean that if I choose to use MAC based addressing, it somehow creates
a problem for you?   Unless you were being forced to use MAC based addresses
(for the nets upon which you assign addresses) what's the problem?

  | In the meantime, I don't see why more traditional schemes
  | can't continue to be used or be discouraged in favor of MAC-based
  | addressing.

They can be used.   You seem to be totally unaware of just what is in the
IPv6 specs.  I'd encourage you to go read them before critisising what you
obviously don't really understand.

kre