Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 07 December 2020 17:57 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B12E3A040B for <ipv6@ietfa.amsl.com>; Mon, 7 Dec 2020 09:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.648
X-Spam-Level:
X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3qqvexqckFP for <ipv6@ietfa.amsl.com>; Mon, 7 Dec 2020 09:57:16 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE903A0408 for <ipv6@ietf.org>; Mon, 7 Dec 2020 09:57:16 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0B7HvAwl001236; Mon, 7 Dec 2020 18:57:10 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1B1C220B833; Mon, 7 Dec 2020 18:57:10 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 09CF320B699; Mon, 7 Dec 2020 18:57:10 +0100 (CET)
Received: from [10.11.244.63] ([10.11.244.63]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0B7Hv9O5027526; Mon, 7 Dec 2020 18:57:09 +0100
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
To: David Allan I <david.i.allan@ericsson.com>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "ipv6@ietf.org" <ipv6@ietf.org>
References: <d839b04e8c6840edaf042478964ce793@boeing.com> <BY5PR15MB37150A20A6CD1144A22A3F9AD0FB0@BY5PR15MB3715.namprd15.prod.outlook.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <957e108e-1899-6706-22ed-b40ac5175b05@gmail.com>
Date: Mon, 7 Dec 2020 18:57:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <BY5PR15MB37150A20A6CD1144A22A3F9AD0FB0@BY5PR15MB3715.namprd15.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yzbaKoJqEw-VeIcPitZsh0_8ymI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2020 17:57:19 -0000


Le 24/11/2020 à 23:28, David Allan I a écrit :
> FWIW for a 5G UE, the SMF assigns the interface ID used for LLA etc.
> as part of the PDU session setup.  See TS24.501 clause 9.11.4.10.

I will add a  reference to this document to the DANIR draft in the V6OPS WG.

I would like to ask whether typing 'what is my IP address' in the google
search bar of a 5G-connected smartphone displays an IPv6 address?

Alex

> 
> Cheers D
> 
> -----Original Message----- From: ipv6 <ipv6-bounces@ietf.org> On
> Behalf Of Templin (US), Fred L Sent: Tuesday, November 24, 2020 1:52
> PM To: Alexandre Petrescu <alexandre.petrescu@gmail.com>om>;
> ipv6@ietf.org Subject: Re: [v6ops] How do you solve 3GPP issue if
> neither operator nor handset supports PD?
> 
> Alex, see below:
> 
>> -----Original Message----- From: ipv6
>> [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandre Petrescu 
>> Sent: Tuesday, November 24, 2020 1:33 PM To: ipv6@ietf.org Subject:
>> Re: [v6ops] How do you solve 3GPP issue if neither operator nor
>> handset supports PD?
>> 
>> 
>> Le 24/11/2020 à 17:44, Templin (US), Fred L a écrit :
>>> Getting what I said earlier onto this thread, I think we should
>>> be discussing the LLA-based PD scheme specified in:
>>> 
>>> https://datatracker.ietf.org/doc/draft-templin-6man-lla-type/
>>> 
>>> What is unique and compelling about this scheme is that it
>>> brings down two birds with one stone; in a single RS/RA exchange,
>>> the mobile node receives both 1) an IPv6 PD, and 2) an LLA that
>>> is guaranteed to be unique on the link without having to apply
>>> DAD.
>> 
>> YEs for 1), but for 2) one would also consider the IPv6CP part of
>> ppp and the PDP protocols.  These two protocols are also involved
>> in the negotiation of an IID, LLA or even a GUA some times, on that
>> link.
> 
> I assume this exchange happens even before the first IPv6 ND message
> exchange over the link? If so, then if the PDP protocols convey an
> OMNI LLA even before any IPv6 ND message exchange then the "PD"
> operation will already be complete since the OMNI LLA already
> contains the delegated prefix. Would that be a useful
> simplification?
> 
> Thanks - Fred
> 
>> Delegating a prefix is typically associated by an operation of 
>> insertion of an entry in a routing table.  That entry should have
>> a next hop address.  That address could be an LL address or a GUA. 
>> These are negotiated by these IPv6CP or PDP protocols.
>> 
>> If it is too complicated to make IPv6-PD option to use the
>> addresses created by IPv6CP or by PDP as nexthop, then one could
>> delegate a prefix without pointing to a nexthop, but using that old
>> p2p trick.
>> 
>> Also, the suggestion of this draft of using another LL address
>> comes down to associating several LL addresses to an interface;
>> because the LL address made by PDP or IPv6CP is always there.  If
>> such a 2nd LL address is associated to an interface, but is not
>> used in the Gateway as a nexthop field, then one wonders why
>> bothering forming it at all. An interface must always have one LL
>> address, and that is given by IPv6CP or PDP, I think.
>> 
>> I am not saying it is not a good idea, though.
>> 
>> Alex
>> 
>>> 
>>> The idea for this LLA-based PD scheme is as follows:
>>> 
>>> 1) The requesting router creates a temporary LLA using
>>> RFC4941(bis) and sets a prefix length indication inside the LLA
>>> itself. The RR then uses the LLA as the IPv6 source address of an
>>> RS message to send to the delegating router.
>>> 
>>> 2) When the delegating router receives the RS, it sees that the
>>> IPv6 source is an RFC4941(bis) address with a non-zero prefix
>>> length indication. The DR then coordinates with the DHCPv6 server
>>> to request a PD of the length indicated by the RR.
>>> 
>>> 3) When the DR receives the PD from the DHCPv6 server, it creates
>>> an OMNI LLA by embedding the delegated prefix in the IID of
>>> fe80::/64, e.g., as fe80::2001:db8:1:2. The DR then sets a prefix
>>> length indication in the OMNI LLA, and sets the LLA as the
>>> destination address of an RA message to send back to the RR.
>>> 
>>> 4) When the RR receives the RA message, it sees that the
>>> destination is an OMNI LLA with a non-zero prefix length. The RR
>>> then uses the embedded prefix within the OMNI LLA as its
>>> delegated prefix, and regards the Router Lifetime as the time at
>>> which the delegated prefix needs to be renewed.
>>> 
>>> Questions?
>>> 
>>> Fred
>>> 
>>> --------------------------------------------------------------------
>>>
>>> 
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>>> --------------------------------------------------------------------
>>>
>>
>>
>>> 
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>
>> 
--------------------------------------------------------------------
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>