doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc4917.txt b/doc/rfc/rfc4917.txt
new file mode 100644
index 0000000..d716639
--- /dev/null
+++ b/doc/rfc/rfc4917.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          V. Sastry
+Request for Comments: 4917                           Samsung Electronics
+Category: Standards Track                                       K. Leung
+                                                                A. Patel
+                                                           Cisco Systems
+                                                               June 2007
+
+
+                  Mobile IPv4 Message String Extension
+
+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 IETF Trust (2007).
+
+Abstract
+
+   This document specifies a new extension for use in Mobile IPv4.  This
+   extension can be added by the Home Agent and the Foreign Agent to
+   Registration Reply messages.  This extension carries a text string
+   that is intended for the user of the Mobile Node.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................2
+   3. Mobile IPv4 Message String Extension Format .....................2
+   4. Operation and Use of the Message String Extension ...............3
+   5. Security Considerations .........................................4
+   6. IANA Considerations .............................................4
+   7. Acknowledgements ................................................5
+   8. Normative References ............................................5
+
+
+
+
+
+
+
+
+
+
+
+
+Sastry, et al.              Standards Track                     [Page 1]
+
+RFC 4917          Mobile IPv4 Message String Extension         June 2007
+
+
+1.  Introduction
+
+   This document specifies a new skippable extension that can be added
+   by the Foreign Agent and Home Agent in any registration message
+   targeted for the Mobile Node.  Such a message may be either a
+   Registration Reply or Registration Revocation (i.e., co-located
+   Care-of Address mode).  For the Registration Reply message, this
+   extension can be added regardless of whether the registration has
+   succeeded or failed.
+
+   The content of the text string in this extension and its usage by the
+   Mobile Node is implementation specific.  The text string in this
+   extension is intended for the user of the Mobile Node.  For example,
+   this message can be displayed on the Mobile Node's user interface,
+   logged, or handled in any other implementation dependent way,
+   depending on the form of the Mobile Node.
+
+   Typical contents of the text string will indicate a registration
+   failure reason, or give a welcome message on successful registration.
+   This is important, as the failure reason code gives very limited
+   information for interpretation by the user of the Mobile Node.  For
+   example, a string like "registration failed : Prepaid Quota for the
+   user is exhausted" can give a human readable description of the
+   result of Mobile IP registration.
+
+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 RFC 2119 [RFC2119].
+
+3.  Mobile IPv4 Message String Extension Format
+
+   The Message String Extension conforms to the Short Extension format
+   specified for Mobile IPv4 [RFC3344].  The Message String Extension is
+   a skippable extension.
+
+    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   |    Text ....
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type:
+
+      145: An 8-bit identifier of the type mobility option.
+
+
+
+
+
+Sastry, et al.              Standards Track                     [Page 2]
+
+RFC 4917          Mobile IPv4 Message String Extension         June 2007
+
+
+   Length:
+
+      An 8-bit unsigned integer.  Length of the extension, in bytes,
+      excluding the extension Type and the extension Length fields.
+      This field MUST be set to 1 plus the total length of the Text
+      field.
+
+   Sub-Type:
+
+      1: Extension comes from the Home Agent
+
+      2: Extension comes from the Foreign Agent
+
+   Text:
+
+      The Text field is one or more octets, and its contents are
+      implementation dependent.  It is intended to be human readable,
+      and MUST NOT affect the operation of the protocol.  The message
+      MUST be in UTF-8 encoded ISO-10646 [RFC3629] characters.  The
+      number of octets in the encoded representation of the message is
+      always exactly the value of the Length field minus one.  (The
+      number of unicode characters represented by this octet sequence
+      may be smaller than the number of octets.)
+
+4.  Operation and Use of the Message String Extension
+
+   The Message String Extension is only valid for use within Mobile IPv4
+   Registration Reply and Registration Revocation messages.  The Message
+   String Extension is a skippable extension.  Either the Home Agent or
+   Foreign Agent or both can add the Message String Extension to
+   registration messages.  The usage of Text field of the Message String
+   Extension is implementation dependent.  For example, the message can
+   be displayed on the Mobile Node's user interface, logged, or handled
+   in an implementation dependent way, depending on the form of the
+   Mobile Node.  The Mobile Node may throttle how often the user is
+   notified of the message.
+
+   As an example, the Home Agent may reject the first Registration
+   Request because the prepaid quota for the user is reached and may
+   attach a Message String Extension with the text "Prepaid quota
+   reached.  Please contact www.paymore.example.com to update balance".
+   The Mobile Node could display this on the user interface.  As a
+   response, the user of the Mobile Node may take the required action to
+   update the prepaid account and retry the registration process.  The
+   Home Agent may accept this Registration Request and attach a Message
+
+
+
+
+
+
+Sastry, et al.              Standards Track                     [Page 3]
+
+RFC 4917          Mobile IPv4 Message String Extension         June 2007
+
+
+   String Extension with the text "Welcome to
+   www.serviceprovider.example.com".  The Mobile Node could display this
+   on the user interface, thus confirming a successful creation of
+   binding on Home Agent.
+
+   In the case that the message is not originated by the Home Agent
+   itself, but for instance, is received from a RADIUS server [RFC2865],
+   it could be received in some other encoding than UTF-8.  If so, the
+   Home Agent MUST convert the message to UTF-8 encoded ISO-10646
+   [RFC3629] characters.
+
+5.  Security Considerations
+
+   The Message String Extension can be added by the Home Agent or
+   Foreign Agent or both.  The protection of the extension is based on
+   the ordering method specified for message authentication in RFC 3344
+   [RFC3344] and emphasized below.
+
+   If the extension is added by the Home Agent (extension with subtype
+   1) to a Registration Reply or Registration Revocation message, it
+   MUST appear before Mobile-Home Authentication Extension [RFC3344].
+
+   If the extension is added by the Foreign Agent (extension with
+   subtype 2) to a Registration Reply message, it MUST appear after
+   Mobile-Home Authentication Extension [RFC3344] whenever present.
+   Also the extension MUST appear before the Mobile-Foreign
+   Authentication Extension whenever present.  However, since security
+   association between the Mobile Node and Foreign Agent is optional, it
+   is possible that the extension is not authenticated in this case.
+
+   There is no confidentiality provided by the extension; the message is
+   transferred unencrypted, and if sensitive information is sent for
+   display purposes, it may need to be protected by other means.
+
+6.  IANA Considerations
+
+   This specification reserves number 145 for the Message String
+   Extension in Section 3 from the space of numbers for skippable
+   mobility extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344]
+   at http://www.iana.org/assignments/mobileip-numbers.
+
+   This specification also creates a new subtype space for the type
+   number of this extension.  The subtype values 1 and 2 are defined in
+   this specification.  The subtype value 1 is reserved for use by the
+
+
+
+
+
+
+
+Sastry, et al.              Standards Track                     [Page 4]
+
+RFC 4917          Mobile IPv4 Message String Extension         June 2007
+
+
+   Home Agent and subtype value 2 is reserved for use by the Foreign
+   Agent.  Similar to the procedures specified for Mobile IPv4 [RFC3344]
+   number spaces, future allocations from this number space require
+   expert review [RFC2434].
+
+7.  Acknowledgements
+
+   The authors would like to thank Avi Lior, Curtis Provost, and Henrik
+   Levkowetz for their useful comments on an earlier version of this
+   document.  Also, Russ Housley, Vidya Narayanan, Blake Ramsdell, Paul
+   Hoffman, and Jeff Hutzelman provided justifications to mandate the
+   need for only UTF-8 encoding in the message and solicited better
+   clarifications in the security considerations section.
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+              "Remote Authentication Dial In User Service (RADIUS)", RFC
+              2865, June 2000.
+
+   [RFC3344]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
+              3344, August 2002.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sastry, et al.              Standards Track                     [Page 5]
+
+RFC 4917          Mobile IPv4 Message String Extension         June 2007
+
+
+Authors' Addresses
+
+   Venkateshwara Sastry
+   Samsung Electronics
+   124/C 5th D Cross
+   Girinagar I Phase
+   Bangalore  560085
+   India
+
+   Phone: +91-80-26725942
+   EMail: venkat.sastry@gmail.com
+
+
+   Kent Leung
+   Cisco Systems
+   170 W. Tasman Drive
+   San Jose, CA  95134
+   US
+
+   Phone: +1 408-526-5030
+   EMail: kleung@cisco.com
+
+
+   Alpesh Patel
+   Cisco Systems
+   170 W. Tasman Drive
+   San Jose, CA  95134
+   US
+
+   Phone: +1 408-853-9580
+   EMail: alpesh@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sastry, et al.              Standards Track                     [Page 6]
+
+RFC 4917          Mobile IPv4 Message String Extension         June 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Sastry, et al.              Standards Track                     [Page 7]
+