idnits 2.17.00 (12 Aug 2021) /tmp/idnits22316/draft-korhonen-dmm-prefix-properties-02.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 (July 7, 2012) is 3604 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) == Outdated reference: draft-ietf-6man-rfc3484bis has been published as RFC 6724 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-bhandari-dhc-class-based-prefix-01 == Outdated reference: A later version (-02) exists of draft-liu-dmm-mobility-api-00 Summary: 1 error (**), 0 flaws (~~), 4 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: January 8, 2013 S. Gundavelli 7 Cisco 8 P. Seite 9 France Telecom - Orange 10 D. Liu 11 China Mobile 12 July 7, 2012 14 IPv6 Prefix Mobility Management Properties 15 draft-korhonen-dmm-prefix-properties-02.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 January 8, 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 16367 are vendor specific. Class 222 values between 16368 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 [I-D.ietf-6man-rfc3484bis] automatically, 243 except for the 'M' flag as described later. A specific rule to 244 host's policy table has to be inserted by an application or some 245 daemon process. Alternatively, an application can express its 246 address mobility property preferences through the socket API 247 extensions (see discussion in [I-D.liu-dmm-mobility-api]), which 248 means the socket library or middleware has to modify 249 [I-D.ietf-6man-rfc3484bis] policy table or 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 254 [I-D.ietf-6man-rfc3484bis] Source Address Selection Rule 8 when 255 selecting a default source address among multiple choices and an 256 application has not explicitly indicate what kind of source address 257 it prefers: 259 0 Default preference. 261 1 Low preference. 263 5. Security Considerations 265 Existing Prefix Information Option related security considerations 266 apply as described in [RFC4861] and [RFC4191]. A malicious node on 267 the shared link could include such 'mobility property' flags in a 268 Prefix Information Option causing the host to learn wrong information 269 regarding the prefix and thus make misguided selection of prefixes on 270 the link. Similarly a malicious middleman on the link could modify 271 'mobility property' flags in a Prefix Information Option causing 272 misguided selection of prefixes. In order to avoid on-link attacks, 273 SeND [RFC3971] can be used to reject Router Advertisements from 274 potentially malicious nodes and guarantee integrity protection of the 275 Router Advertisements. 277 6. IANA Considerations 279 Section 3 defines a new flag bits and fields to the IPv6 Neighbor 280 Discovery protocol's Prefix Information Option [RFC4861]. 282 Section 3 creates a new 'prefix Class' registry under the Internet 283 Control Message Protocol version 6 (ICMPv6) Parameters registry. 284 Value 0 is reserved. Values from 1 to 8191 are allocated according 285 to the RFC Required policy [RFC5226]. Values between 8192 and 16367 286 have the First Come First Served allocation policy [RFC5226]. 287 Finally, values from 16368 to 16383 are reserved for Private Use 288 [RFC5226]. 290 7. References 291 7.1. Normative References 293 [I-D.ietf-6man-rfc3484bis] 294 Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 295 "Default Address Selection for Internet Protocol version 6 296 (IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress), 297 June 2012. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 303 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 304 September 2007. 306 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 307 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 308 May 2008. 310 7.2. Informative References 312 [I-D.bhandari-dhc-class-based-prefix] 313 Systems, C., Halwasia, G., Bandi, S., Gundavelli, S., and 314 H. Deng, "DHCPv6 class based prefix", 315 draft-bhandari-dhc-class-based-prefix-01 (work in 316 progress), March 2012. 318 [I-D.liu-dmm-mobility-api] 319 Liu, D. and H. Deng, "Mobility API Extension for DMM", 320 draft-liu-dmm-mobility-api-00 (work in progress), 321 March 2012. 323 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 324 Stevens, "Basic Socket Interface Extensions for IPv6", 325 RFC 3493, February 2003. 327 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 328 "Linux Netlink as an IP Services Protocol", RFC 3549, 329 July 2003. 331 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 332 Neighbor Discovery (SEND)", RFC 3971, March 2005. 334 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 335 More-Specific Routes", RFC 4191, November 2005. 337 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 338 Socket API for Source Address Selection", RFC 5014, 339 September 2007. 341 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 342 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 344 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 345 in IPv6", RFC 6275, July 2011. 347 [TS.29274] 348 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 349 Packet Radio Service (GPRS) Tunnelling Protocol for 350 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 351 December 2010. 353 Authors' Addresses 355 Jouni Korhonen 356 Nokia Siemens Networks 357 Linnoitustie 6 358 FIN-02600 Espoo 359 Finland 361 Email: jouni.nospam@gmail.com 363 Basavaraj Patil 364 Nokia 365 6021 Connection Drive 366 Irving, TX 75039 367 USA 369 Email: basavaraj.patil@nokia.com 371 Sri Gundavelli 372 Cisco 373 170 West Tasman Drive 374 San Jose, CA 95134 375 USA 377 Email: sgundave@cisco.com 378 Pierrick Seite 379 France Telecom - Orange 380 4, rue du Clos Courtel, BP 91226 381 Cesson-Sevigne 35512 382 France 384 Email: pierrick.seite@orange.com 386 Dapeng Liu 387 China Mobile 388 32 Xuanwumen West Street 389 Beijng, Xicheng District 100053 390 China 392 Email: liudapeng@chinamobile.com