NETEXT Working Group C. Bernardos Internet-Draft UC3M Intended status: Experimental T. Melia Expires: April 29, 2010 Alcatel-Lucent Bell Labs P. Seite France Telecom J. Korhonen Nokia Siemens Networks October 26, 2009 Multihoming extensions for Proxy Mobile IPv6 draft-bernardos-mif-pmip-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Bernardos, et al. Expires April 29, 2010 [Page 1] Internet-Draft PMIPv6 multihoming October 2009 Abstract The IETF standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. PMIPv6 also provides limited multi- homing support to multi-mode mobile devices. The IETF is working on optimizations for PMIPv6. While multi-homing item has been proposed to be part of the approved work, discussions showed there are still many controversial issues to be addressed (i.e. the no-host modification theorem). This document explores solutions for the multi-homing use case aiming at helping PMIPv6 development where possible. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Bernardos, et al. Expires April 29, 2010 [Page 2] Internet-Draft PMIPv6 multihoming October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. MIF scope and PMIPv6 . . . . . . . . . . . . . . . . . . . . . 5 3. A use case . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Considerations on feasibility and approach overview . . . . . 7 4.1. MN considerations . . . . . . . . . . . . . . . . . . . . 8 4.2. LMA considerations . . . . . . . . . . . . . . . . . . . . 9 4.3. MAG considerations . . . . . . . . . . . . . . . . . . . . 9 4.4. Downlink and Uplink considerations . . . . . . . . . . . . 10 4.5. IPv4 considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Bernardos, et al. Expires April 29, 2010 [Page 3] Internet-Draft PMIPv6 multihoming October 2009 1. Introduction Proxy Mobile IPv6 (PMIPv6), specified in RFC 5213 [RFC5213] and [I-D.ietf-netlmm-pmip6-ipv4-support], provides network based mobility management to hosts connecting to a PMIPv6 domain. PMIPv6 introduces two new functional entities, the Local Mobility Anchor (LMA) and the Mobility Access Gateway (MAG). The MAG is the first layer three hop detecting Mobile Node (MN) attachment and providing IP connectivity. The LMA is the entity assigning one or more Home Network Prefixes (HNPs) and zero or one IPv4 Home Address (IPv4-MN-HoA)to the MN and is the topological anchor for all traffic from/to the MN. PMIPv6 allows an MN to connect to the same PMIPv6 domain through different interfaces. ID [I-D.devarapalli-netext-multi-interface-support] identifies at least three possible scenarios, namely i) unique prefix per interface, ii) same prefix but different global addresses per interface, iii) shared address across multiple interfaces. The ID further describes issues associated with each scenario. The first two scenarios are similar, and bring similar issues, whereas the third one is more complex to tackle, since it requires to deal with the sharing of the same IP address across different interfaces. This document focuses on the two first scenarios, as depicted in Figure 1. However, if [RFC1918] defined private IPv4 addresses are used as IPv4 Home Addresses, the scenario iii) may happen implicitly. Unless the LMA coordinates private IPv4 Home Addresses across different access technologies and mobility session, then there is a possibility that the same private IPv4 Home Address would be assigned to both if1 and if2 of the MN. Bernardos, et al. Expires April 29, 2010 [Page 4] Internet-Draft PMIPv6 multihoming October 2009 LMA Binding Cache +----+ ----------------- |LMA | MN:if1 [prefix1 or addr1] --> MAG1 +----+ MN:if2 [prefix2 or addr1] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | if1 if2 | +------[MN]------+ Figure 1: Unique prefix and Unique address per Interface scenarios The fact is that many (client) hosts currently have the ability to attach to multiple networks simultaneously, and that implies benefits (e.g., enables load balancing, improved connectivity, higher throughput and better reliability, etc.), but also brings some operation issues (e.g., default router selection, address selection, DNS server selection, choice of interface for packet transmission, the treatment of configuration information received from the various networks, etc.). Configuration decisions about how to deal with the different information from each of the interface might have a very strong impact on the connectivity experienced by a node with multiple network interfaces (from now on we refer a node with multiple network interfaces as a MIF node). In the context of PMIPv6, current specification [RFC5213] does not address the case of a MIF node attaching to a PMIPv6 domain other than stating it is possible. We argue it is important to enable PMIPv6 to bring MIF nodes the advantages related to the simultaneous use of multiple interfaces. Moreover a MIF node could be seen as a not-modified host implementing the right technology for multi- interface handling. 2. MIF scope and PMIPv6 Current scope of MIF nodes as described in [I-D.ietf-mif-problem-statement] only covers the issues of host attaching to multiple networks. The current work is focused on Bernardos, et al. Expires April 29, 2010 [Page 5] Internet-Draft PMIPv6 multihoming October 2009 documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice, both for IPv4 and IPv6. While [I-D.ietf-mif-problem-statement]is not addressing any (neither flow nor host nor network) mobility, a MIF node might find itself connected to a PMIPv6 domain. PMIPv6 should be extended to efficiently support MIF nodes attaching to a PMIPv6 domain, enabling features such as the ones identified in [I-D.jeyatharan-netext-multihoming-ps], e.g., dynamic mobility sessions between different interfaces, allowing traffic to be forwarded to any of the interfaces of a MIF node, not only to the one configured with the destination prefix/address of that traffic). 3. A use case This section describes a simple use case of a MIF node in a PMIPv6 domain, as an example of a situation where PMIPv6 needs to be extended. +-----+ | CN1 | +-----+ | LMA Binding Cache | ===================== | MN:if1, pref1, MAG1 +-----+ +-----+ :if2, pref2, MAG2 | CN2 |--------| LMA | +-----+ +-----+ //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | if1 if2 | +-------[MN]------+ (WLAN) (3G) Figure 2: Use case Bernardos, et al. Expires April 29, 2010 [Page 6] Internet-Draft PMIPv6 multihoming October 2009 Figure 2 shows a potential use case of interest involving an MIF mobile node attached to a PMIPv6 domain. The MN is attached to MAG1 through its WLAN interface (if1), and to MAG2 through its 3G interface (if2). Lets consider the case in which each interface has been assigned a different prefix by the LMA (for the sake of simplicity we have left the IPv4 case out of this example). Two different mobility bindings are created in the LMA referring to the MN. In this scenario, if the MN decides to move if1 from MAG1 to a different MAG of the same domain, the PMIPv6 support would take care of ensuring that the same prefix (pref1) is assigned at the new MAG (we assume that there is an L2 identifier for if1 that the new MAG can include in the PBU). Lets assume for the sake of this example that the MN starts a communication with CN1, using as source IPv6 address (pref1::if1) the one assigned to its WLAN interface (if1), and that it also starts a different communication with CN2, using as source IPv6 address (pref2::if2) the one assigned to its 3G interface (if2). In this scenario, it would be useful to enable the MN be able to receive traffic addressed to pref1::if1 via if2 and vice versa. However, current PMIPv6 specification does not support this. Analogously, it would be also useful to allow the MN send traffic with source address pref1::if1 through if2 and vice versa. We argue in the next section that PMIPv6 could benefit from MIF outcomes to support the previous scenario while limiting impact on the LMA and MAG operation. 4. Considerations on feasibility and approach overview We analyse in the next sections the feasibility of the scenario presented in Section 3, by identifying the requirements and changes that would be needed in PMIPv6 to support it. In this version of the document we do not specify with all the required details the solution, but rather concentrate on the concept, with the goal of triggering the discussion within the IETF. Figure 3 shows in a glimpse the extensions to PMIPv6 required to support the MIF example scenario shown in Section 3. Bernardos, et al. Expires April 29, 2010 [Page 7] Internet-Draft PMIPv6 multihoming October 2009 +-----+ | CN1 | +-----+ | LMA Binding Cache LMA policy/routing table | ===================== ============================ | MN:if1, pref1, MAG1 flow1(CN1,MN[pref1])->MAG2 +-----+ +-----+ :if2, pref2, MAG2 flow2(CN1,MN[pref2])->MAG2 | CN2 |-----| LMA | ... +-----+ +-----+ flowN(CN2,MN[pref1])->MAG1 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG2 routing table +----+ +----+ ================================ |MAG1| |MAG2| (dest) (next hop) +----+ +----+ pref2::/64 directly connected | | pref1::/64 directly connected | | | if1 if2 | +-------[MN]------+ MN implements the weak host model (WLAN) (3G) Figure 3: Solution overview 4.1. MN considerations In order to support the reception of traffic addressed to pref1::if1 at the interface if2, the MN MUST follow the Weak host model [RFC1122], [I-D.thaler-ip-model-evolution]. This model does not limit traffic reception at a host only to IP packets whose destination address matches the IP address assigned to the interface receiving the packets, but allows to receive and process packets whose IP destination address corresponds to that of any of the local interfaces of the host. By implementing the Weak host model, the MN in Figure 3 would be able to process traffic addressed to any of its IP addresses (i.e., pref1::if1 and pref2::if2), no matter to which interface that traffic arrives to. We have performed some tests with different operating systems, and the results show that both Linux (tested with Linux-2.6.26) and Mac OS X (tested with Leopard) implements the Weak host model for both IPv4 and IPv6 traffic. We have not performed tests with Windows, but some results have been reported in [I-D.ietf-mif-current-practices]. Bernardos, et al. Expires April 29, 2010 [Page 8] Internet-Draft PMIPv6 multihoming October 2009 It should be noted that Windows XP and Windows Server 2003 use the weak host model for sends and receives for all IPv4 interfaces and the strong host model for sends and receives for all IPv6 interfaces. This behavior cannot be modified. The Next Generation TCP/IP stack in Windows Vista and Windows Server 2008 supports strong host sends and receives for both IPv4 and IPv6 by default on all interfaces. The stack can be configured to use weak host model. Generally it should be possible to enable automatic configuration of the weak model during network attachment/entry according to policies configured in the operator's network. Signaling exchanged between the MAG and the LMA (PUB, PBA) needs to be extended to configure the MN (via RS/RA or DHCP) to use the weak host model on a specific interface. As an example according to RFC 5175 [RFC5175] a bit can be assigned in the RA message indicating such option. The access provider could then decide to configure the MAGs to advertise the MN for weak model configuration. Obviously, understanding a new RA/RS bit or a DHCP option would require new functionality in the MN`s IP stack, or at minimum some kind of a networking configuration manager running in a MIF node. 4.2. LMA considerations The LMA MUST be able to identify all the mobility bindings at its Binding Cache (BC) that refer to the same MN, using the MN- identifier. The LMA SHOULD have an additional policy/routing table. This table is used by the LMA to store and look up information about how to route packets to a certain MN. With current PMIPv6 specification, the LMA decides on the next hop towards a particular MN based only on the destination prefix (that would result on an outgoing tunnel interface to reach the MAG where that prefix is currently reachable). In order to allow the LMA to dynamically decide which is the best path for a certain traffic to reach the MN, a policy/routing table SHOULD be used. By using this table, the LMA would be able to send different flows addressed to the same destination IP address (e.g. pref1::if1) via different MAGs. 4.3. MAG considerations The MAG MUST support routing packets addressed to MNs locally attached to the MAG, but using a destination prefix or address that is not on-link. In order to do that, the MAG SHOULD be informed by the LMA about the set of IP addresses that the MN has acquired from the PMIPv6 domain, so the MAG can add the required entries on its routing table. The PBA MAY be extended to include such information. The prefixes advertised in the Router Advertisement (RA) sent from the MAG to the MN include only those that would be advertised in case of base RFC 5213 operation without any flow/policy routing Bernardos, et al. Expires April 29, 2010 [Page 9] Internet-Draft PMIPv6 multihoming October 2009 extensions. 4.4. Downlink and Uplink considerations The extensions outlined in this document would allow an MN to simultaneously receive traffic through all of its interfaces that are attached to the same PMIPv6 domain. Enabling such a feature in the Downlink (DL) makes sense when several access networks are available at the same time, as for example in heterogeneous PMIPv6 domains where several access technologies exhibiting different DL capacities are found (e.g., WLAN and 3G). Enabling the feature on the Uplink (UL) is also possible. Enabling the network (i.e., the LMA) to have the control on which MN's outgoing interface it used for a certain flow requires changes on the MN side, as well as signaling on the MN-AR interface or configuring explicit routes on the MN using existing host configuration protocols at IP level (e.g. DHCP). Nevertheless, if the decision is on the MN side, this might be easily supported by the solution outlined in this document, by properly configuring the routing and ingress filtering at the MAGs. The mapping of a flow to an interface may be driven by the terminal, the LMA or both: 1. driven by the terminal: the terminal establishes the policy and selects the interface to send packets. The LMA must be aware of the flow/interface mapping policy to keep consistency in routing (the terminal would expect receiving traffic on a specific interface). So the terminal may provide its policy to the LMA. 2. driven by the LMA: the LMA have the control on which MN's outgoing interface is used for a certain flow. In such a case the MN's routing table is updated according to the policy which must be provided to the MN by the LMA. 3. MN driven but assisted by the LMA: the terminal controls the mapping of the flows to the possible interfaces. However the LMA provides some default policies which can be updated by the MN. The policies must be exchanged in both directions (from LMA to MN and vice versa). 4.5. IPv4 considerations IPv4 Home Addresses work mostly in a similar manner as IPv6 HNPs in the context of PMIPv6 and MIF nodes. Though, a MIF node may by default apply a different host model depending on the IP version. Bernardos, et al. Expires April 29, 2010 [Page 10] Internet-Draft PMIPv6 multihoming October 2009 One problem with IPv4 Home Addresses is the possible use of private IPv4 addresses [RFC1918]. It is possible for a MIF node to configure overlapping public IPv4 Addresses on multiple interfaces. This is not a new issue as it has been possible since the introduction of [RFC1918] and any multi-homed IPv4 node. Still, the host operation is not generally clearly defined in case of multiple overlapping addresses. The only common advice is to avoid overlapping [RFC1918] private IPv4 Home Addresses within PMIPv6 domain, unless the MIF nodes are known to be able to handle such situation gracefully. This situation resembles the scenario iii) of [I-D.devarapalli-netext-multi-interface-support] and therefore is out of scope of this document. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations None. 7. Acknowledgements The authors would like to thank Paulo Ferrer and Marco Liebsch for their comments and discussion on this document. The research of Carlos J. Bernardos leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN project) and also from the Ministry of Science and Innovation of Spain, under the QUARTET project (TIN2009-13992-C02-01). 8. References 8.1. Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Bernardos, et al. Expires April 29, 2010 [Page 11] Internet-Draft PMIPv6 multihoming October 2009 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement Flags Option", RFC 5175, March 2008. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 8.2. Informative References [I-D.devarapalli-netext-multi-interface-support] Devarapalli, V., Kant, N., Lim, H., and C. Vogt, "Multiple Interface Support with Proxy Mobile IPv6", draft-devarapalli-netext-multi-interface-support-00 (work in progress), March 2009. [I-D.ietf-mif-current-practices] Wasserman, M., "Current Practices for Multiple Interface Hosts", draft-ietf-mif-current-practices-00 (work in progress), October 2009. [I-D.ietf-mif-problem-statement] Blanchet, M. and P. Seite, "Multiple Interfaces Problem Statement", draft-ietf-mif-problem-statement-01 (work in progress), October 2009. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 (work in progress), September 2009. [I-D.jeyatharan-netext-multihoming-ps] Jeyatharan, M. and C. Ng, "Multihoming Problem Statement in NetLMM", draft-jeyatharan-netext-multihoming-ps-01 (work in progress), March 2009. [I-D.thaler-ip-model-evolution] Thaler, D., "Evolution of the IP Model", draft-thaler-ip-model-evolution-01 (work in progress), July 2008. Bernardos, et al. Expires April 29, 2010 [Page 12] Internet-Draft PMIPv6 multihoming October 2009 Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Telemaco Melia Alcatel-Lucent Bell Labs Email: Telemaco.Melia@alcatel-lucent.com Pierrick Seite France Telecom Email: pierrick.seite@orange-ftgroup.com Jouni Korhonen Nokia Siemens Networks Email: jouni.korhonen@nsn.com Bernardos, et al. Expires April 29, 2010 [Page 13]