Subject: [Mip4] draft-mip4-experimental-messages-03.txt - New version before posting to IESG

From: Alpesh <[email-masked]>
Date: Mon, 24 May 2004 06:41:53 -0700

Hi -

A new of the draft "Experimental Message, Extension and Error Codes for 
Mobile IPv4"
is attached herewith for your reference.

We have added two new subsections regarding experimental extensions in 
ICMP router
advertisement messages used by MIPv4.

Thanks
alpesh

   Mobile IP Working Group                               Alpesh Patel 
   INTERNET DRAFT                                          Kent Leung 
   11 May 2004                                          Cisco Systems 

    Experimental Message, Extension and Error Codes for Mobile IPv4 
             draft-ietf-mip4-experimental-messages-03.txt 

   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 (2004). All Rights Reserved. 

   Abstract 

        Mobile IPv4 message types range from 0 to 255. This document 
        reserves a message type for use by an individual, company, or 
        organization for experimental purpose, to evaluate enhancements 
        to Mobile IPv4 messages before formal standards proposal. 

         
     
  Patel, Leung        Expires November 10, 2004             [Page 1] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

        Table of Contents 

        1. Introduction.............................................2 
        2. Terminology..............................................3 
        3. Experimental Message.....................................3 
        4. Experimental Extensions..................................4 
        4.1 Non-skippable Mobile IPv4 Experimental Extension........5 
        4.2 Non-skippable Router Discovery Experimental Extension...5 
        4.3 Skippable Mobile IPv4 Experimental Extension............6 
        4.4 Skippable ICMP Router Discovery Experimental Extension..7 
        5. Experimental Error Codes.................................7 
        6. Mobility Entity Considerations...........................7 
        7. IANA Considerations......................................8 
        8. Security Considerations..................................8 
        9. Backward Compatibility Considerations....................9 
        10. Intellectual Property Rights............................9 
        11. Acknowledgements........................................9 
        12. References.............................................10 
        12.1 Normative References..................................10 
        12.2 Informative References................................10 
        13. Authors' Addresses.....................................10 
        Intellectual Property Statement............................11 
        Full Copyright Statement...................................11 

   1. Introduction  

        Mobile IPv4 message types range from 0 to 255. This document 
        reserves a message type for experimental purposes, to evaluate 
        enhancements to Mobile IPv4 messages before formal standards 
        proposal. 
         
        Without experimental message capability, one would have to 
        select a type value from the range defined for IANA assignment, 
        which may result in collisions. 
         
        Also, Mobile IP defines a general extension mechanism to allow 
        optional information to be carried by Mobile IP control 
        messages. Extensions are not skippable if defined in range 
        [0-127] and skippable if defined in range [128-255]. This 
        document reserves extension types in both the skippable and 
        non-skippable range for experimental use.  
         
        Mobile IPv4 defines error codes for use by the FA [64-127] and 
        HA [128-192]. This document reserves an error code in both 
        these ranges for experimental use. 
         
        This document defines and reserves experimental numbers as per 
        the recommendation of BCP 82 (section 2.2), RFC 3692. 
  
  Patel, Leung        Expires November 10, 2004             [Page 2] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

    2. Terminology 

        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 [1].  

        In addition, this document frequently uses the following terms: 

        EXP-MSG-TYPE: A Mobile-IPv4 message number in the range [0-255] 
        to be assigned by IANA for experimental use. 
         
        EXP-SKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery 
        (advertisement) extension number in the range [128-255] to be 
        assigned by IANA for experimental use. 
         
        EXP-NONSKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery 
        (advertisement) extension number in the range [0-127] to be 
        assigned by IANA for experimental use. 
         
        EXP-HA-ERROR-CODE: A Mobile-IPv4 error code in the range [128-
        192] for use by HA in reply messages to indicate error 
        condition. 
         
        EXP-FA-ERROR-CODE: A Mobile-IPv4 error code in the range [64-
        127] for use by FA in reply messages to indicate error 
        condition. 
         
        Mobility Entity: Entities as defined in [2] (home agent, 
        foreign agent and mobile node). 

   3. Experimental Message 

        Since the nature and purpose of an experimental message cannot 
        be known in advance, the structure is defined as an opaque 
        payload. Entities implementing the message can interpret the 
        message as per their implementation. One suggestion is to 
        interpret based on extensions present in the message. 
       
        These messages may be used between the mobility entities (Home 
        Agent, Foreign Agent, and Mobile Node). Experimental messages 
        SHOULD be authenticated using any of the authentication 
        mechanism defined for Mobile IP ([2], [5]).  

  Patel, Leung        Expires November 10, 2004             [Page 3] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

        This message MAY contain extensions defined in Mobile IP, 
        including vendor specific extensions [4]. 

        IP fields: 
           Source Address Typically the interface address from which 
           the message is sent. 
       
           Destination Address The address of the agent or the Mobile    
           Node. 

        UDP fields: 
       
            Source Port        Set according to RFC 768 (variable) 
       
            Destination Port   Set to the value 434 

        Mobile IP fields shown below follow the UDP header: 
 
      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      |                 Opaque. . .                       
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Type       EXP-MSG-TYPE (To be assigned by IANA) 
         
         Opaque     Zero or more octets of data, with structure defined 
                    only by the particular experiment it is used for. 

        Once an experimental message has been tested and shown to be 
        useful, a permanent number should be obtained through the 
        normal assignment procedures. 
         
        A single experimental message type is recommended since this 
        message can contain extensions based on which the message can 
        be interpreted.  

   4. Experimental Extensions 

        This document reserves Mobile IPv4 extensions in both the 
        skippable and non-skippable range for experimental purposes. 
        The long extension format (for non-skippable extensions) and 
        short extension format (for skippable extensions), as defined 
        by [2] are used for Mobile IPv4 experimental extensions.  
  
  Patel, Leung        Expires November 10, 2004             [Page 4] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

        Also, ICMP router discovery extension numbers in both the 
        skippable and non-skippable range are reserved for experimental 
        use. 

   4.1 Non-skippable Mobile IPv4 Experimental Extension 

        This format is applicable for non-skippable extensions and may 
        carry information more than 256 bytes. 

      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      |  Sub-Type     |           Length              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           Opaque. . . 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Type     EXP-NONSKIP-EXT-TYPE (to be assigned by IANA) is   
                 the type, which describes an experimental extension. 
         
        Sub-Type is a unique number given to each member in the  
                 aggregated type. 
         
        Length   Indicates the length (in bytes) of the data field  
                 within this extension.  It does NOT include the Type,  
                 Sub-Type and Length bytes. 
         
         Opaque   Zero or more octets of data, with structure defined 
                 only by the particular experiment it is used for. 
         
        Since the length field is 16 bits wide, the extension data can 
        exceed 256 bytes in length. 

   4.2 Non-skippable Router Discovery Experimental Extension 

      This format is applicable for non-skippable extensions. 

      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      |    Length     |           Opaque . . .  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

  Patel, Leung        Expires November 10, 2004             [Page 5] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

        Type     EXP-NONSKIP-EXT-TYPE (to be assigned by IANA) is   
                 the type, which describes an ICMP router discovery   
                 experimental extension. 
         
        Length   Indicates the length (in bytes) of the data field  
                 within this extension.  It does NOT include the Type,  
                 Sub-Type and Length bytes. 
         
         Opaque   Zero or more octets of data, with structure defined 
                 only by the particular experiment it is used for. 

        A node, which receives a router advertisement with this 
        extension should ignore the extension if it does not recognize 
        it.  
         
        A mobility entity, which understands this extension, but does 
        not recognize it should drop (ignore) the router advertisement. 

   4.3 Skippable Mobile IPv4 Experimental Extension 

        This format is applicable for skippable extensions, which carry 
        information less than 256 bytes. 

      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      |  Length     |   Sub-Type    |  Opaque. . . 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Type     EXP-SKIP-EXT-TYPE (to be assigned by IANA) is the  
                 type, which describes an experimental extension. 
         
        Length   Indicates the length (in bytes) of the data field  
                 within this extension.  It does NOT include the Type  
                 and Length bytes. 
         
        Sub-Type is a unique number given to each member in the  
                 aggregated type. 
         
         Opaque   Zero or more octets of data, with structure defined 
                 only by the particular experiment it is used for. 

        Since the length field is 8 bits wide, the extension data 
        cannot exceed 256 bytes in length. 

  Patel, Leung        Expires November 10, 2004             [Page 6] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

   4.4 Skippable ICMP Router Discovery Experimental Extension 

        This format is applicable for skippable ICMP router discovery 
        extensions. This extension should be ignored if an 
        implementation does not understand it. 
 
      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      |  Length     |   Opaque. . . 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        Type     EXP-SKIP-EXT-TYPE (to be assigned by IANA) is the  
                 type, which describes an experimental extension. 
         
        Length   Indicates the length (in bytes) of the data field  
                 within this extension.  It does NOT include the Type  
                 and Length bytes. 
         
         Opaque   Zero or more octets of data, with structure defined 
                 only by the particular experiment it is used for. 

        A node, which receives a router advertisement with this 
        extension should ignore the extension. 

   5. Experimental Error Codes 

        This document reserves reply error code EXP-FA-ERROR-CODE, in 
        the range [64-127], for use by the FA. This document also 
        reserves reply error code EXP-HA-ERROR-CODE, in the range [128-
        192], for use by the HA.  
         
        These experimental error codes may be used in registration 
        reply messages.  
 
        It is recommended that experimental error codes are used 
        with experimental messages and extensions whenever none of the 
        standardized error codes are applicable. 

   6. Mobility Entity Considerations 

  Patel, Leung        Expires November 10, 2004             [Page 7] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

        Mobility entities can send and receive experimental messages. 
        Implementations that don't understand the message type SHOULD 
        silently discard the message. 
         
        Experimental extensions can be carried in experimental messages 
        and standards defined messages. In the later case, it is 
        suggested that experimental extensions MUST not be used in 
        deployed products and usage be restricted to experimentations 
        only. 

   7. IANA Considerations 

        IANA services are required for this draft. Since a new message 
        type is needed to be reserved as experimental, a value must be 
        assigned for EXP-MSG-TYPE from the Mobile IP control message 
        space. 
         
        Also, values for EXP-NONSKIP-EXT-TYPE and EXP-SKIP-EXT-TYPE 
        must be assigned for experimental extensions. 

        The value for EXP-NONSKIP-EXT-TYPE should be assigned from the 
        numbering space for non-skippable extensions which may appear 
        in control messages, and also (with the same number) from the 
        numbering space for non-skippable extensions which may appear 
        in ICMP router discovery messages.  The value 127 is suggested 
        in both cases. 

        The value for EXP-SKIP-EXT-TYPE should be assigned from the 
        numbering space for skippable extensions which may appear in 
        control messages, and also (with the same number) from the 
        numbering space for skippable extensions which may appear in 
        ICMP router discovery messages.  The value 255 is suggested in 
        both cases. 

        Also, values for EXP-HA-ERROR-CODE and EXP-FA-ERROR-CODE must 
        be assigned for experimental error code. The suggested values 
        are 192 for the EXP-HA-ERROR-CODE and 127 for the EXP-FA-ERROR-
        CODE. 

   8. Security Considerations 

        Like all Mobile IP control messages, the experimental messages  
        MUST be authenticated as per the requirements specified in [2] 
        or [5]. Experimental messages without a valid authenticator 
        MUST be discarded. 
  
  Patel, Leung        Expires November 10, 2004             [Page 8] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

 
   9. Backward Compatibility Considerations 

        Mobility entities that don't understand the experimental 
        message MUST silently discard it. 
         
        Mobility entities that don't understand the experimental 
        skippable extensions MUST ignore them. Mobility entities that 
        don't understand the non-skippable experimental extensions 
        MUST silently discard the message containing them. 
         
        FA and HA SHOULD include experimental error code in reply 
        message only if they have a general indication that the 
        receiving entity would be able to parse it. An indication of 
        this is if the request message was of type EXP-MSG-TYPE or 
        contained at-least one experimental extension. 

   10. Intellectual Property Rights 

        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 [email-masked]. 

   11. Acknowledgements 

  Patel, Leung        Expires November 10, 2004             [Page 9] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

        The authors would like to acknowledge Henrik Levkowetz for his 
        detailed review of the draft and suggestion to incorporate 
        experimental extensions in this draft. 
         
        The authors would also like to acknowledge Thomas Narten for 
        his initial review of the draft and reference to [6] for 
        general guidelines. 

   12. References 

   12.1 Normative References 

   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
       Levels", BCP 14, RFC 2119, March 1997.  
    
   [2] Perkins, C., "IP Mobility Support", RFC 3344, August 2002.  
    
   [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,  
       RFC 1700, October 1994. 

   12.2 Informative References 

   [4] G. Dommety, K. Leung, "Mobile IP Vendor/Organization-Specific  
       Extensions" RFC 3115, April 2001 
    
   [5] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response  
       Extensions", RFC 3012, November 2000 
    
   [6] T. Narten, "Assigning Experimental and Testing Numbers   
       Considered Useful", BCP 82, RFC 3692, January, 2004 

   13. Authors' Addresses 

        Questions and comments about this draft should be directed at 
        the Mobile IPv4 working group: 
           
        [email-masked] 

        Questions and comments about this draft may also be directed to 
        the authors: 

         Alpesh Patel 
  
  Patel, Leung        Expires November 10, 2004             [Page 10] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

         Cisco Systems 
         170 W. Tasman Drive, 
         San Jose, CA 95134 
         USA 
         Email: [email-masked] 
         Phone: +1 408-853-9580 

         Kent Leung 
         Cisco Systems 
         170 W. Tasman Drive, 
         San Jose, CA 95134 
         USA 
         Email: [email-masked] 
         Phone: +1 408-526-5030 

   Intellectual Property Statement 

        The IETF takes no position regarding the validity or scope of 
        any intellectual property 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; neither does 
        it represent that it has made any effort to identify any such 
        rights. Information on the IETF's procedures with respect to 
        rights in standards-track and standards-related documentation 
        can be found in BCP-11. Copies of claims of rights made 
        available for publication 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 implementors or users of this specification can be 
        obtained from the IETF Secretariat. 

        The IETF invites any interested party to bring to its attention 
        any copyrights, patents or patent applications, or other 
        proprietary rights which may cover technology that may be 
        required to practice this standard. Please address the 
        information to the IETF Executive Director. 

   Full Copyright Statement 

        Copyright (C) The Internet Society (2004). All Rights Reserved. 
         
        This document and translations of it may be copied and 
        furnished to others, and derivative works that comment on or 
        otherwise explain it or assist in its implementation may be 
        prepared, copied, published and distributed, in whole or in 
  
  Patel, Leung        Expires November 10, 2004             [Page 11] 
    
  Internet Draft   Experimental Mesg., Ext. & Error Codes   May 2004 

        part, without restriction of any kind, provided that the above 
        copyright notice and this paragraph are included on all such 
        copies and derivative works.  However, this document itself may 
        not be modified in any way, such as by removing the copyright 
        notice or references to the Internet Society or other Internet 
        organizations, except as needed for the purpose of developing 
        Internet standards in which case the procedures for copyrights 
        defined in the Internet Standards process must be followed, or 
        as required to translate it into languages other than English. 
         
        The limited permissions granted above are perpetual and will 
        not be revoked by the Internet Society or its successors or 
        assigns. 
         
        This document and the information contained herein is provided 
        on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 
        ENGINEERING TASK FORCE DISCLAIMS 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.                             

   Acknowledgement 
         
        Funding for the RFC Editor function is currently provided by 
        the Internet Society. 

  Patel, Leung        Expires November 10, 2004             [Page 12]