Re: simpler prefix delegation

Pekka Savola <pekkas@netcore.fi> Thu, 18 March 2004 11:47 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04530 for <ipv6-archive@odin.ietf.org>; Thu, 18 Mar 2004 06:47:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vzZ-0005Th-Mi for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 06:47:18 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IBlH65021048 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 06:47:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vzZ-0005TO-Dx for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 06:47:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04498 for <ipv6-web-archive@ietf.org>; Thu, 18 Mar 2004 06:47:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vzV-0006Yl-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 06:47:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vyX-0006QG-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 06:46:14 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3vxX-0006De-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 06:45:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vwP-00052q-OX; Thu, 18 Mar 2004 06:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vvh-00051V-MB for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 06:43:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04304 for <ipv6@ietf.org>; Thu, 18 Mar 2004 06:43:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vvd-00060u-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:43:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vuf-0005tV-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:42:13 -0500
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vtg-0005gd-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:41:12 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IBeTq29718; Thu, 18 Mar 2004 13:40:29 +0200
Date: Thu, 18 Mar 2004 13:40:29 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Shin Miyakawa <miyakawa@nttv6.jp>
cc: ipv6@ietf.org, skylane@etri.re.kr, erik.nordmark@sun.com
Subject: Re: simpler prefix delegation
In-Reply-To: <20040318.184737.71091593.miyakawa@nttv6.jp>
Message-ID: <Pine.LNX.4.44.0403181224040.27890-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60

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