idnits 2.17.1 draft-ietf-netext-logical-interface-support-10.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 date (September 3, 2014) is 3520 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4861' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC5677' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC6085' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC6418' is defined on line 625, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: March 7, 2015 Cisco 6 September 3, 2014 8 Logical Interface Support for multi-mode IP Hosts 9 draft-ietf-netext-logical-interface-support-10 11 Abstract 13 A Logical Interface is a software semantic internal to the host 14 operating system. This semantic is available in all popular 15 operating systems and is used in various protocol implementations. 16 The Logical Interface support is required on the mobile node 17 operating in a Proxy Mobile IPv6 domain, for leveraging various 18 network-based mobility management features such as inter-technology 19 handoffs, multihoming and flow mobility support. This document 20 explains the operational details of Logical Interface construct and 21 the specifics on how the link-layer implementations hide the physical 22 interfaces from the IP stack and from the network nodes on the 23 attached access networks. Furthermore, this document identifies the 24 applicability of this approach to various link-layer technologies and 25 analyzes the issues around it when used in context with various 26 mobility management features. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 7, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Hiding Link-layer Technologies - Approaches and 67 Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Link-layer Abstraction - Approaches . . . . . . . . . . . 5 69 3.2. Applicability Statement . . . . . . . . . . . . . . . . . 6 70 3.2.1. Link layer support . . . . . . . . . . . . . . . . . . 6 71 3.2.2. Logical Interface . . . . . . . . . . . . . . . . . . 6 73 4. Technology Use cases . . . . . . . . . . . . . . . . . . . . . 8 75 5. Logical Interface Functional Details . . . . . . . . . . . . . 9 76 5.1. Configuration of a Logical Interface . . . . . . . . . . . 10 77 5.2. Logical Interface Forwarding Conceptual Data Structures . 10 79 6. Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 12 80 6.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 12 81 6.2. Inter-Technology Handoff Support . . . . . . . . . . . . . 13 82 6.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 14 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 Proxy Mobile IPv6 [RFC5213] is a network-based mobility protocol. 101 Some of the key goals of the protocol include support for 102 multihoming, inter-technology handoffs and flow mobility support. 103 The base protocol features specified in [RFC5213] and [RFC5844] allow 104 the mobile node to attach to the network using multiple interfaces 105 (simultaneously or sequentially), or to perform handoff between 106 different interfaces of the mobile node. However, for supporting 107 these features, the mobile node is required to be activated with 108 specific software configuration that allows the mobile node to either 109 perform inter-technology handoffs between different interfaces, 110 attach to the network using multiple interfaces, or perform flow 111 movement from one access technology to another. This document 112 analyzes from the mobile node's perspective a specific approach that 113 allows the mobile node to leverage these mobility features. 114 Specifically, it explores the use of the Logical Interface support, a 115 semantic available on most operating systems. 117 A Logical Interface is a construct internal to the operating system. 118 It is an approach where a logical link-layer implementation hides a 119 variety of physical interfaces from the IP stack. This semantic has 120 been used on a variety of operating systems to implement applications 121 such as Mobile IP clients [RFC6275] and IPsec VPN clients [RFC4301]. 123 In the context of an access infrastructure providing network network- 124 based mobility management services across a variety of access 125 technologies, as provided by a Proxy Mobile IPv6 domain [RFC5213], a 126 logical interface can be used to afford inter-technology handover, 127 multihoming, and/or flow mobility without requiring from the mobile 128 node IP stack specific support to that effect. 130 The rest of the document provides a functional description of a 131 Logical Interface on the mobile node and the interworking between a 132 mobile node using logical interface and network elements in the Proxy 133 Mobile IPv6 domain when supporting the aforementioned mobility 134 management features. It also analyzes the issues involved with this 135 approach and characterizes the contexts in which such usage is 136 appropriate. 138 2. Terminology 140 All the mobility related terms used in this document are to be 141 interpreted as defined in Proxy Mobile IPv6 specifications, [RFC5213] 142 and [RFC5844]. In addition, this document introduces the following 143 terms: 145 PIF (Physical Interface) - a network interface card attached to an 146 an host providing network connectivity (e.g. an Ethernet card, a 147 WLAN card, an LTE interface). 149 LIF (Logical Interface) - It is a virtual interface in the IP stack. 150 It appears just as any other physical interface, provides similar 151 semantics with respect to packet transmit and receive functions to 152 the upper layers in the IP stack. However, it is only logical 153 construct and is not a representation of an instance of any 154 physical hardware. 156 Sub-If (Sub Interface) - a physical interface that is part of a 157 logical interface construct. For example, a logical interface may 158 have been created abstracting two physical interfaces, LTE and 159 WLAN. These physical interfaces, LTE and WLAN are referred to as 160 sub-interfaces of that logical interface. In some cases, a sub- 161 interface can also be another logical interface, such as an IPsec 162 tunnel interface. 164 3. Hiding Link-layer Technologies - Approaches and Applicability 166 There are several techniques/mechanisms that allow hiding access 167 technology changes or movement from host IP layer. This section 168 classifies these existing techniques into a set of generic 169 approaches, according to their most representative characteristics. 170 Later sections of this document analyze the applicability of these 171 solution approaches for supporting features such as, inter-technology 172 handovers and IP flow mobility support for a mobile node in a Proxy 173 Mobile IPv6 domain [RFC5213]. 175 3.1. Link-layer Abstraction - Approaches 177 The following generic mechanisms can hide access technology changes 178 from host IP layer: 180 o Link-layer Support - Certain link-layer technologies are able to 181 hide physical media changes from the upper layers. For example, 182 IEEE 802.11 is able to seamlessly change between IEEE 802.11a/b/g 183 physical layers. Also, an 802.11 STA can move between different 184 Access Points within the same domain without the IP stack being 185 aware of the movement. In this case, the IEEE 802.11 MAC layer 186 takes care of the mobility, making the media change invisible to 187 the upper layers. Another example is IEEE 802.3, that supports 188 changing the rate from 10Mbps to 100Mbps and to 1000Mbps. Another 189 example is the situation in the 3GPP Evolved Packet 190 System[TS23401] where a UE can perform inter-access handovers 191 between three different access technologies (2G GERAN, 3G UTRAN, 192 and 4G E-UTRAN) that are invisible to the IP layer at the UE. 194 o A logical interface denotes a mechanism that that logically group/ 195 bond several physical interfaces so they appear to the IP layer as 196 a single interface (see Figure 1). Depending on the type of 197 access technologies, it might be possible to use more than one 198 physical interface at a time -- such that the node is 199 simultaneously attached via different access technologies -- or 200 just to perform handovers across a variety of physical interfaces. 201 Controlling the way the different access technologies are used 202 (simultaneous, sequential attachment, etc) is not trivial and 203 requires additional intelligence and/or configuration within the 204 logical interface implementation. The configuration is typically 205 handled via a connection manager, and based on a combination of 206 user preferences on one hand, and operator preferences such as 207 those provisionned by the Access Network Discovery and Selection 208 Function (ANDSF) [TS23402] on the other hand. 210 3.2. Applicability Statement 212 We now focus on the applicability of the above solutions against the 213 following requirements: 215 o multi technology support 217 o sequential vs. simultaneous access 219 3.2.1. Link layer support 221 Link layer mobility support applies to cases when the same link layer 222 technology is used and mobility can be fully handled at that layer. 223 One example is the case where several 802.11 access points are 224 deployed in the same subnet with a common IP layer configuration 225 (DHCP server, default router, etc.). In this case the handover 226 across access points need not to be hidden to the IP layer since the 227 IP layer configuration remains the same after a handover. This type 228 of scenario is applicable to cases when the different points of 229 attachment (i.e. access points) belong to the same network domain, 230 e.g. Enterprise, hotspots from same operator, etc. 232 Since this type of link layer technology does not typically allow for 233 simultaneous attachment to different access networks of the same 234 technology, the logical interface would not be used to provide 235 simultaneous access for purposes of multihoming or flow mobility. 236 Instead, the logical interface can be used to provide inter-access 237 technology handover between this type of link layer technology and 238 another link layer technology, e.g., between IEEE 802.11 and IEEE 239 802.16. 241 3.2.2. Logical Interface 243 The use of a logical interface allows the mobile node to provide a 244 single interface perspective to the IP layer and its upper layers 245 (transport and application). Doing so allows to hide inter-access 246 technology handovers or application flow handovers across different 247 physical interfaces. 249 The logical interface may support simultaneous attachment, in 250 addition to sequential attachment. It requires additional support at 251 the node and the network in order to benefit from simultaneous 252 attachment. For example special mechanisms are required to enable 253 addressing a particular interface from the network (e.g. for flow 254 mobility). In particular extensions to PMIPv6 are required in order 255 to enable the network (i.e., the MAG and LMA) to deal with logical 256 interface, instead to IP interfaces as current RFC5213 does. RFC5213 257 assumes that each physical interface capable of attaching to a MAG is 258 an IP interface, while the logical interface solution groups several 259 physical interfaces under the same IP logical interface. 261 It is therefore clear that the Logical Interface approach satisfies 262 the multi technology and the sequential vs: simultaneous access 263 support. 265 4. Technology Use cases 267 3GPP has defined the Evolved Packet System (EPS) for heterogeneous 268 wireless access. A mobile device equipped with 3GPP and non-3GPP 269 wireless technologies can simultaneously or sequentially connect any 270 of the available devices and receive IP services through any of them. 271 This document focuses on employing a logical interface for 272 simultaneous and sequential use of a variety of access technologies. 274 As mentioned in the previous sections the Logical Interface construct 275 is able to hide to the IP layer the specifics of each technology in 276 the context of network based mobility (e.g. in multi-access 277 technology networks based on PMIPv6). The LIF concept can be used 278 with at least the following technologies: 3GPP access technologies 279 (3G, LTE), IEEE 802.16 access technology, and IEEE 802.11 access 280 technology. 282 In some UE implementations the wireless connection setup is based on 283 creation of a PPP interface between the IP layer and the wireless 284 modem that is configured with the IPCP and IPv6CP protocol [RFC5072]. 285 In this case the PPP interface does not have any L2 address assigned. 286 In some other implementations the wireless modem is presented to the 287 IP layer as a virtual Ethernet interface. 289 5. Logical Interface Functional Details 291 This section identifies the functional details of a logical interface 292 and provides some implementation considerations. 294 On most operating systems, a network interface is associated with a 295 physical device that offers the services for transmitting and 296 receiving IP packets from the network. In some configurations, a 297 network interface can also be implemented as a logical interface 298 which does not have the inherent capability to transmit, or receive 299 packets on a physical medium, but relies on other physical interfaces 300 for such services. Example of such configuration is an IP tunnel 301 interface. 303 An overview of a logical interface is shown in Figure 1. The logical 304 interface allows heterogeneous attachment while making changes in the 305 underlying media transparent to the IP stack. Simultaneous and 306 sequential network attachment procedures are therefore possible, 307 enabling inter-technology and flow mobility scenarios. 309 +----------------------------+ 310 | TCP/UDP | 311 Session to IP +---->| | 312 Address binding | +----------------------------+ 313 +---->| IP | 314 IP Address +---->| | 315 binding | +----------------------------+ 316 +---->| Logical Interface | 317 Logical to +---->| IPv4/IPv6 Address | 318 Physical | +----------------------------+ 319 Interface +---->| L2 | L2 | | L2 | 320 binding |(IF#1)|(IF#2)| ..... |(IF#n)| 321 +------+------+ +------+ 322 | L1 | L1 | | L1 | 323 | | | | | 324 +------+------+ +------+ 326 Figure 1: General overview of logical interface 328 From the perspective of the IP stack and the applications, a Logical 329 interface is just another interface. In fact, the logical interface 330 is only visible to the IP and upper layers when enabled. A host does 331 not see any operational difference between a Logical and a physical 332 interface. As with physical interfaces, a Logical interface is 333 represented as a software object to which IP address configuration is 334 bound. However, the Logical interface has some special properties 335 which are essential for enabling inter-technology handover and flow- 336 mobility features. Following are those properties: 338 1. The logical interface has a relation to a set of physical 339 interfaces (sub-interfaces) on the host that it is abstracting. 340 These sub-interfaces can be attached or detached from the Logical 341 Interface at any time. The sub-interfaces attached to a Logical 342 interface are not visible to the IP and upper layers. 344 2. The logical interface may be attached to multiple access 345 technologies. 347 3. The Transmit/Receive functions of the logical interface are 348 mapped to the Transmit/Receive services exposed by the sub- 349 interfaces. This mapping is dynamic and any change is not 350 visible to the upper layers of the IP stack. 352 4. The logical interface maintains IP flow information for each of 353 its sub-interfaces. A conceptual data structure is maintained 354 for this purpose. The host may populate this information based 355 on tracking each of the sub-interface for the active flows. 357 5.1. Configuration of a Logical Interface 359 A host may be statically configured with the logical interface 360 configuration, or an application such as a connection manager on the 361 host may dynamically create it. Furthermore, the set of sub- 362 interfaces that are part of a logical interface construct may be a 363 fixed set, or may be kept dynamic, with the sub-interfaces getting 364 added or deleted as needed. The specific details related to these 365 configuration aspects are implementation specific and are outside the 366 scope of this document. 368 The IP layer should be configured with a default router reachable via 369 the logical interface. The default router can be internal to the 370 logical interface, i.e., it is a logical router that in turns decide 371 which physical interface is to be used to transmit packets. 373 5.2. Logical Interface Forwarding Conceptual Data Structures 375 The logical interface maintains the list of sub-interfaces that are 376 part of the logical interface. This conceptual data strucure is 377 called as the LIF Table. The logical interface also maintains the 378 list of flows associated with a given sub-interface and this 379 conceptual data structure is called as the PIF Table. Both of these 380 data structures have to be associated with a logical interface, and 381 are depicted in Figure 2 382 LIF TABLE FLOW table 383 +===============================+ +=============================+ 384 | PIF_ID | FLOW RoutingPolicies | | FLOW ID | Physical_Intf_Id | 385 | | Link Status | +-----------------------------+ 386 +-------------------------------| | FLOW_ID | Physical_Intf_Id | 387 | PIF_ID | FLOW RoutingPolicies | +=============================+ 388 | | Link Status | + .... | .... | 389 +-------------------------------+ +=============================+ 390 | .... | .... | 391 +===============================+ 393 Figure 2 395 The LIF table maintains the mapping between the LIF and each PIF 396 associated to the LIF (refer to property #3, Figure 1). For each PIF 397 entry the table should store the associated Routing Policies, and the 398 Link Status of the PIF (e.g. active, not active). The method by 399 which the Routing Policies are configured on the host is out of scope 400 for this document. 402 The FLOW table allows the logical interface to properly route each IP 403 flow over the right interface. The logical interface can identify 404 the flows arriving on its sub-interfaces and associate them to those 405 sub-interfaces. This approach is similar to reflective QoS performed 406 by the IP routers. For locally generated traffic (e.g. unicast 407 flows), the logical interface should perform interface selection 408 based on the Flow Routing Policies. In case traffic of an existing 409 flow is suddenly received from the network on a different sub- 410 interface than the one locally stored, the logical interface should 411 interpret the event as an explicit flow mobility trigger from the 412 network and it should update the PIF_ID parameter in the FLOW table. 413 Similarly, locally generated events from the sub-interfaces, or 414 configuration updates to the local policy rules can cause updates to 415 the table and hence trigger flow mobility. 417 6. Logical Interface Use-cases in Proxy Mobile IPv6 419 This section explains how the Logical interface support on the mobile 420 node can be used for enabling some of the Proxy Mobile IPv6 protocol 421 features. 423 6.1. Multihoming Support 425 A mobile node with multiple interfaces can attach simultaneously to 426 the Proxy Mobile IPv6 domain. If the host is configured to use 427 Logical interface over the physical interfaces through which it is 428 attached, following are the related considerations. 430 LMA Binding Table 431 +========================+ 432 +----+ | HNP MN-ID CoA ATT | 433 |LMA | +========================+ 434 +----+ | HNP-1 MN-1 PCoA-1 5 | 435 //\\ | HNP-1 MN-1 PCoA-2 4 | 436 +---------//--\\-----------+ 437 ( // \\ ) 438 ( // \\ ) 439 +------//--------\\--------+ 440 // \\ 441 PCoA-1 // \\ PCoA-2 442 +----+ +----+ 443 (WLAN) |MAG1| |MAG2| (3GPP) 444 +----+ +----+ 445 \ / 446 \ / 447 \ / 448 \ / 449 \ / 450 +-------+ +-------+ 451 | if_1 | | if_2 | 452 |(WLAN) | |(3GPP) | 453 +-------+-+-------+ 454 | Logical | 455 | Interface | 456 | (HNP-1) | 457 +-----------------| 458 | MN | 459 +-----------------+ 461 Figure 3: Multihoming Support 463 6.2. Inter-Technology Handoff Support 465 The Proxy Mobile IPv6 protocol enables a mobile node with multiple 466 network interfaces to move between access technologies, but still 467 retaining the same address configuration on its attached interface. 468 The protocol enables a mobile node to achieve address continuity 469 during handoffs. If the host is configured to use Logical interface 470 over the physical interface through which it is attached, following 471 are the related considerations. 473 LMA's Binding Table 474 +==========================+ 475 +----+ | HNP MN-ID CoA ATT | 476 |LMA | +==========================+ 477 +----+ | HNP-1 MN-1 PCoA-1 5 | 478 //\\ (pCoA-2)(4) <--change 479 +---------//--\\-----------+ 480 ( // \\ ) 481 ( // \\ ) 482 +------//--------\\--------+ 483 // \\ 484 PCoA-1 // \\ PCoA-2 485 +----+ +----+ 486 (WLAN) |MAG1| |MAG2| (3GPP) 487 +----+ +----+ 488 \ / 489 \ Handoff / 490 \ / 491 \ / 492 +-------+ +-------+ 493 | if_1 | | if_2 | 494 |(WLAN) | |(3GPP) | 495 +-------+-+-------+ 496 | Logical | 497 | Interface | 498 | (HNP-1) | 499 +-----------------| 500 | MN | 501 +-----------------+ 503 Figure 4: Inter-Technology Handoff Support 505 o When the mobile node performs an handoff between if_1 and if_2, 506 the change will not be visible to the applications of the mobile 507 node. 509 o The protocol signaling between the network elements will ensure 510 the local mobility anchor will switch the forwarding for the 511 advertised prefix set from MAG1 to MAG2. 513 6.3. Flow Mobility Support 515 For supporting flow mobility support, there is a need to support 516 vertical handoff scenarios such as transferring a subset of 517 prefix(es) (hence the flows associated to it/them) from one interface 518 to another. The mobile node can support this scenario by using the 519 Logical interface support. This scenario is similar to the Inter- 520 technology handoff scenario defined in Section 6.2, only a subset of 521 the prefixes are moved between interfaces. 523 Additionally, IP flow mobility in general initiates when the LMA 524 decides to move a particular flow from its default path to a 525 different one. The LMA can decide on which is the best MAG that 526 should be used to forward a particular flow when the flow is 527 initiated e.g. based on application policy profiles) and/or during 528 the lifetime of the flow upon receiving a network-based or a mobile- 529 based trigger. 531 7. IANA Considerations 533 This specification does not require any IANA Actions. 535 8. Security Considerations 537 This specification explains the operational details of Logical 538 interface on an IP host. The Logical Interface implementation on the 539 host is not visible to the network and does not require any special 540 security considerations. 542 9. Authors 544 This document reflects contributions from the following authors 545 (listed in alphabetical order): 547 Carlos Jesus Bernardos Cano 549 cjbc@it.uc3m.es 551 Antonio De la Oliva 553 aoliva@it.uc3m.es 555 Yong-Geun Hong 557 yonggeun.hong@gmail.com 559 Kent Leung 561 kleung@cisco.com 563 Tran Minh Trung 565 trungtm2909@gmail.com 567 Hidetoshi Yokota 569 yokota@kddilabs.jp 571 Juan Carlos Zuniga 573 JuanCarlos.Zuniga@InterDigital.com 575 Julien Laganier 577 jlaganier@JUNIPER.NET 579 10. Acknowledgements 581 The authors would like to acknowledge prior discussions on this topic 582 in NETLMM and NETEXT working groups. The authors would also like to 583 thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj Patil, 584 Peter McCann, and Julien Laganier for all the discussions on this 585 topic. 587 11. References 588 11.1. Normative References 590 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 591 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 592 September 2007. 594 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 595 Address Autoconfiguration", RFC 4862, September 2007. 597 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 598 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 600 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 601 Mobile IPv6", RFC 5844, May 2010. 603 11.2. Informative References 605 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 606 RFC 2131, March 1997. 608 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 609 Internet Protocol", RFC 4301, December 2005. 611 [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 612 PPP", RFC 5072, September 2007. 614 [RFC5677] Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, 615 "IEEE 802.21 Mobility Services Framework Design (MSFD)", 616 RFC 5677, December 2009. 618 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 619 "Address Mapping of IPv6 Multicast Packets on Ethernet", 620 RFC 6085, January 2011. 622 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 623 in IPv6", RFC 6275, July 2011. 625 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 626 Provisioning Domains Problem Statement", RFC 6418, 627 November 2011. 629 [TS23401] "3rd Generation Partnership Project; Technical 630 Specification Group Services and System Aspects; General 631 Packet Radio Service (GPRS) enhancements for Evolved 632 Universal Terrestrial Radio Access Network (E-UTRAN) 633 access.", 2009. 635 [TS23402] "3rd Generation Partnership Project; Technical 636 Specification Group Services and System Aspects; 637 Architecture Enhancements for non-3GPP Accesses.", 2009. 639 Authors' Addresses 641 Telemaco Melia (editor) 642 Alcatel-Lucent 643 Route de Villejust 644 Nozay 91620 645 France 647 Email: telemaco.melia@alcatel-lucent.com 649 Sri Gundavelli (editor) 650 Cisco 651 170 West Tasman Drive 652 San Jose, CA 95134 653 USA 655 Email: sgundave@cisco.com