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

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 18 Jan 2018 12:30:10 +0000

Dear All,

Please review the attached LS from 3GPP SA2 on the RA meta-data related
work. Please send any comments you have to the chairs.

Sri

>
>
>On 1/16/18, 2:45 PM, "Liaison Statement Management Tool" <[email-masked]>
>wrote:
>
>>Title: LS on indicating service continuity usage of the additional IPv6
>>prefix in Router Advertisement
>>Submission Date: 2018-01-16
>>URL of the IETF Web page: https://datatracker.ietf.org/liaison/1554/
>>
>>From: Chang hong <[email-masked]>
>>To: Sri Gundavelli <[email-masked]>,Dapeng Liu
>><[email-masked]>,Terry Manderson <[email-masked]>,Suresh
>>Krishnan <[email-masked]>,Robert Hinden <[email-masked]>,Ole
>>Troan <[email-masked]>
>>Cc: Dapeng Liu <[email-masked]>,Terry Manderson
>><[email-masked]>,IPv6 Maintenance Discussion List
>><[email-masked]>,Ole Troan <[email-masked]>,Sri Gundavelli
>><[email-masked]>,The IETF Chair <[email-masked]>,Robert Hinden
>><[email-masked]>,Distributed Mobility Management Discussion List
>><[email-masked]>,Suresh Krishnan <[email-masked]>
>>Response Contacts: [email-masked],[email-masked]
>>Technical Contacts:
>>Purpose: For information
>>
>>Body: 1. Overall Description:
>>3GPP working group SA2 (System Architecture) would like to inform the
>>IETF that SA2 has defined three SSC (Session and Service Continuity)
>>modes in 3GPP TS 23.501 ("Architecture for the 5G System") clause 5.6.9
>>as follows:
>>-	With SSC mode 1, the network preserves the connectivity service
>>provided to the UE. For the case of PDU Session of IPv4 or IPv6 type, the
>>IP address is preserved.
>>-	With SSC mode 2, the network may release the connectivity service
>>delivered to the UE and release the corresponding PDU Session. For the
>>case of IPv4 or IPv6 type, the network may release IP address(es) that
>>had been allocated to the UE.
>>-	With SSC mode 3, changes to the user plane can be visible to the UE,
>>while the network ensures that the UE suffers no loss of connectivity. A
>>connection through new PDU Session Anchor point is established before the
>>previous connection is terminated in order to allow for better service
>>continuity. For the case of IPv4 or IPv6 type, the IP address is not
>>preserved in this mode when the PDU Session Anchor changes.
>>SA2 has also adopted the use of IPv6 multi-homing in a PDU Session
>>(referred to as "multi-homed IPv6 PDU Session") as described in 3GPP TS
>>23.501 clause 5.6.4.3, a PDU Session being an association between the UE
>>and a Data Network that provides a data connectivity service, which is
>>also defined in 3GPP TS 23.501.
>>When a new IPv6 Prefix is assigned to the UE for a multi-homed IPv6 PDU
>>Session, SA2 has decided to use the Router Advertisement message
>>according to IETF RFC 4191 to deliver the new IPv6 prefix to the UE and
>>configure the Routing Rules in the UE by using the Route Information
>>Option. 
>>SA2 is looking for a mechanism to deliver information regarding the
>>service continuity usage (e.g. whether the prefix can be replaced with or
>>without grace period) associated with the new IPv6 prefix to the UE via
>>the 5G System user plane.
>>
>>SA2 understands that the IETF draft "draft-ietf-dmm-ondemand-mobility-12"
>>defines four IP address types that can be mapped to the three SSC modes
>>as follows:
>>
>>-	SSC mode 1 corresponds to either FIXED or SESSION_LASTING;
>>-	SSC mode 2 corresponds to NON_PERSISTENT;
>>-	SSC mode 3 corresponds to GRACEFUL_REPLACEMENT.
>>
>>SA2 would like to understand if there is any IETF work related to
>>delivery of the IP address type (according to IETF draft
>>"draft-ietf-dmm-ondemand-mobility-12") in the Router Advertisement
>>message, which could be used for delivery of the service continuity usage
>>associated with a new IPv6 prefix in a multi-homed IPv6 PDU Session.
>>
>>2. Actions:
>>To IETF Internet Area, DMM, 6MAN:
>>ACTION: 	SA2 respectfully asks IETF Internet Area, DMM and 6MAN to
>>provide feedback on any IETF work related to delivery of IP address type
>>(according to IETF draft "draft-ietf-dmm-ondemand-mobility-12") in the
>>Router Advertisement message.
>>
>>3. Date of Next SA2 Meetings:
>> 3GPPSA2#125  OR 22 - 26 Jan 2018    Gothenburg  	SE
>> 3GPPSA2#126  OR 26 Feb - 2 Mar 2018    US	        US
>>Attachments:
>>
>>    S2-179625_e-mail_rev2_S2-179363_LS_out_to_IETF_Internet_Area_DMM_6MAN
>>    
>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-16-3gpp-tsg
>>s
>>a-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the-addit
>>i
>>onal-ipv6-prefix-in-router-advertisement-attachment-1.doc
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 18 Jan 2018 21:36:00 +0900

