Internet DRAFT - draft-sarikaya-netext-pmipv6-shared-link
draft-sarikaya-netext-pmipv6-shared-link
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]
