Abstract

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.¶

1. Introduction

Providers have started deploying and transitioning to IPv6. Several IPv4 service continuity mechanisms based on Address plus Port (A+P) [RFC6346] have been proposed for providing unicast IPv4-over-IPv6-only infrastructure, such as Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], Mapping of Address and Port using Translation (MAP-T) [RFC7599], and Lightweight 4over6 [RFC7596]. Also, [RFC8114] specifies a generic solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. For each of these mechanisms, DHCPv6 options have been specified for client configuration.¶

In many networks, user configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server. AAA servers generally communicate using the Remote Authentication Dial In User Service (RADIUS) [RFC2865] protocol. In a fixed broadband network, a Broadband Network Gateway (BNG) acts as the access gateway for users. That is, 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, the term "BNG" describes a device implementing both the AAA client and DHCPv6 server functions.¶

Since IPv4-in-IPv6 softwire configuration information is stored in a AAA server and user configuration information is mainly transmitted through DHCPv6 between the BNGs and Customer Premises Equipment (CEs, a.k.a., CPE), new RADIUS attributes are needed to propagate the information from the AAA servers to BNGs so that they can be provided to CEs using the existing DHCPv6 options.¶

The RADIUS attributes defined in this document provide the configuration to populate the corresponding 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 contents of the attributes defined in this document have a 1:1 mapping into the fields of the various DHCPv6 options in [RFC7598], [RFC8026], and [RFC8115]. Table 1 shows how the DHCPv6 options map to the corresponding RADIUS attribute. For detailed mappings between each DHCPv6 option field and the corresponding RADIUS attribute or field, see Appendix A.¶

A 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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The reader should be familiar with 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 throughout to denote any of the IPv4-in-IPv6 softwire mechanisms listed above. Additionally, the following abbreviations are used within the document:¶

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, Value¶

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, Value¶

3. New RADIUS Attributes

This section defines the following attributes:¶

1. Softwire46-Configuration Attribute (Section 3.1):¶

   This attribute carries the configuration information for MAP-E, MAP-T, and Lightweight 4over6. The configuration information for each Softwire46 mechanism is carried in the corresponding Softwire46 attributes. Different attributes are required for each Softwire46 mechanism.¶

2. Softwire46-Priority Attribute (Section 3.2):¶

   Depending on the deployment scenario, a client may support several different Softwire46 mechanisms. Therefore, a client may request configuration for more than one Softwire46 mechanism at a time. The Softwire46-Priority Attribute contains information allowing the client to prioritize which mechanism to use, corresponding to OPTION_S46_PRIORITY defined in [RFC8026].¶

3. Softwire46-Multicast Attribute (Section 3.3):¶

   This attribute conveys the IPv6 prefixes to be used in [RFC8114] to synthesize IPv4-embedded IPv6 addresses. The BNG uses the IPv6 prefixes returned in the RADIUS Softwire46-Multicast Attribute to populate the DHCPv6 PREFIX64 Option [RFC8115].¶

All of these attributes are allocated from the RADIUS "Extended Type" code space per [RFC6929].¶

All of these attribute designs follow [RFC6158] and [RFC6929].¶

This document adheres to the guidance in [RFC8044] for defining new RADIUS attributes.¶

                                              
                                                /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 
- |                    \                             |    
C |                                                  | 3.PSID  
o |                                                   \   
n |
f |                                             /1.Rule-IPv6-Prefix  
i |                    /                       |    
g |                   | 1.Softwire46-Rule------+ 2.Rule-IPv4-Prefix 
u | Softwire46-MAP-T--+                        |    
r |                   | 2.Softwire46-DMR       | 3.EA-Length 
a |                   |                         \   
t |                   |                               /1.PSID-Offset
i |                   |                              |    
o |                   | 3.Softwire46-PORTPARAMS------+ 2.PSID-Len 
n |                    \                             |    
  |                                                  | 3.PSID
A |                                                   \  
t |                     
t |                                                 /1.IPv4-Address
r |                    /                           |   
i |                   | 1.Softwire46-V4V6Bind -----+ 2.Bind-IPv6-Prefix 
b | Softwire46-       |                             \   
u | Lightweight-4over6+ 2.Softwire46-BR               /1.PSID-Offset
t  \                  |                              |    
e                     | 3.Softwire46-PORTPARAMS  ----+ 2.PSID-Len 
                       \                             |    
                                                     | 3.PSID 
                                                      \  

4. A Sample Configuration Process with RADIUS

Figure 2 illustrates how the RADIUS and DHCPv6 protocols interwork to provide CE with softwire configuration information.¶

 
 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

