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

["Templin (US), Fred L" <[e-mail]>]

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> Sent: Wednesday, November 25, 2020 9:11 AM
> To: tom petch <[e-mail]>; David Allan I <[e-mail]>; Alexandre Petrescu
> <[e-mail]>; [e-mail]
> Subject: RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> 
> 
> 
> > -----Original Message-----
> > From: tom petch [mailto:[e-mail]]
> > Sent: Wednesday, November 25, 2020 9:03 AM
> > To: Templin (US), Fred L <[e-mail]>; David Allan I <[e-mail]>; Alexandre Petrescu
> > <[e-mail]>; [e-mail]
> > Subject:  Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> >
> > From: ipv6 <[e-mail]> on behalf of Templin (US), Fred L <[e-mail]>
> > Sent: 25 November 2020 14:23
> > > -----Original Message-----
> > > From: David Allan I [mailto:[e-mail]]
> > > Sent: Tuesday, November 24, 2020 2:29 PM
> >
> > > 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.
> >
> > Wouldn't it be better if the interface ID contained a useful piece of information such
> > as a delegated prefix, instead of just a bag of bits?
> >
> > <tp>
> > No!
> > An identifier should identify, be unique within its namespace, be easy to use in whatever manner it gets used.
> >
> > Load it up with 'useful' semantics and it will become defective as some of the semantics change or aren't present in some cases.
> >
> > Brian addressed this back in June.
> 
> Brian also cited this construction format in RFC7421 (cited as [AER-TRANS]).

Sorry; make that "[AERO-TRANS]".

> 
> Fred
> 
> > Tom Petch
> >
> > Fred
> >
> > > 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
> > > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > 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
> --------------------------------------------------------------------