idnits 2.17.1 draft-sarikaya-netext-pmipv6-shared-link-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document date (July 12, 2012) is 4299 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5268 (Obsoleted by RFC 5568) ** Downref: Normative reference to an Informational RFC: RFC 4903 ** Downref: Normative reference to an Informational RFC: RFC 4260 ** Downref: Normative reference to an Informational RFC: RFC 5757 == Outdated reference: A later version (-06) exists of draft-gundavelli-netext-pmipv6-wlan-applicability-03 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Expires: January 13, 2013 July 12, 2012 6 PMIPv6 Operation on Shared Links 7 draft-sarikaya-netext-pmipv6-shared-link-01 9 Abstract 11 This document describes Proxy Mobile IPv6 (PMIPv6) operation on 12 shared links such as IEEE 802.11. Two solutions of providing point- 13 to-point link operation on the shared links are compared. Advantages 14 and disadvantages of each solution are identified. Issues related to 15 the placement of Mobile Access Gateway (MAG) in fixed broadband 16 network are also discussed. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 13, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Shared Link Operation in IEEE 802.11 Links . . . . . . . . . . 4 55 4. Problems with PMIPv6 Operation in IEEE 802.11 Links . . . . . 4 56 5. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Solution 1: RA Mapping . . . . . . . . . . . . . . . . . . . . 6 58 7. Solution 2: VLAN . . . . . . . . . . . . . . . . . . . . . . . 7 59 8. Other Issues Related to WLAN Applicability . . . . . . . . . . 7 60 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 61 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 63 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 13.2. Informative references . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 Proxy Mobile IPv6 [RFC5213] is designed to work on point-to-point 72 links. Since mobile networks provide point-to-point links PMIPv6 73 operation on such networks present no problems. However, recently 74 interest has grown on PMIPv6 operation on IEEE 802.11 links 75 [ieee802.11], a.k.a Wi-Fi links due to the proliferation of smart 76 phones which support both a wide-area wireless link as well as a 77 wireless local area network (WLAN) link. However, 802.11 networks 78 provide a shared link operation. 80 In PMIPv6, the Mobile Access Gateway (MAG) acts as the default router 81 on the point-to-point link shared with the mobile node (MN). PMIPv6 82 assumes that if it is to operate on a shared link, the link should be 83 configured in such a way that it emulates point-to-point delivery 84 between the mobile node and the mobile access gateway for all the 85 protocol traffic. The protocol traffic that is relevant in this 86 document is multicast packets sent by MAG and MN, i.e. router 87 advertisements and DHCP messages. On a point-to-point link multicast 88 packets are delivered to a single destination. However, on shared 89 links they may be delivered to more than one nodes, i.e. point-to- 90 point delivery may be violated. 92 In a related work, Mobile IPv6 [RFC6275] handover operation in the 93 context of 802.11 access networks is described in [RFC4260]. Several 94 scenarios are identified for Fast Handovers for Mobile IPv6 (FMIPv6), 95 which is Mobile IPv6 handover protocol [RFC5268] to operate on IEEE 96 802.11 links. Since Mobile IPv6 can work on the shared links, there 97 is no issue in the case of Mobile IPv6 on this aspect. 99 In [RFC5757] 802.11 WLAN operation is described. The focus was 100 placed on the delivery of multicast data packets from and to the 101 mobile nodes. PMIPv6 link operation has not been in the scope. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 The terminology in this document is based on the definitions in 110 [RFC4291], [RFC2464] and [RFC5213] 112 3. Shared Link Operation in IEEE 802.11 Links 114 IEEE modeled 802.11 link operation after the Ethernet including the 115 source and destination addresses. Like on Ethernet, the hosts on the 116 same 802.11 link share a common IPv6 prefix. Multicast addressing is 117 also inherited from the Ethernet IEEE 802 address structure. IEEE 118 802 addresses are of 48 bits long, i.e. 6 octets. 120 A 16-octet IPv6 multicast address maps to IEEE 802 multicast address 121 as follows: the first two octets are set to the value 3333 122 hexadecimal to indicate multicast frame and the last four octets are 123 copied from the last four octets of IPv6 multicast address and these 124 last four octets become the multicast group address [RFC2464]. 126 The Interface Address used in IPv6 link local addresses is formed 127 based on the EUI-64 identifier which is derived from 48-bit IEEE 802 128 address by setting the fourth and fifth octets of the EUI to the 129 fixed value FFFE hexadecimal. EUI-64 has the "Universal/Local" (U/L) 130 bit, which is the next-to-lowest order bit of the first octet. 132 The Solicited-Node multicast address in the range FF02:0:0:0:0:1: 133 FF00:0000 to FF02:0:0:0:0:1:FFFF:FFFF maps to an IEEE 802 multicast 134 address in the range 33-33-FF-00-00-00 to 33-33-FF-FF-FF-FF. 136 4. Problems with PMIPv6 Operation in IEEE 802.11 Links 138 Proxy Mobile IPv6 Mobile Node in IEEE 802.11 link first forms a link 139 local address with the last 64 bits as the Interface address obtained 140 from the mobile node's Wi-Fi interface IEEE 802 address. 3G interface 141 that most mobile node's have do not have an IEEE 802 address. 143 Mobile node next sends a Router Solicitation message. The source 144 address is either the Interface Address or the unspecified address. 145 Mobile Access Gateway replies with a Router Advertisement message 146 containing home network prefixes assigned to this mobile node. The 147 destination address is the unicast address of the mobile node if the 148 source address of the Router Solicitation is the Interface address. 149 Otherwise the router advertisement is sent to the all-nodes multicast 150 address (FF02::1). 152 Mobile node receives the router advertisement and forms global 153 unicast address(es) using the home network prefix(es) received and 154 starts communication with the corresponding nodes. 156 As more mobile nodes come into the same IEEE 802.11 link and each of 157 them are assigned different sets of home network prefixes the 158 situation arises that on a shared link, there are several hosts each 159 assigned to a different prefix. This creates a multi-link subnet 160 [RFC4903] which MUST be avoided. 162 In case the mobile node sends the router solicitation message with 163 the unspecified address as the source address, the mobile access 164 gateway sends the router advertisement to the all-nodes multicast 165 address (FF02::1) which gets converted to IEEE 802 multicast address 166 of 33-33-00-00-00-01. Such a router advertisement message is 167 received by the all mobile nodes on the link. Mobile nodes create 168 unicast global addresses from each prefix they receive from the 169 routers. On a shared link, this creates the situation that multiple 170 hosts have duplicate addresses which MUST be avoided. 172 On a shared link, nodes perform address resolution by multicasting a 173 Neighbor Solicitation that asks the target node to return its link- 174 layer address. This is done by multicasting Neighbor Solicitation 175 message to the solicited-node multicast address of the target 176 address. The target returns its link layer address, i.e. IEEE 802 177 address in a Neighbor Advertisement message. On an IEEE 802.11 link 178 there could exist a mixture of nodes with some being PMIPv6 mobile 179 nodes. Such Neighbor Solicitation messages will be sent to IEEE 802 180 multicast address on the solicited-node multicast address range which 181 might be received by more than one nodes, including PMIPv6 mobile 182 nodes. However, PMIPv6 mobile nodes MUST not receive Neighbor 183 Solicitation messages other than the Mobile Access Gateway. 185 5. Solutions 187 In Section 4 we identified that most of the problems are related to 188 the delivery of multicast packets in IEEE 802.11 links. 190 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol 191 [RFC5416] allows two modes of operation for the Wireless Termination 192 Point (WTP), i.e. the Wi-Fi Access Points (AP): split MAC or local 193 MAC. In split MAC operation, the Distribution and Integration 194 services reside on the Access Controller (AC), and therefore all user 195 data is tunneled between the WTP and the AC. Mobile Access Gateway 196 of PMIPv6 would be located at the AC. 198 Split MAC operation of CAPWAP protocol would create a point-to-point 199 link between the mobile nodes and the Mobile Access Gateway. 200 Therefore it can be thought of as a solution. However, if Local MAC 201 operation is used, the problems persist. 203 We next describe two solutions to the problems: [RFC6085] provides a 204 solution in this direction. The idea is to modify the destination 205 address and make it a unicast address. The other solution is Virtual 206 LAN based. 208 6. Solution 1: RA Mapping 210 [RFC2464], specifies the delivery of an IPv6 packet with a multicast 211 destination address by simply mapping the destination address into an 212 Ethernet link-layer multicast address. Multicast delivery is taken 213 care of by IEEE 802.11 procedures. When it is clear that only one 214 address is relevant, [RFC6085] allows for a mapping of such a 215 destination address into an IEEE 802 link-layer unicast address. 216 Subsequent delivery of the Ethernet frame should be to a single node 217 on the IEEE 802.11 link. 219 One example is the delivery of the Router Advertisement message to 220 PMIPv6 mobile nodes. If the router advertisement message's 221 destination address is IEEE 802 multicast address of 222 33-33-00-00-00-01, this address can be mapped to the IEEE 802 link- 223 layer unicast address of the mobile node that issued the previous 224 Router Solicitation message. This will allow the delivery of the 225 Router Advertisement message directly to the mobile node that has 226 solicited it. 228 There are many issues related to this solution. It is not clear 229 which node the mapping will take place. The most likely node is the 230 Wi-Fi Access Point (AP). Also [RFC6085] has left unspecified how the 231 node that does the mapping determines that only one address is 232 relevant. It could be very heavy load on the APs to monitor all 233 relevant messages like Router Solicitations issued on the link and 234 the subsequent replies from the router in the Extended Service Set 235 (ESS). 237 Similar mapping to a single IEEE 802 link-layer unicast address may 238 prove useful for Neighbor Solicitation messages as well. [RFC6085] 239 does not specify the type of multicast message that the mapping 240 applies. Even if the Neighbor Solicitation messages sent to the 241 solicited-node multicast address were eligible for such a mapping, it 242 is not clear if the mapping node, e.g. the AP could determine the 243 single link-layer unicast address to map to. 245 The final issue with the solution in [RFC6085] is that it does not 246 address the multi-link subnet issue. The mapping successfully 247 applied would create a link with as many as PMIPv6 mobile nodes 248 having their distinct set of home network prefixes. This is not 249 acceptable on a shared link. 251 7. Solution 2: VLAN 253 3GPP recently launched a Study on S2a Mobility based On GTP & WLAN 254 access to EPC, in short SaMOG [samog]. SaMOG identifies IEEE 802.1q 255 Virtual Local Area Network (VLAN) as a solution to PMIPv6 operation 256 on shared links such as IEEE 802.11 links. IEEE 802.1q allows up to 257 4095 VLANs to be created on a given IEEE 802.11 link. This is done 258 by using the VLAN Identifier (VID) field in the Ethernet frame. VID 259 is a 12-bit field specifying the VLAN to which the frame belongs, 260 allowing up to 4096 VLANs to be formed. 262 With VLAN solution each mobile node is assigned a unique VID and all 263 Ethernet frames the mobile node receives/sends are tagged with this 264 VID. These frames are received at the access point and then sent 265 upstream towards the Mobile Access Gateway. VLAN effectively creates 266 a point-to-point link between the MAG and the MN. VLAN effectively 267 solves the problem of having several mobile nodes with different home 268 network prefixes on a shared link. 270 There are several issues related to this solution. VLAN Identifier 271 has well known limitation of allowing a maximum of 4095 VLANs, i.e. 272 4095 mobile nodes on a given IEEE 802.11 link. This limitation may 273 not be so serious in practice. 275 VLANs make the access point and the customer premises equipment (CPE) 276 router which is usually co-located a dumb device. The CPE becomes a 277 bridge not a router. Recently the tendency by the broadband network 278 operators is to move as much intelligence as possible closer to the 279 user, or home and thus render the CPE a router not a bridge. 281 8. Other Issues Related to WLAN Applicability 283 PMIPv6 has the functional elements of MAG and LMA and colocation of 284 these elements with fixed network functional elements is an issue. 286 MAG can be colocated with the Residential Gateway (RG) which is 287 usually colocated with the Access Point (AP). In this case RG must 288 be a Layer 3 device, i.e. routed RG. In case RG is a Layer 2 device, 289 i.e. bridged RG, MAG can be colocated with the edge router, or 290 Broadband Network Gateway (BNG). 292 LMA is colocated with the access controller (AC) of CAPWAP 293 architecture [RFC5415] which is usually placed in the core network 294 [I-D.gundavelli-netext-pmipv6-wlan-applicability]. LMA may be 295 colocated with the Packet Data Network Gateway (PDN Gateway) in some 296 scenarios [samog]. 298 Colocating MAG with the RG may be a good solution but it also is 299 expensive and not so scalable. Colocating MAG with BNG is probably a 300 good compromise but such a solution requires all RGs to be Layer 2 301 devices which may not be acceptable to many operators. 303 All MAGs in Proxy Mobile IPv6 MUST use a fixed link-local address and 304 a fixed link-layer address on their Wi-Fi links according to 305 [RFC5213]. In [RFC6543] these values are recommended to be 00-00-5E- 306 00-52-13 and 0200:5EFF:FE00:5213, respectively. Of course, the 307 deployments can use some other values, specific to their deployments. 308 In multi-vendor deployments, it becomes an operational challenge to 309 impose this on all of the access links that each MAG shares with the 310 mobile nodes. 312 9. Recommendations 314 There are two recommendations we can make: 316 One option could be to define a shared link operation for Proxy 317 Mobile IPv6. This option requires some standardization effort to be 318 undertaken. In doing this it could also be a good opportunity to fix 319 other problems in the design of PMIPv6 that have surfaced since the 320 publication of the standard. 322 The other option is not to use Proxy Mobile IPv6 in shared links. Of 323 course this recommendation also effects PMIP-like protocols, e.g. 324 GPRS Tunneling Protocol (GTP). 326 10. Security Considerations 328 This document does not define any new security issues. PMIPv6 329 security procedures apply. 331 11. IANA considerations 333 None. 335 12. Acknowledgements 337 TBD. 339 13. References 340 13.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 346 Networks", RFC 2464, December 1998. 348 [RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, 349 June 2008. 351 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 352 June 2007. 354 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 355 Architecture", RFC 4291, February 2006. 357 [RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 358 Networks", RFC 4260, November 2005. 360 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 361 in IPv6", RFC 6275, July 2011. 363 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 364 "Address Mapping of IPv6 Multicast Packets on Ethernet", 365 RFC 6085, January 2011. 367 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 368 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 369 and Brief Survey", RFC 5757, February 2010. 371 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 372 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 374 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 375 Provisioning of Wireless Access Points (CAPWAP) Protocol 376 Specification", RFC 5415, March 2009. 378 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 379 Provisioning of Wireless Access Points (CAPWAP) Protocol 380 Binding for IEEE 802.11", RFC 5416, March 2009. 382 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 383 Proxy Mobile IPv6", RFC 6543, May 2012. 385 13.2. Informative references 387 [I-D.gundavelli-netext-pmipv6-wlan-applicability] 388 Gundavelli, S., "Applicability of Proxy Mobile IPv6 389 Protocol for WLAN Access Networks", 390 draft-gundavelli-netext-pmipv6-wlan-applicability-03 (work 391 in progress), April 2012. 393 [samog] "3GPP TR 23.852 V1.0.0, Study on S2a Mobility based On GTP 394 & WLAN access to EPC (SaMOG) (Release 12)", June 2012. 396 [ieee802.11] 397 "Information technology - Telecommunications and 398 information exchange between systems - Local and 399 metropolitan area networks - Specific requirements - Part 400 11: Wireless LAN Medium Access Control (MAC) and Physical 401 Layer (PHY) specifications", IEEE Standard 802.11, 2008", 402 2008. 404 Author's Address 406 Behcet Sarikaya 407 Huawei USA 408 5340 Legacy Dr. 409 Plano, TX 75024 411 Phone: 412 Email: sarikaya@ieee.org