rfc-8658

RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)

S. Jiang (Editor), Y. Fu (Editor), C. Xie, T. Li, M. Boucadair (Editor)
date2019-11 streamIETF areaint wgsoftwire statusPROPOSED STANDARD pages34 canonicalhttps://www.rfc-editor.org/rfc/rfc8658 doi10.17487/RFC8658
IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly. This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered.

Extracted elements (29)

design-rationale §3

All three new top-level RADIUS attributes (Softwire46-Configuration, Softwire46-Priority, Softwire46-Multicast) are allocated from the RADIUS 'Extended Type' code space per RFC 6929, as standard RADIUS type space (1–191) was not available. This follows RFC 6158 and RFC 8044 design guidelines.

radius, registry

design-rationale §1

The RADIUS attributes defined in this document have a 1:1 field mapping into the corresponding DHCPv6 options in RFC 7598, RFC 8026, and RFC 8115. This allows the BNG to directly translate RADIUS-received configuration into DHCPv6 options for CE provisioning without protocol-specific processing.

radius, v6ops

design-rationale §3.1.3.1

Using separate TLV-Type values 4 (BMR) and 5 (FMR) for Softwire46-Rule achieves the same design goals as the 'Softwire46 Rule Flags' F-flag in DHCPv6 OPTION_S46_RULE (Section 4.1 of RFC 7598), avoiding the need for a flags field within the RADIUS TLV.

radius, v6ops

interoperability-note §4 MUST NOT

If the BNG does not receive a Softwire46-Configuration Attribute in Access-Accept, it may fall back to preconfigured local Softwire46 configuration. If Access-Reject is received, Softwire46 configuration MUST NOT be supplied to the CE.

radius, v6ops

interoperability-note §4

The BNG must implement dual roles: it acts as an AAA/RADIUS client toward the AAA server and as a DHCPv6 server toward Customer Edge devices. Softwire46 configuration flows from AAA → BNG via RADIUS and from BNG → CE via DHCPv6 container options (OPTION_S46_CONT_MAPE/MAPT/LW).

radius, v6ops

interoperability-note §4 MUST

When a CE enters the DHCPv6 Rebind state (T2 expires), a secondary BNG receiving the DHCPv6 message MUST initiate a new RADIUS Access-Request including the Softwire46-Configuration Attribute to the AAA server.

radius, v6ops

normative-requirement §3.3.1 MUST

ASM-Prefix64 (TLV-Type 19) and SSM-Prefix64 (TLV-Type 20) MUST each be a /96 prefix per RFC 8115, encoded as a 16-octet ipv6prefix TLV. The conveyed ASM prefix MUST belong to the ASM range and SSM prefix MUST belong to the SSM range.

radius, multicast, v6ops

normative-requirement §3.1.6.2 MUST

PSID-Len MUST be set to zero to indicate the PSID field is to be ignored. When non-zero (k bits), the address-sharing ratio is 2^k. After the first 'a' offset bits in the port number, the next k bits represent the PSID value.

radius, v6ops

normative-requirement §3.1.4.1 REQUIRED

Rule-IPv6-Prefix is REQUIRED for every Softwire46-Rule; there MUST be exactly one Rule-IPv6-Prefix encapsulated in each Softwire46-Rule instance.

radius, v6ops

normative-requirement §3.1 REQUIRED

The BNG SHALL use the configuration information returned in the RADIUS Softwire46-Configuration Attribute to populate the DHCPv6 Softwire46 container option(s) defined in Section 5 of RFC 7598.

radius, v6ops

normative-requirement §3.1 MUST NOT

The Softwire46-Configuration Attribute MAY appear in Access-Accept, Access-Request, CoA-Request, and Accounting-Request packets. It MUST NOT appear in any other RADIUS packet type (e.g., Access-Reject, Access-Challenge).

radius, v6ops

normative-requirement §3.1 MUST

The Softwire46-Configuration Attribute MUST contain one or more of the following attributes: Softwire46-MAP-E, Softwire46-MAP-T, and/or Softwire46-Lightweight-4over6. There MUST be at most one instance of each type encapsulated in one Softwire46-Configuration Attribute.

radius, v6ops

normative-requirement §3.3 MUST

The Softwire46-Multicast Attribute MUST include ASM-Prefix64 or SSM-Prefix64 (or both). U-Prefix64 MUST be present when SSM-Prefix64 is present; U-Prefix64 MAY be present when only ASM-Prefix64 is present.

radius, multicast, v6ops

normative-requirement §3.3.3 MUST

U-Prefix64 (TLV-Type 21) unicast prefix length MUST be set to 32, 40, 48, 56, 64, or 96 as specified in RFC 6052. It identifies the IPv6 unicast prefix used to construct IPv4-embedded IPv6 addresses for IPv4 multicast sources in SSM mode.

radius, multicast, v6ops

protocol-element §3.1

Softwire46-Configuration Attribute (identifier 241.9, type 'tlv') carries configuration information for MAP-E, MAP-T, and Lightweight 4over6 from an AAA server to a BNG. It encapsulates one or more of: Softwire46-MAP-E, Softwire46-MAP-T, and Softwire46-Lightweight-4over6 sub-attributes.

