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

Le 24/11/2020 à 22:52, Templin (US), Fred L a écrit :
> 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?

YEs it does.

> 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?

YEs.

Alex

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