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 05, 2013.

Copyright Notice

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
• 2. Background and Motivation
• 3. Option Formats
• 4. Host Considerations
• 4.1. Internal Data Structures
• 4.2. Default Address Selection
• 5. Security Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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

 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                             +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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:

'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' 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 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

7.1. Normative References

7.2. Informative References

Authors' Addresses