>> Well, one can have one own's HA (not cellular network's) to manage the >>static prefix allocated to the UE, and the cellular network to assign a >>variable prefix in RA.
Sure, but now the discussion is no longer about the IPv6 prefix allocation for the LTE access. You can do this today if you have a MIPv6 client stack, and its already supported over IKEv2/IPsec. Sri On 5/3/18, 7:05 AM, "Alexandre Petrescu" <[email protected]> wrote: > > >Le 03/05/2018 à 15:55, Sri Gundavelli (sgundave) a écrit : >>> It is probably the only reason at this time that makes Mobile IP still >>> necessary. >> >> >> Not really. You will have the same issue with Mobile IP. >> >> Static allocation implies the UE’s session is anchored on a gateway node >> which is the topological anchor for that address block. > >Well, one can have one own's HA (not cellular network's) to manage the >static prefix allocated to the UE, and the cellular network to assign a >variable prefix in RA. > >> Unless, the assigned prefixes are dynamically programmed (ignoring other >> issues), UE’s session always needs to anchored on the same node. > >Yes, the HA. > >Alex > >> >> Sri >> >> >> >> >> >> On 5/3/18, 12:06 AM, "Alexandre Petrescu" <[email protected]> >> wrote: >> >>> >>> >>> Le 02/05/2018 à 16:29, Sri Gundavelli (sgundave) a écrit : >>>>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>>> alocate >>>> a stable prefix in RA to a UE. However, I have never seen it in >>>>practice >>>> in a cellular network. >>>> >>>> >>>> Enabling static IP allocation by default has a scaling issue. The IPv6 >>>> prefix that is allocated to the UE is part of an aggregate block >>>> configured on a given PGW node. Reserving IPv6 prefixes from that >>>>block >>>> makes that one PGW node as the anchor for that UE. Operators loose >>>> flexibility with respect to gateway assignments. >>> >>> Yes, I agree. >>> >>>> If you look at some of the work that went in 3GPP Rel 10 timeframe, it >>>> was >>>> about enhancements to gateway selection logic based on number of >>>> access-network parameters. It allowed operators to allow gateway >>>> selection >>>> based on proximity, policy and other parameters. Now, any time there >>>>is >>>> an >>>> IPv6 prefix reservation that flexibility is lost, as that creates a >>>> Gateway/Subscriber stickiness, and potentially resulting in uneven >>>> distribution of subscriber session across all the gateways. So, this >>>>is >>>> an >>>> operational problems and may be v6ops is the right group for such >>>> discussions. >>> >>> I can agree - it is an operational issue. >>> >>> It is probably the only reason at this time that makes Mobile IP still >>> necessary. >>> >>> Alex >>> >>>> >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 5/2/18, 12:28 AM, "Alexandre Petrescu" >>>><[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> Le 25/04/2018 à 05:00, Sri Gundavelli (sgundave) a écrit : >>>>>> Hi Alex, >>>>>> >>>>>> I cannot comment on the supported network/service configuration in >>>>>>any >>>>>> operator's network. But, I’d think the allocation of stable /64’s is >>>>>> similar to static IPv4 (/32) address allocations that are supported >>>>>>in >>>>>> many operator networks today. There are also RADIUS / DIAMETER >>>>>> attributes >>>>>> such as Framed-IPv6-Prefix ..etc which can be used for obtaining >>>>>> statically configured values by PGW. So, IMO, its very much possible >>>>>> to >>>>>> allocate static IPv6 Per-UE prefixes for the UE. Its also possible >>>>>>to >>>>>> allocate static IPv6 prefixes for the networks behind UE. IMO, this >>>>>>is >>>>>> just a configuration and operators can surely do this today. >>>>>> >>>>>> But, I am not sure where we are going with this? >>>>> >>>>> I am asking because I would like it to happen as you describe as >>>>>being >>>>> possible. >>>>> >>>>> I can agree that the possibility with RADIUS/DIAMETER permits to >>>>> alocate >>>>> a stable prefix in RA to a UE. >>>>> >>>>> However, I have never seen it in practice in a cellular network. >>>>> >>>>> When I connect I always get a different IPv6 prefix in RA. >>>>> >>>>> Where are we going with this? Let us go towards identifying first if >>>>> _anybody_ (any cellular network) allocates a stable IPv6 prefix in RA >>>>> to >>>>> UE. It may be someone does allocate such, as it may be nobody does. >>>>> >>>>> In the first case, then I will suggest my operator to do likewise. >>>>> >>>>> In the latter case, then let us go in a direction where we understand >>>>> _why_ operators dont implement stable IPv6 prefixes per UE. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> >>>>>> Sri >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4/24/18, 7:31 AM, "Alexandre Petrescu" >>>>>> <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Sri, >>>>>>> >>>>>>> Is there an operator today that allocates a stable /64 in RA to >>>>>>>User >>>>>>> Equipment? (resists re-connection) >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>> Le 26/03/2018 à 07:14, Sri Gundavelli (sgundave) a écrit : >>>>>>>> Alex: >>>>>>>> >>>>>>>> This is a good point. Yes, there is DHCPv6 prefix delegation >>>>>>>>support >>>>>>>> in >>>>>>>> 3GPP architecture for supporting mobile router use-cases. This is >>>>>>>> essentially for delegating prefixes for the networks attached to >>>>>>>>the >>>>>>>> UE. >>>>>>>> This was introduced in Rel-10 by cisco. I have not followed the >>>>>>>> recent >>>>>>>> SA2 >>>>>>>> discussions and I do not know if MR support based on DHCPv6 will >>>>>>>> continue >>>>>>>> to be supported or not, and if they have considered the >>>>>>>>alternative >>>>>>>> options for supporting the same. I think we can certainly ask that >>>>>>>> question, but I also wonder if the coloring is specific to the PDU >>>>>>>> session, or if its broadly applicable for all UE address/prefix >>>>>>>> assignments. >>>>>>>> >>>>>>>> >>>>>>>> Sri >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/23/18, 2:48 AM, "dmm on behalf of Alexandre Petrescu" >>>>>>>> <[email protected] on behalf of [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 22/03/2018 à 18:49, Liaison Statement Management Tool a écrit >>>>>>>>>: >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> SA2 would like to point out that among the four mechanisms for >>>>>>>>>> address configuration delivery mentioned in your LS reply (i.e. >>>>>>>>>> DHCPv4, DHCPv6, IPv6 ND and IKEv2) only the IPv6 ND mechanisms, >>>>>>>>>> and >>>>>>>>>> in particular the Router Advertisement message, seem to be >>>>>>>>>> applicable >>>>>>>>>> in the 5G System architecture in the specific context of >>>>>>>>>> Multi-homed >>>>>>>>>> IPv6 PDU Sessions. >>>>>>>>> Please tell SA2 that current 4G cellular networks are specified >>>>>>>>>to, >>>>>>>>> and >>>>>>>>> do use to some extent, DHCPv6 Prefix Delegation to assign a >>>>>>>>>prefix >>>>>>>>> to >>>>>>>>> an >>>>>>>>> end node like an IoT Router. >>>>>>>>> >>>>>>>>> A /56 prefix delivered to the end node should have the same >>>>>>>>> capabilities >>>>>>>>> as an address. We also want that /56 prefix to be more stable, or >>>>>>>>> less >>>>>>>>> stable, etc. >>>>>>>>> >>>>>>>>> I dont understand why 5G System architecture excludes DHCPv6 from >>>>>>>>> the >>>>>>>>> list of applicable address configuration delivery. >>>>>>>>> >>>>>>>>> I understand why 5G System architectures prefers ND - it is for >>>>>>>>> addresses. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> With respect to the following question in the IETF¹s reply LS: >>>>>>>>>> We also like to point out that, all though >>>>>>>>>> the LS >>>>>>>>>> statement explicitly refers to both IPv4 and IPv6 address types, >>>>>>>>>> however >>>>>>>>>> it only mentions about (RA) (IPv6 >>>>>>>>>> ND implied) as the mechanism for address >>>>>>>>>> property >>>>>>>>>> delivery. It is to be noted that the approach of delivering >>>>>>>>>> coloring >>>>>>>>>> meta-data in RA messages will most >>>>>>>>>> likely be to limited to IPv6 address/prefix >>>>>>>>>> types >>>>>>>>>> and >>>>>>>>>> will not be extended to IPv4 addresses. If this capability is >>>>>>>>>> required >>>>>>>>>> for IPv4, we may have to possibly >>>>>>>>>> extend DHCP protocol(s). >>>>>>>>>> >>>>>>>>>> We request 3GPP to clarify if the Ask is >>>>>>>>>> explicitly >>>>>>>>>> for IPv6, or if its for both IPv4 and IPv6 address/prefix types. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> SA2 would like to clarify that the request is explicitly for >>>>>>>>>>IPv6. >>>>>>>>>> SA2 >>>>>>>>>> discussed the example documents that were referenced in your LS >>>>>>>>>> reply >>>>>>>>>> and concluded that the following draft seems to be the most >>>>>>>>>> promising >>>>>>>>>> candidate for the problem under discussion in this >>>>>>>>>>correspondence: >>>>>>>>>> https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt. >>>>>>>>>> SA2 would like to kindly ask IETF DMM working group to keep SA2 >>>>>>>>>> updated >>>>>>>>>> of the work on the subject of including property meta-data in >>>>>>>>>>IPv6 >>>>>>>>>> ND >>>>>>>>>> address assignment procedures for potential use in the 5G System >>>>>>>>>> to >>>>>>>>>> indicate the mobility property of additional IPv6 prefixes >>>>>>>>>> assigned >>>>>>>>>> as >>>>>>>>>> part of the Multi-homed IPv6 PDU Session functionality. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2 Actions >>>>>>>>>> To IETF DMM working group: >>>>>>>>>> ACTION: SA2 would like to kindly ask IETF DMM working >>>>>>>>>> group >>>>>>>>>> to >>>>>>>>>> keep SA2 updated of the work on the subject of including >>>>>>>>>>property >>>>>>>>>> meta-data in IPv6 ND address assignment procedures for potential >>>>>>>>>> use >>>>>>>>>> in >>>>>>>>>> the 5G System to indicate the mobility property of additional >>>>>>>>>>IPv6 >>>>>>>>>> prefixes assigned as part of the Multi-homed IPv6 PDU Session >>>>>>>>>> functionality. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3 Dates of next TSG SA WG2 meetings >>>>>>>>>> TSG SA WG2 Meeting 127 16 - 20 Apr 2018 Sanya, CN >>>>>>>>>> TSG SA WG2 Meeting 127-Bis 28 May 1 Jun 2018 Newport Beach, >>>>>>>>>> US >>>>>>>>>> Attachments: >>>>>>>>>> >>>>>>>>>> S2-182967_was2844_LS_IETF_SSC3 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-03-22- >>>>>>>>>>3g >>>>>>>>>> pp >>>>>>>>>> -t >>>>>>>>>> sg >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of- >>>>>>>>>>th >>>>>>>>>> e- >>>>>>>>>> ad >>>>>>>>>> di >>>>>>>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> dmm mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> dmm mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