Whatever the outcome, we should encourage them to consider separate
RAs from separate link-local router addresses for logically separate
data.  (Like PvDs, essentially)

Trying to allocate bits in the PIO and RIO for address type won't
really prove sustainable.

On 18 January 2018 at 21:30, Sri Gundavelli (sgundave)
<[email-masked]> wrote:
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 25 Jan 2018 16:54:29 +0000

Thank you Erik for the feedback.

Sri

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Jan 2018 18:04:08 +0100

Yes,
and we should also encourage them to talk in terms of prefixes also, not 
only in terms of addresses.

Whenever 3GPP says "SSC mode 1 ... IP address is preserved" it should 
say "IP address or IP prefix is preserved".

Because there are places where the 3GPP network gives a /56 prefix to UE 
using DHCPv6-PD.  That's clearly not one address.

This is a question I made to the operator giving DHCPv6-PD: is the 
allocated /56 resisting handovers (stays same upon handovers)?  I am 
told the /56 resists to handovers, to a certain extent.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 27 Jan 2018 20:23:14 +0000

I think we should break the entire discussion into three parts:

1.) The approach of coloring IP addresses with mobility properties:

#a. Fixed IP Address

#b. Non-persistent IP Address

#c. Graceful Replacement IP Address

This is covered in draft-ietf-dmm-ondemand-mobility-13. The modes, #a, #b
and #c seem to map to the 3GPP SSC mode 1, 2 and 3 respectively.

This work is on track to become a "proposed standard", and will most
likely will hit IESG very soon.

2.) The approach of network including property meta-data in address
assignment procedures

There are three mechanisms for address configuration delivery to the
end-host:

#a.) DHCPv6
#b.) IPv6 ND (PIO Options, others ..etc)
#c.) IKEv2 Address Configuration Options

There are many proposals on this including:

https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt
https://www.ietf.org/id/draft-moses-dmm-dhcp-ondemand-mobility-08.txt

Also, some from the past

https://www.ietf.org/archive/id/draft-ietf-mif-mpvd-ndp-support-03.txt
https://www.ietf.org/archive/id/draft-ietf-mif-mpvd-id-02.txt
https://www.ietf.org/archive/id/draft-bhandari-dhc-class-based-prefix-05.tx
t
...

We need to bring the work in scope and accelerate the adoption process for
ND based extension. For now, I am ignoring the discussion on what
approach/option that will be used for this.

The LS does not talk about IKEv2 or DHCP, but we need to have a discussion
on that as well. 

3.) The approach of indicating the color to the applications on the mobile
node

This is about extending socket interface with the property tags. This is
covered in draft-ietf-dmm-ondemand-mobility-13, and the draft is on track
to become a proposed standard.

Based on this, we can say the gap is in #2 and that IETF/DMM WG is looking
at various proposals. Most likely, and very soon, the WG will finalize the
approach and will have a working document covering this extension. The WG
will also try to meet the 3GPP release targets for this work item.

Please comment, if you have any comments on this response.

Regards
Sri

>>>>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-16-3gpp-
>>>>>t
>>>>>sg
>>>>>s
>>>>>a-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the-ad
>>>>>d
>>>>>it
>>>>>i

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 31 Jan 2018 16:44:57 +0100

Le 27/01/2018 à 21:23, Sri Gundavelli (sgundave) a écrit :
[...]
> ND based extension.

Do you mean ND extension that would do Prefix Delegation?

I am asking, because you list approaches of coloring IP addresses with 
mobility properties (fixed, non persistent, graceful replacement) and 
then talk about approaches for assigning meta-data procedures.  I do not 
understand.

What I need is that when operators assign a /56 prefix (not an address) 
to an IoT router that prefix to have a property among: fixed, 
long-lasting after re-connection, or after handover.  Or maybe changing 
after re-connection, or after handover.  The terminology 
'fixed/changing/session-lasting' can vary, but there must be a way to 
request 'fixed'.

Remark I am talking about a /56 _prefix_, not a /64 prefix.  A /64 
prefix is useless for an IoT Router.

Remark I am talking about a prefix, not about an address.

