idnits 2.17.00 (12 Aug 2021) /tmp/idnits21563/draft-korhonen-dmm-prefix-properties-01.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 (March 11, 2012) is 3722 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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,3484 (if approved) B. Patil 5 Intended status: Standards Track Nokia 6 Expires: September 12, 2012 S. Gundavelli 7 Cisco 8 March 11, 2012 10 IPv6 Prefix Mobility Management Properties 11 draft-korhonen-dmm-prefix-properties-01.txt 13 Abstract 15 This specification defines an extension to the IPv6 Neighbor 16 Discovery protocol and its Prefix Information Option. The Prefix 17 Information Option is extended with flag bits that describe the 18 mobility management properties associated to the prefix. This 19 specification updates RFC4861 and also updates RFC3484 Source Address 20 Selection algorithm. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 12, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Background and Motivation . . . . . . . . . . . . . . . . . . . 3 64 3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Host Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Internal Data Structures . . . . . . . . . . . . . . . . . 6 67 4.2. Default Address Selection . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Appendix A. Additions to the Socket Interface and the 74 Protocol-Independent Nodename Translation . . . . . . 8 75 A.1. Socket Interface . . . . . . . . . . . . . . . . . . . . . 8 76 A.2. Protocol-Independent Nodename Translation . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 This specification defines an extension to the IPv6 Neighbor 82 Discovery protocol and its Prefix Information Option (PIO) [RFC4861]. 83 The Prefix Information Option is extended with flag bits that 84 describe the mobility management properties associated to the prefix, 85 and at the same time defines corresponding source address selection 86 hint flags to the IPv6 Socket API for Source Address Selection 87 [RFC5014]. 89 The IPv6 Socket API for Source Address Selection [RFC5014] already 90 covers Mobile IPv6 [RFC6275] and allows selecting between a home 91 address (HoA) and a care-of address (CoA). A mobile node (MN) with a 92 client based mobility IP stack is supposed to know which prefixes are 93 CoA(s) and/or HoA(s). The extensions to [RFC4861] are minimal in a 94 sense that they do not define new functionality to any existing 95 mobility protocol but instead add an explicit indication of network 96 based mobility knowledge into the IPv6 stateless address 97 autoconfiguration (SLAAC). This would allow for network based 98 mobility solutions, such as Proxy Mobile IPv6 [RFC5213] or GTP 99 [TS.29274] to explicitly indicate that their prefixes have mobility, 100 and therefore, the MN IP stack can make an educated selection between 101 prefixes that have mobility and those that do not. There is also a 102 potential need to extend both [RFC3493] and [RFC5014] in order to 103 provide required hooks into socket APIs. 105 The underlying assumption is that a MN has multiple prefixes to 106 choose from. Typically this means either the MN has multiple 107 interfaces or an interface has been configured with multiple 108 prefixes. This specification does not make a distinction between 109 these alternatives and does not either make any assumptions how the 110 possible transfer of a prefix is done between interfaces in the case 111 a network based mobility solution is used. 113 2. Background and Motivation 115 IP mobility and its centralized topological anchoring of IP addresses 116 has known issues. For instance, non-optimal routing is a classical 117 example. Another concerns include excessive tunneling, increased 118 signaling due the maintenance of mobility related bindings, 119 aggregation of traffic to centralized mobility anchor gateways and 120 unnecessary IP mobility related state management for IP traffic that 121 does not as such benefit from mobility. In general, it is observed 122 that most applications do not need IP level mobility, and work just 123 fine with "temporary" IP addresses that come and go. However, IP 124 mobility still has its virtues making the applications unaware of 125 mobility, and certain wireless mobile networking architecture make 126 extensive use of network based IP mobility. 128 In order to overcome some of the above issues, use of local resources 129 and topologically local addressing could be enhanced. In many cases 130 this would lead to use of multiple addresses of which some provide 131 mobility and some do not. However, an end host has to have means to 132 distinguish between addresses that provide mobility, and those that 133 are short lived and usable only within a limited topological area. 134 This specification provides extensions to IPv6 address management and 135 source address selection so that end hosts (and their applications) 136 can select a proper address for their needs. 138 [to be enhanced] 140 3. Option Formats 142 Neighbor Discovery messages include zero or more options, some of 143 which may appear multiple times in the same message. Options should 144 be padded when necessary to ensure that they end on their natural 64- 145 bit boundaries. Figure 1 illustrates a Prefix Information Option 146 [RFC4861] that is extended with flag bits describing the mobility 147 properties of the prefix: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | 3 | 4 | Prefix Length |L|A| Rsvd1 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Valid Lifetime | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Preferred Lifetime | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | C | Reserved2 | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 + + 162 | | 163 + Prefix + 164 | | 165 + + 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: Extended Prefix Information Option 171 'C' 2-bit flag field describing the mobility properties of the 172 prefix. The following properties are defined: 174 00 No specific property associated to the prefix. The prefix is 175 treated according to RFC4861. 177 01 The prefix may or may not provide network based mobility, and 178 if mobility is provided that is only within a limited area. 179 Therefore, the end host must be prepared that the prefix may 180 become invalid abruptly before the valid or even the 181 preferred lifetime expire. 183 10 The prefix provides network based mobility and should remain 184 unchanged the valid lifetime of the prefix. 186 11 Reserved. Treated as '00' by the receiver. 188 A common use case is to define 'C' flags when the 'A'=1 i.e. when 189 Stateless Address AutoConfiguration (SLAAC) is used. However, it is 190 possible to associate 'C' flags also to prefixes when 'A'=0. In 191 cases when there are multiple learned prefixes with 'C' flags set to 192 a non-zero value that can also be aggregated, then the longest prefix 193 takes precedence. 195 If the prefix lifetime(s) is set to infinity that does not override 196 the prefix mobility properties indicated in 'C' flags. For instance, 197 a prefix with an infinite lifetime but 'C' flags set to '01' indicate 198 that the prefix is bound to change abruptly due a handover at some 199 point of time. 201 'C' flags also define the prefix preference for an IP stack that 202 understands the extensions defined in this specification. The IP 203 stack SHOULD use the following preferences to supersede 204 [I-D.ietf-6man-rfc3484bis] Source Address Selection Rule 8 when 205 selecting a default source address among multiple choices and an 206 application has not explicitly indicate what kind of source address 207 it prefers: 209 00 Medium (default) preference. 211 01 High preference. 213 10 Low preference. 215 11 Reserved - MUST NOT be used. 217 4. Host Considerations 219 4.1. Internal Data Structures 221 The host internal data structures need to be extended with 'mobility 222 property' flag information associated to the learned prefix and 223 configured addresses. How this is accomplished is host 224 implementation specific. It is also a host implementation issue how 225 an application can learn or query mobility properties of an address 226 or a prefix. One possibility is to provide such information through 227 the socket API extensions (see discussion in Appendix A). Other 228 possibilities include the use of e.g., ioctl() or NetLink [RFC3549] 229 extensions. 231 4.2. Default Address Selection 233 The 'mobility property' flags are only used as a hint. They do not 234 affect the existing [I-D.ietf-6man-rfc3484bis] automatically. A 235 specific rule to host's policy table has to be inserted by an 236 application or some daemon process. Alternatively, an application 237 can express its address mobility property preferences through the 238 socket API extensions (see discussion in Appendix A), which means the 239 socket library or middleware has to modify [I-D.ietf-6man-rfc3484bis] 240 policy table or algorithm. 242 5. Security Considerations 244 Existing Prefix Information Option related security considerations 245 apply as described in [RFC4861] and [RFC4191]. A malicious node on 246 the shared link could include such 'mobility property' flags in a 247 Prefix Information Option causing the host to learn wrong information 248 regarding the prefix and thus make misguided selection of prefixes on 249 the link. Similarly a malicious middleman on the link could modify 250 'mobility property' flags in a Prefix Information Option causing 251 misguided selection of prefixes. In order to avoid on-link attacks, 252 SeND [RFC3971] can be used to reject Router Advertisements from 253 potentially malicious nodes and guarantee integrity protection of the 254 Router Advertisements. 256 6. IANA Considerations 258 Section 3 defines a new flag bits (2 bit 'C' flag) to the IPv6 259 Neighbor Discovery protocol's Prefix Information Option [RFC4861]. 261 7. References 262 7.1. Normative References 264 [I-D.ietf-6man-rfc3484bis] 265 Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 266 "Default Address Selection for Internet Protocol version 6 267 (IPv6)", draft-ietf-6man-rfc3484bis-01 (work in progress), 268 March 2012. 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 274 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 275 September 2007. 277 7.2. Informative References 279 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 280 Stevens, "Basic Socket Interface Extensions for IPv6", 281 RFC 3493, February 2003. 283 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 284 "Linux Netlink as an IP Services Protocol", RFC 3549, 285 July 2003. 287 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 288 Neighbor Discovery (SEND)", RFC 3971, March 2005. 290 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 291 More-Specific Routes", RFC 4191, November 2005. 293 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 294 Socket API for Source Address Selection", RFC 5014, 295 September 2007. 297 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 298 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 300 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 301 in IPv6", RFC 6275, July 2011. 303 [TS.29274] 304 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 305 Packet Radio Service (GPRS) Tunnelling Protocol for 306 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 307 December 2010. 309 Appendix A. Additions to the Socket Interface and the Protocol- 310 Independent Nodename Translation 312 Following sections are for informational and discussion purposes 313 only. 315 This specification also describes non-normative extensions to both 316 Socket Interface [RFC3493][RFC5014] and the Protocol-Independent 317 Nodename Translation [RFC5014]. These socket APIs and DNS resolver 318 APIs extension correspond to the Prefix Information option mobility 319 properties flag bit settings. 321 A.1. Socket Interface 323 This specification extends the socket option IPV6_ADDR_PREFERENCES at 324 the IPPROTO_IPV6 level. The following new flags are defined to 325 query, alter or set the default rule of source address selection 326 rules [I-D.ietf-6man-rfc3484bis]. They are also defined as a result 327 of including the header: 329 IPV6_PREFER_SRC_HNP /* Prefer Home Network Prefix derived IPv6 330 address as source */ 332 IPV6_PREFER_SRC_HNP_TMP /* Prefer temoporary Home Network Prefix 333 derived IPv6 address as source */ 335 A.2. Protocol-Independent Nodename Translation 337 the Default Address Selection [I-D.ietf-6man-rfc3484bis] document 338 indicates possible implementation strategies for getaddrinfo(). The 339 address selection hint flags for the getaddrinfo() specificed in this 340 document extend the 'int ai_eflags' field in the struct addrinfo 341 [RFC5014][RFC3493]. 343 The IPV6 source address preference values (IPV6_PREFER_SRC_HNP and 344 IPV6_PREFER_SRC_HNP_TMP) defined for the IPV6_ADDR_PREFERENCES socket 345 option are also defined as address selection preference flags in 346 header for the "ai_eflags" extended flag-set field of the 347 addrinfo data structure. 349 Similarly to [RFC5014], if contradictory flags, such as 350 IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_HNP*, are set in ai_eflags, 351 the getaddrinfo() fails and returns the value EAI_BADEXTFLAGS. This 352 error value MUST be interpreted into a descriptive text string when 353 passed to the gai_strerror() function [RFC3493]. 355 Authors' Addresses 357 Jouni Korhonen 358 Nokia Siemens Networks 359 Linnoitustie 6 360 FIN-02600 Espoo 361 Finland 363 Email: jouni.nospam@gmail.com 365 Basavaraj Patil 366 Nokia 367 6021 Connection Drive 368 Irving, TX 75039 369 USA 371 Email: basavaraj.patil@nokia.com 373 Sri Gundavelli 374 Cisco 375 170 West Tasman Drive 376 San Jose, CA 95134 377 USA 379 Email: sgundave@cisco.com