Subject: Re: New RA Option Number for IP Prefix Specification Option

From: Wu-chi Feng <[email-masked]>
Date: Wed, 11 Jul 2018 13:40:52 -0700

Were there any other comments from the 6man community?

In the response to Lorenzo previously, I accidentally omitted the reference
to [1]:
https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-14

Regards,
Wu-chi

On Sat, Jun 30, 2018 at 12:14 PM, Wu-chi Feng <[email-masked]> wrote:

> Thanks for the comments, Lorenzo.
>
> This approach would work but would then mix semantics / meaning with the
> lifetime other than the lifetime itself. This may lead to some ambiguity.
> For example, 5.5.3 calls for hosts to ignore prefixes less than 2 hours
> unless done via secure network discovery.  Additionally, it may be more
> beneficial for the routers to be able to specify the type of connection
> explicitly than implicitly through setting a threshold in the RA lifetime.
>
> In DMM, there are 4 types of IP addresses defined in [1]: Fixed IP,
> Session-lasting, Non-persistent, and Graceful Replacement. Similarly, in
> 3GPP there are 3 SSC modes being defined.
>
> In our discussions, we felt that having a generic IP address specification
> RA option would be a cleaner way to do it. Hosts that do not recognize the
> option will ignore it; those that do will process it.  There is precedence
> for creating RA options (e.g., those for Mobile IPv6).  We are hoping to do
> something a bit more generic so that we don't have RA options that are tied
> to a specific application.
>
> Thanks,
> Wu-chi
>
> On Mon, Jun 25, 2018 at 8:05 PM, Lorenzo Colitti <[email-masked]>
> wrote:
>
>> I do think this is an important problem to work on.
>>
>> However: why a new protocol option? It seems like the network could just
>> announce non-stable prefixes as having a lower lifetime (currently, stable
>> prefixes have a lifetime of 0xffffffff specified in the 3GPP documents).
>> Then the host could just have an API to select IP addresses based on their
>> preferred lifetime. No protocol changes would be required (except maybe
>> you'd need to waive the 2-hour rule in RFC 4862 section 5.5.3
>> <https://tools.ietf.org/html/rfc4862#section-5.5.3>).
>>
>> On Tue, Jun 26, 2018 at 7:16 AM Wu-chi Feng <[email-masked]> wrote:
>>
>>> We have been working for quite some time in the DMM (distributed
>>> mobility management) WG on enabling applications to indicate to the network
>>> whether or not they need a guarantee that their source IP prefix will stay
>>> valid, even after moving and changing their point of attachment to the
>>> network. Most cellular network today automatically guarantee the validity
>>> of mobile hosts’ source IP prefix by various means (tunneling based on PMIP
>>> or GTP are the most popular ones). This guarantee incurs overhead such as
>>> non-optimized routes, traffic load at the mobility anchor and single point
>>> of failure. Some applications can easily recover from changes to the host’s
>>> source IP prefix as a result of movement and can benefit from the
>>> optimization that is gained from not having to tunnel all their traffic.
>>>
>>> 3GPP is also working on similar concepts which they call SSC modes:
>>> Service and Session Continuity.  The 3GPP group defines standards for
>>> cellular telephony.  At the beginning of the year, 3GPP issued a liaison
>>> statement (LS) with regard to the ability to specify a session continuity
>>> type for an IP prefix.  There currently is an individual draft [1], which
>>> was last presented at IETF 101 [2]. After the presentation and further
>>> discussion, it seems like the best option would be to create a generic new
>>> “Prefix Specification Option” that is a new option for RA. We are thinking
>>> that creating a generic way of specifying what the prefix is may be the
>>> least polluting of the option numbers.  We could use the prefix
>>> specification option to specify the SSC mode in the LS from 3GPP.  We also
>>> envision this to allow the specification for other things such as, perhaps,
>>> pay-for services.  The idea would be to:
>>> *) Have a new RA option number
>>> *) Within the new “Prefix Specification Option” have a type option
>>> *) One of the types will be Prefix Service Continuity, where we will
>>> specify the SSC mode. Other types could then fall under this single prefix
>>> specification option.
>>> The other option would be to modify the prefix option, but we suspect
>>> this might be much less palatable to the 6MAN community.
>>>
>>> There are examples of more specific RA options that exist today (e.g.,
>>> Mobile IPv6 RA options), and we are seeking feedback from the community
>>> regarding the proposed approach to solve the problem trying to be solved by
>>> the 3GPP community.  Putting something in place that 3GPP can leverage will
>>> avoid having an ad hoc (non-standardized) use of RA options in the cellular
>>> network.
>>>
>>> Current / ongoing status for IETF 102:
>>> *) DMM WG would like to hear feedback from the 6MAN community before
>>> pushing the draft into a working group document.
>>> *) If there is sufficient interest or you want to hear more, we will
>>> request a presentation slot in the 6MAN WG for IETF 102.
>>> *) The 6MAN feedback will be presented to the DMM WG.
>>>
>>> Regards,
>>> Wu-chi Feng and Danny Moses
>>>
>>> [1] https://datatracker.ietf.org/doc/draft-feng-dmm-ra-prefixtype/
>>> [2] https://datatracker.ietf.org/meeting/101/materials/slides-10
>>> 1-dmm-ra-extensions-for-on-demand-mobility-00
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [email-masked]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jul 2018 00:23:57 -0700

> Were there any other comments from the 6man community?

There were other comments, yes.
https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=suH6o2ErKlLbU643TyPCewvX1So