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 protected] on behalf of [email protected]> wrote: > > >Le 27/01/2018 à 21:23, Sri Gundavelli (sgundave) a écrit : >[...] >> We need to bring the work in scope and accelerate the adoption process >>for >> 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 >> 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 >> >> >>>>> >>>>> >>>>>> >>>>>> >>>>>> 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_6MA >>>>>>>N >>>>>>> >>>>>>> >>>>>>>https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-16-3gp >>>>>>>p- >>>>>>> t >>>>>>> sg >>>>>>> s >>>>>>> >>>>>>>a-sa2-int-6man-dmm-ls-on-indicating-service-continuity-usage-of-the- >>>>>>>ad >>>>>>> d >>>>>>> it >>>>>>> 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 >> > >_______________________________________________ >dmm mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
