[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6