Alex

  For now, I am ignoring the discussion on what

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 31 Jan 2018 15:57:14 +0000

Alex:

Defining standard property tags is one thing, and delivering those tags in
protocols is another thing.

With Delegated prefixes, or hosted prefixes, network should be able to
mark them with different properties on address-configuration delivery
protocols (Ex: ND)

You may want to read those specs, including
draft-ietf-dmm-ondemand-mobility

Sri

On 1/31/18, 7:44 AM, "dmm on behalf of Alexandre Petrescu"
<[email-masked] on behalf of [email-masked]> wrote:

>>>>>>> URL of the IETF Web page:
>>>>>>>https://datatracker.ietf.org/liaison/1554/
>>>>>>>
>>>>>>> provided to the UE. For the case of PDU Session of IPv4 or IPv6
>>>>>>>type,
>>>>>>> the
>>>>>>> IP address is preserved.
>>>>>>> -     With SSC mode 3, changes to the user plane can be visible to
>>>>>>>the
>>>>>>> UE,
>>>>>>> while the network ensures that the UE suffers no loss of
>>>>>>>connectivity.
>>>>>>> A
>>>>>>> connection through new PDU Session Anchor point is established
>>>>>>>before
>>>>>>> the
>>>>>>> (referred to as "multi-homed IPv6 PDU Session") as described in
>>>>>>>3GPP
>>>>>>> TS
>>>>>>> 23.501 clause 5.6.4.3, a PDU Session being an association between
>>>>>>>the
>>>>>>> UE
>>>>>>> service continuity usage (e.g. whether the prefix can be replaced
>>>>>>>with
>>>>>>> or
>>>>>>> ACTION:       SA2 respectfully asks IETF Internet Area, DMM and
>>>>>>>6MAN
>>>>>>> to

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 31 Jan 2018 21:14:44 +0000

Based on the feedback and some offline discussions with Danny and others,
here is the response with some corrections. Please comment.

------------------------------------

Dear 3GPP SA2 Chair:

Thank you for your LS query (Reference:
https://datatracker.ietf.org/liaison/1554/). The IETF DMM working group
has reviewed the LS statement and below is our response.

In our view, the work-item described in the LS query has three components:

1.) The approach of coloring IPv4 and IPv6 addresses/prefixes with
mobility properties.

This is about standardizing IP address address/prefix ³types". Each ³type"
has a certain behavior that the network is expected to provide. Section
3.1, of draft-ietf-dmm-ondemand-mobility-13 defines the following four
address types, which are applicable to both IPv4 and IPv6 addresses and
prefixes. 

#a. Fixed IP Address
#b. Session-lasting IP Address
#c. Non-persistent IP Address
#d. Graceful Replacement IP Address

These modes, #a, #b, #c,and #d can be mapped to the 3GPP SSC modes 1, 2
and 3.

We are happy to report that this work-item is on track to become an
³informational standard", and will most likely will hit IESG very soon.

We kindly request 3GPP to provide any feedback that you may have on this
draft.

There are multiple mechanisms for address configuration delivery to the
end-host:

#a.) DHCPv4
#b.) DHCPv6
#c.) IPv6 ND (PIO Options, others ..etc)
#d.) IKEv2 Address Configuration Options

Also, some proposals from the previous years:

Currently, these documents are under review in the IETF DMM WG. However,
the DMM working group has not chosen any specific draft as WG document.
Given the interest from 3GPP for this work, we will try to accelerate the
document selection process and will try to move this work forward. This is
subject to finding consensus for taking up this work.

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 kindly request SA2 to clarify if the Ask is explicitly for IPv6, or if
its for both IPv4 and IPv6 address/prefix types.

3.) The approach of indicating the coloring meta-data to the applications
on the mobile node (UE in 3GPP terminology).

This is about extending socket interface with the property tags. This is
covered in draft-ietf-dmm-ondemand-mobility-13,

We are happy to report that this work is on track to become an
³informational standard", and will most likely will hit IESG very soon.

We kindly request 3GPP to provide any feedback that you may have on this
draft.

Regards
Dapeng Liu and Sri Gundavelli
(Chairs IETF DMM Working Group)

-----------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Feb 2018 08:23:21 +0100

Le 31/01/2018 à 22:14, Sri Gundavelli (sgundave) a écrit :
> https://www.ietf.org/archive/id/draft-bhandari-dhc-class-based-prefix-05.txt

I propose you add the following draft about ND Prefix Delegation 
extensions to Neighbor Discovery:
https://tools.ietf.org/html/draft-kaiser-nd-pd-01
(it is not about coloring the prefix, but it is about prefix delegation 
options in ND)

Alex