idnits 2.17.1 draft-devarapalli-netlmm-pmipv6-heartbeat-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 344. 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 19, 2008) is 5908 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-proxymip6-10 ** Obsolete normative reference: RFC 4306 (ref. '4') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group V. Devarapalli 3 Internet-Draft H. Lim 4 Intended status: Standards Track N. Kant 5 Expires: August 22, 2008 Azaire Networks 6 S. Krishnan 7 Ericsson 8 February 19, 2008 10 Heartbeat Mechanism for Proxy Mobile IPv6 11 draft-devarapalli-netlmm-pmipv6-heartbeat-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 22, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 Proxy Mobile IPv6 is a network-based mobility management protocol. 45 The mobility entities involved in the Proxy Mobile IPv6 protocol, the 46 Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), 47 setup tunnels dynamically to manage mobility for a mobile node within 48 the Proxy Mobile IPv6 domain. This document describes a heartbeat 49 mechanism between the MAG and the LMA to detect failures quickly and 50 take appropriate action. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Failure Detection . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . . . 9 68 1. Introduction 70 Proxy Mobile IPv6 enables network-based mobility for IPv6 hosts that 71 do not implement any mobility protocols. The protocol is described 72 in detail in [2]. The Local Mobility Anchor (LMA) acts the anchor 73 for the mobile node sessions as long as the mobile node is attached 74 to the Proxy Mobile IPv6 domain. For the definition of Proxy Mobile 75 IPv6 domain, see [2]. The mobile node is at any time attached to a 76 Mobile Access Gateway (MAG) that manages mobility for the mobile 77 node. The MAG and the LMA set up IP-in-IP tunnels to tunnel all 78 traffic that belongs to the mobile node. 80 If the LMA crashes or if there is a communication problem on the path 81 between the MAG and the LMA, the MAG discovers this only when it 82 sends the next proxy Binding Update and gets no response from the 83 LMA. If a MAG becomes unreachable, the LMA can detect it only when 84 it starts receiving ICMP unreachable messages from an intermediate 85 router in response to data traffic the LMA tunnels to the MAG. For 86 some deployments of Proxy Mobile IPv6, it is desirable to detect the 87 LMA or the MAG reachability failure very early, so that appropriate 88 action could be taken. The appropriate actions, for example, 89 releasing resources, is out of scope for this document. 91 This document proposes a heartbeat mechanism between the MAG and the 92 LMA to detect the current status of reachability between them. The 93 heartbeat message is a mobility header message (protocol type 135). 94 The MAG and the LMA exchange heartbeat messages every few seconds to 95 detect if the other end is still reachable. The interval between 96 consecutive heartbeats is configurable. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [1]. 104 3. Heartbeat Mechanism 106 The MAG and the LMA exchange heartbeat messages every 107 HEARTBEAT_INTERVAL seconds to detect the current status of 108 reachability between them. A MAG typically initiates the heartbeat 109 exchange by sending a Heartbeat Request to the LMA. Each Heartbeat 110 Request contains a sequence number that is incremented sequentially. 111 The sequence number on the last Heartbeat Request message is always 112 recorded by the MAG. The HEARTBEAT_INTERVAL is carried in the 113 Heartbeat Request message. The Heartbeat message is described in 114 more detail in Section 3.2. 116 A heartbeat message can be sent only if the MAG has at least one 117 proxy binding cache entry at the LMA for a mobile node attached to 118 the MAG. If there are no proxy binding cache entries at the LMA for 119 any of the mobile nodes attached to the MAG, then the heartbeat 120 messages MUST NOT be sent. 122 When the LMA receives a Heartbeat Request message, it responds with a 123 Heartbeat Response message. The sequence number and the heartbeat 124 interval in the Heartbeat Request message are recorded on the LMA. 125 The LMA copies the sequence number from the Heartbeat Request message 126 onto the Heartbeat Response message. The Heartbeat Interval field is 127 set to 0 in the Heartbeat Response message. 129 The HEARTBEAT_INTERNAL SHOULD NOT be configured to a value less than 130 30 seconds. Sending heartbeat messages too often may become an 131 overhead on the path between the MAG and the LMA. 133 The LMA MAY also send a one-time Heartbeat Request message to the MAG 134 to check a MAG's reachability status. The Heartbeat Interval in the 135 Heartbeat Request message is set to 0 to indicate that it is a one- 136 time message and is not transmitted periodically. If a MAG receives 137 a Heartbeat Request message from the LMA, it MUST respond with a 138 Heartbeat Response message. 140 If the LMA or the MAG do not support the heartbeat messages, they 141 should respond with an ICMP Parameter Problem, Code 0, message to the 142 initiator. The 'Pointer' field in the ICMP Parameter Problem message 143 SHOULD point to the 'MH Type' field, indicating that the particular 144 Mobility Header message is not supported. When the ICMP Parameter 145 Problem message is received in response to Heartbeat Request message, 146 the initiating MAG or the LMA MUST NOT use heartbeat messages with 147 the other end again. 149 3.1. Failure Detection 151 If the MAG does not receive more than MISSING_HEARTBEATS_ALLOWED 152 number of responses from the LMA, it concludes that the LMA is not 153 reachable. The MISSING_HEARTBEATS_ALLOWED value is configurable on 154 the MAG. The MAG may then take appropriate action (out of scope for 155 this document). 157 The LMA also has a MISSING_HEARTBEATS_ALLOWED counter configured per 158 MAG. The LMA knows how often to expect a heartbeat message from the 159 MAG based on the Heartbeat Interval in the first Heartbeat Request 160 message received from the MAG. If the LMA does not receive more than 161 MISSING_HEARTBEATS_ALLOWED Heartbeat Request messages from the MAG, 162 it concludes that the MAG is not reachable. 164 The LMA may also optionally send a Heartbeat Request message to the 165 MAG before concluding that the MAG is unreachable. The Heartbeat 166 Interval value is set to 0 to indicate that this is a one-time 167 heartbeat message and is not sent periodically. If the LMA does not 168 get a response from the MAG, it re-transmits the Heartbeat Request 169 message. The number of times the Heartbeat Request is re-transmitted 170 is configurable on the LMA. If a response from the MAG is received, 171 then the LMA concludes that the MAG is reachable and resets the 172 MISSING_HEARTBEATS_ALLOWED counter for the particular MAG. 174 3.2. Heartbeat Message 176 The following illustrates the message format for the Heartbeat 177 Mobility Header message. The 'MH Type' field in the Mobility Header 178 indicates that it is a Heartbeat message. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Reserved | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Sequence Number | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Heartbeat Interval | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Type 192 A 8-bit field that indicates whether the message is a request or a 193 response. A value of '1' indicates that it is a request. A value 194 of '2' indicates that it is a response. 196 Reserved 198 A 8-bit field set to 0 and ignored by the receiver. 200 Sequence Number 202 A 32-bit sequence number used for matching the request to the 203 reply. 205 Heartbeat Interval 207 A 32-bit value indicating the interval in seconds between two 208 consecutive heartbeat messages. A value of 0 indicates that the 209 Heartbeat message is just a one-time message and not sent 210 periodically. 212 4. Security Considerations 214 The heartbeat messages are just used for checking reachability 215 between the MAG and the LMA. They do not carry information that is 216 useful for eavesdroppers on the path. Integrity protection using 217 IPsec [3] for the heartbeat messages MUST be supported on the MAG and 218 the LMA. The use of IPsec protection is optional. Confidentiality 219 protection is not required. 221 For dynamic key negotiation between the MAG and the LMA, IKEv2 [4] 222 SHOULD be used. 224 5. IANA Considerations 226 The Heartbeat message defined in Section 3.2 must have the type value 227 allocated from the same space as the 'MH Type' field in the Mobility 228 Header defined in RFC 3775 [5]. 230 6. Acknowledgments 232 A heartbeat mechanism for a network-based mobility management 233 protocol was first described in [6]. The authors would like to thank 234 the members of a NETLMM design team that produced that document. The 235 mechanism described in this document also derives from the path 236 management mechanism described in [7]. 238 We would also like to thank Alessio Casati for first suggesting a 239 fault handling mechanism for Proxy Mobile IPv6. 241 7. References 243 7.1. Normative References 245 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 246 Levels", BCP 14, RFC 2119, March 1997. 248 [2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 249 B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 250 (work in progress), February 2008. 252 [3] Kent, S. and K. Seo, "Security Architecture for the Internet 253 Protocol", RFC 4301, December 2005. 255 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 256 December 2005. 258 7.2. Informative References 260 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 261 IPv6", RFC 3775, June 2004. 263 [6] Giaretta, G., "The NetLMM Protocol", 264 draft-giaretta-netlmm-dt-protocol-02 (work in progress), 265 October 2006. 267 [7] 3rd Generation Parternship Project, "3GPP Technical 268 Specification 29.060 V7.6.0: "Technical Specification Group Core 269 Network and Terminals; General Packet Radio Service (GPRS); GPRS 270 Tunnelling Protocol (GTP) across the Gn and Gp interface 271 (Release 7)"", July 2007. 273 Authors' Addresses 275 Vijay Devarapalli 276 Azaire Networks 277 3121 Jay Street 278 Santa Clara, CA 95054 279 USA 281 Email: vijay.devarapalli@azairenet.com 283 Heeseon Lim 284 Azaire Networks 285 3121 Jay Street 286 Santa Clara, CA 95054 287 USA 289 Email: heeseon.lim@azairenet.com 290 Nishi Kant 291 Azaire Networks 292 3121 Jay Street 293 Santa Clara, CA 95054 294 USA 296 Email: nishi.kant@azairenet.com 298 Suresh Krishnan 299 Ericsson 300 8400 Decarie Blvd. 301 Town of Mount Royal, QC 302 Canada 304 Email: suresh.krishnan@ericsson.com 306 Full Copyright Statement 308 Copyright (C) The IETF Trust (2008). 310 This document is subject to the rights, licenses and restrictions 311 contained in BCP 78, and except as set forth therein, the authors 312 retain all their rights. 314 This document and the information contained herein are provided on an 315 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 316 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 317 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 318 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 319 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 322 Intellectual Property 324 The IETF takes no position regarding the validity or scope of any 325 Intellectual Property Rights or other rights that might be claimed to 326 pertain to the implementation or use of the technology described in 327 this document or the extent to which any license under such rights 328 might or might not be available; nor does it represent that it has 329 made any independent effort to identify any such rights. Information 330 on the procedures with respect to rights in RFC documents can be 331 found in BCP 78 and BCP 79. 333 Copies of IPR disclosures made to the IETF Secretariat and any 334 assurances of licenses to be made available, or the result of an 335 attempt made to obtain a general license or permission for the use of 336 such proprietary rights by implementers or users of this 337 specification can be obtained from the IETF on-line IPR repository at 338 http://www.ietf.org/ipr. 340 The IETF invites any interested party to bring to its attention any 341 copyrights, patents or patent applications, or other proprietary 342 rights that may cover technology that may be required to implement 343 this standard. Please address the information to the IETF at 344 ietf-ipr@ietf.org. 346 Acknowledgment 348 Funding for the RFC Editor function is provided by the IETF 349 Administrative Support Activity (IASA).