idnits 2.17.1 draft-melia-netext-logical-interface-support-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 5, 2010) is 5043 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5844' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC5164' is defined on line 627, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG T. Melia, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational S. Gundavelli, Ed. 5 Expires: January 6, 2011 Cisco 6 H. Yokota 7 KDDI Lab 8 C. Bernardos 9 Universidad Carlos III de Madrid 10 July 5, 2010 12 Logical Interface Support for multi-mode IP Hosts 13 draft-melia-netext-logical-interface-support-01.txt 15 Abstract 17 A Logical Interface is a software semantic internal to the host 18 operating system. This semantic is available in all popular 19 operating systems and is used in various protocol implementations. 20 The Logical Interface support is desirable on the mobile node 21 operating in a Proxy Mobile IPv6 domain, for leveraging various 22 network-based mobility management features such as inter-technology 23 handoffs, multihoming and flow mobility support. This document 24 explains the operational details of Logical Interface construct and 25 the specifics on how the link-layer implementations hide the physical 26 interfaces from the IP stack and from the network nodes. 27 Furthermore, this document identifies the applicability of this 28 approach to various link-layer technologies and analyses the issues 29 around it when used in context with various mobility management 30 features. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 6, 2011. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 70 3. Hiding link layer technologies - Approaches and 71 Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. Link-layer Abstraction - Approaches . . . . . . . . . . . 6 73 3.2. Applicability Statement . . . . . . . . . . . . . . . . . 8 74 3.2.1. Link layer support . . . . . . . . . . . . . . . . . . 8 75 3.2.2. Logical Interface . . . . . . . . . . . . . . . . . . 8 76 3.2.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . 9 78 4. Logical Interface Operation . . . . . . . . . . . . . . . . . 10 80 5. Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 12 81 5.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 12 82 5.2. Inter-Technology Handoff Support . . . . . . . . . . . . . 13 83 5.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 15 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 Proxy Mobile IPv6 [RFC5213] is a network-based mobility protocol. 102 Some of the key goals of the protocol include support for 103 multihoming, inter-technology handoffs and flow mobility support. 104 The PMIPv6 extensions chartered in the NETEXT WG) allow the mobile 105 node to attach to the network using multiple interfaces 106 (simultaneously or sequentally), or to perform handoff between 107 different interfaces of the mobile node. However, for supporting 108 these features, the mobile node is required to be activated with 109 specific software configuration that allows the mobile node to either 110 perform inter-technology handoffs between different interfaces, 111 attach to the network using multiple interfaces (sequentially or 112 simultaneously), or perform flow movement from one access technology 113 to another. This document analyses from the mobile node's 114 perspective a specific approach that allows the mobile node to 115 leverage these mobility features. Specifically, it explores the use 116 of the Logical Interface support, a semantic available on most 117 operating systems. 119 A Logical Interface is a construct internal to the operating system. 120 It is an approach where the link-layer implementations hide the 121 physical interfaces from the IP stack and from the network nodes. 122 This semantic is widely available in all popular operating systems. 123 Many applications such as Mobile IP client [RFC3775], IPsec VPN 124 client [RFC4301] and L2TP client [RFC3931] all rely on this semantic 125 for their protocol implementation and the same semantic can also be 126 useful in this context. Specifically, the mobile node [RFC5213] can 127 use the logical interface configuration for leveraging various 128 network-based mobility management features provided by the Proxy 129 Mobile IPv6 domain. The rest of the document provides the 130 operational details of the Logical Interface on the mobile node and 131 the inter-working between a mobile node using logical interface and 132 network elements in the Proxy Mobile IPv6 domain. It also analyzes 133 the issues involved with this approach and characterizes the contexts 134 in which such use is appropriate. 136 2. Requirements Language 138 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 139 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 140 described in [RFC2119]. 142 3. Hiding link layer technologies - Approaches and Applicability 144 There are several techniques/mechanisms that allow hiding access 145 technology changes or movement from host IP layer. This section 146 classifies these existing techniques into a set of generic 147 approaches, according to their most representative characteristics. 148 We then refer to these generic mechanisms later in the document, when 149 analyzing their applicability to inter-access technology and flow 150 mobility purposes in PMIPv6. 152 3.1. Link-layer Abstraction - Approaches 154 The following generic mechanisms can hide access technology changes 155 from host IP layer: 157 o Link layer support: certain link layer technologies are able to 158 hide physical media changes from the upper layers (see Figure 1). 159 For example, IEEE 802.11 is able to seamlessly change between IEEE 160 802.11a/b/g physical layers. Also, an 802.11 STA can move between 161 different Access Points (APs) within the same domain without the 162 IP stack being aware of the movement. In this case, the IEEE 163 802.11 MAC layer takes care of the mobility, making the media 164 change invisible to the upper layers. Another example is IEEE 165 802.3, that supports changing the rate from 10Mbps to 100Mbps and 166 to 1000Mbps. 167 Mobile Node 168 +-----------------------+ 169 | TCP/UDP | AR1 AR2 170 +-----------------------+ +-----+ +-----+ 171 | IP | | IP | | IP | 172 +-----------------------+ +-----+ +-----+ 173 | Link Layer (L2) | | L2 | | L2 | 174 +-----+-----+-----+-----+ +-----+ +-----+ 175 | L1a | L1b | L1c | L1d |<---------->| L1d | | L1b | 176 +-----+-----+-----+-----+ +-----+ +-----+ 177 ^ ^ 178 |_________________________________________| 180 Link layer support solution architecture 182 There are also other examples with more complicated architectures, 183 like for instance, 3GPP Rel-8. In this case, a UE can move 184 (inter-RA handover) between GERAN/UTRAN/E-UTRAN, being this 185 movement invisible to the IP layer at the UE, and also to the LMA 186 logical component at the PGW. The link layer stack at the UE 187 (i.e. PDCP and RLC layers), and the GTP between the RAN and the 188 SGW (which plays the role of inter-3GPP AN mobility anchor) hide 189 this kind of mobility, which is not visible to the IP layer of the 190 UE (see Figure 2). 191 --------- 192 | Appl. |<-----------------------------------------------------> 193 --------- ---------- 194 | |<+ - - - - - - - - - - - - - - - - - - - - +>| | 195 | IP | . ----------------- . ------------------- . | IP | 196 | |<+>| relay |<+>| relay | . | | 197 --------- . ----------------- . ------------------- . ---------- 198 | PDCP |<+>| PDCP | GTP-U |<+>| GTP-U | GTP-U |<+>| GTP-U | 199 --------- . ----------------- . ------------------- . ---------- 200 | RLC |<+>| RLC | UDP/IP |<+>| UDP/IP | UDP/IP |<+>| UDP/IP | 201 --------- . ----------------- . ------------------- . ---------- 202 | MAC |<+>| MAC | L2 |<+>| L2 | L2 |<+>| L2 | 203 --------- . ----------------- . ------------------- . ---------- 204 | L1 |<+>| L1 | L1 |<+>| L1 | L1 |<+>| L1 | 205 --------- . ----------------- . ------------------- . ---------- 206 UE Uu E-UTRAN S1-U SGW S5/S8a PGW 208 3GPP Rel-8 data plane architecture (GTP option) 210 o Logical interface: this refers to solutions (see Figure 3) that 211 logically group/bond several physical interfaces so they appear to 212 the upper layers (i.e. IP) as one single interface (where 213 application sockets bind). Depending on the OS support, it might 214 be possible to use more than one physical interface at a time -- 215 so the node is simultaneously attached to different media -- or 216 just to provide a fail-over mode. Controlling the way the 217 different media is used (simultaneous, sequential attachment, etc) 218 is not trivial and requires additional intelligence and/or 219 configuration at the logical interface device driver. An example 220 of this type of solution is the Logical interface [I-D.yokota- 221 netlmm-pmipv6-mn-itho-support] or the bonding driver. 222 +----------------------------+ 223 | TCP/UDP | 224 Session to IP +->| | 225 address binding | +----------------------------+ 226 +->| IP | 227 IP to logical +->| | 228 interface binding | +----------------------------+ 229 +->| Logical interface | 230 logical to physical +->| (MN-HoA) | 231 interface binding | +----------------------------+ 232 +->| L2 | L2 | | L2 | 233 |(IF#1)|(IF#2)| ..... |(IF#n)| 234 +------+------+ +------+ 235 | L1 | L1 | | L1 | 236 | | | | | 237 +------+------+ +------+ 239 Logical IP Interface 241 3.2. Applicability Statement 243 We now focus on the applicability of the above solutions against the 244 following requirements: 246 o multi technology support 248 o sequential vs. simultaneous access 250 o no impact to the IP layer (e.g. Neighbor Discovery, path MTU) 252 3.2.1. Link layer support 254 Link layer mobility support applies to cases when the same link layer 255 technology is used and mobility can be fully handled at these layers. 256 One example is the case where several 802.11 APs are deployed in the 257 same subnet and all of them share higher layer resources such as DHCP 258 server, IP gateway, etc. In this case the APs can autonomously (or 259 with the help of a central box) communicate and control the STA 260 association changes from one AP to another, without the STA being 261 aware of the movement. This type of scenario is applicable to cases 262 when the different points of attachment (i.e. APs) belong to the 263 same network domain, e.g. enterprise, hotspots from same operator, 264 etc. 266 This type of solution does not typically allow for simultaneous 267 attachment to different access networks, and therefore can only be 268 considered for inter-access technology handovers, but not for flow 269 mobility. Existing RFC 5213 handover hint mechanisms could benefit 270 from link layer information (e.g. triggers) to detect and identify MN 271 handovers. 273 Link layer support is not applicable when two different access 274 technologies are involved (e.g. 802.11 WLAN and 802.16 WiMAX) and the 275 same is true when the same access technology expands over multiple 276 network domains. This solution does not impose any change at the IP 277 layer since changes in the access technology occur at layer two. 279 3.2.2. Logical Interface 281 The use of a logical interface allows the mobile node to provide a 282 single interface view to the layers above IP (thus not changing the 283 IP layer itself). Upper layers can bind to this interface, which 284 hides inner inter-access technology handovers or data flow transfers 285 among different physical interfaces. 287 This type of solution may support simultaneous attachment, in 288 addition to sequential attachment. It requires additional support at 289 the node and the network in order to benefit from simultaneous 290 attachment. For example special mechanisms are required to enable 291 addressing a particular interface from the network (e.g. for flow 292 mobility). In particular extensions to PMIPv6 are required in order 293 to enable the network (i.e., the MAG and LMA) to deal with physical 294 interfaces, instead to IP interfaces as current RFC5213 does. 295 RFC5213 assumes that each physical interface capable of attaching to 296 a MAG is an IP interface, while the logical interface solution groups 297 several physical interfaces under the same IP logical interface. 299 Neighbor discovery in conjunction with the logical interface concept 300 has been widely studied for IPv4. Link awareness and gratuitous ARP 301 messages ensure neighbor reachability in case of media change. The 302 same apply to IPv6 where Router Solicitation/Router Advertisement can 303 be sent/received to efficiently manage neighbor cache population. 305 3.2.3. Conclusion 307 From the above it is clear that the logical interface is the best 308 most appropriate solution. It allows heterogeneous attachement while 309 leaving the change in the meadi transparent to the IP stack. 310 Simultaneous and sequential network attachment procedures are 311 possible enabling inter-technology and flow mobility scenarios. 312 Thorugh link awareness the logical interface can keep consistent 313 neighbor caches and move flows across access networks transparently 314 to the upper layers. 316 4. Logical Interface Operation 318 On most operating systems, a network interface is associated with a 319 physical device that provides the capability for transmitting and 320 receiving network packets. In some cases a network interface can 321 also be implemented as a logical interface which does not feature any 322 packet transmission or receive capabilities, but relies on other 323 network interfaces for such capabilities. This logical interface can 324 be realized by means of a Logical interface. 326 +----------------------------+ 327 | TCP/UDP | 328 Session to IP +---->| | 329 Address binding | +----------------------------+ 330 +---->| IP | 331 IP Address +---->| | 332 binding | +----------------------------+ 333 +---->| Logical Interface | 334 Logical to +---->| | 335 Physical | +----------------------------+ 336 Interface +---->| L2 | L2 | | L2 | 337 binding |(IF#1)|(IF#2)| ..... |(IF#n)| 338 +------+------+ +------+ 339 | L1 | L1 | | L1 | 340 | | | | | 341 +------+------+ +------+ 343 Figure 1: Logical Interface Implementation 345 From the perspective of the IP stack and the applications, a Logical 346 interface is just another interface. A host does not see any 347 difference between a Logical and a physical interface. All 348 interfaces are represented as software objects to which IP address 349 configuration is bound. However, the Logical interface has some 350 special properties which are essential for enabling intert-technology 351 handover and flow-mobility features. Following are those properties: 353 o Logical interface is a logical interface that appears to the host 354 stack as any other interface. IP address configuration can be 355 bound to this interface by configuring one or more IPv4 and/or 356 IPv6 addresses to this interface. 358 o Logical interface has a relation to a set of physical interfaces 359 on the host. These physical interfaces in the context of Logical 360 interface are known as sub-interfaces. These sub-interfaces 361 provide transmit and receive functions for sending and receiving 362 packets over physical links. A Logical interface can receive 363 packets sent to any of its sub-interfaces. In other words the MN 364 ccepts packets on any physical interface as long as the IP address 365 is valid (downlink). 367 o The link-layer identifier of the Logical interface is used in the 368 link-layer header of the IP packets sent through this interface, 369 and the link-layer address of the physical interface will not be 370 used. 372 o The send/receive vectors of a Logical interface are managed 373 dynamically and are tied to the sub-interfaces. The mapping 374 between this Logical interface and the sub-interfaces can change 375 dynamically and this change will not be visible to the 376 applications. The side effect of this is the ability for the 377 application bound to the address configuration on the Logical 378 interface, to survive across inter-technology handoffs. 379 Applications will survive across the mapping change between a 380 Logical interface and its sub interfaces. 382 o An IP link as seen by the applications that the Logical interface 383 is being part of through specific sub interface(s), when changed 384 to be as part of through a different set of sub interface(s), will 385 not trigger session loss, address loss, as long as the prefix is 386 valid, and the host continues to exchange Neighbor Discovery 387 meesages [RFC4861] from the IP routers to the Logical interface 388 over the sub-interface(s). 390 o The host has the path awareness of an IPv4/IPv6 link through a 391 sub-interface and standard routing table(s) lookup (via the 392 logical interface) uses the sub-interfaces for packet forwarding. 393 Addresses from Prefix P1, P2 tied to the Logical interface, may 394 have two different link paths, Prefix P1 over E0, Prefix P2 over 395 E1, and this mapping may be reversed, without applications being 396 aware of, and with the needed path changes on the network side. 398 o The Logical interface MUST transmit uplink packets on the same 399 physical interface on which the downlink packet was received for 400 the particular prefix/flow. This will guarantee that packets 401 belonging to the same session (e.g. TCP connection) are routed 402 along the same path (downlink and uplink). In other words a flow 403 mobility decision taken at the LMA will be understood at the MN as 404 an implicit decision when packets belonging to the same flow will 405 arrive at a new interface. 407 5. Logical Interface Use-cases in Proxy Mobile IPv6 409 This section explains how the Logical interface support on the mobile 410 node can be used for enabling some of the Proxy Mobile IPv6 protocol 411 features. 413 5.1. Multihoming Support 415 A mobile node in the Proxy Mobile IPv6 domain can potentially attach 416 to the Proxy Mobile IPv6 domain, simultaneously through multiple 417 interfaces. Each of the attachment links are assigned a unique set 418 of IPv6 prefixes. If the host is configured to use Logical interface 419 over the physical interface through which it is attached, following 420 are the related considerations. 422 LMA's Binding Table 423 +================================+ 424 +----+ | HNP MN-ID CoA ATT LL-ID | 425 |LMA | +================================+ 426 +----+ | HNP-1 MN-1 PCoA-1 5 ZZZ | 427 //\\ | HNP-2 MN-1 PCoA-2 4 ZZZ | 428 +---------//--\\-----------+ 429 ( // \\ ) 430 ( // \\ ) 431 +------//--------\\--------+ 432 // \\ 433 PCoA-1 // \\ PCoA-2 434 +----+ +----+ 435 (WLAN) |MAG1| |MAG2| (WiMAX) 436 +----+ +----+ 437 \ / 438 \ / 439 HNP-1 \ / HNP-2 440 \ / 441 \ / 442 +-------+ +-------+ 443 | if_1 | | if_2 | 444 |(WLAN) | |(WiMAX)| 445 +-------+-+-------+ 446 | Logical | 447 (LL-ID: ZZZ) | Interface | HNP-1::zzz/128 448 +-----------------| HNP-2::zzz/128 449 | MN | 450 +-----------------+ 452 Figure 2: Multihoming Support 454 o The mobile node detects the advertised prefixes from the MAG1 and 455 MAG2 as the onlink prefixes on the link to which the Logical 456 interface is attached. 458 o The mobile node can generate address configuration using stateless 459 auto configuration mode from any of those prefixes. 461 o The applications can be bound to any of the addresses bound to the 462 Logical interface and that is determined based on the source 463 address selection rules. 465 o The host has path awareness for the hosted prefixes based on the 466 received Router Advertisement messages. Any packets with source 467 address generated using HNP_1 will be routed through the interface 468 if_1 and for packets using source address from HNP_2 will be 469 routed through the interface if_2. 471 5.2. Inter-Technology Handoff Support 473 The Proxy Mobile IPv6 protocol enables a mobile node with multiple 474 network interfaces to move between access technologies, but still 475 retaining the same address configuration on its attached interface. 476 The protocol enables a mobile node to achieve address continuity 477 during handoffs. If the host is configured to use Logical interface 478 over the physical interface through which it is attached, following 479 are the related considerations. 481 LMA's Binding Table 482 +================================+ 483 +----+ | HNP MN-ID CoA ATT LL-ID | 484 |LMA | +================================+ 485 +----+ | HNP-1 MN-1 PCoA-1 5 ZZZ | 486 //\\ (pCoA-2)(4) <-change 487 +---------//--\\-----------+ 488 ( // \\ ) 489 ( // \\ ) 490 +------//--------\\--------+ 491 // \\ 492 PCoA-1 // \\ PCoA-2 493 +----+ +----+ 494 (WLAN) |MAG1| |MAG2| (WiMAX) 495 +----+ +----+ 496 \ / 497 \ Handoff / 498 \ ----> / HNP-1 499 \ / 500 \ / 501 +-------+ +-------+ 502 | if_1 | | if_2 | 503 |(WLAN) | |(WiMAX)| 504 +-------+-+-------+ 505 | Logical | 506 (LL-ID: ZZZ) | Interface | HNP-1::zzz/128 507 +-----------------| 508 | MN | 509 +-----------------+ 511 Figure 3: Inter-Technology Handoff Support 513 o When the mobile node performs an handoff between if_1 and if_2, 514 the change will not be visible to the applications of the mobile 515 node. It will continue to receive Router Advertisements from the 516 network, but from a different sub-interface path. 518 o The protocol signaling between the network elements will ensure 519 the local mobility anchor will switch the forwarding for the 520 advertised prefix set from MAG1 to MAG2. 522 o The MAG2 will host the prefix on the attached link and will 523 include the home network prefixes in the Router Advertisements 524 that it sends on the link. 526 5.3. Flow Mobility Support 528 For supporting flow mobility support, there is a need to support 529 vertical handoff scenarios such as transferring a subset of 530 prefix(es) (hence the flows associated to it/them) from one interface 531 to another. The mobile node can support this scenario by using the 532 Logical interface support. This scenario is similar to the Inter- 533 technology handoff scenario defined in Section Section 5.2, only a 534 subset of the prefixes are moved between interfaces. 536 Additionally, IP flow mobility in general initiates when the LMA 537 decides to move a particular flow from its default path to a 538 different one. The LMA can decide on which is the best MAG that 539 should be used to forward a particular flow when the flow is 540 initiated e.g. based on application policy profiles) and/or during 541 the lifetime of the flow upon receiving a network-based or a mobile- 542 based trigger. 544 As an example of mobile-based triggers, the LMA could receive input 545 (e.g.by means of a layer 2.5 function via L3 signalling [RFC5677]) 546 from the MN detecting changes in the mobile wireless environment 547 (e.g. weak radio signal, new network detected, etc.). Upon receiving 548 these triggers, the LMA can initiate the flow mobility procedures. 549 For instance, when the mobile node only supports single-radio 550 operation (i.e. one radio transmitting at a time), only sequential 551 (i.e. not simultaneous) attachment to different MAGs over different 552 media is possible. In this case layer 2.5 signalling can be used to 553 perform the inter-access technology handover and communicate to the 554 LMA the desired target access technology, MN-ID, Flow-ID and prefix. 556 6. IANA Considerations 558 This specification does not require any IANA Actions. 560 7. Security Considerations 562 This specification explains the operational details of Logical 563 interface on an IP host. The Logical Interface implementation on the 564 host is not visible to the network and does not require any special 565 security considerations. 567 8. Contributors 569 This document reflects contributions from the following authors. We 570 sincerely acknowledge their contributions. 572 Tran Minh Trung 574 trungtm2909@gmail.com 576 Yong-Geun Hong 578 yonggeun.hong@gmail.com 580 Kent Leung 582 kleung@cisco.com 584 Antonio de la Oliva 586 aoliva@it.uc3m.es 588 Juan Carlos Zuniga 590 JuanCarlos.Zuniga@InterDigital.com 592 9. Acknowledgements 594 The authors would like to acknowledge prior discussions on this topic 595 in NETLMM and NETEXT working groups. The authors would also like to 596 thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj Patil, 597 Julien Laganier for all the discussions on this topic. 599 10. References 601 10.1. Normative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 607 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 608 September 2007. 610 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 611 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 613 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 614 Mobile IPv6", RFC 5844, May 2010. 616 10.2. Informative References 618 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 619 in IPv6", RFC 3775, June 2004. 621 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 622 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 624 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 625 Internet Protocol", RFC 4301, December 2005. 627 [RFC5164] Melia, T., "Mobility Services Transport: Problem 628 Statement", RFC 5164, March 2008. 630 [RFC5677] Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, 631 "IEEE 802.21 Mobility Services Framework Design (MSFD)", 632 RFC 5677, December 2009. 634 Authors' Addresses 636 Telemaco Melia (editor) 637 Alcatel-Lucent 638 Route de Villejust 639 Nozay, Ile de France 91620 640 FR 642 Email: telemaco.melia@alcatel-lucent.com 644 Sri Gundavelli (editor) 645 Cisco 646 170 West Tasman Drive 647 San Jose, CA 95134 648 USA 650 Email: sgundave@cisco.com 651 Hidetoshi Yokota 652 KDDI Lab 653 2-1-15 Ohara 654 Fujimino, Saitama 356-8502 655 Japan 657 Phone: 658 Fax: 659 Email: yokota@kddilabs.jp 660 URI: 662 Carlos J. Bernardos 663 Universidad Carlos III de Madrid 664 Av. Universidad, 30 665 Leganes, Madrid, 28911 666 Spain 668 Phone: +34 91624 6236 669 Fax: 670 Email: cjbc@it.uc3m.es 671 URI: http://www.it.uc3m.es/cjbc/