idnits 2.17.1 draft-ietf-mip6-mn-ident-option-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 250. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 266), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** 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 33 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 144: '...ent, this option MUST appear before an...' RFC 2119 keyword, line 147: '...e Home Agent, it MUST be present in al...' RFC 2119 keyword, line 149: '...Binding Update, it MUST be included in...' 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 (December 9, 2004) is 7077 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 2486 (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Patel 3 Internet-Draft K. Leung 4 Expires: June 9, 2005 Cisco Systems 5 M. Khalil 6 H. Akhtar 7 Nortel Networks 8 K. Chowdhury 9 Starent Networks 10 December 9, 2004 12 MN Identifier Option for Mobile IPv6 13 draft-ietf-mip6-mn-ident-option-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 9, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 This document defines new mobility option to identify mobility 47 entities using identifiers other than the home IP address. This 48 option can be used in messages containing a mobility header. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. MN Identifier option . . . . . . . . . . . . . . . . . . . . . 5 55 3.1 MN-NAI mobility option . . . . . . . . . . . . . . . . . . 6 56 3.2 Processing Considerations . . . . . . . . . . . . . . . . 6 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 62 Intellectual Property and Copyright Statements . . . . . . . . 11 64 1. Introduction 66 The base specification of Mobile IPv6 [RFC3775] identifies mobility 67 entities using an IPv6 address. A mechanism is needed where in 68 mobility entities can be identified using other identifiers (for 69 example, a network access identifier (NAI) [RFC2486], International 70 Mobile Station Identifier (IMSI), an application/deployment specific 71 opaque identifier etc). Using other identities for a mobile node 72 (MN) permits various applicabilities, e.g. authentication using 73 existing infrastructure (AAA (Authentication, Authorization and 74 Accounting), HLR/AuC (Home Location Register/Authentication Center)), 75 dynamic allocation of a mobility anchor point, dynamic allocation of 76 an address etc. 78 This document defines an option with subtype number which identify a 79 specific type of identifier. One instance of subtype, the NAI is 80 defined in Section 3.1. It is expected that other types of 81 identifiers will be defined by other documents in the future. 83 2. Terminology 85 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 87 this document are to be interpreted as described in RFC 2119. 89 3. MN Identifier option 91 This section defines the Mobile Node Identifier option. Various 92 forms of identifiers can be used to identify a MN. Some examples 93 include a Network Access Identifier (NAI) [RFC2486], an opaque 94 identifier applicable to a particular application, etc. The sub-type 95 field in the option defines the specific type of identifier. 97 This option can be used in mobility messages containing a mobility 98 header. The subtype field in the option is used to interpret the 99 specific type of identifier. 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Option Type | Option Length | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Subtype | Identifier ... 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 Option Type: 111 MN-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier 112 of the type mobility option. 114 Option Length: 116 8-bit unsigned integer, representing the length in octets of 117 the Subtype and Identifier fields. 119 Subtype: 121 Subtype field defines the specific type of identifier included 122 in the identifier field. 124 Identifier: 126 A variable length identifier of type as specified by the 127 subtype field of this option. 129 Alignment requirements: 131 This option does not have any alignment requirements. 133 3.1 MN-NAI mobility option 135 The format of the MN-NAI mobility option is as defined in Section 3. 136 This option uses the subtype value of 1. The MN-NAI mobility option 137 is used to identify the mobile node. 139 The MN-NAI mobility option uses an identifier of the form user@realm 140 [RFC2486]. 142 3.2 Processing Considerations 144 When present, this option MUST appear before any authentication 145 enabling extension in a message containing a mobility header. Also, 146 if this option is present in the first Binding Update used to create 147 a binding cache entry at the Home Agent, it MUST be present in all 148 subsequent Binding Updates used to renew the binding cache entry. If 149 this option is present in the Binding Update, it MUST be included in 150 the corresponding reply (Binding Acknowledgement). 152 4. Security Considerations 154 None. This document defines new identifiers for a mobile node and 155 does not introduce new security threats. 157 5. IANA Considerations 159 IANA services are required for this document. The values for new 160 mobility options must be assigned from the Mobile IPv6 [RFC3775] 161 numbering space. 163 The values for Mobility Option types MN-ID-OPTION-TYPE as defined in 164 Section 3 need to be assigned. The suggested value is 7 for the 165 MN-ID-OPTION-TYPE. 167 IANA should record value for this new Mobility Option. 169 6. Acknowledgements 171 The authors would like to thank Basavaraj Patil for his review and 172 suggestions on this draft. 174 7 Normative References 176 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 177 RFC 2486, January 1999. 179 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 180 in IPv6", RFC 3775, June 2004. 182 Authors' Addresses 184 Alpesh Patel 185 Cisco Systems 186 170 W. Tasman Drive 187 San Jose, CA 95134 188 US 190 Phone: +1 408-853-9580 191 EMail: alpesh@cisco.com 193 Kent Leung 194 Cisco Systems 195 170 W. Tasman Drive 196 San Jose, CA 95134 197 US 199 Phone: +1 408-526-5030 200 EMail: kleung@cisco.com 202 Mohamed Khalil 203 Nortel Networks 204 2221 Lakeside Blvd. 205 Richardson, TX 75082 206 US 208 Phone: +1 972-685-0574 209 EMail: mkhalil@nortelnetworks.com 210 Haseeb Akhtar 211 Nortel Networks 212 2221 Lakeside Blvd. 213 Richardson, TX 75082 214 US 216 Phone: +1 972-684-4732 217 EMail: haseebak@nortelnetworks.com 219 Kuntal Chowdhury 220 Starent Networks 221 2540 Coolwater Dr. 222 Plano, TX 75025 223 US 225 Phone: +1 214 550 1416 226 EMail: kchowdury@starentnetworks.com 228 Intellectual Property Statement 230 The IETF takes no position regarding the validity or scope of any 231 Intellectual Property Rights or other rights that might be claimed to 232 pertain to the implementation or use of the technology described in 233 this document or the extent to which any license under such rights 234 might or might not be available; nor does it represent that it has 235 made any independent effort to identify any such rights. Information 236 on the procedures with respect to rights in RFC documents can be 237 found in BCP 78 and BCP 79. 239 Copies of IPR disclosures made to the IETF Secretariat and any 240 assurances of licenses to be made available, or the result of an 241 attempt made to obtain a general license or permission for the use of 242 such proprietary rights by implementers or users of this 243 specification can be obtained from the IETF on-line IPR repository at 244 http://www.ietf.org/ipr. 246 The IETF invites any interested party to bring to its attention any 247 copyrights, patents or patent applications, or other proprietary 248 rights that may cover technology that may be required to implement 249 this standard. Please address the information to the IETF at 250 ietf-ipr@ietf.org. 252 Disclaimer of Validity 254 This document and the information contained herein are provided on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 257 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 258 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 259 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 Copyright Statement 264 Copyright (C) The Internet Society (2004). This document is subject 265 to the rights, licenses and restrictions contained in BCP 78, and 266 except as set forth therein, the authors retain all their rights. 268 Acknowledgment 270 Funding for the RFC Editor function is currently provided by the 271 Internet Society.