Distributed Mobility Management (DMM) J. Korhonen
Internet-Draft Renesas Mobile
Updates: 4861 (if approved) B. Patil
Intended status: Standards Track S. Gundavelli
Expires: August 20, 2013 Cisco
P. Seite
France Telecom - Orange
D. Liu
China Mobile
February 16, 2013
IPv6 Prefix Properties
draft-korhonen-6man-prefix-properties-00.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
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 August 20, 2013.
Copyright Notice
Korhonen, et al. Expires August 20, 2013 [Page 1]
Internet-Draft IPv6 Prefix Properties February 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background and Motivation . . . . . . . . . . . . . . . . . . . 3
3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Host Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Internal Data Structures . . . . . . . . . . . . . . . . . 5
4.2. Default Address Selection . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Korhonen, et al. Expires August 20, 2013 [Page 2]
Internet-Draft IPv6 Prefix Properties February 2013
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, for example, the mobility management properties associated
to the prefix, and a class value that conveys metadata associated to
the prefix with 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. Outside the mobility protocols,
there are other potential use cases where associating properties to
the advertised prefixes could be useful as discussed in
[I-D.bhandari-dhc-class-based-prefix].
The extensions to [RFC4861] are minimal in a sense that they do not
define new functionality to, for example, 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
This section discusses the motivations behind adding metadata and
other address selection decision making affecting information into
IPv6 prefixes. The additional information is convey from the network
to a end host during the IPv6 address configuration phase. The
Korhonen, et al. Expires August 20, 2013 [Page 3]
Internet-Draft IPv6 Prefix Properties February 2013
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.
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 outside mobility protocols as described in
[I-D.bhandari-dhc-class-based-prefix]. This specification
complements [I-D.bhandari-dhc-class-based-prefix] by providing the
SLAAC version of the additional prefix related information delivery
compared to the DHCPv6 stateful approach.
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 the Class value and the Properties
flag bits:
Korhonen, et al. Expires August 20, 2013 [Page 4]
Internet-Draft IPv6 Prefix Properties February 2013
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class | Properties |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended Prefix Information Option
Properties 16 bits vector of flags for prefix properties. The
prefix property adds complementary information to e.g., mobility,
Internet reachability and security properties. The possible
values are described in Section 6.1 of
[I-D.bhandari-dhc-class-based-prefix]. The value '0' is reserved
and states nothing about the prefix. Unknown Properties are
treated as value '0'.
Class 16 bits of metadata associated with the prefix. The Class has
only local relevance within an administrative domain. There are
no centralized registry available for the Class values. The
value '0' is reserved and states nothing about the prefix.
Unknown Class is treated as value '0'.
4. Host Considerations
4.1. 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
Korhonen, et al. Expires August 20, 2013 [Page 5]
Internet-Draft IPv6 Prefix Properties February 2013
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' and the 'prefix Class' information is only used
as a hint. They do 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 algorithm.
The IP stack MAY use the 'prefix Properties' flags and 'prefix Class'
information 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.
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 two new fields into the IPv6 Neighbor Discovery
protocol's Prefix Information Option [RFC4861]. The prefix Class
field has only local administrative domain relevance and causes no
IANA actions. The prefix Properties bit vector flags field reuses
the existing DHCPv6 OPTION_PREFIX_PROPERTY values registry
established by [I-D.bhandari-dhc-class-based-prefix].
7. References
Korhonen, et al. Expires August 20, 2013 [Page 6]
Internet-Draft IPv6 Prefix Properties February 2013
7.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.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
7.2. Informative References
[I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Bandi, S., Gundavelli, S.,
Deng, H., and L. Thiebaut, "DHCPv6 class based prefix",
draft-bhandari-dhc-class-based-prefix-03 (work in
progress), July 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,
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
Korhonen, et al. Expires August 20, 2013 [Page 7]
Internet-Draft IPv6 Prefix Properties February 2013
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
Renesas Mobile
Porkkalankatu 24
FIN-00180 Helsinki
Finland
Email: jouni.nospam@gmail.com
Basavaraj Patil
Cisco
Email: bpatil1@gmail.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Pierrick Seite
France Telecom - Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange.com
Korhonen, et al. Expires August 20, 2013 [Page 8]
Internet-Draft IPv6 Prefix Properties February 2013
Dapeng Liu
China Mobile
32 Xuanwumen West Street
Beijng, Xicheng District 100053
China
Email: liudapeng@chinamobile.com
Korhonen, et al. Expires August 20, 2013 [Page 9]