Re: [3gv6] Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)

<teemu.savolainen@nokia.com> Tue, 02 March 2010 15:56 UTC

Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: 3gv6@core3.amsl.com
Delivered-To: 3gv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F5F28C10A for <3gv6@core3.amsl.com>; Tue, 2 Mar 2010 07:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.798
X-Spam-Level:
X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.801, 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 b0Pv35KCG941 for <3gv6@core3.amsl.com>; Tue, 2 Mar 2010 07:56:42 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 725053A8B69 for <3gv6@ietf.org>; Tue, 2 Mar 2010 07:56:42 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o22FuYxJ006977; Tue, 2 Mar 2010 17:56:37 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 17:56:26 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 17:56:20 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 17:56:07 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 2 Mar 2010 16:56:06 +0100
From: teemu.savolainen@nokia.com
To: konrad@silmor.de
Date: Tue, 02 Mar 2010 16:56:04 +0100
Thread-Topic: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)
Thread-Index: Acq6CzHVfTCzgn3cSkWN1xOmH+2TkgADc2vw
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@NOK-EUMSG-01.mgdnok.nokia.com>
References: <1267309761.3168.5.camel@Nokia-N900-51-1> <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de>
In-Reply-To: <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de>
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: 02 Mar 2010 15:56:07.0021 (UTC) FILETIME=[DE9FB9D0:01CABA20]
X-Nokia-AV: Clean
Cc: v6ops@ops.ietf.org, otroan@employees.org, 3gv6@ietf.org
Subject: Re: [3gv6] Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)
X-BeenThere: 3gv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This mailing list is intended for discussions relating to the use of IPv6 in cellular networks." <3gv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/3gv6>, <mailto:3gv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/3gv6>
List-Post: <mailto:3gv6@ietf.org>
List-Help: <mailto:3gv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/3gv6>, <mailto:3gv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2010 15:56:43 -0000

Hi Conrad,

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

Rather the delegating router would delegate a prefix minus one /64. I.e. the one /64 would not be really assigned back to the originating link, but rather never assigned to requesting router at the first place...

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

Isn't this close to what I describe in stateless draft, i.e. having a /32 bit ISP prefix, and then using 24 lowest bits of the /64 prefix given to UE (with SLAAC) in calculating the delegated /56 prefix? In DHCPv6-"light" this calculation would be done by DR, in Stateless this would be done by RR.

Best regards,

Teemu