Skip to main content

IPv6 Prefix Mobility Management Properties
draft-korhonen-dmm-prefix-properties-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jouni Korhonen , Basavaraj Patil , Sri Gundavelli , Pierrick Seite , Dapeng Liu
Last updated 2012-07-06
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-korhonen-dmm-prefix-properties-02
Distributed Mobility Management (DMM)                        J. Korhonen
Internet-Draft                                    Nokia Siemens Networks
Updates: 4861 (if approved)                                     B. Patil
Intended status: Standards Track                                   Nokia
Expires: January 8, 2013                                   S. Gundavelli
                                                                   Cisco
                                                                P. Seite
                                                 France Telecom - Orange
                                                                  D. Liu
                                                            China Mobile
                                                            July 7, 2012

               IPv6 Prefix Mobility Management Properties
              draft-korhonen-dmm-prefix-properties-02.txt

Abstract

   This specification defines an extension to the IPv6 Neighbor
   Discovery protocol and its Prefix Information Option.  The Prefix
   Information Option is extended with flag bits that describe the
   mobility management properties associated to the prefix.  This
   specification updates RFC4861.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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."

   This Internet-Draft will expire on January 8, 2013.

Copyright Notice

Korhonen, et al.         Expires January 8, 2013                [Page 1]
Internet-Draft           IPv6 Prefix Properties                July 2012

   Copyright (c) 2012 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Background and Motivation . . . . . . . . . . . . . . . . . . . 3
   3.  Option Formats  . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Host Considerations . . . . . . . . . . . . . . . . . . . . . . 6
     4.1.  Internal Data Structures  . . . . . . . . . . . . . . . . . 6
     4.2.  Default Address Selection . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Korhonen, et al.         Expires January 8, 2013                [Page 2]
Internet-Draft           IPv6 Prefix Properties                July 2012

1.  Introduction

   This specification defines an extension to the IPv6 Neighbor
   Discovery protocol and its Prefix Information Option (PIO) [RFC4861].
   The Prefix Information Option is extended with flag bits that
   describe the mobility management properties associated to the prefix,
   and at the same time defines corresponding source address selection
   hint flags to the IPv6 Socket API for Source Address Selection
   [RFC5014].

   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.

   The extensions to [RFC4861] are minimal in a sense that they do not
   define new functionality to any existing mobility protocol but
   instead add an explicit indication of network based mobility
   knowledge into the IPv6 stateless address autoconfiguration (SLAAC).

   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.

2.  Background and Motivation

   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

Korhonen, et al.         Expires January 8, 2013                [Page 3]
Internet-Draft           IPv6 Prefix Properties                July 2012

   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.
   This specification provides extensions to IPv6 address management and
   source address selection so that end hosts (and their applications)
   can select a proper address for their needs.

   This specification also shares similar motivations for classifying
   the prefix properties as described in
   [I-D.bhandari-dhc-class-based-prefix].

3.  Option Formats

   Neighbor Discovery messages include zero or more options, some of
   which may appear multiple times in the same message.  Options should
   be padded when necessary to ensure that they end on their natural 64-
   bit boundaries.  Figure 1 illustrates a Prefix Information Option
   [RFC4861] that is extended with a mobility and a security property
   flag bit, and a 'class' describing the properties of the prefix:

Korhonen, et al.         Expires January 8, 2013                [Page 4]
Internet-Draft           IPv6 Prefix Properties                July 2012

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       3       |       4       | Prefix Length |L|A|   Rsvd1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Valid Lifetime                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Preferred Lifetime                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|S|          Class            |       Reserved2               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                            Prefix                             +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1: Extended Prefix Information Option

   'M' 1-bit flag describing the mobility properties of the prefix.  The
       following properties are defined:

       0   No specific network based mobility property associated to the
           prefix.  The prefix is treated according to RFC4861.

       1   The prefix provides network based mobility and may remain
           unchanged the valid lifetime of the prefix.

   'S' 1-bit flag providing a hint of the security properties associated
       to the used prefix.  When set to '0' the prefix is assigned on an
       interface whose network connectivity to the first-hop router does
       not offer any kind of integrity or confidentiality guarantees.
       When set to '1' the prefix is assigned to an interface whose
       network connectivity offers some level of integrity or
       confidentiality guarantees between the end host and the first-hop
       router.  For example, the interface could be associated with a
       VPN.

   'Class'  14 bits of prefix class.  The prefix class adds
       complementary information to mobility and security properties, as
       also described in [I-D.bhandari-dhc-class-based-prefix].  The
       value '0' is reserved and stated nothing about the prefix.
       Unknown Class is treated as value '0'.

   We call the combination of the 'M' flag, the 'S' flag and the 'class'

