Subject: New RA Option Number for IP Prefix Specification Option

From: Wu-chi Feng <[email-masked]>
Date: Mon, 25 Jun 2018 15:15:02 -0700

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-101-dmm-ra-extensions-for-on-demand-mobility-00

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 26 Jun 2018 12:05:28 +0900

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:

> 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:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Wu-chi Feng <[email-masked]>
Date: Sat, 30 Jun 2018 12:14:32 -0700

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:

>> The other option would be to modify the prefix option, but we suspect
>> this might be much less palatable to the 6MAN community.
>>
>> [2] https://datatracker.ietf.org/meeting/101/materials/slides-
>> 101-dmm-ra-extensions-for-on-demand-mobility-00
>>
>>