idnits 2.17.1 draft-korhonen-6man-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) (Using the creation date from RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2013) is 3942 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-bhandari-dhc-class-based-prefix-04 == Outdated reference: A later version (-02) exists of draft-liu-dmm-mobility-api-01 == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-06 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 Renesas Mobile 4 Updates: 4861, 4862 (if approved) B. Patil 5 Intended status: Standards Track S. Gundavelli 6 Expires: January 11, 2014 Cisco 7 P. Seite 8 Orange 9 D. Liu 10 China Mobile 11 July 10, 2013 13 IPv6 Prefix Properties 14 draft-korhonen-6man-prefix-properties-02.txt 16 Abstract 18 This specification defines an extension to the IPv6 Neighbor 19 Discovery protocol and the stateless address autoconfiguration 20 procedure. A new Prefix Information Option with meta data is defined 21 that describe the properties and other prefix class meta data 22 associated with the prefix. The stateless address autoconfiguration 23 procedure and end hosts can make use of the additional properties and 24 class information when selecting prefixes for a particular uses and 25 use cases. This specification updates RFC4861 and also updates 26 RFC4862. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 11, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Background and Motivation . . . . . . . . . . . . . . . . . . 5 81 3. Option Formats . . . . . . . . . . . . . . . . . . . . . . . . 6 82 3.1. Prefix Information Option with Meta Data . . . . . . . . . 6 83 3.2. Meta Data Suboptions . . . . . . . . . . . . . . . . . . . 7 84 4. Host Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 4.1. Stateless Address Autoconfiguration Enhancements . . . . . 9 86 4.2. Internal Data Structures . . . . . . . . . . . . . . . . . 9 87 4.3. Default Address Selection . . . . . . . . . . . . . . . . 9 88 5. Router Considerations . . . . . . . . . . . . . . . . . . . . 10 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 97 1. Introduction 99 This specification defines a new neighbor discovery protocol message 100 option, the Prefix Information Option with Meta Data (PIOMT), that 101 indicate, for example, the mobility management properties associated 102 to the prefix, and a class value that conveys metadata associated to 103 the prefix with a local administrative domain wide importance. 104 Furthermore, the specification discusses corresponding source address 105 selection hint flags to the IPv6 Socket API for Source Address 106 Selection [RFC5014]. 108 For example, the IPv6 Socket API for Source Address Selection 109 [RFC5014] already covers Mobile IPv6 [RFC6275] and allows selecting 110 between a home address (HoA) and a care-of address (CoA). A mobile 111 node (MN) with a client based mobility IP stack is supposed to know 112 which prefixes are CoA(s) and/or HoA(s). However, this is not the 113 case with network based mobility management where the MN is expected 114 to be agnostic of the mobility support. There has been attempts in 115 past to define similar functionality for the mobility protocols 116 purposes [I-D.damic-6man-pmip6-ind]. Outside the mobility protocols, 117 there are other potential use cases where associating properties to 118 the advertised prefixes could be useful as discussed in 119 [I-D.bhandari-dhc-class-based-prefix]. 121 The extensions to [RFC4861] are minimal in a sense that they do not 122 define new functionality, for example, to any existing mobility 123 protocol but instead add an explicit indication of network based 124 mobility knowledge into the IPv6 stateless address autoconfiguration 125 (SLAAC) [RFC4862]. The new functionality is achieved by defining a 126 new, backward compatible, option to IPv6 router advertisements that 127 convey the required prefix related meta data information the SLAAC 128 procedure may take use of. 130 This would allow for network based mobility solutions, such as Proxy 131 Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that 132 their prefixes have mobility, and therefore, the MN IP stack can make 133 an educated selection between prefixes that have mobility and those 134 that do not. There is also a potential need to extend both [RFC3493] 135 and [RFC5014] in order to provide required hooks into socket APIs. 137 The underlying assumption is that a MN has multiple prefixes to 138 choose from. Typically this means either the MN has multiple 139 interfaces or an interface has been configured with multiple 140 prefixes. This specification does not make a distinction between 141 these alternatives and does not either make any assumptions how the 142 possible transfer of a prefix is done between interfaces in the case 143 a network based mobility solution is used. 145 2. Background and Motivation 147 This section discusses the motivations behind adding metadata and 148 other address selection decision making affecting information into 149 IPv6 prefixes. The additional information is conveyed from the 150 network to a end host during the IPv6 address configuration phase. 151 The motivation example taken from and discussed below is from the 152 mobile networks. 154 IP mobility and its centralized topological anchoring of IP addresses 155 has known issues. For instance, non-optimal routing is a classical 156 example. Another concerns include excessive tunneling, increased 157 signaling due the maintenance of mobility related bindings, 158 aggregation of traffic to centralized mobility anchor gateways and 159 unnecessary IP mobility related state management for IP traffic that 160 does not as such benefit from mobility. In general, it is observed 161 that most applications do not need IP level mobility, and work just 162 fine with "temporary" IP addresses that come and go. However, IP 163 mobility still has its virtues making the applications unaware of 164 mobility, and certain wireless mobile networking architecture make 165 extensive use of network based IP mobility. 167 In order to overcome some of the above issues, use of local resources 168 and topologically local addressing could be enhanced. In many cases 169 this would lead to use of multiple addresses of which some provide 170 mobility and some do not. However, an end host has to have means to 171 distinguish between addresses that provide mobility, and those that 172 are short lived and usable only within a limited topological area. 174 [I-D.seite-dmm-dma] and [I-D.draft-liu-dmm-dynamic-anchor-discussion] 175 discuss the dynamic anchor solution for distributed mobility 176 management. The idea is to use the local allocated prefix for any 177 newly initiated 'IP session' and use the previously allocated prefix 178 for the ongoing sessions. This specification can be used to 179 implement the prefix selection for dynamic anchoring. For example, 180 both the locally allocated and the remotely allocated/anchored 181 prefixes can be identified by the prefix property option as described 182 in Section 3.2. 184 This specification also shares similar motivations for classifying 185 the prefix as described in [I-D.bhandari-dhc-class-based-prefix]. 186 Some service providers may wish to allocate specific prefixes for 187 some services or type of traffic. In this situation, the end host 188 must be able to classify prefixes according to type of service. 190 This specification provides tools for extending the IPv6 address 191 management and source address selection so that end hosts (and their 192 applications) can select a proper address for their needs. This 193 specification complements [I-D.bhandari-dhc-class-based-prefix] by 194 providing the SLAAC version of the additional prefix related meta 195 data information delivery compared to the DHCPv6 stateful approach. 197 3. Option Formats 199 3.1. Prefix Information Option with Meta Data 201 This specification defines a new neighbor discovery protocol message 202 option, the Prefix Information Option with Meta Data (PIOMT), to be 203 used in router advertisement messages. The PIOMT is treated exactly 204 the same as [RFC4861] Prefix Information Option (PIO) except with an 205 addition of new meta data suboptions. 207 The PIOMT can coexist with RFC4861 PIO. The prefixes advertised in 208 both PIOMT and PIO can even be the same. It is up to the receiving 209 end host to select the appropriate prefix(es) for configuring its 210 IPv6 addresses. In a case the PIO and the PIOMT share the same 211 prefix, then all the other parameter (like flags and lifetimes) MUST 212 be the same. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type | Length | Prefix Length |L|A| Reserved1 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Valid Lifetime | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Preferred Lifetime | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Reserved2 | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 + + 227 | | 228 + Prefix + 229 | | 230 + + 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 : Suboptions : 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 1: Prefix Information Option with additional meta data 238 Type 240 Set to TBD1. 242 Length 244 4 if no suboptions are present. Greater than 4 if one or more 245 suboptions are present. 247 Suboptions 249 Zero or more suboptions that describe properties and other meta 250 data attached to the advertised prefix. See Section 3.2 for 251 description of the meta data suboption format and suboptions 252 already defined in this specification. The existence of 253 suboptions can be determined from the length field. If the 254 length is greater than 4, then at least one suboption MUST be 255 present. 257 Rest of the fields are handled exactly as described in Section 4.6.2. 258 of RFC4861 [RFC4861]. 260 3.2. Meta Data Suboptions 262 The generic suboption format for the PIO with meta data (PIOMT) is 263 shown in Figure 2. The suboption follows the alignment and length 264 rules familiar from [RFC4861]. On a particular note, the flag 'C' 265 describes whether the suboption is mandatory to understand by the 266 receiver or not. If 'C' is set to zero (0), the receiver can 267 silently discard an unknown suboption and skip to the next suboption. 268 If 'C' is set to one (1), then an unknown suboption causes the 269 receiver to silently discard the entire PIOMT and no further 270 suboptions need to be parsed. There can be multiple instances of the 271 same suboption type in one PIOMT option. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length |C| Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | ... ~ 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 2: Generic meta data suboption format 283 Figure 3 shows the Prefix Properties suboption. The prefix 284 properties values are defined in Section 6.1. of 285 [I-D.bhandari-dhc-class-based-prefix]. When an end host receives a 286 router advertisement message with a PIOMT and the prefix properties 287 suboption, it can use the suboption information as an additional hint 288 for selecting the prefix for a desired purpose and use case. The 289 prefix properties have global meaning i.e., they have the same 290 treatment and handling cross administrative domains. The value for 291 the 'C' flag SHOULD be one (1). This also implies that if the prefix 292 properties bit vector has a flag bit set, which the receiving end 293 host does not understand and the 'C' flag is also set, then the whole 294 PIOMT option MUST be discarded. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | 0 | 1 |C| Reserved1 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Prefix properties | Reserved2 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 3: Prefix Properties suboption 306 Figure 4 shows the Prefix Class suboption. The prefix class values 307 and usage follow what has been defined in Section 2.3. of 308 [I-D.bhandari-dhc-class-based-prefix]. When an end host receives a 309 router advertisement message with a PIOMT and the prefix class 310 suboption, it can use the suboption information as an additional hint 311 for selecting the prefix for a desired purpose and use case. The 312 prefix class has only local administrative meaning i.e., they are 313 local to the access network and may overlap both semantically and 314 registry wise across different administrative domains. How the 315 boundaries of an administrative domain are determined is outside the 316 scope of this specification. The value for the 'C' flag SHOULD be 317 zero (0). 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | 1 | 1 |C| Reserved1 | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Prefix class | Reserved2 | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 4: Prefix Class suboption 329 Future specifications MAY define new suboptions. One potential 330 example could be a suboption to identify the provisioning domain 331 where the configuration information originates. 333 4. Host Considerations 335 4.1. Stateless Address Autoconfiguration Enhancements 337 This specification extends to the [RFC4862] Stateless Address 338 Autoconfiguration (SLAAC). As described in Section 3.1, a new 339 [RFC4861] PIO like option PIOMT can be used to either complement or 340 entirely replace the PIO in a router advertisement. An end host that 341 understands the PIOMT option MUST always prefer a prefix found in the 342 PIOMT over the same prefix found in the PIO option. 344 4.2. Internal Data Structures 346 The host internal data structures need to be extended with the 347 'prefix property' and the 'prefix class' information associated to 348 the learned prefix and configured addresses. How this is 349 accomplished is host implementation specific. It is also a host 350 implementation issue how an application can learn or query both 351 properties or class of an address or a prefix. One possibility is to 352 provide such information through the socket API extensions (see 353 discussion in [I-D.liu-dmm-mobility-api]). Other possibilities 354 include the use of e.g., ioctl() or NetLink [RFC3549] extensions. 356 4.3. Default Address Selection 358 The 'prefix property' is only used as a hint. It does not affect the 359 existing [RFC6724] automatically. A specific rule to host's policy 360 table has to be inserted by an application or some daemon process. 361 Alternatively, an application can express its address mobility 362 property preferences through the socket API extensions (see 363 discussion in [I-D.liu-dmm-mobility-api]), which means the socket 364 library or middleware has to modify [RFC6724] policy table or 365 algorithm. 367 The 'prefix properties' flags MAY define the prefix preference for an 368 IP stack that understands the extensions defined in this 369 specification. The IP stack SHOULD use the properties preferences to 370 supersede [RFC6724] Source Address Selection Rule 8 when selecting a 371 default source address among multiple choices and an application has 372 not explicitly indicate what kind of source address it prefers. 374 The 'prefix class' defines an application 'class' the advertised 375 prefix is intended to be used for. The class has only local 376 administrative domain significance. The 'prefix class' can be used, 377 for example, to identify prefixes that are meant to be used reach a 378 voice over IP (VoIP) service or a video streaming application within 379 the local administrative network. A specific application in the end 380 host MAY use this additional class information when enumerating 381 through multiple available addresses and then select a specific 382 address to be used for its purposes. 384 5. Router Considerations 386 A network administrator MAY configure routers complying to this 387 specification that also emit router advertisements to include the 388 PIOMT option into every router advertisement that would also contain 389 the [RFC4861] PIO option. Since the PIOMT emitting router has no 390 prior knowledge whether the end hosts on the link support the PIOMT 391 option, it is strongly RECOMMENDED that both [RFC4861] PIO and the 392 PIOMT are always included in the router advertisement, even if the 393 advertised prefixes were the same. Whether a router sends router 394 advertisements containing the PIOMT options is a local administrative 395 decision. 397 A router can also make use of the 'C' flag handling in the PIOMT 398 suboptions when introducing new functionality into the network. 399 Since it is possible to include multiple suboptions of the same type 400 into the PIOMT option, the router can easily make a difference 401 between e.g., prefix properties that must be understood by the 402 receiver and those that can safely be ignored. 404 6. Security Considerations 406 Existing Prefix Information Option related security considerations 407 apply as described in [RFC4861] and [RFC4191]. A malicious node on 408 the shared link could include such 'mobility property' flags in a 409 Prefix Information Option causing the host to learn wrong information 410 regarding the prefix and thus make misguided selection of prefixes on 411 the link. Similarly a malicious middleman on the link could modify 412 'mobility property' flags in a Prefix Information Option causing 413 misguided selection of prefixes. In order to avoid on-link attacks, 414 SeND [RFC3971] can be used to reject Router Advertisements from 415 potentially malicious nodes and guarantee integrity protection of the 416 Router Advertisements. 418 7. IANA Considerations 420 Section 3.1 defines a new IPv6 Neighbor Discovery protocol option 421 type TBD1 for the Prefix Information Option with Meta Data. The type 422 value is defined in the existing 'IPv6 Neighbor Discovery Option 423 Formats' IANA registry. 425 Section 3.2 defines a new IANA registry for the Prefix Information 426 Option with Meta Data suboptions. The registry allocation policy is 427 Standards Action [RFC5226]. The initial allocations for the prefix 428 properties and prefix class suboptions are listed in Section 3.2. 430 8. Acknowledgements 432 The authors thank Ole Troan for his feedback and suggestions on this 433 document (the Classed PIO). 435 9. References 437 9.1. Normative References 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, March 1997. 442 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 443 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 444 September 2007. 446 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 447 Address Autoconfiguration", RFC 4862, September 2007. 449 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 450 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 451 May 2008. 453 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 454 "Default Address Selection for Internet Protocol Version 6 455 (IPv6)", RFC 6724, September 2012. 457 9.2. Informative References 459 [I-D.bhandari-dhc-class-based-prefix] 460 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 461 Thiebaut, L., and J. Korhonen, "DHCPv6 class based 462 prefix", draft-bhandari-dhc-class-based-prefix-04 (work in 463 progress), February 2013. 465 [I-D.damic-6man-pmip6-ind] 466 Damic, D., "Proxy Mobile IPv6 indication and discovery", 467 draft-damic-6man-pmip6-ind-00 (work in progress), 468 March 2009. 470 [I-D.draft-liu-dmm-dynamic-anchor-discussion] 471 Liu, D., "DMM Dynamic Anchor Discussion", 472 draft-liu-dmm-dynamic-anchor-discussion-00 (work in 473 progress), March 2012. 475 [I-D.liu-dmm-mobility-api] 476 Liu, D. and H. Deng, "Mobility API Extension for 477 Distributed Mobility Management", 478 draft-liu-dmm-mobility-api-01 (work in progress), 479 July 2013. 481 [I-D.seite-dmm-dma] 482 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 483 Anchoring", draft-seite-dmm-dma-06 (work in progress), 484 January 2013. 486 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 487 Stevens, "Basic Socket Interface Extensions for IPv6", 488 RFC 3493, February 2003. 490 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 491 "Linux Netlink as an IP Services Protocol", RFC 3549, 492 July 2003. 494 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 495 Neighbor Discovery (SEND)", RFC 3971, March 2005. 497 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 498 More-Specific Routes", RFC 4191, November 2005. 500 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 501 Socket API for Source Address Selection", RFC 5014, 502 September 2007. 504 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 505 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 507 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 508 in IPv6", RFC 6275, July 2011. 510 [TS.29274] 511 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 512 Packet Radio Service (GPRS) Tunnelling Protocol for 513 Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 514 December 2010. 516 Authors' Addresses 518 Jouni Korhonen 519 Renesas Mobile 520 Porkkalankatu 24 521 FIN-00180 Helsinki 522 Finland 524 Email: jouni.nospam@gmail.com 526 Basavaraj Patil 527 Cisco 529 Email: bpatil1@gmail.com 531 Sri Gundavelli 532 Cisco 533 170 West Tasman Drive 534 San Jose, CA 95134 535 USA 537 Email: sgundave@cisco.com 539 Pierrick Seite 540 Orange 541 4, rue du Clos Courtel, BP 91226 542 Cesson-Sevigne 35512 543 France 545 Email: pierrick.seite@orange.com 547 Dapeng Liu 548 China Mobile 549 32 Xuanwumen West Street 550 Beijng, Xicheng District 100053 551 China 553 Email: liudapeng@chinamobile.com