idnits 2.17.1 draft-ietf-mip4-message-string-ext-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 306. 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 (March 1, 2007) is 6260 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 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 V. Sastry 3 Internet-Draft Samsung Electronics 4 Intended status: Standards Track K. Leung 5 Expires: September 2, 2007 A. Patel 6 Cisco Systems 7 March 1, 2007 9 Mobile IPv4 Message String Extension 10 draft-ietf-mip4-message-string-ext-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 2, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies a new extension for use in Mobile IPv4. This 44 extension can be added by the Home Agent and the Foreign Agent to 45 Registration Reply messages. This extension carries a text string 46 that is intended for the user of the Mobile Node. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Mobile IPv4 Message String Extension Format . . . . . . . . . 5 53 4. Operation and Use of the Message String Extension . . . . . . 6 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 57 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 59 Intellectual Property and Copyright Statements . . . . . . . . . . 12 61 1. Introduction 63 This document specifies a new skippable extension that can be added 64 by the Foreign Agent and Home Agent in any registration message 65 targeted for the Mobile Node. Such a message may be either a 66 Registration Reply or Registration Revocation (i.e. co-located 67 Care-of Address mode). For the Registration Reply message, this 68 extension can be added regardless of whether the registration has 69 succeeded or failed. 71 The content of the text string in this extension and its usage by the 72 Mobile Node is implementation specific. The text string in this 73 extension is intended for the user of the Mobile Node. For example, 74 this message can be displayed on the Mobile Node's user interface, 75 logged, or handled in any other implementation dependent way, 76 depending on the form of the Mobile Node. 78 Typical contents of the text string will indicate a registration 79 failure reason, or give a welcome message on successful registration. 80 This is important as the failure reason code gives very limited 81 information for interpretation by the user of the Mobile Node. For 82 example, a string like "registration failed : Prepaid Quota for the 83 user is exhausted" can give a human readable description of the 84 result of Mobile IP registration. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 3. Mobile IPv4 Message String Extension Format 94 The Message String Extension conforms to the Short Extension format 95 specified for Mobile IPv4 [RFC3344]. The Message String Extension is 96 a skippable extension. 98 0 1 2 3 99 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 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Type | Length | Sub-Type | Text .... 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Type: 106 To be assigned by IANA. An 8-bit identifier of the type mobility 107 option. 109 Length: 111 8-bit unsigned integer. Length of the extension, in bytes, 112 excluding the extension Type and the extension Length fields. 113 This field MUST be set to 1 plus the total length of the Text 114 field. 116 Sub-Type: 118 1: 120 Extension comes from the Home Agent 122 2: 124 Extension comes from the Foreign Agent 126 Text: 128 The Text field is one or more octets, and its contents are 129 implementation dependent. It is intended to be human readable, 130 and MUST NOT affect operation of the protocol. The message MUST 131 be in UTF-8 encoded ISO-10646 [RFC3629] characters. The number of 132 octets in the encoded representation of the message is always 133 exactly the value of the Length field minus one. (In the UTF-8 134 case, the number of unicode characters represented by this octet 135 sequence may be smaller than the number of octets.) 137 4. Operation and Use of the Message String Extension 139 The Message String Extension is only valid for use within Mobile IPv4 140 Registration Reply and Registration Revocation messages. The Message 141 String Extension is a skippable extension. Either the Home Agent or 142 Foreign Agent or both can add the Message String Extension to 143 registration messages. The usage of Text field of the Message String 144 Extension is implementation dependent. For example, the message can 145 be displayed on the Mobile Node's user interface, logged, or handled 146 in an implementation dependent way, depending on the form of the 147 Mobile Node. The Mobile Node may throttle how often the user is 148 notified of the message. 150 As an example, the Home Agent may reject the first Registration 151 Request due to prepaid quota for the user is reached and may attach a 152 Message String Extension with the text "Prepaid quota reached. 153 Please contact www.paymore.example.com to update balance". The 154 Mobile Node could display this on the user interface. As a response, 155 the user of the Mobile Node may take the required action to update 156 the prepaid account and retry the registration process. The Home 157 Agent may accept this Registration Request and attach a Message 158 String Extension with the text "Welcome to 159 www.serviceprovider.example.com". The Mobile Node could display this 160 on the user interface thus confirming successful creation of binding 161 on Home Agent. 163 In the case that the message is not originated by the Home Agent 164 itself, but for instance is received from a RADIUS server [RFC2865], 165 it could be received in some other encoding than UTF-8. If so, the 166 Home Agent MUST convert the message to UTF-8 encoded ISO-10646 167 [RFC3629] characters. 169 5. Security Considerations 171 The Message String Extension can be added by the Home Agent or 172 Foreign Agent or both. The protection of the extension is based on 173 the ordering method specified for message authentication in RFC 3344 174 [RFC3344] and emphasized below. 176 If the extension is added by the Home Agent (extension with subtype 177 1) to a Registration Reply or Registration Revocation message, it 178 MUST appear before Mobile-Home Authentication Extension [RFC3344]. 180 If the extension is added by the Foreign Agent (extension with 181 subtype 2) to a Registration Reply message, it MUST appear after 182 Mobile-Home Authentication Extension [RFC3344] whenever present. 183 Also the extension MUST appear before the Mobile-Foreign 184 Authentication Extension whenever present. However, since security 185 association between the Mobile Node and Foreign Agent is optional, it 186 is possible that the extension is not authenticated in this case. 188 There is no confidentiality provided by the extension; the message is 189 transferred unencrypted, and if sensitive information is sent for 190 display purposes, it may need to be protected by other means. 192 6. IANA Considerations 194 This specification reserves one number for the Message String 195 Extension in Section 3 from the space of numbers for skippable 196 mobility extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] 197 at http://www.iana.org/assignments/mobileip-numbers. 199 The value 145 is suggested for this extension. 201 This specification also creates a new subtype space for the type 202 number of this extension. The subtype values 1 and 2 are defined in 203 this specification. The subtype value 1 is reserved for use by Home 204 Agent and subtype value 2 is reserved for use by Foreign Agent. 205 Similar to the procedures specified for Mobile IPv4 [RFC3344] number 206 spaces, future allocations from this number space require expert 207 review [RFC2434]. 209 7. Acknowledgements 211 The authors would like to thank Avi Lior, Curtis Provost and Henrik 212 Levkowetz for their useful comments on an earlier version of this 213 document. Also, Russ Housley, Vidya Narayanan, Blake Ramsdell, Paul 214 Hoffman, and Jeff Hutzelman provided justifications to mandate the 215 need for only UTF-8 encoding in the message and solicited better 216 clarifications in the security consideration section. 218 8. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 224 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 225 October 1998. 227 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 228 "Remote Authentication Dial In User Service (RADIUS)", 229 RFC 2865, June 2000. 231 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 232 August 2002. 234 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 235 10646", STD 63, RFC 3629, November 2003. 237 Authors' Addresses 239 Venkateshwara Sastry 240 Samsung Electronics 241 Bagmane Lake View, 'Block -B' 242 66/1, Bagmane Tech Park, Byrasandra, 243 C. V. Raman Nagar 244 Bangalpre 560093 245 India 247 Phone: +91-80-41819999 248 Email: venkat.s@samsung.com 250 Kent Leung 251 Cisco Systems 252 170 W. Tasman Drive 253 San Jose, CA 95134 254 US 256 Phone: +1 408-526-5030 257 Email: kleung@cisco.com 259 Alpesh Patel 260 Cisco Systems 261 170 W. Tasman Drive 262 San Jose, CA 95134 263 US 265 Phone: +1 408-853-9580 266 Email: alpesh@cisco.com 268 Full Copyright Statement 270 Copyright (C) The IETF Trust (2007). 272 This document is subject to the rights, licenses and restrictions 273 contained in BCP 78, and except as set forth therein, the authors 274 retain all their rights. 276 This document and the information contained herein are provided on an 277 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 278 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 279 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 280 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 281 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 282 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 284 Intellectual Property 286 The IETF takes no position regarding the validity or scope of any 287 Intellectual Property Rights or other rights that might be claimed to 288 pertain to the implementation or use of the technology described in 289 this document or the extent to which any license under such rights 290 might or might not be available; nor does it represent that it has 291 made any independent effort to identify any such rights. Information 292 on the procedures with respect to rights in RFC documents can be 293 found in BCP 78 and BCP 79. 295 Copies of IPR disclosures made to the IETF Secretariat and any 296 assurances of licenses to be made available, or the result of an 297 attempt made to obtain a general license or permission for the use of 298 such proprietary rights by implementers or users of this 299 specification can be obtained from the IETF on-line IPR repository at 300 http://www.ietf.org/ipr. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary 304 rights that may cover technology that may be required to implement 305 this standard. Please address the information to the IETF at 306 ietf-ipr@ietf.org. 308 Acknowledgment 310 Funding for the RFC Editor function is provided by the IETF 311 Administrative Support Activity (IASA).