Distributed Mobility Management (DMM)                        J. Korhonen
Internet-Draft                                            Renesas Mobile
Updates: 4861, 4862 (if approved)                               B. Patil
Intended status: Standards Track                           S. Gundavelli
Expires: January 11, 2014                                          Cisco
                                                                P. Seite
                                                                  D. Liu
                                                            China Mobile
                                                           July 10, 2013

                         IPv6 Prefix Properties


   This specification defines an extension to the IPv6 Neighbor
   Discovery protocol and the stateless address autoconfiguration
   procedure.  A new Prefix Information Option with meta data is defined
   that describe the properties and other prefix class meta data
   associated with the prefix.  The stateless address autoconfiguration
   procedure and end hosts can make use of the additional properties and
   class information when selecting prefixes for a particular uses and
   use cases.  This specification updates RFC4861 and also updates

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Korhonen, et al.        Expires January 11, 2014                [Page 1]

Internet-Draft           IPv6 Prefix Properties                July 2013

   This Internet-Draft will expire on January 11, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Korhonen, et al.        Expires January 11, 2014                [Page 2]

Internet-Draft           IPv6 Prefix Properties                July 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Background and Motivation  . . . . . . . . . . . . . . . . . .  5
   3.  Option Formats . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Prefix Information Option with Meta Data . . . . . . . . .  6
     3.2.  Meta Data Suboptions . . . . . . . . . . . . . . . . . . .  7
   4.  Host Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Stateless Address Autoconfiguration Enhancements . . . . .  9
     4.2.  Internal Data Structures . . . . . . . . . . . . . . . . .  9
     4.3.  Default Address Selection  . . . . . . . . . . . . . . . .  9
   5.  Router Considerations  . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Korhonen, et al.        Expires January 11, 2014                [Page 3]

Internet-Draft           IPv6 Prefix Properties                July 2013

1.  Introduction

   This specification defines a new neighbor discovery protocol message
   option, the Prefix Information Option with Meta Data (PIOMT), that
   indicate, for example, the mobility management properties associated
   to the prefix, and a class value that conveys metadata associated to
   the prefix with a local administrative domain wide importance.
   Furthermore, the specification discusses corresponding source address
   selection hint flags to the IPv6 Socket API for Source Address
   Selection [RFC5014].

   For example, the IPv6 Socket API for Source Address Selection
   [RFC5014] already covers Mobile IPv6 [RFC6275] and allows selecting
   between a home address (HoA) and a care-of address (CoA).  A mobile
   node (MN) with a client based mobility IP stack is supposed to know
   which prefixes are CoA(s) and/or HoA(s).  However, this is not the
   case with network based mobility management where the MN is expected
   to be agnostic of the mobility support.  There has been attempts in
   past to define similar functionality for the mobility protocols
   purposes [I-D.damic-6man-pmip6-ind].  Outside the mobility protocols,
   there are other potential use cases where associating properties to
   the advertised prefixes could be useful as discussed in

   The extensions to [RFC4861] are minimal in a sense that they do not
   define new functionality, for example, to any existing mobility
   protocol but instead add an explicit indication of network based
   mobility knowledge into the IPv6 stateless address autoconfiguration
   (SLAAC) [RFC4862].  The new functionality is achieved by defining a
   new, backward compatible, option to IPv6 router advertisements that
   convey the required prefix related meta data information the SLAAC
   procedure may take use of.

   This would allow for network based mobility solutions, such as Proxy
   Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that
   their prefixes have mobility, and therefore, the MN IP stack can make
   an educated selection between prefixes that have mobility and those
   that do not.  There is also a potential need to extend both [RFC3493]
   and [RFC5014] in order to provide required hooks into socket APIs.

   The underlying assumption is that a MN has multiple prefixes to
   choose from.  Typically this means either the MN has multiple
   interfaces or an interface has been configured with multiple
   prefixes.  This specification does not make a distinction between
   these alternatives and does not either make any assumptions how the
   possible transfer of a prefix is done between interfaces in the case
   a network based mobility solution is used.

Korhonen, et al.        Expires January 11, 2014                [Page 4]

Internet-Draft           IPv6 Prefix Properties                July 2013

