Actually, I do not understand very well why we need a new prefix delegation mechanism. The assumptions to justify such work are the complexity of DHCPv6-PD protocol and the fact that all the problems in the world are not necessarily solved by DHCPv6 but I do not see in the thread some real reasons to undertake the specification of a new mechanism for one purpose. If the DHCPv6-PD specification is too "heavy", even if it was not necessarly the point of view of implementors according to Ralph's message, I think it would be better to try to simplify the protocol than specifying a new protocol that will cause some interaction problems since customers, ISPs and vendors will have to deal with two mechanisms for one purpose.
David > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la > part de Pekka > Savola > Envoye : jeudi 18 mars 2004 15:24 > A : Ole Troan > Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Objet : Re: simpler prefix delegation > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
