idnits 2.17.00 (12 Aug 2021) /tmp/idnits21561/draft-korhonen-dmm-prefix-properties-00.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 (February 23, 2012) is 3739 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) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 (if approved) B. Patil 5 Intended status: Standards Track Nokia 6 Expires: August 26, 2012 S. Gundavelli 7 Cisco 8 February 23, 2012 10 IPv6 Prefix Mobility Management Properties 11 draft-korhonen-dmm-prefix-properties-00.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. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 26, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Background and Motivation . . . . . . . . . . . . . . . . . . . 3 63 3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Host Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Internal Data Structures . . . . . . . . . . . . . . . . . 5 66 4.2. Default Address Selection . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 72 Appendix A. Additions to the Socket Interface and the 73 Protocol-Independent Nodename Translation . . . . . . 6 74 A.1. Socket Interface . . . . . . . . . . . . . . . . . . . . . 7 75 A.2. Protocol-Independent Nodename Translation . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 This specification defines an extension to the IPv6 Neighbor 81 Discovery protocol and its Prefix Information Option (PIO) [RFC4861]. 82 The Prefix Information Option is extended with flag bits that 83 describe the mobility management properties associated to the prefix, 84 and at the same time defines corresponding source address selection 85 hint flags to the IPv6 Socket API for Source Address Selection 86 [RFC5014]. 88 The IPv6 Socket API for Source Address Selection [RFC5014] already 89 covers Mobile IPv6 [RFC6275] and allows selecting between a home 90 address (HoA) and a care-of address (CoA). A mobile node (MN) with a 91 client based mobility IP stack is supposed to know which prefixes are 92 CoA(s) and/or HoA(s). The extensions to [RFC4861] are minimal in a 93 sense that they do not define new functionality to any existing 94 mobility protocol but instead add an explicit indication of network 95 based mobility knowledge into the IPv6 stateless address 96 autoconfiguration (SLAAC). This would allow for network based 97 mobility solutions, such as Proxy Mobile IPv6 [RFC5213] or GTP 98 [TS.29274] to explicitly indicate that their prefixes have mobility, 99 and therefore, the MN IP stack can make an educated selection between 100 prefixes that have mobility and those that do not. There is also a 101 potential need to extend both [RFC3493] and [RFC5014] in order to 102 provide required hooks into socket APIs. 104 The underlying assumption is that a MN has multiple prefixes to 105 choose from. Typically this means either the MN has multiple 106 interfaces or an interface has been configured with multiple 107 prefixes. This specification does not make a distinction between 108 these alternatives and does not either make any assumptions how the 109 possible transfer of a prefix is done between interfaces in the case 110 a network based mobility solution is used. 112 2. Background and Motivation 114 [Discussion: explain the background and subsequently the motivation, 115 which lead to "coloring" prefixes, and what we expect to gain from 116 this extension to IPv6 addressing & neighbor discovery protocol. To 117 be written later.] 119 3. Option Formats 121 Neighbor Discovery messages include zero or more options, some of 122 which may appear multiple times in the same message. Options should 123 be padded when necessary to ensure that they end on their natural 64- 124 bit boundaries. Figure 1 illustrates a Prefix Information Option 125 [RFC4861] that is extended with flag bits describing the mobility 126 properties of the prefix: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | 3 | 4 | Prefix Length |L|A| C | Rsvd1 | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Valid Lifetime | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Preferred Lifetime | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Reserved2 | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | | 140 + + 141 | | 142 + Prefix + 143 | | 144 + + 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1: Extended Prefix Information Option 150 'C' 2-bit flag field describing the mobility properties of the 151 prefix. The following properties are defined: 153 00 No specific property associated to the prefix. The prefix is 154 treated according to RFC4861. 156 01 The prefix provides network based mobility and will remain 157 unchanged at the valid lifetime of the prefix. 159 10 The prefix provides network based mobility but only within a 160 limited area, thus the end host must be prepared that the 161 prefix may become invalid before the valid or even the 162 preferred lifetime expire. 164 11 Reserved. Treated as '00' by the receiver. 166 A common use case is to define 'C' flags when the 'A'=1 i.e. when 167 Stateless Address AutoConfiguration (SLAAC) is used. However, it is 168 possible to associate 'C' flags also to prefixes when 'A'=0. In 169 cases when there are multiple learned prefixes with 'C' flags set to 170 a non-zero value that can also be aggregated, then the longest prefix 171 takes precedence. 173 4. Host Considerations 175 4.1. Internal Data Structures 177 The host internal data structures need to be extended with 'mobility 178 property' flag information associated to the learned prefix and 179 configured addresses. How this is accomplished is host 180 implementation specific. It is also a host implementation issue how 181 an application can learn or query mobility properties of an address 182 or a prefix. One possibility is to provide such information through 183 the socket API extensions (see discussion in Appendix A). Other 184 possibilities include the use of e.g., ioctl() or NetLink [RFC3549] 185 extensions. 187 4.2. Default Address Selection 189 The 'mobility property' flags are only used as a hint. They do not 190 affect the existing [RFC3484] automatically. A specific rule to 191 host's policy table has to be inserted by an application or some 192 daemon process. Alternatively, an application can express its 193 address mobility property preferences through the socket API 194 extensions (see discussion in Appendix A), which means the socket 195 library or middleware has to modify [RFC3484] policy table or 196 algorithm. 198 5. Security Considerations 200 Existing Prefix Information Option related security considerations 201 apply as described in [RFC4861] and [RFC4191]. A malicious node on 202 the shared link could include such 'mobility property' flags in a 203 Prefix Information Option causing the host to learn wrong information 204 regarding the prefix and thus make misguided selection of prefixes on 205 the link. Similarly a malicious middleman on the link could modify 206 'mobility property' flags in a Prefix Information Option causing 207 misguided selection of prefixes. In order to avoid on-link attacks, 208 SeND [RFC3971] can be used to reject Router Advertisements from 209 potentially malicious nodes and guarantee integrity protection of the 210 Router Advertisements. 212 6. IANA Considerations 214 Section 3 defines a new flag bits (2 bit 'C' flag) to the IPv6 215 Neighbor Discovery protocol's Prefix Information Option [RFC4861]. 217 7. References 218 7.1. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC3484] Draves, R., "Default Address Selection for Internet 224 Protocol version 6 (IPv6)", RFC 3484, February 2003. 226 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 227 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 228 September 2007. 230 7.2. Informative References 232 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 233 Stevens, "Basic Socket Interface Extensions for IPv6", 234 RFC 3493, February 2003. 236 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 237 "Linux Netlink as an IP Services Protocol", RFC 3549, 238 July 2003. 240 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 241 Neighbor Discovery (SEND)", RFC 3971, March 2005. 243 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 244 More-Specific Routes", RFC 4191, November 2005. 246 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 247 Socket API for Source Address Selection", RFC 5014, 248 September 2007. 250 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 251 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 253 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 254 in IPv6", RFC 6275, July 2011. 256 [TS.29274] 257 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 258 Packet Radio Service (GPRS) Tunnelling Protocol for 259 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 260 December 2010. 262 Appendix A. Additions to the Socket Interface and the Protocol- 263 Independent Nodename Translation 265 Following sections are for informational and discussion purposes 266 only. 268 This specification also describes non-normative extensions to both 269 Socket Interface [RFC3493][RFC5014] and the Protocol-Independent 270 Nodename Translation [RFC5014]. These socket APIs and DNS resolver 271 APIs extension correspond to the Prefix Information option mobility 272 properties flag bit settings. 274 A.1. Socket Interface 276 This specification extends the socket option IPV6_ADDR_PREFERENCES at 277 the IPPROTO_IPV6 level. The following new flags are defined to 278 query, alter or set the default rule of source address selection 279 rules [RFC3484]. They are also defined as a result of including the 280 header: 282 IPV6_PREFER_SRC_HNP /* Prefer Home Network Prefix derived IPv6 283 address as source */ 285 IPV6_PREFER_SRC_HNP_TMP /* Prefer temoporary Home Network Prefix 286 derived IPv6 address as source */ 288 A.2. Protocol-Independent Nodename Translation 290 the Default Address Selection [RFC3484] document indicates possible 291 implementation strategies for getaddrinfo(). The address selection 292 hint flags for the getaddrinfo() specificed in this document extend 293 the 'int ai_eflags' field in the struct addrinfo [RFC5014][RFC3493]. 295 The IPV6 source address preference values (IPV6_PREFER_SRC_HNP and 296 IPV6_PREFER_SRC_HNP_TMP) defined for the IPV6_ADDR_PREFERENCES socket 297 option are also defined as address selection preference flags in 298 header for the "ai_eflags" extended flag-set field of the 299 addrinfo data structure. 301 Similarly to [RFC5014], if contradictory flags, such as 302 IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_HNP*, are set in ai_eflags, 303 the getaddrinfo() fails and returns the value EAI_BADEXTFLAGS. This 304 error value MUST be interpreted into a descriptive text string when 305 passed to the gai_strerror() function [RFC3493]. 307 Authors' Addresses 309 Jouni Korhonen 310 Nokia Siemens Networks 311 Linnoitustie 6 312 FIN-02600 Espoo 313 Finland 315 Email: jouni.nospam@gmail.com 317 Basavaraj Patil 318 Nokia 319 6021 Connection Drive 320 Irving, TX 75039 321 USA 323 Email: basavaraj.patil@nokia.com 325 Sri Gundavelli 326 Cisco 327 170 West Tasman Drive 328 San Jose, CA 95134 329 USA 331 Email: sgundave@cisco.com