2.  Background and Motivation

   This section discusses the motivations behind adding metadata and
   other address selection decision making affecting information into
   IPv6 prefixes.  The additional information is conveyed from the
   network to a end host during the IPv6 address configuration phase.
   The motivation example taken from and discussed below is from the
   mobile networks.

   IP mobility and its centralized topological anchoring of IP addresses
   has known issues.  For instance, non-optimal routing is a classical
   example.  Another concerns include excessive tunneling, increased
   signaling due the maintenance of mobility related bindings,
   aggregation of traffic to centralized mobility anchor gateways and
   unnecessary IP mobility related state management for IP traffic that
   does not as such benefit from mobility.  In general, it is observed
   that most applications do not need IP level mobility, and work just
   fine with "temporary" IP addresses that come and go.  However, IP
   mobility still has its virtues making the applications unaware of
   mobility, and certain wireless mobile networking architecture make
   extensive use of network based IP mobility.

   In order to overcome some of the above issues, use of local resources
   and topologically local addressing could be enhanced.  In many cases
   this would lead to use of multiple addresses of which some provide
   mobility and some do not.  However, an end host has to have means to
   distinguish between addresses that provide mobility, and those that
   are short lived and usable only within a limited topological area.

   [I-D.seite-dmm-dma] and [I-D.draft-liu-dmm-dynamic-anchor-discussion]
   discuss the dynamic anchor solution for distributed mobility
   management.  The idea is to use the local allocated prefix for any
   newly initiated 'IP session' and use the previously allocated prefix
   for the ongoing sessions.  This specification can be used to
   implement the prefix selection for dynamic anchoring.  For example,
   both the locally allocated and the remotely allocated/anchored
   prefixes can be identified by the prefix property option as described
   in Section 3.2.

   This specification also shares similar motivations for classifying
   the prefix as described in [I-D.bhandari-dhc-class-based-prefix].
   Some service providers may wish to allocate specific prefixes for
   some services or type of traffic.  In this situation, the end host
   must be able to classify prefixes according to type of service.

   This specification provides tools for extending the IPv6 address
   management and source address selection so that end hosts (and their
   applications) can select a proper address for their needs.  This

Korhonen, et al.        Expires January 11, 2014                [Page 5]

Internet-Draft           IPv6 Prefix Properties                July 2013

   specification complements [I-D.bhandari-dhc-class-based-prefix] by
   providing the SLAAC version of the additional prefix related meta
   data information delivery compared to the DHCPv6 stateful approach.

3.  Option Formats

3.1.  Prefix Information Option with Meta Data

   This specification defines a new neighbor discovery protocol message
   option, the Prefix Information Option with Meta Data (PIOMT), to be
   used in router advertisement messages.  The PIOMT is treated exactly
   the same as [RFC4861] Prefix Information Option (PIO) except with an
   addition of new meta data suboptions.

   The PIOMT can coexist with RFC4861 PIO.  The prefixes advertised in
   both PIOMT and PIO can even be the same.  It is up to the receiving
   end host to select the appropriate prefix(es) for configuring its
   IPv6 addresses.  In a case the PIO and the PIOMT share the same
   prefix, then all the other parameter (like flags and lifetimes) MUST
   be the same.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |      Type     |    Length     | Prefix Length |L|A| Reserved1 |
       |                         Valid Lifetime                        |
       |                       Preferred Lifetime                      |
       |                            Reserved2                          |
       |                                                               |
       +                                                               +
       |                                                               |
       +                            Prefix                             +
       |                                                               |
       +                                                               +
       |                                                               |
       :                          Suboptions                           :

       Figure 1: Prefix Information Option with additional meta data

Korhonen, et al.        Expires January 11, 2014                [Page 6]

Internet-Draft           IPv6 Prefix Properties                July 2013


       Set to TBD1.


       4 if no suboptions are present.  Greater than 4 if one or more
       suboptions are present.


       Zero or more suboptions that describe properties and other meta
       data attached to the advertised prefix.  See Section 3.2 for
       description of the meta data suboption format and suboptions
       already defined in this specification.  The existence of
       suboptions can be determined from the length field.  If the
       length is greater than 4, then at least one suboption MUST be

   Rest of the fields are handled exactly as described in Section 4.6.2.
   of RFC4861 [RFC4861].

3.2.  Meta Data Suboptions

   The generic suboption format for the PIO with meta data (PIOMT) is
   shown in Figure 2.  The suboption follows the alignment and length
   rules familiar from [RFC4861].  On a particular note, the flag 'C'
   describes whether the suboption is mandatory to understand by the
   receiver or not.  If 'C' is set to zero (0), the receiver can
   silently discard an unknown suboption and skip to the next suboption.
   If 'C' is set to one (1), then an unknown suboption causes the
   receiver to silently discard the entire PIOMT and no further
   suboptions need to be parsed.  There can be multiple instances of the
   same suboption type in one PIOMT option.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |     Type      |    Length     |C|          Reserved           |
       |                              ...                              ~

               Figure 2: Generic meta data suboption format

   Figure 3 shows the Prefix Properties suboption.  The prefix
   properties values are defined in Section 6.1. of
   [I-D.bhandari-dhc-class-based-prefix].  When an end host receives a

