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

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

Le 18/01/2018 à 13:36, Erik Kline a écrit :
> 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 protected]> wrote:
>> 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 protected]>
>>> 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 protected]>
>>>> To: Sri Gundavelli <[email protected]>,Dapeng Liu
>>>> <[email protected]>,Terry Manderson <[email protected]>,Suresh
>>>> Krishnan <[email protected]>,Robert Hinden <[email protected]>,Ole
>>>> Troan <[email protected]>
>>>> Cc: Dapeng Liu <[email protected]>,Terry Manderson
>>>> <[email protected]>,IPv6 Maintenance Discussion List
>>>> <[email protected]>,Ole Troan <[email protected]>,Sri Gundavelli
>>>> <[email protected]>,The IETF Chair <[email protected]>,Robert Hinden
>>>> <[email protected]>,Distributed Mobility Management Discussion List
>>>> <[email protected]>,Suresh Krishnan <[email protected]>
>>>> Response Contacts: [email protected],[email protected]
>>>> 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
>>>
>>
>> _______________________________________________
>> 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