Korhonen, et al.         Expires January 8, 2013                [Page 5]
Internet-Draft           IPv6 Prefix Properties                July 2012

   as the 'prefix property'.

   A common use case is to define the 'M' flag when the 'A'=1 i.e. when
   Stateless Address AutoConfiguration (SLAAC) is used.  However, it is
   possible to associate the 'M' flag also to prefixes when 'A'=0.  In
   cases when there are multiple learned prefixes with the 'M' flag set
   to a non-zero value that can also be aggregated, then the longest
   prefix takes precedence.

   If the prefix lifetime(s) is set to infinity that does not override
   the prefix mobility properties indicated in the 'M' flag.  For
   instance, a prefix with an infinite lifetime but the 'M' flag set to
   '0' indicate that the prefix may change abruptly due a handover at
   some point of time.

   A combination where all the 'M', 'S', and 'class' are set to zero
   ('0') is reserved, and used to indicate that the PIO sender has not
   implemented the extension specified in this document or does not want
   to state anything regarding the PIO.

   Prefix class values from 8192 to 16367 are vendor specific.  Class
   values between 16368 and 16383 are reserved for private and
   experimental use.

4.  Host Considerations

4.1.  Internal Data Structures

   The host internal data structures need to be extended with the
   'prefix property' 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 mobility properties 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.2.  Default Address Selection

   The 'prefix property' information is only used as a hint.  They do
   not affect the existing [I-D.ietf-6man-rfc3484bis] automatically,
   except for the 'M' flag as described later.  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

Korhonen, et al.         Expires January 8, 2013                [Page 6]
Internet-Draft           IPv6 Prefix Properties                July 2012

   means the socket library or middleware has to modify
   [I-D.ietf-6man-rfc3484bis] policy table or algorithm.

   The 'M' flag defines the prefix preference for an IP stack that
   understands the extensions defined in this specification.  The IP
   stack SHOULD use the following preferences to supersede
   [I-D.ietf-6man-rfc3484bis] 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:

   0   Default preference.

   1   Low preference.

5.  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.

6.  IANA Considerations

   Section 3 defines a new flag bits and fields to the IPv6 Neighbor
   Discovery protocol's Prefix Information Option [RFC4861].

   Section 3 creates a new 'prefix Class' registry under the Internet
   Control Message Protocol version 6 (ICMPv6) Parameters registry.
   Value 0 is reserved.  Values from 1 to 8191 are allocated according
   to the RFC Required policy [RFC5226].  Values between 8192 and 16367
   have the First Come First Served allocation policy [RFC5226].
   Finally, values from 16368 to 16383 are reserved for Private Use
   [RFC5226].

7.  References

Korhonen, et al.         Expires January 8, 2013                [Page 7]
Internet-Draft           IPv6 Prefix Properties                July 2012

7.1.  Normative References

   [I-D.ietf-6man-rfc3484bis]
              Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol version 6
              (IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress),
              June 2012.

   [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.

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

7.2.  Informative References

   [I-D.bhandari-dhc-class-based-prefix]
              Systems, C., Halwasia, G., Bandi, S., Gundavelli, S., and
              H. Deng, "DHCPv6 class based prefix",
              draft-bhandari-dhc-class-based-prefix-01 (work in
              progress), March 2012.

   [I-D.liu-dmm-mobility-api]
              Liu, D. and H. Deng, "Mobility API Extension for DMM",
              draft-liu-dmm-mobility-api-00 (work in progress),
              March 2012.

   [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,

Korhonen, et al.         Expires January 8, 2013                [Page 8]
Internet-Draft           IPv6 Prefix Properties                July 2012

              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.

   [TS.29274]
              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.

Authors' Addresses

   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   FIN-02600 Espoo
   Finland

   Email: jouni.nospam@gmail.com

   Basavaraj Patil
   Nokia
   6021 Connection Drive
   Irving,  TX  75039
   USA

   Email: basavaraj.patil@nokia.com

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com

Korhonen, et al.         Expires January 8, 2013                [Page 9]
Internet-Draft           IPv6 Prefix Properties                July 2012

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

   Email: pierrick.seite@orange.com

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

   Email: liudapeng@chinamobile.com

Korhonen, et al.         Expires January 8, 2013               [Page 10]