doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc4242.txt b/doc/rfc/rfc4242.txt
new file mode 100644
index 0000000..95df46a
--- /dev/null
+++ b/doc/rfc/rfc4242.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          S. Venaas
+Request for Comments: 4242                                       UNINETT
+Category: Standards Track                                       T. Chown
+                                               University of Southampton
+                                                                 B. Volz
+                                                     Cisco Systems, Inc.
+                                                           November 2005
+
+
+                  Information Refresh Time Option for
+         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+
+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 (2005).
+
+Abstract
+
+   This document describes a Dynamic Host Configuration Protocol for
+   IPv6 (DHCPv6) option for specifying an upper bound for how long a
+   client should wait before refreshing information retrieved from
+   DHCPv6.  It is used with stateless DHCPv6 as there are no addresses
+   or other entities with lifetimes that can tell the client when to
+   contact the DHCPv6 server to refresh its configuration.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................2
+   3. Information Refresh Time Option Definition ......................2
+      3.1. Constants ..................................................3
+      3.2. Client Behaviour ...........................................3
+      3.3. Server Behaviour ...........................................4
+      3.4. Option Format ..............................................5
+   4. IANA Considerations .............................................5
+   5. Acknowledgements ................................................5
+   6. Security Considerations .........................................5
+   7. References ......................................................6
+      7.1. Normative References .......................................6
+      7.2. Informative References .....................................6
+
+
+
+Venaas, et al.              Standards Track                     [Page 1]
+
+RFC 4242       Information Refresh Time Option for DHCPv6  November 2005
+
+
+1.  Introduction
+
+   DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts.
+   However, many hosts will use stateless autoconfiguration as specified
+   in [RFC2462] for address assignment, and use DHCPv6 only for other
+   configuration data; see [RFC3736].  This other configuration data
+   will typically have no associated lifetime, hence there may be no
+   information telling a host when to refresh its DHCPv6 configuration
+   data.  Therefore, an option that can be used from server to client to
+   inform the client when it should refresh the other configuration data
+   is needed.
+
+   This option is useful in many situations:
+
+      - Unstable environments where unexpected changes are likely to
+        occur.
+
+      - For planned changes, including renumbering.  An administrator
+        can gradually decrease the time as the event nears.
+
+      - Limit the amount of time before new services or servers are
+        available to the client, such as the addition of a new NTP
+        server or a change of address of a DNS server.  See [RFC4076].
+
+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 BCP 14, RFC 2119
+   [RFC2119].
+
+3.  Information Refresh Time Option Definition
+
+   The information refresh time option specifies an upper bound for how
+   long a client should wait before refreshing information retrieved
+   from DHCPv6.  It is only used in Reply messages in response to
+   Information-Request messages.  In other messages there will usually
+   be other options that indicate when the client should contact the
+   server, e.g., addresses with lifetimes.
+
+   Note that it is only an upper bound.  If the client has any reason to
+   make a DHCPv6 request before the refresh time expires, it should
+   attempt to refresh all the data.
+
+   A client may contact the server before the refresh time expires.
+   Reasons it may do this include the need for additional configuration
+
+
+
+
+
+Venaas, et al.              Standards Track                     [Page 2]
+
+RFC 4242       Information Refresh Time Option for DHCPv6  November 2005
+
+
+   parameters (such as by an application), a new IPv6 prefix announced
+   by a router, or that it has an indication that it may have moved to a
+   new link.
+
+   The refresh time option specifies a common refresh time for all the
+   data.  It doesn't make sense to have different refresh time values
+   for different data, since when the client has reason to refresh some
+   of its data, it should also refresh the remaining data.  Because of
+   this, the option must only appear in the options area of the Reply
+   message.
+
+   The expiry of the refresh time in itself does not in any way mean
+   that the client should remove the data.  The client should keep its
+   current data while attempting to refresh it.  However, the client is
+   free to fall back to mechanisms other than DHCPv6 if it cannot
+   refresh the data within a reasonable amount of time.
+
+   When a client receives a Reply to an Information-Request that
+   contains configuration information, it should install that new
+   configuration information after removing any previously received
+   configuration information.  It should also remove information that is
+   missing from the new information set, e.g., an option might be left
+   out or contain only a subset of what it did previously.
+
+3.1.  Constants
+
+   We define two constants for use by the protocol.  How they are used
+   is specified in the sections below.
+
+      IRT_DEFAULT 86400
+         In some cases the client uses a default refresh time
+         IRT_DEFAULT.  The recommended value for IRT_DEFAULT is 86400
+         (24 hours).  The client implementation SHOULD allow for this
+         value to be configurable.
+
+      IRT_MINIMUM 600
+         This defines a minimum value for the refresh time.
+
+3.2.  Client Behaviour
+
+   A client MUST request this option in the Option Request Option (ORO)
+   when sending Information-Request messages to the DHCPv6 server.  A
+   client MUST NOT request this option in the ORO in any other messages.
+
+   If the Reply to an Information-Request message does not contain this
+   option, the client MUST behave as if the option with value
+   IRT_DEFAULT was provided.
+
+
+
+
+Venaas, et al.              Standards Track                     [Page 3]
+
+RFC 4242       Information Refresh Time Option for DHCPv6  November 2005
+
+
+   A client MUST use the refresh time IRT_MINIMUM if it receives the
+   option with a value less than IRT_MINIMUM.
+
+   As per section 5.6 of [RFC3315], the value 0xffffffff is taken to
+   mean "infinity" and implies that the client should not refresh its
+   configuration data without some other trigger (such as detecting
+   movement to a new link).
+
+   If a client contacts the server to obtain new data or refresh some
+   existing data before the refresh time expires, then it SHOULD also
+   refresh all data covered by this option.
+
+   When the client detects that the refresh time has expired, it SHOULD
+   try to update its configuration data by sending an Information-
+   Request as specified in section 18.1.5 of [RFC3315], except that the
+   client MUST delay sending the first Information-Request by a random
+   amount of time between 0 and INF_MAX_DELAY.
+
+   A client MAY have a maximum value for the refresh time, where that
+   value is used whenever the client receives this option with a value
+   higher than the maximum.  This also means that the maximum value is
+   used when the received value is "infinity".  A maximum value might
+   make the client less vulnerable to attacks based on forged DHCP
+   messages.  Without a maximum value, a client may be made to use wrong
+   information for a possibly infinite period of time.  There may
+   however be reasons for having a very long refresh time, so it may be
+   useful for this maximum value to be configurable.
+
+3.3.  Server Behaviour
+
+   A server sending a Reply to an Information-Request message SHOULD
+   include this option if it is requested in the ORO of the Information-
+   Request.
+
+   The option value MUST NOT be smaller than IRT_MINIMUM.  The server
+   SHOULD give a warning if it is configured with a smaller value.
+
+   The option MUST only appear in the options area of Reply messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Venaas, et al.              Standards Track                     [Page 4]
+
+RFC 4242       Information Refresh Time Option for DHCPv6  November 2005
+
+
+3.4.  Option Format
+
+   The format of the information refresh time option 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          option-code          |           option-len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    information-refresh-time                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code
+         OPTION_INFORMATION_REFRESH_TIME (32)
+
+      option-len
+         4
+
+      information-refresh-time
+         Time duration relative to the current time, expressed in units
+         of seconds
+
+4.  IANA Considerations
+
+   The IANA has assigned an option code for the information refresh time
+   option from the DHCPv6 option-code space [RFC3315].
+
+5.  Acknowledgements
+
+   The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten,
+   Joe Quanaim, and A.K. Vijayabhaskar for valuable discussions and
+   comments.
+
+6.  Security Considerations
+
+   Section 23 of [RFC3315] outlines the DHCPv6 security considerations.
+   This option does not change these in any significant way.  An
+   attacker could send faked Reply messages with a low information
+   refresh time value, which would trigger use of IRT_MINIMUM to
+   minimize this threat.  Another attack might be to send a very large
+   value, to make the client use forged information for a long period of
+   time.  A possible maximum limit at the client is suggested, which
+   would reduce this problem.
+
+
+
+
+
+
+
+
+Venaas, et al.              Standards Track                     [Page 5]
+
+RFC 4242       Information Refresh Time Option for DHCPv6  November 2005
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2462]   Thomson, S. and T. Narten, "IPv6 Stateless Address
+               Autoconfiguration", RFC 2462, December 1998.
+
+   [RFC3315]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+               and M. Carney, "Dynamic Host Configuration Protocol for
+               IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3736]   Droms, R., "Stateless Dynamic Host Configuration Protocol
+               (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+7.2.  Informative References
+
+   [RFC4076]   Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
+               Requirements for Stateless Dynamic Host Configuration
+               Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Venaas, et al.              Standards Track                     [Page 6]
+
+RFC 4242       Information Refresh Time Option for DHCPv6  November 2005
+
+
+Authors' Addresses
+
+   Stig Venaas
+   UNINETT
+   Trondheim  NO 7465
+   Norway
+
+   EMail: venaas@uninett.no
+
+
+   Tim Chown
+   University of Southampton
+   School of Electronics and Computer Science
+   Southampton, Hampshire  SO17 1BJ
+   United Kingdom
+
+   EMail: tjc@ecs.soton.ac.uk
+
+
+   Bernard Volz
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   USA
+
+   EMail: volz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Venaas, et al.              Standards Track                     [Page 7]
+
+RFC 4242       Information Refresh Time Option for DHCPv6  November 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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 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.
+
+
+
+
+
+
+
+Venaas, et al.              Standards Track                     [Page 8]
+