[v6ops] Announcing draft-petrescu-relay-route-pd-problem-00 (was: Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 22 October 2013 11:36 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7D12B11E8155 for <v6ops@ietfa.amsl.com>; Tue, 22 Oct 2013 04:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.905
X-Spam-Status: No, score=-9.905 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kZ5mgHPMXc2N for <v6ops@ietfa.amsl.com>; Tue, 22 Oct 2013 04:35:53 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 911AF11E818B for <v6ops@ietf.org>; Tue, 22 Oct 2013 04:35:22 -0700 (PDT)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr []) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r9MBZIA1028097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <v6ops@ietf.org>; Tue, 22 Oct 2013 13:35:18 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr []) by nephilia.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r9MBZItA001244 for <v6ops@ietf.org>; Tue, 22 Oct 2013 13:35:18 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [] (is010446-4.intra.cea.fr []) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r9MBZEnl001583 for <v6ops@ietf.org>; Tue, 22 Oct 2013 13:35:18 +0200
Message-ID: <526662F2.1060808@gmail.com>
Date: Tue, 22 Oct 2013 13:35:14 +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.1
MIME-Version: 1.0
To: "v6ops@ietf.org" <v6ops@ietf.org>
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> <5253C891.7090009@gmail.com>
In-Reply-To: <5253C891.7090009@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [v6ops] Announcing draft-petrescu-relay-route-pd-problem-00 (was: 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, 22 Oct 2013 11:36:03 -0000

Hello participants to v6ops WG,

We have just submitted draft-petrescu-relay-route-pd-problem-00
"Route Problem at Relay during DHCPv6 Prefix Delegation"
M. Boucadair (France Telecom)
L. Yeh (Freelancer Technologies)
A. Petrescu (CEA).

It presents a problem of routing at Relay during Prefix Delegation of
DHCPv6; also lists some solutions I-Ds.  The problem may be relevant in
the DHC WG, at the Broadband Forum and maybe at 3GPP.

Please comment on this draft.



Le 08/10/2013 10:55, Alexandru Petrescu a écrit :
> 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
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops