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

Ole Troan <otroan@employees.org> Sat, 27 February 2010 12:11 UTC

Return-Path: <ichiroumakino@gmail.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 085F43A8760 for <3gv6@core3.amsl.com>; Sat, 27 Feb 2010 04:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Level:
X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 suu2MMmB3H6y for <3gv6@core3.amsl.com>; Sat, 27 Feb 2010 04:11:00 -0800 (PST)
Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id D445A3A8400 for <3gv6@ietf.org>; Sat, 27 Feb 2010 04:10:58 -0800 (PST)
Received: by bwz3 with SMTP id 3so712660bwz.29 for <3gv6@ietf.org>; Sat, 27 Feb 2010 04:13:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=xmP0J9JbaJxWAq2w0pQgU3iSfweYfyxxG0Ygeao5NIY=; b=NpM9inarNyMWz6G4plPRBlQacxDKlPVlnB6fHQ2TaPz6CydE1seNEvCST/t5EYCYz0 RgS5Pm2h4u4XAbs0JOQS+Ox63BgXqL15IzQQIoB+1aBEQe4PfaaagJI1Rj5sMzR3qctd yCGjdCWnQifFIhh8cvHc/dx92Iwoz/xLmMk2I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=nygr9Wb4JR3Xv6Rgm2gwC4kizdGuPz5B154h28oYAygUTmntEYXmaJ9rF9awLp3jDU eRoRPV19Xj3lYb5BLH0JHTHE9nHHZkmn28DP+7etvPCvKW7PQGgCt+ogYlnfREIF0Lxf HqDa7e30Mv75lyXb2FGdhK9iP2gOhi3nkaHVc=
MIME-Version: 1.0
Sender: ichiroumakino@gmail.com
Received: by 10.204.34.24 with SMTP id j24mr1204636bkd.147.1267272793143; Sat, 27 Feb 2010 04:13:13 -0800 (PST)
In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F589C90CAFE@NOK-EUMSG-01.mgdnok.nokia.com>
References: <18034D4D7FE9AE48BF19AB1B0EF2729F589C90CAFE@NOK-EUMSG-01.mgdnok.nokia.com>
Date: Sat, 27 Feb 2010 13:13:13 +0100
X-Google-Sender-Auth: 9a99a4c8664af6a7
Message-ID: <2bbba3c11002270413v7b24e31fi966d7ae87868e6f@mail.gmail.com>
From: Ole Troan <otroan@employees.org>
To: teemu.savolainen@nokia.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 27 Feb 2010 07:28:41 -0800
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: Sat, 27 Feb 2010 12:11:01 -0000

Teemu,

note, that I'm probably biased since I was one of the co-authors of RFC3633. ;-)

am I interpreting the motivation of this draft correctly if I say that
you aren't concerned about the 2 or 4 packet DHCPv6 exchange between
the RR and the DR, but rather about the DHCP binding state and
resulting DHCP backend infrastructure?

if that is correct, couldn't you still run DHCP PD, but the prefixes
handed out are on the DR generated based on the other identifiers
described in your draft? then you don't need any further DHCP
infrastructure, changes on the RR or any new protocol machinery
between the RR and DR.

a delegated prefix is expected to have a 'reasonable' lifetime. rapid
renumbering or some would say renumbering at all is problematic. if
you bind a prefix to given L2 identifiers, doesn't that mean that you
will renumber every time your connection to the network changes?

cheers,
Ole


On Fri, Feb 26, 2010 at 12:48 PM,  <teemu.savolainen@nokia.com> wrote:
> Hi,
>
> We have updated the Stateless IPv6 Prefix Delegation draft with the following significant changes (in addition to various minor changes):
>
> * Describing better that GTP TEID or GRE Key or similar could be used to construct the delegated prefix
>
> * Describing address space waste mitigation ways: dedicated APN (in 3GPP), and emphasizing need to optimize the size of the delegated prefixes
>
> * Aggregating prefixes so that the /64 of the WAN interface (e.g. used for PDP context) is now part of the shorter-than-/64 prefix allocated to a node. I.e. a node may be allocated, for example, a single /60, of which one /64 is taken for WAN link by the gateway, leaving the rest for the node to use for downstream advertisement/delegation purposes
>
> * Added a note that while possible, it may not be feasible, to delegate prefixes from different subnets (possible if one configures multiple ISP prefixes, but that would increase address space consumption even more)
>
> ------
> http://www.ietf.org/id/draft-savolainen-stateless-pd-01.txt
>
> Abstract:
> This document describes an automatic and stateless IPv6 prefix delegation solution for IPv6-only and dual-stack access networks.
> The solution builds on automatic delegation mechanism defined by 6RD, but is suitable for IPv6-only networks, including those that have not deployed stateful DHCPv6.  The described stateless approach essentially exchanges the complexity of the stateful prefix delegation to increased consumption of IPv6 address space and less flexible properties.
> ------
>
> All comments are welcome.
>
> Best regards,
>
> Teemu
>
>