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

<teemu.savolainen@nokia.com> Sun, 28 February 2010 16:13 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 19FC03A87A9 for <3gv6@core3.amsl.com>; Sun, 28 Feb 2010 08:13:37 -0800 (PST)
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 lt4Y4vWWc+j4 for <3gv6@core3.amsl.com>; Sun, 28 Feb 2010 08:13:36 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 2585D3A8339 for <3gv6@ietf.org>; Sun, 28 Feb 2010 08:13:36 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o1SGDVuU021925; Sun, 28 Feb 2010 10:13:33 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Feb 2010 18:13:26 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Feb 2010 18:13:26 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Feb 2010 18:13:17 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Sun, 28 Feb 2010 17:13:16 +0100
From: teemu.savolainen@nokia.com
To: otroan@employees.org
Date: Sun, 28 Feb 2010 17:13:15 +0100
Thread-Topic: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)
Thread-Index: Acq3//jDCgeAj5UHRPOmKPYPLWykPAAkCZ7w
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F589C90D03E@NOK-EUMSG-01.mgdnok.nokia.com>
References: <1267309761.3168.5.camel@Nokia-N900-51-1> <9205F60F-5A7C-44BD-A2E0-B44D131C3568@employees.org>
In-Reply-To: <9205F60F-5A7C-44BD-A2E0-B44D131C3568@employees.org>
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: 28 Feb 2010 16:13:17.0610 (UTC) FILETIME=[F013A0A0:01CAB890]
X-Nokia-AV: Clean
Cc: v6ops@ops.ietf.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: Sun, 28 Feb 2010 16:13:37 -0000

Ole,

> -----Original Message-----
> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of ext Ole
> Troan
> Sent: 28. helmikuuta 2010 00:56
> To: Savolainen Teemu (Nokia-D/Tampere)
> Cc: 3gv6@ietf.org; v6ops@ops.ietf.org
> Subject: Re: Stateless Prefix Delegation I-D updated (draft-savolainen-
> stateless-pd)
>
> I think this violates the contract the RR has with the DR. you cannot
> delegate / aka give something to someone and then take back a bit of
> it. even though many managers delegate this way. ;-)
> 
> you could perhaps resolve this by making a modified PD option which
> carry a representation of the address block which allows for this.

But that is not backwards compatible..
 
> or you could just split the block in two. e.g the route on the DR is a
> /55, you delegate the bottom /56 and you use the top one for the
> linknet /64.

I thought of this as well, but it creates some waste... but maybe that could be mitigated by setting up the environment so that legacy RFC3633 compliant RR's would get half of the block given to those RRs that support the new option?

I.e. (3GPP) network policy could allocate e.g. /56 for a subscription, and if the subscriber is using legacy equipment he gets just /57, but if new equipment supporting new option then he would get /56 minus one /64?

Best regards,

Teemu