doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3025.txt b/doc/rfc/rfc3025.txt
new file mode 100644
index 0000000..398127d
--- /dev/null
+++ b/doc/rfc/rfc3025.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         G. Dommety
+Request for Comments: 3025                                      K. Leung
+Category: Standards Track                                  cisco Systems
+                                                           February 2001
+
+
+           Mobile IP Vendor/Organization-Specific Extensions
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document defines two new extensions to Mobile IP.  These
+   extensions will facilitate equipment vendors and organizations to
+   make specific use of these extensions as they see fit for research or
+   deployment purposes.
+
+1. Introduction
+
+   Current specification of Mobile IP [1] does not allow for
+   organizations and vendors to include organization/vendor-specific
+   information in the Mobile IP messages.  With the imminent wide scale
+   deployment of Mobile IP it is useful to have vendor or organization-
+   Specific Extensions to support this capability.  This document
+   defines two extensions that can be used for making organization
+   specific extensions by vendors/organizations for their own specific
+   purposes.
+
+1.1. Specification Language
+
+   The keywords "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 [3].
+
+   In addition, the following words are used to signify the requirements
+   of the specification.
+
+
+
+
+
+Dommety & Leung             Standards Track                     [Page 1]
+
+RFC 3025          Mobile IP Vendor Specific Extensions     February 2001
+
+
+   silently discard
+            The implementation discards the datagram without further
+            processing, and without indicating an error to the sender.
+            The implementation SHOULD provide the capability of logging
+            the error, including the contents of the discarded datagram,
+            and SHOULD record the event in a statistics counter.
+
+2. Vendor/Organization Specific Extensions
+
+   Two Vendor/Organization Specific Extensions are described, Critical
+   (CVSE) and Normal (NVSE) Vendor/Organization Specific Extensions.
+   The basic differences between the Critical and Normal Extensions are
+   that when the Critical extension is encountered but not recognized,
+   the message containing the extension MUST be silently discarded,
+   whereas when a Normal Vendor/Organization Specific Extension is
+   encountered but not recognized, the extension SHOULD be ignored, but
+   the rest of the Extensions and message data MUST still be processed.
+   Another difference between the two is that Critical
+   Vendor/Organization Extension has a length field of two octets and
+   the NVSE has a length field of only one octet.
+
+2.1. Critical Vendor/Organization Specific Extension (CVSE)
+
+   The format of this extension is as shown below.
+
+    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      |   Reserved    |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Vendor/Org-ID                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Vendor-CVSE-Type     |    Vendor-CVSE-Value ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Figure 1: Critical Vendor/Organization Specific Extension
+
+   Type       CVSE-TYPE-NUMBER 37
+
+   Reserved   Reserved for future use.  MUST be set to 0 on sending,
+              MUST be ignored on reception.
+
+   Length     Length in bytes of this extension, not including the Type
+              and Length bytes.
+
+
+
+
+
+
+
+Dommety & Leung             Standards Track                     [Page 2]
+
+RFC 3025          Mobile IP Vendor Specific Extensions     February 2001
+
+
+   Vendor/Org-ID
+              The high-order octet is 0 and the low-order 3 octets are
+              the SMI Network Management Private Enterprise Code of the
+              Vendor in network byte order, as defined in the Assigned
+              Numbers RFC [2].
+
+   Vendor-CVSE-Type
+              Indicates the particular type of Vendor-CVSE-Extension.
+              The administration of the Vendor-CVSE-Types is done by the
+              Vendor.
+
+   Vendor-CVSE-Value
+              Vendor/organization specific data of this Vendor-CVSE-
+              Extension.  These data fields may be published in future
+              RFCs.  The Vendor-CVSE-Value is zero or more octets.  The
+              length of this field can be computed from the Length Field
+              Value.
+
+   If an implementation does not recognize the CVSE, according to RFC
+   2002 [1], the entire packet is to be silently dropped.
+
+2.2. Normal Vendor/Organization Specific Extension (NVSE)
+
+   The format of this extension is as shown below.
+
+    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     |               Reserved        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Vendor/Org-ID                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Vendor-NVSE-Type           | Vendor-NVSE-Value ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 2: Normal Vendor/Organization Specific Extension
+
+   Type       NVSE-TYPE-NUMBER 133
+
+   Length     Length in bytes of this extension, not including the Type
+              and Length bytes.
+
+   Reserved   Reserved for future use.  To be set to 0.
+
+
+
+
+
+
+
+
+Dommety & Leung             Standards Track                     [Page 3]
+
+RFC 3025          Mobile IP Vendor Specific Extensions     February 2001
+
+
+   Vendor/Org-ID
+              The high-order octet is 0 and the low-order 3 octets are
+              the SMI Network Management Private Enterprise Code of the
+              Vendor in network byte order, as defined in the Assigned
+              Numbers RFC [2].
+
+   Vendor-NVSE-Type Indicates the particular type of Vendor-NVSE-
+              Extension. The administration of the Vendor-NVSE-Types is
+              done by the Vendor.
+
+   Vendor-NVSE-Value
+              Vendor/organization specific data of this Vendor-NVSE-
+              Extension.  These data fields may be published in future
+              RFCs.  The Vendor-NVSE-Value is zero or more octets.  The
+              length  of this field can be computed from the Length
+              Field Value.
+
+2.3 Vendor/Organization Specific Extensions Processing Considerations
+
+   When a Mobile IP entity receives a registration request message (or
+   any other request/update message) with an extension of type CVSE-
+   TYPE-NUMBER and recognizes it, but the extension contains an
+   unknown/unsupported vendor ID or Vendor-CVSE-Type, a registration
+   reject (or the appropriate deny message) MUST be sent with the error
+   code to indicate that the registration was rejected due to the
+   presence of an unknown CVSE.
+
+   When a Mobile IP entity receives a registration reply (or any other
+   mobile IP reply/acknowledgement message) with an extension of type
+   CVSE-TYPE-NUMBER and recognizes it, but the extensions contains an
+   unknown/unsupported vendor ID or Vendor-CVSE-Type, the processing is
+   performed as described below.
+
+   1. If the Mobile IP entity is a transit node for the reply (i.e.,
+   this entity processes and sends the registration reply to another
+   entity) a registration reject (or the appropriate deny message) MUST
+   be sent with the error code to indicate that the registration was
+   rejected due to the presence of an unknown CVSE.  For example, FA
+   when it receives an unknown CVSE in a registration reply from the HA,
+   should send a registration reject to the MN.
+
+   2. If the Mobile IP entity is not a transit node for the reply, the
+   reply is treated as a reject (or the appropriate deny message) due to
+   the presence of an unknown CVSE.
+
+
+
+
+
+
+
+Dommety & Leung             Standards Track                     [Page 4]
+
+RFC 3025          Mobile IP Vendor Specific Extensions     February 2001
+
+
+   While designing enhancements wherein a CVSE is included in a reply
+   message, it should noted that the reply message could be discarded by
+   the mobile IP entity processing this message.  Enhancements that
+   include a CVSE should take this into consideration during design.
+
+   When a Mobile IP entity receives a mobile IP related message
+   (registration request/reply, advertisement/solicitation, etc.) with
+   an extension of type NVSE-TYPE-NUMBER and recognizes it, but the
+   extension contains an unknown/unsupported vendor ID or Vendor-NVSE-
+   Type, the entire extension is skipped.
+
+   NOTE that according to RFC 2002 [1], when an extension numbered
+   within the range 0 through 127 is encountered in a registration
+   message but not recognized, the message containing that extension
+   MUST be silently discarded.  This document is compliant with the
+   above specification and specifies the action if the extension of type
+   CVSE-TYPE-NUMBER is encountered and recognized, but does not support
+   the vendor ID or the vendor type extension within.
+
+2.4 Error Codes
+
+   The following error codes are defined.
+
+   Registration denied by the Foreign agent:
+
+        ERROR-FA-1 100: Unsupported Vendor-ID or
+        unable to interpret Vendor-CVSE-Type in the CVSE sent by the
+        Mobile Node to the Foreign Agent.
+
+        ERROR-FA-2 101: Unsupported Vendor-ID or
+        unable to interpret Vendor-CVSE-Type in the CVSE sent by the
+        Home Agent to the Foreign Agent.
+
+   Registration denied by the Home agent:
+
+        ERROR-HA-1 140: Unsupported Vendor-ID or
+        unable to interpret Vendor-CVSE-Type in the CVSE sent by the
+        Mobile Node to the Home Agent.
+
+        ERROR-HA-2 141: Unsupported Vendor-ID or
+        unable to interpret Vendor-CVSE-Type in the CVSE sent by the
+        Foreign Agent to the Home Agent.
+
+
+
+
+
+
+
+
+
+Dommety & Leung             Standards Track                     [Page 5]
+
+RFC 3025          Mobile IP Vendor Specific Extensions     February 2001
+
+
+3. Restrictions
+
+   Multiple TLV's with the types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER
+   can be included in a message.  TLVs with types CVSE-TYPE-NUMBER and
+   NVSE-TYPE-NUMBER can be placed anywhere after the fixed portion of
+   the Mobile IP message.  These TLVs are expected to be protected by
+   the corresponding authenticator as necessary.  Ordering of these
+   TLV's should not be modified by intermediate nodes.
+
+4. IANA Considerations
+
+   The Critical Vendor/Organization Specific Extension (CVSE) as defined
+   in Section 2.1 and Normal Vendor/Organization Specific Extension
+   (NVSE) as defined in section 2.2 are proposed new extensions to the
+   Mobile IP protocol, defined in RFC 2002 [1] and extended in RFC 2356
+   [5].
+
+   IANA has assigned a Type value of CVSE-TYPE-NUMBER for the Critical
+   Vendor/Organization Specific Extension (CVSE), and a Type value of
+   NVSE-TYPE-NUMBER for the Normal Vendor/Organization Specific
+   Extension (NVSE).  The numbers CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER
+   for the CVSE and the NVSE are taken from the numbering space defined
+   for Mobile IP registration extensions [1].
+
+   IANA has assigned new Foreign Agent Error Codes, ERROR-FA-1 and
+   ERROR-FA-2 taken from the numbering space defined for Mobile IP
+   Foreign Agent error codes [1].  IANA has also assigned new Home Agent
+   Error Codes, ERROR-HA-1 and ERROR-HA-2 taken from the numbering space
+   defined for Mobile IP Home Agent error codes [1].
+
+5. Security Considerations
+
+   This document assumes that the Mobile IP messages are authenticated
+   using a method defined by the Mobile IP protocol.  This document does
+   not impose any additional requirements on Mobile IP messages from a
+   security point of view.  So this is not expected to be a security
+   issue.
+
+6. Acknowledgments
+
+   The authors would like to thank TR45.4 WG, TR45.6 WG, Basavaraj
+   Patil, Phil Roberts, Jouni Malinen, and Patrice Calhoun for their
+   useful discussions.
+
+
+
+
+
+
+
+
+Dommety & Leung             Standards Track                     [Page 6]
+
+RFC 3025          Mobile IP Vendor Specific Extensions     February 2001
+
+
+7. References
+
+   [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
+
+   [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+       October 1994.
+
+   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [4] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May
+       1998.
+
+   [5] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
+       Mobile IP", RFC 2356, June 1998.
+
+8. Authors' Addresses
+
+   Gopal Dommety
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: gdommety@cisco.com
+
+
+   Kent Leung
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: kleung@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dommety & Leung             Standards Track                     [Page 7]
+
+RFC 3025          Mobile IP Vendor Specific Extensions     February 2001
+
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dommety & Leung             Standards Track                     [Page 8]
+