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