doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc4076.txt b/doc/rfc/rfc4076.txt
new file mode 100644
index 0000000..91c496b
--- /dev/null
+++ b/doc/rfc/rfc4076.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                           T. Chown
+Request for Comments: 4076                     University of Southampton
+Category: Informational                                        S. Venaas
+                                                                 UNINETT
+                                                        A. Vijayabhaskar
+                                   Cisco Systems (India) Private Limited
+                                                                May 2005
+
+
+                Renumbering Requirements for Stateless
+         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   IPv6 hosts using Stateless Address Autoconfiguration are able to
+   configure their IPv6 address and default router settings
+   automatically.  However, further settings are not available.  If
+   these hosts wish to configure their DNS, NTP, or other specific
+   settings automatically, the stateless variant of the Dynamic Host
+   Configuration Protocol for IPv6 (DHCPv6) could be used.  This
+   combination of Stateless Address Autoconfiguration and stateless
+   DHCPv6 could be used quite commonly in IPv6 networks.  However, hosts
+   using this combination currently have no means by which to be
+   informed of changes in stateless DHCPv6 option settings; e.g., the
+   addition of a new NTP server address, a change in DNS search paths,
+   or full site renumbering.  This document is presented as a problem
+   statement from which a solution should be proposed in a subsequent
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chown, et al.                Informational                      [Page 1]
+
+RFC 4076            Renumbering for Stateless DHCPv6            May 2005
+
+
+Table of Contents
+
+   1.  Introduction ...................................................2
+   2.  Problem Statement ..............................................3
+   3.  Renumbering Scenarios ..........................................3
+       3.1.  Site Renumbering .........................................4
+       3.2.  Changes to a DHCPv6-assigned Setting .....................4
+   4.  Renumbering Requirements .......................................4
+   5.  Considerations in Choosing a Solution ..........................4
+   6.  Solution Space .................................................5
+   7.  Summary ........................................................5
+   8.  Security Considerations ........................................6
+   9.  Acknowledgements ...............................................6
+   10. References .....................................................6
+       10.1. Normative References .....................................6
+       10.2. Informative References ...................................6
+
+1.  Introduction
+
+   IPv6 hosts using Stateless Address Autoconfiguration [2] are able to
+   configure their IPv6 address and default router settings
+   automatically.  Although Stateless Address Autoconfiguration for IPv6
+   allows automatic configuration of these settings, it does not provide
+   a mechanism for additional non IP-address settings to be configured
+   automatically.
+
+   The full version of the Dynamic Host Configuration Protocol for IPv6
+   (DHCPv6) [3] is designed to provide both stateful address assignment
+   to IPv6 hosts, as well as additional (non IP-address) configuration
+   including DNS, NTP, and other specific settings.  A full stateful
+   DHCPv6 server allocates the addresses and maintains the clients'
+   bindings to keep track of client leases.
+
+   If hosts using Stateless Address Autoconfiguration for IPv6 wish to
+   configure their DNS, NTP, or other specific settings automatically,
+   the stateless variant [4] of DHCPv6 could be used.  This variant is
+   more lightweight.  It does not do address assignment; instead, it
+   only provides additional configuration parameters, such as DNS
+   resolver addresses.  It does not maintain dynamic state about the
+   information assigned to clients, and therefore there is no need to
+   maintain dynamic per-client state on the server.
+
+   This combination of Stateless Address Autoconfiguration and stateless
+   DHCPv6 could be used quite commonly in IPv6 networks.
+
+
+
+
+
+
+
+Chown, et al.                Informational                      [Page 2]
+
+RFC 4076            Renumbering for Stateless DHCPv6            May 2005
+
+
+2.  Problem Statement
+
+   A problem, however, lies in the ability, or lack of ability, of
+   clients using this combination to be informed of (or to deduce)
+   changes in DHCPv6-assigned settings.
+
+   While a DHCPv6 server unicasts Reconfigure messages to individual
+   clients to trigger them to initiate Information-request/reply
+   configuration exchanges to update their configuration settings, the
+   stateless variant of DHCPv6 cannot use the Reconfigure mechanism
+   because it does not maintain a list of IP addresses (leases) to send
+   the unicast messages to.  Note that in DHCPv6, Reconfigure messages
+   must be unicast; multicast is not allowed.
+
+   Thus, events including the following cannot be handled:
+
+   o  Full site renumbering
+
+   o  DNS server change of address
+
+   o  NTP server change of address
+
+   o  A change in DNS search paths
+
+   It would be highly desirable that a host using the combination of
+   Stateless Address Autoconfiguration and stateless DHCPv6 could handle
+   a renumbering or reconfiguration event, whether planned or unplanned
+   by the network administrator.
+
+   Note that the scope of the problem could extend beyond Stateless
+   DHCPv6, since only IP address options have a lifetime; i.e., there is
+   no mechanism even in the full DHCPv6 that "expires" old information
+   or otherwise forces a client to recheck that new/updated information
+   is available.  However, with full DHCPv6, a node may learn of updates
+   to non-address options when renewing its address lease.
+
+3.  Renumbering Scenarios
+
+   There are two main scenarios for changes to DHCPv6-assigned settings
+   that would require the client to initiate an Information-request/
+   reply exchange to update the configuration.
+
+
+
+
+
+
+
+
+
+
+Chown, et al.                Informational                      [Page 3]
+
+RFC 4076            Renumbering for Stateless DHCPv6            May 2005
+
+
+3.1.  Site Renumbering
+
+   One of the fundamental principles of IPv6 is that sites receive their
+   IPv6 address allocations from an ISP using provider-assigned (PA)
+   address space.  There is currently no provider-independent (PI)
+   address space in IPv6.  Therefore, a site changing its ISP must
+   renumber its network.  Any such site renumbering will require hosts
+   to reconfigure both their own address and default router settings and
+   their stateless DHCPv6-assigned settings.
+
+3.2.  Changes to a DHCPv6-assigned Setting
+
+   An administrator may need to change one or more stateless
+   DHCPv6-assigned settings; e.g., an NTP server, DNS server, or the DNS
+   search path.  This may be required if a new, additional DNS server is
+   brought online and is moved to a new network (prefix), or if an
+   existing server is decommissioned or known to be unavailable.
+
+4.  Renumbering Requirements
+
+   Ideally, any of the above scenarios should be handled automatically
+   by the hosts on the network.  For this to be realised, a method is
+   required whereby the hosts are informed that they should request new
+   stateless DHCPv6-assigned setting information.
+
+   The solution to the problem may depend on whether the renumbering or
+   configuration change is planned or unplanned, from the perspective of
+   the network administrator.  There is already work underway toward
+   understanding the planned renumbering [5] scenario for IPv6 networks.
+   However, there is currently no mechanism in stateless DHCPv6 for
+   handling planned renumbering events.
+
+5.  Considerations in Choosing a Solution
+
+   A number of considerations could be listed for a desirable solution:
+
+   o  The solution should support planned renumbering; it is desirable
+      that it also supports unplanned renumbering.
+
+   o  Security is important.  No new security concerns should be
+      introduced to Stateless DHCPv6 by the solution.
+
+   o  It must be possible to update options, even if the network is not
+      renumbered.
+
+   o  It is desirable to maintain the "stateless" property; i.e., no
+      per-client state should need to be kept in the server.
+
+
+
+
+Chown, et al.                Informational                      [Page 4]
+
+RFC 4076            Renumbering for Stateless DHCPv6            May 2005
+
+
+6.  Solution Space
+
+   Solutions should be designed and presented in a separate document.
+   An initial brief set of candidate solutions might include the
+   following:
+
+   o  Add a Reconfigure message mechanism that would work in the
+      stateless DHCPv6 environment.  This could enable planned or
+      unplanned events, but may require a multicast mechanism in order
+      to be realised.
+
+   o  Convey a valid lifetime timer to clients for stateless DHCPv6-
+      assigned settings.  This could primarily enable planned events,
+      but with a small time-out it could handle unplanned events to some
+      extent at the expense of the additional request traffic.  The
+      selection of recommended lifetime values/ranges would be the
+      subject of future work.
+
+   o  Use some form of Router Advertisement (RA) [1] as a hint to
+      request new stateless DHCPv6-assigned settings.  Using only an
+      observed new RA prefix as a hint to re-request settings would not
+      handle changes that are purely to NTP, DNS, or other options.
+      Other possible means of detection of network (re)attachment could
+      also be used as cues (e.g., see Goals of Detecting Network
+      Attachment (DNA) in IPv6 [6]).
+
+   o  Change the semantics of the 'O' flag in RAs [2] so that toggling
+      its value may trigger an Information-request message.
+
+   There will also be conditions under which a client should send an
+   Information-request, such as reconnection to a link.  Recommendations
+   for these cases are outside the scope of this document, but we expect
+   ongoing work in the DNA WG (as scoped in Goals of Detecting Network
+   Attachment (DNA) in IPv6 [6]) to yield recommendations.
+
+7.  Summary
+
+   This document presents a problem statement for how IPv6 hosts that
+   use the combination of Stateless Address Autoconfiguration and
+   stateless DHCPv6 may be informed of renumbering events or other
+   changes to the settings that they originally learned through
+   stateless DHCPv6.  A short list of candidate solutions is presented,
+   which the authors hope will be expanded upon in subsequent documents.
+
+
+
+
+
+
+
+
+Chown, et al.                Informational                      [Page 5]
+
+RFC 4076            Renumbering for Stateless DHCPv6            May 2005
+
+
+8.  Security Considerations
+
+   There are no security considerations in this problem statement per
+   se.  However, whatever mechanism is designed or chosen to address
+   this problem should avoid introducing new security concerns for
+   (stateless) DHCPv6.
+
+   The issues of maintaining appropriate security through a renumbering
+   event are outside the scope of this document (if specific servers
+   within the network are being added or removed, firewall
+   configurations and ACLs, for example, will need to reflect this).
+   However, this is an important area for further work.
+
+9.  Acknowledgements
+
+   The authors would like to thank Ralph Droms, Bernie Volz, and other
+   individuals on the DHC mail list for their comments on this document,
+   as well as colleagues on the 6NET project.  We also thank the review
+   comments, particularly those from Thomas Narten.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+        for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [2]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+        Autoconfiguration", RFC 2462, December 1998.
+
+   [3]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+        RFC 3315, July 2003.
+
+   [4]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
+        Service for IPv6", RFC 3736, April 2004.
+
+10.2.  Informative References
+
+   [5]  Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an
+        IPv6 Network without a Flag Day", Work in Progress, July 2004.
+
+   [6]  Choi, J., "Goals of Detecting Network Attachment (DNA) in IPv6",
+        Work in Progress, October 2004.
+
+
+
+
+
+
+
+Chown, et al.                Informational                      [Page 6]
+
+RFC 4076            Renumbering for Stateless DHCPv6            May 2005
+
+
+Authors' Addresses
+
+   Tim Chown
+   University of Southampton
+   School of Electronics and Computer Science
+   Southampton, Hampshire  SO17 1BJ
+   United Kingdom
+
+   EMail: tjc@ecs.soton.ac.uk
+
+
+   Stig Venaas
+   UNINETT
+   Trondheim  NO 7465
+   Norway
+
+   EMail: venaas@uninett.no
+
+
+   Vijayabhaskar A Kalusivalingam
+   Cisco Systems (India) Private Limited
+   9, Brunton Road
+   Bangalore  560025
+   India
+
+   EMail: vibhaska@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chown, et al.                Informational                      [Page 7]
+
+RFC 4076            Renumbering for Stateless DHCPv6            May 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.
+
+
+
+
+
+
+
+Chown, et al.                Informational                      [Page 8]
+