Movatterモバイル変換

Network Working Group                                           J. KempfRequest for Comments: 4065                               DoCoMo Labs USACategory: Experimental                                         July 2005Instructions for Seamoby andExperimental Mobility Protocol IANA AllocationsStatus of This Memo   This memo defines an Experimental Protocol for the Internet   community.  It does not specify an Internet standard of any kind.   Discussion and suggestions for improvement are requested.   Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2005).Abstract   The Seamoby Candidate Access Router Discovery (CARD) protocol and the   Context Transfer Protocol (CXTP) are experimental protocols designed   to accelerate IP handover between wireless access routers.  These   protocols require IANA allocations for ICMP type and options, Stream   Control Transmission Protocol (SCTP) Payload Protocol Identifiers,   port numbers, and registries for certain formatted message options.   This document contains instructions to IANA about which allocations   are required for the Seamoby protocols.  The ICMP subtype extension   format for Seamoby has been additionally designed so that it can be   utilized by other experimental mobility protocols, and the SCTP port   number is also available for other experimental mobility protocols.Kempf                         Experimental                      [Page 1]

RFC 4065                Seamoby IANA Allocations               July 2005Table of Contents1.  Introduction..................................................22.  Common IPv4 and IPv6 Allocations..............................23.  IPv4 Allocations..............................................34.  IPv6 Allocations..............................................35.  Candidate Access Router Discovery Protocol Registries.........36.  Context Transfer Profile Type Registry........................5   7.  Context Transfer Protocol Authorization Token Calculation       Algorithm.....................................................58.  ICMP Experimental Mobility Subtype Format and Registry........59.  Utilization by Other Experimental Mobility Protocols..........610. Normative References..........................................611. Security Considerations.......................................712. IANA Considerations...........................................71.  Introduction   The Seamoby Candidate Access Router Discovery (CARD) protocol   [RFC4066] and the Context Transfer Protocol (CXTP) [RFC4067] 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, port   numbers, and the 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 is prudent to conserve Internet   numbering resources that might be needed for other protocols that   could see wider deployment.  This document contains instructions to   IANA for the Seamoby protocols.  Additionally, the ICMP subtype   extension format has been designed so that it could be used by 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 inRFC 2119 [RFC2119].   Allocation policy names Specification Required, IETF Consensus   Action, and Designated Expert are to be interpreted as described inRFC 2434 [RFC2434].2.  Common IPv4 and IPv6 Allocations   IANA has assigned SCTP port numbers 5090 for use by [RFC4066] and   5091 for use of [RFC4067].  SeeSection 5.2.1 of [RFC4066] for a   description of the inter-access router CARD protocol use of SCTP, andSection 3.1 of [RFC4067] for a description of the inter-access router   CXTP use of SCTP.Kempf                         Experimental                      [Page 2]

RFC 4065                Seamoby IANA Allocations               July 20053.  IPv4 Allocations   IANA has assigned ICMP type 41 for IPv4 identifying ICMP messages   utilized by experimental mobility protocols such as Seamoby.  SeeSection 5.1.1 of [RFC4066] for a description of experimental mobility   CARD ICMP messages andSection 3.2 of [RFC4067] for the CXTP ICMP   messages, specified by Seamoby.  SeeSection 9 of this document for a   description of the experimental mobility protocol ICMP subtype format   and initial allocations.   IANA has assigned Mobile IPv4 Foreign Agent Discovery [RFC3344]   option type codes for the following:   Code              Purpose                  Reference   ---------------------------------------------------------------------    137        CARD MN-AR signature optionSection 6.4 of [RFC4066]    138        CARD Request optionSection 5.1.2.1 of [RFC4066]    139        CARD Reply optionSection 5.1.2.2 of [RFC4066]4.  IPv6 Allocations   IANA has assigned ICMP type code 150 for IPv6 identifying ICMP   messages utilized by experimental mobility protocols such as Seamoby.   SeeSection 5.1.1 of [RFC4066] for a description of experimental   mobility CARD ICMP messages andSection 3.2 of [RFC4067] for the CXTP   ICMP messages, specified by Seamoby.  SeeSection 9 of this document   for a description of the experimental mobility protocol subtype   format and initial allocations.   IANA has assigned IPv6RFC 2461 Neighbor Discovery [RFC2461] option   type codes for the following:   Code            Purpose                   Reference   ----------------------------------------------------------------    138          CARD Request optionSection 5.1.2.1 of [RFC4066]    139          CARD Reply optionSection 5.1.2.2 of [RFC4066]5.  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.Kempf                         Experimental                      [Page 3]