1. The CE creates a DHCPv6 Solicit message. For unicast softwire configuration, the message includes an OPTION_REQUEST_OPTION (6) with the Softwire46 Container option code(s) as defined in [RFC7598]. OPTION_S46_CONT_MAPE (94) should be included for MAP-E, OPTION_S46_CONT_MAPT (95) for MAP-T, and OPTION_S46_CONT_LW (96) for Lightweight 4over6. For multicast configuration, the option number for OPTION_V6_PREFIX64 (113) is included in the client's Option Request Option (ORO). The message is sent to the BNG.¶
2. On receipt of the DHCPv6 Solicit message, the BNG constructs a RADIUS Access-Request message containing a User-Name Attribute (1) (containing either a CE Media Access Control (MAC) address, interface-id, or both) and a User-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 are also included (as requested by the client). The resulting message is sent to the AAA server.¶
3. The AAA server authenticates the request. If this is successful, and a suitable configuration is available, an Access-Accept message is sent to the BNG containing the requested Softwire46-Configuration Attribute or Softwire46-Multicast Attribute. It is the responsibility of the AAA server to ensure the consistency of the provided configuration.¶
4. The BNG maps the received softwire configuration into the corresponding fields in the DHCPv6 softwire configuration option(s). These are included in the DHCPv6 Advertise message, which is sent to the CE.¶
5. The CE sends a DHCPv6 Request message. In the ORO, the option codes of any of the required softwire options that were received in the DHCPv6 Advertise message are included.¶
6. The BNG sends a DHCPv6 Reply message to the client containing the softwire container option(s) enumerated in the ORO.¶

TESTING SPACING="COMPACT"¶

1. The CE creates a DHCPv6 Solicit message. For unicast softwire configuration, the message includes an OPTION_REQUEST_OPTION (6) with the Softwire46 Container option code(s) as defined in [RFC7598]. OPTION_S46_CONT_MAPE (94) should be included for MAP-E, OPTION_S46_CONT_MAPT (95) for MAP-T, and OPTION_S46_CONT_LW (96) for Lightweight 4over6. For multicast configuration, the option number for OPTION_V6_PREFIX64 (113) is included in the client's Option Request Option (ORO). The message is sent to the BNG.¶
2. On receipt of the DHCPv6 Solicit message, the BNG constructs a RADIUS Access-Request message containing a User-Name Attribute (1) (containing either a CE Media Access Control (MAC) address, interface-id, or both) and a User-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 are also included (as requested by the client). The resulting message is sent to the AAA server.¶
3. The AAA server authenticates the request. If this is successful, and a suitable configuration is available, an Access-Accept message is sent to the BNG containing the requested Softwire46-Configuration Attribute or Softwire46-Multicast Attribute. It is the responsibility of the AAA server to ensure the consistency of the provided configuration.¶
4. The BNG maps the received softwire configuration into the corresponding fields in the DHCPv6 softwire configuration option(s). These are included in the DHCPv6 Advertise message, which is sent to the CE.¶
5. The CE sends a DHCPv6 Request message. In the ORO, the option codes of any of the required softwire options that were received in the DHCPv6 Advertise message are included.¶
6. The BNG sends a DHCPv6 Reply message to the client containing the softwire container option(s) enumerated in the ORO.¶

The authorization operation could be done independently after the authentication process. In this case, steps 1-5 are completed as above, then the following steps are performed:¶

6a.

When the BNG receives the DHCPv6 Request, it constructs a RADIUS Access-Request message, which contains a Service-Type Attribute (6) with the value "Authorize Only" (17), the corresponding Softwire46-Configuration Attribute, and a State Attribute obtained from the previous authentication process according to [RFC5080]. The resulting message is sent to the AAA server.¶

7a.

The AAA server checks the authorization request. If it is approved, an Access-Accept message is returned to the BNG with the corresponding Softwire46-Configuration Attribute.¶

8a.

The BNG sends a Reply message to the client containing the softwire container options enumerated in the ORO.¶

TESTING:¶

6a.

When the BNG receives the DHCPv6 Request, it constructs a RADIUS Access-Request message, which contains a Service-Type Attribute (6) with the value "Authorize Only" (17), the corresponding Softwire46-Configuration Attribute, and a State Attribute obtained from the previous authentication process according to [RFC5080]. The resulting message is sent to the AAA server.¶

7a.

The AAA server checks the authorization request. If it is approved, an Access-Accept message is returned to the BNG with the corresponding Softwire46-Configuration Attribute.¶

8a.

The BNG sends a Reply message to the client containing the softwire container options enumerated in the ORO.¶

