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> Mon, 07 October 2013 13:58 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 0912A21F9E83 for <v6ops@ietfa.amsl.com>; Mon, 7 Oct 2013 06:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.005
X-Spam-Level:
X-Spam-Status: No, score=-10.005 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 0g14WHQaosUn for <v6ops@ietfa.amsl.com>; Mon, 7 Oct 2013 06:58:25 -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 A2C7121F9E6C for <v6ops@ietf.org>; Mon, 7 Oct 2013 06:58:24 -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 r97DwN8m021551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Oct 2013 15:58:23 +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 r97DwMfq018046; Mon, 7 Oct 2013 15:58:22 +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 r97DwJ8q031126; Mon, 7 Oct 2013 15:58:22 +0200
Message-ID: <5252BDFA.8040907@gmail.com>
Date: Mon, 07 Oct 2013 15:58:18 +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: Vízdal Aleš <ales.vizdal@t-mobile.cz>, Mikael Abrahamsson <swmike@swm.pp.se>
References: <52526E71.4050402@gmail.com> <alpine.DEB.2.02.1310071023000.20065@uplift.swm.pp.se> <52529E67.3000905@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD8771BDD53@SRVHKE02.rdm.cz>
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD8771BDD53@SRVHKE02.rdm.cz>
Content-Type: text/plain; charset="ISO-8859-2"; 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: Mon, 07 Oct 2013 13:58:30 -0000

Le 07/10/2013 14:19, Vízdal Aleš a écrit :
>> -----Original Message----- From: v6ops-bounces@ietf.org
>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu
>> Sent: Monday, October 07, 2013 1:44 PM To: Mikael Abrahamsson Cc:
>> v6ops@ietf.org Subject: Re: [v6ops] Need ref to 3GPP spec for the
>> use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering
>>
>> Le 07/10/2013 10:33, Mikael Abrahamsson a écrit :
>>> On Mon, 7 Oct 2013, Alexandru Petrescu wrote:
>>>
>>>> Hello,
>>>>
>>>> I need a reference to a 3GPP spec which requires or explains
>>>> the use of DHCPv6 Prefix Delegation for smartphone tethering
>>>> (mobile hotspot).
>>>>
>>>> This is because we write a problem statement draft in DHC WG
>>>> ""Route Problem at Relay during DHCPv6 Prefix Delegation".
>>>>
>>>> I would like that draft to reflect the problem not only in the
>>>>  homenet-kind of deployments (DSL, broadband forum) but also
>>>> smartphone deployments.
>>>
>>> http://www.3gpp.org/ftp/Specs/html-info/23402.htm
>>>
>>> If you download the 10.8.0 spec you will find:
>>>
>>> "4.7.5    IPv6 Prefix Delegation using S2c Optionally a single
>>> network prefix shorter than a /64 prefix may be assigned to a PDN
>>> connection (TS 23.401 [4]). When S2c is used to access a PDN, the
>>> UE acting as a Mobile Router may request delegation of one or
>>> more IPv6 prefix(es) via DHCPv6 Prefix Delegation signalling as
>>> described in RFC 6267 [56]. The UE does not need to explicitly
>>> register these additional prefixes using S2c signaling as
>>> implicit mode registration is used."
>>
>> Thanks for the reference.  This is the kind of use at 3GPP that I
>> am looking for.  I will use it right away.
>>
>> (for info: there are some errors in the above text (I guess they
>> mean RFC 6276 bit 6267; second, I doubt Prefix Delegation with
>> NEMO is needed in this context - but rather simple PD without
>> tunnels; RFC 6276 assumes the Relay is on the mobile router,
>> whereas the cellular deployment would host the Relay in the fixed
>> network).)
>
> I guess that the right RFCs shall be 3633 & 6603.

I think yes, sure, that's better, that's the pure PD and the PD-exclude
RFCs.  Not sure about the necessity of PD-exclude in a 3GPP specific
scenario, but there may exist a reason for that -exclude.

Remark though that in that spec I couldnt find enunciating a problem of
routing at Relay, during the Prefix Delegation process.

It's strange, because the broadband forum _has_ identified such a problem.

Either there is no problem, in which case 3gpp would rather advise bf to
not worry  about it; or there is, and 3gpp would need to ack it.

Alex
PS: the BroadBand's problem at Relay during Prefix Delegation is
described in technical report titled "IPv6 in the context of TR-101",
dated November 2010 as:
> "hosts receiving IPv6 addresses from the RR are not known to the
> BNG, i.e. the BNG is not aware of what addresses/prefixes are
> assigned to hosts attached to the RG acting as RR."