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

Alexandre Petrescu <> Tue, 24 November 2020 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DB343A0C1D for <>; Tue, 24 Nov 2020 13:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.648
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_H4=-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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q2XXaSA-u5VG for <>; Tue, 24 Nov 2020 13:32:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BFAC3A0C0E for <>; Tue, 24 Nov 2020 13:32:35 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOLWYgb031913 for <>; Tue, 24 Nov 2020 22:32:34 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 59238209651 for <>; Tue, 24 Nov 2020 22:32:34 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 4EB26209665 for <>; Tue, 24 Nov 2020 22:32:34 +0100 (CET)
Received: from [] ([]) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOLWXLj012491 for <>; Tue, 24 Nov 2020 22:32:34 +0100
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Tue, 24 Nov 2020 22:32:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2020 21:32:41 -0000

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:
> 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.

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.


> 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
> Administrative Requests:
> --------------------------------------------------------------------