Charlie,
Reference Point:
--------------------------------
1) Each computer will get an IPv6 address whenever it asks for
it. If it asks twice, it will get two addresses.
2) Each computer will get the same list of IPv6 addresses no
matter how often it asks.
---------------------------------
As you already know and for the record I fully agree with all your
"technical analysis" and also am a proponent of #1. You have also clearly
articulated the reasoning why a different direction was selected in this
instance than DHCPv4.
Also what is very important architecturally as you stated, nothing in
dhcpv6 prevents #2 at all.
That being said it is also imperative we ship a spec by San Diego
meeting that many implementors feel comfortable writing code to and
showing up at our bake-offs at with running code in 2001. Hats
off also to Francis Dupont and his team who have implemented this code
and that should be a positive light and message to this community as
Francis is one of our lead implementors for IPv6 for many years.
Also as editor, implementor, and WG member for the IPv6 base API we all know
APIs don't get done fast when you try to cover the future (e.g. Scoping,
Anycast Effect) and to hold up any protocol for an API is just plain bad
engineering trade-off judgement. We need to build the protocol and the
API will come. Or look at the IPv6 Advanced API that is taking some
time too. Not only that but wearing my product engineer hat it is very
bad when you keep changing the API in an emerging market which we have done
in IPv6 and we have mail from ISVs now that told us either stop or we
give up on IPv6. So premature APIs are very dangerous in the market
too.
I think your mail should be part of the input to tomorrow's design interim
meeting which I have the highest hopes for thorough and par excellence
technical and architectural discussion will take place. Ralph Droms has
done a good job putting together the agenda and is still collecting
input and also the DHCPv4 implementors are reading the drafts. This is
all goodness for IPv6 as I think many are totally convinced now that
Stateless is not the only Plug N Play solution for IPv6 the market will
want and need and my favorite metric "pay for". That in of itself has been
a long hard battle in addition to building the protocol.
I think it a good technical challenge to DHCPv6 for the folks who have
lived with DHCPv4 implementations on the street, built them, or taught and
configured them to ask the basic question of dhcpv6, why does the
protocol leave any of the models inherent to DHCPv4.
Also this protocol cannot be driven only by client/sever computing as
was DHCPv4. I will not restate what you said so well but IPv6 and the
Internet are about a lot more than client desktops, servers, and routers
but about the Internet networking fabric that has evolved beyond any of the
Pioneers expectations. DHCPv6 technically has to be extensibile and
support the future needs of Mobile and Wireless devices where ever they
may roam :-----).
Talk to you at the meeting tomorrow.
regards,
/jim
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
