Re: simpler prefix delegation

[Ralph Droms <[e-mail]>]

Pekka,

We have some experience with the DHCPv6 spec that is useful in evaluating
its complexity.  There are roughly 6-10 full implementations of
DHCPv6, including prefix delegation, address assignment and stateless.

We performed interoperability testing of 6 or so implementations last year
at TAHI and Connectathon.  I summarized the test results in an I-D (which
has since expired).  We discovered no show-stopper interoperability problems
with the implementations under test.  There were 10 or 12 less significant
problems that were easily fixed with clarifications to the spec.  I think
these interoperability results compare very favorably with initial testing
of most IETF specs.  We were able to integrate those fixes into the spec
before it was published as RFC 3315.

I received no complaints from any of the implementors that the spec was "too
complicated" or "too heavyweight".  I infer from these results that the spec
is readable and useful as the basis for an implementation.  I also point out
that, depending on how you read the requirements, the DHCPv6 spec could
advance to Draft Standard today, as we have demonstrated interoperability
among multiple, independently developed implementations based on RFC3315.

Here's a complete CLI for configuring the Cicso DHCPv6 server in IOS (note
that this implementation in IOS resides in routers and does not require
a separate server):

(1)  ipv6 local pool cpepref 3FFE:501:1000::/44 48
(2)  ipv6 dhcp pool cpepool
       prefix-delegation pool cpepref
       dns-server 2002:1:1:11::1
       dns-server 2002:1:1:11::2
       domain-name cisco.com
       domain-name eng.cisco.com
(3)  interface FastEthernet0/0
       ipv6 dhcp server cpepool

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...

- Ralph

At 01:40 PM 3/18/2004 +0200, Pekka Savola wrote:
>On Thu, 18 Mar 2004, Shin Miyakawa wrote:
> > > when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way
> > > too heavy-weight".
> >
> > "way too Heavy Weight" is not well-defined.
> > Please explain a bit more how you decide this. Pekka ?
> >
> > When we dicuss about measurement, we should be mathematical.
> > Otherwise it sounds just a feeling or myth which
> > leads us to just a superstition.
> >
> > In this case, the information carried by the protocol
> >  - either DHCP format or whatever -  is essentially the same;
> > just a prefix information which is about 128bits + prefix length.
> > Therefore the volume of the bits are also not so different  in either 
> case.
>
>There are many kinds of complexity / "heavy-weight":
>
>  - specification complexity (how long the specs are, how difficul to
>understand, etc.) -- DHCPv6 + PD: ~120 pages.
>
>  - implementation complexity (how many lines of code, any particularly
>difficult issues, etc.) -- DHCPv6: dozens? of thousands
>
>  - requirements from the system (how does the mechanism interface with
>the routers, access databases, etc. -- e.g., do you need to have v6
>support in RADIUS databases, do you need to have customer information
>stored there, how is that communicated to the router or the DHCPv6
>server): It appears as if DHCPv6 has non-trivial set-up complexity.
>
>  - the overhead in the messages (added bytes in all or some of the
>packets): not much, unless you run PPP like described e.g. in
>draft-shirasaki-dualstack-service-03.txt
>
>  - the number of messages (how many packets (and how big) needed:
>DHCPv6 request at least two roundtrips (4 messages), if PPP is used,
>even more.
>
>It should be obvious that there is a significant difference here.
>
>The critical questions, of course are:
>  - is the difference significant enough (in any specific scenario)
>  - if yes, does it make sense to have another solution for some
>    specific scenarios (whether commonplace or not)
>
> > When I started the work of prefix delegation several years ago,
> > Steve Deering told me that ICMP and RA are very fundamental so we
> > should keep those as simple as possible.
>
>Well, I think we're discussing a very fundamental issue; it's IMHO
>much more non-sensical to invent new protocols just because we can.
>
> > Lastly, Let us recall very important fact which is that we should
> > not have many options or protocols for the same purpose.
>
>These IMHO serve slightly different purposes.  DHCPv6 provides you
>with a complex solution that works every time (well, on public LANs
>setting up the key management is a mess); this proposal is aimed at
>the simpler setups where the complexity is unnecessary and redundant.
>In such scenarios, DHCPv6 is more likely than not even used (e.g.,
>with IPv6-over-IPv4 configured tunnels) -- and should not be required
>(IMHO, of course).
>
>Let me ask another question: would you rather have proxy-ND for /64
>prefixes or a simple (non-DHCPv6) prefix delegation for /48's?
>
>--
>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
>[e-mail]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------