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