RFC 8026
Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism
RFC 8026: Unified IPv4-in-IPv6 Softwire CPE: A DHCPv6-Based Prioritization Mechanism ✨
🎀 Okay bestie, this one is by M. Boucadair (Orange) and I. Farrer (Deutsche Telekom AG). It came out in November 2016 as a Standards Track document from the IETF, and it's numbered RFC 8026 with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Abstract
🦋 So in IPv6-only provider networks, sending IPv4 packets wrapped up inside IPv6 is a super common way to keep IPv4 service working. There are a bunch of different ways to do this, and each one has its own vibe. These approaches all share a similar architecture and use the same data plane stuff, so this memo defines a DHCPv6 option. With it, one single CPE can work with all the standardized and proposed ways of delivering encapsulated IPv4-in-IPv6 services, using a prioritization mechanism to decide which one to pick 🧚
Status of This Memo
🌸 This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc8026. 🍓
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) as they stood on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes. 🫶
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 . . . . . . . . . . . . . . . . . . . . . . . 111. Introduction ✨
IPv4 service continuity is one of the biggest technical challenges you have to handle during the IPv6 migration. Over the last few years, people have come up with a bunch of different approaches to help with this (see [RFC6333], [RFC7596], and [RFC7597], for example). This document calls these approaches "S46 mechanisms." They exist to meet the specific deployment, scaling, addressing, and other needs of different service providers' networks. 🦋
A feature that all these different modes share is that the softwire tunnel endpoint functionality lives inside the Customer Premises Equipment (CPE) router. Because the data plane is so similar, one CPE may be able to support several of these approaches. Users might also want to set a specific mode of operation 💖
A service provider's network may also have more than one S46 mechanism turned on, so it can support a mixed CPE population with different client functionality. This happens, for instance, during a migration between mechanisms, or when services need specific supporting softwire architectures 🔥
For softwire-based services to get established successfully, it's essential that the customer's end node, the service provider's end node, and the provisioning systems can indicate their capabilities and preferred mode of operation 👑
A few DHCPv6 options for provisioning softwires have been standardized already:
- 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 a softwire client can then use to get 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.
This document describes a DHCPv6-based prioritization method. A CPE that supports several S46 mechanisms and gets configured for more than one of them can use it to prioritize which mechanism to use. The method needs no server-side logic, and it only requires a simple S46 mechanism prioritization to be implemented in the CPE 🌈
Heads up, though: this prioritization method doesn't give the client redundancy between S46 mechanisms. So if the highest priority S46 mechanism provisioned to the client is unavailable for any reason, the way to spot that and fall back to the next highest priority mechanism is outside the scope of this document 🙈
1.1. Terminology
This document uses the following terms:
- 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].
- 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].
- Customer Premises Equipment (CPE): 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
Here's the rationale behind this document, in seven parts 🎀
- Simplified solution migration paths: Define unified CPE behavior, allowing for smooth migration between the different S46 mechanisms.
- Deterministic CPE coexistence behavior: Specify the behavior when several S46 mechanisms coexist in the CPE.
- Deterministic service provider coexistence behavior: Specify the behavior when several modes coexist in the service provider's network.
- Reusability: Maximize the reuse of existing functional blocks, including tunnel endpoints, the port-restricted Network Address Port Translator IPv4/IPv4 (NAPT44), forwarding behavior, etc.
- Solution agnostic: Adopt neutral terminology and avoid (as far as possible) overloading the document with solution-specific terms.
- Flexibility: Allow operators to compile CPE software only for the mode(s) necessary for their chosen deployment context(s).
- Simplicity: Provide a model that lets operators implement only the specific mode(s) they need, without the extra complexity of unneeded modes.
1.3. DHCPv6 S46 Priority Option
🌸 The S46 Priority Option conveys a priority order of IPv4 service continuity mechanisms. Here's what its format looks like:
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 OptionThe fields work like this:
- option-code: OPTION_S46_PRIORITY (111)
- option-length: >=2 and a multiple of 2, in octets.
- s46-option-code: 16-bit IANA-registered option code of the DHCPv6 option that identifies the softwire mechanism. S46 mechanisms are prioritized in the order they appear in the S46 Priority Option.
🔥 The codes in OPTION_S46_PRIORITY get 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 catch invalid values and duplicates. The option MUST contain at least one s46-option-code. 💅
To be continued 🌈👀
1.4. DHCPv6 Client Behavior ✨
Clients MAY ask for the OPTION_S46_PRIORITY option, which is defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. Just so you know, the client lists the option codes it wants in the Option Request Option. 💖
When a DHCPv6 Advertise message from the server shows up with OPTION_S46_PRIORITY in it, the client runs through this checklist:
- It checks the DHCPv6 message for options with valid S46 mechanism configuration. Any it finds go onto a candidate list of possible S46 mechanisms. 🔍
- It checks the OPTION_S46_PRIORITY contents for the DHCPv6 option codes in the included
s46-option-codefields. From those it builds an S46 mechanism priority list, ordered from highest to lowest based on the order they appear in. 📋 - It works through the priority list, checking each entry against the candidate list, until it finds a match. 🎯
- Once it finds a match, the client MUST configure the resulting S46 mechanism. No skipping this one, bestie! 🔥
If nothing on the priority list matches anything on the candidate list, the client MAY go ahead and configure one or more of the provisioned S46 softwire mechanism(s). Which one(s) it picks is implementation specific and not defined here, so that's totally up to the implementer. 🦋
If an invalid OPTION_S46_PRIORITY option comes in, the client MAY go ahead and configure the provisioned S46 mechanisms as if OPTION_S46_PRIORITY had never arrived. 🌸
If an unknown option code shows up inside OPTION_S46_PRIORITY, the client MUST skip it and keep going through any other listed option codes. The starting list of option codes that are allowed in an OPTION_S46_PRIORITY option is in Section 4.1. 🧚
1.5. DHCPv6 Server Behavior 👑
Sections 17.2.2 and 18.2 of [RFC3315] are the rules for how the server handles option assignment. Quick heads up: the server will only send a particular option code if it's been configured with specific values for that code AND the client asked for it. 💅
OPTION_S46_PRIORITY is a singleton, meaning it's a one-of-a-kind option. Servers MUST NOT send more than one instance of the OPTION_S46_PRIORITY option. Never more than one, periodt! 🙈
2. Operator Deployment Considerations for Deploying Multiple Softwire Mechanisms 🌈
Okay, this next part is for operators who are planning to run multiple softwire mechanisms in their network, like during a migration from one mechanism to another. Here's what to think about. 🧠
2.1. Client Address Planning 🏡
Operators usually don't have a ton of IPv4 resources, so it might be tempting to use one common range of IPv4 addresses across all the active softwire mechanisms. Lowkey understandable, but it's likely to cause trouble routing ingress IPv4 traffic to the correct Border Relay (BR) / AFTR instance that's actively serving a given CE. For example, a client set up to use MAP-E might send its traffic to the MAP-E BR, but on the way back the ingress IP traffic gets routed to a MAP-T BR instead. The translated packet that gets forwarded to the MAP-E client then gets dropped. 😭
So, operators are advised to use separate IPv4 pools for each of the different mechanisms. It makes planning and IPv4 routing way simpler. 🫶
For IPv6 planning, there's less of a constraint. The BR/AFTR elements for the different mechanisms can hold configuration that overlaps the client's IPv6 addresses, as long as only one mechanism is actively serving a given client at a time. The IPv6 address used as the tunnel concentrator's endpoint (the BR/AFTR address), however, needs to be different for each mechanism so everything works correctly. ✨
2.2. Backwards Compatability with Existing Softwire Clients 🎀
Some deployed clients can support multiple softwire mechanisms but don't implement the prioritization mechanism described here. These clients may need extra planning. In this case, the CPE would request configuration for all of the supported softwire mechanisms in its DHCPv6 Option Request Option (ORO), but it would not request OPTION_S46_PRIORITY. By default, the DHCPv6 server will respond with configuration for all of the requested mechanisms, which could lead to unpredictable and unwanted client configuration. Yikes! 😬
In this scenario, the operator might need to add logic to the DHCPv6 server that spots these clients and only provisions them with configuration for a single softwire mechanism. It should be noted that this can add complexity and reduce scalability in the DHCPv6 server implementation, because of the extra DHCPv6 message processing overhead. 🌸
3. Security Considerations 🚨
Security considerations discussed in [RFC6334] and [RFC7598] apply to this document. Read those too, bestie. 📚
Misbehaving intermediate nodes may alter the content of the S46 Priority Option. That can lead to a different IPv4 service continuity mechanism being set up than the one the network side originally preferred. 😱
Also, a misbehaving node may alter the content of the S46 Priority Option and other DHCPv6 options (for example, DHCPv6 Option 64 or 90) so that traffic gets intercepted by an illegitimate node. Those attacks aren't unique to the S46 Priority Option. They apply to any DHCPv6 option that a misbehaving intermediate node can alter. This is a whole vibe-killer, so please take it seriously. 💀
4. IANA Considerations 🌷
IANA has allocated the following DHCPv6 option code:
111 OPTION_S46_PRIORITYAll 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 called "Option Codes permitted in the S46 Priority Option". This registry lists 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 table below shows the option codes that are currently defined and the S46 mechanisms they represent. It shows the format and the initial values for the new registry. Option codes that haven't been requested to be added through the stated procedure should not be mentioned at all in the table, and 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>.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>.Acknowledgements 🫶
Huge 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. You all are literally the best. 👑
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📦 where this page comes from
- ietf: rfc8026 2016-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms