idnits 2.17.00 (12 Aug 2021) /tmp/idnits3948/draft-krishnan-mext-ha-redirect-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 317. 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 (February 25, 2008) is 5192 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-netlmm-proxymip6 has been published as RFC 5213 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft S. Touati 4 Intended status: Informational Z. Qiang 5 Expires: August 28, 2008 Ericsson 6 February 25, 2008 8 Redirecting Proxy Binding Updates in PMIPv6 9 draft-krishnan-mext-ha-redirect-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies a new LMA Redirect mechanism, where an 43 initially contacted LMA can let the MAG know that it needs to connect 44 to an alternate LMA to get mobility services, either for overload 45 prevention and/or load balancing purposes. This document proposes a 46 new error code for the proxy binding acknowledgement message and a 47 new mobility option to be carried on the binding acknowledgement 48 message for this purpose. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Proposed method . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Alternate LMA List Option . . . . . . . . . . . . . . . . . . . 3 56 5. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 7. Operational Considerations . . . . . . . . . . . . . . . . . . 6 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . . . . 9 65 1. Requirements notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Introduction 73 In PMIPv6 [PMIPv6], LMAs are responsible for the registration of 74 mobile nodes in the home network, intercepting packets destined for 75 them, and tunneling these packets to their proxy care-of address 76 hosted on a MAG. When the LMA has to support a large number of 77 mobile nodes and actively tunnel traffic to them, it could become 78 overloaded, leading to dropped packets and connections. 80 An LMA might not want to accept any new bindings of mobile nodes 81 other than the ones it is currently supporting, for various reasons. 82 i.e., it might be overloaded, it wants to achieve better load 83 balancing with another known LMA in the same network, or it has some 84 scheduled maintenance coming up soon. 86 [RFC5142] provides a mechanism that allows a Home Agent to signal the 87 Mobile Node that it should contact a new Home Agent, but it is not 88 clear if this mechanism can be used for PMIPv6 in the interaction 89 between the MAG and the LMA. 91 3. Proposed method 93 When an LMA receives a PBU message from a MAG and is not able to 94 serve the MN specified in the PBU, it sends a PBA message back with 95 an error code describing the cause for why it cannot accept the 96 binding. Along with the status code, the LMA optionally includes a 97 mobility option called the Alternate LMA list, that contains a list 98 of LMA addresses that the MAG can contact to obtain mobility service 99 for the MN. The method by which the alternate LMA list is created on 100 the LMA is out of scope of this document. 102 A new status code is defined in this document. The PMIPV6-LMA- 103 REDIRECT status code is used when the LMA wishes to redirect the MAG. 105 4. Alternate LMA List Option 107 This document defines a new mobility option called the Alternate LMA 108 List Option. This option MUST be used only in PBA messages sent from 109 a LMA towards the MAG. This option SHOULD be present if the status 110 code is PMIPV6-LMA-REDIRECT. It MUST NOT be present if the status 111 code is not PMIPV6-LMA-REDIRECT. 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Option Type | Option Length | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Num LMAs | Reserved | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | | 121 : : 122 : LMA1 Address : 123 : : 124 | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | | 127 : : 128 : LMA2 Address : 129 : : 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 : : 133 : : 134 : : 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | 137 : : 138 : LMAn Address : 139 : : 140 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Option Type 144 TBA3 146 Option Length 147 Length of the Alternate LMA List mobility option. 149 Num LMAs 150 Number of LMA addresses in the following list 152 Reserved 153 This field MUST be set to zero and ignored on reception 155 LMA1 Address 156 128 bit address of the first LMA 158 LMAn Address 159 128 bit address of the nth LMA 160 Figure 1: Alternate LMA List Option Format 162 5. LMA Operation 164 Upon receiving a Proxy Binding Update message from a MAG, the LMA may 165 reject the binding and provide a list of alternate LMAs. This may be 166 done for various reasons like administrative, load balancing, or 167 policy reasons as described earlier. 169 The LMA MUST prepare a Proxy Binding Acknowledgment message, as 170 described in [PMIPv6], with a status code PMIPV6-LMA-REDIRECT. The 171 LMA needs to be aware of alternate LMAs that can serve the MN, and it 172 MUST include an Alternate LMA List option containing the addresses of 173 the alternate LMAs. 175 6. MAG Operation 177 Upon receiving the Proxy Binding Acknowledgment from the LMA with the 178 status code set to PMIPV6-LMA-REDIRECT, the MAG SHOULD parse the 179 Alternate LMA List Option, and extract the IPv6 addresses of the 180 LMA(s). 182 The MAG MUST then send a Proxy Binding Update message to the first 183 LMA address received in the Alternate LMA List Option, containing the 184 same information as the initial PBU message. 186 If the connection to the alternate LMA fails and the Status code is 187 not PMIPV6-LMA-REDIRECT, the Mobile node MUST select, if available, 188 the next LMAA address received in the initial PBA message. This 189 process continues until the exhaustion of the list of LMAs. 191 If the MAG receives a Proxy Binding acknowledgment message from an 192 alternate LMA with status code PMIPV6-LMA-REDIRECT, then this newly 193 received list of LMAs MUST override the previously received one. The 194 MAG MUST select the first LMA in the newly received list, and send it 195 a Proxy Binding Update message. 197 In general, each time a new redirect is received by the MAG it will 198 override the previously received redirect(s) if any and the MAG 199 always acts only upon the latest Alternate LMA List. 201 7. Operational Considerations 203 In case the Redirect Mobility Option is used for redirect purposes, 204 the potential LMA that can be returned to a MAG MUST be able to 205 handle the Home Prefix of the Home Address of the Mobile Node. 207 There could be a limit to how many redirects can be accepted by a MAG 208 before it gives up. This can be configured on the MAG. This doesn't 209 preclude the LMA from sending the Redirect Mobility Option. 211 It is possible that two or more LMAs can send redirects that can send 212 an MAG on a loop. This can be avoided by careful configuration of 213 the network. A protocol based solution is possible but will 214 unnecessarily complicate the MAG. 216 8. IANA Considerations 218 This document requests the assignment of the following status code 219 from the Mobile IPv6 parameters Status Codes registry located at 220 http://www.iana.org/assignments/mobility-parameters . 222 TBA2 PMIPV6-LMA-REDIRECT 224 This also requests the assignment of the following option code from 225 the Mobile IPv6 parameters Mobility Options registry located at 226 http://www.iana.org/assignments/mobility-parameters . 228 TBA3 Alternate LMAA List 230 9. Security Considerations 232 This document specifies an option in the proxy binding 233 acknowledgement message that redirects the MAG towards another LMA. 234 A malicious or compromised LMA can send this message to redirect an 235 MAG towards a possibly unavailable set of LMA addresses. 237 10. Normative References 239 [PMIPv6] Gundavelli, S., "Proxy Mobile IPv6", 240 draft-ietf-netlmm-proxymip6-11 (work in progress), 241 March 2007. 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 247 "Mobility Header Home Agent Switch Message", RFC 5142, 248 January 2008. 250 Authors' Addresses 252 Suresh Krishnan 253 Ericsson 254 8400 Decarie Blvd. 255 Town of Mount Royal, QC 256 Canada 258 Phone: +1 514 345 7900 x42871 259 Email: suresh.krishnan@ericsson.com 261 Samy Touati 262 Ericsson 263 8400 Decarie Blvd. 264 Town of Mount Royal, QC 265 Canada 267 Phone: +1 514 345 7900 x42366 268 Email: samy.touati@ericsson.com 270 Zu Qiang 271 Ericsson 272 8400 Decarie Blvd. 273 Town of Mount Royal, QC 274 Canada 276 Phone: +1 514 345 7900 x47370 277 Email: zu.qiang@ericsson.com 279 Full Copyright Statement 281 Copyright (C) The IETF Trust (2008). 283 This document is subject to the rights, licenses and restrictions 284 contained in BCP 78, and except as set forth therein, the authors 285 retain all their rights. 287 This document and the information contained herein are provided on an 288 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 289 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 290 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 291 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 292 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 295 Intellectual Property 297 The IETF takes no position regarding the validity or scope of any 298 Intellectual Property Rights or other rights that might be claimed to 299 pertain to the implementation or use of the technology described in 300 this document or the extent to which any license under such rights 301 might or might not be available; nor does it represent that it has 302 made any independent effort to identify any such rights. Information 303 on the procedures with respect to rights in RFC documents can be 304 found in BCP 78 and BCP 79. 306 Copies of IPR disclosures made to the IETF Secretariat and any 307 assurances of licenses to be made available, or the result of an 308 attempt made to obtain a general license or permission for the use of 309 such proprietary rights by implementers or users of this 310 specification can be obtained from the IETF on-line IPR repository at 311 http://www.ietf.org/ipr. 313 The IETF invites any interested party to bring to its attention any 314 copyrights, patents or patent applications, or other proprietary 315 rights that may cover technology that may be required to implement 316 this standard. Please address the information to the IETF at 317 ietf-ipr@ietf.org. 319 Acknowledgment 321 Funding for the RFC Editor function is provided by the IETF 322 Administrative Support Activity (IASA).