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

Re: simpler prefix delegation



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