radius, v6ops

protocol-element §3.1.1.3

Softwire46-Lightweight-4over6 (TLV-Type 3) MUST contain Softwire46-BR and exactly one Softwire46-V4V6Bind sub-attribute, and MAY contain Softwire46-PORTPARAMS. Softwire46-Rule and Softwire46-DMR are not permitted.

radius, v6ops

protocol-element §3.1.1.1

Softwire46-MAP-E (TLV-Type 1) MUST contain Softwire46-Rule and Softwire46-BR sub-attributes, and MAY contain Softwire46-PORTPARAMS. One or more Softwire46-BR instances are required; one BMR plus zero or more FMRs must be included via Softwire46-Rule.

radius, v6ops

protocol-element §3.1.1.2

Softwire46-MAP-T (TLV-Type 2) MUST contain Softwire46-Rule and exactly one Softwire46-DMR sub-attribute, and MAY contain Softwire46-PORTPARAMS. Softwire46-BR is not permitted in MAP-T.

radius, v6ops

protocol-element §3.3

Softwire46-Multicast Attribute (identifier 241.11, type 'tlv') conveys IPv6 prefixes used to synthesize multicast and unicast IPv4-embedded IPv6 addresses per RFC 8114. The BNG uses these prefixes to populate the DHCPv6 PREFIX64 Option (RFC 8115).

radius, multicast, v6ops

protocol-element §3.2

Softwire46-Priority Attribute (identifier 241.10, type 'tlv') conveys an ordered list of Softwire46 mechanism option codes allowing a CE to prioritize which softwire mechanism to use, corresponding to OPTION_S46_PRIORITY (RFC 8026). Mechanisms are prioritized by appearance order.

radius, v6ops

registry §7.3

IANA created a new registry 'Option Codes Permitted in the Softwire46-Priority Attribute' with initial values: 1=MAP-E (RFC 7597), 2=MAP-T (RFC 7599), 3=Lightweight 4over6 (RFC 7596), 144=DS-Lite (RFC 6519). Additional codes require IETF Review.

registry, radius, v6ops

registry §7.2

IANA created a new registry 'RADIUS Softwire46 Configuration and Multicast Attributes' with values 1–21 assigned (Softwire46-MAP-E through U-Prefix64) and values 22–255 unassigned. All attributes are nested sub-TLVs; registration procedure is Standards Action.

registry, radius, v6ops

registry §7.1

IANA registered three new RADIUS attributes from the 'Short Extended Space' of RFC 6929: Softwire46-Configuration (241.9, tlv), Softwire46-Priority (241.10, tlv), and Softwire46-Multicast (241.11, tlv). Registration procedure is Standards Action.

registry, radius

security-consideration §6

RADIUS communication should optionally be secured by IPsec (RFC 4301) or TLS (RFC 6614). The Message-Authenticator attribute (type 80, RFC 2869) should be used to protect both Access-Request and Access-Accept messages in the softwire configuration flow.

security, radius, tls, ipsec

security-consideration §6

This document targets deployments where a trusted relationship is in place between the RADIUS client and server. The existing RADIUS security vulnerabilities discussed in RFC 2607 and RFC 2869 apply; there is an inherent requirement to trust the counterparty.

security, radius

wire-format §3.1.3.2

Softwire46-BR (TLV-Type 6) has a fixed TLV-Length of 18 octets and carries the Border Relay IPv6 address as a 16-octet ipv6addr field. Softwire46-DMR (TLV-Type 7) carries a variable-length ipv6prefix (dmr-ipv6-prefix) with TLV-Length of 4 plus prefix length in octets; prefixes 0–96 bits are allowed, right-padded to octet boundary.

radius, v6ops

wire-format §3.1.3.5

Softwire46-PORTPARAMS (TLV-Type 9) contains PSID-Offset (TLV-Type 15, 6 octets, 8-bit value right-justified in 32 bits), PSID-Len (TLV-Type 16, 6 octets, 8-bit 'k' value), and PSID (TLV-Type 17, 6 octets, 16-bit value right-justified in 32 bits). Unused bits MUST be set to zero.

radius, v6ops

wire-format §3.1.3.1

Softwire46-Rule uses TLV-Type 4 for Basic Mapping Rule (BMR) or TLV-Type 5 for Forwarding Mapping Rule (FMR). It contains sub-attributes Rule-IPv6-Prefix (TLV-Type 10, ipv6prefix), Rule-IPv4-Prefix (TLV-Type 11, ipv4prefix), and EA-Length (TLV-Type 12, 6-octet integer with EA-len in 32 bits).

radius, v6ops

wire-format §3.1.3.4

Softwire46-V4V6Bind (TLV-Type 8, type 'tlv') contains IPv4-Address (TLV-Type 13, 6 octets, 32-bit ipv4addr) and Bind-IPv6-Prefix (TLV-Type 14, variable-length ipv6prefix) used to identify the CE's IPv4 address and the IPv6 prefix for tunnel source construction.

radius, v6ops