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

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

Return-Path: <konrad@silmor.de>
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 3B20528C13B for <3gv6@core3.amsl.com>; Tue, 2 Mar 2010 09:56:23 -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 2t51Rw6aASSu for <3gv6@core3.amsl.com>; Tue, 2 Mar 2010 09:56:22 -0800 (PST)
Received: from p15139323.pureserver.info (nine.six.linux-info-tag.de [IPv6:2002:d9a0:db4b:1::9]) by core3.amsl.com (Postfix) with ESMTP id 4409A28C1D6 for <3gv6@ietf.org>; Tue, 2 Mar 2010 09:56:22 -0800 (PST)
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 1NmWKR-0007PQ-Sm; Tue, 02 Mar 2010 18:56:20 +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 18:56:19 +0100 (CET)
Message-ID: <ab1c41801a9af836af3e300b4d3a6cce.squirrel@squirrel.six.silmor.de>
In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F589C9BCEE7@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>
Date: Tue, 02 Mar 2010 18:56:19 +0100
From: Konrad Rosenbaum <konrad@silmor.de>
To: teemu.savolainen@nokia.com
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
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 17:56:23 -0000

Hi,

On Tue, March 2, 2010 16:56, teemu.savolainen@nokia.com wrote:
> 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...

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 2001:db8:1:201::/64
to its WLAN port. For the device itself everything is fine - its routing
table contains two orthogonal /64 routes.

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

(*)some IPv6 stacks may omit this one

It may work or it may not work. The alternative is a lot more entries in
the routing table.

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.

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

Correct.


   Konrad