idnits 2.17.00 (12 Aug 2021) /tmp/idnits23320/draft-korhonen-dmm-prefix-properties-04.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 RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- 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 6, 2015) is 2510 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: A later version (-02) exists of draft-ietf-mif-mpvd-id-01 == Outdated reference: A later version (-03) exists of draft-ietf-mif-mpvd-ndp-support-01 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-dmm-ondemand-mobility has been published as RFC 8653 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 Broadcom Corporation 4 Updates: 4862 (if approved) S. Gundavelli 5 Intended status: Standards Track Cisco 6 Expires: January 7, 2016 P. Seite 7 Orange 8 D. Liu 9 Alibaba 10 July 6, 2015 12 IPv6 Prefix Properties 13 draft-korhonen-dmm-prefix-properties-04.txt 15 Abstract 17 This specification defines an extension to the IPv6 stateless address 18 autoconfiguration procedure. New options with meta data are defined 19 that describe the properties and other prefix class meta data 20 associated with the prefix. The stateless address autoconfiguration 21 procedure and end hosts can make use of the additional properties and 22 class information when selecting source address prefixes for a 23 particular uses and use cases. This specification updates RFC4862. 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 7, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Background and Motivation . . . . . . . . . . . . . . . . . . 3 67 3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Prefix Meta Data . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Meta Data Suboptions . . . . . . . . . . . . . . . . . . 6 70 4. Host Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Stateless Address Autoconfiguration Enhancements . . . . 7 72 4.2. Internal Data Structures . . . . . . . . . . . . . . . . 8 73 4.3. Default Address Selection . . . . . . . . . . . . . . . . 8 74 5. Router Considerations . . . . . . . . . . . . . . . . . . . . 8 75 6. Multiple Provisioning Domain Considerations . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 10.2. Informational References . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 This specification defines a new neighbor discovery protocol message 87 option, the Prefix Information Option with Meta Data (PIOMD), that 88 indicate, for example, the mobility management properties associated 89 to the prefix, and a class value that conveys metadata associated to 90 the prefix with a local administrative domain wide importance. The 91 solution may use of Multiple Provisioning Domains (MPVD) framework 92 [RFC7556] [I-D.ietf-mif-mpvd-ndp-support]. Furthermore, the 93 specification discusses corresponding source address selection hint 94 issues with the IPv6 Socket API and applications in general 95 [I-D.ietf-dmm-ondemand-mobility]. 97 For example, the IPv6 Socket API for Source Address Selection 98 [RFC5014] already covers Mobile IPv6 [RFC6275] and allows selecting 99 between a home address (HoA) and a care-of address (CoA). A mobile 100 node (MN) with a client based mobility IP stack is supposed to know 101 which prefixes are CoA(s) and/or HoA(s). However, this is not the 102 case with network based mobility management where the MN is expected 103 to be agnostic of the mobility support. 105 The extensions are minimal in a sense that they do not define new 106 functionality, for example, to any existing mobility protocol but 107 instead add an explicit indication of network based mobility 108 knowledge into the IPv6 stateless address autoconfiguration (SLAAC) 109 [RFC4862]. The heavy lifting is mostly on the applications side and 110 on the IP stack providing interface for applications, since they need 111 to make use of the new functionality. The new functionality is 112 achieved by defining a new, backward compatible, IPv6 neighbor 113 discovery protocol options that convey the required prefix related 114 meta data information the SLAAC procedure may take use of. 116 This would allow for network based mobility solutions, such as Proxy 117 Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that 118 their prefixes have mobility, and therefore, the MN IP stack or 119 specifically applications can make an educated selection between 120 prefixes that have mobility and those that do not. There is also a 121 potential need to extend both [RFC3493] and [RFC5014] in order to 122 provide required hooks into socket APIs. 124 The underlying assumption is that a MN has multiple prefixes to 125 choose from. Typically this means either the MN has multiple 126 interfaces or an interface has been configured with multiple 127 prefixes. This specification does not make a distinction between 128 these alternatives and does not either make any assumptions how the 129 possible transfer of a prefix is done between interfaces in the case 130 a network based mobility solution is used. 132 2. Background and Motivation 134 This section discusses the motivations behind adding metadata and 135 other address selection decision making affecting information into 136 IPv6 prefixes. The additional information is conveyed from the 137 network to a end host during the IPv6 address configuration phase. 138 The motivation example taken from and discussed below is from the 139 mobile networks. 141 IP mobility and its centralized topological anchoring of IP addresses 142 has known issues. For instance, non-optimal routing is a classical 143 example. Another concerns include excessive tunneling, increased 144 signaling due the maintenance of mobility related bindings, 145 aggregation of traffic to centralized mobility anchor gateways and 146 unnecessary IP mobility related state management for IP traffic that 147 does not as such benefit from mobility. In general, it is observed 148 that most applications do not need IP level mobility, and work just 149 fine with "temporary" IP addresses that come and go. However, IP 150 mobility still has its virtues making the applications unaware of 151 mobility, and certain wireless mobile networking architecture make 152 extensive use of network based IP mobility. 154 In order to overcome some of the above issues, use of local resources 155 and topologically local addressing could be enhanced. In many cases 156 this would lead to use of multiple addresses of which some provide 157 mobility and some do not. However, an end host has to have means to 158 distinguish between addresses that provide mobility, and those that 159 are short lived and usable only within a limited topological area. 161 [RFC7333] discussed the requirements for distributed mobility 162 management and [RFC7429] describes the gaps from current best 163 practices and the desired approaches for de-centralized mobility 164 management. One approach is using the dynamic anchoring for 165 distributed de-centralized mobility management. The idea is to use 166 the local allocated prefix for any newly initiated 'IP session' and 167 use the previously allocated prefix for the ongoing sessions. This 168 specification can be used to implement the prefix selection for 169 dynamic anchoring. For example, both the locally allocated and the 170 remotely allocated/anchored prefixes can be identified by the prefix 171 property option as described in Section 3.2. 173 The solution described in this document also shares similar 174 motivations for classifying the prefix as described in 175 [I-D.bhandari-dhc-class-based-prefix]. Some service providers may 176 wish to allocate specific prefixes for some services or type of 177 traffic. In this situation, the end host must be able to classify 178 prefixes according to type of service. 180 This specification provides tools for extending the IPv6 address 181 management and source address selection so that end hosts (and their 182 applications) can select a proper address for their needs. This 183 specification complements [I-D.bhandari-dhc-class-based-prefix] by 184 providing the SLAAC version of the additional prefix related meta 185 data information delivery compared to the DHCPv6 stateful approach. 187 3. Option Formats 188 3.1. Prefix Meta Data 190 This specification defines a new neighbor discovery protocol message 191 option, the Prefix Information Option with Meta Data (PIOMD), to be 192 used in router advertisement messages. The PIOMD is treated as the 193 same as [RFC4861] Prefix Information Option (PIO) except with an 194 addition of new meta data suboptions. 196 The PIOMD can coexist with RFC4861 PIO. The prefixes advertised in 197 both PIOMD and PIO can even be the same. It is up to the receiving 198 end host to select the appropriate prefix(es) for configuring its 199 IPv6 addresses. In a case the PIO and the PIOMD share the same 200 prefix, then all the other parameter (like flags and lifetimes) MUST 201 be the same. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | Prefix Length |L|A| Reserved1 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Valid Lifetime | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Preferred Lifetime | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Reserved2 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 + + 216 | | 217 + Prefix + 218 | | 219 + + 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 : Suboptions : 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: Prefix Information Option with additional meta data 227 Type 229 Set to TBD1. 231 Length 233 4 if no suboptions are present. Greater than 4 if one or more 234 suboptions are present. 236 Suboptions 238 Zero or more suboptions that describe properties and other meta 239 data attached to the advertised prefix. See Section 3.2 for 240 description of the meta data suboption format and suboptions 241 already defined in this specification. The existence of 242 suboptions can be determined from the length field. If the 243 length is greater than 4, then at least one suboption MUST be 244 present. 246 Rest of the fields are handled exactly as described in Section 4.6.2. 247 of RFC4861 [RFC4861]. 249 3.2. Meta Data Suboptions 251 The generic suboption format for the PIO with meta data (PIOMD) is 252 shown in Figure 2. The suboption follows the alignment and length 253 rules familiar from [RFC4861]. On a particular note, the flag 'C' 254 describes whether the suboption is mandatory to understand by the 255 receiver or not. If 'C' is set to zero (0), the receiver can 256 silently discard an unknown suboption and skip to the next suboption. 257 If 'C' is set to one (1), then an unknown suboption causes the 258 receiver to silently discard the entire PIOMT and no further 259 suboptions need to be parsed. There can be multiple instances of the 260 same suboption type in one PIOMD option. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Length |C| Reserved | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | ... ~ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 2: Generic meta data suboption format 272 Figure 3 shows the Prefix Properties suboption. The prefix 273 properties values are defined in Section 6.1. of 274 [I-D.bhandari-dhc-class-based-prefix]. When an end host receives a 275 router advertisement message with a PIOMD and the prefix properties 276 suboption, it can use the suboption information as an additional hint 277 for selecting the prefix for a desired purpose and use case. The 278 prefix properties have global meaning i.e., they have the same 279 treatment and handling cross administrative domains. The value for 280 the 'C' flag SHOULD be one (1). This also implies that if the prefix 281 properties bit vector has a flag bit set, which the receiving end 282 host does not understand and the 'C' flag is also set, then the whole 283 PIOMD option MUST be discarded. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | 0 | 1 |C| Reserved1 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Prefix properties | Reserved2 | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 3: Prefix Properties suboption 295 Figure 4 shows the Prefix Class suboption. The prefix class values 296 and usage follow what has been defined in Section 2.3. of 297 [I-D.bhandari-dhc-class-based-prefix]. When an end host receives a 298 router advertisement message with a PIOMD and the prefix class 299 suboption, it can use the suboption information as an additional hint 300 for selecting the prefix for a desired purpose and use case. The 301 prefix class has only local administrative meaning i.e., they are 302 local to the access network and may overlap both semantically and 303 registry wise across different administrative domains. How the 304 boundaries of an administrative domain are determined is outside the 305 scope of this specification. The value for the 'C' flag SHOULD be 306 zero (0). 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | 1 | 1 |C| Reserved1 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Prefix class | Reserved2 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 4: Prefix Class suboption 318 Future specifications MAY define new suboptions. One potential 319 example could be a suboption to identify the provisioning domain 320 where the configuration information originates. 322 4. Host Considerations 324 4.1. Stateless Address Autoconfiguration Enhancements 326 This specification extends to the [RFC4862] Stateless Address 327 Autoconfiguration (SLAAC). As described in Section 3.1, a new 328 [RFC4861] PIO like option PIOMD can be used to either complement or 329 entirely replace the PIO in a router advertisement. An end host that 330 understands the PIOMD option MUST always prefer a prefix found in the 331 PIOMD over the same prefix found in the PIO option. 333 4.2. Internal Data Structures 335 The host internal data structures need to be extended with the 336 'prefix property' and the 'prefix class' information associated to 337 the learned prefix and configured addresses. How this is 338 accomplished is host implementation specific. It is also a host 339 implementation issue how an application can learn or query both 340 properties or class of an address or a prefix. One possibility is to 341 provide such information through the socket API extensions (see 342 discussion in [I-D.ietf-dmm-ondemand-mobility]). Other possibilities 343 include the use of e.g., ioctl() or NetLink [RFC3549] extensions. 345 4.3. Default Address Selection 347 The 'prefix property' is only used as a hint. It does not affect the 348 existing [RFC6724] automatically. A specific rule to host's policy 349 table has to be inserted by an application or some daemon process. 350 Alternatively, an application can express its address mobility 351 property preferences through the socket API extensions (see 352 discussion in [I-D.ietf-dmm-ondemand-mobility]), which means the 353 socket library or middleware has to modify [RFC6724] policy table or 354 algorithm. 356 The 'prefix properties' flags MAY define the prefix preference for an 357 IP stack that understands the extensions defined in this 358 specification. The IP stack SHOULD use the properties preferences to 359 supersede [RFC6724] Source Address Selection Rule 8 when selecting a 360 default source address among multiple choices and an application has 361 not explicitly indicate what kind of source address it prefers. 363 The 'prefix class' defines an application 'class' the advertised 364 prefix is intended to be used for. The class has only local 365 administrative domain significance. The 'prefix class' can be used, 366 for example, to identify prefixes that are meant to be used reach a 367 voice over IP (VoIP) service or a video streaming application within 368 the local administrative network. A specific application in the end 369 host MAY use this additional class information when enumerating 370 through multiple available addresses and then select a specific 371 address to be used for its purposes. 373 5. Router Considerations 375 A network administrator MAY configure routers complying to this 376 specification also send router advertisements with the PIOMD option 377 into every router advertisement that also contains the [RFC4861] PIO 378 option. Since the PIOMD sending router has no prior knowledge 379 whether the end hosts on the link support the PIOMD option, it is 380 strongly RECOMMENDED that both [RFC4861] PIO and the PIOMD are always 381 included in the router advertisement, even if the advertised prefixes 382 were the same. Alternatively (or in addition) multiple provisioning 383 domains [I-D.ietf-mif-mpvd-ndp-support] can be used to separate 384 prefixes advertised using PIOMD options. See Section 6 for further 385 details. 387 A router can also make use of the 'C' flag handling in the PIOMD 388 suboptions when introducing new functionality into the network. 389 Since it is possible to include multiple suboptions of the same type 390 into the PIOMD option, the router can easily make a difference 391 between e.g., prefix properties that must be understood by the 392 receiver and those that can safely be ignored. 394 6. Multiple Provisioning Domain Considerations 396 Multiple Provisioning Domains (MPVD) framework [RFC7556] allows 397 grouping network configuration information under an explicitly named 398 provisioning domain (which can be, for example, a Network Access 399 Identifier (NAI) of the mobility service provider 400 [I-D.ietf-mif-mpvd-id]). This would allow network operators to place 401 mobility related configuration information (including prefixes) under 402 specific explicit provisioning domains and non-mobile configuration 403 information into other explicit domain or implicit provisioning 404 domains. 406 MPVDs are the RECOMMENDED way to deliver PIOMD options. This allows 407 mobile hosts to query for mobility related configuration information 408 and network operators selectively advertise mobility related network 409 configurations. MPVDs also provide adequate security features for 410 mobile hosts to verify the authenticity of the configuration 411 information. However, MPVD does not 413 7. Security Considerations 415 Existing Prefix Information Option related security considerations 416 apply as described in [RFC4861] and [RFC4191]. A malicious node on 417 the shared link could include stale metadata in a PIOMD causing the 418 host to learn wrong information regarding the prefix and thus make 419 misguided selection of prefixes on the link. Similarly a malicious 420 middleman on the link could modify or remove metadata in the PIOMD 421 causing misguided selection of prefixes. In order to avoid on-link 422 attacks, SeND [RFC3971] can be used to reject Router Advertisements 423 from potentially malicious nodes and guarantee integrity protection 424 of the Router Advertisements. 426 If MPVD support for NDP [I-D.ietf-mif-mpvd-ndp-support] is used, then 427 the mobile host can use its security features to verify the 428 authenticity and correctness of the received PIOMD information. 430 8. IANA Considerations 432 Section 3.1 defines a new IPv6 Neighbor Discovery protocol option 433 type TBD1 for the Prefix Information Option with Meta Data. The type 434 value is defined in the existing 'IPv6 Neighbor Discovery Option 435 Formats' IANA registry. 437 Section 3.2 defines a new IANA registry for the Prefix Information 438 Option with Meta Data suboptions. The registry allocation policy is 439 Standards Action [RFC5226]. The initial allocations for the prefix 440 properties and prefix class suboptions are listed in Section 3.2. 442 9. Acknowledgements 444 The authors thank Ole Troan for his feedback and suggestions on this 445 document (the Classed PIO). 447 10. References 449 10.1. Normative References 451 [I-D.ietf-mif-mpvd-id] 452 Krishnan, S., Korhonen, J., Bhandari, S., and S. 453 Gundavelli, "Identification of provisioning domains", 454 draft-ietf-mif-mpvd-id-01 (work in progress), February 455 2015. 457 [I-D.ietf-mif-mpvd-ndp-support] 458 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 459 for multiple provisioning domains in IPv6 Neighbor 460 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-01 461 (work in progress), February 2015. 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 467 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 468 September 2007. 470 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 471 Address Autoconfiguration", RFC 4862, September 2007. 473 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 474 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 475 May 2008. 477 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 478 "Default Address Selection for Internet Protocol Version 6 479 (IPv6)", RFC 6724, September 2012. 481 10.2. Informational References 483 [I-D.bhandari-dhc-class-based-prefix] 484 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 485 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 486 based prefix", draft-bhandari-dhc-class-based-prefix-05 487 (work in progress), July 2013. 489 [I-D.ietf-dmm-ondemand-mobility] 490 Yegin, A., Kweon, K., Lee, J., Park, J., and D. Moses, "On 491 Demand Mobility Management", draft-ietf-dmm-ondemand- 492 mobility-00 (work in progress), May 2015. 494 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 495 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 496 3493, February 2003. 498 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 499 "Linux Netlink as an IP Services Protocol", RFC 3549, July 500 2003. 502 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 503 Neighbor Discovery (SEND)", RFC 3971, March 2005. 505 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 506 More-Specific Routes", RFC 4191, November 2005. 508 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 509 Socket API for Source Address Selection", RFC 5014, 510 September 2007. 512 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 513 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 515 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 516 in IPv6", RFC 6275, July 2011. 518 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 519 "Requirements for Distributed Mobility Management", RFC 520 7333, August 2014. 522 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 523 Bernardos, "Distributed Mobility Management: Current 524 Practices and Gap Analysis", RFC 7429, January 2015. 526 [RFC7556] Anipko, D., "Multiple Provisioning Domain Architecture", 527 RFC 7556, June 2015. 529 [TS.29274] 530 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 531 Packet Radio Service (GPRS) Tunnelling Protocol for 532 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, December 533 2010. 535 Authors' Addresses 537 Jouni Korhonen 538 Broadcom Corporation 539 3151 Zanker Rd. 540 CA San Jose 541 USA 543 Email: jouni.nospam@gmail.com 545 Sri Gundavelli 546 Cisco 547 170 West Tasman Drive 548 San Jose, CA 95134 549 USA 551 Email: sgundave@cisco.com 553 Pierrick Seite 554 Orange 555 4, rue du Clos Courtel, BP 91226 556 Cesson-Sevigne 35512 557 France 559 Email: pierrick.seite@orange.com 561 Dapeng Liu 562 Alibaba 564 Email: max.ldp@alibaba-inc.com