IETF Logo Mail Archive

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

<teemu.savolainen@nokia.com> Sun, 28 February 2010 16:20 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 160DD3A87C0 for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 28 Feb 2010 08:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.547
X-Spam-Level:
X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 XYK6KnBfil8U for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 28 Feb 2010 08:20:18 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2668D3A8695 for <v6ops-archive@lists.ietf.org>; Sun, 28 Feb 2010 08:20:18 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Nllm1-000JyQ-JL for v6ops-data0@psg.com; Sun, 28 Feb 2010 16:13:41 +0000
Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <teemu.savolainen@nokia.com>) id 1Nllly-000Jxv-2Z for v6ops@ops.ietf.org; Sun, 28 Feb 2010 16:13:38 +0000
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
CC: 3gv6@ietf.org, v6ops@ops.ietf.org
Date: Sun, 28 Feb 2010 17:13:15 +0100
Subject: RE: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)
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
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

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

v2.23.0 | Report a Bug | By Email