Internet DRAFT - draft-ietf-seamoby-iana

draft-ietf-seamoby-iana





                                                                James Kempf 
  Internet Draft                                            DoCoMo Labs USA 
  Document: draft-ietf-seamoby-iana-02.txt                                  
  Expires: December, 2004                                        June, 2004 
      
      
      Instructions for Seamoby and Experimental Mobility 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 type and options, SCTP Payload Protocol Identifiers, port numbers, 
     and registries for certain formatted message options. This document contains 
     instructions to IANA about what allocations are required for the Seamoby 
     protocols. The ICMP subtype extension format for Seamoby has 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. 
   
  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 

      
     Kempf                   Expires November, 2004                   [Page 1] 

     Internet Draft        Seamoby IANA Allocations                   May, 2004 
      
     6.0  Context Transfer Profile Type Registry................................4 
     7.0  Context Transfer Protocol Authorization Token Calculation Algorithm...4 
     8.0  ICMP Experimental Mobility Subtype Format and Registry................5 
     9.0  Utilization by Other Experimental Mobility Protocols..................5 
     10.0  Normative References................................................6 
     11.0  Security Considerations.............................................6 
     12.0  IANA Considerations.................................................6 
     13.0  Author Information..................................................6 
     14.0  Full Copyright Statement............................................6 
     15.0  Intellectual Property...............................................7 
     16.0  Acknowledgement.....................................................7 
      
   
   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, 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 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 
      
     Kempf                    Expires November 2004                     [Page 2] 

     Internet Draft        Seamoby IANA Allocations                   May, 2004 
      
     [CARD] for a description of experimental mobility CARD ICMP messages and 
     Section 3.2 of [CTP] for the CTP ICMP messages, specified by Seamoby. See 
     Section 9.0 of this document for a description of the experimental mobility 
     protocol ICMP subtype format and initial allocations. 
      
     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 and Section 3.2 of [CTP] for the CTP ICMP messages, specified by 
     Seamoby. See Section 9.0 of this document for a description of the 
     experimental mobility protocol subtype format and initial allocations. 
      
     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.  
      
     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. 
      
     Kempf                    Expires November 2004                     [Page 3] 

     Internet Draft        Seamoby IANA Allocations                   May, 2004 
      
      
  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. 
      
   7.0    Context Transfer Protocol Authorization Token Calculation Algorithm 
      
     In Section 2.5.4 of [CTP], CTP 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]. 
      

      
     Kempf                    Expires November 2004                     [Page 4] 

     Internet Draft        Seamoby IANA Allocations                   May, 2004 
      
   8.0    ICMP Experimental Mobility Subtype Format and Registry 
      
     The ICMP Experimental Mobility Type is utilized by CARD and CTP 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, which 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, TBD4; for IPv6 TBD8 
      
         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               0       Section 5.1.1 of [CARD] 
       CTP                1       Section 3.2 of [CTP] 
      
     Subsequent allocations of subtype codes SHALL be done by the method of 
     Specification Required and IESG Review as defined in RFC 2434. 
      
      
   9.0    Utilization by Other Experimental Mobility Protocols 
      

      
     Kempf                    Expires November 2004                     [Page 5] 

     Internet Draft        Seamoby IANA Allocations                   May, 2004 
      
     The ICMP Experimental Mobility 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.  
      
      
      
   10.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. 
      
   11.0   Security Considerations 
      
     There are no security considerations associated with this document. 
      
   12.0   IANA Considerations 
      
     This entire document is about IANA considerations. 
      
   13.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 
      
   14.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. 
   
     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 

      
     Kempf                    Expires November 2004                     [Page 6] 

     Internet Draft        Seamoby IANA Allocations                   May, 2004 
      
     OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
     PURPOSE. 
   
   15.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. 
   
   16.0   Acknowledgement 
   
     Funding for the RFC Editor function is currently provided by the Internet 
     Society. 
      

























      
     Kempf                    Expires November 2004                     [Page 7]