Korhonen, et al.        Expires January 11, 2014                [Page 7]

Internet-Draft           IPv6 Prefix Properties                July 2013

   router advertisement message with a PIOMT and the prefix properties
   suboption, it can use the suboption information as an additional hint
   for selecting the prefix for a desired purpose and use case.  The
   prefix properties have global meaning i.e., they have the same
   treatment and handling cross administrative domains.  The value for
   the 'C' flag SHOULD be one (1).  This also implies that if the prefix
   properties bit vector has a flag bit set, which the receiving end
   host does not understand and the 'C' flag is also set, then the whole
   PIOMT option MUST be discarded.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |       0       |        1      |C|         Reserved1           |
       |        Prefix properties      |           Reserved2           |

                   Figure 3: Prefix Properties suboption

   Figure 4 shows the Prefix Class suboption.  The prefix class values
   and usage follow what has been defined in Section 2.3. of
   [I-D.bhandari-dhc-class-based-prefix].  When an end host receives a
   router advertisement message with a PIOMT and the prefix class
   suboption, it can use the suboption information as an additional hint
   for selecting the prefix for a desired purpose and use case.  The
   prefix class has only local administrative meaning i.e., they are
   local to the access network and may overlap both semantically and
   registry wise across different administrative domains.  How the
   boundaries of an administrative domain are determined is outside the
   scope of this specification.  The value for the 'C' flag SHOULD be
   zero (0).

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |       1       |        1      |C|         Reserved1           |
       |         Prefix class          |           Reserved2           |

                     Figure 4: Prefix Class suboption

   Future specifications MAY define new suboptions.  One potential
   example could be a suboption to identify the provisioning domain
   where the configuration information originates.

Korhonen, et al.        Expires January 11, 2014                [Page 8]

Internet-Draft           IPv6 Prefix Properties                July 2013

4.  Host Considerations

4.1.  Stateless Address Autoconfiguration Enhancements

   This specification extends to the [RFC4862] Stateless Address
   Autoconfiguration (SLAAC).  As described in Section 3.1, a new
   [RFC4861] PIO like option PIOMT can be used to either complement or
   entirely replace the PIO in a router advertisement.  An end host that
   understands the PIOMT option MUST always prefer a prefix found in the
   PIOMT over the same prefix found in the PIO option.

4.2.  Internal Data Structures

   The host internal data structures need to be extended with the
   'prefix property' and the 'prefix class' information associated to
   the learned prefix and configured addresses.  How this is
   accomplished is host implementation specific.  It is also a host
   implementation issue how an application can learn or query both
   properties or class of an address or a prefix.  One possibility is to
   provide such information through the socket API extensions (see
   discussion in [I-D.liu-dmm-mobility-api]).  Other possibilities
   include the use of e.g., ioctl() or NetLink [RFC3549] extensions.

4.3.  Default Address Selection

   The 'prefix property' is only used as a hint.  It does not affect the
   existing [RFC6724] automatically.  A specific rule to host's policy
   table has to be inserted by an application or some daemon process.
   Alternatively, an application can express its address mobility
   property preferences through the socket API extensions (see
   discussion in [I-D.liu-dmm-mobility-api]), which means the socket
   library or middleware has to modify [RFC6724] policy table or

   The 'prefix properties' flags MAY define the prefix preference for an
   IP stack that understands the extensions defined in this
   specification.  The IP stack SHOULD use the properties preferences to
   supersede [RFC6724] Source Address Selection Rule 8 when selecting a
   default source address among multiple choices and an application has
   not explicitly indicate what kind of source address it prefers.

   The 'prefix class' defines an application 'class' the advertised
   prefix is intended to be used for.  The class has only local
   administrative domain significance.  The 'prefix class' can be used,
   for example, to identify prefixes that are meant to be used reach a
   voice over IP (VoIP) service or a video streaming application within
   the local administrative network.  A specific application in the end
   host MAY use this additional class information when enumerating

Korhonen, et al.        Expires January 11, 2014                [Page 9]

Internet-Draft           IPv6 Prefix Properties                July 2013

   through multiple available addresses and then select a specific
   address to be used for its purposes.

