RE: simpler prefix delegation

["BINET David FTRD/DMI/CAE" <david.binet at francetelecom.com>]

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 : ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]De la 
> part de Pekka
> Savola
> Envoye : jeudi 18 mars 2004 15:24
> A : Ole Troan
> Cc : ipv6@ietf.org; rdroms@cisco.com; skylane@etri.re.kr;
> erik.nordmark@sun.com
> 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
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------