Re: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)

"Konrad Rosenbaum" <konrad@silmor.de> Tue, 02 March 2010 13:22 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EBE3A84BD for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 2 Mar 2010 05:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
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 9iI0FzQkkirJ for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 2 Mar 2010 05:22:46 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E1BF3A6922 for <v6ops-archive@lists.ietf.org>; Tue, 2 Mar 2010 05:22:46 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1NmS1p-000CRp-3X for v6ops-data0@psg.com; Tue, 02 Mar 2010 13:20:49 +0000
Received: from [2002:d9a0:db4b:1::9] (helo=p15139323.pureserver.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <konrad@silmor.de>) id 1NmS1k-000CRN-7n for v6ops@ops.ietf.org; Tue, 02 Mar 2010 13:20:44 +0000
Received: from localhost ([127.0.0.1] helo=squirrel.six.silmor.de) by p15139323.pureserver.info with esmtp (Exim 4.69) (envelope-from <konrad@silmor.de>) id 1NmS1f-0006Q3-Ol; Tue, 02 Mar 2010 14:20:40 +0100
Received: from 2002:d9a0:db4b::4 (proxying for 188.92.33.52) (SquirrelMail authenticated user konrad) by squirrel.six.silmor.de with HTTP; Tue, 2 Mar 2010 14:20:39 +0100 (CET)
Message-ID: <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de>
In-Reply-To: <1267309761.3168.5.camel@Nokia-N900-51-1>
References: <1267309761.3168.5.camel@Nokia-N900-51-1>
Date: Tue, 02 Mar 2010 14:20:39 +0100
Subject: Re: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)
From: Konrad Rosenbaum <konrad@silmor.de>
To: teemu.savolainen@nokia.com
Cc: otroan@employees.org, 3gv6@ietf.org, v6ops@ops.ietf.org
User-Agent: SquirrelMail/1.4.15
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi,

On Sat, February 27, 2010 23:29, teemu.savolainen@nokia.com wrote:
> Have you seen also
> http://tools.ietf.org/html/draft-krishnan-intarea-pd-epc-00 ? With DHCPv6
> PD there's the issue of not being able to use one /64 on the WAN from the
> delegated space. On the other hand, not having a global /64 prefix on the
> WAN at all (unnumbred model) probably would be too big change for the
> 3GPP. Any thoughts about this issue?

I assume you mean specifically section 5 of this draft - the supposed
problem with DHCPv6 not allowing to assign prefixes backward. This has
good reasons: DHCP is a forward assignment - assigning part of the
delegated prefix back to the originating link usually leads to problems
with routing.

The solution is to assign a separate portion of the provider prefix to
direct link prefixes and delegate something different from this. It
requires a bit more thinking on the network operators part, but causes
much less pain for the support hotline... ;-)

Eg. if the provider uses 2001:db8::/32 and has about 10mio customers
(24bit customer ID) one solution would be to reserve 2001:db8:0::/40 for
link assignment and 2001:db8:100::/40 through 2001:db8:ff00::/40 for PD.
As a customer I could for example get 2001:db8:11:2233::/64 via SLAAC for
the uplink and 2001:db8:1122:3300::/56 via DHCPv6 PD for delegation
downstream.



    Konrad