idnits 2.17.1 draft-ietf-mip6-nai-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 29 has weird spacing: '... The list ...' == Line 60 has weird spacing: '...AI can have ...' == Line 62 has weird spacing: '...xisting authe...' == Line 126 has weird spacing: '...tension in a...' == Line 156 has weird spacing: '... any copyr...' == (2 more instances...) -- 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) ** Obsolete normative reference: RFC 2486 (ref. '2') (Obsoleted by RFC 4282) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Alpesh Patel 3 INTERNET DRAFT Kent Leung 4 July 2004 Cisco System Inc. 5 Haseeb Akhtar 6 Mohamed Khalil 7 Kuntal Chowdhury 8 Nortel Networks 10 Network Access Identifier Option for Mobile IPv6 11 draft-ietf-mip6-nai-option-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 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 Abstract 37 This document defines new mobility option to identify mobility 38 entities using a network access identifier. This option can be 39 used in messages containing a mobility header. 41 Table of Contents 43 1. Introduction....................................................2 44 2. Terminology.....................................................2 45 3. NAI Mobility option.............................................2 46 3.1 MN-NAI mobility option.........................................3 47 3.2 Processing Considerations......................................3 48 4. IANA Considerations.............................................3 49 6. Intellectual Property Rights....................................4 50 7. Acknowledgements................................................4 51 8. References......................................................4 52 9. Contact Information.............................................4 53 Full Copyright Statement...........................................6 55 1. Introduction 57 The base specification of Mobile IPv6 [1] identifies mobility 58 entities using an IPv6 address. A mechanism is needed where in 59 mobility entities can be identified using a network access 60 identifier (NAI). NAI can have varied applicability, for 61 instance, can be used to authenticate mobility entities using 62 existing authentication infrastructure (AAA), to dynamically 63 allocate a mobility anchor point, to dynamically allocate an 64 address etc. 66 2. Terminology 68 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 69 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 70 "OPTIONAL" in this document are to be interpreted as described in 71 RFC 2119 [2]. 73 3. NAI Mobility option 75 This section defines the NAI mobility option that may be used in 76 Binding Update and Binding Acknowledgement messages. It is used 77 to identify the mobility entity using an identifier of the form 78 user@realm [2]. 80 This document also defines some subtype numbers, which identify 81 the specific type of NAI carried in Section 3.1. It is expected 82 that other types of NAI will be defined by other documents in the 83 future. 85 0 1 2 3 86 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 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Option Type | Option Length | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Subtype | NAI... 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 Option Type 95 NAI-OPTION-TYPE to be defined by IANA. An 8-bit identifier of the 96 type mobility option. 98 Option Length 100 8-bit unsigned integer, representing the length in octets of the 101 subtype and NAI, not including the Option Type and Option Length 102 fields. 104 Subtype 106 Subtype field defines the type of NAI, identifying the mobility 107 entity. 109 NAI 111 A string of form user@realm as defined in [2]. 113 Alignment requirements 115 117 3.1 MN-NAI mobility option 119 The format of the MN-NAI mobility option is as defined in 120 section 3. This option uses the subtype value of 1. The MN-NAI 121 option is used to identify the mobile node. 123 3.2 Processing Considerations 125 This option must appear before any authentication enabling 126 extension in a message containing a mobility header. NAI 127 Mobility option can be used to identify the mobile node for 128 authentication. 130 4. IANA Considerations 131 The option type NAI-OPTION-TYPE is defined in section 3.1 is a 132 new mobility option. 134 IANA should record a value for this new mobility option. 136 5. Security Considerations 138 6. Intellectual Property Rights 140 The IETF takes no position regarding the validity or scope of 141 any intellectual property or other rights that might be claimed 142 to pertain to the implementation or use of the technology 143 described in this document or the extent to which any license 144 under such rights might or might not be available; neither does 145 it represent that it has made any effort to identify any such 146 rights. Information on the IETF's procedures with respect to 147 rights in standards-track and standards-related documentation 148 can be found in BCP-11. Copies of claims of rights made 149 available for publication and any assurances of licenses to be 150 made available, or the result of an attempt made to obtain a 151 general license or permission for the use of such proprietary 152 rights by implementers or users of this specification can be 153 obtained from the IETF Secretariat. 155 The IETF invites any interested party to bring to its attention 156 any copyrights, patents or patent applications, or other 157 proprietary rights, which may cover technology that may be 158 required to practice this standard. Please address the 159 information to the IETF Executive Director. 161 7. Acknowledgements 163 8. References 165 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 166 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June 167 2003. 169 [2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 170 2486, January 1999. 172 9. Contact Information 173 Questions and comments about this draft should be directed at 174 the Mobile IPv6 working group: 176 mip6@ietf.org 178 Questions and comments about this draft may also be directed to 179 the authors: 181 Alpesh Patel 182 Cisco Systems 183 170 W. Tasman Drive, 184 San Jose, CA 95134 185 USA 187 Email: alpesh@cisco.com 188 Phone: +1 408-853-9580 190 Kent Leung 191 Cisco Systems 192 170 W. Tasman Drive, 193 San Jose, CA 95134 194 USA 196 Email: kleung@cisco.com 197 Phone: +1 408-526-5030 199 Mohamed Khalil 200 Nortel Networks 201 2221 Lakeside Blvd. 202 Richardson, CA 75082 203 USA 205 Email: mkhalil@nortelnetworks.com 206 Phone: +1 972-685-0574 208 Haseeb Akhtar 209 Nortel Networks 210 2221 Lakeside Blvd. 211 Richardson, CA 75082 212 USA 214 Email: haseebak@nortelnetworks.com 215 Phone: +1 972-684-4732 217 Kuntal Chowdury 218 Nortel Networks 219 2221 Lakeside Blvd. 221 Richardson, CA 75082 222 USA 224 Email: chowdury@nortelnetworks.com 225 Phone: +1 972-685-7788 227 Full Copyright Statement 229 Copyright (C) The Internet Society (2002). All Rights 230 Reserved. 232 This document and translations of it may be copied and 233 furnished to others, and derivative works that comment on or 234 otherwise explain it or assist in its implementation may be 235 prepared, copied, published and distributed, in whole or in 236 part, without restriction of any kind, provided that the above 237 copyright notice and this paragraph are included on all such 238 copies and derivative works. However, this document itself may 239 not be modified in any way, such as by removing the copyright 240 notice or references to the Internet Society or other Internet 241 organizations, except as needed for the purpose of developing 242 Internet standards in which case the procedures for copyrights 243 defined in the Internet Standards process must be followed, or 244 as required to translate it into languages other than English. 246 The limited permissions granted above are perpetual and will 247 not be revoked by the Internet Society or its successors or 248 assigns. 250 This document and the information contained herein is provided 251 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 252 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 253 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 254 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 255 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 256 PARTICULAR PURPOSE. 258 Acknowledgement 260 Funding for the RFC Editor function is currently provided by 261 the Internet Society.