Distributed Mobility Management (DMM) J. Korhonen Internet-Draft Renesas Mobile Updates: 4861, 4862 (if approved) B. Patil Intended status: Standards Track S. Gundavelli Expires: August 29, 2013 Cisco P. Seite France Telecom - Orange D. Liu China Mobile February 25, 2013 IPv6 Prefix Properties draft-korhonen-6man-prefix-properties-01.txt Abstract This specification defines an extension to the IPv6 Neighbor Discovery protocol and the stateless address autoconfiguration procedure. The Prefix Information Option is extended with flag bits that describe the properties associated to the prefix. A new Classed Prefix Information Option is also defined to associate an advertised prefix with an additional meta data that the stateless address autoconfiguration procedure and end hosts can make use of. This specification updates RFC4861 and RFC4862. 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 29, 2013. Korhonen, et al. Expires August 29, 2013 [Page 1] Internet-Draft IPv6 Prefix Properties February 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background and Motivation . . . . . . . . . . . . . . . . . . . 4 3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Prefix Information Option . . . . . . . . . . . . . . . . . 4 3.2. Classed Prefix Information Option . . . . . . . . . . . . . 5 4. Host Considerations . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Internal Data Structures . . . . . . . . . . . . . . . . . 7 4.2. Default Address Selection . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Korhonen, et al. Expires August 29, 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. There has been attemps 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 [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. Korhonen, et al. Expires August 29, 2013 [Page 3] Internet-Draft IPv6 Prefix Properties February 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 convey 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. 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]. 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 3.1. Prefix Information Option 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 Korhonen, et al. Expires August 29, 2013 [Page 4] Internet-Draft IPv6 Prefix Properties February 2013 [RFC4861] that is extended with the 'Properties' flag bits: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Properties | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: 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'. 3.2. Classed Prefix Information Option This specification defines a new neighbor discovery message option: the Classed Prefix Information Option (CPIO). Figure 2 illustrates the new Classed Prefix Information Option. The CPIO behaves in a same way than the "conventional" RFC4861 PIO, except that an updated SLAAC [RFC4862] procedure will only configure addresses out CPIO advertised prefixes when host stack actually understands the new option type and founds a 'Class' that it is interested in. Korhonen, et al. Expires August 29, 2013 [Page 5] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 4 | Prefix Length |L|A| Rsvd1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Properties | Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Classed Prefix Information Option Type Classed Prefix Information Option type set to value TBD. 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'. Korhonen, et al. Expires August 29, 2013 [Page 6] Internet-Draft IPv6 Prefix Properties February 2013 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 discussion in [I-D.liu-dmm-mobility-api]). Other possibilities include the use of e.g., ioctl() or NetLink [RFC3549] extensions. [Editor's note: The SLAAC procedure using the CPIO and the 'Class' meta data to be described in more detail.] 4.2. Default Address Selection The 'prefix Property' 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 '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. [Editor's note: Describe the 'prefix Class' usage when doing address selection and how applications can make use of it.] 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 Korhonen, et al. Expires August 29, 2013 [Page 7] Internet-Draft IPv6 Prefix Properties February 2013 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]. Figure 2 defines a new neighbor discovery message option Type into the existing IPv6 Neighbor Discovery Option Formats registry. 7. Acknowledgements The authors thank Ole Troan for his feedback and suggestions on this document (the Classed PIO). 8. References 8.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. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. 8.2. Informative References [I-D.bhandari-dhc-class-based-prefix] Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L., and J. Korhonen, "DHCPv6 class based Korhonen, et al. Expires August 29, 2013 [Page 8] Internet-Draft IPv6 Prefix Properties February 2013 prefix", draft-bhandari-dhc-class-based-prefix-04 (work in progress), February 2013. [I-D.damic-6man-pmip6-ind] Damic, D., "Proxy Mobile IPv6 indication and discovery", draft-damic-6man-pmip6-ind-00 (work in progress), March 2009. [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 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. Korhonen, et al. Expires August 29, 2013 [Page 9] Internet-Draft IPv6 Prefix Properties February 2013 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 Dapeng Liu China Mobile 32 Xuanwumen West Street Beijng, Xicheng District 100053 China Email: liudapeng@chinamobile.com Korhonen, et al. Expires August 29, 2013 [Page 10]