RFC 8658
RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)
Abstract ✨
okay so IPv4-over-IPv6 transition mechanisms give you IPv4 connectivity on IPv6 native networks while IPv4 and IPv6 are both hanging out together (the coexistence period) 🦋. DHCPv6 options already exist to configure clients for Lightweight 4over6, MAP-E, MAP-T unicast softwires, and multicast softwires 💅. BUT in lots of networks the config lives in an Authentication, Authorization, and Accounting (AAA) server, which uses the Remote Authentication Dial In User Service (RADIUS) protocol for centralized user management 🎀. So whenever a new transition mechanism drops, new RADIUS attributes have to be defined to match 😭.
This document defines new RADIUS attributes that carry Address plus Port based softwire configuration parameters from a AAA server to a Broadband Network Gateway 🌸. Both unicast and multicast attributes are covered ✨.
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 got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑. For more on Internet Standards, check Section 2 of RFC 7841 🧚.
For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8658 💜.
Copyright Notice
Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these documents carefully, because they spell out your rights and restrictions for this document 📜. Code Components extracted from this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🙈.
Table of Contents
1. Introduction
2. Terminology
3. New RADIUS Attributes
3.1. Softwire46-Configuration Attribute
3.1.1. Softwire46 Attributes
3.1.1.1. Softwire46-MAP-E Attribute
3.1.1.2. Softwire46-MAP-T Attribute
3.1.1.3. Softwire46-Lightweight-4over6 Attribute
3.1.2. Softwire46 Sub-attributes
3.1.3. Specification of the Softwire46 Sub-attributes
3.1.3.1. Softwire46-Rule Attribute
3.1.3.2. Softwire46-BR Attribute
3.1.3.3. Softwire46-DMR Attribute
3.1.3.4. Softwire46-V4V6Bind Attribute
3.1.3.5. Softwire46-PORTPARAMS Attribute
3.1.4. Sub-attributes for Softwire46-Rule
3.1.4.1. Rule-IPv6-Prefix Attribute
3.1.4.2. Rule-IPv4-Prefix Attribute
3.1.4.3. EA-Length Attribute
3.1.5. Attributes for Softwire46-v4v6Bind
3.1.5.1. IPv4-Address Attribute
3.1.5.2. Bind-IPv6-Prefix Attribute
3.1.6. Attributes for Softwire46-PORTPARAMS
3.1.6.1. PSID-Offset Attribute
3.1.6.2. PSID-Len Attribute
3.1.6.3. PSID Attribute
3.2. Softwire46-Priority Attribute
3.2.1. Softwire46-Option-Code
3.3. Softwire46-Multicast Attribute
3.3.1. ASM-Prefix64 Attribute
3.3.2. SSM-Prefix64 Attribute
3.3.3. U-Prefix64 Attribute
4. A Sample Configuration Process with RADIUS
5. Table of Attributes
6. Security Considerations
7. IANA Considerations
7.1. New RADIUS Attributes
7.2. RADIUS Softwire46 Configuration and Multicast
Attributes
7.3. Softwire46 Mechanisms and Their Identifying Option
Codes
8. References
8.1. Normative References
8.2. Informative References
Appendix A. DHCPv6 to RADIUS Field Mappings
A.1. OPTION_S46_RULE (89) to Softwire46-Rule Sub-TLV Field
Mappings
A.2. OPTION_S46_BR (90) to Softwire46-BR Field Mappings
A.3. OPTION_S46_DMR (91) to Softwire46-DMR
A.4. OPTION_S46_V4V6BIND (92) to Softwire46-V4V6Bind
A.5. OPTION_S46_PORTPARAMS (93) to Softwire46-PORTPARAMS
Field Mappings
A.6. OPTION_S46_PRIORITY (111) to Softwire46-PORTPARAMS
Field Mappings
A.7. OPTION_V6_PREFIX64 (113) to Softwire46-Multicast
Attribute Field Mappings
Acknowledgements
Contributors
Authors' Addresses1. Introduction ✨
Providers have started deploying and moving over to IPv6 🚀. A few IPv4 service continuity mechanisms based on Address plus Port (A+P) [RFC6346] have been proposed to give unicast IPv4 service over IPv6-only infrastructure. Those include Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], Mapping of Address and Port using Translation (MAP-T) [RFC7599], and Lightweight 4over6 [RFC7596] 💅. Then there's [RFC8114], which gives a generic solution for delivering IPv4 multicast services to IPv4 clients over an IPv6 multicast network 🦋. Each of these mechanisms has DHCPv6 options specified for client configuration 🎀.
In lots of networks, user configuration info lives in an Authentication, Authorization, and Accounting (AAA) server 🫶. AAA servers usually talk over the Remote Authentication Dial In User Service (RADIUS) [RFC2865] protocol 📡. In a fixed broadband network, a Broadband Network Gateway (BNG) is the access gateway for users. So the BNG acts as both a AAA client to the AAA server and a DHCPv6 server for DHCPv6 messages sent by clients 💖. Throughout this document, "BNG" means a device that does both the AAA client and DHCPv6 server jobs 🧚.
Here's the tea 🍓: IPv4-in-IPv6 softwire configuration info is stored in a AAA server, but user config info mostly gets sent through DHCPv6 between the BNGs and Customer Premises Equipment (CEs, a.k.a., CPE) 💜. That means new RADIUS attributes are needed to pass the info from the AAA servers to BNGs, so the BNGs can hand it to CEs using the DHCPv6 options that already exist ✨.
The RADIUS attributes in this document carry the config that fills in the matching DHCPv6 options for unicast and multicast softwire configurations. Specifically:
- "Mapping of Address and Port with Encapsulation (MAP-E)" [RFC7597] (DHCPv6 options defined in [RFC7598]).
- "Mapping of Address and Port using Translation (MAP-T)" [RFC7599] (DHCPv6 options defined in [RFC7598]).
- "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture" [RFC7596] (DHCPv6 options defined in [RFC7598]).
- "Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism" [RFC8026].
- "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network" [RFC8114] (DHCPv6 options defined in [RFC8115]).
The attributes in this document map 1:1 onto the fields of the DHCPv6 options in [RFC7598], [RFC8026], and [RFC8115] 🌈. Table 1 shows which RADIUS attribute each DHCPv6 option maps to. For the detailed field-by-field mappings, see Appendix A 🔥.
+----------------------------+-----------------------+
| DHCPv6 Option | RADIUS Attribute |
+============================+=======================+
| OPTION_S46_RULE (89) | Softwire46-Rule |
+----------------------------+-----------------------+
| OPTION_S46_BR (90) | Softwire46-BR |
+----------------------------+-----------------------+
| OPTION_S46_DMR (91) | Softwire46-DMR |
+----------------------------+-----------------------+
| OPTION_S46_V4V6BIND (92) | Softwire46-V4V6Bind |
+----------------------------+-----------------------+
| OPTION_S46_PORTPARAMS (93) | Softwire46-PORTPARAMS |
+----------------------------+-----------------------+
| OPTION_S46_PRIORITY (111) | Softwire46-Priority |
+----------------------------+-----------------------+
| OPTION_V6_PREFIX64 (113) | Softwire46-Multicast |
+----------------------------+-----------------------+
Table 1: Mapping between DHCPv6 Options and
RADIUS AttributesA RADIUS attribute for Dual-Stack Lite [RFC6333] is defined in [RFC6519] 🦋.
This document targets deployments where a trusted relationship is in place between the RADIUS client and server 🔒.
2. Terminology 💅
The BCP 14 key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". They get read as described in BCP 14 [RFC2119] [RFC8174], but only when, and only if, they show up in all capitals, like I'm showing here 🎀.
You'll want to know the concepts and terms defined in [RFC7596], [RFC7597], [RFC7599], and [RFC8026] 📚.
The terms "multicast Basic Bridging BroadBand" element (mB4) and "multicast Address Family Transition Router" element (mAFTR) are defined in [RFC8114] 🧚.
Softwire46 (S46) is used all through the doc to mean any of the IPv4-in-IPv6 softwire mechanisms listed above 🌸. The doc also uses these abbreviations:
BNG: Broadband Network Gateway
BR: Border Relay
CE: Customer Edge
CoA: Change-of-Authorization
DMR: Default Mapping Rule
EA: Embedded Address
lwAFTR: Lightweight Address Family Transition Router
MAP-E: Mapping of Address and Port with Encapsulation
MAP-T: Mapping of Address and Port using Translation
PSID: Port Set Identifier
TLV: Type, Length, Value3. New RADIUS Attributes ✨
okay bestie, this section is where we get to define the new RADIUS attributes 🎀 there are three of them, and they're all about getting the Softwire46 config to the right place 💅
- Softwire46-Configuration Attribute (Section 3.1): this one carries the config info for MAP-E, MAP-T, and Lightweight 4over6 🦋 each Softwire46 mechanism gets its own config inside the matching Softwire46 attributes, and different mechanisms need different attributes
- Softwire46-Priority Attribute (Section 3.2): so a client can support a bunch of Softwire46 mechanisms depending on the deployment, which means it can ask for config for more than one at a time 🌈 this attribute tells the client which mechanism to prioritize, and it lines up with OPTION_S46_PRIORITY from [RFC8026] 👑
- Softwire46-Multicast Attribute (Section 3.3): this one passes along the IPv6 prefixes used by [RFC8114] to make IPv4-embedded IPv6 addresses 🧚 the BNG takes those prefixes from the RADIUS Softwire46-Multicast Attribute and uses them to fill in the DHCPv6 PREFIX64 Option from [RFC8115] ✨
All of these attributes come from the RADIUS "Extended Type" code space, following [RFC6929] 🌸 their designs also follow [RFC6158] and [RFC6929], and the way they're defined follows the guidance in [RFC8044] 💖
3.1. Softwire46-Configuration Attribute
This one is a "tlv" type, as defined in "Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions" [RFC6929] 🎀 it holds some sub-attributes, and there are a few rules for it:
- The Softwire46-Configuration Attribute MUST contain one or more of the following attributes: Softwire46-MAP-E, Softwire46-MAP-T, and/or Softwire46-Lightweight-4over6 💅
- The Softwire46-Configuration Attribute carries the config info for MAP-E, MAP-T, or Lightweight 4over6 🦋 the BNG SHALL use that info from the RADIUS attribute to fill in the DHCPv6 Softwire46 container option(s) defined in Section 5 of [RFC7598] ✨
- The Softwire46-Configuration Attribute MAY appear in an Access-Accept packet 🌈 it also MAY show up in an Access-Request packet to say which Softwire46 config it prefers, but the server doesn't have to honor that preference 🙈
- The Softwire46-Configuration Attribute MAY appear in a CoA-Request packet 💜
- The Softwire46-Configuration Attribute MAY appear in an Accounting-Request packet 🍓
- The Softwire46-Configuration Attribute MUST NOT appear in any other RADIUS packet 💀
So the attribute's structure looks like this, bestie 👑
Type:241Length: the total length in bytes of all the fields in this attribute, including the Type, Length, Extended-Type, and the whole length of the embedded attributes 📏Extended-Type:9Value: holds one or more of the following attributes, and each attribute type can show up once at most 🫶- Softwire46-MAP-E: for configuring MAP-E clients. Check Section 3.1.1.1 for how to build it 🦋
- Softwire46-MAP-T: for configuring MAP-T clients. Check Section 3.1.1.2 for how to build it 🌸
- Softwire46-Lightweight-4over6: for configuring Lightweight 4over6 clients. Check Section 3.1.1.3 for how to build it ✨
The Softwire46-Configuration Attribute is associated with the identifier 241.9 🔥
3.1.1. Softwire46 Attributes
The Softwire46 attributes can only be encapsulated in the Softwire46-Configuration Attribute 💅 depending on the deployment, a client might ask for more than one transition mechanism at a time 🌈 there MUST be at least one Softwire46 attribute encapsulated in one Softwire46-Configuration Attribute 😭 and there MUST be at most one instance of each type of Softwire46 attribute encapsulated in one Softwire46-Configuration Attribute 🎀
There are three types of Softwire46 attributes:
- Softwire46-MAP-E (Section 3.1.1.1)
- Softwire46-MAP-T (Section 3.1.1.2)
- Softwire46-Lightweight 4over6 (Section 3.1.1.3)
Each type has a bunch of sub-attributes, which are defined in Section 3.1.3 🧚 the hierarchy of the Softwire46 attributes is in Figure 1, and Section 3.1.2 tells you which sub-attributes are mandatory, optional, or not permitted for each one 💖
/1.Rule-IPv6-Prefix
S / |
o / | 1.Softwire46-Rule --+ 2.Rule-IPv4-Prefix
f | Softwire46-MAP-E--+ |
t | | 2.Softwire46-BR | 3.EA-Length
w | | \
i | | /1.PSID-Offset
r | | |
e | | 3.Softwire46-PORTPARAMS -----+ 2.PSID-Len
4 | \ |
6 | | 3.PSID
- | \
C |
o | /1.Rule-IPv6-Prefix
n | / |
f | | 1.Softwire46-Rule---+ 2.Rule-IPv4-Prefix
i | Softwire46-MAP-T--+ |
g | | 2.Softwire46-DMR | 3.EA-Length
u | | \
r | | /1.PSID-Offset
a | | |
t | | 3.Softwire46-PORTPARAMS------+ 2.PSID-Len
i | \ |
o | | 3.PSID
n | \
|
A | /1.IPv4-Address
t | / |
t | | 1.Softwire46-V4V6Bind --+ 2.Bind-IPv6-Prefix
r | Softwire46- | \
i | Lightweight-4over6+ 2.Softwire46-BR /1.PSID-Offset
b \ | |
u | 3.Softwire46-PORTPARAMS ----+ 2.PSID-Len
t \ |
e | 3.PSID
\
Figure 1: Softwire46 Attribute Hierarchy3.1.1.1. Softwire46-MAP-E Attribute
This attribute carries the config info for MAP-E 🦋 its structure is shown below:
TLV-Type:1TLV-Length: the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields 📏TLV-Value: holds a set of sub-attributes, with these rules 🫶- It MUST contain Softwire46-Rule, defined in Section 3.1.3.1.
- It MUST contain Softwire46-BR, defined in Section 3.1.3.2.
- It MAY contain Softwire46-PORTPARAMS, defined in Section 3.1.3.5.
3.1.1.2. Softwire46-MAP-T Attribute
This attribute carries the config info for MAP-T 🌸 its structure is shown below:
TLV-Type:2TLV-Length: the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields 📏TLV-Value: holds a set of sub-attributes, with these rules 🫶- It MUST contain Softwire46-Rule, defined in Section 3.1.3.1.
- It MUST contain Softwire46-DMR, defined in Section 3.1.3.3.
- It MAY contain Softwire46-PORTPARAMS, defined in Section 3.1.3.5.
3.1.1.3. Softwire46-Lightweight-4over6 Attribute
This attribute carries the config info for Lightweight 4over6 ✨ its structure is shown below:
TLV-Type:3TLV-Length: the length of this attribute, including the TLV-Type, TLV-Length, and TLV-Value fields 📏TLV-Value: holds a set of sub-attributes as follows 🫶- It MUST contain Softwire46-BR, defined in Section 3.1.3.2.
- It MUST contain Softwire46-V4V6Bind, defined in Section 3.1.3.4.
- It MAY contain Softwire46-PORTPARAMS, defined in Section 3.1.3.5.
3.1.2. Softwire46 Sub-attributes
Table 2 shows which encapsulated sub-attributes are mandatory, optional, or not permitted for each Softwire46 attribute 💅
+-----------------------+-------+-------+--------------------+
| Sub-attributes | MAP-E | MAP-T | Lightweight 4over6 |
+=======================+=======+=======+====================+
| Softwire46-BR | 1+ | 0 | 1+ |
+-----------------------+-------+-------+--------------------+
| Softwire46-Rule | 1 | 1 | 0 |
+-----------------------+-------+-------+--------------------+
| Softwire46-DMR | 0 | 1 | 0 |
+-----------------------+-------+-------+--------------------+
| Softwire46-V4V6Bind | 0 | 0 | 1 |
+-----------------------+-------+-------+--------------------+
| Softwire46-PORTPARAMS | 0-1 | 0-1 | 0-1 |
+-----------------------+-------+-------+--------------------+
Table 2: Softwire46 Sub-attributesThe list below explains what the Table 2 entries mean 🧚
0: Not permitted0-1: Optional; zero or one instance of the attribute may be present.1: Mandatory; only one instance of the attribute must be present.1+: Mandatory; one or more instances of the attribute may be present.
3.1.3. Specification of the Softwire46 Sub-attributes
3.1.3.1. Softwire46-Rule Attribute ✨
okay so Softwire46-Rule can ONLY be tucked inside Softwire46-MAP-E (Section 3.1.1.1) or Softwire46-MAP-T (Section 3.1.1.2) 💅. Depending on the deployment scenario, one Basic Mapping Rule (BMR) and zero or more Forwarding Mapping Rules (FMRs) MUST be included in Softwire46-MAP-E and Softwire46-MAP-T 🎀.
Each type of Softwire46-Rule has its own little crew of sub-attributes, like Rule-IPv6-Prefix, Rule-IPv4-Prefix, and EA-Length 🌸. The layout for those lives in Section 3.1.4.
Having multiple TLV types gets you the same vibe as the "Softwire46 Rule Flags" from Section 4.1 of [RFC7598] 🦋. Using TLV type 5 is the same as setting the F flag in the OPTION_S46_RULE S46 Rule Flags field ✨.
TLV-Type- 4 Basic Mapping Rule only (not to be used for forwarding)
- 5 Forwarding Permitted Mapping Rule
TLV-Length: Indicates the length of this attribute, including theTLV-Type,TLV-Length, andTLV-Valuefields.Data Type: The attribute Softwire46-Rule is of type "tlv" (Section 3.13 of [RFC8044]).TLV-Value: This field contains a set of attributes as follows:- Rule-IPv6-Prefix: This attribute contains the IPv6 prefix for use in the MAP rule. Refer to Section 3.1.4.1.
- Rule-IPv4-Prefix: This attribute contains the IPv4 prefix for use in the MAP rule. Refer to Section 3.1.4.2.
- EA-Length: This attribute contains the Embedded Address (EA) bit length. Refer to Section 3.1.4.3.
3.1.3.2. Softwire46-BR Attribute 🧚
Softwire46-BR can only be encapsulated in Softwire46-MAP-E (Section 3.1.1.1) or Softwire46-Lightweight-4over6 (Section 3.1.1.3) 💜.
There MUST be at least one Softwire46-BR included in each Softwire46-MAP-E or Softwire46-Lightweight-4over6 🔥.
Here's how the Softwire46-BR is shaped 👑:
TLV-Type: 6TLV-Length: 18 octetsData Type: The attribute Softwire46-BR is of type "ipv6addr" (Section 3.9 of [RFC8044]).TLV-Value: br-ipv6-address. A fixed-length field of 16 octets that specifies the IPv6 address for the Softwire46 Border Relay (BR).
3.1.3.3. Softwire46-DMR Attribute 🍓
Softwire46-DMR may only appear in Softwire46-MAP-T (Section 3.1.1.2) 🦋. There MUST be exactly one Softwire46-DMR included in one Softwire46- MAP-T ✨.
The structure of Softwire46-DMR goes like this 💅:
TLV-Type: 7TLV-Length: 4 + length of dmr-ipv6-prefix specified in octets.Data Type: The attribute Softwire46-DMR is of type "ipv6prefix" (Section 3.10 of [RFC8044]).TLV-Value: A variable-length (dmr-prefix6-len) field specifying the IPv6 prefix (dmr-ipv6-prefix) for the BR. This field is right-padded with zeros to the nearest octet boundary when dmr-prefix6-len is not divisible by 8. Prefixes with lengths from 0 to 96 are allowed 🌈.
3.1.3.4. Softwire46-V4V6Bind Attribute 🌸
Softwire46-V4V6Bind may only be encapsulated in Softwire46-Lightweight-4over6 (Section 3.1.1.3) 🫶. There MUST be exactly one Softwire46-V4V6Bind included in each Softwire46-Lightweight-4over6 💖.
The shape of Softwire46-V4V6Bind:
TLV-Type: 8TLV-Length: Indicates the length of this attribute, including theTLV-Type,TLV-Length, andTLV-Valuefields.Data Type: The attribute Softwire46-V4V6Bind is of type "tlv" (Section 3.13 of [RFC8044]).TLV-Value: This field contains a set of attributes as follows:- IPv4-Address: This attribute contains an IPv4 address, used to specify the full or shared IPv4 address of the CE. Refer to Section 3.1.5.1.
- Bind-IPv6-Prefix: This attribute contains an IPv6 prefix used to indicate which configured prefix the Softwire46 CE should use for constructing the softwire. Refer to Section 3.1.5.2.
3.1.3.5. Softwire46-PORTPARAMS Attribute 🎀
Softwire46-PORTPARAMS is optional ⭐. It's used to specify port set information for IPv4 address sharing between clients 🦋. Softwire46-PORTPARAMS MAY be included in any of the Softwire46 attributes ✨.
Here's the structure 🌈:
TLV-Type: 9TLV-Length: Indicates the length of this attribute, including theTLV-Type,TLV-Length, andTLV-Valuefields.Data Type: The attribute Softwire46-PORTPARAMS is of type "tlv" (Section 3.13 of [RFC8044]).TLV-Value: This field contains a set of attributes as follows:- PSID-Offset: This attribute specifies the numeric value for the Softwire46 algorithm's excluded port range/offset bits (a bits). Refer to Section 3.1.6.1.
- PSID-Len: This attribute specifies the number of significant bits in the PSID field (also known as 'k'). Refer to Section 3.1.6.2.
- PSID: This attribute specifies the PSID value. Refer to Section 3.1.6.3.
3.1.4. Sub-attributes for Softwire46-Rule 💜
There are two types of Softwire46-Rule: the Basic Mapping Rule and the Forwarding Mapping Rule 🌸. You can tell them apart by the value in the TLV-Type field of Softwire46-Rule (Section 3.1.3.1) 💅.
Each type of Softwire46-Rule also has a bunch of sub-attributes, detailed in the subsections below 🧚.
3.1.4.1. Rule-IPv6-Prefix Attribute 👑
Rule-IPv6-Prefix is REQUIRED for every Softwire46-Rule 🔥. There MUST be exactly one Rule-IPv6-Prefix encapsulated in each type of Softwire46-Rule 💖.
Rule-IPv6-Prefix follows the framed IPv6 prefix designed in [RFC3162] and [RFC8044] 🦋.
TLV-Type: 10TLV-Length: 4 + length of rule-ipv6-prefix specified in octets.Data Type: The attribute Rule-IPv6-Prefix is of type "ipv6prefix" (Section 3.10 of [RFC8044]).TLV-Value: A variable-length field that specifies an IPv6 prefix (rule-ipv6-prefix) appearing in the MAP rule.
3.1.4.2. Rule-IPv4-Prefix Attribute 🍓
This attribute conveys the MAP Rule IPv4 prefix 🫶. Here's the shape:
TLV-Type: 11TLV-Length: 4 + length of rule-ipv4-prefix specified in octets.Data Type: The attribute Rule-IPv4-Prefix is of type "ipv4prefix" (Section 3.11 of [RFC8044]).TLV-Value: A variable-length field that specifies an IPv4 prefix (rule-ipv4-prefix) appearing in the MAP rule.
3.1.4.3. EA-Length Attribute 🌈
This attribute conveys the Embedded Address (EA) bit length ✨. Here's the structure:
TLV-Type: 12TLV-Length: 6 octetsData Type: The attribute EA-Length is of type "integer" (Section 3.1 of [RFC8044]).TLV-Value: EA-len; 32 bits long. Specifies the Embedded Address (EA) bit length. Allowed values range from 0 to 48 💅.
3.1.5. Attributes for Softwire46-v4v6Bind 🦋
3.1.5.1. IPv4-Address Attribute 🎀
The IPv4-Address MAY be used to specify the full or shared IPv4 address of the CE 🌸.
TLV-Type: 13TLV-Length: 6 octetsData Type: The attribute IPv4-Address is of type "ipv4addr" (Section 3.8 of [RFC8044]).TLV-Value: 32 bits long. Specifies the IPv4 address (ipv4-address) to appear in Softwire46-V4V6Bind (Section 3.1.3.4).
3.1.5.2. Bind-IPv6-Prefix Attribute 🧚
The Bind-IPv6-Prefix is used by the CE to identify the correct IPv6 prefix to be used as the tunnel source 💖.
TLV-Type: 14TLV-Length: 4 + length of bind-ipv6-prefix specified in octets.Data Type: The attribute Bind-IPv6-Prefix is of type "ipv6prefix" (Section 3.10 of [RFC8044]).TLV-Value: A variable-length field specifying the IPv6 prefix or address for the Softwire46 CE (bind-ipv6-prefix). This field is right-padded with zeros to the nearest octet boundary when the prefix length is not divisible by 8 🫶.
3.1.6. Attributes for Softwire46-PORTPARAMS 🌈
3.1.6.1. PSID-Offset Attribute ✨
This attribute conveys the Port Set Identifier offset as defined in [RFC7597] 💅. It's encoded in 32 bits as per the recommendation in Appendix A.2.1 of [RFC6158] 👑.
TLV-Type: 15TLV-Length: 6 octetsData Type: The attribute PSID-Offset is of type "integer" (Section 3.1 of [RFC8044]).TLV-Value: Contains the PSID-Offset (8 bits) right justified, and the unused bits in this field MUST be set to zero. This field specifies the numeric value for the Softwire46 algorithm's excluded port range/offset bits (a bits), as per Section 5.1 of [RFC7597].
Default values for this field are specific to the softwire mechanism being implemented and are defined in the relevant specification document 🦋.
3.1.6.2. PSID-Len Attribute 🌸
This attribute conveys the PSID length as defined in [RFC7597] 🎀. It's encoded in 32 bits as per the recommendation in Appendix A.2.1 of [RFC6158] ✨.
TLV-Type: 16TLV-Length: 6 octetsData Type: The attribute PSID-Len is of type "integer" (Section 3.1 of [RFC8044]).TLV-Value: Contains the PSID-len (8 bits) right justified, and the unused bits in this field MUST be set to zero. This field specifies the number of significant bits in the PSID field (also known as 'k'). When set to 0, the PSID field is to be ignored. After the first a bits, there are k bits in the port number representing the value of the PSID. Subsequently, the address-sharing ratio would be2^k🔥.
3.1.6.3. PSID Attribute 🍓
This attribute conveys the PSID as defined in [RFC7597] 🧚. It's encoded in 32 bits as per the recommendation in Appendix A.2.1 of [RFC6158] 🫶.
TLV-Type: 17TLV-Length: 6 octetsData Type: The attribute PSID is of type "integer" (Section 3.1 of [RFC8044]).TLV-Value: Contains the PSID (16 bits) right justified, and the unused bits in this field MUST be set to zero.
The PSID value algorithmically identifies a set of ports assigned to a CE 💖. The first k bits on the left of this 2-octet field are the PSID value, and the remaining (16-k) bits on the right are padding zeros 🌈.
3.2. Softwire46-Priority Attribute 💅
Okay so the Softwire46-Priority Attribute is basically the client's wishlist 🧚. It's an ordered list of Softwire46 mechanisms, so the client can say which one it likes best. It lines up with OPTION_S46_PRIORITY from [RFC8026], and the rules are lowkey strict, bestie 🫶
- The Softwire46-Priority Attribute MAY appear in an Access-Accept packet. It MAY also appear in an Access-Request packet.
- The Softwire46-Priority Attribute MAY appear in a CoA-Request packet.
- The Softwire46-Priority Attribute MAY appear in an Accounting-Request packet.
- The Softwire46-Priority Attribute MUST NOT appear in any other RADIUS packet. 🙅♀️
The structure is giving very organized 🎀:
Type: 241Length: Indicates the length of this attribute, including the Type, Length, Extended-Type and Value fields.Extended-Type: 10TLV-Value: The attribute includes one or more Softwire46-Option-Code TLVs. A Softwire46-Priority Attribute MUST contain at least one Softwire46-Option-Code TLV (Section 3.2.1).
Here's the main character moment: Softwire46 mechanisms are ranked by their order of appearance in the attribute. So the first-appearing mechanism is the most preferred one 👑
The Softwire46-Priority Attribute is associated with the following identifier: 241.10. ✨
3.2.1. Softwire46-Option-Code 🦋
This attribute carries an option code assigned to a Softwire46 mechanism [RFC8026]. It's encoded in 32 bits, following the recommendation in Appendix A.2.1 of [RFC6158]. Iconic 💜
The structure of Softwire46-Option-Code looks like this:
TLV-Type: 18TLV-Length: 6 octetsData Type: The attribute Softwire46-Option-Code is of type "integer" (Section 3.1 of [RFC8044]).TLV-Value: A 32-bit IANA-registered option code representing a Softwire46 mechanism (Softwire46-option-code). The codes and their corresponding Softwire46 mechanisms are listed in Section 7.3.
3.3. Softwire46-Multicast Attribute 🌈
The Softwire46-Multicast Attribute conveys the IPv6 prefixes used to synthesize multicast and unicast IPv4-embedded IPv6 addresses, as per [RFC8114]. It's a "tlv" attribute that holds additional TLVs. Here are the rules, no cap:
- The BNG SHALL use the IPv6 prefixes returned in the RADIUS Softwire46-Multicast Attribute to populate the DHCPv6 PREFIX64 Option [RFC8115]. 🍓
- This attribute MAY be used in Access-Request packets as a hint to the RADIUS server. For example, if the BNG is preconfigured for Softwire46-Multicast, these prefixes may be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the BNG, and it MAY assign a different Softwire46-Multicast Attribute. 🧚
- The Softwire46-Multicast Attribute MAY appear in an Access-Request, Access-Accept, CoA-Request, and Accounting-Request packet.
- The Softwire46-Multicast Attribute MUST NOT appear in any other RADIUS packet.
- The Softwire46-Multicast Attribute MAY contain ASM-Prefix64 (Section 3.3.1), SSM-Prefix64 (Section 3.3.2), and U-Prefix64 (Section 3.3.3).
- The Softwire46-Multicast Attribute MUST include ASM-Prefix64 or SSM-Prefix64, and it MAY include both.
- The U-Prefix64 MUST be present when SSM-Prefix64 is present. U-Prefix64 MAY be present when ASM-Prefix64 is present. 💅
The structure is as follows:
Type: 241Length: This field indicates the total length in bytes of all fields of this attribute, including the Type, Length, Extended-Type, and the entire length of the embedded attributes.Extended-Type: 11Value: This field contains a set of attributes as follows:ASM-Prefix64: This attribute contains the Any-Source Multicast (ASM) IPv6 prefix. Refer to Section 3.3.1.SSM-Prefix64: This attribute contains the Source-Source Multicast (SSM) IPv6 prefix. Refer to Section 3.3.2.U-Prefix64: This attribute contains the IPv4 prefix used for address translation. Refer to Section 3.3.3.
The Softwire46-Multicast Attribute is associated with the following identifier: 241.11. 🦋
3.3.1. ASM-Prefix64 Attribute 🌸
The ASM-Prefix64 attribute is structured as follows:
TLV-Type: 19TLV-Length: 16 octets. The length of asm-prefix64 must be /96 [RFC8115].Data Type: The attribute ASM-Prefix64 is of type "ipv6prefix" (Section 3.10 of [RFC8044]).TLV-Value: This field specifies the IPv6 multicast prefix (asm-prefix64) to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the ASM mode. The conveyed multicast IPv6 prefix MUST belong to the ASM range. ✨
3.3.2. SSM-Prefix64 Attribute 🧚
The SSM-Prefix64 attribute is structured as follows:
Type: 20TLV-Length: 16 octets. The length of ssm-prefix64 must be /96 [RFC8115].Data Type: The attribute SSM-Prefix64 is of type "ipv6prefix" (Section 3.10 of [RFC8044]).TLV-Type: This field specifies the IPv6 multicast prefix (ssm-prefix64) to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the SSM mode. The conveyed multicast IPv6 prefix MUST belong to the SSM range. 🔥
3.3.3. U-Prefix64 Attribute 💖
The structure of U-Prefix64 is shown below:
TLV-Type: 21TLV-Length: 4 + length of unicast-prefix. As specified in [RFC6052], the unicast-prefix prefix length MUST be set to 32, 40, 48, 56, 64, or 96. 🙈Data Type: The attribute U-Prefix64 is of type "ipv6prefix" (Section 3.10 of [RFC8044]).TLV-Value: This field identifies the IPv6 unicast prefix (u-prefix64) to be used in the SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. It may also be used to extract the IPv4 address from the received multicast data flows. 😭
4. A Sample Configuration Process with RADIUS ✨
okay so this section is literally the play-by-play of how RADIUS and DHCPv6 team up to get the CE its softwire config 💖 Figure 2 shows the whole flow, bestie:
CE BNG AAA Server
| | |
|-------1.DHCPv6 Solicit------->| |
|(ORO with unicast and/or | |
| multicast container option | |
| codes(s)) | |
| |-------2.Access-Request------->|
| | (Softwire46-Configuration |
| | Attribute and/or |
| |Softwire46-Multicast Attribute)|
| | |
| |<------3.Access-Accept---------|
| | (Softwire46-Configuration |
| | Attribute and/or |
| |Softwire46-Multicast Attribute)|
| | |
|<----4.DHCPv6 Advertisement----| |
| (container option(s)) | |
| | |
|-------5.DHCPv6 Request------>| |
| (container option(s)) | |
| | |
|<--------6.DHCPv6 Reply--------| |
| (container option(s)) | |
| | |
DHCPv6 RADIUS
Figure 2: Interaction between DHCPv6 and AAA Server with
RADIUS AuthenticationHere's the step-by-step, no cap:
- The CE makes a DHCPv6 Solicit message. For unicast softwire config, it includes an
OPTION_REQUEST_OPTION (6)with the Softwire46 Container option code(s) from [RFC7598].OPTION_S46_CONT_MAPE (94)should be included for MAP-E,OPTION_S46_CONT_MAPT (95)for MAP-T, andOPTION_S46_CONT_LW (96)for Lightweight 4over6. For multicast config, the option number forOPTION_V6_PREFIX64 (113)goes in the client's Option Request Option (ORO). The message gets sent to the BNG 📨 - When the BNG gets that Solicit, it builds a RADIUS Access-Request with a
User-Name Attribute (1)(holding a CE Media Access Control (MAC) address, interface-id, or both) and aUser-Password Attribute (2)(with a preconfigured shared password between the CE and AAA server, as defined in [RFC2865]). The Softwire46-Configuration Attribute and/or Softwire46-Multicast Attribute get tossed in too, as requested by the client. Then it's sent to the AAA server 🫶 - The AAA server authenticates the request. If that works out and a suitable config is available, it sends an Access-Accept back to the BNG with the requested Softwire46-Configuration Attribute or Softwire46-Multicast Attribute. The AAA server is responsible for making sure the provided config is consistent 👑
- The BNG maps the received softwire config into the matching fields of the DHCPv6 softwire configuration option(s). Those go in the DHCPv6 Advertise message, which gets sent to the CE 🦋
- The CE sends a DHCPv6 Request. In the ORO, it lists the option codes of any required softwire options that showed up in the Advertise message 🎀
- The BNG sends a DHCPv6 Reply to the client with the softwire container option(s) listed in the ORO. Done and dusted 💅
The authorization step can also happen separately after authentication. In that case, steps 1 through 5 go down exactly as above, and then these extra steps happen:
6a. When the BNG gets the DHCPv6 Request, it builds a RADIUS Access-Request. It includes a Service-Type Attribute (6) set to "Authorize Only" (17), the matching Softwire46-Configuration Attribute, and a State Attribute carried over from the earlier authentication, per [RFC5080]. That message goes to the AAA server 🌸
7a. The AAA server checks the authorization request. If it's approved, an Access-Accept comes back to the BNG with the matching Softwire46-Configuration Attribute 🧚
8a. The BNG sends a Reply to the client with the softwire container options listed in the ORO ⭐
Now, the extra stuff you need to keep in mind, periodt 💜
- In the config message flows above, the Message-Authenticator (type 80) [RFC2869] should be used to protect both Access-Request and Access-Accept messages 🔐
- If the BNG doesn't get the matching Softwire46-Configuration Attribute in the Access-Accept, it may fall back to building the DHCPv6 softwire configuration options from the preconfigured Softwire46 config, if that's there 🍓
- If the BNG gets an Access-Reject from the AAA server, then the Softwire46 config must not be supplied to the client. Hard no 🙅♀️
- As specified in Section 18.2.5 of [RFC8415] ("Creation and Transmission of Rebind Messages"), if the DHCPv6 server that got the Renew message at time T1 hasn't responded by time T2, the CE (DHCPv6 client) should enter the Rebind state and try to reach any available server. In that situation, a secondary BNG that gets the DHCPv6 message must start a new Access-Request towards the AAA server. The secondary BNG includes the Softwire46-Configuration Attribute in that Access-Request 🔄
- For Lightweight 4over6, the CE's binding state needs to be synchronized between the clients and the Lightweight AFTR (lwAFTR)/BR. There are two ways to do that: static preconfiguration of the bindings on both the AAA server and lwAFTR, or on demand, where the AAA server updates the lwAFTR with the CE's binding state as it gets created or deleted 🦋
In some deployments, the DHCP server may use the Accounting-Request to report the softwire config it handed to a requesting host over to a AAA server. The DHCP server is responsible for making sure the config it gives to requesting hosts is consistent. Reported data sent to a AAA server may be needed for various operational purposes (e.g., regulatory) 📊
A config change (e.g., BR address) can trigger an exchange of CoA-Requests between the BNG and the AAA server, as Figure 3 shows. Basically, when the BNG gets a CoA-Request containing Softwire46 attributes, it sends a DHCPv6 Reconfigure message to the right CE to say an updated config is available. When the CE gets that, it sends a DHCPv6 Renew or Information-Request to grab the updated Softwire46 config. In deployments where the BNG embeds a DHCPv6 relay, CoA-Requests can be used following the procedure in [RFC6977] 🌈
CE BNG AAA Server
| | |
|---DHCPv6 Solicit--------->| |
| |---Access-Request---------->|
| |<--Access-Accept------------|
| |(Softwire46-Configuration |
| | Attribute ...) |
....
| | |
| |<-----CoA-Request-----------|
| |(Softwire46-Configuration |
| | Attribute ...) |
| |------CoA-Response--------->|
|<--DHCPv6 Reconfigure------| |
| | |
....
Figure 3: Change of Configuration Example5. Table of Attributes 🎀
okay this part's the cheat sheet! This document specifies three new RADIUS attributes, and here they are:
- Softwire46-Configuration Attribute:
241.9 - Softwire46-Priority Attribute:
241.10 - Softwire46-Multicast Attribute:
241.11
Table 3 shows which attributes can show up in which kinds of packets, and how many of each:
+-------+------+------+---------+----+-------+------+---------------+
|Request|Accept|Reject|Challenge|Acct|CoA-Req| # | Attribute |
| | | | |Req | | | |
+=======+======+======+=========+====+=======+======+===============+
| 0-1 | 0-1 | 0 | 0 |0-1 | 0-1 |241.9 | Softwire46- |
| | | | | | | | Configuration |
+-------+------+------+---------+----+-------+------+---------------+
| 0-1 | 0-1 | 0 | 0 |0-1 | 0-1 |241.10| Softwire46- |
| | | | | | | | Priority |
+-------+------+------+---------+----+-------+------+---------------+
| 0-1 | 0-1 | 0 | 0 |0-1 | 0-1 |241.11| Softwire46- |
| | | | | | | | Multicast |
+-------+------+------+---------+----+-------+------+---------------+
Table 3: Table of AttributesThat's the whole vibe for this part, bestie! 💖
6. Security Considerations 🔐✨
Okay bestie, this is the serious part 😭🔒. Section 9 of [RFC7596] discusses security issues related to Lightweight 4over6. Section 10 of [RFC7597] covers MAP-E, Section 13 of [RFC7599] covers MAP-T, and Section 9 of [RFC8114] covers security issues for delivering IPv4 multicast services to IPv4 clients over an IPv6 multicast network. Read those if you want the full picture 💅.
This document doesn't introduce any security issues that are inherently different from the ones already identified in Section 8 of [RFC2865] and Section 6 of [RFC5176] for CoA messages. The known vulnerabilities of the RADIUS protocol, which are discussed in Section 7 of [RFC2607] and Section 7 of [RFC2869], still apply here 🥀. These well-established RADIUS properties put some limits on how it can safely be used, because there's an inherent need to trust the other side not to misbehave 🙈.
So, this document is aimed at deployments where there's a trusted relationship between the RADIUS client and server. Communication can optionally be secured with IPsec or Transport Layer Security (TLS) [RFC6614] 🔒. If RADIUS is carried over IPv6, the use of IPsec [RFC4301] for security is discussed in [RFC3162].
Security considerations for interactions between a Softwire46 CE and the BNG are covered too: Section 9 of [RFC7598] (DHCPv6 options for the configuration of Softwire46 address and port-mapped clients), Section 3 of [RFC8026] (a DHCPv6-based Softwire46 prioritization mechanism), and Section 5 of [RFC8115] (DHCPv6 options for configuration of IPv4-embedded IPv6 prefixes) 🧚.
7. IANA Considerations 📋
IANA has made new code point assignments for RADIUS attributes, as described in the subsections below. The assignments should use the RADIUS registry available at https://www.iana.org/assignments/radius-types/.
7.1. New RADIUS Attributes
IANA has assigned the attribute types defined in this document from the RADIUS namespace, as described in Section 2 (IANA Considerations) of [RFC3575], in accordance with BCP 26 [RFC8126] 🌸.
IANA has registered three new RADIUS attributes from the "Short Extended Space" section of [RFC6929]. They are the Softwire46-Configuration Attribute, Softwire46-Priority Attribute, and Softwire46-Multicast Attribute 💖:
+--------+--------------------------+-----------+-------------+
| Type | Description | Data Type | Reference |
+========+==========================+===========+=============+
| 241.9 | Softwire46-Configuration | tlv | Section 3.1 |
+--------+--------------------------+-----------+-------------+
| 241.10 | Softwire46-Priority | tlv | Section 3.2 |
+--------+--------------------------+-----------+-------------+
| 241.11 | Softwire46-Multicast | tlv | Section 3.3 |
+--------+--------------------------+-----------+-------------+
Table 4: New RADIUS Attributes7.2. RADIUS Softwire46 Configuration and Multicast Attributes
IANA has created a new registry called "RADIUS Softwire46 Configuration and Multicast Attributes" 🧁.
Every attribute in this registry has one or more parent RADIUS attributes in nesting (refer to [RFC6929]) 🪆.
This registry was initially populated with the following values:
+--------+-------------------------------+------------+-----------+
| Value | Description | Data Type | Reference |
+========+===============================+============+===========+
| 0 | Reserved | | |
+--------+-------------------------------+------------+-----------+
| 1 | Softwire46-MAP-E | tlv | Section |
| | | | 3.1.1.1 |
+--------+-------------------------------+------------+-----------+
| 2 | Softwire46-MAP-T | tlv | Section |
| | | | 3.1.1.2 |
+--------+-------------------------------+------------+-----------+
| 3 | Softwire46-Lightweight-4over6 | tlv | Section |
| | | | 3.1.1.3 |
+--------+-------------------------------+------------+-----------+
| 4 | Softwire46-Rule (BMR) | tlv | Section |
| | | | 3.1.3.1 |
+--------+-------------------------------+------------+-----------+
| 5 | Softwire46-Rule (FMR) | tlv | Section |
| | | | 3.1.3.1 |
+--------+-------------------------------+------------+-----------+
| 6 | Softwire46-BR | ipv6addr | Section |
| | | | 3.1.3.2 |
+--------+-------------------------------+------------+-----------+
| 7 | Softwire46-DMR | ipv6prefix | Section |
| | | | 3.1.3.3 |
+--------+-------------------------------+------------+-----------+
| 8 | Softwire46-V4V6Bind | tlv | Section |
| | | | 3.1.3.4 |
+--------+-------------------------------+------------+-----------+
| 9 | Softwire46-PORTPARAMS | tlv | Section |
| | | | 3.1.3.5 |
+--------+-------------------------------+------------+-----------+
| 10 | Rule-IPv6-Prefix | ipv6prefix | Section |
| | | | 3.1.4.1 |
+--------+-------------------------------+------------+-----------+
| 11 | Rule-IPv4-Prefix | ipv4prefix | Section |
| | | | 3.1.4.2 |
+--------+-------------------------------+------------+-----------+
| 12 | EA-Length | integer | Section |
| | | | 3.1.4.3 |
+--------+-------------------------------+------------+-----------+
| 13 | IPv4-Address | ipv4addr | Section |
| | | | 3.1.5.1 |
+--------+-------------------------------+------------+-----------+
| 14 | Bind-IPv6-Prefix | ipv6prefix | Section |
| | | | 3.1.5.2 |
+--------+-------------------------------+------------+-----------+
| 15 | PSID-Offset | integer | Section |
| | | | 3.1.6.1 |
+--------+-------------------------------+------------+-----------+
| 16 | PSID-Len | integer | Section |
| | | | 3.1.6.2 |
+--------+-------------------------------+------------+-----------+
| 17 | PSID | integer | Section |
| | | | 3.1.6.3 |
+--------+-------------------------------+------------+-----------+
| 18 | Softwire46-Option-Code | integer | Section |
| | | | 3.2.1 |
+--------+-------------------------------+------------+-----------+
| 19 | ASM-Prefix64 | ipv6prefix | Section |
| | | | 3.3.1 |
+--------+-------------------------------+------------+-----------+
| 20 | SSM-Prefix64 | ipv6prefix | Section |
| | | | 3.3.2 |
+--------+-------------------------------+------------+-----------+
| 21 | U-Prefix64 | ipv6prefix | Section |
| | | | 3.3.3 |
+--------+-------------------------------+------------+-----------+
| 22-255 | Unassigned | | |
+--------+-------------------------------+------------+-----------+
Table 5: RADIUS Softwire46 Configuration and Multicast AttributesThe registration procedure for this registry is Standards Action, as defined in [RFC8126] 📜.
7.3. Softwire46 Mechanisms and Their Identifying Option Codes
The Softwire46-Priority Attribute conveys an ordered list of option codes assigned to Softwire46 mechanisms. IANA has created, and will maintain, a new registry titled "Option Codes Permitted in the Softwire46-Priority Attribute" 🎀.
Table 6 shows the initial version of the allowed option codes and the Softwire46 mechanisms they represent. The option code for DS-Lite is derived from the IANA-allocated RADIUS Attribute Type value for DS-Lite [RFC6519]. The option codes for MAP-E, MAP-T, and Lightweight 4over6 are the TLV-Type values for the MAP-E, MAP-T, and Lightweight 4over6 attributes defined in Section 3.1.1 🦋.
+-------------+----------------------+-----------+
| Option Code | Softwire46 Mechanism | Reference |
+=============+======================+===========+
| 1 | MAP-E | [RFC7597] |
+-------------+----------------------+-----------+
| 2 | MAP-T | [RFC7599] |
+-------------+----------------------+-----------+
| 3 | Lightweight 4over6 | [RFC7596] |
+-------------+----------------------+-----------+
| 144 | DS-Lite | [RFC6519] |
+-------------+----------------------+-----------+
Table 6: Option Codes to S46 MechanismsAdditional option codes may be added to this list in the future, using the IETF Review process described in Section 4.8 of [RFC8126] 🌈.
8. References 📚✨
8.1. Normative References
okay bestie, these are the docs this spec needs you to have read first 📚 every entry is listed below exactly as written 💅
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, DOI 10.17487/RFC3162, August 2001,
<https://www.rfc-editor.org/info/rfc3162>.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
DOI 10.17487/RFC3575, July 2003,
<https://www.rfc-editor.org/info/rfc3575>.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December
2007, <https://www.rfc-editor.org/info/rfc5080>.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
DOI 10.17487/RFC5176, January 2008,
<https://www.rfc-editor.org/info/rfc5176>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011,
<https://www.rfc-editor.org/info/rfc6158>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013,
<https://www.rfc-editor.org/info/rfc6929>.
[RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6
Softwire Customer Premises Equipment (CPE): A DHCPv6-Based
Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026,
November 2016, <https://www.rfc-editor.org/info/rfc8026>.
[RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044,
DOI 10.17487/RFC8044, January 2017,
<https://www.rfc-editor.org/info/rfc8044>.
[RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017,
<https://www.rfc-editor.org/info/rfc8115>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.8.2. Informative References
these ones are the extra reading 🦋 handy for background, not required to get the core spec
[LIGHTWEIGHT-4OVER6]
Xie, C., Sun, Q., Qiong, Q., Zhou, C., Tsou, T., and Z.
Liu, "Radius Extension for Lightweight 4over6", Work in
Progress, Internet-Draft, draft-sun-softwire-lw4over6-
radext-01, 6 March 2014, <https://tools.ietf.org/html/
draft-sun-softwire-lw4over6-radext-01>.
[RADIUS-EXT]
Wang, Q., Meng, W., Wang, C., and M. Boucadair, "RADIUS
Extensions for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", Work in Progress, Internet-Draft, draft-wang-
radext-multicast-radius-ext-00, 2 December 2015,
<https://tools.ietf.org/html/draft-wang-radext-multicast-
radius-ext-00>.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607,
DOI 10.17487/RFC2607, June 1999,
<https://www.rfc-editor.org/info/rfc2607>.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000,
<https://www.rfc-editor.org/info/rfc2869>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[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,
<https://www.rfc-editor.org/info/rfc6333>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
the IPv4 Address Shortage", RFC 6346,
DOI 10.17487/RFC6346, August 2011,
<https://www.rfc-editor.org/info/rfc6346>.
[RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual-
Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February
2012, <https://www.rfc-editor.org/info/rfc6519>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/info/rfc6614>.
[RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6
Reconfiguration from Relay Agents", RFC 6977,
DOI 10.17487/RFC6977, July 2013,
<https://www.rfc-editor.org/info/rfc6977>.
[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, <https://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,
<https://www.rfc-editor.org/info/rfc7597>.
[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,
<https://www.rfc-editor.org/info/rfc7598>.
[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, <https://www.rfc-editor.org/info/rfc7599>.
[RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q.
Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients
over an IPv6 Multicast Network", RFC 8114,
DOI 10.17487/RFC8114, March 2017,
<https://www.rfc-editor.org/info/rfc8114>.Appendix A. DHCPv6 to RADIUS Field Mappings 🧚
okay so this appendix is basically the matching game 🎀 it shows how the softwire DHCPv6 option fields line up with the RADIUS attributes defined in this document. no cap, it's the cheat sheet you'll want open
A.1. OPTION_S46_RULE (89) to Softwire46-Rule Sub-TLV Field Mappings
+-----------------------+----------------------+------------------+
| OPTION_S46_RULE Field | Softwire46-Rule Name | TLV Subfield |
+=======================+======================+==================+
| flags | N/A | TLV-type (4, 5) |
+-----------------------+----------------------+------------------+
| ea-len | EA-Length | EA-len |
+-----------------------+----------------------+------------------+
| prefix4-len | Rule-IPv4-Prefix | Prefix-Length |
+-----------------------+----------------------+------------------+
| ipv4-prefix | Rule-IPv4-Prefix | rule-ipv4-prefix |
+-----------------------+----------------------+------------------+
| prefix6-len | Rule-IPv6-Prefix | Prefix-Length |
+-----------------------+----------------------+------------------+
| ipv6-prefix | Rule-IPv6-Prefix | rule-ipv6-prefix |
+-----------------------+----------------------+------------------+
Table 7: OPTION_S46_RULE to Softwire46-Rule Sub-TLV Field MappingsA.2. OPTION_S46_BR (90) to Softwire46-BR Field Mappings
+---------------------+------------------------+
| OPTION_S46_BR Field | Softwire46-BR Subfield |
+=====================+========================+
| br-ipv6-address | br-ipv6-address |
+---------------------+------------------------+
Table 8: OPTION_S46_BR to Softwire46-BR
Field MappingsA.3. OPTION_S46_DMR (91) to Softwire46-DMR
+----------------------+-------------------------+
| OPTION_S46_DMR Field | Softwire46-DMR Subfield |
+======================+=========================+
| dmr-prefix6-len | dmr-prefix6-len |
+----------------------+-------------------------+
| dmr-ipv6-prefix | dmr-ipv6-prefix |
+----------------------+-------------------------+
Table 9: OPTION_S46_DMR to Softwire46-DMR
Field MappingsA.4. OPTION_S46_V4V6BIND (92) to Softwire46-V4V6Bind
+---------------------+---------------------+------------------+
| OPTION_S46_V4V6BIND | Softwire46-V4V6Bind | TLV Subfield |
| Field | Name | |
+=====================+=====================+==================+
| ipv4-address | IPv4-Address | ipv4-address |
+---------------------+---------------------+------------------+
| bindprefix6-len | Bind-IPv6-Prefix | Prefix-Length |
+---------------------+---------------------+------------------+
| bind-ipv6-prefix | Bind-IPv6-Prefix | bind-ipv6-prefix |
+---------------------+---------------------+------------------+
Table 10: OPTION_S46_V4V6BIND to Softwire46-V4V6Bind
Field MappingsA.5. OPTION_S46_PORTPARAMS (93) to Softwire46-PORTPARAMS Field Mappings 🧚
okay so this table maps the fields of OPTION_S46_PORTPARAMS (93) onto the Softwire46-PORTPARAMS TLV, and it's giving neat little matching pairs 💖
+-----------------------------+-----------------------+-------------+
| OPTION_S46_PORTPARAMS | Softwire46-PORTPARAMS | TLV |
| Field | Name | Subfield |
+=============================+=======================+=============+
| offset | PSID-Offset | PSID-Offset |
+-----------------------------+-----------------------+-------------+
| PSID-len | PSID-Len | PSID-len |
+-----------------------------+-----------------------+-------------+
| PSID | PSID | PSID |
+-----------------------------+-----------------------+-------------+
Table 11: OPTION_S46_PORTPARAMS to Softwire46-PORTPARAMS
Field Mappingsso the offset field lands in PSID-Offset, PSID-len lands in PSID-Len, and PSID stays PSID 🎀 three fields, three clean matches, iconic
A.6. OPTION_S46_PRIORITY (111) to Softwire46-PORTPARAMS Field Mappings 🌸
next up is the priority option. OPTION_S46_PRIORITY (111) only has one field to map, so this table is short and sweet 🍓
+---------------------------+------------------------+
| OPTION_S46_PRIORITY Field | Softwire46-Priority |
| | Attribute Subfield |
+===========================+========================+
| s46-option-code | Softwire46-option-code |
+---------------------------+------------------------+
Table 12: OPTION_S46_PRIORITY to
Softwire46-PORTPARAMS Field Mappingsso s46-option-code maps to Softwire46-option-code ✨ one field, one buddy, zero drama
A.7. OPTION_V6_PREFIX64 (113) to Softwire46-Multicast Attribute Field Mappings 🦋
last but DEFINITELY not least, OPTION_V6_PREFIX64 (113) gets mapped onto the Softwire46-Multicast attribute 😭 this one's a bigger table because there are three kinds of prefix in here: ASM, SSM, and unicast. each one has its own length and its own prefix, and they each get their own TLV name 💜
+--------------------------+----------------------+---------------+
| OPTION_V6_PREFIX64 Field | Softwire46-Multicast | TLV Subfield |
| | Attribute TLV Name | |
+==========================+======================+===============+
| asm-length | ASM-Prefix64 | Prefix-Length |
+--------------------------+----------------------+---------------+
| ASM_mPrefix64 | ASM-Prefix64 | asm-prefix64 |
+--------------------------+----------------------+---------------+
| ssm-length | SSM-Prefix64 | Prefix-Length |
+--------------------------+----------------------+---------------+
| SSM_mPrefix64 | SSM-Prefix64 | ssm-prefix64 |
+--------------------------+----------------------+---------------+
| unicast-length | U-Prefix64 | Prefix-Length |
+--------------------------+----------------------+---------------+
| uPrefix64 | U-Prefix64 | u-prefix64 |
+--------------------------+----------------------+---------------+
Table 13: OPTION_V6_PREFIX64 to Softwire46-Multicast Field Mappingsso the pattern is: each length field goes to Prefix-Length, and each prefix field goes to its own named subfield. asm-length and ASM_mPrefix64 both land in ASM-Prefix64, ssm-length and SSM_mPrefix64 both land in SSM-Prefix64, and unicast-length and uPrefix64 both land in U-Prefix64 🌈 it's literally a pair-up party
Acknowledgements ✨
okay the authors want to shout out a bunch of amazing people 🫶 huge thanks to Peter Lothberg, Wojciech Dec, Ian Farrer, Suresh Krishnan, Qian Wang, Wei Meng, Cui Wang, Alan Dekok, Stefan Winter, and Yu Tianpeng for their super valuable comments on this doc 💅
this document was merged with [LIGHTWEIGHT-4OVER6] and [RADIUS-EXT]. thank you to everyone who contributed to this doc, you're all main character energy 👑
and many many thanks to Al Morton, Bernie Volz, Joel Halpern, and Donald Eastlake for the review 🙈🔥
Contributors 🌷
these are the folks who helped write this doc, with their affiliations, countries, and emails 💜
Bing Liu
Huawei Technologies Co., Ltd.
China
Email: leo.liubing@huawei.com
Peter Deacon
IEA Software, Inc.
United States of America
Email: peterd@iea-software.com
Qiong Sun
China Telecom
China
Email: sunqiong@ctbri.com.cn
Qi Sun
Tsinghua University
China
Email: sunqibupt@gmail.com
Cathy Zhou
Huawei Technologies
China
Email: cathy.zhou@huawei.com
Tina Tsou
Huawei Technologies (USA)
United States of America
Email: Tina.Tsou.Zouting@huawei.com
ZiLong Liu
Tsinghua University
China
Email: liuzilong8266@126.com
Yong Cui
Tsinghua University
China
Email: yong@csnet1.cs.tsinghua.edu.cnAuthors' Addresses 🎀
and finally, the editors and authors and where to find them 🦋 the editors are marked, so you know who to bug first 😂
Sheng Jiang (editor)
China
Hai-Dian District, Beijing, 100095
Q14, Huawei Campus, No.156 Beiqing Road
Huawei Technologies Co., Ltd.
Email: jiangsheng@huawei.com
Yu Fu (editor)
China
Hai-Dian District, Beijing, 100190
No.4 South 4th Street, Zhongguancun
CNNIC
Email: eleven711711@foxmail.com
Chongfeng Xie
China
Beijing
China Telecom
Email: xiechf.bri@chinatelecom.cn
Tianxiang Li
China
100084
Beijing
Tsinghua University
Email: peter416733@gmail.com
Mohamed Boucadair (editor)
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.comthat's the whole doc, bestie! 🌈✨ thank you for reading all of it with me 🫶💖
📦 where this page comes from
- ietf: rfc8658 2019-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms