idnits 2.17.1 draft-kempf-mip6-ha-alert-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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 390), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 153 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 332, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IPv6 J. Kempf 2 Internet Draft DoCoMo USA Labs 3 Expires: October,2005 Feburary, 2005 5 Extension to RFC 3775 for Alerting the Mobile Node to Home Agent 6 Unavailability 7 draft-kempf-mip6-ha-alert-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on July 28, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 RFC 3775 contains no way for a home agent to notify a mobile node 41 that the home agent will shortly become unavailable, and suggest 42 possible substitutes. A mobile node can suddenly find itself without 43 mobility service. This document describes a simple protocol to inform 44 the mobile node when its home agent is about to become unavailable 46 Kempf Expires October, 2005 Page [1] 47 and whether the mobile node should re-run bootstrapping to find a new 48 home agent. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC-2119 [1]. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Scenarios......................................................3 60 2.1. Periodic Maintenance......................................3 61 2.2. Functional Load Balancing.................................3 62 2.3. Home Agent Renumbering....................................4 63 3. Home Agent Unavailability Message..............................4 64 3.1. Validation of HAU Messages................................4 65 3.2. Home Agent Unavailability Message Format..................5 66 4. Home Agent Considerations......................................6 67 5. Mobile Node Considerations.....................................6 68 6. Security Considerations........................................7 69 7. Open Questions.................................................7 70 8. References.....................................................8 71 8.1. Normative References......................................8 72 8.2. Informative References....................................8 73 Author's Addresses................................................8 74 Intellectual Property Statement...................................8 75 Disclaimer of Validity............................................9 76 Copyright Statement...............................................9 77 Acknowledgment....................................................9 79 1. Introduction 81 RFC 3775 [2] contains no protocol to allow a home agent to inform its 82 mobile nodes that it is about to cease service. Without such 83 functionality, a mobile node can suddenly find itself without its 84 tunneled traffic. Even worse, if the mobile node is route optimizing, 85 it may not discover the problem until much later, after other nodes 86 fail to contact it. 88 Note that, as a router on the home link, the home agent can use an 89 unmodified RFC 2461 [2] Redirect to tell the mobile node about a new 90 router on the home link, but the message is ambiguous. Is the 91 recommended router a home agent or it just a router only for nodes on 92 the home link? What if the entire link is going down? RFC 2461 only 93 allows routers to be referred to by their link local address in 94 Redirects, which would not allow a mobile node away from home to find 95 the new home agent. A home agent can also send a Router Advertisement 96 with lifetime zero to indicate that it was becoming unavailable, but 97 this would not provide the mobile node with any indication of a 98 suggested substitute. 100 In this document, a simple extension of the RFC 3775 Home Agent 101 Discovery message is proposed to allow home agent unavailability 102 alerting. The extension allows a home agent to send an unsolicited 103 Home Agent Discovery message to inform the mobile node about the need 104 to find a new home agent. 106 2. Scenarios 108 Here are a few sample scenarios where a home agent unavailability 109 alerting message would be useful. 111 2.1. Periodic Maintenance 113 Although many users and engineers would prefer that networking 114 equipment run without ever shutting down, most responsible service 115 providers do periodic maintenance in order to maintain reliability. 116 If a home agent is shut down for maintenance, some way is required to 117 tell the client mobile nodes so they don't lose mobility service. 119 2.2. Functional Load Balancing 121 A Mobile IPv6 home agent provides the client with two basic services: 122 a rendezvous server where correspondents can find the current care of 123 address for the mobile node, and - when route optimization isn't used 124 - an overlay router to redirect traffic sent to/from the home address 125 to/from the care of address. A mobility service provider could have 126 two sets of home agents to handle the two functions. The rendezvous 127 function could be handled by a machine specialized for high speed 128 transaction processing, while the overlay router function could be 129 handled by a machine with high data throughput. 131 A mobile node would start on the rendezvous server-like home agent 132 and stay there if it does route optimization. However, if the 133 original home agent detects that the mobile node isn't doing route 134 optimization, it could redirect the mobile node to a home agent with 135 better data throughput (of course, any existing TCP sessions would be 136 dropped). 138 2.3. Home Agent Renumbering 140 Periodically, a mobility service provider may want to shut down home 141 agent service at a set of IPv6 addresses and bring service back up at 142 a new set of addresses. Note that this may not involve anything as 143 complex as IPv6 network renumbering, it may just involve changing the 144 addresses on the home agents. There are various reasons why a 145 mobility service provider might want to do this; an example is if the 146 mobility service provider revokes the account of a user who the 147 service provider has reason to believe might use the old home agent 148 address to disrupt service for other users. With a service 149 unavailability message, the service provider could inform mobile 150 nodes to look for a new home agent. 152 3. Home Agent Unavailability Message 154 A home agent sends a Home Agent Unavailability (HAU) message when an 155 anticipated period of unavailability occurs for the home agent. The 156 message is sent to the mobile node's home address and is tunneled to 157 the mobile node at its care of address. 159 3.1. Validation of HAU Messages 161 A mobile node MUST silently discard a received HAU message that does 162 not satisfy all of the following validity checks: 164 - IP Source Address is the global home agent address 166 - The message is covered by the IPsec ESP SAs for ICMP messages 167 between the home agent and mobile node. 169 - IP Destination Address is the mobile node's home address. 171 - ICMP Checksum is valid. 173 - ICMP Code is TBD. 175 - ICMP length (derived from the IP length) is 8 or more octets. 177 - All included options have a length that is greater than 178 zero. 180 The contents of the Reserved field, and of any unrecognized options 181 MUST be ignored. 183 3.2. Home Agent Unavailability Message Format 185 Home agents send HAU packets to inform mobile node clients about 186 pending periods of unavailability. The home agent can recommend a 187 list of substitute home agent addresses, or it can require the mobile 188 node to re-initiate bootstrapping to find a new home agent by setting 189 the length of the substitute list to zero. 191 0 1 2 3 193 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Code | Checksum | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Reserved | Number of Addresses | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | 201 + Home Agent Address List... 202 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Options ... 205 +-+-+-+-+-+-+-+-+-+-+-+- 207 IP Fields: 209 Source Address 211 MUST be the home agent's global address. 213 Destination Address 215 MUST be the mobile node's home address. 217 ESP Header 219 The packet MUST be protected by an ESP tunnel 220 mode header for data origin authentication and 221 encryption, used to protect ICMP packets between 222 the home agent and mobile node. 224 ICMP Fields: 226 Type 145 227 Code TBD (assigned by IANA) 229 Checksum The ICMP checksum 231 Reserved This field is unused. It MUST be initialized to 232 zero by the sender and MUST be ignored by the 233 receiver. 235 Number of Addresses 237 An unsigned integer giving the number of IPv6 238 home agent addresses in the list to follow. If 239 zero, then the mobile node MUST redo home agent 240 discovery. 242 Home Agent Address List 244 List of 128 bit IPv6 addresses for suggested 245 substitute home agents. 247 Possible Options: 249 There are no default options. Options can be added by extension. 251 4. Home Agent Considerations 253 A home agent SHOULD send a HAU message when a known period of 254 unavailability is pending. The message MUST be sent to all mobile 255 nodes with currently active bindings. If alternative home agent 256 addresses are known, either on the same subnet or a different one, 257 the home agent SHOULD include them in the list of suggested 258 substitute home agents. Otherwise, the home agent MUST set the length 259 of the substitute home agent list to zero, forcing the mobile node to 260 perform home agent discovery by some other means. 262 5. Mobile Node Considerations 264 Upon receipt of a HAU message, a mobile node MUST cease utilizing the 265 old home agent for overlay traffic routing. If the HAU message 266 contains a list of substitute home agents, the mobile node SHOULD 267 select a home agent at random and establish the necessary IPsec 268 security associations with the new home agent by whatever means 269 required as part of the mobile node/home agent bootstrapping protocol 270 for the home agent's mobility service provider. If no substitute home 271 agents are included in the list, the mobile node MUST first perform 272 home agent discovery. 274 6. Security Considerations 276 As with other home link ICMP messages in RFC 3775, the HAU message 277 MUST use the home agent to mobile node ESP encryption SA for 278 confidentiality protection, and MUST use the home agent to mobile 279 node ESP authentication SA for integrity protection. 281 IANA Considerations 283 A new ICMP Code, TBD, is required for the ICMP Home Agent Discovery 284 message, type 145. 286 7. Open Questions 288 - If a home agent has a lot of clients, the IKE traffic and 289 binding updates to the new home agent or agents could result 290 in a lot of congestion. Would it make sense to enable a mode 291 whereby the home agent can transfer the security and binding 292 context to the new home agents, then set a flag in the HAU 293 so that the mobile nodes don't have to re-initialize? 294 Generally, transferring IPsec between hosts ("outside the 295 crypto boundary") is strongly frowned upon by security 296 folks, but one could make an argument that a distributed 297 crypto boundary in which the machines share a strong 298 security association could be set up. The other problem is 299 what new home address to use. One could specify something 300 simple, like the old interface identifier plus subnet prefix 301 from the new home agent subnet, but that disallows subtle 302 address allocation strategies such as CGA or RFC 3041 303 address privacy. All in all, it seems like a hack. Sme kind 304 of timing randomization on the initialization traffic would 305 reduce the potential for congestion, but not the overall 306 traffic volume. 308 - If a home agent has lots of clients, it could end up 309 unicasting lots of HAU messages, which could result in a lot 310 of traffic and thus congestion. Would it make more sense to 311 use a multicast message, perhaps to the All Nodes Multicast 312 Address? Or should we introduce an All Mobile Nodes 313 Multicast Address to avoid having fixed nodes on the subnet 314 get the message? If multicast is used, then what security is 315 on the packet? IPsec is for unicast only, so the ICMP SA 316 can't be used. 318 - Should the HAU include a "remaining lifetime" field, 319 indicating how long the mobile node has before the home 320 agent becomes unavailable? 322 8. References 324 8.1. Normative References 326 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 327 Levels", BCP 14, RFC 2119, March 1997. 329 [2] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 330 IPv6", RFC 3775, June, 2004. 332 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 333 for IP Version 6 (IPv6)", RFC 2461, December 1998 335 8.2. Informative References 337 Author's Addresses 339 James Kempf 340 DoCoMo USA Labs 341 181 Metro Drive 342 Suite 300 343 San Jose, CA 344 95110 346 Phone: +1 408 451 4711 347 Email: kempf@docomolabs-usa.com 349 Intellectual Property Statement 351 The IETF takes no position regarding the validity or scope of any 352 Intellectual Property Rights or other rights that might be claimed to 353 pertain to the implementation or use of the technology described in 354 this document or the extent to which any license under such rights 355 might or might not be available; nor does it represent that it has 356 made any independent effort to identify any such rights. Information 357 on the procedures with respect to rights in RFC documents can be 358 found in BCP 78 and BCP 79. 360 Copies of IPR disclosures made to the IETF Secretariat and any 361 assurances of licenses to be made available, or the result of an 362 attempt made to obtain a general license or permission for the use of 363 such proprietary rights by implementers or users of this 364 specification can be obtained from the IETF on-line IPR repository at 365 http://www.ietf.org/ipr. 367 The IETF invites any interested party to bring to its attention any 368 copyrights, patents or patent applications, or other proprietary 369 rights that may cover technology that may be required to implement 370 this standard. Please address the information to the IETF at 371 ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that 372 any applicable patent or other IPR claims of which I am aware have 373 been disclosed, and any of which I become aware will be disclosed, in 374 accordance with RFC 3668. 376 Disclaimer of Validity 378 This document and the information contained herein are provided on an 379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 381 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 382 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 383 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 Copyright Statement 388 Copyright (C) The Internet Society (2004). This document is subject 389 to the rights, licenses and restrictions contained in BCP 78, and 390 except as set forth therein, the authors retain all their rights. 392 Acknowledgment 394 Funding for the RFC Editor function is currently provided by the 395 Internet Society.