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 --------------------------------------------------------------------
- Re: simpler prefix delegation Pekka Savola
- simpler prefix delegation Pekka Savola
- Re: simpler prefix delegation Pekka Savola
- Re: simpler prefix delegation Ralph Droms
- Re: simpler prefix delegation Ole Troan
- Re: simpler prefix delegation Ole Troan
- Re: simpler prefix delegation Laurent.Clevy
- Re: simpler prefix delegation Pekka Savola
- Re: simpler prefix delegation Pekka Savola
- RE: simpler prefix delegation BINET David FTRD/DMI/CAE
- Re: simpler prefix delegation Alain Durand
- Re: simpler prefix delegation Brian E Carpenter
- Re: simpler prefix delegation Christian Strauf
- RE: simpler prefix delegation Byung-Yeob Kim
- Re: simpler prefix delegation Pekka Savola
- Re: simpler prefix delegation Ralph Droms
- Re: simpler prefix delegation Pekka Savola
- Re: simpler prefix delegation Ole Troan
- RE: simpler prefix delegation Christian Huitema
- Re: simpler prefix delegation JINMEI Tatuya / 神明達哉
- Re: simpler prefix delegation Erik Nordmark
- Re: simpler prefix delegation Fred Templin
- Re: simpler prefix delegation Ralph Droms
- Re: simpler prefix delegation Wataru Kawakami -ipv4-
- Re: simpler prefix delegation Ole Troan
- RE: simpler prefix delegation matthew.ford
- Re: simpler prefix delegation Ralph Droms
- Re: simpler prefix delegation Shin Miyakawa