doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc6603.txt b/doc/rfc/rfc6603.txt
new file mode 100644
index 0000000..76e3405
--- /dev/null
+++ b/doc/rfc/rfc6603.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  J. Korhonen, Ed.
+Request for Comments: 6603                        Nokia Siemens Networks
+Updates: 3633                                              T. Savolainen
+Category: Standards Track                                          Nokia
+ISSN: 2070-1721                                              S. Krishnan
+                                                                Ericsson
+                                                                O. Troan
+                                                      Cisco Systems, Inc
+                                                                May 2012
+
+
+        Prefix Exclude Option for DHCPv6-based Prefix Delegation
+
+Abstract
+
+   This specification defines an optional mechanism to allow exclusion
+   of one specific prefix from a delegated prefix set when using
+   DHCPv6-based prefix delegation.  The new mechanism updates RFC 3633.
+
+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 5741.
+
+   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/rfc6603.
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+
+
+
+Korhonen, et al.             Standards Track                    [Page 1]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Requirements and Terminology ....................................2
+   3. Problem Background ..............................................3
+   4. Solution ........................................................3
+      4.1. Prefix Delegation with Excluded Prefixes ...................3
+      4.2. Prefix Exclude Option ......................................4
+   5. Delegating Router Solicitation ..................................6
+      5.1. Requesting Router ..........................................6
+      5.2. Delegating Router ..........................................6
+   6. Requesting Router Initiated Prefix Delegation ...................7
+      6.1. Requesting Router ..........................................7
+      6.2. Delegating Router ..........................................8
+   7. Security Considerations .........................................8
+   8. IANA Considerations .............................................8
+   9. Acknowledgements ................................................8
+   10. References .....................................................9
+      10.1. Normative References ......................................9
+      10.2. Informative References ....................................9
+
+1.  Introduction
+
+   This specification defines an optional mechanism and the related
+   DHCPv6 option to allow exclusion of one specific prefix from a
+   delegated prefix set when using DHCPv6-based prefix delegation.
+
+   The prefix exclusion mechanism is targeted at deployments where
+   DHCPv6-based prefix delegation is used, but a single aggregated
+   route/prefix has to represent one customer, instead of using one
+   prefix for the link between the delegating router and the requesting
+   router and another prefix for the customer network.  The mechanism
+   defined in this specification allows a delegating router to use a
+   prefix out of the delegated prefix set on the link through which it
+   exchanges DHCPv6 messages with the requesting router, and is intended
+   for use in networks where each requesting router is on its own
+   layer-2 domain.
+
+2.  Requirements and 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 [RFC2119].
+
+
+
+
+
+
+
+
+Korhonen, et al.             Standards Track                    [Page 2]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+3.  Problem Background
+
+   DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit
+   limitation described in Section 12.1 of [RFC3633] that a prefix
+   delegated to a requesting router cannot be used by the delegating
+   router.  This restriction implies that the delegating router will
+   have two (non-aggregatable) routes towards a customer: one for the
+   link between the requesting router and the delegating router, and one
+   for the customer site behind the requesting router.
+
+   There are architectures and link models where a host (e.g., a mobile
+   router, also acting as a requesting router) always has a single (/64)
+   prefix configured on its uplink interface and the delegating router
+   is also the requesting router's first-hop router.  Furthermore, it
+   may be required that the prefix configured on the uplink interface
+   has to be aggregatable with the delegated prefixes.  This introduces
+   a problem in how to use DHCPv6-PD together with stateless [RFC4862]
+   or stateful [RFC3315] address autoconfiguration on a link where the
+   /64 advertised is also part of the prefix delegated (e.g., /56) to
+   the requesting router.
+
+4.  Solution
+
+4.1.  Prefix Delegation with Excluded Prefixes
+
+   This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE
+   (67), that is used to exclude exactly one prefix from a delegated
+   prefix.  The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX
+   IAprefix-options field.  There can be at most one OPTION_PD_EXCLUDE
+   option in one OPTION_IAPREFIX option.  The OPTION_PD_EXCLUDE option
+   allows prefix delegation where a requesting router is delegated a
+   prefix (e.g., /56) and the delegating router uses one prefix (e.g.,
+   /64) on the link through which it exchanges DHCPv6 messages with the
+   requesting router with a prefix out of the same delegated prefix set.
+
+   A requesting router includes an OPTION_ORO option with the
+   OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, or Rebind
+   message to inform the delegating router about the support for the
+   prefix delegation functionality defined in this specification.  A
+   delegating router may include the OPTION_PD_EXCLUDE option code in an
+   OPTION_ORO option in a Reconfigure message to indicate that the
+   requesting router should request OPTION_PD_EXCLUDE from the
+   delegating router.
+
+
+
+
+
+
+
+
+Korhonen, et al.             Standards Track                    [Page 3]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+   The delegating router includes the prefix in the OPTION_PD_EXCLUDE
+   option that is excluded from the delegated prefix set.  The
+   requesting router MUST NOT assign the excluded prefix to any of its
+   downstream interfaces.
+
+4.2.  Prefix Exclude Option
+
+    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_PD_EXCLUDE       |         option-len            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  prefix-len   | IPv6 subnet ID (1 to 16 octets)               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                           Prefix Exclude Option
+
+   o  option-code: OPTION_PD_EXCLUDE (67).
+
+   o  option-len: 1 + length of IPv6 subnet ID in octets.  A valid
+      option-len is between 2 and 17.
+
+   o  prefix-len: The length of the excluded prefix in bits.  The
+      prefix-len MUST be between 'OPTION_IAPREFIX prefix-length'+1 and
+      128.
+
+   o  IPv6 subnet ID: A variable-length IPv6 subnet ID up to 128 bits.
+
+   The IPv6 subnet ID contains prefix-len minus 'OPTION_IAPREFIX prefix-
+   length' bits extracted from the excluded prefix starting from the bit
+   position 'OPTION_IAPREFIX prefix-length'.  The extracted subnet ID
+   MUST be left-shifted to start from a full octet boundary, i.e., left-
+   shift of 'OPTION_IAPREFIX prefix-length' mod 8 bits.  The subnet ID
+   MUST be zero-padded to the next full octet boundary.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al.             Standards Track                    [Page 4]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+   The encoding of the IPv6 subnet ID can be expressed in a C-like
+   pseudocode as shown below:
+
+     uint128_t p1;           // the delegated IPv6 prefix
+     uint128_t p2;           // the excluded IPv6 prefix
+     uint16_t a;             // the OPTION_IAPREFIX prefix-length
+     uint8_t b;              // the excluded IPv6 prefix length
+     uint8_t s;
+
+     // sanity checks
+
+     s = 128-a;              // size of non-prefix bits
+     assert(b>a);            // b must be at least a+1
+     assert(p1>>s == p2>>s); // p1 and p2 must share a common
+                             // prefix of 'a' bits
+
+     // calculate the option content
+
+     uint16_t c = b-a-1;     // the IPv6_subnet_ID_length-1 in bits
+     uint16_t d = (c/8)+1;   // the IPv6_subnet_ID_length in octets
+     uint128_t p = p2<<a;    // p is the IPv6 subnet ID that has the
+                             // common p1 prefix left-shifted out to
+                             // a full octet boundary (trailing bits
+                             // are zeroed)
+
+     // populate the option
+
+     uint8_t* id = &OPTION_PD_EXCLUDE.IPv6_subnet_ID;
+     OPTION_PD_EXCLUDE.option_len = d+1;
+     OPTION_PD_EXCLUDE.prefix_len = b;
+
+     while (d-- > 0) {
+       *id++ = p>>120;
+       p <<= 8;
+     }
+
+   The OPTION_PD_EXCLUDE option MUST only be included in the
+   OPTION_IAPREFIX IAprefix-options [RFC3633] field.
+
+   Any prefix excluded from the delegated prefix MUST be contained in
+   OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX.
+
+   The prefix included in the OPTION_PD_EXCLUDE option shares the same
+   preferred-lifetime and valid-lifetime as the delegated prefix in the
+   encapsulating OPTION_IAPREFIX option.
+
+   The prefix in the OPTION_PD_EXCLUDE option MUST be part of the
+   delegated prefix in the OPTION_IAPREFIX.  For example, the requesting
+
+
+
+Korhonen, et al.             Standards Track                    [Page 5]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+   router has earlier been assigned a 2001:db8:dead:beef::/64 prefix by
+   the delegating router, and the delegated prefix in the
+   OPTION_IAPREFIX is 2001:db8:dead:bee0::/59.  In this case, 2001:db8:
+   dead:beef::/64 is a valid prefix to be used in the OPTION_PD_EXCLUDE
+   option.  The OPTION_PD_EXCLUDE option would be encoded as follows:
+
+    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_PD_EXCLUDE       |               2               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       64      |0|1|1|1|1|0|0|0|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                   ^         ^
+                   |         |
+                   |         +- 3 zero-padded bits follow
+                   |
+                   +- using C syntax: 0xef << (59 % 8)
+                      Note: 59 mod 8 = 3
+
+5.  Delegating Router Solicitation
+
+   The requesting router locates and selects a delegating router in the
+   same way as described in Section 11 [RFC3633].  This specification
+   only describes the additional steps required by the use of the
+   OPTION_PD_EXCLUDE option.
+
+5.1.  Requesting Router
+
+   If the requesting router implements the solution described in Section
+   4.1, then the requesting router SHOULD include the OPTION_PD_EXCLUDE
+   option code in the OPTION_ORO option in Solicit messages.
+
+   Once receiving Advertise message(s), the requesting router uses the
+   prefix(es) received in OPTION_PD_EXCLUDE, in addition to the
+   advertised prefixes, to choose the delegating router.  The requesting
+   router MUST proceed to the Prefix Delegation procedure described in
+   Section 6.1.  If the Advertise message did not include the
+   OPTION_PD_EXCLUDE option, then the requesting router MUST fall back
+   to normal behavior, as described in Section 11.1 of [RFC3633].
+
+5.2.  Delegating Router
+
+   If the OPTION_ORO option in the Solicit message includes the
+   OPTION_PD_EXCLUDE option code, then the delegating router knows that
+   the requesting router supports the solution defined in this
+   specification.  If the Solicit message also contains an IA_PD option,
+   the delegating router can delegate to the requesting router a prefix
+
+
+
+Korhonen, et al.             Standards Track                    [Page 6]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+   that includes the prefix already assigned to the requesting router's
+   uplink interface.  The delegating router includes the prefix
+   originally, or to be, assigned to the requesting router in the
+   OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option
+   in the Advertise message.
+
+   If the OPTION_ORO option in the Solicit message does not include the
+   OPTION_PD_EXCLUDE option code, then the delegating router MUST fall
+   back to normal behavior, as described in Section 11.2 of [RFC3633].
+
+   If the OPTION_ORO option in the Solicit message includes the
+   OPTION_PD_EXCLUDE option code but the delegating router does not
+   support the solution described in this specification, then the
+   delegating router acts as specified in [RFC3633].
+
+6.  Requesting Router-Initiated Prefix Delegation
+
+   The procedures described in the following sections are aligned with
+   Section 12 of [RFC3633].  In this specification, we only describe the
+   additional steps required by the use of the OPTION_PD_EXCLUDE option.
+
+6.1.  Requesting Router
+
+   The requesting router behavior regarding the use of the
+   OPTION_PD_EXCLUDE option is mostly identical to the steps described
+   in Section 5.1, with the difference being the use of a DHCPv6 Request
+   instead of an Solicit message.  The requesting router SHOULD include
+   the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6
+   messages as described in Section 22.7 of [RFC3315].  The requesting
+   router SHOULD include the OPTION_PD_EXCLUDE option code in the
+   OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of
+   [RFC3315].
+
+   The requesting router uses a Release message to return the delegated
+   prefix(es) to a delegating router.  The prefix(es) to be released
+   MUST be included in the IA_PDs along with the excluded prefix
+   included in the OPTION_PD_EXCLUDE option.  The requesting router MUST
+   NOT use the OPTION_PD_EXCLUDE option to introduce an additional
+   excluded prefix in the Release message for which it originally got a
+   valid binding.
+
+   The requesting router must create sink routes for the delegated
+   prefixes, minus the excluded prefixes.  This may be done by creating
+   sink routes for delegated prefixes and more specific routes for the
+   excluded prefixes.
+
+
+
+
+
+
+Korhonen, et al.             Standards Track                    [Page 7]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+6.2.  Delegating Router
+
+   The delegating router behavior regarding the use of the
+   OPTION_PD_EXCLUDE option is more or less identical to the step
+   described in Section 5.2.  The only difference is the DHCPv6 messages
+   used to carry the OPTION_PD_EXCLUDE option.
+
+   The delegating router may mark any prefix(es) in the IA_PD Prefix
+   options in a Release message from a requesting router as 'available',
+   excluding the prefix included in the OPTION_PD_EXCLUDE options.  If
+   the Release message contains a 'new' excluded prefix in any
+   OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply
+   message with the Status Code set to NoBinding for that IA_PD option.
+
+7.  Security Considerations
+
+   Security considerations for DHCPv6 are described in Section 23 of
+   [RFC3315].  For DHCPv6 Prefix Delegation, they are described in
+   Section 15 of [RFC3633].  In particular, RFC 3633 provides
+   recommendations for protection against prefix delegation attacks.
+   This specification does not add any new security considerations
+   beyond those provided by RFC 3633.
+
+8.  IANA Considerations
+
+   A new DHCPv6 Option Code has been reserved from the "Dynamic Host
+   Configuration Protocol for IPv6 (DHCPv6)" registry for DHCP Option
+   Codes.
+
+      OPTION_PD_EXCLUDE   (67)
+
+9.  Acknowledgements
+
+   The authors would like to thank Ralph Droms, Frank Brockners, Ted
+   Lemon, Julien Laganier, Fredrik Garneij, Sri Gundavelli, Mikael
+   Abrahamsson, Behcet Sarikaya, Jyrki Soini, Deng Hui, Stephen Jacob,
+   Hemant Singh, Gaurav Halwasia, Lorenzo Colitti, and Tomasz Mrugalski
+   for their valuable comments and discussions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al.             Standards Track                    [Page 8]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+              Host Configuration Protocol (DHCP) version 6", RFC 3633,
+              December 2003.
+
+10.2.  Informative References
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862, September 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al.             Standards Track                    [Page 9]
+
+RFC 6603                    PD Exclude Option                   May 2012
+
+
+Authors' Addresses
+
+   Jouni Korhonen (editor)
+   Nokia Siemens Networks
+   Linnoitustie 6
+   FI-02600 Espoo
+   Finland
+
+   EMail: jouni.nospam@gmail.com
+
+
+   Teemu Savolainen
+   Nokia
+   Hermiankatu 12 D
+   FI-33720 Tampere
+   Finland
+
+   EMail: teemu.savolainen@nokia.com
+
+
+   Suresh Krishnan
+   Ericsson
+   8400 Decarie Blvd.
+   Town of Mount Royal, QC
+   Canada
+
+   EMail: suresh.krishnan@ericsson.com
+
+
+   Ole Troan
+   Cisco Systems, Inc
+   Oslo
+   Norway
+
+   EMail: ot@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al.             Standards Track                   [Page 10]
+