Subject: Re: [DMM] New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement"

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 May 2018 09:28:08 +0200

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-masked]>
> 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-masked] on behalf of [email-masked]> 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-3gpp-t
>>>>> sg
>>>>>
>>>>> sa-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the-ad
>>>>> di
>>>>> tional-ipv6-prefix-in-router-advertisement-attachment-1.docx
>>>>>
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>
>>>> _______________________________________________
>>>> dmm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>
> 
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 2 May 2018 14:29:19 +0000

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

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.

Sri

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 3 May 2018 09:06:16 +0200

> flexibility with respect to gateway assignments.

Yes, I agree.

> operational problems and may be v6ops is the right group for such

I can agree - it is an operational issue.

It is probably the only reason at this time that makes Mobile IP still 
necessary.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 3 May 2018 13:55:40 +0000

> It is probably the only reason at this time that makes Mobile IP still

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.

Unless, the assigned prefixes are dynamically programmed (ignoring other
issues), UE’s session always needs to anchored on the same node.

Sri

On 5/3/18, 12:06 AM, "Alexandre Petrescu" <[email-masked]>
wrote:

>>>>>>>> indicate the mobility property of additional IPv6 prefixes
>>>>>>>>assigned
>>>>>>>> as
>>>>>>>>         ACTION: SA2 would like to kindly ask IETF DMM working
>>>>>>>>group
>>>>>>>> to
>>>>>>>>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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 3 May 2018 16:05:06 +0200

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

> issues), UE’s session always needs to anchored on the same node.

Yes, the HA.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 3 May 2018 23:43:15 +0000

>>static prefix allocated to the UE, and the cellular network to assign a

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-masked]>
wrote:

>>>> based on proximity, policy and other parameters. Now, any time there
>>>>is
>>>> an
>>>> distribution of subscriber session across all the gateways. So, this
>>>>is
>>>> an
>>>>>>>> This is a good point. Yes, there is DHCPv6 prefix delegation
>>>>>>>>support
>>>>>>>> in
>>>>>>>> essentially for delegating prefixes for the networks attached to
>>>>>>>>the
>>>>>>>> UE.
>>>>>>>>> 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
>>>>>>>>>> SA2 would like to clarify that the request is explicitly for
>>>>>>>>>>IPv6.
>>>>>>>>>> SA2
>>>>>>>>>> of the work on the subject of including property meta-data in
>>>>>>>>>>IPv6
>>>>>>>>>> ND

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 7 May 2018 09:25:27 +0200

> stack, and its already supported over IKEv2/IPsec.

Sure.

Why operators have no scaling issue allocating a stable IPv4 address to
UE but have such an issue when allocating a stable IPv6 prefix to UE?

Why operators live ok with gateway/subscriber stickiness for IPv4 (and
thus allocate a stable IPv4 address to UE) but not for IPv6 (dont
allocate a stable IPv6 to UE)?

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 7 May 2018 14:59:32 +0000

Sure. IPv4 or IPv6, its fundamentally the same issue. May be they will
support it in future, or they don¹t want to extend the same for IPv6. This
is for operators to comment and not for me. I cannot speculate the reasons
behind their choices, but I do not see some conspiracy theory behind not
extending it to IPv6. Its just flexibility of anchoring nodes on any
gateways, IMO. Or, may there are much important reasons than this one that
I do not understand.

Sri