idnits 2.17.1 draft-ietf-netext-logical-interface-support-14.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 (March 13, 2016) is 2965 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-netext-pmipv6-flowmob-17 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 0 errors (**), 0 flaws (~~), 2 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 Kudelski Security 4 Intended status: Informational S. Gundavelli, Ed. 5 Expires: September 14, 2016 Cisco 6 March 13, 2016 8 Logical-interface Support for Multi-access enabled IP Hosts 9 draft-ietf-netext-logical-interface-support-14 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 attached 17 to a Proxy Mobile IPv6 domain, for leveraging various network-based 18 mobility management features such as inter-technology handoffs, 19 multihoming and flow mobility support. This document explains the 20 operational details of Logical-interface construct and the specifics 21 on how the link-layer implementations hide the physical interfaces 22 from the IP stack and from the network nodes on the attached access 23 networks. Furthermore, this document identifies the applicability of 24 this approach to various link-layer technologies and analyzes the 25 issues around it when used in conjunction with various mobility 26 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 September 14, 2016. 45 Copyright Notice 47 Copyright (c) 2016 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. Link layer support . . . . . . . . . . . . . . . . . . . . 6 70 3.3. Logical Interface . . . . . . . . . . . . . . . . . . . . 6 72 4. Technology Use cases . . . . . . . . . . . . . . . . . . . . . 7 74 5. Logical Interface Functional Details . . . . . . . . . . . . . 8 75 5.1. Configuration of a Logical Interface . . . . . . . . . . . 9 76 5.2. Logical-Interface Forwarding Table . . . . . . . . . . . . 9 78 6. Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 11 79 6.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 11 80 6.2. Inter-Technology Handoff Support . . . . . . . . . . . . . 12 81 6.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 13 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility 100 management protocol standardized by IETF. One of the key goals of 101 the PMIPv6 protocol is to enable a mobile node to perform handovers 102 across access-networks based on different access technologies. The 103 protocol was also designed with the goal to allow a mobile node to 104 simultaneously attach to different access networks and perform flow- 105 based access selection [I-D.ietf-netext-pmipv6-flowmob]. The base 106 protocol features specified in [RFC5213] and [RFC5844] has support 107 for these capabilities. However, for supporting these features, the 108 mobile node is required to be enabled with with specific software 109 configuration known as logical-interface support. The logical- 110 interface configuration is essential for a mobile node to perform 111 inter-access handovers without impacting the IP sessions on the host. 113 A Logical Interface construct is internal to the operating system. 114 It is an approach of interface abstraction, where a logical link- 115 layer implementation hides a variety of physical interfaces from the 116 IP stack. This semantic was used on a variety of operating systems 117 to implement applications such as Mobile IP client [RFC6275] and 118 IPsec VPN client [RFC4301]. Many host operating systems have support 119 for some form of such logical interface construct. But, there is no 120 specification which documents the behavior of these logical- 121 interface, or the requirements of a logical interface for supporting 122 the above mentioned mobility management features. This specification 123 attempts to document these aspects. 125 The rest of the document provides a functional description of a 126 Logical Interface on the mobile node and the interworking between a 127 mobile node using a logical interface and the network elements in the 128 Proxy Mobile IPv6 domain. It also analyzes the issues involved with 129 the use of logical-interface and characterizes the contexts in which 130 such usage is appropriate. 132 2. Terminology 134 All the mobility related terms used in this document are to be 135 interpreted as defined in Proxy Mobile IPv6 specifications, [RFC5213] 136 and [RFC5844]. In addition, this document uses the following terms: 138 PIF (Physical Interface) - It is a network interface module on the 139 host that is used for connecting to an access network. An host 140 typically has number of network interface modules, such as 141 Ethernet, Wireless LAN, LTE ..etc. Each of these network 142 interfaces can support specific link technology. 144 LIF (Logical Interface) - It is a virtual interface in the IP stack. 145 Logical interface appears to the IP stack just as any other 146 physical interface, provides similar semantics with respect to 147 packet transmit and receive functions to the upper layers of the 148 IP stack. However, it is only a logical construct and is not a 149 representation of an instance of any physical hardware. 151 SIF (Sub Interface) - It is a physical or logical interface that is 152 part of a logical interface construct. For example, a logical 153 interface may have been created abstracting two physical 154 interfaces, LTE and WLAN. These physical interfaces, LTE and WLAN 155 are referred to as sub-interfaces of that logical interface. In 156 some cases, a sub-interface can also be another logical interface, 157 such as an IPsec tunnel interface. 159 3. Hiding Link-layer Technologies - Approaches and Applicability 161 There are several techniques that allow hiding of changes in access- 162 technology changes from the host layer. These changes in access 163 technology is primarily due to host's movement between access 164 networks. This section classifies these existing techniques into a 165 set of generic approaches, according to their most representative 166 characteristics. Later sections of this document analyze the 167 applicability of these solution approaches for supporting features 168 such as, inter-technology handovers and IP flow mobility support for 169 a mobile node. 171 3.1. Link-layer Abstraction - Approaches 173 The following generic mechanisms can hide access technology changes 174 from host IP layer: 176 o Link-layer Support - Certain link-layer technologies are able to 177 hide physical media changes from the upper layers. For example, 178 IEEE 802.11 is able to seamlessly change between IEEE 802.11a/b/g 179 physical layers. Also, an 802.11 STA can move between different 180 Access Points within the same domain without the IP stack being 181 aware of the movement. In this case, the IEEE 802.11 MAC layer 182 takes care of the mobility, making the media change invisible to 183 the upper layers. Another example is IEEE 802.3, that supports 184 changing the rate from 10Mbps to 100Mbps and to 1000Mbps. Another 185 example is the situation in the 3GPP Evolved Packet System 186 [TS23401] where a UE can perform inter-access handovers between 187 three different access technologies (2G GERAN, 3G UTRAN, and 4G 188 E-UTRAN) that are invisible to the IP layer at the UE. 190 o A logical interface denotes a mechanism that logically groups 191 several physical interfaces so they appear to the IP layer as a 192 single interface (see Figure 1). Depending on the type of access 193 technologies, it might be possible to use more than one physical 194 interface at a time -- such that the node is simultaneously 195 attached via different access technologies -- or just to perform 196 handovers across a variety of physical interfaces. Controlling 197 the way the different access technologies are used (simultaneous, 198 sequential attachment, etc) is not trivial and requires additional 199 intelligence and/or configuration within the logical interface 200 implementation. The configuration is typically handled via a 201 connection manager, and based on a combination of user preferences 202 on one hand, and operator preferences such as those provisioned by 203 the Access Network Discovery and Selection Function (ANDSF) 204 [TS23402] on the other hand. The IETF Interfaces MIB specified in 205 [RFC2863] and the YANG data model for Interface management 206 specified in [RFC7223] treats logical interface as just any other 207 type of network interface on the host. This essentially makes 208 logical interface as a natural operating system construct. 210 3.2. Link layer support 212 Link layer mobility support applies to cases when the same link layer 213 technology is used and mobility can be fully handled at that layer. 214 One example is the case where several 802.11 access points are 215 deployed in the same subnet with a common IP layer configuration 216 (DHCP server, default router, etc.). In this case the handover 217 across access points need not to be hidden to the IP layer since the 218 IP layer configuration remains the same after a handover. This type 219 of scenario is applicable to cases when the different points of 220 attachment (i.e. access points) belong to the same network domain, 221 e.g. Enterprise, hotspots from same operator, etc. 223 Since this type of link layer technology does not typically allow for 224 simultaneous attachment to different access networks of the same 225 technology, the logical interface would not be used to provide 226 simultaneous access for purposes of multihoming or flow mobility. 227 Instead, the logical interface can be used to provide inter-access 228 technology handover between this type of link layer technology and 229 another link layer technology, e.g., between IEEE 802.11 and IEEE 230 802.16. 232 3.3. Logical Interface 234 The use of a logical interface allows the mobile node to provide a 235 single interface perspective to the IP layer and its upper layers 236 (transport and application). Doing so allows to hide inter-access 237 technology handovers or application flow handovers across different 238 physical interfaces. 240 The logical interface may support simultaneous attachment, in 241 addition to sequential attachment. It requires additional support at 242 the node and the network in order to benefit from simultaneous 243 attachment. For example special mechanisms are required to enable 244 addressing a particular interface from the network (e.g. for flow 245 mobility). In particular extensions to PMIPv6 are required in order 246 to enable the network (i.e., the MAG and LMA) to deal with logical 247 interface, instead to IP interfaces as current RFC5213 does. RFC5213 248 assumes that each physical interface capable of attaching to a MAG is 249 an IP interface, while the logical interface solution groups several 250 physical interfaces under the same IP logical interface. 252 It is therefore clear that the Logical Interface approach satisfies 253 the multi technology and the sequential vs: simultaneous access 254 support. 256 4. Technology Use cases 258 3GPP has defined the Evolved Packet System (EPS) for heterogeneous 259 wireless access. A mobile device equipped with 3GPP and non-3GPP 260 wireless technologies can simultaneously or sequentially connect any 261 of the available devices and receive IP services through any of them. 262 This document focuses on employing a logical interface for 263 simultaneous and sequential use of a variety of access technologies. 265 As mentioned in the previous sections the Logical Interface construct 266 is able to hide to the IP layer the specifics of each technology in 267 the context of network based mobility (e.g. in multi-access 268 technology networks based on PMIPv6). The LIF concept can be used 269 with at least the following technologies: 3GPP access technologies 270 (3G, LTE), IEEE 802.16 access technology, and IEEE 802.11 access 271 technology. 273 In some UE implementations the wireless connection setup is based on 274 creation of a PPP interface between the IP layer and the wireless 275 modem that is configured with the IPCP and IPv6CP protocol [RFC5072]. 276 In this case the PPP interface does not have any L2 address assigned. 277 In some other implementations the wireless modem is presented to the 278 IP layer as a virtual Ethernet interface. 280 5. Logical Interface Functional Details 282 This section identifies the functional details of a logical interface 283 and provides some implementation considerations. 285 On most operating systems, a network interface is associated with a 286 physical device that offers the services for transmitting and 287 receiving IP packets from the network. In some configurations, a 288 network interface can also be implemented as a logical interface 289 which does not have the inherent capability to transmit, or receive 290 packets on a physical medium, but relies on other physical interfaces 291 for such services. Example of such configuration is an IP tunnel 292 interface. 294 An overview of a logical interface is shown in Figure 1. The logical 295 interface allows heterogeneous attachment while making changes in the 296 underlying media transparent to the IP stack. Simultaneous and 297 sequential network attachment procedures are therefore possible, 298 enabling inter-technology and flow mobility scenarios. 300 +----------------------------+ 301 | TCP/UDP | 302 Session to IP +---->| | 303 Address binding | +----------------------------+ 304 +---->| IP | 305 IP Address +---->| | 306 binding | +----------------------------+ 307 +---->| Logical Interface | 308 Logical to +---->| IPv4/IPv6 Address | 309 Physical | +----------------------------+ 310 Interface +---->| L2 | L2 | | L2 | 311 binding |(IF#1)|(IF#2)| ..... |(IF#n)| 312 +------+------+ +------+ 313 | L1 | L1 | | L1 | 314 | | | | | 315 +------+------+ +------+ 317 Figure 1: General overview of logical interface 319 From the perspective of the IP stack and the applications, a Logical 320 interface is just another interface. In fact, the logical interface 321 is only visible to the IP and upper layers when enabled. A host does 322 not see any operational difference between a Logical and a physical 323 interface. As with physical interfaces, a Logical interface is 324 represented as a software object to which IP address configuration is 325 bound. However, the Logical interface has some special properties 326 which are essential for enabling inter-technology handover and flow- 327 mobility features. Following are those properties: 329 1. The logical interface has a relation to a set of physical 330 interfaces (sub-interfaces) on the host that it is abstracting. 331 These sub-interfaces can be attached or detached from the Logical 332 Interface at any time. The sub-interfaces attached to a Logical 333 interface are not visible to the IP and upper layers. 335 2. The logical interface may be attached to multiple access 336 technologies. 338 3. The Transmit/Receive functions of the logical interface are 339 mapped to the Transmit/Receive services exposed by the sub- 340 interfaces. This mapping is dynamic and any change is not 341 visible to the upper layers of the IP stack. 343 4. The logical interface maintains IP flow information for each of 344 its sub-interfaces. A conceptual data structure is maintained 345 for this purpose. The host may populate this information based 346 on tracking each of the sub-interface for the active flows. 348 5.1. Configuration of a Logical Interface 350 A host may be statically configured with the logical interface 351 configuration, or an application such as a connection manager on the 352 host may dynamically create it. Furthermore, the set of sub- 353 interfaces that are part of a logical interface construct may be a 354 fixed set, or may be kept dynamic, with the sub-interfaces getting 355 added or deleted as needed. The specific details related to these 356 configuration aspects are implementation specific and are outside the 357 scope of this document. 359 The IP layer should be configured with a default router reachable via 360 the logical interface. The default router can be internal to the 361 logical interface, i.e., it is a logical router that in turns decide 362 which physical interface is to be used to transmit packets. 364 5.2. Logical-Interface Forwarding Table 366 The logical interface maintains the list of sub-interfaces that are 367 part of logical-interface construct. This is a conceptual data 368 structure, called as the Logical-Interface Forwarding Table. 370 The logical interface also maintains the list of flows associated 371 with a given sub-interface and this conceptual data structure is 372 called as the PIF Table. Both of these data structures have to be 373 associated with a logical interface, and are depicted in Figure 2. 375 LIF TABLE FLOW table 376 +===============================+ +=============================+ 377 | PIF_ID | FLOW Routing Policies| | FLOW ID | Physical_Intf_Id | 378 | | Link Status | +-----------------------------+ 379 +-------------------------------| | FLOW_ID | Physical_Intf_Id | 380 | PIF_ID | FLOW Routing Policies| +=============================+ 381 | | Link Status | + .... | .... | 382 +-------------------------------+ +=============================+ 383 | .... | .... | 384 +===============================+ 386 Figure 2: Logical Interface Table 388 The LIF table maintains the mapping between the LIF and each PIF 389 associated to the LIF (refer to property #3, Figure 1). For each PIF 390 entry the table should store the associated Routing Policies, and the 391 Link Status of the PIF (e.g. active, not active). The method by 392 which the Routing Policies are configured on the host is out of scope 393 for this document. 395 The FLOW table allows the logical interface to properly route each IP 396 flow over the right interface. The logical interface can identify 397 the flows arriving on its sub-interfaces and associate them to those 398 sub-interfaces. This approach is similar to reflective QoS performed 399 by the IP routers. For locally generated traffic (e.g. unicast 400 flows), the logical interface should perform interface selection 401 based on the Flow Routing Policies. In case traffic of an existing 402 flow is suddenly received from the network on a different sub- 403 interface than the one locally stored, the logical interface should 404 interpret the event as an explicit flow mobility trigger from the 405 network and it should update the PIF_ID parameter in the FLOW table. 406 Similarly, locally generated events from the sub-interfaces, or 407 configuration updates to the local policy rules can cause updates to 408 the table and hence trigger flow mobility. 410 6. Logical Interface Use-cases in Proxy Mobile IPv6 412 This section explains how the Logical interface support on the mobile 413 node can be used for enabling some of the Proxy Mobile IPv6 protocol 414 features. 416 6.1. Multihoming Support 418 A mobile node with multiple interfaces can attach simultaneously to 419 the Proxy Mobile IPv6 domain. If the host is configured to use 420 Logical interface over the physical interfaces through which it is 421 attached, following are the related considerations. 423 LMA Binding Table 424 +========================+ 425 +----+ | HNP MN-ID CoA ATT | 426 |LMA | +========================+ 427 +----+ | HNP-1 MN-1 PCoA-1 5 | 428 //\\ | HNP-1 MN-1 PCoA-2 4 | 429 +---------//--\\-----------+ 430 ( // \\ ) 431 ( // \\ ) 432 +------//--------\\--------+ 433 // \\ 434 PCoA-1 // \\ PCoA-2 435 +----+ +----+ 436 (WLAN) |MAG1| |MAG2| (3GPP) 437 +----+ +----+ 438 \ / 439 \ / 440 \ / 441 \ / 442 \ / 443 +-------+ +-------+ 444 | if_1 | | if_2 | 445 |(WLAN) | |(3GPP) | 446 +-------+-+-------+ 447 | Logical | 448 | Interface | 449 | (HNP-1) | 450 +-----------------| 451 | MN | 452 +-----------------+ 454 Figure 3: Multihoming Support 456 6.2. Inter-Technology Handoff Support 458 The Proxy Mobile IPv6 protocol enables a mobile node with multiple 459 network interfaces to move between access technologies, but still 460 retaining the same address configuration on its attached interface. 461 The protocol enables a mobile node to achieve address continuity 462 during handoffs. If the host is configured to use Logical interface 463 over the physical interface through which it is attached, following 464 are the related considerations. 466 LMA's Binding Table 467 +==========================+ 468 +----+ | HNP MN-ID CoA ATT | 469 |LMA | +==========================+ 470 +----+ | HNP-1 MN-1 PCoA-1 5 | 471 //\\ (pCoA-2)(4) <--change 472 +---------//--\\-----------+ 473 ( // \\ ) 474 ( // \\ ) 475 +------//--------\\--------+ 476 // \\ 477 PCoA-1 // \\ PCoA-2 478 +----+ +----+ 479 (WLAN) |MAG1| |MAG2| (3GPP) 480 +----+ +----+ 481 \ / 482 \ Handoff / 483 \ / 484 \ / 485 +-------+ +-------+ 486 | if_1 | | if_2 | 487 |(WLAN) | |(3GPP) | 488 +-------+-+-------+ 489 | Logical | 490 | Interface | 491 | (HNP-1) | 492 +-----------------| 493 | MN | 494 +-----------------+ 496 Figure 4: Inter-Technology Handoff Support 498 o When the mobile node performs an handoff between if_1 and if_2, 499 the change will not be visible to the applications of the mobile 500 node. 502 o The protocol signaling between the network elements will ensure 503 the local mobility anchor will switch the forwarding for the 504 advertised prefix set from MAG1 to MAG2. 506 6.3. Flow Mobility Support 508 For supporting IP flow mobility, there is a need to support vertical 509 handoff scenarios such as transferring a subset of prefix(es) (hence 510 the flows associated to it/them) from one interface to another. The 511 mobile node can support this scenario by using the Logical interface 512 support. This scenario is similar to the Inter- technology handoff 513 scenario defined in Section 6.2, only a subset of the prefixes are 514 moved between interfaces. 516 Additionally, IP flow mobility in general initiates when the LMA 517 decides to move a particular flow from its default path to a 518 different one. The LMA can decide on which is the best MAG that 519 should be used to forward a particular flow when the flow is 520 initiated e.g. based on application policy profiles) and/or during 521 the lifetime of the flow upon receiving a network-based or a mobile- 522 based trigger. However, the specific details on how the LMA can 523 formulate such flow policy is outside the scope of this document. 525 7. IANA Considerations 527 This specification does not require any IANA Actions. 529 8. Security Considerations 531 This specification explains the operational details of Logical 532 interface on an IP host. The Logical Interface implementation on the 533 host is not visible to the network and does not require any special 534 security considerations. 536 Different layer-2 interfaces and the access networks to which they 537 are connected have different security properties. For example, the 538 layer-2 network security of an end-user operated Wireless LAN network 539 is in the control of the home user and whereas an LTE operator has 540 the control on the layer-2 security of the LTE access network. An 541 external entity using lawful means, or through other means obtain the 542 security keys from the LTE operator and the same may not be possible 543 in the case of a home user operated wireless LAN network. Therefore, 544 grouping interfaces with such varying security properties into one 545 logical interface could have negative consequences in some cases. 546 Such differences though subtle, are entirely hidden by logical 547 interfaces and are unknown to the upper layers. 549 9. Authors 551 This document reflects contributions from the following authors 552 (listed in alphabetical order): 554 Carlos Jesus Bernardos Cano 556 cjbc@it.uc3m.es 558 Antonio De la Oliva 560 aoliva@it.uc3m.es 562 Yong-Geun Hong 564 yonggeun.hong@gmail.com 566 Kent Leung 568 kleung@cisco.com 570 Tran Minh Trung 572 trungtm2909@gmail.com 574 Hidetoshi Yokota 576 yokota@kddilabs.jp 578 Juan Carlos Zuniga 580 JuanCarlos.Zuniga@InterDigital.com 582 10. Acknowledgements 584 The authors would like to acknowledge all the discussions on this 585 topic in NETLMM and NETEXT working groups. The authors would also 586 like to thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj 587 Patil, Peter McCann, Julien Laganier, Maximilian Riegel, Georgios 588 karagian, Stephen Farrell, Benoit Claise for their inputs to the 589 document. 591 11. References 592 11.1. Normative References 594 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 595 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 596 RFC 5213, DOI 10.17487/RFC5213, August 2008, 597 . 599 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 600 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 601 . 603 11.2. Informative References 605 [I-D.ietf-netext-pmipv6-flowmob] 606 Bernardos, C., "Proxy Mobile IPv6 Extensions to Support 607 Flow Mobility", draft-ietf-netext-pmipv6-flowmob-17 (work 608 in progress), March 2016. 610 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 611 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 612 . 614 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 615 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 616 December 2005, . 618 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 619 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 620 . 622 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 623 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, 624 July 2011, . 626 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 627 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 628 . 630 [TS23401] "3rd Generation Partnership Project; Technical 631 Specification Group Services and System Aspects; General 632 Packet Radio Service (GPRS) enhancements for Evolved 633 Universal Terrestrial Radio Access Network (E-UTRAN) 634 access.", 2009. 636 [TS23402] "3rd Generation Partnership Project; Technical 637 Specification Group Services and System Aspects; 638 Architecture Enhancements for non-3GPP Accesses.", 2009. 640 Authors' Addresses 642 Telemaco Melia (editor) 643 Kudelski Security 644 Geneva 645 Switzerland 647 Email: telemaco.melia@gmail.com 649 Sri Gundavelli (editor) 650 Cisco 651 170 West Tasman Drive 652 San Jose, CA 95134 653 USA 655 Email: sgundave@cisco.com