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

<teemu.savolainen@nokia.com> Wed, 03 March 2010 21:23 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 30D2B3A8DEE for <3gv6@core3.amsl.com>; Wed, 3 Mar 2010 13:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.908
X-Spam-Level:
X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=0.691, 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 J+CpygXbvWMA for <3gv6@core3.amsl.com>; Wed, 3 Mar 2010 13:23:06 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CCCE23A8E12 for <3gv6@ietf.org>; Wed, 3 Mar 2010 13:22:52 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o23LMjZ8003295; Wed, 3 Mar 2010 23:22:47 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 23:22:47 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 23:22:42 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 3 Mar 2010 22:22:41 +0100
From: teemu.savolainen@nokia.com
To: konrad@silmor.de
Date: Wed, 03 Mar 2010 22:22:39 +0100
Thread-Topic: Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)
Thread-Index: Acq6MbSrqr33RCr5R56k/ae0loMV/gA5NWqg
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F589CA40336@NOK-EUMSG-01.mgdnok.nokia.com>
References: <1267309761.3168.5.camel@Nokia-N900-51-1> <08c08ee106e47b366ab18ca2f0a9a722.squirrel@squirrel.six.silmor.de> <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@NOK-EUMSG-01.mgdnok.nokia.com> <ab1c41801a9af836af3e300b4d3a6cce.squirrel@squirrel.six.silmor.de>
In-Reply-To: <ab1c41801a9af836af3e300b4d3a6cce.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: 03 Mar 2010 21:22:42.0072 (UTC) FILETIME=[A898F980:01CABB17]
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: Wed, 03 Mar 2010 21:23:14 -0000

Hi,

> In theory what you propose should work, but...
> 
> Let's assume we assign 2001:db8:1:200::/56 to the device.
> 
> It would give the uplink 2001:db8:1:200::/64 and say

Actually the network (AC) would advertise to the device's uplink that prefix, not the device.

> However the Access Concentrator has to deal with a paradoxical
> situation:
> several overlapping routes. If we assume the AC has host-ID ::1 and the
> CPE device or mobile phone has ::2:
> 
> 2001:db8:1:200::1/128 loops back to the AC(*)
> 2001:db8:1:200::/64 has the link as direct target without gateway
> 2001:db8:1:200::/56 goes to gateway fe80::2 via the same link

Mikael commented the longest matching prefix point, so why it wouldn't work? (From point-to-point link (PPP) point of view, the AC just needs to send all packets matching to /56 to the peer except the address it has possibly configured to its end).
 
> It may work or it may not work. The alternative is a lot more entries
> in the routing table.

Hmm.. but that problem is perhaps a problem only for the AC, right? I mean for all provisioning, policy and charging (PCC) etc entities it is just single /56 that needs to be considered per subscription, not a /56 and a /64?

> What I described below has the upside that the third route does not
> overlap with the others. It has of course the downside that it uses up
> slightly more address space.

.. and that PCC needs to consider both /56 and /64 for a single subscription, whileas in the alternative PCC has to consider only single /56.

Best regards,

Teemu