idnits 2.17.1 draft-ietf-seamoby-iana-02.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.5 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 336. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 307), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 31. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11.0 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 12.0 IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 142 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 335 has weird spacing: '...equired to im...' -- 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) -- Missing reference section? 'CARD' on line 272 looks like a reference -- Missing reference section? 'CTP' on line 275 looks like a reference -- Missing reference section? 'RFC2119' on line 85 looks like a reference -- Missing reference section? 'RFC2434' on line 279 looks like a reference -- Missing reference section? 'RFC3220' on line 283 looks like a reference -- Missing reference section? 'RFC2461' on line 281 looks like a reference -- Missing reference section? 'RFC2026' on line 277 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 James Kempf 3 Internet Draft DoCoMo Labs USA 4 Document: draft-ietf-seamoby-iana-02.txt 5 Expires: December, 2004 June, 2004 7 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and may 19 be updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite them 21 other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2003). All Rights Reserved. 33 Abstract 35 Seamoby Candidate Access Router Discovery protocol and Context Transfer 36 Protocol are experimental protocols designed to accelerate IP handover 37 between wireless access routers. These protocols require IANA allocations 38 for ICMP type and options, SCTP Payload Protocol Identifiers, port numbers, 39 and registries for certain formatted message options. This document contains 40 instructions to IANA about what allocations are required for the Seamoby 41 protocols. The ICMP subtype extension format for Seamoby has additionally 42 designed so that it can be utilized by other experimental mobility 43 protocols, and the SCTP port number is also available for other experimental 44 mobility protocols. 46 Table of Contents 48 1.0 Introduction..........................................................2 49 2.0 Common IPv4 and IPv6 Allocations......................................2 50 3.0 IPv4 Allocations......................................................2 51 4.0 IPv6 Allocations......................................................3 52 5.0 Candidate Access Router Discovery Protocol Registries.................3 53 6.0 Context Transfer Profile Type Registry................................4 54 7.0 Context Transfer Protocol Authorization Token Calculation Algorithm...4 55 8.0 ICMP Experimental Mobility Subtype Format and Registry................5 56 9.0 Utilization by Other Experimental Mobility Protocols..................5 57 10.0 Normative References................................................6 58 11.0 Security Considerations.............................................6 59 12.0 IANA Considerations.................................................6 60 13.0 Author Information..................................................6 61 14.0 Full Copyright Statement............................................6 62 15.0 Intellectual Property...............................................7 63 16.0 Acknowledgement.....................................................7 65 1.0 Introduction 67 The Seamoby Candidate Access Router Discovery (CARD) protocol [CARD] and 68 Context Transfer Protocol (CTP) [CTP] are experimental protocols designed to 69 accelerate IP handover between wireless access routers. These protocols 70 require IANA allocations for ICMP options and type, SCTP Payload Protocol 71 Identifiers and port number, and establishment of registries for certain 72 formatted message options. Because the protocols are experimental, there is 73 no guarantee that they will ever see widespread deployment in their current 74 form. Consequently, it seems prudent to conserve Internet numbering 75 resources that might be needed for other protocols which could see wider 76 deployment. This draft contains instructions to IANA for the Seamoby 77 protocols. Additionally, the ICMP subtype extension format has been designed 78 so that it could be used by other experimental mobility protocols. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 Allocation policy names Specification Required, IETF Consensus Action, and 84 Designated Expert are to be interpreted as described in RFC 2434 [RFC2434]. 86 2.0 Common IPv4 and IPv6 Allocations 88 IANA SHALL assign SCTP port number TBD1 for use by experimental mobility 89 protocols such as Seamoby. See Section 5.2.1 of [CARD] for a description of 90 inter-access router CARD protocol use of SCTP, and Section 3.1 of [CTP] for 91 a description of the inter-access router CTP use of SCTP. 93 IANA SHALL assign SCTP Payload Protocol Identifier (PPI) TBD2, designated 94 "CTP", for the Context Transfer Protocol, and SCTP Payload Protocol 95 Identifier TBD3, designated "CARD", for the Candidate Access Router 96 Discovery protocol. These are used to differentiate inter-router CARD and 97 CTP messages on the SCTP port. The allocation policy for new PPI numbers is 98 the method of IETF Consensus Action. 100 3.0 IPv4 Allocations 102 IANA SHALL assign ICMP type TBD4 for IPv4 identifying ICMP messages utilized 103 by experimental mobility protocols such as Seamoby. See Section 5.1.1 of 105 [CARD] for a description of experimental mobility CARD ICMP messages and 106 Section 3.2 of [CTP] for the CTP ICMP messages, specified by Seamoby. See 107 Section 9.0 of this document for a description of the experimental mobility 108 protocol ICMP subtype format and initial allocations. 110 IANA SHALL assign Mobile IPv4 Foreign Agent Discovery [RFC3220] option type 111 codes for the following: 113 Code Purpose Reference 114 -------------------------------------------------------------- 115 TBD5 CARD MN-AR signature option Section 6.4 of [CARD] 116 TBD6 CARD Request option Section 5.1.2.1 of [CARD] 117 TBD7 CARD Reply option Section 5.1.2.2 of [CARD] 119 4.0 IPv6 Allocations 121 IANA SHALL assign ICMP type code TBD8 for IPv6 identifying ICMP messages 122 utilized by experimental mobility protocols such as Seamoby. See Section 123 5.1.1 of [CARD] for a description of experimental mobility CARD ICMP 124 messages and Section 3.2 of [CTP] for the CTP ICMP messages, specified by 125 Seamoby. See Section 9.0 of this document for a description of the 126 experimental mobility protocol subtype format and initial allocations. 128 IANA SHALL assign IPv6 RFC 2461 Neighbor Discovery [RFC2461] option type 129 codes for the following: 131 Code Purpose Reference 132 -------------------------------------------------------------- 133 TBD9 CARD Request option Section 5.1.2.1 of [CARD] 134 TBD10 CARD Reply option Section 5.1.2.2 of [CARD] 136 5.0 Candidate Access Router Discovery Protocol Registries 138 For CARD, two new registries are created that IANA is to maintain, named: 140 1) The AVP Type Registry, 141 2) The Layer 2 Access Technology Identifier Registry. 143 These are described in the following subsections. 145 5.1 AVP Type Registry 147 The AVP Type Registry allows future expansion of the CARD AVP type space to 148 include new AVPs. AVP Type codes are 16 bit unsigned integers. See Section 149 5.1.4 of [CARD] for a description of AVPs. 151 The registry SHALL be initially populated with the following table: 153 AVP Name Type Code 154 ---------------------------------------------- 155 RESERVED 0x00 157 Future allocations of AVP type codes are made through Expert Review, as 158 defined in RFC 2434. 160 5.2 Layer 2 Access Technology Identifier Registry 162 The Layer 2 Access Technology Identifier registry allows the registration of 163 type codes to uniquely identify specific access technologies in the L2-Type 164 field of the CARD L2 ID sub-option. L2 ID codes are 16 bit unsigned 165 integers. See Section 5.1.3.1 of [CARD] for a description of the CARD L2 ID 166 sub-option. 168 The registry SHALL initially be populated with the following table: 170 Layer 2 Access Technology Type Code 171 ---------------------------------------------- 172 RESERVED 0x00 173 IEEE 802.3 (Ethernet) 0x01 174 IEEE 802.11a 0x02 175 IEEE 802.11b 0x03 176 IEEE 802.11g 0x04 177 IEEE 802.15.1(Bluetooth) 0x05 178 IEEE 802.15.3 0x06 179 IEEE 802.15.4 0x07 180 IEEE 802.16 0x08 182 Future allocation of Layer 2 Access Technology identifiers are made by the 183 method of Specification Required as defined in RFC 2434. All requests for 184 allocations MUST be accompanied by a reference to a technical document in 185 which the design of the Layer 2 access technology is described. 187 6.0 Context Transfer Profile Type Registry 189 CTP requires IANA to maintain a registry named the Context Transfer Profile 190 Type Registry, which is a registry of context Feature Profile Type 191 identifiers. Feature Profile Type identifiers are 16 bit unsigned integers 192 that identify particular types of feature contexts. See Section 2.4 of [CTP] 193 for a description of how contexts are carried in CTP. 195 The registry SHALL initially be populated with the following table: 197 Context Profile Type Code 198 ---------------------------------------------- 199 RESERVED 0x00 200 IPv6 Multicast Listener Context 0x01 202 Future allocations of Feature Profile Type codes are made through Expert 203 Review, as defined in RFC 2434. 205 7.0 Context Transfer Protocol Authorization Token Calculation Algorithm 207 In Section 2.5.4 of [CTP], CTP requires an authorization token calculation 208 algorithm indicator. Currently, the only indicator defined is 0x1, for 209 HMAC_SHA1. Additional algorithms may be added by the method of Specification 210 Required [RFC2434]. 212 8.0 ICMP Experimental Mobility Subtype Format and Registry 214 The ICMP Experimental Mobility Type is utilized by CARD and CTP in the 215 following way. The interpretation of the Code field is as defined by the 216 relevant ICMP standard for IPv4 and IPv6, and does not change. The protocols 217 are free to utilize the Code for their own purposes. The ICMP Experimental 218 Mobility Type defines a one octet subtype field within the ICMP Reserved 219 field, which identifies the specific protocol. The ICMP header for the 220 Experimental Mobility Type is: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Code | Checksum | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Subtype | Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Options... 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 232 Type For IPv4, TBD4; for IPv6 TBD8 234 Code As defined by the relevant ICMP specification, and 235 free for use by the Experimental Mobility protocol. 237 Checksum ICMP checksum 239 Subtype One octet subtype code identifying the Experimental 240 Mobility protocol 242 Reserved Unless otherwise defined by the Experimental Mobility 243 protocol, set to zero by the sender and ignored by 244 the receiver. 246 Options As defined by the Experimental Mobility protocol. 248 IANA SHALL maintain a registry of one octet unsigned integer subtype codes 249 for the Experimental Mobility protocols called the Experimental Mobility 250 Protocol Subtype Registry. 252 Initial allocations in the registry SHALL be established as follows: 254 Protocol/Message Subtype Reference 255 ---------------------------------------------------------------------- 256 CARD 0 Section 5.1.1 of [CARD] 257 CTP 1 Section 3.2 of [CTP] 259 Subsequent allocations of subtype codes SHALL be done by the method of 260 Specification Required and IESG Review as defined in RFC 2434. 262 9.0 Utilization by Other Experimental Mobility Protocols 263 The ICMP Experimental Mobility type code and SCTP port are available for 264 other experimental mobility protocols to utilize. Other experimental 265 mobility protocols MAY define additional ICMP messages that utilize the code 266 points under the Experimental Mobility ICMP type, and MAY define protocols 267 that utilize additional SCTP PPI numbers for the Experimental Mobility 268 protocol port. 270 10.0 Normative References 272 [CARD] Liebsch, M., Singh, A. (editors), Chaskar, H., Funato, D., and Shim, 273 Ensoo, " Candidate Access Router Discovery", Internet Draft, work in 274 progress. 275 [CTP] Loughny, J. (editor), Nahkjiri, M., Perkins, C., and Koodli, R., 276 "Context Transfer Protocol", Internet Draft, work in progress. 277 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, 278 RFC 2026, October 1996. 279 [RFC2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA 280 Considerations Section in RFCs", RFC 2434, October, 1998. 281 [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for 282 IP Version 6 (IPv6)", RFC 2461, December, 1998. 283 [RFC3220] Perkins, C. (editor),"IP Mobility Support for IPv4", RFC 3220, 284 January, 2002. 286 11.0 Security Considerations 288 There are no security considerations associated with this document. 290 12.0 IANA Considerations 292 This entire document is about IANA considerations. 294 13.0 Author Information 296 James Kempf Phone: +1 408 451 4711 297 DoCoMo Labs USA Email: kempf@docomolabs-usa.com 298 181 Metro Drive 299 Suite 300 300 San Jose, CA 301 95110 303 14.0 Full Copyright Statement 305 Copyright (C) The Internet Society (2004). This document is subject to the 306 rights, licenses and restrictions contained in BCP 78, and except as set 307 forth therein, the authors retain all their rights. 309 This document and the information contained herein are provided on an "AS IS" 310 basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED 311 BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 312 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 313 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 314 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 315 PURPOSE. 317 15.0 Intellectual Property 319 The IETF takes no position regarding the validity or scope of any 320 Intellectual Property Rights or other rights that might be claimed to pertain 321 to the implementation or use of the technology described in this document or 322 the extent to which any license under such rights might or might not be 323 available; nor does it represent that it has made any independent effort to 324 identify any such rights. Information on the procedures with respect to 325 rights in RFC documents can be found in BCP 78 and BCP 79. 327 Copies of IPR disclosures made to the IETF Secretariat and any assurances of 328 licenses to be made available, or the result of an attempt made to obtain a 329 general license or permission for the use of such proprietary rights by 330 implementers or users of this specification can be obtained from the IETF on- 331 line IPR repository at http://www.ietf.org/ipr. 333 The IETF invites any interested party to bring to its attention any 334 copyrights, patents or patent applications, or other proprietary rights that 335 may cover technology that may be required to implement this standard. 336 Please address the information to the IETF at ietf-ipr@ietf.org. 338 16.0 Acknowledgement 340 Funding for the RFC Editor function is currently provided by the Internet 341 Society.