idnits 2.17.1 draft-ietf-netext-logical-interface-support-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2012) is 4379 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: October 31, 2012 Cisco 6 April 29, 2012 8 Logical Interface Support for multi-mode IP Hosts 9 draft-ietf-netext-logical-interface-support-05.txt 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 October 31, 2012. 45 Copyright Notice 47 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Hiding Link-layer Technologies - Approaches and 67 Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Link-layer Abstraction - Approaches . . . . . . . . . . . 6 69 3.2. Applicability Statement . . . . . . . . . . . . . . . . . 7 70 3.2.1. Link layer support . . . . . . . . . . . . . . . . . . 8 71 3.2.2. Logical Interface . . . . . . . . . . . . . . . . . . 8 73 4. Technology Use cases . . . . . . . . . . . . . . . . . . . . . 10 75 5. Logical Interface Functional Details . . . . . . . . . . . . . 11 76 5.1. Configuration of a Logical Interface . . . . . . . . . . . 12 77 5.2. MTU considerations for a Logical Interface . . . . . . . . 13 78 5.3. Supported Link models for a logical interface . . . . . . 13 79 5.4. Link-layer Identifier Selection for a Logical Interface . 13 80 5.5. ND Considerations for Logical Interface . . . . . . . . . 14 81 5.6. Provisioning Domain Considerations . . . . . . . . . . . . 15 82 5.7. Logical Interface Forwarding Conceptual Data Structures . 15 84 6. Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 17 85 6.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 17 86 6.2. Inter-Technology Handoff Support . . . . . . . . . . . . . 18 87 6.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 20 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 93 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 98 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 Proxy Mobile IPv6 [RFC5213] is a network-based mobility protocol. 105 Some of the key goals of the protocol include support for 106 multihoming, inter-technology handoffs and flow mobility support. 107 The base protocol features specified in [RFC5213] and [RFC5844] allow 108 the mobile node to attach to the network using multiple interfaces 109 (simultaneously or sequentially), or to perform handoff between 110 different interfaces of the mobile node. However, for supporting 111 these features, the mobile node is required to be activated with 112 specific software configuration that allows the mobile node to either 113 perform inter-technology handoffs between different interfaces, 114 attach to the network using multiple interfaces, or perform flow 115 movement from one access technology to another. This document 116 analyzes from the mobile node's perspective a specific approach that 117 allows the mobile node to leverage these mobility features. 118 Specifically, it explores the use of the Logical Interface support, a 119 semantic available on most operating systems. 121 A Logical Interface is a construct internal to the operating system. 122 It is an approach where the link-layer implementations hide the 123 physical interfaces from the IP stack and from the network nodes on 124 the attached access networks. This semantic is widely available in 125 all popular operating systems. Many applications such as Mobile IP 126 client [RFC6275] and IPsec VPN client [RFC4301] rely on this semantic 127 for their protocol implementation and the same semantic can also be 128 useful in this context. Specifically, the mobile node can use the 129 logical interface configuration for leveraging various network-based 130 mobility management features provided by the Proxy Mobile IPv6 domain 131 [RFC5213]. 133 The rest of the document provides the operational details of a 134 Logical Interface on the mobile node and the inter-working between a 135 mobile node using logical interface and network elements in the Proxy 136 Mobile IPv6 domain when supporting some of the mobility management 137 features. It also analyzes the issues involved with this approach 138 and characterizes the contexts in which such usage is appropriate. 140 2. Terminology 142 All the mobility related terms used in this document are to be 143 interpreted as defined in Proxy Mobile IPv6 specifications, [RFC5213] 144 and [RFC5844]. In addition, this document introduces the following 145 terms: 147 PIF (Physical Interface) - a network interface card attached to an 148 an host providing network connectivity (e.g. an Ethernet card, a 149 WLAN card, an LTE interface). 151 LIF (Logical Interface) - It is a virtual interface in the IP stack. 152 It appears just as any other physical interface, provides similar 153 semantics with respect to packet transmit and receive functions to 154 the upper layers in the IP stack. However, it is only logical 155 construct and is not a representation of an instance of any 156 physical hardware. 158 VLL-ID (Virtual Link-layer ID) - a virtual link-layer address 159 configured on the logical interface. This identifier can be 160 randomly generated, or configured based on the link-layer address 161 of one of the physical interface. 163 Sub-If (Sub Interface) - a physical interface that is part of a 164 logical interface construct. For example, a logical interface may 165 have been created abstracting two physical interfaces, LTE and 166 WLAN. These physical interfaces, LTE and WLAN are referred to as 167 sub-interfaces of that logical interface. In some cases, a sub- 168 interface can also be another logical interface, such as an IPsec 169 tunnel interface. 171 3. Hiding Link-layer Technologies - Approaches and Applicability 173 There are several techniques/mechanisms that allow hiding access 174 technology changes or movement from host IP layer. This section 175 classifies these existing techniques into a set of generic 176 approaches, according to their most representative characteristics. 177 Later sections of this document analyze the applicability of these 178 solution approaches for supporting features such as, inter-technology 179 handovers and IP flow mobility support for a mobile node in a Proxy 180 Mobile IPv6 domain [RFC5213]. 182 3.1. Link-layer Abstraction - Approaches 184 The following generic mechanisms can hide access technology changes 185 from host IP layer: 187 o Link-layer Support - Certain link-layer technologies are able to 188 hide physical media changes from the upper layers (see Figure 1). 189 For example, IEEE 802.11 is able to seamlessly change between IEEE 190 802.11a/b/g physical layers. Also, an 802.11 STA can move between 191 different Access Points within the same domain without the IP 192 stack being aware of the movement. In this case, the IEEE 802.11 193 MAC layer takes care of the mobility, making the media change 194 invisible to the upper layers. Another example is IEEE 802.3, 195 that supports changing the rate from 10Mbps to 100Mbps and to 196 1000Mbps. 197 Mobile Node 198 +-----------------------+ 199 | TCP/UDP | AR1 AR2 200 +-----------------------+ +-----+ +-----+ 201 | IP | | IP | | IP | 202 +-----------------------+ +-----+ +-----+ 203 | Link Layer (L2) | | L2 | | L2 | 204 +-----+-----+-----+-----+ +-----+ +-----+ 205 | L1a | L1b | L1c | L1d |<---------->| L1d | | L1b | 206 +-----+-----+-----+-----+ +-----+ +-----+ 207 ^ ^ 208 |_________________________________________| 210 Figure 1: Link layer support solution architecture 212 There are also other examples with more complicated architectures, 213 like for instance, 3GPP EPC [TS23401]. In this case, a UE can 214 move (inter-RA handover) between GERAN/UTRAN/E-UTRAN, being this 215 movement invisible to the IP layer at the UE, and also to the LMA 216 logical component at the PGW. The link layer stack at the UE 217 (i.e. PDCP and RLC layers), and the GTP between the RAN and the 218 SGW (which plays the role of inter-3GPP AN mobility anchor) hide 219 this kind of mobility, which is not visible to the IP layer of the 220 UE (see Figure 2). 221 --------- 222 | Appl. |<-----------------------------------------------------> 223 --------- ---------- 224 | |<+ - - - - - - - - - - - - - - - - - - - - +>| | 225 | IP | . ----------------- . ------------------- . | IP | 226 | |<+>| relay |<+>| relay | . | | 227 --------- . ----------------- . ------------------- . ---------- 228 | PDCP |<+>| PDCP | GTP-U |<+>| GTP-U | GTP-U |<+>| GTP-U | 229 --------- . ----------------- . ------------------- . ---------- 230 | RLC |<+>| RLC | UDP/IP |<+>| UDP/IP | UDP/IP |<+>| UDP/IP | 231 --------- . ----------------- . ------------------- . ---------- 232 | MAC |<+>| MAC | L2 |<+>| L2 | L2 |<+>| L2 | 233 --------- . ----------------- . ------------------- . ---------- 234 | L1 |<+>| L1 | L1 |<+>| L1 | L1 |<+>| L1 | 235 --------- . ----------------- . ------------------- . ---------- 236 UE Uu E-UTRAN S1-U SGW S5/S8a PGW 238 Figure 2: 3GPP LTE/EPC data plane architecture (GTP option) 240 o Logical interface: this refers to solutions (see Figure 3) that 241 logically group/bond several physical interfaces so they appear to 242 the upper layers (i.e. IP) as one single interface (where 243 application sockets bind). Depending on the OS support, it might 244 be possible to use more than one physical interface at a time -- 245 so the node is simultaneously attached to different media -- or 246 just to provide a fail-over mode. Controlling the way the 247 different media is used (simultaneous, sequential attachment, etc) 248 is not trivial and requires additional intelligence and/or 249 configuration at the logical interface device driver. An example 250 of this type of solution is the Logical interface, which is 251 defined in this document, or the bonding driver (a Linux 252 implementation). 254 3.2. Applicability Statement 256 We now focus on the applicability of the above solutions against the 257 following requirements: 259 o multi technology support 261 o sequential vs. simultaneous access 263 3.2.1. Link layer support 265 Link layer mobility support applies to cases when the same link layer 266 technology is used and mobility can be fully handled at these layers. 267 One example is the case where several 802.11 access points are 268 deployed in the same subnet and all of them share higher layer 269 resources such as DHCP server, IP gateway, etc. In this case the 270 access points can autonomously (or with the help of a central box) 271 communicate and control the STA association changes from one AP to 272 another, without the STA being aware of the movement. This type of 273 scenario is applicable to cases when the different points of 274 attachment (i.e. access points) belong to the same network domain, 275 e.g. Enterprise, hotspots from same operator, etc. 277 This type of solution does not typically allow for simultaneous 278 attachment to different access networks, and therefore can only be 279 considered for inter-access technology handovers, but not for flow 280 mobility. Existing RFC 5213 handover hint mechanisms could benefit 281 from link layer information (e.g. triggers) to detect and identify MN 282 handovers. 284 Link layer support is not applicable when two different access 285 technologies are involved (e.g. 802.11 WLAN and 802.16 WiMAX) and the 286 same is true when the same access technology expands over multiple 287 network domains. This solution does not impose any change at the IP 288 layer since changes in the access technology occur at layer two. 290 3.2.2. Logical Interface 292 The use of a logical interface allows the mobile node to provide a 293 single interface view to the layers above IP (thus not changing the 294 IP layer itself). Upper layers can bind to this interface, which 295 hides inner inter-access technology handovers or data flow transfers 296 among different physical interfaces. 298 This type of solution may support simultaneous attachment, in 299 addition to sequential attachment. It requires additional support at 300 the node and the network in order to benefit from simultaneous 301 attachment. For example special mechanisms are required to enable 302 addressing a particular interface from the network (e.g. for flow 303 mobility). In particular extensions to PMIPv6 are required in order 304 to enable the network (i.e., the MAG and LMA) to deal with logical 305 interface, instead to IP interfaces as current RFC5213 does. RFC5213 306 assumes that each physical interface capable of attaching to a MAG is 307 an IP interface, while the logical interface solution groups several 308 physical interfaces under the same IP logical interface. 310 It is therefore clear that the Logical Interface approach satisfies 311 the multi technology and the sequential vs: simultaneous access 312 support. 314 4. Technology Use cases 316 The 3GPP has defined the Evolved Packet Core (EPC) for heterogeneous 317 wireless access. A mobile device equipped with 3GPP and non-3GPP 318 wireless technologies can simultaneously or sequentially connect any 319 of the available devices and receive IP services through any of them. 320 This document focuses on the simultaneous/sequential use of these 321 technologies and on the use cases that derive. 323 As mentioned in the previous sections the Logical Interface construct 324 is required to hide the specifics of each technology in the context 325 of network based mobility (e.g. in PMIPv6 deployments). The LIF 326 concept can be used with at least the following technologies: 3GPP 327 access technologies (3G, LTE), WIMAX access technology and IEEE 328 802.11 access technology. 330 3GPP In most OS implementations the connection setup establishes a 331 PPP interface through the IPCP and IPv6CP protocol [RFC5072]. In 332 this case the PPP interface does not have any L2 address assigned 333 and does not generate any ARP or ND message for layer two address 334 resolution. Conversely recent implementations configure an 335 ethernet alike interface at OS level hiding to the upper layers 336 the PPP nature of the connection. It has been verified (Android 337 platform) that in these cases the ethernet alike interface 338 configures a random L2 MAC address and uses this address as source 339 link layer address option carried in the ND messages. ARP is also 340 run between the mobile device and the remote peer (the network is 341 a /30 address space). 343 WIMAX In WiMAX system also, the connection between the mobile 344 station (MS) and the access router (AR) is a point-to-point link. 345 The MS auto configures an address based on the prefix advertised 346 by the AR or is assigned an address via DHCPv6. The stateless 347 address auto-configuration is performed as per [RFC4861] and the 348 IPv6 address is formed by adding an IID to the prefix learnt from 349 Router Advertisement. IPv6 packets sent or received by the MS are 350 identified by specific IDs, by which the AR can map them to the 351 corresponding tunnel in the network. 353 5. Logical Interface Functional Details 355 This section identifies the functional details of a logical interface 356 and provides some implementation considerations. 358 On most operating systems, a network interface is associated with a 359 physical device that offers the services for transmitting and 360 receiving IP packets to the applications on the host. In some 361 configurations, a network interface can also be implemented as a 362 logical interface which does not have the inherent capability to 363 transmit, or receive packets on a physical medium, but relies on 364 other physical interfaces for such services. Example of such 365 configuration is an IP tunnel interface. 367 General overview of a logical interface is shown in Figure 3. The 368 logical interface allows heterogeneous attachment while leaving the 369 change in the media transparent to the IP stack. Simultaneous and 370 sequential network attachment procedures are possible enabling inter- 371 technology and flow mobility scenarios. 373 +----------------------------+ 374 | TCP/UDP | 375 Session to IP +---->| | 376 Address binding | +----------------------------+ 377 +---->| IP | 378 IP Address +---->| | 379 binding | +----------------------------+ 380 +---->| Logical Interface | 381 Logical to +---->| IPv4/IPv6 Address | 382 Physical | +----------------------------+ 383 Interface +---->| L2 | L2 | | L2 | 384 binding |(IF#1)|(IF#2)| ..... |(IF#n)| 385 +------+------+ +------+ 386 | L1 | L1 | | L1 | 387 | | | | | 388 +------+------+ +------+ 390 Figure 3: General overview of logical interface 392 From the perspective of the IP stack and the applications, a Logical 393 interface is just another interface. In fact, the logical interface 394 is only visible to the IP and upper layers when enabled. A host does 395 not see any operational difference between a Logical and a physical 396 interface. As with physical interfaces, a Logical interface is 397 represented as a software object to which IP address configuration is 398 bound. However, the Logical interface has some special properties 399 which are essential for enabling inter-technology handover and flow- 400 mobility features. Following are those properties: 402 1. The logical interface has a relation to a set of physical 403 interfaces (sub-interfaces) on the host that it is abstracting. 404 These sub-interfaces can be attached or detached from the Logical 405 Interface at any time. The sub-interfaces attached to a Logical 406 interface are not visible to the IP and upper layers. 408 2. The logical Interface may either use a virtual interface 409 identifier independent of the interface identifiers of its sub- 410 interfaces, or it may use the link-layer identifier from one of 411 its sub-interfaces. 413 3. The logical interface has the path awareness with respect to the 414 attached IP networks. For example, the logical interface may be 415 bound to two IP networks, CAFE::/64 and BABA::/64, each of these 416 prefixes may have been hosted on access networks attached through 417 different sub-interfaces, WLAN and LTE. The logical interface 418 has the path awareness with respect to IP network to sub- 419 interface mapping. 421 4. The logical interface may be attached to multiple access 422 technologies with different link MTU values. The adopted MTU 423 value for the logical interface must be lowest MTU value across 424 those access technologies. 426 5. The Transmit/Receive functions of the logical interface are 427 mapped to the Transmit/Receive services exposed by the sub- 428 interfaces. This mapping is dynamic and any change is not 429 visible to the upper layers of the IP stack. 431 6. The logical interface adapts to the point-to-point link model. 433 7. The logical interface maintains IP flow information for each of 434 its sub-interfaces. A conceptual data structure is maintained 435 for this purpose. The host may populate this information based 436 on tracking each of the sub-interface for the active flows. 438 5.1. Configuration of a Logical Interface 440 A host may be statically configured with the logical interface 441 configuration, or an application such as a connection manager on the 442 host may dynamically create it. Furthermore, the set of sub- 443 interfaces that are part of a logical interface construct may be a 444 fixed set, or may be kept dynamic, with the sub-interfaces getting 445 added or deleted as needed. The specific details related to these 446 configuration aspects are implementation specific and is outside the 447 scope of this document. 449 5.2. MTU considerations for a Logical Interface 451 The link MTU (maximum transmission unit) value configured on a 452 logical interface should be the lowest of the MTU values supported 453 across any of the physical interfaces that are part of that logical 454 interface construct. The MTU value should be configured as part of 455 the logical interface creation on the host. 457 Furthermore, this value must be updated any time there is a change to 458 the logical interface construct, such as when interfaces are added or 459 deleted from the logical interface setup. Any time there is an 460 inter-technology handover between two access technologies, the 461 applications on the host bound to the IP address configuration on the 462 logical interface will not detect the change and will continue to use 463 the MTU value of the logical interface for the outbound packets, 464 which is never greater than the MTU value on that supported access 465 network. However, the access network may continue to deliver the 466 packets conforming to the MTU value supported on that access 467 technology and the logical interface should be able to receive those 468 packets from the physical interface attached to that network. This 469 approach of MTU configuration will ensure there is no IP packet 470 fragmentation after inter-technology handovers. 472 5.3. Supported Link models for a logical interface 474 As per the base Proxy Mobile IPv6 specification [RFC5213] the media 475 underneath the physical interface has to be bound to a point-to-point 476 link [RFC5213]. Access technologies that provides a shared media 477 (e.g., IEEE 802.11) can be supported as long as they provide a point- 478 to-point link [RFC4861]. The details of how a shared media provides 479 a point to point link are link layer specific and/or operational 480 matters that are out of scope of this document. For example IEEE 481 802.11 media can provide a point-to-point link via the appropriate 482 use of IEEE 802.1Q VLAN header where a distinct VLAN is configured 483 between the MAG and each of the mobile node, or by the approach of 484 MAG transmitting multicast packets as layer-2 unicast packets 485 [RFC6085] and thereby preserving the point-to-point link properties 486 on a shared link. 488 5.4. Link-layer Identifier Selection for a Logical Interface 490 The logical Interface may be configured to use the link-layer 491 identifier from one of its sub-interfaces, or an identifier 492 independent of the link-layer identifiers of the sub-interfaces. 493 Following are the considerations. 495 o In access architectures where it is possible to adopt a virtual 496 link-layer identifier and use it for layer-2 communications in any 497 of the access networks, a virtual identifier (VLL-Id) may be used. 498 The specifics on how that identifier is chosen is out side the 499 scope of this document. This identifier may be used for all link- 500 layer communications. This identifier may also be used as the 501 interface identifier when generating IPv6 global or link-local 502 addresses, based on Stateless Autoconfiguration [RFC4862] 504 o In access architectures, where the link-layer identifier is 505 associated with a specific access technology, it will not be 506 possible for the logical interface to adopt a virtual identifier 507 and it use it across different access networks. In such networks, 508 the logical interface must use the identifier of the respective 509 sub-interface through which a packet is being transmitted. 510 However, if more than one access technology domains that are part 511 of the logical interface have such requirement, then the logical 512 interface will not be able to support such configuration. 514 5.5. ND Considerations for Logical Interface 516 The following are the considerations related to supporting Neighbor 517 Discovery [RFC4861] on a logical interface. 519 o Any Neighbor Discovery messages, such as Router Solicitation, 520 Neighbor Solicitation Neighbor Advertisement messages that the 521 host sends to a multicast destination address of link-local scope 522 such as, all-nodes, all-routers, solicited-node multicast group 523 addresses, using either an unspecified (::) source address, or a 524 link-local address configured on the logical interface will be 525 replicated and forwarded on each of the sub-interfaces under that 526 logical interface. However, if the destination address is a 527 unicast address and if that target is known to exist on a specific 528 sub-interface, the packet will be forwarded only on that specific 529 sub-interface and will not be replicated on all sub-interfaces. 531 o Any Neighbor Discovery messages, such as Router Advertisement, 532 that the host receives from any of its sub-interfaces part of the 533 logical interface, will be associated with the logical interface, 534 i.e., in some implementations the packet will appear on the input 535 interface of the logical interface. 537 o When using Stateless Address Autoconfiguraion [RFC4862] for 538 generating IPv6 address configuration on the logical interface, 539 the host may use any of the IPv6 prefixes received from the Router 540 Advertisement messages that it received from any of its sub- 541 interfaces. 543 o The response to a Neighbor Discovery message received for a 544 unicast, link-specific multicast group address, will be sent on 545 the same sub-interface path where the packet was received. 547 o When using DHCPv4 [RFC2131] for obtaining address configuration 548 for the logical interface, the value in the chaddr field in the 549 DHCP messages will be based on the link-layer identifier scheme 550 chosen by the logical interface. 552 5.6. Provisioning Domain Considerations 554 The considerations related to the support of multiple provisioning 555 domains in a multi-interface host is documented in [RFC6418]. These 556 considerations specifically focus on the aspects related to DNS 557 configuration. However, from the perspective of logical interface 558 support, these considerations are not applicable, as the logical 559 interface support is relevant only for a single provisioning domain. 560 The key motivation for logical interface support is inter-technology 561 handovers and the handovers are always in the context of a single 562 provisioning domain. 564 5.7. Logical Interface Forwarding Conceptual Data Structures 566 The logical interface maintains the list of sub-interfaces that are 567 part of the logical interface. This conceptual data strucure is 568 called as the LIF Table. The logical interface also maintains the 569 list of flows associated with a given sub-interface and this 570 conceptual data structure is called as the PIF Table. Both of these 571 data structures have to be associated with a logical interface, and 572 are depicted in Figure 4 574 LIF TABLE FLOW table 575 +===============================+ +=============================+ 576 | PIF_ID | FLOW RoutingPolicies | | FLOW ID | Physical_Intf_Id | 577 | | Home Network Prefix | +-----------------------------+ 578 | | Link Layer Address | | FLOW_ID | Physical_Intf_Id | 579 | | Status | +=============================+ 580 +-------------------------------| 581 | PIF_ID | FLOW RoutingPolicies | 582 | | Home Network Prefix | 583 | | Link Layer Address | 584 | | Status | 585 +-------------------------------+ 586 | .... | .... | 587 +===============================+ 588 Figure 4 590 The LIF table maintains the mapping between the LIF and each PIF 591 associated to the LIF (refer to property #3, Figure 3). For each PIF 592 entry the table should store the associated Routing Policies, the 593 Home Network Prefix received in Router Advertisement, the configured 594 link layer Address (as described above) and the Status of the PIF 595 (e.g. active, not active). The method by which the Routing Policies 596 are configured on the host is out of scope for this document. 598 The FLOW table allows the logical interface to properly route each IP 599 flow over the right interface. The logical interface can identify 600 the flows arriving on its sub-interfaces and associate them to those 601 sub-interfaces. This approach is similar to reflective QoS performed 602 by the IP routers. For locally generated traffic (e.g. unicast 603 flows), the logical interface should perform interface selection 604 based on the Flow Routing Policies. In case traffic of an existing 605 flow is suddenly received from the network on a different sub- 606 interface than the one locally stored, the logical interface should 607 interpret the event as an explicit flow mobility trigger from the 608 network and it should update the PIF_ID parameter in the FLOW table. 609 Similarly, locally generated events from the sub-interfaces, or 610 configuration updates to the local policy rules can cause updates to 611 the table and hence trigger flow mobility. 613 6. Logical Interface Use-cases in Proxy Mobile IPv6 615 This section explains how the Logical interface support on the mobile 616 node can be used for enabling some of the Proxy Mobile IPv6 protocol 617 features. 619 6.1. Multihoming Support 621 A mobile node with multiple interfaces can attach simultaneously to 622 the Proxy Mobile IPv6 domain. Each of the attachment links are 623 assigned a unique set of IPv6 prefixes. If the host is configured to 624 use Logical interface over the physical interface through which it is 625 attached, following are the related considerations. 627 LMA Binding Table 628 +================================+ 629 +----+ | HNP MN-ID CoA ATT LL-ID | 630 |LMA | +================================+ 631 +----+ | HNP-1 MN-1 PCoA-1 5 ZZZ | 632 //\\ | HNP-2 MN-1 PCoA-2 4 ZZZ | 633 +---------//--\\-----------+ 634 ( // \\ ) 635 ( // \\ ) 636 +------//--------\\--------+ 637 // \\ 638 PCoA-1 // \\ PCoA-2 639 +----+ +----+ 640 (WLAN) |MAG1| |MAG2| (WiMAX) 641 +----+ +----+ 642 \ / 643 \ / 644 HNP-1 \ / HNP-2 645 \ / 646 \ / 647 +-------+ +-------+ 648 | if_1 | | if_2 | 649 |(WLAN) | |(WiMAX)| 650 +-------+-+-------+ 651 | Logical | 652 (LL-ID: ZZZ) | Interface | HNP-1::zzz/128 653 +-----------------| HNP-2::zzz/128 654 | MN | 655 +-----------------+ 657 Figure 5: Multihoming Support 659 o The mobile node detects the advertised prefixes from the MAG1 and 660 MAG2 as the on link prefixes on the link to which the Logical 661 interface is attached. 663 o The mobile node can generate address configuration using stateless 664 auto configuration mode from any of those prefixes. 666 o The applications can be bound to any of the addresses bound to the 667 Logical interface and that is determined based on the source 668 address selection rules. 670 o The host has path awareness for the hosted prefixes based on the 671 received Router Advertisement messages. Any packets with source 672 address generated using HNP_1 will be routed through the interface 673 if_1 and for packets using source address from HNP_2 will be 674 routed through the interface if_2. 676 6.2. Inter-Technology Handoff Support 678 The Proxy Mobile IPv6 protocol enables a mobile node with multiple 679 network interfaces to move between access technologies, but still 680 retaining the same address configuration on its attached interface. 681 The protocol enables a mobile node to achieve address continuity 682 during handoffs. If the host is configured to use Logical interface 683 over the physical interface through which it is attached, following 684 are the related considerations. 686 LMA's Binding Table 687 +================================+ 688 +----+ | HNP MN-ID CoA ATT LL-ID | 689 |LMA | +================================+ 690 +----+ | HNP-1 MN-1 PCoA-1 5 ZZZ | 691 //\\ (pCoA-2)(4) <-change 692 +---------//--\\-----------+ 693 ( // \\ ) 694 ( // \\ ) 695 +------//--------\\--------+ 696 // \\ 697 PCoA-1 // \\ PCoA-2 698 +----+ +----+ 699 (WLAN) |MAG1| |MAG2| (WiMAX) 700 +----+ +----+ 701 \ / 702 \ Handoff / 703 \ ----> / HNP-1 704 \ / 705 \ / 706 +-------+ +-------+ 707 | if_1 | | if_2 | 708 |(WLAN) | |(WiMAX)| 709 +-------+-+-------+ 710 | Logical | 711 (LL-ID: ZZZ) | Interface | HNP-1::zzz/128 712 +-----------------| 713 | MN | 714 +-----------------+ 716 Figure 6: Inter-Technology Handoff Support 718 o When the mobile node performs an handoff between if_1 and if_2, 719 the change will not be visible to the applications of the mobile 720 node. It will continue to receive Router Advertisements from the 721 network, but from a different sub-interface path. 723 o The protocol signaling between the network elements will ensure 724 the local mobility anchor will switch the forwarding for the 725 advertised prefix set from MAG1 to MAG2. 727 o The MAG2 will host the prefix on the attached link and will 728 include the home network prefixes in the Router Advertisements 729 that it sends on the link. 731 6.3. Flow Mobility Support 733 For supporting flow mobility support, there is a need to support 734 vertical handoff scenarios such as transferring a subset of 735 prefix(es) (hence the flows associated to it/them) from one interface 736 to another. The mobile node can support this scenario by using the 737 Logical interface support. This scenario is similar to the Inter- 738 technology handoff scenario defined in Section 6.2, only a subset of 739 the prefixes are moved between interfaces. 741 Additionally, IP flow mobility in general initiates when the LMA 742 decides to move a particular flow from its default path to a 743 different one. The LMA can decide on which is the best MAG that 744 should be used to forward a particular flow when the flow is 745 initiated e.g. based on application policy profiles) and/or during 746 the lifetime of the flow upon receiving a network-based or a mobile- 747 based trigger. 749 As an example of mobile-based triggers, the LMA could receive input 750 (e.g.by means of a layer 2.5 function via L3 signaling [RFC5677]) 751 from the MN detecting changes in the mobile wireless environment 752 (e.g. weak radio signal, new network detected, etc.). Upon receiving 753 these triggers, the LMA can initiate the flow mobility procedures. 754 For instance, when the mobile node only supports single-radio 755 operation (i.e. one radio transmitting at a time), only sequential 756 (i.e. not simultaneous) attachment to different MAGs over different 757 media is possible. In this case layer 2.5 signaling can be used to 758 perform the inter-access technology handover and communicate to the 759 LMA the desired target access technology, MN-ID, Flow-ID and prefix. 761 7. IANA Considerations 763 This specification does not require any IANA Actions. 765 8. Security Considerations 767 This specification explains the operational details of Logical 768 interface on an IP host. The Logical Interface implementation on the 769 host is not visible to the network and does not require any special 770 security considerations. 772 9. Authors 774 This document reflects contributions from the following authors 775 (listed in alphabetical order): 777 Carlos Jesus Bernardos Cano 779 cjbc@it.uc3m.es 781 Antonio De la Oliva 783 aoliva@it.uc3m.es 785 Yong-Geun Hong 787 yonggeun.hong@gmail.com 789 Kent Leung 791 kleung@cisco.com 793 Tran Minh Trung 795 trungtm2909@gmail.com 797 Hidetoshi Yokota 799 yokota@kddilabs.jp 801 Juan Carlos Zuniga 803 JuanCarlos.Zuniga@InterDigital.com 805 10. Acknowledgements 807 The authors would like to acknowledge prior discussions on this topic 808 in NETLMM and NETEXT working groups. The authors would also like to 809 thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj Patil, 810 Peter McCann, and Julien Laganier for all the discussions on this 811 topic. 813 11. References 814 11.1. Normative References 816 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 817 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 818 September 2007. 820 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 821 Address Autoconfiguration", RFC 4862, September 2007. 823 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 824 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 826 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 827 Mobile IPv6", RFC 5844, May 2010. 829 11.2. Informative References 831 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 832 RFC 2131, March 1997. 834 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 835 Internet Protocol", RFC 4301, December 2005. 837 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 838 PPP", RFC 5072, September 2007. 840 [RFC5677] Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, 841 "IEEE 802.21 Mobility Services Framework Design (MSFD)", 842 RFC 5677, December 2009. 844 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 845 "Address Mapping of IPv6 Multicast Packets on Ethernet", 846 RFC 6085, January 2011. 848 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 849 in IPv6", RFC 6275, July 2011. 851 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 852 Provisioning Domains Problem Statement", RFC 6418, 853 November 2011. 855 [TS23401] "3rd Generation Partnership Project; Technical 856 Specification Group Services and System Aspects; General 857 Packet Radio Service (GPRS) enhancements for Evolved 858 Universal Terrestrial Radio Access Network (E-UTRAN) 859 access.", 2009. 861 Authors' Addresses 863 Telemaco Melia (editor) 864 Alcatel-Lucent 865 Route de Villejust 866 Nozay 91620 867 France 869 Email: telemaco.melia@alcatel-lucent.com 871 Sri Gundavelli (editor) 872 Cisco 873 170 West Tasman Drive 874 San Jose, CA 95134 875 USA 877 Email: sgundave@cisco.com