diff options
Diffstat (limited to 'doc/rfc/rfc8026.txt')
| -rw-r--r-- | doc/rfc/rfc8026.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc8026.txt b/doc/rfc/rfc8026.txt new file mode 100644 index 0000000..c2e6b88 --- /dev/null +++ b/doc/rfc/rfc8026.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Boucadair +Request for Comments: 8026 Orange +Category: Standards Track I. Farrer +ISSN: 2070-1721 Deutsche Telekom AG + November 2016 + + + Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): + A DHCPv6-Based Prioritization Mechanism + +Abstract + + In IPv6-only provider networks, transporting IPv4 packets + encapsulated in IPv6 is a common solution to the problem of IPv4 + service continuity. A number of differing functional approaches have + been developed for this, each having their own specific + characteristics. As these approaches share a similar functional + architecture and use the same data plane mechanisms, this memo + specifies a DHCPv6 option, whereby a single instance of Customer + Premises Equipment (CPE) can interwork with all of the standardized + and proposed approaches to providing encapsulated IPv4-in-IPv6 + services by providing a prioritization mechanism. + +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/rfc8026. + + + + + + + + + + + + + + + +Boucadair & Farrer Standards Track [Page 1] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + +Copyright Notice + + Copyright (c) 2016 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4 + 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. DHCPv6 S46 Priority Option . . . . . . . . . . . . . . . 5 + 1.4. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 6 + 1.5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 + 2. Operator Deployment Considerations for Deploying Multiple + Softwire Mechanisms . . . . . . . . . . . . . . . . . . . . . 7 + 2.1. Client Address Planning . . . . . . . . . . . . . . . . . 7 + 2.2. Backwards Compatability with Existing Softwire Clients . 7 + 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. S46 Mechanisms and Their Identifying Option Codes . . . . 8 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 + 5.2. Informative References . . . . . . . . . . . . . . . . . 10 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + + + + + + + + + + + + + + + +Boucadair & Farrer Standards Track [Page 2] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + +1. Introduction + + IPv4 service continuity is one of the major technical challenges that + must be considered during IPv6 migration. Over the past few years, a + number of different approaches have been developed to assist with + this problem (e.g., as described in [RFC6333], [RFC7596], and + [RFC7597]). These approaches, referred to as "S46 mechanisms" in + this document, exist in order to meet the particular deployment, + scaling, addressing, and other requirements of different service + providers' networks. + + A common feature shared among all of the differing modes is the + integration of softwire tunnel endpoint functionality into the + Customer Premises Equipment (CPE) router. Due to this inherent data + plane similarity, a single CPE may be capable of supporting several + different approaches. Users may also wish to configure a specific + mode of operation. + + A service provider's network may also have more than one S46 + mechanism enabled in order to support a diverse CPE population with + differing client functionality, such as during a migration between + mechanisms or where services require specific supporting softwire + architectures. + + For softwire-based services to be successfully established, it is + essential that the customer's end node and the service provider's end + node and provisioning systems are able to indicate their capabilities + and preferred mode of operation. + + A number of DHCPv6 options for the provisioning of softwires have + been standardized: + + RFC 6334 Defines DHCPv6 option 64 for configuring Basic Bridging + BroadBand (B4) [RFC6333] elements with the IPv6 address of + the Address Family Transition Router (AFTR) [RFC6333]. + + RFC 7341 Defines DHCPv6 option 88 for configuring the address of a + DHCPv4-over-DHCPv6 server, which can then be used by a + softwire client for obtaining further configuration. + + RFC 7598 Defines DHCPv6 options 94, 95, and 96 for provisioning + Mapping of Address and Port with Encapsulation (MAP-E) + [RFC7597], Mapping of Address and Port using Translation + (MAP-T) [RFC7599], and Lightweight 4over6 [RFC7596] + respectively. + + + + + + +Boucadair & Farrer Standards Track [Page 3] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + + This document describes a DHCPv6-based prioritization method, whereby + a CPE that supports several S46 mechanisms and receives configuration + for more than one can prioritize which mechanism to use. The method + requires no server-side logic to be implemented and only uses a + simple S46 mechanism prioritization to be implemented in the CPE. + + The prioritization method as described here does not provide + redundancy between S46 mechanisms for the client. That is, if the + highest priority S46 mechanism that has been provisioned to the + client is not available for any reason, the means for identifying + this and falling back to the S46 mechanism with the next highest + priority is not in the scope of this document. + +1.1. Terminology + + This document makes use of the following terms: + + o Address Family Transition Router (AFTR): The IPv4-in-IPv6 tunnel + termination point and the Network Address Translator IPv4/IPv4 + (NAT44) function deployed in the operator's network [RFC6333]. + + o Border Relay (BR): A MAP-enabled router managed by the service + provider at the edge of a MAP domain. A BR has at least an + IPv6-enabled interface and an IPv4 interface connected to the + native IPv4 network [RFC7597]. + + o Customer Premises Equipment (CPE): Denotes the equipment at the + customer edge that terminates the customer end of an IPv6 + transitional tunnel. In some documents (e.g., [RFC7597]), this + functional entity is called the Customer Edge (CE). + +1.1.1. Requirements Language + + 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]. + +1.2. Rationale + + The following rationale has been adopted for this document: + + (1) Simplified solution migration paths: Define unified CPE + behavior, allowing for smooth migration between the different + S46 mechanisms. + + (2) Deterministic CPE coexistence behavior: Specify the behavior + when several S46 mechanisms coexist in the CPE. + + + + +Boucadair & Farrer Standards Track [Page 4] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + + (3) Deterministic service provider coexistence behavior: Specify the + behavior when several modes coexist in the service providers + network. + + (4) Reusability: Maximize the reuse of existing functional blocks + including tunnel endpoints, the port-restricted Network Address + Port Translator IPv4/IPv4 (NAPT44), forwarding behavior, etc. + + (5) Solution agnostic: Adopt neutral terminology and avoid (as far + as possible) overloading the document with solution-specific + terms. + + (6) Flexibility: Allow operators to compile CPE software only for + the mode(s) necessary for their chosen deployment context(s). + + (7) Simplicity: Provide a model that allows operators to only + implement the specific mode(s) that they require without the + additional complexity of unneeded modes. + +1.3. DHCPv6 S46 Priority Option + + The S46 Priority Option is used to convey a priority order of IPv4 + service continuity mechanisms. Figure 1 shows the format of the S46 + Priority 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_S46_PRIORITY | option-length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | s46-option-code | s46-option-code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | s46-option-code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: S46 Priority Option + + o option-code: OPTION_S46_PRIORITY (111) + + o option-length: >=2 and a multiple of 2, in octets. + + o s46-option-code: 16-bit IANA-registered option code of the DHCPv6 + option that is used to identify the softwire mechanism. S46 + mechanisms are prioritized in the appearance order in the S46 + Priority Option. + + + + + + +Boucadair & Farrer Standards Track [Page 5] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + + Codes in OPTION_S46_PRIORITY are processed in order; if a client + receives more than one s46-option-code with a particular value, it + should consider this case to be invalid. DHCP servers MAY validate + the list of s46-option-code values to detect invalid values and + duplicates. The option MUST contain at least one s46-option-code. + +1.4. DHCPv6 Client Behavior + + Clients MAY request the OPTION_S46_PRIORITY option, as defined in + [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. + As a convenience to the reader, we mention here that the client + includes requested option codes in the Option Request Option. + + Upon receipt of a DHCPv6 Advertise message from the server containing + OPTION_S46_PRIORITY, the client performs the following steps: + + 1. Check the contents of the DHCPv6 message for options containing + valid S46 mechanism configuration. A candidate list of possible + S46 mechanisms is created from these option codes. + + 2. Check the contents of OPTION_S46_PRIORITY for the DHCPv6 option + codes contained in the included s46-option-code fields. From + this, an S46 mechanism priority list is created, ordered from + highest to lowest following the appearance order. + + 3. Sequentially check the priority list against the candidate list + until a match is found. + + 4. When a match is found, the client MUST configure the resulting + S46 mechanism. + + In the event that no match is found between the priority list and the + candidate list, the client MAY proceed with configuring one or more + of the provisioned S46 softwire mechanism(s). In this case, which + mechanism(s) are chosen by the client is implementation specific and + not defined here. + + If an invalid OPTION_S46_PRIORITY option is received, the client MAY + proceed with configuring the provisioned S46 mechanisms as if + OPTION_S46_PRIORITY had not been received. + + If an unknown option code is received in the OPTION_S46_PRIORITY + option, the client MUST skip it and continue processing other listed + option codes if they exist. The initial option codes that are + allowed to be included in an OPTION_S46_PRIORITY option are listed in + Section 4.1. + + + + + +Boucadair & Farrer Standards Track [Page 6] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + +1.5. DHCPv6 Server Behavior + + Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in + regard to option assignment. As a convenience to the reader, we + mention here that the server will send a particular option code only + if configured with specific values for that option code and if the + client requested it. + + Option OPTION_S46_PRIORITY is a singleton. Servers MUST NOT send + more than one instance of the OPTION_S46_PRIORITY option. + +2. Operator Deployment Considerations for Deploying Multiple Softwire + Mechanisms + + The following subsections describe some considerations for operators + who are planning on implementing multiple softwire mechanisms in + their network (e.g., during a migration between mechanisms). + +2.1. Client Address Planning + + As an operator's available IPv4 resources are likely to be limited, + it may be desirable to use a common range of IPv4 addresses across + all of the active softwire mechanisms. However, this is likely to + result in difficulties in routing ingress IPv4 traffic to the correct + Border Relay (BR) / AFTR instance, which is actively serving a given + CE. For example, a client that is configured to use MAP-E may send + its traffic to the MAP-E BR; however, on the return path, the ingress + IP traffic gets routed to a MAP-T BR. The resulting translated + packet that gets forwarded to the MAP-E client will be dropped. + + Therefore, operators are advised to use separate IPv4 pools for each + of the different mechanisms to simplify planning and IPv4 routing. + + For IPv6 planning, there is less of a constraint as the BR/AFTR + elements for the different mechanisms can contain configuration for + overlapping the client's IPv6 addresses, provided that one mechanism + is actively serving a given client at a time. However, the IPv6 + address that is used as the tunnel concentrator's endpoint (BR/AFTR + address) needs to be different for each mechanism to ensure correct + operation. + +2.2. Backwards Compatability with Existing Softwire Clients + + Deployed clients that can support multiple softwire mechanisms, but + do not implement the prioritization mechanism described here may + require additional planning. In this scenario, the CPE would request + configuration for all of the supported softwire mechanisms in its + DHCPv6 Option Request Option (ORO), but would not request + + + +Boucadair & Farrer Standards Track [Page 7] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + + OPTION_S46_PRIORITY. By default, the DHCPv6 server will respond with + configuration for all of the requested mechanisms, which could result + in unpredictable and unwanted client configuration. + + In this scenario, it may be necessary for the operator to implement + logic within the DHCPv6 server to identify such clients and only + provision them with configuration for a single softwire mechanism. + It should be noted that this can lead to complexity and reduced + scalability in the DHCPv6 server implementation due to the additional + DHCPv6 message processing overhead. + +3. Security Considerations + + Security considerations discussed in [RFC6334] and [RFC7598] apply + for this document. + + Misbehaving intermediate nodes may alter the content of the S46 + Priority Option. This may lead to setting a different IPv4 service + continuity mechanism than the one initially preferred by the network + side. Also, a misbehaving node may alter the content of the S46 + Priority Option and other DHCPv6 options (e.g., DHCPv6 Option 64 or + 90) so that the traffic is intercepted by an illegitimate node. + Those attacks are not unique to the S46 Priority Option but are + applicable to any DHCPv6 option that can be altered by a misbehaving + intermediate node. + +4. IANA Considerations + + IANA has allocated the following DHCPv6 option code: + + 111 OPTION_S46_PRIORITY + + All values should be added to the DHCPv6 option code space defined in + Section 24.3 of [RFC3315]. + +4.1. S46 Mechanisms and Their Identifying Option Codes + + IANA has created a new registry titled "Option Codes permitted in the + S46 Priority Option". This registry enumerates the set of DHCPv6 + option codes that can be included in the OPTION_S46_PRIORITY option. + Options may be added to this list using the IETF Review process + described in Section 4.1 of [RFC5226]. + + The following table shows the option codes that are currently defined + and the S46 mechanisms that they represent. The contents of this + table shows the format and the initial values for the new registry. + Option codes that have not been requested to be added according to + the stated procedure should not be mentioned at all in the table, and + + + +Boucadair & Farrer Standards Track [Page 8] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + + they should not be listed as "reserved" or "unassigned". The valid + range of values for the registry is the range of DHCPv6 option codes + (1-65535). + + +-------------+--------------------+-----------+ + | Option Code | S46 Mechanism | Reference | + +-------------+--------------------+-----------+ + | 64 | DS-Lite | [RFC6334] | + | 88 | DHCPv4 over DHCPv6 | [RFC7341] | + | 94 | MAP-E | [RFC7598] | + | 95 | MAP-T | [RFC7598] | + | 96 | Lightweight 4over6 | [RFC7598] | + +-------------+--------------------+-----------+ + + Table 1: DHCPv6 Option to S46 Mechanism Mappings + +5. References + +5.1. 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>. + + [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", + RFC 6334, DOI 10.17487/RFC6334, August 2011, + <http://www.rfc-editor.org/info/rfc6334>. + + [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. + Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", + RFC 7341, DOI 10.17487/RFC7341, August 2014, + <http://www.rfc-editor.org/info/rfc7341>. + + [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, + W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for + Configuration of Softwire Address and Port-Mapped + Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, + <http://www.rfc-editor.org/info/rfc7598>. + + + + + + +Boucadair & Farrer Standards Track [Page 9] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + +5.2. Informative References + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- + Stack Lite Broadband Deployments Following IPv4 + Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, + <http://www.rfc-editor.org/info/rfc6333>. + + [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. + Farrer, "Lightweight 4over6: An Extension to the Dual- + Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, + July 2015, <http://www.rfc-editor.org/info/rfc7596>. + + [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., + Murakami, T., and T. Taylor, Ed., "Mapping of Address and + Port with Encapsulation (MAP-E)", RFC 7597, + DOI 10.17487/RFC7597, July 2015, + <http://www.rfc-editor.org/info/rfc7597>. + + [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., + and T. Murakami, "Mapping of Address and Port using + Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July + 2015, <http://www.rfc-editor.org/info/rfc7599>. + + + + + + + + + + + + + + + + + + + + + + + + +Boucadair & Farrer Standards Track [Page 10] + +RFC 8026 OPTION_S46_PRIORITY DHCPv6 Option November 2016 + + +Acknowledgements + + Many thanks to O. Troan, S. Barth, A. Yourtchenko, B. Volz, T. + Mrugalski, J. Scudder, P. Kyzivat, F. Baker, and B. Campbell for + their input and suggestions. + +Authors' Addresses + + Mohamed Boucadair + Orange + Rennes + France + + Email: mohamed.boucadair@orange.com + + + Ian Farrer + Deutsche Telekom AG + CTO-ATI, Landgrabenweg 151 + Bonn, NRW 53227 + Germany + + Email: ian.farrer@telekom.de + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Boucadair & Farrer Standards Track [Page 11] + |