[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                        B. Sarikaya
Internet-Draft                                                Huawei USA
Expires: November 4, 2012                                    May 3, 2012


                    PMIPv6 Operation on Shared Links
              draft-sarikaya-netext-pmipv6-shared-link-00

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.

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 November 4, 2012.

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 November 4, 2012                [Page 1]


Internet-Draft               PMIPv6 on WiFi                     May 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.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   9.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  7
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     11.1.  Normative References  . . . . . . . . . . . . . . . . . .  8
     11.2.  Informative references  . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10



































Sarikaya                Expires November 4, 2012                [Page 2]


Internet-Draft               PMIPv6 on WiFi                     May 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 November 4, 2012                [Page 3]


Internet-Draft               PMIPv6 on WiFi                     May 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 November 4, 2012                [Page 4]


Internet-Draft               PMIPv6 on WiFi                     May 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 November 4, 2012                [Page 5]


Internet-Draft               PMIPv6 on WiFi                     May 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 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 November 4, 2012                [Page 6]


Internet-Draft               PMIPv6 on WiFi                     May 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.  Security Considerations

   This document does not define any new security issues.  PMIPv6
   security procedures apply.


9.  IANA considerations

   None.


10.  Acknowledgements

   TBD.


11.  References



Sarikaya                Expires November 4, 2012                [Page 7]


Internet-Draft               PMIPv6 on WiFi                     May 2012


11.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.

   [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.

11.2.  Informative references

   [samog]    "3GPP TR 23.852 V1.0.0, Study on S2a Mobility based On GTP
              & WLAN access to EPC (SaMOG) (Release 11)", December 2011.

   [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



Sarikaya                Expires November 4, 2012                [Page 8]


Internet-Draft               PMIPv6 on WiFi                     May 2012


              Layer (PHY) specifications", IEEE Standard 802.11, 2008",
              2008.

















































Sarikaya                Expires November 4, 2012                [Page 9]


Internet-Draft               PMIPv6 on WiFi                     May 2012


Author's Address

   Behcet Sarikaya
   Huawei USA
   5340 Legacy Dr.
   Plano, TX  75074

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org










































Sarikaya                Expires November 4, 2012               [Page 10]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/