Network Working Group B. Sarikaya Internet-Draft Huawei USA Expires: January 13, 2013 July 12, 2012 PMIPv6 Operation on Shared Links draft-sarikaya-netext-pmipv6-shared-link-01 Abstract This document describes Proxy Mobile IPv6 (PMIPv6) operation on shared links such as IEEE 802.11. Two solutions of providing point- to-point link operation on the shared links are compared. Advantages and disadvantages of each solution are identified. Issues related to the placement of Mobile Access Gateway (MAG) in fixed broadband network are also discussed. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 13, 2013. Copyright Notice Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Sarikaya Expires January 13, 2013 [Page 1] Internet-Draft PMIPv6 on WiFi July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Shared Link Operation in IEEE 802.11 Links . . . . . . . . . . 4 4. Problems with PMIPv6 Operation in IEEE 802.11 Links . . . . . 4 5. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Solution 1: RA Mapping . . . . . . . . . . . . . . . . . . . . 6 7. Solution 2: VLAN . . . . . . . . . . . . . . . . . . . . . . . 7 8. Other Issues Related to WLAN Applicability . . . . . . . . . . 7 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 13.2. Informative references . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Sarikaya Expires January 13, 2013 [Page 2] Internet-Draft PMIPv6 on WiFi July 2012 1. Introduction Proxy Mobile IPv6 [RFC5213] is designed to work on point-to-point links. Since mobile networks provide point-to-point links PMIPv6 operation on such networks present no problems. However, recently interest has grown on PMIPv6 operation on IEEE 802.11 links [ieee802.11], a.k.a Wi-Fi links due to the proliferation of smart phones which support both a wide-area wireless link as well as a wireless local area network (WLAN) link. However, 802.11 networks provide a shared link operation. In PMIPv6, the Mobile Access Gateway (MAG) acts as the default router on the point-to-point link shared with the mobile node (MN). PMIPv6 assumes that if it is to operate on a shared link, the link should be configured in such a way that it emulates point-to-point delivery between the mobile node and the mobile access gateway for all the protocol traffic. The protocol traffic that is relevant in this document is multicast packets sent by MAG and MN, i.e. router advertisements and DHCP messages. On a point-to-point link multicast packets are delivered to a single destination. However, on shared links they may be delivered to more than one nodes, i.e. point-to- point delivery may be violated. In a related work, Mobile IPv6 [RFC6275] handover operation in the context of 802.11 access networks is described in [RFC4260]. Several scenarios are identified for Fast Handovers for Mobile IPv6 (FMIPv6), which is Mobile IPv6 handover protocol [RFC5268] to operate on IEEE 802.11 links. Since Mobile IPv6 can work on the shared links, there is no issue in the case of Mobile IPv6 on this aspect. In [RFC5757] 802.11 WLAN operation is described. The focus was placed on the delivery of multicast data packets from and to the mobile nodes. PMIPv6 link operation has not been in the scope. 2. Terminology 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 [RFC2119]. The terminology in this document is based on the definitions in [RFC4291], [RFC2464] and [RFC5213] Sarikaya Expires January 13, 2013 [Page 3] Internet-Draft PMIPv6 on WiFi July 2012 3. Shared Link Operation in IEEE 802.11 Links IEEE modeled 802.11 link operation after the Ethernet including the source and destination addresses. Like on Ethernet, the hosts on the same 802.11 link share a common IPv6 prefix. Multicast addressing is also inherited from the Ethernet IEEE 802 address structure. IEEE 802 addresses are of 48 bits long, i.e. 6 octets. A 16-octet IPv6 multicast address maps to IEEE 802 multicast address as follows: the first two octets are set to the value 3333 hexadecimal to indicate multicast frame and the last four octets are copied from the last four octets of IPv6 multicast address and these last four octets become the multicast group address [RFC2464]. The Interface Address used in IPv6 link local addresses is formed based on the EUI-64 identifier which is derived from 48-bit IEEE 802 address by setting the fourth and fifth octets of the EUI to the fixed value FFFE hexadecimal. EUI-64 has the "Universal/Local" (U/L) bit, which is the next-to-lowest order bit of the first octet. The Solicited-Node multicast address in the range FF02:0:0:0:0:1: FF00:0000 to FF02:0:0:0:0:1:FFFF:FFFF maps to an IEEE 802 multicast address in the range 33-33-FF-00-00-00 to 33-33-FF-FF-FF-FF. 4. Problems with PMIPv6 Operation in IEEE 802.11 Links Proxy Mobile IPv6 Mobile Node in IEEE 802.11 link first forms a link local address with the last 64 bits as the Interface address obtained from the mobile node's Wi-Fi interface IEEE 802 address. 3G interface that most mobile node's have do not have an IEEE 802 address. Mobile node next sends a Router Solicitation message. The source address is either the Interface Address or the unspecified address. Mobile Access Gateway replies with a Router Advertisement message containing home network prefixes assigned to this mobile node. The destination address is the unicast address of the mobile node if the source address of the Router Solicitation is the Interface address. Otherwise the router advertisement is sent to the all-nodes multicast address (FF02::1). Mobile node receives the router advertisement and forms global unicast address(es) using the home network prefix(es) received and starts communication with the corresponding nodes. As more mobile nodes come into the same IEEE 802.11 link and each of them are assigned different sets of home network prefixes the situation arises that on a shared link, there are several hosts each Sarikaya Expires January 13, 2013 [Page 4] Internet-Draft PMIPv6 on WiFi July 2012 assigned to a different prefix. This creates a multi-link subnet [RFC4903] which MUST be avoided. In case the mobile node sends the router solicitation message with the unspecified address as the source address, the mobile access gateway sends the router advertisement to the all-nodes multicast address (FF02::1) which gets converted to IEEE 802 multicast address of 33-33-00-00-00-01. Such a router advertisement message is received by the all mobile nodes on the link. Mobile nodes create unicast global addresses from each prefix they receive from the routers. On a shared link, this creates the situation that multiple hosts have duplicate addresses which MUST be avoided. On a shared link, nodes perform address resolution by multicasting a Neighbor Solicitation that asks the target node to return its link- layer address. This is done by multicasting Neighbor Solicitation message to the solicited-node multicast address of the target address. The target returns its link layer address, i.e. IEEE 802 address in a Neighbor Advertisement message. On an IEEE 802.11 link there could exist a mixture of nodes with some being PMIPv6 mobile nodes. Such Neighbor Solicitation messages will be sent to IEEE 802 multicast address on the solicited-node multicast address range which might be received by more than one nodes, including PMIPv6 mobile nodes. However, PMIPv6 mobile nodes MUST not receive Neighbor Solicitation messages other than the Mobile Access Gateway. 5. Solutions In Section 4 we identified that most of the problems are related to the delivery of multicast packets in IEEE 802.11 links. Control and Provisioning of Wireless Access Points (CAPWAP) Protocol [RFC5416] allows two modes of operation for the Wireless Termination Point (WTP), i.e. the Wi-Fi Access Points (AP): split MAC or local MAC. In split MAC operation, the Distribution and Integration services reside on the Access Controller (AC), and therefore all user data is tunneled between the WTP and the AC. Mobile Access Gateway of PMIPv6 would be located at the AC. Split MAC operation of CAPWAP protocol would create a point-to-point link between the mobile nodes and the Mobile Access Gateway. Therefore it can be thought of as a solution. However, if Local MAC operation is used, the problems persist. We next describe two solutions to the problems: [RFC6085] provides a solution in this direction. The idea is to modify the destination address and make it a unicast address. The other solution is Virtual Sarikaya Expires January 13, 2013 [Page 5] Internet-Draft PMIPv6 on WiFi July 2012 LAN based. 6. Solution 1: RA Mapping [RFC2464], specifies the delivery of an IPv6 packet with a multicast destination address by simply mapping the destination address into an Ethernet link-layer multicast address. Multicast delivery is taken care of by IEEE 802.11 procedures. When it is clear that only one address is relevant, [RFC6085] allows for a mapping of such a destination address into an IEEE 802 link-layer unicast address. Subsequent delivery of the Ethernet frame should be to a single node on the IEEE 802.11 link. One example is the delivery of the Router Advertisement message to PMIPv6 mobile nodes. If the router advertisement message's destination address is IEEE 802 multicast address of 33-33-00-00-00-01, this address can be mapped to the IEEE 802 link- layer unicast address of the mobile node that issued the previous Router Solicitation message. This will allow the delivery of the Router Advertisement message directly to the mobile node that has solicited it. There are many issues related to this solution. It is not clear which node the mapping will take place. The most likely node is the Wi-Fi Access Point (AP). Also [RFC6085] has left unspecified how the node that does the mapping determines that only one address is relevant. It could be very heavy load on the APs to monitor all relevant messages like Router Solicitations issued on the link and the subsequent replies from the router in the Extended Service Set (ESS). Similar mapping to a single IEEE 802 link-layer unicast address may prove useful for Neighbor Solicitation messages as well. [RFC6085] does not specify the type of multicast message that the mapping applies. Even if the Neighbor Solicitation messages sent to the solicited-node multicast address were eligible for such a mapping, it is not clear if the mapping node, e.g. the AP could determine the single link-layer unicast address to map to. The final issue with the solution in [RFC6085] is that it does not address the multi-link subnet issue. The mapping successfully applied would create a link with as many as PMIPv6 mobile nodes having their distinct set of home network prefixes. This is not acceptable on a shared link. Sarikaya Expires January 13, 2013 [Page 6] Internet-Draft PMIPv6 on WiFi July 2012 7. Solution 2: VLAN 3GPP recently launched a Study on S2a Mobility based On GTP & WLAN access to EPC, in short SaMOG [samog]. SaMOG identifies IEEE 802.1q Virtual Local Area Network (VLAN) as a solution to PMIPv6 operation on shared links such as IEEE 802.11 links. IEEE 802.1q allows up to 4095 VLANs to be created on a given IEEE 802.11 link. This is done by using the VLAN Identifier (VID) field in the Ethernet frame. VID is a 12-bit field specifying the VLAN to which the frame belongs, allowing up to 4096 VLANs to be formed. With VLAN solution each mobile node is assigned a unique VID and all Ethernet frames the mobile node receives/sends are tagged with this VID. These frames are received at the access point and then sent upstream towards the Mobile Access Gateway. VLAN effectively creates a point-to-point link between the MAG and the MN. VLAN effectively solves the problem of having several mobile nodes with different home network prefixes on a shared link. There are several issues related to this solution. VLAN Identifier has well known limitation of allowing a maximum of 4095 VLANs, i.e. 4095 mobile nodes on a given IEEE 802.11 link. This limitation may not be so serious in practice. VLANs make the access point and the customer premises equipment (CPE) router which is usually co-located a dumb device. The CPE becomes a bridge not a router. Recently the tendency by the broadband network operators is to move as much intelligence as possible closer to the user, or home and thus render the CPE a router not a bridge. 8. Other Issues Related to WLAN Applicability PMIPv6 has the functional elements of MAG and LMA and colocation of these elements with fixed network functional elements is an issue. MAG can be colocated with the Residential Gateway (RG) which is usually colocated with the Access Point (AP). In this case RG must be a Layer 3 device, i.e. routed RG. In case RG is a Layer 2 device, i.e. bridged RG, MAG can be colocated with the edge router, or Broadband Network Gateway (BNG). LMA is colocated with the access controller (AC) of CAPWAP architecture [RFC5415] which is usually placed in the core network [I-D.gundavelli-netext-pmipv6-wlan-applicability]. LMA may be colocated with the Packet Data Network Gateway (PDN Gateway) in some scenarios [samog]. Sarikaya Expires January 13, 2013 [Page 7] Internet-Draft PMIPv6 on WiFi July 2012 Colocating MAG with the RG may be a good solution but it also is expensive and not so scalable. Colocating MAG with BNG is probably a good compromise but such a solution requires all RGs to be Layer 2 devices which may not be acceptable to many operators. All MAGs in Proxy Mobile IPv6 MUST use a fixed link-local address and a fixed link-layer address on their Wi-Fi links according to [RFC5213]. In [RFC6543] these values are recommended to be 00-00-5E- 00-52-13 and 0200:5EFF:FE00:5213, respectively. Of course, the deployments can use some other values, specific to their deployments. In multi-vendor deployments, it becomes an operational challenge to impose this on all of the access links that each MAG shares with the mobile nodes. 9. Recommendations There are two recommendations we can make: One option could be to define a shared link operation for Proxy Mobile IPv6. This option requires some standardization effort to be undertaken. In doing this it could also be a good opportunity to fix other problems in the design of PMIPv6 that have surfaced since the publication of the standard. The other option is not to use Proxy Mobile IPv6 in shared links. Of course this recommendation also effects PMIP-like protocols, e.g. GPRS Tunneling Protocol (GTP). 10. Security Considerations This document does not define any new security issues. PMIPv6 security procedures apply. 11. IANA considerations None. 12. Acknowledgements TBD. 13. References Sarikaya Expires January 13, 2013 [Page 8] Internet-Draft PMIPv6 on WiFi July 2012 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", RFC 4260, November 2005. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, "Address Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085, January 2011. [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009. [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for Proxy Mobile IPv6", RFC 6543, May 2012. Sarikaya Expires January 13, 2013 [Page 9] Internet-Draft PMIPv6 on WiFi July 2012 13.2. Informative references [I-D.gundavelli-netext-pmipv6-wlan-applicability] Gundavelli, S., "Applicability of Proxy Mobile IPv6 Protocol for WLAN Access Networks", draft-gundavelli-netext-pmipv6-wlan-applicability-03 (work in progress), April 2012. [samog] "3GPP TR 23.852 V1.0.0, Study on S2a Mobility based On GTP & WLAN access to EPC (SaMOG) (Release 12)", June 2012. [ieee802.11] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 2008", 2008. Sarikaya Expires January 13, 2013 [Page 10] Internet-Draft PMIPv6 on WiFi July 2012 Author's Address Behcet Sarikaya Huawei USA 5340 Legacy Dr. Plano, TX 75024 Phone: Email: sarikaya@ieee.org Sarikaya Expires January 13, 2013 [Page 11]