Still on IPv6 prefix delegation

<teemu.savolainen@nokia.com> Mon, 26 October 2009 08:54 UTC

Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615B028C187 for <ipv6@core3.amsl.com>; Mon, 26 Oct 2009 01:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YciO45a99GKn for <ipv6@core3.amsl.com>; Mon, 26 Oct 2009 01:54:45 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B5E8828C102 for <ipv6@ietf.org>; Mon, 26 Oct 2009 01:54:19 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9Q8rRbD011345 for <ipv6@ietf.org>; Mon, 26 Oct 2009 03:54:32 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:53:41 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:53:41 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 26 Oct 2009 09:53:40 +0100
From: teemu.savolainen@nokia.com
To: ipv6@ietf.org
Date: Mon, 26 Oct 2009 09:52:06 +0100
Subject: Still on IPv6 prefix delegation
Thread-Topic: Still on IPv6 prefix delegation
Thread-Index: AcpWGZiYPuKGlQ1TS7KlPoswONrRZQ==
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F5166931EC8@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Oct 2009 08:53:41.0194 (UTC) FILETIME=[D0DF32A0:01CA5619]
X-Nokia-AV: Clean
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2009 08:54:46 -0000

Hi All,

The DHCPv6 Prefix Delegation, as per RFC3633, is currently The Standard Way for IPv6 Prefix Delegation. 

Additionally, 6to4 (RFC3056) describes how a site having a public IPv4 address can automatically configure an unique /48 IPv6 address prefix.

Furthermore, 6RD (http://tools.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-00.txt) expands the concept by allowing use of private IPv4 addresses and introducing configurable prefix lenghts (e.g. /56).

Both 6to4 and 6RD, however, require IPv4 to work and both of them use encapsulation.

While marvelling these solutions, I started to wonder why couldn't we have stateless prefix delegation on IPv6-only environments as well, where instead of IPv4 addresses some other source of uniqueness would be used, such as bits from unique IPv6 address, unique /64 prefix, L2 identifier and so on.

I wrote a draft that builds on 6RD and describes my thoughts: 

   "Stateless IPv6 Prefix Delegation for IPv6 enabled networks"
   http://tools.ietf.org/internet-drafts/draft-savolainen-stateless-pd-00.txt

   "This document describes an automatic and stateless IPv6 prefix
   delegation solution for IPv6-only networks.  The solution builds on
   automatic delegation mechanism defined by 6RD, but is suitable for
   IPv6-only networks, including those that have not deployed stateful
   DHCPv6.  The described stateless approach essentially exchanges the
   complexity of the stateful approach to consumption of IPv6 address
   space and more statical properties."

I would be happy if you could please educate me on what would be the biggest controversies of such an approach?

Thank you,

	Teemu