Reponding to both you and Ralph. [Ralph:] ..... > The CLI sets up a pool of prefixes for delegation(1), associates the prefix > pool with other DHCPv6 server configuration information (2) and enables the > server on an interface (3). In this example, there is no customer > identification or authentication (which is optional). It's hard to imagine > a simpler interface...
Yep -- the _interface_ can't be much simpler than that. It can be set-up easily. Then why again do we need 120+ pages, dozens of thousands of lines of codes, at least 4 messages, etc.etc. to accomplish all this? This is a very simple case, solved with *very* simple means! On Thu, 18 Mar 2004, Ole Troan wrote: > Haberman's ICMP prefix delegation draft initiated the IPv6 W.G's work > on prefix delegation. it pretty soon became clear that we were > reinventing DHCP, so instead of developing a new DHCP lookalike, we > decided to reuse the existing DHCP infrastructure instead. That was probably based on the premise that it would have had to re-implement everything that DHCP could provide. I don't make that assumption. Maybe the simple solution could be used in all the configured tunnel cases now, and 50-90% of xDSL access cases; but someone is bound to figure out uses for which one might desire something like DHCPv6 PD. I have no objection to that :). > if I understand you correctly you want to specify a separate protocol > which handles prefix delegation in a restricted setup. how is the > requesting router going to determine which prefix delegation protocol > to use? can you auto-detect that the user setup is suitable for the > 'simple' protocol? For the requestor, it doesn't really matter. If you implement both, you just run them in whichever order you want. If you get a prefix, you don't try with the other protocol. The point is to support the case if the delegator would only support one protocol (possibly the "simpler" one), not both. > as an implementor I find that implementing only one protocol to > solve a problem is less complex and results in a less heavyweight > implementation, than having to implement two protocols... If everyone would implement the more complex protocol, possibly. Of course, the question is -- why should everyone implement a complex protocol if they only need a very small part of it which can stand easily on its own? This is a similar argument to the "DNS resolver discovery" in some way, but more urgent in the sense that on dual-stack systems you don't need to discover IPv6 DNS resolver, but you still need the prefix :-). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
