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. > > no, it was made on the assumption that the protocol would have to > fulfill the requirements as stated in the requirements document.
What I proposed does this; let's see: 3.1 Number and Length of Delegated Prefixes ==> fills all three requirements. 3.2 Use of Delegated Prefixes in Customer Network ==> fills both requirements. 3.3 Static and Dynamic Assignment The prefix delegation mechanism should allow for long-lived static pre-assignment of prefixes and for automated, possibly short-lived on-demand dynamic assignment of prefixes to a customer. ==> both allowed. (The former obviously requires configuration, but this is no different from DHCPv6.) The short-lived delegation case may profit from the lifetime associated with the prefix. 3.4 Policy-based Assignment The prefix delegation mechanism should allow for the use of policy in assigning prefixes to a customer. For example, the customer's identity and type of subscribed service may be used to determine the address block from which the customer's prefix is selected, and the length of the prefix assigned to the customer. ==> policy is outside the scope of the proposal, but this is a "should" so it fulfills the requirements even as-is. Obviously, this is supported if a database or similar includes notion of policy in terms of customer interfaces (or the like), or if you use the authentication/user identification option. 3.5 Security and Authentication The prefix delegation mechanism must provide for reliable authentication of the identity of the customer to which the prefixes are to be assigned, and must provide for reliable, secure transmission of the delegated prefixes to the customer. ==> yes (incoming interface or other customer identification, SEND, or the authentication/identification option), yes (SEND). 3.6 Accounting ==> yes. 3.7 Hardware technology Considerations The prefix delegation mechanism should work on any hardware technology and should be hardware technology independent. The mechanism must work on shared links. The mechanism should work with all hardware technologies either with an authentication mechanism or without, but ISPs would like to take advantage of the hardware technology's authentication mechanism if it exists. ==> yes; yes for shared links (requires authentication in some means as above; equally problematic with DHCPv6); yes. So, it seems all the requirements are fulfilled, with much lower amount of complexity. > can you please specify exactly what you want to simplify? it is hard > to argue against vague statements like 'complex' and 'heavyweight'... I want to simplify the protocol, for the protocol to be simple and easy to understand, and trivial to implement. DHCPv6 PD spec is about 20 pages long; that is one primer: the whole protocol should be no longer than that. Of course, all of this is a moot point if the consensus is that full DHCPv6 must be implemented by every box (especially if it could be used as a router); but I don't think such exists. -- 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 --------------------------------------------------------------------