5.  Router Considerations

   A network administrator MAY configure routers complying to this
   specification that also emit router advertisements to include the
   PIOMT option into every router advertisement that would also contain
   the [RFC4861] PIO option.  Since the PIOMT emitting router has no
   prior knowledge whether the end hosts on the link support the PIOMT
   option, it is strongly RECOMMENDED that both [RFC4861] PIO and the
   PIOMT are always included in the router advertisement, even if the
   advertised prefixes were the same.  Whether a router sends router
   advertisements containing the PIOMT options is a local administrative

   A router can also make use of the 'C' flag handling in the PIOMT
   suboptions when introducing new functionality into the network.
   Since it is possible to include multiple suboptions of the same type
   into the PIOMT option, the router can easily make a difference
   between e.g., prefix properties that must be understood by the
   receiver and those that can safely be ignored.

6.  Security Considerations

   Existing Prefix Information Option related security considerations
   apply as described in [RFC4861] and [RFC4191].  A malicious node on
   the shared link could include such 'mobility property' flags in a
   Prefix Information Option causing the host to learn wrong information
   regarding the prefix and thus make misguided selection of prefixes on
   the link.  Similarly a malicious middleman on the link could modify
   'mobility property' flags in a Prefix Information Option causing
   misguided selection of prefixes.  In order to avoid on-link attacks,
   SeND [RFC3971] can be used to reject Router Advertisements from
   potentially malicious nodes and guarantee integrity protection of the
   Router Advertisements.

7.  IANA Considerations

   Section 3.1 defines a new IPv6 Neighbor Discovery protocol option
   type TBD1 for the Prefix Information Option with Meta Data.  The type
   value is defined in the existing 'IPv6 Neighbor Discovery Option
   Formats' IANA registry.

   Section 3.2 defines a new IANA registry for the Prefix Information

Korhonen, et al.        Expires January 11, 2014               [Page 10]

Internet-Draft           IPv6 Prefix Properties                July 2013

   Option with Meta Data suboptions.  The registry allocation policy is
   Standards Action [RFC5226].  The initial allocations for the prefix
   properties and prefix class suboptions are listed in Section 3.2.

8.  Acknowledgements

   The authors thank Ole Troan for his feedback and suggestions on this
   document (the Classed PIO).

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

9.2.  Informative References

              Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
              Thiebaut, L., and J. Korhonen, "DHCPv6 class based
              prefix", draft-bhandari-dhc-class-based-prefix-04 (work in
              progress), February 2013.

              Damic, D., "Proxy Mobile IPv6 indication and discovery",
              draft-damic-6man-pmip6-ind-00 (work in progress),
              March 2009.

              Liu, D., "DMM Dynamic Anchor Discussion",

Korhonen, et al.        Expires January 11, 2014               [Page 11]

Internet-Draft           IPv6 Prefix Properties                July 2013

              draft-liu-dmm-dynamic-anchor-discussion-00 (work in
              progress), March 2012.

              Liu, D. and H. Deng, "Mobility API Extension for
              Distributed Mobility Management",
              draft-liu-dmm-mobility-api-01 (work in progress),
              July 2013.

              Seite, P., Bertin, P., and J. Lee, "Distributed Mobility
              Anchoring", draft-seite-dmm-dma-06 (work in progress),
              January 2013.

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, February 2003.

   [RFC3549]  Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov,
              "Linux Netlink as an IP Services Protocol", RFC 3549,
              July 2003.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC5014]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
              Socket API for Source Address Selection", RFC 5014,
              September 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

              3GPP, "3GPP Evolved Packet System (EPS);  Evolved General
              Packet Radio Service (GPRS)  Tunnelling Protocol for
              Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0,
              December 2010.

Korhonen, et al.        Expires January 11, 2014               [Page 12]

Internet-Draft           IPv6 Prefix Properties                July 2013

Authors' Addresses

   Jouni Korhonen
   Renesas Mobile
   Porkkalankatu 24
   FIN-00180 Helsinki

   Email: jouni.nospam@gmail.com

   Basavaraj Patil

   Email: bpatil1@gmail.com

   Sri Gundavelli
   170 West Tasman Drive
   San Jose, CA  95134

   Email: sgundave@cisco.com

   Pierrick Seite
   4, rue du Clos Courtel, BP 91226
   Cesson-Sevigne  35512

   Email: pierrick.seite@orange.com

   Dapeng Liu
   China Mobile
   32 Xuanwumen West Street
   Beijng, Xicheng District  100053

   Email: liudapeng@chinamobile.com

Korhonen, et al.        Expires January 11, 2014               [Page 13]