idnits 2.17.1 draft-haley-mip6-mh-signaling-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 227. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 243), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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.) -- The document date (February 2005) is 7010 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) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2463 (ref. '3') (Obsoleted by RFC 4443) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IPv6 2 Internet Draft B. Haley 3 Document: draft-haley-mip6-mh-signaling-00.txt Hewlett-Packard 4 Company 5 Expires: July, 2005 February 2005 7 Mobility Header Signaling Message 8 draft-haley-mip6-mh-signaling-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 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 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document specifies a new Mobility Header message type that can 40 be used between a mobile node and home agent to signal an event that 41 requires attention. 43 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119 [1]. 48 Table of Contents 50 1. Introduction...................................................2 51 2. Mobility Header Signaling Message..............................3 52 3. Sending Signaling Messages.....................................4 53 4. Receiving Signaling Messages...................................4 54 5. IANA Considerations............................................4 55 6. Security Considerations........................................5 56 7. References.....................................................5 57 7.1. Normative References......................................5 58 7.2. Informative references....................................5 59 Acknowledgments...................................................5 60 Author's Addresses................................................5 62 1. Introduction 64 RFC 3775 [2] contains no provision to allow a home agent to inform a 65 mobile node, or vice-versa, that there is an event that requires its 66 attention. For example, a home agent may wish to handoff some of its 67 mobile nodes to another home agent because it has come overloaded or 68 it is going offline. 70 This protocol describes a generic signaling message type that can be 71 used to send messages between home agents and mobile nodes securely. 73 This protocol does not describe the type of messages that might be 74 exchanged, that information should be defined in the document for the 75 specific Mobility option that will be used. 77 2. Mobility Header Signaling Message 79 The Mobility Header Signaling message is used by the home agent to 80 signal the mobile node, or vice-versa, that there is an event that 81 requires attention. Signaling messages are sent as described in 82 Section 3. 84 The message described below follows the Mobility Header format 85 specified in Section 6.1 of [2]: 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Payload Proto | Header Len | MH Type | Reserved | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Checksum | | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 92 | | 93 . . 94 . Message Data . 95 . . 96 | | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 The Signaling Message uses the MH Type value 8 (TBD). When this 100 value is indicated in the MH Type field, the format of the Message 101 Data field in the Mobility Header is as follows: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Reserved | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | 109 . . 110 . Mobility options . 111 . . 112 | | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Reserved 117 16-bit field reserved for future use. The value MUST be 118 initialized to zero by the sender, and MUST be ignored by the 119 receiver. 121 Mobility options 123 Variable-length field of such length that the complete Mobility 124 Header is an integer multiple of 8 octets long. This field 125 contains zero of more TLV-encoded mobility options. The encoding 126 and format of defined options MUST follow the format specified in 127 Section 6.2 of [2]. The receiver MUST ignore and skip any options 128 with it does not understand. 130 This specification does not define any options valid for the 131 Signaling message. 133 If no options are present in this message, no padding is necessary 134 and the Header Len field in the Mobility Header will be set to 0. 136 3. Sending Signaling Messages 138 When sending a Signaling message, the sending node constructs the 139 packet as it would any other Mobility Header, except the MH Type 140 field MUST be set to 8 (TBD). 142 Signaling messages SHOULD be subject to rate limiting in the same 143 manner as is done for ICMPv6 messages [3]. 145 4. Receiving Signaling Messages 147 Upon receiving a Signaling message, the Mobility Header MUST be 148 verified as specified in [2], specifically: 150 o The Checksum, MH type, Payload Proto and Header Len fields 151 MUST meet the requirements of Section 9.2 of [2]. 153 o The packet MUST be covered by the IPsec ESP SA in place for 154 Binding Updates and Acknowledgements (Section 5.1 of [2]). 156 If the packet is dropped due to the above tests, the receiving node 157 MUST follow the processing rules as Section 9.2 of [2] defines. For 158 example, it MUST send a Binding Error message with the Status field 159 set to 2 (unrecognized MH Type value) if it does not support the 160 message type. 162 5. IANA Considerations 164 A new Mobility Header type is required for the following new message 165 described in Section 2: 167 8 Signaling message 169 6. Security Considerations 171 As with other messages in [2], the Signaling message MUST use the 172 home agent to mobile node ESP encryption SA for confidentiality 173 protection, and MUST use the home agent to mobile node ESP 174 authentication SA for integrity protection. 176 7. References 178 7.1. Normative References 180 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 181 Levels", BCP 14, RFC 2119, March 1997 183 [2] Johnson, D. Perkins, C., and Arkko, J., "Mobility Support in 184 IPv6", RFC 3775, June, 2004. 186 [3] Conta, A. and S. Deering, "Internet Control Message Protocol 187 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 188 Specification", RFC 2463, December 1998. 190 7.2. Informative references 192 Acknowledgments 194 Thanks to Hui Deng, James Kempf and Vijay Devarapalli for their 195 initial review of the draft. 197 Author's Addresses 199 Brian Haley 200 Hewlett-Packard Company 201 110 Spitbrook Road 202 Nashua, NH 03062, USA 203 Email: Brian.Haley@hp.com 205 Intellectual Property Statement 207 The IETF takes no position regarding the validity or scope of any 208 Intellectual Property Rights or other rights that might be claimed to 209 pertain to the implementation or use of the technology described in 210 this document or the extent to which any license under such rights 211 might or might not be available; nor does it represent that it has 212 made any independent effort to identify any such rights. Information 213 on the procedures with respect to rights in RFC documents can be 214 found in BCP 78 and BCP 79. 216 Copies of IPR disclosures made to the IETF Secretariat and any 217 assurances of licenses to be made available, or the result of an 218 attempt made to obtain a general license or permission for the use of 219 such proprietary rights by implementers or users of this 220 specification can be obtained from the IETF on-line IPR repository at 221 http://www.ietf.org/ipr. 223 The IETF invites any interested party to bring to its attention any 224 copyrights, patents or patent applications, or other proprietary 225 rights that may cover technology that may be required to implement 226 this standard. Please address the information to the IETF at 227 ietf-ipr@ietf.org. 229 Disclaimer of Validity 231 This document and the information contained herein are provided on an 232 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 233 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 234 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 235 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 236 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 237 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 239 Copyright Statement 241 Copyright (C) The Internet Society (2004). This document is subject 242 to the rights, licenses and restrictions contained in BCP 78, and 243 except as set forth therein, the authors retain all their rights. 245 Acknowledgment 247 Funding for the RFC Editor function is currently provided by the 248 Internet Society.