idnits 2.17.1 draft-korhonen-dmm-prefix-properties-05.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 (February 25, 2016) is 2984 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 (-03) exists of draft-ietf-mif-mpvd-ndp-support-02 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-18) exists of draft-ietf-dmm-ondemand-mobility-02 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 Broadcom 4 Updates: 4862 (if approved) S. Gundavelli 5 Intended status: Standards Track Cisco 6 Expires: August 28, 2016 P. Seite 7 Orange 8 D. Liu 9 Alibaba 10 February 25, 2016 12 IPv6 Prefix Properties 13 draft-korhonen-dmm-prefix-properties-05.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 August 28, 2016. 48 Copyright Notice 50 Copyright (c) 2016 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 [I-D.ietf-mif-mpvd-id]. This would allow network 399 operators to place mobility related configuration information 400 (including prefixes) under a specific explicit provisioning domain 401 and non-mobile configuration information into other explicit domain 402 or implicit provisioning domain. 404 MPVDs are the RECOMMENDED way to deliver PIOMD options. This allows 405 mobile network operators selectively advertise mobility related 406 network configurations. MPVDs also provide adequate security 407 features for mobile hosts to verify the authenticity of the 408 configuration information. 410 7. Security Considerations 412 Existing Prefix Information Option related security considerations 413 apply as described in [RFC4861] and [RFC4191]. A malicious node on 414 the shared link could include stale metadata in a PIOMD causing the 415 host to learn wrong information regarding the prefix and thus make 416 misguided selection of prefixes on the link. Similarly a malicious 417 middleman on the link could modify or remove metadata in the PIOMD 418 causing misguided selection of prefixes. In order to avoid on-link 419 attacks, SeND [RFC3971] can be used to reject Router Advertisements 420 from potentially malicious nodes and guarantee integrity protection 421 of the Router Advertisements. 423 If MPVD support for NDP [I-D.ietf-mif-mpvd-ndp-support] is used, then 424 the mobile host can use its security features to verify the 425 authenticity and correctness of the received PIOMD information. 427 8. IANA Considerations 429 Section 3.1 defines a new IPv6 Neighbor Discovery protocol option 430 type TBD1 for the Prefix Information Option with Meta Data. The type 431 value is defined in the existing 'IPv6 Neighbor Discovery Option 432 Formats' IANA registry. 434 Section 3.2 defines a new IANA registry for the Prefix Information 435 Option with Meta Data suboptions. The registry allocation policy is 436 Standards Action [RFC5226]. The initial allocations for the prefix 437 properties and prefix class suboptions are listed in Section 3.2. 439 9. Acknowledgements 441 The authors thank Ole Troan for his feedback and suggestions on this 442 document (the Classed PIO). 444 10. References 446 10.1. Normative References 448 [I-D.ietf-mif-mpvd-id] 449 Krishnan, S., Korhonen, J., Bhandari, S., and S. 450 Gundavelli, "Identification of provisioning domains", 451 draft-ietf-mif-mpvd-id-02 (work in progress), October 452 2015. 454 [I-D.ietf-mif-mpvd-ndp-support] 455 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 456 for multiple provisioning domains in IPv6 Neighbor 457 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-02 458 (work in progress), October 2015. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 466 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 467 DOI 10.17487/RFC4861, September 2007, 468 . 470 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 471 Address Autoconfiguration", RFC 4862, 472 DOI 10.17487/RFC4862, September 2007, 473 . 475 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 476 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 477 DOI 10.17487/RFC5226, May 2008, 478 . 480 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 481 "Default Address Selection for Internet Protocol Version 6 482 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 483 . 485 10.2. Informational References 487 [I-D.bhandari-dhc-class-based-prefix] 488 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 489 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 490 based prefix", draft-bhandari-dhc-class-based-prefix-05 491 (work in progress), July 2013. 493 [I-D.ietf-dmm-ondemand-mobility] 494 Yegin, A., Kweon, K., Lee, J., Park, J., and D. Moses, "On 495 Demand Mobility Management", draft-ietf-dmm-ondemand- 496 mobility-02 (work in progress), February 2016. 498 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 499 Stevens, "Basic Socket Interface Extensions for IPv6", 500 RFC 3493, DOI 10.17487/RFC3493, February 2003, 501 . 503 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 504 "Linux Netlink as an IP Services Protocol", RFC 3549, 505 DOI 10.17487/RFC3549, July 2003, 506 . 508 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 509 "SEcure Neighbor Discovery (SEND)", RFC 3971, 510 DOI 10.17487/RFC3971, March 2005, 511 . 513 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 514 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 515 November 2005, . 517 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 518 Socket API for Source Address Selection", RFC 5014, 519 DOI 10.17487/RFC5014, September 2007, 520 . 522 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 523 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 524 RFC 5213, DOI 10.17487/RFC5213, August 2008, 525 . 527 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 528 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 529 2011, . 531 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 532 Korhonen, "Requirements for Distributed Mobility 533 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 534 . 536 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 537 CJ. Bernardos, "Distributed Mobility Management: Current 538 Practices and Gap Analysis", RFC 7429, 539 DOI 10.17487/RFC7429, January 2015, 540 . 542 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 543 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 544 . 546 [TS.29274] 547 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 548 Packet Radio Service (GPRS) Tunnelling Protocol for 549 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, December 550 2010. 552 Authors' Addresses 554 Jouni Korhonen 555 Broadcom 556 3151 Zanker Rd. 557 CA San Jose 558 USA 560 Email: jouni.nospam@gmail.com 562 Sri Gundavelli 563 Cisco 564 170 West Tasman Drive 565 San Jose, CA 95134 566 USA 568 Email: sgundave@cisco.com 569 Pierrick Seite 570 Orange 571 4, rue du Clos Courtel, BP 91226 572 Cesson-Sevigne 35512 573 France 575 Email: pierrick.seite@orange.com 577 Dapeng Liu 578 Alibaba 580 Email: max.ldp@alibaba-inc.com