James Kempf Internet Draft DoCoMo Labs USA Document: draft-ietf-seamoby-iana-01.txt Expires: November, 2004 May, 2004 Instructions for Seamoby Experimental Protocol IANA Allocations Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Seamoby Candidate Access Router Discovery protocol and Context Transfer Protocol are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP types, SCTP Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about what allocations are required. Table of Contents 1.0 Introduction..........................................................2 2.0 Common IPv4 and IPv6 Allocations......................................2 3.0 IPv4 Allocations......................................................2 4.0 IPv6 Allocations......................................................3 5.0 Candidate Access Router Discovery Protocol Registries.................3 6.0 Context Transfer Profile Type Registry................................4 7.0 Utilization by Other Experimental Mobility Protocols..................5 8.0 Normative References..................................................5 9.0 Security Considerations...............................................5 Kempf Expires November, 2004 [Page 1]
Internet Draft Seamoby IANA Allocations May, 2004 10.0 IANA Considerations.................................................5 11.0 Author Information..................................................5 12.0 Full Copyright Statement............................................5 13.0 Intellectual Property...............................................6 14.0 Acknowledgement.....................................................6 1.0 Introduction The Seamoby Candidate Access Router Discovery (CARD) protocol [CARD] and Context Transfer Protocol (CTP) [CTP] are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP options and type, SCTP Payload Protocol Identifiers and port number, and establishment of registries for certain formatted message options. Because the protocols are experimental, there is no guarantee that they will ever see widespread deployment in their current form. Consequently, it seems prudent to conserve Internet numbering resources that might be needed for other protocols which could see wider deployment. This draft contains instructions to IANA for the Seamoby protocols. Additionally, some of these allocations are available for other Experimental Mobility protocols. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Allocation policy names Specification Required, IETF Consensus Action, and Designated Expert are to be interpreted as described in RFC 2434 [RFC2434]. 2.0 Common IPv4 and IPv6 Allocations IANA SHALL assign SCTP port number TBD1 for use by Experimental Mobility protocols such as Seamoby. See Section 5.2.1 of [CARD] for a description of inter-access router CARD protocol use of SCTP, and Section 3.1 of [CTP] for a description of the inter-access router CTP use of SCTP. IANA SHALL assign SCTP Payload Protocol Identifier (PPI) TBD2, designated "CTP", for the Context Transfer Protocol, and SCTP Payload Protocol Identifier TBD3, designated "CARD", for the Candidate Access Router Discovery protocol. These are used to differentiate inter-router CARD and CTP messages on the SCTP port. The allocation policy for new PPI numbers is the method of IETF Consensus Action. 3.0 IPv4 Allocations IANA SHALL assign ICMP type TBD4 for IPv4 identifying ICMP messages utilized by Experimental Mobility protocols such as Seamoby. See Section 5.1.1 of [CARD] for a description of Experimental Mobility CARD ICMP messages specified by Seamoby, and Section 3.2 of [CTP] for the CTP ICMP messages. Furthermore, the IANA SHALL assign the following codes under the Experimental Mobility ICMP type for Seamoby: Code Purpose Reference ----------------------------------------------------------------- Kempf Expires November 2004 [Page 2]
Internet Draft Seamoby IANA Allocations May, 2004 0 CARD host to router signaling Section 5.1.1 of [CARD] 1 CTP host to router signaling Section 3.2 of [CTP] The allocation policy for additional code points under the Experimental Mobility ICMP type is the method of IETF Consensus Action. IANA SHALL assign Mobile IPv4 Foreign Agent Discovery [RFC3220] option type codes for the following: Code Purpose Reference -------------------------------------------------------------- TBD5 CARD MN-AR signature option Section 6.4 of [CARD] TBD6 CARD Request option Section 5.1.2.1 of [CARD] TBD7 CARD Reply option Section 5.1.2.2 of [CARD] 4.0 IPv6 Allocations IANA SHALL assign ICMP type code TBD8 for IPv6 identifying ICMP messages utilized by Experimental Mobility protocols such as Seamoby. See Section 5.1.1 of [CARD] for a description of Experimental Mobility CARD ICMP messages specified by Seamoby, and Section 3.2 of [CTP] for the CTP ICMP messages. Furthermore, the IANA SHALL assign the following codes under the Experimental Mobility ICMP type for Seamoby: Code Purpose Reference ----------------------------------------------------------------- 0 CARD host to router signaling Section 5.1.1 of [CARD] 1 CTP host to router signaling Section 3.2 of [CTP] The allocation policy for additional code points under the Experimental Mobility ICMP type is the method of IETF Consensus Action. IANA SHALL assign IPv6 RFC 2461 Neighbor Discovery [RFC2461] option type codes for the following: Code Purpose Reference -------------------------------------------------------------- TBD9 CARD Request option Section 5.1.2.1 of [CARD] TBD10 CARD Reply option Section 5.1.2.2 of [CARD] 5.0 Candidate Access Router Discovery Protocol Registries For CARD, two new registries are created that IANA is to maintain, named: 1) The AVP Type Registry, 2) The Layer 2 Access Technology Identifier Registry. These are described in the following subsections. 5.1 AVP Type Registry The AVP Type Registry allows future expansion of the CARD AVP type space to include new AVPs. AVP Type codes are 16 bit unsigned integers. See Section 5.1.4 of [CARD] for a description of AVPs. Kempf Expires November 2004 [Page 3]
Internet Draft Seamoby IANA Allocations May, 2004 The registry SHALL be initially populated with the following table: AVP Name Type Code ---------------------------------------------- RESERVED 0x00 Future allocations of AVP type codes are made through Expert Review, as defined in RFC 2434. 5.2 Layer 2 Access Technology Identifier Registry The Layer 2 Access Technology Identifier registry allows the registration of type codes to uniquely identify specific access technologies in the L2-Type field of the CARD L2 ID sub-option. L2 ID codes are 16 bit unsigned integers. See Section 5.1.3.1 of [CARD] for a description of the CARD L2 ID sub-option. The registry SHALL initially be populated with the following table: Layer 2 Access Technology Type Code ---------------------------------------------- RESERVED 0x00 IEEE 802.3 (Ethernet) 0x01 IEEE 802.11a 0x02 IEEE 802.11b 0x03 IEEE 802.11g 0x04 IEEE 802.15.1(Bluetooth) 0x05 IEEE 802.15.3 0x06 IEEE 802.15.4 0x07 IEEE 802.16 0x08 Future allocation of Layer 2 Access Technology identifiers are made by the method of Specification Required as defined in RFC 2434. All requests for allocations MUST be accompanied by a reference to a technical document in which the design of the Layer 2 access technology is described. 6.0 Context Transfer Profile Type Registry CTP requires IANA to maintain a registry named the Context Transfer Profile Type Registry, which is a registry of context Feature Profile Type identifiers. Feature Profile Type identifiers are 16 bit unsigned integers that identify particular types of feature contexts. See Section 2.4 of [CTP] for a description of how contexts are carried in CTP. The registry SHALL initially be populated with the following table: Context Profile Type Code ---------------------------------------------- RESERVED 0x00 IPv6 Multicast Listener Context 0x01 Future allocations of Feature Profile Type codes are made through Expert Review, as defined in RFC 2434. Kempf Expires November 2004 [Page 4]
Internet Draft Seamoby IANA Allocations May, 2004 7.0 Utilization by Other Experimental Mobility Protocols The ICMP type code and SCTP port are available for other Experimental Mobility protocols to utilize. Other Experimental Mobility protocols MAY define additional ICMP messages that utilize the code points under the Experimental Mobility ICMP type, and MAY define protocols that utilize additional SCTP PPI numbers for the Experimental Mobility protocol port. Such allocations are made through the method of IETF Consensus, as defined in RFC 2434. 8.0 Normative References [CARD] Liebsch, M., Singh, A. (editors), Chaskar, H., Funato, D., and Shim, Ensoo, " Candidate Access Router Discovery", Internet Draft, work in progress. [CTP] Loughny, J. (editor), Nahkjiri, M., Perkins, C., and Koodli, R., "Context Transfer Protocol", Internet Draft, work in progress. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October, 1998. [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998. [RFC3220] Perkins, C. (editor),"IP Mobility Support for IPv4", RFC 3220, January, 2002. 9.0 Security Considerations There are no security considerations associated with this document. 10.0 IANA Considerations This entire document is about IANA considerations. 11.0 Author Information James Kempf Phone: +1 408 451 4711 DoCoMo Labs USA Email: kempf@docomolabs-usa.com 181 Metro Drive Suite 300 San Jose, CA 95110 12.0 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Kempf Expires November 2004 [Page 5]
Internet Draft Seamoby IANA Allocations May, 2004 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13.0 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on- line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 14.0 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kempf Expires November 2004 [Page 6]
