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 08:56 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 0595621E818E for <v6ops@ietfa.amsl.com>; Tue, 8 Oct 2013 01:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.975
X-Spam-Level:
X-Spam-Status: No, score=-9.975 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 LqcuyLEk0UnV for <v6ops@ietfa.amsl.com>; Tue, 8 Oct 2013 01:55:54 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9F76F21E8169 for <v6ops@ietf.org>; Tue, 8 Oct 2013 01:55:53 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r988tn6L011642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 10:55:49 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r988tnTo020540; Tue, 8 Oct 2013 10:55:49 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r988tj8f011992; Tue, 8 Oct 2013 10:55:49 +0200
Message-ID: <5253C891.7090009@gmail.com>
Date: Tue, 08 Oct 2013 10:55:45 +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>, "Rajiv Asati (rajiva)" <rajiva@cisco.com>, Mikael Abrahamsson <swmike@swm.pp.se>
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> <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> <5253B80E.7030008@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD877245410@SRVHKE02.rdm.cz>
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD877245410@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: Tue, 08 Oct 2013 08:56:01 -0000

Le 08/10/2013 10:49, Vízdal Aleš a écrit :
>>> The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP
>>> through all the intermediate nodes.
>>
>> Ah, right, there is a GTP tunnel above all the intermediary IP
>> nodes.
>>
>> However, even when a tunnel is dynamically set up, a routing table
>>  entry is added in the Relay's routing table (or other similar
>> entry).  The parameters of that entry necessarily include, among
>> others, the prefix which is allocated.
>>
>> No?
>
> The tunnel stays up for the lifetime of the PDP/PDN context.

Ok.

> There is no relay in the 3GPP access architecture.

Ok.

> If the tunnel drops, the PGW/GGSN will remove the route from their
> routing table, once a new tunnel is setup the routing table is
> updated accordingly.

The route associated with that tunnel should contain a parameter 
containing the Delegated Prefix.  When there is no delegated prefix, 
that route entry should be updated.

The tunnel could stay up but only for the Smartphone.  Or it could stay 
up for both the Smartphone _and_ the Hosts in the smartphone's LAN. 
These are two different things.

Alex


>
>> Alex
>
> Ales
>
>