doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc8168.txt b/doc/rfc/rfc8168.txt
new file mode 100644
index 0000000..76d6f61
--- /dev/null
+++ b/doc/rfc/rfc8168.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                             T. Li
+Request for Comments: 8168                                        C. Liu
+Category: Standards Track                                         Y. Cui
+ISSN: 2070-1721                                      Tsinghua University
+                                                                May 2017
+
+
+                    DHCPv6 Prefix-Length Hint Issues
+
+Abstract
+
+   DHCPv6 Prefix Delegation allows a client to include a prefix-length
+   hint value in the IA_PD option to indicate a preference for the size
+   of the prefix to be delegated, but it is unclear about how the client
+   and server should act in different situations involving the prefix-
+   length hint.  This document provides a summary of the existing
+   problems with the prefix-length hint and guidance on what the client
+   and server could do in different situations.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8168.
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Li, et al.                   Standards Track                    [Page 1]
+
+RFC 8168            DHCPv6 Prefix-Length Hint Issues            May 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
+   3.  Problem Description and Proposed Solutions  . . . . . . . . .   3
+     3.1.  Creation of Solicit Message . . . . . . . . . . . . . . .   3
+     3.2.  Receipt of Solicit Message  . . . . . . . . . . . . . . .   4
+     3.3.  Receipt of Advertise Message  . . . . . . . . . . . . . .   5
+     3.4.  Creation of Renew/Rebind Message  . . . . . . . . . . . .   6
+     3.5.  Receipt of Renew/Rebind Message . . . . . . . . . . . . .   6
+     3.6.  General Recommendation  . . . . . . . . . . . . . . . . .   8
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
+   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
+
+1.  Introduction
+
+   DHCPv6 Prefix Delegation [RFC3633] allows a client to include a
+   prefix-length hint value in the message sent to the server to
+   indicate a preference for the size of the prefix to be delegated.  A
+   prefix-length hint is communicated by a client to the server by
+   including an IA_PD Prefix Option (IAPREFIX option), encapsulated in
+   an IA_PD option, with the "IPv6 prefix" field set to zero and the
+   "prefix-length" field set to a non-zero value.  The servers are free
+   to ignore the prefix-length hint values depending on server policy.
+   However, some clients may not be able to function (or only in a
+   degraded state) when they're provided with a prefix whose length is
+   different from what they requested.  For example, if the client is
+   asking for a /56 and the server returns a /64, the functionality of
+   the client might be limited because it might not be able to split the
+   prefix for all its interfaces.  For other hints, such as requesting
+   for an explicit address, this might be less critical, as it just
+   helps a client that wishes to continue using what it used last time.
+   The prefix-length hint directly impacts the operational capability of
+   the client; thus, it should be given more consideration.
+
+   [RFC3633] is unclear about how the client and server should act in
+   different situations involving the prefix-length hint.  From the
+   client perspective, it should be able to use the prefix-length hint
+   to signal to the server its real-time need and should be able to
+   handle prefixes with lengths different from the prefix-length hint.
+   This document provides guidance on what a client should do in
+   different situations to help it operate properly.  From the server
+   perspective, the server is free to ignore the prefix-length hints
+   depending on server policy; however, in cases where the server has a
+
+
+
+
+Li, et al.                   Standards Track                    [Page 2]
+
+RFC 8168            DHCPv6 Prefix-Length Hint Issues            May 2017
+
+
+   policy for considering the hint, this document provides guidance on
+   how the prefix-length hint should be handled by the server in
+   different situations.
+
+2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Problem Description and Proposed Solutions
+
+3.1.  Creation of Solicit Message
+
+   Problem:
+
+   The Solicit message allows a client to ask servers for prefixes and
+   other configuration parameters.  The client might want a different
+   prefix length due to configuration changes, or it might just want the
+   same prefix again after reboot.  The client might also prefer a
+   prefix of a specific length in case the requested prefix is not
+   available.  The server could decide whether to provide the client
+   with the preferred prefix depending on server policy, but the client
+   should be able to signal to the server its real-time need.
+
+   The server usually has a record of the prefix it gave to the client
+   during its most recent interaction.  The best way to assure a
+   completely new delegated prefix is to send a new IAID (Identity
+   Association IDentifier) in the IA_PD (Identity Association for Prefix
+   Delegation).  However, this would require the client device to have
+   persistent storage, because rebooting the device would cause the
+   client to use the original IAID in the IA_PD.
+
+   Solution:
+
+   When the client prefers a prefix of a specific length from the
+   server, the client MUST send a Solicit message using the same IAID in
+   the IA_PD, include the preferred prefix-length value in the "prefix-
+   length" field of the IAPREFIX option, and set the "IPv6 prefix" field
+   to zero.  This is an indication to the server that the client prefers
+   a prefix of the specified length, regardless of what it received
+   before.
+
+   When the client wants the same prefix back from the server, it MUST
+   send a Solicit message using the same IAID in the IA_PD, include the
+   previously delegated prefix value in the "IPv6 prefix" field of the
+
+
+
+Li, et al.                   Standards Track                    [Page 3]
+
+RFC 8168            DHCPv6 Prefix-Length Hint Issues            May 2017
+
+
+   IAPREFIX option, and include the length of the prefix in the "prefix-
+   length" field.  This is an indication to the server that the client
+   wants the same prefix back.
+
+   When the client wants the same prefix back from the server and would
+   prefer to accept a prefix of a specified length in case the requested
+   prefix is not available, the client MUST send a Solicit message using
+   the same IAID in the IA_PD, include the previously delegated prefix
+   in one IAPREFIX option, and include the prefix-length hint in another
+   IAPREFIX option.  There is no requirement regarding the order of the
+   two IAPREFIX options.
+
+3.2.  Receipt of Solicit Message
+
+   Problem:
+
+   [RFC3633] allows a client to include a prefix-length hint in the
+   Solicit message to signal its preference to the server.  How the
+   prefix-length hint should be handled by the server is unclear.  The
+   client might want a different prefix length due to configuration
+   changes or it might just want the same prefix again after reboot.
+   The server should interpret these cases differently.
+
+   Many servers are configured to provide only prefixes of specific
+   lengths to the client, for example, if the client requested for a /54
+   but the server could only provide /30, /48, and /56.  How should
+   these servers decide which prefix to give to the client based on the
+   prefix-length hint?
+
+   Solution:
+
+   Upon the receipt of Solicit message, if the client included only a
+   prefix-length hint in the message, the server SHOULD first check its
+   prefix pool for a prefix with a length matching the prefix-length
+   hint value, regardless of the prefix record from previous
+   interactions with the client.  If the server does not have a prefix
+   with a length matching the prefix-length hint value, then the server
+   SHOULD provide the prefix whose length is shorter and closest to the
+   prefix-length hint value.
+
+   If the client included a specific prefix value in the Solicit
+   message, the server SHOULD check its prefix pool for a prefix
+   matching the requested prefix value.  If the requested prefix is not
+   available in the server's prefix pool, and the client also included a
+   prefix-length hint in the same IA_PD option, then the server SHOULD
+   check its prefix pool for a prefix with a length matching the prefix-
+   length hint value.  If the server does not have a prefix with a
+   length matching the prefix-length hint value, the server SHOULD
+
+
+
+Li, et al.                   Standards Track                    [Page 4]
+
+RFC 8168            DHCPv6 Prefix-Length Hint Issues            May 2017
+
+
+   provide the prefix whose length is shorter and closest to the prefix-
+   length hint value.
+
+   If the server will not assign any prefixes to any IA_PDs in a
+   subsequent Request from the client, the server MUST send an Advertise
+   message to the client as described in Section 11.2 of [RFC3633].
+
+3.3.  Receipt of Advertise Message
+
+   Problem:
+
+   The server might not be able to honor the prefix-length hint due to
+   server policy or lack of resources in its prefix pool.  If the prefix
+   length provided by the server in the Advertise message is different
+   from what the client requested in the Solicit message, the question
+   would be whether the client should use the provided prefix length or
+   continue to ask for its preferred prefix length.  There are certain
+   situations in which the client could not operate properly if it used
+   a prefix whose length is different from what it requested in the
+   prefix-length hint.  However, if the client ignores the Advertise
+   messages and continues to solicit for the preferred prefix length,
+   the client might be stuck in the DHCP process.  Another question is
+   whether the client should ignore other configuration parameters such
+   as available addresses.
+
+   Solution:
+
+   If the client could use the prefixes included in the Advertise
+   messages despite being different from the prefix-length hint, the
+   client SHOULD choose the shortest prefix length that is closest to
+   the prefix-length hint.  The client SHOULD continue requesting the
+   preferred prefix in the subsequent DHCPv6 messages as defined in
+   Section 3.4 of this document.
+
+   If the client sent a Solicit with only IA_PDs and cannot use the
+   prefixes included in the Advertise messages, it MUST ignore the
+   Advertise messages and continue to send Solicit messages until it
+   gets the preferred prefix.  To avoid traffic congestion, the client
+   MUST send Solicit messages at defined intervals, as specified in
+   [RFC7083].
+
+   If the client also solicited for other stateful configuration options
+   such as IA_NAs and the client cannot use the prefixes included in the
+   Advertise messages, the client SHOULD accept the other stateful
+   configuration options and continue to request the desired IA_PD
+   prefix in subsequent DHCPv6 messages as specified in [RFC7550].
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 5]
+
+RFC 8168            DHCPv6 Prefix-Length Hint Issues            May 2017
+
+
+3.4.  Creation of Renew/Rebind Message
+
+   Problem:
+
+   Servers might not be able to provide a prefix with the length equal
+   to or shorter than the prefix-length hint.  If the client decided to
+   use the prefix provided by the server despite it being longer than
+   the prefix-length hint but would still prefer the prefix-length hint
+   originally requested in the Solicit message, there should be some way
+   for the client to express this preference during Renew/Rebind.  For
+   example, if the client requested for a /60 but got a /64, the client
+   should be able to signal to the server during Renew/Rebind that it
+   would still prefer a /60.  This is to see whether the server has the
+   prefix preferred by the client available in its prefix pool during
+   Renew/Rebind.  [RFC3633] is not completely clear on whether the
+   client is allowed to include a prefix-length hint in the Renew/Rebind
+   message.
+
+   Solution:
+
+   During Renew/Rebind, if the client prefers a prefix length that is
+   different from the prefix it is currently using, then the client
+   SHOULD send the Renew/Rebind message with the same IA_PD, and include
+   two IAPREFIX options, one containing the currently delegated prefix
+   and the other containing the prefix-length hint.  This is to extend
+   the lifetime of the prefix the client is currently using, get the
+   prefix the client prefers, and go through a graceful switch over.
+
+   If the server is unable to provide the client with the newly
+   requested prefix, but is able to extend lifetime of the old prefix,
+   the client SHOULD continue using the old prefix.
+
+3.5.  Receipt of Renew/Rebind Message
+
+   Problem:
+
+   The prefix preferred by the client might become available in the
+   server's prefix pool during Renew/Rebind, even though it was
+   unavailable during Solicit.  This might be due to a server
+   configuration change or because some other client stopped using the
+   prefix.
+
+   The question is whether the server should remember the prefix-length
+   hint the client originally included in the Solicit message and check
+   it during Renew/Rebind to see if it has the prefix length the client
+   preferred.  This would require the server to keep extra information
+   about the client.  There is also the possibility that the client's
+   preference for the prefix length might have changed during this time
+
+
+
+Li, et al.                   Standards Track                    [Page 6]
+
+RFC 8168            DHCPv6 Prefix-Length Hint Issues            May 2017
+
+
+   interval, so the prefix-length hint remembered by the server might
+   not be what the client prefers during Renew/Rebind.
+
+   Instead of having the server remember the prefix-length hint of the
+   client, another option is for the client to include the prefix-length
+   hint in the Renew/Rebind message.  [RFC3633] is unclear about what
+   the server should do if the client also included a prefix-length hint
+   value in the Renew/Rebind message and whether the server could
+   provide a different prefix to the client during Renew/Rebind.
+
+   Solution:
+
+   Upon the receipt of a Renew/Rebind message, if the client included in
+   the IA_PD both an IAPREFIX option with the delegated prefix value and
+   an IAPREFIX option with a prefix-length hint value, the server SHOULD
+   check whether it could extend the lifetime of the original delegated
+   prefix and whether it has any available prefix matching the prefix-
+   length hint (or determine the closest possible to the prefix-length
+   hint) within its limit.
+
+   If the server assigned the prefix included in IA_PD to the client,
+   the server SHOULD do one of the following, depending on its policy:
+
+   1. Extend the lifetime of the original delegated prefix.
+
+   2. Extend the lifetime of the original delegated prefix and assign a
+      new prefix of the requested length.
+
+   3. Mark the original delegated prefix as invalid by giving it 0
+      lifetimes, and assign a new prefix of the requested length.  This
+      avoids the complexity of handling multiple delegated prefixes but
+      may break all the existing connections of the client.
+
+   4. Assign the original delegated prefix with 0 preferred-lifetime, a
+      specific non-zero valid-lifetime depending on actual requirement,
+      and assign a new prefix of the requested length.  This allows the
+      client to finish up existing connections with the original prefix
+      and use the new prefix to establish new connections.
+
+   5. Do not include the original delegated prefix in the Reply message,
+      and assign a new prefix of the requested length.  The original
+      prefix would be valid until its lifetime expires.  This avoids
+      sudden renumbering on the client.
+
+   If the server does not know the client's bindings (e.g., a different
+   server receiving the message during Rebind), then the server SHOULD
+   ignore the original delegated prefix and try to assign a new prefix
+   of the requested length.
+
+
+
+Li, et al.                   Standards Track                    [Page 7]
+
+RFC 8168            DHCPv6 Prefix-Length Hint Issues            May 2017
+
+
+   It's unnecessary for the server to remember the prefix-length hint
+   the client requested during Solicit.  It is possible that the
+   client's preference for the prefix length might have changed during
+   this time interval, so the prefix-length hint in the Renew message is
+   reflecting what the client prefers at the time.
+
+3.6.  General Recommendation
+
+   The recommendation to address the issues discussed in this document
+   is for a client that wants (at least) to have a delegated prefix of a
+   specific prefix length to always include an IAPREFIX option with just
+   the prefix-length hint in addition to any IAPREFIX options it has
+   included for each IA_PD in any Solicit, Request, Renew, and Rebind
+   messages it sends.  While a server is free to ignore the hint,
+   servers that do not choose to ignore the hint should attempt to
+   assign a prefix of the hint length (or assign the next closest length
+   that does not exceed the hint) if one is available.  Whether a server
+   favors the hint or avoiding a renumbering event is a matter of server
+   policy.
+
+4.  Security Considerations
+
+   This document provides guidance on how the clients and servers
+   interact with regard to the DHCPv6 prefix-length hint.  Security
+   considerations in DHCP are described in Section 23 of [RFC3315].
+   Security considerations regarding DHCPv6 prefix delegation are
+   described in Section 15 of [RFC3633].
+
+5.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+6.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
+              2003, <http://www.rfc-editor.org/info/rfc3315>.
+
+   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+              Host Configuration Protocol (DHCP) version 6", RFC 3633,
+              DOI 10.17487/RFC3633, December 2003,
+              <http://www.rfc-editor.org/info/rfc3633>.
+
+
+
+Li, et al.                   Standards Track                    [Page 8]
+
+RFC 8168            DHCPv6 Prefix-Length Hint Issues            May 2017
+
+
+   [RFC7083]  Droms, R., "Modification to Default Values of SOL_MAX_RT
+              and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November
+              2013, <http://www.rfc-editor.org/info/rfc7083>.
+
+   [RFC7550]  Troan, O., Volz, B., and M. Siodelski, "Issues and
+              Recommendations with Multiple Stateful DHCPv6 Options",
+              RFC 7550, DOI 10.17487/RFC7550, May 2015,
+              <http://www.rfc-editor.org/info/rfc7550>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <http://www.rfc-editor.org/info/rfc8174>.
+
+Acknowledgements
+
+   Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar,
+   Marcin Siodelski, Ted Lemon, Roni Even, Benoit Claise, Mirja
+   Kuehlewind, Kathleen Moriarty, Eric Rescorla, Alvaro Retana, Susan
+   Hares, and Hilarie Orman for their review and comments.
+
+Authors' Addresses
+
+   Tianxiang Li
+   Tsinghua University
+   Beijing  100084
+   China
+
+   Phone: +86-18301185866
+   Email: peter416733@gmail.com
+
+
+   Cong Liu
+   Tsinghua University
+   Beijing  100084
+   China
+
+   Phone: +86-10-6278-5822
+   Email: gnocuil@gmail.com
+
+
+   Yong Cui
+   Tsinghua University
+   Beijing  100084
+   China
+
+   Phone: +86-10-6260-3059
+   Email: yong.cui.thu@gmail.com
+
+
+
+
+Li, et al.                   Standards Track                    [Page 9]
+