In addition to the above, the following points need to be considered:¶

• In the configuration message flows described above, the Message-Authenticator (type 80) [RFC2869] should be used to protect both Access-Request and Access-Accept messages.¶
• If the BNG does not receive the corresponding Softwire46-Configuration Attribute in the Access-Accept message, it may fall back to creating the DHCPv6 softwire configuration options using the preconfigured Softwire46 configuration if this is present.¶
• If the BNG receives an Access-Reject from the AAA server, then the Softwire46 configuration must not be supplied to the client.¶
• As specified in Section 18.2.5 of [RFC8415] ("Creation and Transmission of Rebind Messages") if the DHCPv6 server to which the DHCPv6 Renew message was sent at time T1 has not responded by time T2, the CE (DHCPv6 client) should enter the Rebind state and attempt to contact any available server. In this situation, a secondary BNG receiving the DHCPv6 message must initiate a new Access-Request message towards the AAA server. The secondary BNG includes the Softwire46-Configuration Attribute in this Access-Request message.¶
• For Lightweight 4over6, the CE's binding state needs to be synchronized between the clients and the Lightweight AFTR (lwAFTR)/BR. This can be achieved in two ways: static preconfiguration of the bindings on both the AAA server and lwAFTR or on demand, whereby the AAA server updates the lwAFTR with the CE's binding state as it is created or deleted.¶

In some deployments, the DHCP server may use the Accounting-Request to report the softwire configuration returned to a requesting host to a AAA server. It is the responsibility of the DHCP server to ensure the consistency of the configuration provided to the requesting hosts. Reported data to a AAA server may be required for various operational purposes (e.g., regulatory).¶

A configuration change (e.g., BR address) may result in an exchange of CoA-Requests between the BNG and the AAA server, as shown in Figure 3. Concretely, when the BNG receives a CoA-Request message containing Softwire46 attributes, it sends a DHCPv6 Reconfigure message to the appropriate CE to inform that CE that an updated configuration is available. Upon receipt of such a message, the CE sends a DHCPv6 Renew or Information-Request in order to receive the updated Softwire46 configuration. In deployments where the BNG embeds a DHCPv6 relay, CoA-Requests can be used following the procedure specified in [RFC6977].¶

       CE                          BNG                       AAA Server
        |                           |                            |
        |---DHCPv6 Solicit--------->|                            |
        |                           |---Access-Request---------->|
        |                           |<--Access-Accept------------|
        |                           |(Softwire46-Configuration   |
        |                           |    Attribute ...)          |
                                  ....
        |                           |                            |
        |                           |<-----CoA-Request-----------|
        |                           |(Softwire46-Configuration   |
        |                           |    Attribute ...)          |
        |                           |------CoA-Response--------->|
        |<--DHCPv6 Reconfigure------|                            |
        |                           |                            |
                                  ....

5. Table of Attributes

This document specifies three new RADIUS attributes, and their formats are as follows:¶

• Softwire46-Configuration Attribute: 241.9¶
• Softwire46-Priority Attribute: 241.10¶
• Softwire46-Multicast Attribute: 241.11¶

Table 3 describes which attributes may be found in which kinds of packets and in what quantity.¶

8. References

Contributors

Bing Liu 
Huawei Technologies Co., Ltd. 
Q14, Huawei Campus, No.156 Beiqing Road 
Hai-Dian District, Beijing, 100095 
China 

Email: leo.liubing@huawei.com


Peter Deacon 
IEA Software, Inc. 
P.O. Box 1170 
Veradale, WA  99037 
United States of America 

Email: peterd@iea-software.com


Qiong Sun 
China Telecom 
Beijing 
China 

Email: sunqiong@ctbri.com.cn


Qi Sun 
Tsinghua University 
Department of Computer Science, Tsinghua University 
Beijing 100084 
China 

Phone: +86-10-6278-5822 
Email: sunqibupt@gmail.com


Cathy Zhou 
Huawei Technologies 
Bantian, Longgang District 
Shenzhen 518129 
China 
   
Email: cathy.zhou@huawei.com


Tina Tsou 
Huawei Technologies (USA) 
2330 Central Expressway 
Santa Clara, CA 95050 
United States of America 

Email: Tina.Tsou.Zouting@huawei.com


ZiLong Liu 
Tsinghua University 
Beijing 100084 
China 

Phone: +86-10-6278-5822 
Email: liuzilong8266@126.com


Yong Cui 
Tsinghua University 
Beijing 100084 
China 

Phone: +86-10-62603059 
Email: yong@csnet1.cs.tsinghua.edu.cn