idnits 2.17.1 draft-devarapalli-netlmm-pmipv6-data-plane-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 334. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5659 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 (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-05 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '4') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '6') (Obsoleted by RFC 5996) == Outdated reference: A later version (-14) exists of draft-ietf-mext-binding-revocation-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group V. Devarapalli 3 Internet-Draft WiChorus 4 Intended status: Standards Track October 27, 2008 5 Expires: April 30, 2009 7 Separating Control and Data Plane for Proxy Mobile IPv6 8 draft-devarapalli-netlmm-pmipv6-data-plane-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 30, 2009. 35 Abstract 37 Proxy Mobile IPv6 is a network-based mobility management protocol. 38 The mobility entities involved in the Proxy Mobile IPv6 protocol, the 39 Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), 40 setup tunnels dynamically to manage mobility for a mobile node within 41 the Proxy Mobile IPv6 domain. This document describes an extension 42 to the Proxy Mobile IPv6 protocol to register a data plane address, 43 that is different from the Proxy Care-of Address with the LMA. This 44 allows separation of control and data plane. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Control and Data Plane Separation . . . . . . . . . . . . . . . 4 51 3.1. Extensions to Binding Update List and Binding Cache 52 Data Structures . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Data Plane Address Mobility Option . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . . . 8 63 1. Introduction 65 Proxy Mobile IPv6 [2] enables network-based mobility for IPv6 hosts 66 that do not implement any mobility protocols. The protocol is 67 described in detail in [2]. In order to facilitate the network-based 68 mobility, the PMIPv6 protocol defines a Mobile Access Gateway (MAG), 69 which acts as a proxy for the Mobile IPv6 [4] signaling, and the 70 Local Mobility Anchor (LMA) which acts similar to a Home Agent, 71 anchoring a Mobile Node's sessions within a Proxy Mobile IPv6 72 (PMIPv6) domain. The LMA and the MAG establish a bidirectional 73 tunnel for forwarding all data traffic belonging to the Mobile Nodes. 75 Some of the deployments of Proxy Mobile IPv6 are planning to separate 76 the control and data plane end points for the Mobile Access Gateway. 77 There will be a separate IP address for the entity that sends and 78 receives the Proxy Mobile IPv6 signaling messages. Similarly, there 79 will be a separate IP address for the entity that encapsulates and 80 decapsulates the data traffic to/from the mobile node. According to 81 RFC 5213 [2] and RFC 3775 [4], the LMA stores only IP address, the 82 Proxy Care-of Address (PCOA), in the proxy binding cache entry at the 83 LMA. Therefore the LMA uses the same IP address of a MAG for 84 signaling messages and data traffic. 86 In order to allow the separation of the control and data plane, this 87 document describes an extension to register two IP addresses with the 88 LMA. The IP address used for the signaling messages will continue to 89 be called the Proxy Care-of Address. A separate IP address for the 90 data plane is carried in the Proxy Binding Update to indicate the 91 tunnel end point for the data traffic. 93 The separation of control and data plane allows a number of 94 scenarios. It is possible to keep the control plane end point the 95 same for a mobile node as it moves across the MAGs in the PMIPv6 96 domain. The new MAG, the mobile node attaches to, is only used as 97 the data plane end point. This helps in avoiding access 98 authentication every time the mobile node moves and attaches to a 99 different MAG. The mechanism described in the document also enables 100 some load balancing scenarios, where the data traffic is directed to 101 different application blades in a chassis-based PMIPv6 network entity 102 implementation, with a fewer number of blades handling the control 103 traffic. 105 The control and data plane separation might require some interaction 106 between the control plane and data plane end points. For example, 107 the data plane end point would need to install some forwarding 108 entries for the mobile node based on the PMIPv6 signaling messages 109 exchanged by the control plane end point. Future versions of this 110 document may specify the messages required for such an interaction. 112 It is out of scope for this document for now. 114 The mechanism described in the document can be used by both the MAG 115 and the LMA for control and data plane separation. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [1]. 123 3. Control and Data Plane Separation 125 If a MAG wants to register a separate data plane address, it MUST 126 include the Data Plane Address mobility option described in 127 Section 4, in the Proxy Binding Update. The MAG MUST include the 128 IPv6 address of the data plane end point in the Data Plane Address 129 mobility option In case there is an IPv4 transport network between 130 the MAG and the LMA as described in [3], the MAG MUST include the 131 IPv4 address of the data plane end point. 133 When the LMA receives a Proxy Binding Update message with the Data 134 Plane Address mobility option, it MUST store the address in the 135 mobility option as the end point for the PMIPv6 tunnel created for 136 carrying the mobile node's traffic. The source address of the Proxy 137 Binding Update message or the address in the Alternate Care-of 138 Address option [4], if present, is stored as the Proxy Care-of 139 Address for the particular binding. If the Data Plane Address option 140 was successfully processed, the LMA MUST include the Data Plane 141 Address option in the Proxy Binding Acknowledgment message without 142 any IP address in the mobility option. In case the LMA does not 143 support the mechanism described in this document, it will not 144 recognize the Data Plane Address mobility option and will skip 145 processing the option. If the LMA recognizes the option, but does 146 not want use separate IP addresses for the control and data planes, 147 it MUST send a Proxy Binding Acknowledgment message with a failed 148 status, "DATA_PLANE_SEPARATION_NOT_ALLOWED". 150 If the MAG receives a Proxy Binding Acknowledgment message without 151 the Data Plane mobility option in response to a Proxy Binding Update 152 in which it had included a Data Plane Address option, it MUST 153 conclude that the LMA does not support the separation of control and 154 data plane. The MAG MUST then raise an alarm for an administrative 155 action. If the MAG receives a Proxy Binding Acknowledgment message 156 with status, "DATA_PLANE_SEPARATION_NOT_ALLOWED", it MUST NOT send 157 any more Proxy Binding Update messages to the particular LMA and MUST 158 raise an alarm for an administrative action. 160 Even though the mechanism described in this document is primarily 161 intended for separation of control and data plane on the MAG, it is 162 possible to use it for the LMA also. If the LMA wants to use a 163 separate data plane address, it should include the data plane end 164 point in the Data Plane Address mobility option in the Proxy Binding 165 Acknowledgment message. The MAG would use this address as the LMA 166 tunnel end point for data traffic. 168 3.1. Extensions to Binding Update List and Binding Cache Data 169 Structures 171 This document extends the Binding Update List entry on the MAG and 172 the Binding Cache Entry on the LMA to include the data plane address 173 in addition to the Proxy Care-of Address. The Proxy Care-of Address 174 MUST be used for all Proxy Mobile IPv6 signaling messages, including 175 messages initiated by the LMA like the Binding Revocation Indication 176 message [7]. The Data Plane address MUST be used for tunneling the 177 data traffic meant for the mobile node. 179 4. Data Plane Address Mobility Option 181 The following shows the message format for a new mobility option for 182 carrying the data plane address, or the tunnel end point. The Data 183 Plane Address Mobility Option is only valid in a Proxy Binding Update 184 and Proxy Binding Acknowledgment messages. It has an alignment 185 requirement of 4n+1. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Type | Length | Reserved | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Data Plane Address .... | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Type 197 A 8-bit field that indicates that it is a Data Plane Address 198 mobility option. 200 Length 202 A 8-bit field that indicates the length of the option in octets 203 excluding the 'Type' and 'Length' fields. It is set to '5' if an 204 IPv4 address is carried in the option. It is set to '17' if an 205 IPv6 address is carried in the option. If there is no address 206 being carried in the option, i.e., it is being sent by the LMA 207 just to acknowledge the processing of the Data Plane Address 208 mobility option in the Proxy Binding Acknowledgment, then it is 209 set to '1'. 211 Reserved 213 A 8-bit field that is set to '0' and ignored by the receiver. 215 Data Plane Address 217 A 32-bit or 128-bit field to carry the IPv4 or IPv6 address of the 218 Proxy Mobile IPv6 tunnel end point. This field is absent if the 219 LMA is sending this option in the Proxy Binding Acknowledgment 220 messages to indicate that it processed the Data Plane Address 221 mobility option in the preceding Proxy Binding Update message. 223 5. Security Considerations 225 Since the Data Plane Address mobility option is carried in the Proxy 226 Binding Update and Proxy Binding Acknowledgment messages, no 227 additional security beyond what is described in RFC 5213. According 228 to RFC 5213 [2], these messages are protected by the use of IPsec 229 [5]. 231 As a result of the control and data plane separation, if there is an 232 interface with new messages between the control plane and data plane 233 end points, the messages exchanged on this interface MUST be secured. 234 Integrity protection is mandatory. Confidentiality protection is 235 optional. If the messages use the Mobility Header protocol [4], it 236 is recommended that these messages are protected by the use of IKEv2 237 [6] and IPsec [5]. 239 6. IANA Considerations 241 The Data Plane Address mobility option defined in Section 4 must have 242 the type value allocated from the same space as the Mobility Options 243 defined in RFC 3775 [4]. 245 A new Proxy Binding Ack status value from the "Status Codes" registry 246 defined by RFC 3775 [4] should be allocated. The new status code is 247 a failure status code, (>128) and is called 248 "DATA_PLANE_SEPARATION_NOT_ALLOWED". 250 7. Acknowledgments 252 The author would like to think the folks involved in the discussion 253 on the NETLMM mailing list on the topic of separating the control and 254 data plane for Proxy Mobile IPv6. 256 8. References 258 8.1. Normative References 260 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 261 Levels", BCP 14, RFC 2119, March 1997. 263 [2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 264 B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 266 [3] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile 267 IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05 (work in 268 progress), September 2008. 270 8.2. Informative References 272 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 273 IPv6", RFC 3775, June 2004. 275 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 276 Protocol", RFC 4301, December 2005. 278 [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 279 December 2005. 281 [7] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. 282 Yegani, "Binding Revocation for IPv6 Mobility", 283 draft-ietf-mext-binding-revocation-01 (work in progress), 284 August 2008. 286 Author's Address 288 Vijay Devarapalli 289 WiChorus 290 3950 North First Street 291 San Jose, CA 95134 292 USA 294 Email: vijay@wichorus.com 296 Full Copyright Statement 298 Copyright (C) The IETF Trust (2008). 300 This document is subject to the rights, licenses and restrictions 301 contained in BCP 78, and except as set forth therein, the authors 302 retain all their rights. 304 This document and the information contained herein are provided on an 305 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 306 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 307 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 308 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 309 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 310 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 312 Intellectual Property 314 The IETF takes no position regarding the validity or scope of any 315 Intellectual Property Rights or other rights that might be claimed to 316 pertain to the implementation or use of the technology described in 317 this document or the extent to which any license under such rights 318 might or might not be available; nor does it represent that it has 319 made any independent effort to identify any such rights. Information 320 on the procedures with respect to rights in RFC documents can be 321 found in BCP 78 and BCP 79. 323 Copies of IPR disclosures made to the IETF Secretariat and any 324 assurances of licenses to be made available, or the result of an 325 attempt made to obtain a general license or permission for the use of 326 such proprietary rights by implementers or users of this 327 specification can be obtained from the IETF on-line IPR repository at 328 http://www.ietf.org/ipr. 330 The IETF invites any interested party to bring to its attention any 331 copyrights, patents or patent applications, or other proprietary 332 rights that may cover technology that may be required to implement 333 this standard. Please address the information to the IETF at 334 ietf-ipr@ietf.org.