idnits 2.17.1 draft-ietf-netext-pmip-cp-up-separation-07.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 issues found here. 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 -- The document date (August 30, 2014) is 3498 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) == Outdated reference: A later version (-06) exists of draft-matsushima-stateless-uplane-vepc-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG R. Wakikawa 3 Internet-Draft Softbank Mobile 4 Intended status: Standards Track R. Pazhyannur 5 Expires: March 3, 2015 S. Gundavelli 6 Cisco 7 C. Perkins 8 Futurewei Inc. 9 August 30, 2014 11 Separation of Control and User Plane for Proxy Mobile IPv6 12 draft-ietf-netext-pmip-cp-up-separation-07.txt 14 Abstract 16 This document specifies a method to split the Control Plane (CP) and 17 User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. 18 Existing specifications allow a mobile access gateway (MAG) to 19 separate its control and user plane using the Alternate Care of 20 address mobility option for IPv6, or Alternate IPv4 Care of Address 21 option for IPv4. However, the current specification does not provide 22 any mechanism allowing the local mobility anchor (LMA) to perform an 23 analogous functional split. To remedy that shortcoming, this 24 document specifies a mobility option enabling a LMA to provide an 25 alternate LMA address to be used for the bi-directional user plane 26 traffic between the MAG and LMA. With this new option, a LMA will be 27 able to use an IP address for its user plane which is different than 28 the IP address used for the control plane. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 3, 2015. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 65 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Additional Fields in Conceptual Data Structures . . . . . . . 6 68 4. LMA User Plane Address Mobility Option . . . . . . . . . . . . 6 69 5. Protocol Configuration Variable . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 A PMIPv6 infrastructure comprises two primary entities: LMA (local 81 mobility anchor) and MAG (mobile access gateway). The interface 82 between MAG and LMA consists of the control plane and user plane. 83 The control plane is responsible for signaling messages between MAG 84 and LMA such as the Proxy Binding Update (PBU) and Proxy Binding 85 Acknowledgement (PBA) messages to establish a mobility binding. In 86 addition, the control plane components in the MAG and LMA are also 87 responsible for setting up and tearing down a bi-directional tunnel 88 between the MAG and LMA. The user plane is used for carrying the 89 mobile node's IP traffic between the MAG and the LMA over the bi- 90 directional tunnel. 92 Widely deployed mobility management systems for wireless 93 communications require separation of IP transport for forwarding user 94 plane and control plane traffic. This separation offers more 95 flexible deployment options for LMA and MAG entities in Proxy Mobile 96 IPv6 as described in [I-D.wakikawa-req-mobile-cp-separation]. To 97 meet this requirement, Proxy Mobile IPv6 (PMIPv6) requires that the 98 control plane functions of the LMA to be addressable at a different 99 IP address than the IP address assigned for the user plane. However, 100 PMIPv6 does not currently specify a mechanism for allowing the LMA to 101 separate the control plane from the user plane. The LMA is currently 102 required to associate the IP address of the tunnel source with the 103 target IP address for the control messages received from the MAG. 105 The control plane and user plane components (of the MAG and LMA) are 106 typically co-located in the same physical entity. However, there are 107 situations where it is desirable to have the control and user plane 108 of the MAG and LMA in separate physical entities. For example, in a 109 WLAN (Wireless LAN) network, it may be desirable to have the control 110 plane component of the MAG reside on the Access Controller (also 111 sometimes referred to as Wireless LAN Controller (WLC)) while the 112 user plane component of the MAG resides on the WLAN Access Point. 113 This enables all the control plane messages to the LMA to be 114 centralized while the user plane would be distributed across the 115 multiple Access Points. Similarly there is a need for either the 116 control plane and user plane component of the LMA to be separated 117 according to different scaling requirements, or in other cases the 118 need to centralize the control plane in one geographical location 119 while distributing the user plane component across multiple 120 locations. For example, as illustrated in Figure 1, the LMA and MAG 121 could have one control session established for PMIPv6 control 122 signaling, while maintaining separate connectivity via GRE or 123 IP-in-IP tunneling for forwarding user plane traffic. 125 MAG LMA 126 +--------+ +--------+ 127 +------+ | MAG-CP |--------------| LMA-CP | _----_ 128 | MN | | | PMIPv6 | | _( )_ 129 | |---- +--------+ +--------+ ===( Internet ) 130 +------+ : : (_ _) 131 +--------+ +--------+ '----' 132 | MAG-UP |--------------| LMA-UP | 133 | | GRE/IP-in-IP | | 134 +--------+ /UDP +--------+ 135 CP: Control Plane 136 UP: User Plane 138 Figure 1: Functional Separation of the Control and User Plane 140 [RFC6463] and [RFC6275] enable separating the control and user plane 141 in the MAG. In particular, [RFC6463] defines the Alternate IPv4 142 Proxy Care of Address Option, and [RFC6275] defines an Alternate Care 143 of Address for IPv6 address. The MAG may provide an Alternate Care 144 of Address in the PBU, and if the LMA supports this option then a bi- 145 directional tunnel is setup between the LMA address and the MAG's 146 alternate Care of address. However, these documents do not specify a 147 corresponding option for the LMA to provide an alternate address to 148 the MAG. 150 This specification therefore defines a new mobility option that 151 enables a local mobility anchor to provide an alternate LMA address 152 to be used for the bidirectional tunnel between the MAG and LMA as 153 shown in Figure 1. 155 The LMA Control Plane and the LMA User Plane functions are typically 156 deployed on the same IP node and in such scenario the interface 157 between these functions is internal to the implementation. 158 Deployments may also choose to deploy the LMA Control Plane and the 159 LMA User Plane functions on separate IP nodes. In such deployment 160 models, there needs to be a protocol interface between these two 161 functions and which is outside the scope of this document. Possible 162 options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0], 163 FORCES [RFC5810], use of routing infrastructure 164 [I-D.matsushima-stateless-uplane-vepc] or vendor specific approaches. 165 This specification does not mandate a specific protocol interface and 166 views this interface as a generic interface relevant more broadly for 167 many other protocol systems in addition to Proxy Mobile IPv6. When 168 the LMA Control Plane and the LMA User Plane functions are deployed 169 on separate IP nodes, the requirement related to user-plane address 170 anchoring specified in Section 5.6.2 of [RFC5213] and Section 3.1.3 171 of [RFC5844] must be met by the node hosting the LMA user plane 172 functionality. The LMA user plane node must be topological anchor 173 point for the IP address/prefixes allocated to the mobile node. 175 2. Conventions and Terminology 177 2.1. Conventions 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 2.2. Terminology 185 3GPP terms can be found in [RFC6459]. Other mobility related terms 186 used in this document are to be interpreted as defined in [RFC5213] 187 and [RFC5844]. Additionally, this document uses the following terms: 189 IP-in-IP 191 IP-within-IP encapsulation [RFC2473], [RFC4213] 193 GRE 195 Generic Routing Encapsulation [RFC1701] 197 UDP Encapsulation 199 Encapsulation mode based on UDP transport specified in [RFC5844] 201 LMA Control Plane Address (LMA-CPA) 203 The IP address on the LMA that is used for sending and receiving 204 control plane traffic from the MAG. 206 LMA User Plane Address (LMA-UPA) 208 The IP address on the LMA that is used for sending and receiving 209 user plane traffic from the MAG. 211 MAG Control Plane Address (MAG-CPA) 213 The IP address on the MAG that is used for sending and receiving 214 control plane traffic from the LMA. 216 MAG User Plane Address (MAG-UPA) 217 The IP address on the MAG that is used for sending and receiving 218 user plane traffic from the LMA. This address is also referred to 219 as the Alternate Care of Address. 221 3. Additional Fields in Conceptual Data Structures 223 To support the capability specified in this document, the conceptual 224 Binding Update List entry data structure maintained by the LMA and 225 the MAG is extended with the following additional fields. 227 o The IP address of the LMA that carries user plane traffic. 229 o The IP address of the LMA that handles control plane traffic. 231 4. LMA User Plane Address Mobility Option 233 The LMA User Plane Address mobility option is a new mobility header 234 option defined for use with PBU and PBA messages exchanged between 235 the LMA and the MAG. This option is used for notifying the MAG about 236 the LMA's user plane IPv6 or IPv4 address. There can be zero, one or 237 two instances of the LMA User Plane Address mobility option present 238 in the message. When two instances of the option are present, one 239 instance of the option must be for IPv4 transport and the other 240 instance must be for IPv6 transport. 242 The LMA User Plane Address mobility option has an alignment 243 requirement of 8n+2. Its format is as shown in Figure 2: 245 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 + + 252 | | 253 . . 254 + LMA User Plane Address + 255 | | 256 + + 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 2: LMA User Plane Address option format 262 Type 263 To be assigned by IANA. 265 Length 267 8-bit unsigned integer indicating the length of the option in 268 octets, excluding the type and length fields. 270 Reserved 272 This field is unused in this specification. The value MUST be set 273 to zero (0) by the sender and MUST be ignored by the receiver. 275 LMA User Plane Address 277 Contains the 32-bit IPv4 address, or the 128-bit IPv6 address of 278 the LMA User plane. When the LMA User Plane Address Mobility 279 option is included in a PBU message, this field can be a zero 280 length field, or it can have a value of ALL_ZERO, with all bits in 281 the 32-bit IPv4 address, or the 128-bit IPv6 address set to zero. 283 When including the LMA User Plane Address mobility option in the PBU, 284 the MAG must apply the following rules: 286 o When using IPv4 transport for the user-plane, the IP address field 287 in the option MUST be either a zero-length field, or a 4-octet 288 field with ALL_ZERO value. 290 o When using IPv6 transport for the user-plane, the IP address field 291 in the option MUST be either a zero-length field, or a 16-octet 292 field with ALL_ZERO value. 294 When the LMA includes the LMA User Plane Address mobility option in 295 the PBA, the IP address field in the option MUST be set to the LMA's 296 IPv4 or IPv6 address carrying user-plane traffic. 298 o When using IPv4 transport for the user-plane, the IP address field 299 in the option is the IPv4 address carrying user-plane traffic. 301 o When using IPv6 transport for the user-plane, the IP address field 302 in the option is the IPv6 address carrying user-plane traffic. 304 The encapsulation mode that will be chosen for the user-plane between 305 the MAG and the LMA has to based on the considerations specified in 306 [RFC5213] and [RFC5844]. 308 5. Protocol Configuration Variable 310 This specification defines the following configuration variable, 311 which must be configurable (e.g., by the system management) on the 312 LMA and MAG mobility entities. The configured value for this 313 protocol variable MUST survive server reboots and service restarts, 314 and MUST be the same for every LMA and MAG in the network domain 315 supporting PMIPv6. 317 Domain-wide-LMA-UPA-Support 319 This variable indicates whether or not all the mobility 320 entities in the PMIPv6 domain support the LMA User Plane 321 Address mobility option. 323 When this variable on the MAG is set to zero (0), the MAG MUST 324 indicate whether it supports this feature, by including the LMA 325 User Plane Address mobility option in the PBU. If the option 326 is not present in the PBU, the LMA SHALL disable this feature 327 for the mobility session corresponding to the PBU. 329 Setting this variable to one (1) on the MAG indicates that 330 there is domain-wide support for this feature and the MAG is 331 not required to include the LMA User Plane Address mobility 332 option in the PBA. In this case, the MAG MAY choose not to 333 include the LMA User Plane Address mobility option in the PBU. 335 When this variable on the LMA is set to zero (0), the LMA MUST 336 NOT include the LMA User Plane Address mobility option in the 337 PBA, unless the MAG has indicated support for this feature by 338 including the LMA User Plane Address mobility option in the PBU 339 message. 341 Setting this variable to one (1) on the LMA indicates that 342 there is domain-wide support for this feature and the LMA 343 SHOULD choose to include this LMA User Plane Address mobility 344 option in the PBA even if the option is not present in the PBU 345 message. 347 On both the LMA and the MAG, the default value for this 348 variable is zero (0). This implies that the default behavior 349 of a MAG is to include this option in the PBU and the default 350 behavior of a LMA is to include this option in a PBA only if 351 the option is present in the PBU. 353 6. IANA Considerations 355 This document requires the following IANA actions. 357 o Action-1: This specification defines a new mobility header option, 358 LMA User Plane Address mobility option. The format of this option 359 is described in Section 4. The type value for this 360 mobility option is to be allocated from the Mobility Options 361 registry at . 362 RFC Editor: Please replace in Section 4 with the assigned 363 value and update this section accordingly. 365 7. Security Considerations 367 The Proxy Mobile IPv6 specification [RFC5213] requires the signaling 368 messages between the MAG and the LMA to be protected using end-to-end 369 security association(s) offering integrity and data origin 370 authentication. The Proxy Mobile IPv6 specification also requires 371 IPsec [RFC4301] to be a mandatory-to-implement security mechanism. 373 This document specifies an approach where the Control and User Plane 374 functions of the MAG and LMA are separated and hosted on different IP 375 nodes. In such deployment models, the nodes hosting those respective 376 Control Plane functions have to still meet the above the security 377 requirement. Specifically, the Proxy Mobile IPv6 signaling messages 378 exchanged between these entities MUST be protected using end-to-end 379 security association(s) offering integrity and data origin 380 authentication. Furthermore, IPsec is a mandatory-to-implement 381 security mechanism for the nodes hosting the Control Plane function 382 of the MAG and LMA. Additional documents may specify alternative 383 mechanisms and the mobility entities can enable a specific mechanism 384 for securing Proxy Mobile IPv6 signaling messages, based on either a 385 static configuration or after a dynamic negotiation using any 386 standard security negotiation protocols. 388 As per the Proxy Mobile IPv6 specification, the use of IPsec for 389 protecting the mobile node's User Plane traffic is optional. This 390 specification keeps the same requirement and therefore requires the 391 nodes hosting the User Plane functions of the MAG and the LMA to have 392 IPsec as a mandatory-to-implement security mechanism, but make the 393 use of IPsec as optional for User Plane traffic protection. 395 The LMA User Plane Address mobility option defined in this 396 specification is for use in PBU and PBA messages. This option is 397 carried like any other mobility header option as specified in 398 [RFC5213]. Therefore, it inherits security guidelines from 399 [RFC5213]. 401 The LMA-UPA address provided within the LMA User Plane Address 402 mobility option MUST be a valid address under the administrative 403 control associated with the LMA functional block. 405 If the LMA-UP and the LMA-CP functions are hosted in different 406 entities, any control messages between these two entities containing 407 the LMA User Plane Address mobility option MUST be protected by 408 IPsec. 410 8. Acknowledgements 412 The authors of this document thank the NetExt Working Group for the 413 valuable feedback to different versions of this specification. In 414 particular the authors want to thank John Kaippallimalil, Sridhar 415 Bhaskaran, Nirav Salot, Bruno Landais, Brian Carpenter, Pete Resnick, 416 Stephen Farrell and Brian Haberman for their valuable comments and 417 suggestions to improve this specification. 419 9. References 421 9.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 427 Internet Protocol", RFC 4301, December 2005. 429 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 430 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 432 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 433 Mobile IPv6", RFC 5844, May 2010. 435 9.2. Informative References 437 [I-D.matsushima-stateless-uplane-vepc] 438 Matsushima, S. and R. Wakikawa, "Stateless user-plane 439 architecture for virtualized EPC (vEPC)", 440 draft-matsushima-stateless-uplane-vepc-03 (work in 441 progress), July 2014. 443 [I-D.wakikawa-req-mobile-cp-separation] 444 Wakikawa, R., Matsushima, S., Patil, B., Chen, B., DJ, D., 445 and H. Deng, "Requirements and use cases for separating 446 control and user planes in mobile network architectures", 447 draft-wakikawa-req-mobile-cp-separation-00 (work in 448 progress), November 2013. 450 [OpenFlow-Spec-v1.4.0] 451 Open Networking Foundation, "OpenFlow Switch 452 Specification", 2013. 454 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 455 Routing Encapsulation (GRE)", RFC 1701, October 1994. 457 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 458 IPv6 Specification", RFC 2473, December 1998. 460 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 461 for IPv6 Hosts and Routers", RFC 4213, October 2005. 463 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 464 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 465 Control Element Separation (ForCES) Protocol 466 Specification", RFC 5810, March 2010. 468 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 469 in IPv6", RFC 6275, July 2011. 471 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 472 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 473 Partnership Project (3GPP) Evolved Packet System (EPS)", 474 RFC 6459, January 2012. 476 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 477 "Runtime Local Mobility Anchor (LMA) Assignment Support 478 for Proxy Mobile IPv6", RFC 6463, February 2012. 480 Authors' Addresses 482 Ryuji Wakikawa 483 Softbank Mobile 484 1-9-1,Higashi-Shimbashi,Minato-Ku 485 Tokyo 105-7322 486 Japan 488 Email: ryuji.wakikawa@gmail.com 489 Rajesh S. Pazhyannur 490 Cisco 491 170 West Tasman Drive 492 San Jose, CA 95134, 493 USA 495 Email: rpazhyan@cisco.com 497 Sri Gundavelli 498 Cisco 499 170 West Tasman Drive 500 San Jose, CA 95134 501 USA 503 Email: sgundave@cisco.com 505 Charles E. Perkins 506 Futurewei Inc. 507 2330 Central Expressway 508 Santa Clara, CA 95050, 509 USA 511 Email: charliep@computer.org