idnits 2.17.1 draft-korhonen-dmm-prefix-properties-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2012) is 4205 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-bhandari-dhc-class-based-prefix-03 == Outdated reference: A later version (-02) exists of draft-liu-dmm-mobility-api-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Distributed Mobility Management (DMM) J. Korhonen 3 Internet-Draft Nokia Siemens Networks 4 Updates: 4861 (if approved) B. Patil 5 Intended status: Standards Track Nokia 6 Expires: April 22, 2013 S. Gundavelli 7 Cisco 8 P. Seite 9 France Telecom - Orange 10 D. Liu 11 China Mobile 12 October 19, 2012 14 IPv6 Prefix Mobility Management Properties 15 draft-korhonen-dmm-prefix-properties-03.txt 17 Abstract 19 This specification defines an extension to the IPv6 Neighbor 20 Discovery protocol and its Prefix Information Option. The Prefix 21 Information Option is extended with flag bits that describe the 22 mobility management properties associated to the prefix. This 23 specification updates RFC4861. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 22, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Background and Motivation . . . . . . . . . . . . . . . . . . . 3 66 3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Host Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Internal Data Structures . . . . . . . . . . . . . . . . . 6 69 4.2. Default Address Selection . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 This specification defines an extension to the IPv6 Neighbor 80 Discovery protocol and its Prefix Information Option (PIO) [RFC4861]. 81 The Prefix Information Option is extended with flag bits that 82 describe the mobility management properties associated to the prefix, 83 and at the same time defines corresponding source address selection 84 hint flags to the IPv6 Socket API for Source Address Selection 85 [RFC5014]. 87 The IPv6 Socket API for Source Address Selection [RFC5014] already 88 covers Mobile IPv6 [RFC6275] and allows selecting between a home 89 address (HoA) and a care-of address (CoA). A mobile node (MN) with a 90 client based mobility IP stack is supposed to know which prefixes are 91 CoA(s) and/or HoA(s). However, this is not the case with network 92 based mobility management where the MN is expected to be agnostic of 93 the mobility support. 95 The extensions to [RFC4861] are minimal in a sense that they do not 96 define new functionality to any existing mobility protocol but 97 instead add an explicit indication of network based mobility 98 knowledge into the IPv6 stateless address autoconfiguration (SLAAC). 100 This would allow for network based mobility solutions, such as Proxy 101 Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that 102 their prefixes have mobility, and therefore, the MN IP stack can make 103 an educated selection between prefixes that have mobility and those 104 that do not. There is also a potential need to extend both [RFC3493] 105 and [RFC5014] in order to provide required hooks into socket APIs. 107 The underlying assumption is that a MN has multiple prefixes to 108 choose from. Typically this means either the MN has multiple 109 interfaces or an interface has been configured with multiple 110 prefixes. This specification does not make a distinction between 111 these alternatives and does not either make any assumptions how the 112 possible transfer of a prefix is done between interfaces in the case 113 a network based mobility solution is used. 115 2. Background and Motivation 117 IP mobility and its centralized topological anchoring of IP addresses 118 has known issues. For instance, non-optimal routing is a classical 119 example. Another concerns include excessive tunneling, increased 120 signaling due the maintenance of mobility related bindings, 121 aggregation of traffic to centralized mobility anchor gateways and 122 unnecessary IP mobility related state management for IP traffic that 123 does not as such benefit from mobility. In general, it is observed 124 that most applications do not need IP level mobility, and work just 125 fine with "temporary" IP addresses that come and go. However, IP 126 mobility still has its virtues making the applications unaware of 127 mobility, and certain wireless mobile networking architecture make 128 extensive use of network based IP mobility. 130 In order to overcome some of the above issues, use of local resources 131 and topologically local addressing could be enhanced. In many cases 132 this would lead to use of multiple addresses of which some provide 133 mobility and some do not. However, an end host has to have means to 134 distinguish between addresses that provide mobility, and those that 135 are short lived and usable only within a limited topological area. 136 This specification provides extensions to IPv6 address management and 137 source address selection so that end hosts (and their applications) 138 can select a proper address for their needs. 140 This specification also shares similar motivations for classifying 141 the prefix properties as described in 142 [I-D.bhandari-dhc-class-based-prefix]. 144 3. Option Formats 146 Neighbor Discovery messages include zero or more options, some of 147 which may appear multiple times in the same message. Options should 148 be padded when necessary to ensure that they end on their natural 64- 149 bit boundaries. Figure 1 illustrates a Prefix Information Option 150 [RFC4861] that is extended with a mobility and a security property 151 flag bit, and a 'class' describing the properties of the prefix: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | 3 | 4 | Prefix Length |L|A| Rsvd1 | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Valid Lifetime | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Preferred Lifetime | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 |M|S| Class | Reserved2 | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 + + 166 | | 167 + Prefix + 168 | | 169 + + 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: Extended Prefix Information Option 175 'M' 1-bit flag describing the mobility properties of the prefix. The 176 following properties are defined: 178 0 No specific network based mobility property associated to the 179 prefix. The prefix is treated according to RFC4861. 181 1 The prefix provides network based mobility and may remain 182 unchanged the valid lifetime of the prefix. 184 'S' 1-bit flag providing a hint of the security properties associated 185 to the used prefix. When set to '0' the prefix is assigned on an 186 interface whose network connectivity to the first-hop router does 187 not offer any kind of integrity or confidentiality guarantees. 188 When set to '1' the prefix is assigned to an interface whose 189 network connectivity offers some level of integrity or 190 confidentiality guarantees between the end host and the first-hop 191 router. For example, the interface could be associated with a 192 VPN. 194 'Class' 14 bits of prefix class. The prefix class adds 195 complementary information to mobility and security properties, as 196 also described in [I-D.bhandari-dhc-class-based-prefix]. The 197 value '0' is reserved and stated nothing about the prefix. 198 Unknown Class is treated as value '0'. 200 We call the combination of the 'M' flag, the 'S' flag and the 'class' 201 as the 'prefix property'. 203 A common use case is to define the 'M' flag when the 'A'=1 i.e. when 204 Stateless Address AutoConfiguration (SLAAC) is used. However, it is 205 possible to associate the 'M' flag also to prefixes when 'A'=0. In 206 cases when there are multiple learned prefixes with the 'M' flag set 207 to a non-zero value that can also be aggregated, then the longest 208 prefix takes precedence. 210 If the prefix lifetime(s) is set to infinity that does not override 211 the prefix mobility properties indicated in the 'M' flag. For 212 instance, a prefix with an infinite lifetime but the 'M' flag set to 213 '0' indicate that the prefix may change abruptly due a handover at 214 some point of time. 216 A combination where all the 'M', 'S', and 'class' are set to zero 217 ('0') is reserved, and used to indicate that the PIO sender has not 218 implemented the extension specified in this document or does not want 219 to state anything regarding the PIO. 221 Prefix class values from 8192 to 16368 are vendor specific. Class 222 values between 16369 and 16383 are reserved for private and 223 experimental use. 225 4. Host Considerations 227 4.1. Internal Data Structures 229 The host internal data structures need to be extended with the 230 'prefix property' information associated to the learned prefix and 231 configured addresses. How this is accomplished is host 232 implementation specific. It is also a host implementation issue how 233 an application can learn or query mobility properties of an address 234 or a prefix. One possibility is to provide such information through 235 the socket API extensions (see discussion in 236 [I-D.liu-dmm-mobility-api]). Other possibilities include the use of 237 e.g., ioctl() or NetLink [RFC3549] extensions. 239 4.2. Default Address Selection 241 The 'prefix property' information is only used as a hint. They do 242 not affect the existing [RFC6724] automatically, except for the 'M' 243 flag as described later. A specific rule to host's policy table has 244 to be inserted by an application or some daemon process. 245 Alternatively, an application can express its address mobility 246 property preferences through the socket API extensions (see 247 discussion in [I-D.liu-dmm-mobility-api]), which means the socket 248 library or middleware has to modify [RFC6724] policy table or 249 algorithm. 251 The 'M' flag defines the prefix preference for an IP stack that 252 understands the extensions defined in this specification. The IP 253 stack SHOULD use the following preferences to supersede [RFC6724] 254 Source Address Selection Rule 8 when selecting a default source 255 address among multiple choices and an application has not explicitly 256 indicate what kind of source address it prefers: 258 0 Default preference. 260 1 Low preference. 262 5. Security Considerations 264 Existing Prefix Information Option related security considerations 265 apply as described in [RFC4861] and [RFC4191]. A malicious node on 266 the shared link could include such 'mobility property' flags in a 267 Prefix Information Option causing the host to learn wrong information 268 regarding the prefix and thus make misguided selection of prefixes on 269 the link. Similarly a malicious middleman on the link could modify 270 'mobility property' flags in a Prefix Information Option causing 271 misguided selection of prefixes. In order to avoid on-link attacks, 272 SeND [RFC3971] can be used to reject Router Advertisements from 273 potentially malicious nodes and guarantee integrity protection of the 274 Router Advertisements. 276 6. IANA Considerations 278 Section 3 defines a new flag bits and fields to the IPv6 Neighbor 279 Discovery protocol's Prefix Information Option [RFC4861]. 281 Section 3 creates a new 'prefix Class' registry under the Internet 282 Control Message Protocol version 6 (ICMPv6) Parameters registry. 283 Value 0 is reserved. Values from 1 to 8191 are allocated according 284 to the RFC Required policy [RFC5226]. Values between 8192 and 16368 285 have the First Come First Served allocation policy [RFC5226]. 286 Finally, values from 16398 to 16383 are reserved for Private Use 287 [RFC5226]. 289 7. References 290 7.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 296 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 297 September 2007. 299 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 300 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 301 May 2008. 303 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 304 "Default Address Selection for Internet Protocol Version 6 305 (IPv6)", RFC 6724, September 2012. 307 7.2. Informative References 309 [I-D.bhandari-dhc-class-based-prefix] 310 Systems, C., Halwasia, G., Bandi, S., Gundavelli, S., 311 Deng, H., and L. Thiebaut, "DHCPv6 class based prefix", 312 draft-bhandari-dhc-class-based-prefix-03 (work in 313 progress), July 2012. 315 [I-D.liu-dmm-mobility-api] 316 Liu, D. and H. Deng, "Mobility API Extension for DMM", 317 draft-liu-dmm-mobility-api-00 (work in progress), 318 March 2012. 320 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 321 Stevens, "Basic Socket Interface Extensions for IPv6", 322 RFC 3493, February 2003. 324 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 325 "Linux Netlink as an IP Services Protocol", RFC 3549, 326 July 2003. 328 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 329 Neighbor Discovery (SEND)", RFC 3971, March 2005. 331 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 332 More-Specific Routes", RFC 4191, November 2005. 334 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 335 Socket API for Source Address Selection", RFC 5014, 336 September 2007. 338 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 339 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 341 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 342 in IPv6", RFC 6275, July 2011. 344 [TS.29274] 345 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 346 Packet Radio Service (GPRS) Tunnelling Protocol for 347 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 348 December 2010. 350 Authors' Addresses 352 Jouni Korhonen 353 Nokia Siemens Networks 354 Linnoitustie 6 355 FIN-02600 Espoo 356 Finland 358 Email: jouni.nospam@gmail.com 360 Basavaraj Patil 361 Nokia 362 6021 Connection Drive 363 Irving, TX 75039 364 USA 366 Email: basavaraj.patil@nokia.com 368 Sri Gundavelli 369 Cisco 370 170 West Tasman Drive 371 San Jose, CA 95134 372 USA 374 Email: sgundave@cisco.com 375 Pierrick Seite 376 France Telecom - Orange 377 4, rue du Clos Courtel, BP 91226 378 Cesson-Sevigne 35512 379 France 381 Email: pierrick.seite@orange.com 383 Dapeng Liu 384 China Mobile 385 32 Xuanwumen West Street 386 Beijng, Xicheng District 100053 387 China 389 Email: liudapeng@chinamobile.com