Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 08 October 2013 07:42 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F9D21E815A for <v6ops@ietfa.amsl.com>; Tue, 8 Oct 2013 00:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.843
X-Spam-Level:
X-Spam-Status: No, score=-9.843 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47ZIk-5Qpuh5 for <v6ops@ietfa.amsl.com>; Tue, 8 Oct 2013 00:42:51 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 27AB721E8159 for <v6ops@ietf.org>; Tue, 8 Oct 2013 00:42:48 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r987gjfD017653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 09:42:45 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r987gi4J009203; Tue, 8 Oct 2013 09:42:44 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r987gfSj024587; Tue, 8 Oct 2013 09:42:44 +0200
Message-ID: <5253B771.6060505@gmail.com>
Date: Tue, 08 Oct 2013 09:42:41 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Gert Doering <gert@space.net>
References: <B14A62A57AB87D45BB6DD7D9D2B78F0B2AB673CE@xmb-rcd-x06.cisco.com> <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <20131007170914.GU65295@Space.Net> <5252EFE9.2090008@gmail.com> <20131007191743.GY65295@Space.Net>
In-Reply-To: <20131007191743.GY65295@Space.Net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2013 07:42:57 -0000

Le 07/10/2013 21:17, Gert Doering a écrit :
> Hi,
>
> On Mon, Oct 07, 2013 at 07:31:21PM +0200, Alexandru Petrescu wrote:
>> Indeed it is implementation detail the vendor in question needs  to
>> solve.
>>
>> Just that solving it for DHCPv6 Prefix Delegation is going to be
>> more complex than just solving it for DHCPv6 for addresses, as the
>> bbf document presents it.
>
> Well, DHCPv6-for-addresses is about as complex if you do it via a
> relay, and the addresses do not come from a locally assigned pool.
>
> DHCPv6-for-addresses is much easier indeed if you only assign for a
> directly connected multiaccess network (cable, for example...) and do
> not have to deal with "ok, assignment has been done, now what
> addresses need to be stuffed into routing?"

Right, that is one point.  DHCPv6-for-addresses Relay bevaviour
considers that the Relay is already preconfigured statically with a
single prefix which covers all assigned addresses.  There is no need to
dynamically insert/remove that prefix upon address assignment.

On another hand, DHCPv6-for-prefixes may not consider a single prefix
covering (aggregating) all dynamically assigned prefixes.  One such case
is when the smartphone  is assigned one /64 for its ptp link and another
/64 for its LAN (one couldn't aggregate one /64 into another).

> But still, I'm not sure what the context is to make a big deal out
> of it now?

No big deal.  And yes, it is known since some time.

In DHC WG there were many drafts discussing these aspects, since some years.

Just that now we spend some time on writing a Problem Statement draft
(individual proposal) per AD suggestion.

Comments welcome here, because v6ops WG has expertise in the cellular
networks IPv6 deployments (note the 64share and related discussions).

Alex

>
> Gert Doering -- NetMaster
>