RFC 4065                Seamoby IANA Allocations               July 20055.1.  AVP Type Registry   The AVP Type Registry allows for future expansion of the CARD AVP   type space to include new AVPs.  AVP Type codes are 16 bit unsigned   integers.  SeeSection 5.1.4 of [RFC4066] for a description of AVPs.   The registry SHALL be initially populated with the following table:      AVP Name                            Type Code      ----------------------------------------------      RESERVED                                0x00   Future allocations of AVP type codes will be made through Expert   Review, as defined inRFC 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.  SeeSection 5.1.3.1 of   [RFC4066] 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 will be   made by the method of Specification Required, as defined inRFC 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.Kempf                         Experimental                      [Page 4]

RFC 4065                Seamoby IANA Allocations               July 20056.  Context Transfer Profile Type Registry   CXTP 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.   SeeSection 2.4 of [RFC4067] for a description of how contexts are   carried in CXTP.   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 will be made through   Expert Review, as defined inRFC 2434.7.  Context Transfer Protocol Authorization Token Calculation Algorithm   InSection 2.5.4 of [RFC4067], CXTP requires an authorization token   calculation algorithm indicator.  Currently, the only indicator   defined is 0x1, for HMAC_SHA1.  Additional algorithms may be added by   the method of Specification Required [RFC2434].8.  ICMP Experimental Mobility Subtype Format and Registry   The ICMP Experimental Mobility Type is utilized by CARD and CXTP in   the following way.  The interpretation of the Code field is as   defined by the relevant ICMP standard for IPv4 and IPv6, and does not   change.  The protocols are free to utilize the Code for their own   purposes.  The ICMP Experimental Mobility Type defines a one octet   subtype field within the ICMP Reserved field that identifies the   specific protocol.  The ICMP header for the Experimental Mobility   Type is:       0                   1                   2                   3       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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |     Type      |    Code       |          Checksum             |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |     Subtype   |              Reserved                         |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |    Options...      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-      Type         For IPv4, 41; for IPv6 150Kempf                         Experimental                      [Page 5]

RFC 4065                Seamoby IANA Allocations               July 2005      Code         As defined by the relevant ICMP specification and                   free for use by the Experimental Mobility protocol.      Checksum     ICMP checksum      Subtype      One octet subtype code identifying the Experimental                   Mobility protocol      Reserved     Unless otherwise defined by the Experimental Mobility                   protocol, set to zero by the sender and ignored by                   the receiver.      Options      As defined by the Experimental Mobility protocol.   IANA SHALL maintain a registry of one octet unsigned integer subtype   codes for the Experimental Mobility protocols called the Experimental   Mobility Protocol Subtype Registry.   Initial allocations in the registry SHALL be established as follows:   Protocol/Message  Subtype         Reference   ----------------------------------------------------------    CARD               0Section 5.1.1 of [RFC4066]    CXTP               1Section 3.2 of [RFC4067]   Subsequent allocations of subtype codes SHALL be made by the method   of Specification Required and IESG Review as defined inRFC 2434.9.  Usage by Other Experimental Mobility Protocols   The ICMP Experimental Mobility type code is available for other   experimental mobility protocols to use.  Other experimental mobility   protocols MAY define additional ICMP messages that use code points   under the Experimental Mobility ICMP type.10.  Normative References   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an             IANA Considerations Section in RFCs",BCP 26,RFC 2434,             October 1998.   [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor             Discovery for IP Version 6 (IPv6)",RFC 2461, December             1998.   [RFC3344] Perkins, C., "IP Mobility Support for IPv4",RFC 3344,             August 2002.Kempf                         Experimental                      [Page 6]

RFC 4065                Seamoby IANA Allocations               July 2005   [RFC4066] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D.,             and E. Shim, "Candidate Access Router Discovery (CARD)",RFC 4066, July 2005.   [RFC4067] Loughney, J., Ed., Nahkjiri, M., Perkins, C., and R.             Koodli, "Context Transfer Protocol",RFC 4067, July 2005.11.  Security Considerations   There are no security considerations associated with this document.12.  IANA Considerations   This entire document is about IANA considerations.Author's Address   James Kempf   DoCoMo Labs USA   181 Metro Drive   Suite 300   San Jose, CA   95110   Phone: +1 408 451 4711   EMail: kempf@docomolabs-usa.comKempf                         Experimental                      [Page 7]

RFC 4065                Seamoby IANA Allocations               July 2005Full Copyright Statement   Copyright (C) The Internet Society (2005).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   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.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 inBCP 78 andBCP 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 athttp://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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Kempf                         Experimental                      [Page 8]