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

[Alexandre Petrescu <[e-mail]>]

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.

Thanks for the pointer.  I had a look at it.  The document is indeed
relevant to our discussion of delegating prefixes to the Terminal.

I think  as long as the document says that the interfaceid is 64bit
length (8 octets described in a particular table and diagram), and has
sections called "IP address allocation", the document will always feel
entitled to allocate addresses and with prefixes of length 64.

In this sense, as before, I still think 3GPP specs go too far in
specifying IP address allocation whereas IETF specs try to adapt; a
notable example is the prefix exclude option specified at IETF to deal
with a lack of address architecture work in the 3GPP netzork.

IMHO, an ideal 3GPP link to the Terminal is just a link-layer pipe.
This pipe does not negotiate IIDs, does not proxy for any RFC of IP
address allocation protocol such as DHCP and SLAAC, does not try to act
on behalf of the Terminal.

Alex

> 
> Cheers D
> 
> -----Original Message----- From: ipv6 <[e-mail]> On
> Behalf Of Templin (US), Fred L Sent: Tuesday, November 24, 2020 1:52
> PM To: Alexandre Petrescu <[e-mail]>;
> [e-mail] Subject: Re: [v6ops] How do you solve 3GPP issue if
> neither operator nor handset supports PD?
> 
> Alex, see below:
> 
>> -----Original Message----- From: ipv6
>> [mailto:[e-mail]] On Behalf Of Alexandre Petrescu 
>> Sent: Tuesday, November 24, 2020 1:33 PM To: [e-mail] 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 [e-mail] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>>> --------------------------------------------------------------------
>>>
>>
>>
>>> 
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list [e-mail] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>
>> 
--------------------------------------------------------------------
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>