idnits 2.17.00 (12 Aug 2021) /tmp/idnits62736/draft-zuniga-mif-lif-implementation-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.draft-ietf-netext-logical-interface-support]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4226 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3810' is mentioned on line 117, but not defined == Unused Reference: 'I-D.draft-seite-mif-connection-manager' is defined on line 329, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-netext-logical-interface-support has been published as RFC 7847 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIF Working Group JC.Zuniga 2 Internet Draft InterDigital Communications, LLC 3 Intended status: Best Current Practice T.Melia 4 Expires: April 18, 2011 Alcatel-Lucent 5 October 18, 2010 7 Logical Interface (LIF) Implementation Guidelines 8 draft-zuniga-mif-lif-implementation-guidelines-00.txt 10 Abstract 12 A Logical Interface is a software module internal to the host that is 13 available in all popular operating systems. The use of this Logical 14 Interface allows supporting different network-based mobility 15 management solutions. In the NETEXT WG, work has been carried out to 16 define ways in which a Logical Interface can help IP flow mobility 17 (IFOM) for Proxy Mobile IPv6 [I-D.draft-ietf-netext-logical- 18 interface-support]. The same Logical Interface construct can help 19 other mobility management solutions like 3GPP GPRS Tunnelling 20 Protocol (GTP), and it can add benefits to multi-access scenarios 21 such as 3GPP Multi Access PDN Connectivity (MAPCON). This document 22 provides guidelines for the implementation and configuration of a 23 generic Logical Interface. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on April 18, 2011. 48 Copyright Notice 50 Copyright (c) 2010 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the BSD License. 63 Table of Contents 65 1. Introduction...................................................2 66 2. Conventions and Terminology....................................3 67 3. Logical Interface (LIF)........................................3 68 3.1. Description...............................................3 69 3.1.1. Usage in PMIPv6......................................4 70 3.1.2. Usage in GTP.........................................4 71 3.1.3. Usage in MAPCON......................................5 72 3.2. Implementation Guidelines.................................6 73 3.2.1. Policy management....................................6 74 3.2.2. Interface configuration..............................6 75 3.2.3. Flow mapping.........................................6 76 4. Security Considerations........................................7 77 5. IANA Considerations............................................7 78 6. References.....................................................7 79 6.1. Normative References......................................7 80 6.2. Informative References....................................7 81 7. Acknowledgments................................................8 82 Authors' Addresses................................................8 84 1. Introduction 86 A Logical Interface (LIF) is a construct internal to the operating 87 system. It is an approach where the link-layer implementation hides 88 the physical interfaces from the IP stack in the host. The IP stack 89 can bind one or many IPv4 and/or IPv6 addresses onto this interface. 91 The basic LIF function is widely available in all popular operating 92 systems. Many applications such as Mobile IP client [RFC3775], IPsec 93 VPN client [RFC4301] and L2TP client [RFC3931] rely on this semantic 94 for their protocol implementation. 96 This basic LIF functionality can be expanded for achieving more 97 advanced mobility features. For instance, in the NETEXT WG work has 98 been carried out to define requirements on this Logical Interface to 99 support IP flow mobility (IFOM) for Proxy Mobile IPv6 [I-D.draft- 100 ietf-netext-logical-interface-support]. Beyond Proxy Mobile IPv6, the 101 use of a LIF can also help supporting IP flow mobility for 3GPP GPRS 102 Tunnelling Protocol (GTP), and similarly it can add benefits to other 103 multi-access scenarios such as 3GPP Multi Access PDN Connectivity 104 (MAPCON) [TD S2-103593]. 106 This document describes the guidelines to implement and configure a 107 generic LIF module to enable the aforementioned mobility and multi- 108 access features. 110 2. Conventions and Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 This document uses the terminology defined in [RFC5213], [RFC3775], 117 and [RFC3810]. 119 3. Logical Interface (LIF) 121 3.1. Description 123 The LIF is a software construct that presents itself to higher layers 124 (i.e. IP) as a normal single interface. However, instead of providing 125 access to a single physical or network interface (i.e. NIC), it can 126 bond one or several network interfaces. As a result, an IP layer that 127 binds to a single LIF will potentially encompass access to several 128 physical interfaces. The actual specific data packet delivery to the 129 different network interfaces is fully controlled by the LIF and it is 130 also hidden to the IP layer. 132 For some implementations, the LIF is known as the master, and the 133 different sub-interfaces that are bonded below it are referred to as 134 slaves. In most cases, the LIF will bond several physical network 135 interfaces. Nevertheless, virtual interfaces (e.g. VPN) can also be 136 treated as slaves and be bonded by the LIF. 138 Although the main purpose of the available LIF modules is to provide 139 for link aggregation and redundancy, it has been shown that some of 140 the LIF functionalities can be expanded to support more advanced 141 features, like multi-access handovers and IP flow mobility. 143 3.1.1. Usage in PMIPv6 145 Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving 146 the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the 147 Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the 148 network and performs the mobility management on behalf of the Mobile 149 Node (MN) or IP host. The Local Mobility Anchor (LMA) is the home 150 agent for the MN and the topological anchor point. 152 At present, there is work going on in the NETEXT working group to 153 extend the basic PMIPv6 functionality to support inter-access 154 handovers and IP flow mobility [I-D.draft-bernardos-netext-pmipv6- 155 flowmob-00]. As part of this work, the LIF has been identified as a 156 critical element in the MN required to support these IP flow mobility 157 and inter-access handover features. A basic set of LIF 158 functionalities has been identified in the group to support multi- 159 homing, inter-technology handovers and IP flow mobility in a Proxy 160 Mobile IPv6 network [I-D.draft-ietf-netext-logical-interface- 161 support]. 163 3.1.2. Usage in GTP 165 Another network-based mobility approach proposed in 3GPP is based on 166 the GPRS Tunnelling protocol (GTP) [TS 23.402]. Similarly to the 167 PMIPv6 architecture, the PDN-GW behaves as a single anchor point and 168 the Serving Gateway and ePDG perform the attachment functions on 169 behalf of the MN. 171 Since GTP tunnels between the gateways and the anchor are transparent 172 to the mobile, the LIF at the MN can perform the exact same actions 173 on traffic flows regardless of the network-based mobility solution. 174 This means that a LIF configured to support the PMIPv6 case can also 175 support the GTP scenario without any modifications. 177 +----------------------------+ 178 | TCP/UDP | 179 Session to IP --| | 180 Address binding < +----------------------------+ 181 --| IP | 182 IP Address(es) ---| | 183 binding < +----------(MN-HoA)----------+ 184 ---| Logical Interface | 185 Logical to | | 186 Physical --> +----------------------------+ 187 Interface | L2 | L2 | | L2 | 188 bonding |(IF#1)|(IF#2)| ..... |(IF#n)| 189 +------+------+ +------+ 190 | L1 | L1 | | L1 | 191 | | | | | 192 +------+------+ +------+ 194 Figure 3: LIF for Proxy Mobile IPv6 / 3GPP GTP 196 3.1.3. Usage in MAPCON 198 MAPCON is a 3GPP technology and refers to the capability of the 199 Evolved Packet Core (EPC)network to configure and maintain two or 200 more PDN connections for a given mobile device across heterogeneous 201 wireless access networks. According to 3GPP, a one to one mapping 202 exists between a PDN connection and an APN. That is, every time that 203 a UE requests to activate a specific APN (either resolved to the same 204 P-GW or to different P-GWs) the network assigns a new IP address (v4, 205 v6 or v4v6). This APN (or IP address) can be configured on a 3GPP 206 network at time T0 and moved at time T1 to the WLAN network. It 207 derives that all the sessions associated to this IP address (alias 208 Home Network Prefix) are handed over from the 3GPP to the non 3GPP 209 access network. If the UE has configured two different APNs on the 210 3GPP access network, after the handover procedure takes place it will 211 continue to use one APN for each wireless channel. 213 In a 3GPP context and from an application perspective, the selection 214 of an IP address corresponds to map a specific application to a given 215 APN. In the IETF world the APN concept does not exists and IP address 216 selection has been studied in [RFC3484] and [RFC5014]. In particular 217 [RFC5014] provides socket API extensions to influence the rules 218 specified in [RFC3484] (e.g. prefer a public IPv4 address over a 219 private one, prefer a HoA over a CoA). However, such extensions do 220 not consider the particular requirements imposed by 3GPP. 222 The use of the LIF in the context of the MAPCON scenario simplifies 223 the operations executed at the mobile device. The routing of flows to 224 interfaces is achieved by means of the policies in the LIF layer and 225 not according to the IP address destination. In this sense the 226 routing operations at the MN are extremely simplified with respect to 227 the extensive use of multiple interfaces and advance routing 228 capabilities. The granularity for routing can for instance be based 229 on prefixes or flows, providing great flexibility to the LIF 230 implementation and associated CM operations. 232 3.2. Implementation Guidelines 234 3.2.1. Policy management 236 LIF policies can be either pre-configured or dynamically configured 237 on a host through some external protocol or function (e.g. OMA DM, 238 IEEE 802.21 IS, etc). Normally, these policies MAY be configured and 239 enforced onto the LIF by a Connection Manager (CM) [I-D.draft-seite- 240 mif-connection-manager]. The CM SHOULD be in charge of managing the 241 different sets of policies and enforcing them in a coherent manner. 243 The mapping between physical and virtual network interfaces and the 244 LIF SHOULD first follow the appropriate network-based policies and 245 then the user-based policies. In this manner, network-based features 246 such as IFOM can be supported. 248 3.2.2. Interface configuration 250 A LIF MUST accept packets arriving on any of its sub-interfaces, as 251 long as the destination IP address is a valid local address. 253 The LIF CAN by default bond all available sub-interfaces. However, if 254 a policy is defined where only some interfaces are considered, for 255 instance for IFOM purposes, the LIF SHOULD only bond the sub- 256 interfaces defined in the policy. 258 When the link layer technology of the sub-interface encapsulates IP 259 packets into frames, the link-layer identifier of the LIF SHOULD be 260 used in the link-layer header of frames transmitted over this sub- 261 interface. 263 3.2.3. Flow mapping 265 In order for the LIF to support IFOM, independent flows need to be 266 monitored at the LIF. Flows can be identified by a 5-tuple comprised 267 of source address, destination address, source port, destination port 268 and protocol. Once a flow is identified, it is mapped to the sub- 269 interface that has first been used to perform the packet transmission 270 and reception functions for this specific flow. This mapping SHOULD 271 be kept for the lifespan of the flow (e.g. TCP session). 273 For IPv6, the LIF MUST be aware of the hosted prefixes based on the 274 received Router Advertisement (RA) messages. For instance, provided 275 that RAs HNP1 are received on interface if1, any packet with source 276 address generated using HNP1 SHOULD be forwarded through interface 277 if1. 279 In case packets from a certain flow are suddenly received on a 280 different sub-interface, an update to the flow mapping table COULD be 281 done so that the corresponding packets are now forwarded though this 282 new sub-interface. This case is especially needed to support the IFOM 283 as described in [I-D.draft-ietf-netext-logical-interface-support]. 285 4. Security Considerations 287 This draft discusses the operations of existing protocols without 288 modifications. It does not introduce new security threats beyond the 289 current security considerations of PMIPv6 [RFC5213]. 291 5. IANA Considerations 293 This document makes no request of IANA. 295 6. References 297 6.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 6.2. Informative References 304 [RFC3484] Draves, R., "Default Address Selection for Internet 305 Protocol version 6 (IPv6)", RFC 3484, February 2003. 307 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 308 in IPv6", RFC 3775, June 2004. 310 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 311 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 313 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 314 Internet Protocol", RFC 4301, December 2005. 316 [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J. "IPv6 317 Socket API for Source Address Selection", RFC 5014, 318 September 2007. 320 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 321 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 323 [I-D.draft-ietf-netext-logical-interface-support] 325 Melia, T. Ed., Gundavelli, S. Ed., "Logical Interface 326 Support for multi-mode IP Hosts", draft-netext-logical- 327 interface-support-00 (work in progress), August 2010. 329 [I-D.draft-seite-mif-connection-manager] 331 Seite, P., Feige, G. "Connection Manager Requirements", 332 draft-seite-mif-connection-manager-01 (work in progress), 333 July 2010. 335 [TD S2-103593] 337 3GPP TD S2-103593, Cisco, "Virtual Interface Support on UE 338 - Requirements & Properties", 2010. 340 [TS 23.402] 342 3GPP, "3GPP TS 23.402; Architecture enhancements for non- 343 3GPP accesses", 2010. 345 7. Acknowledgments 347 This document was prepared using 2-Word-v2.0.template.dot. 349 Authors' Addresses 351 Juan Carlos Zuniga 352 InterDigital Communications, LLC 353 Email: JuanCarlos.Zuniga@InterDigital.com 355 Telemaco Melia 356 Alcatel-Lucent 357 Email: telemaco.melia@alcatel-lucent.com