Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions
draft-zhou-dime-4over6-provisioning-02

Abstract

During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been or are currently being defined for carrying IPv4 packets over IPv6. Work is currently in progress to enumerate the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter attribute-value pairs to be used for that purpose.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 24, 2014.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Description of the Parameters Required By Each Transition Method
• 2.1. Parameters For Dual-Stack Lite
• 2.2. Public IPv4 Over IPv6
• 2.3. Light Weight IPv4 Over IPv6 (LW4o6)
• 2.4. Mapping of Address and Port with Encapsulation (MAP-E)
• 2.5. Summing Up
• 3. Attribute-Value Pair Definitions
• 3.1. DS-Lite Attributes
• 3.1.1. ASM-Prefix64
• 3.1.2. SSM-Prefix64
• 3.1.3. Unicast-Prefix64
• 3.2. Public Unshared IPv4 Address
• 3.3. Light-Weight 4over6 Attributes
• 3.4. MAP-E Attributes
• 3.5. Mapping Rule
• 3.5.1. EA Field Length
• 3.5.2. PSID Offset
• 3.6. Border Router IPv6 Address
• 3.7. IPv4 Prefix or Address
• 3.8. IPv6 Prefix or Address
• 3.9. Port Set Identifier
• 3.10. Mesh Or Hub And Spoke
• 4. Acknowledgements
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

A number of transition technologies have been or are being defined to allow IPv4 packets to pass between hosts and IPv4 networks over an intervening IPv6 network while minimizing the number of public IPv4 addresses that need to be consumed by the hosts. Different operators will deploy different technologies, and sometimes one operator will use more than one technology, depending on what is supported by the available equipment and upon other factors both technical and economic.

Each technique requires the provisioning of some subscriber-specific information on the customer edge device. The provisioning may be by DHCP or by some other method. This document is indifferent to the specific provisioning technique used, but assumes that the information originates in the AAA infrastructure because in some networks, the user configuration information may be managed by AAA (Authentication, Authorization, and Accounting) servers. In a fixed line broadband network, the Broadband Network Gateways (BNGs) act as the access gateway of users. When the BR and BNG are co-located in one device, the approach defined in [I-D.ietf-softwire-map-radius] could be used to acquire the subscriber-specific information via RADIUS. In some deployments when the location of the BR is higher than BNG, the subscriber-specific information will be pushed from AAA server to the BR actively via Diameter [RFC6733]. To allow the information to be carried in Diameter , this document specifies a number of attribute-value pairs (AVPs) for the purpose.

This document takes as its scope the set of transition methods provided for by [I-D.ietf-softwire-unified-cpe]. That document enumerates the information that must be provisioned in the customer edge router to support Dual-Stack Lite [RFC6333], Public IPv4 Over IPv6 [I-D.ietf-softwire-public-4over6], Light Weight IPv4 Over IPv6 (LW4o6) [I-D.ietf-softwire-lw4over6], and Mapping of Address and Port with Encapsulation (MAP-E) [I-D.ietf-softwire-map].

Several documents provide related specifications for RADIUS [RFC2865], for individual transition methods. Potentially there could be a reconciliation between the contents of those documents and the present one, but that has not been done in the present version of this document.

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 RFC 2119 [RFC2119].

2. Description of the Parameters Required By Each Transition Method

This section reviews the parameters that need to be provisioned for each of the transition methods listed above. This enumeration provides the justification for the AVPs defined in the next section. Since most of the transition methods dealt with here are works in progress, this section is subject to modification in future versions.

A means is required to indicate which transition method(s) a given subscriber is allowed to use. [I-D.ietf-softwire-unified-cpe] specifies how to infer the intended method from other DHCP parameters received. The approach taken in this document is to specify grouped AVPs specific to the individual transition methods. The operator can control which transition method a given subscriber uses by ensuring that AAA passes only the grouped AVP relevant to that method.

2.1. Parameters For Dual-Stack Lite

Dual-Stack Lite is documented in [RFC6333]. It requires the following parameters to be provisioned at the B4 at the customer premises. This enumeration does not include the normal provisioning of an IPv6 prefix to the customer equipment. The section numbers shown are where these requirements are indicated in [RFC6333].

• IPv6 address of the border router (AFTR) (sec. 5.4);
• IPv6 address of a DNS recursive server (sec. 5.5). This is probably supplied already independently of transition technology, so does not have to be covered here.
• optionally, the IPv4 address of the B4 interface facing the tunnel, where the default value in the absence of provisioning is 192.0.0.2 and valid values are 192.0.0.2 through 192.0.0.7 (sec. 5.7). Provisioning this information through AAA is problematic because it is most likely used in a case where multiple B4 instances occupy the same device. This document therefore assumes that the B4 interface address is determined by other means (implementation- dependent or static assignment).

2.2. Public IPv4 Over IPv6

Public IPv4 Over IPv6 is described in [I-D.ietf-softwire-public-4over6]. Besides the usual IPv6 prefix or address information, it requires two parameters to be provisioned to the customer equipment:

• a public IPv4 address;
• IPv6 address of the border router

It also requires per-subscriber provisioning on the border router:

• binding between the customer IPv4 address and the customer IPv6 prefix, for routing of incoming packets to the correct tunnel.

2.3. Light Weight IPv4 Over IPv6 (LW4o6)

Light Weight IPv4 Over IPv6 (LW4o6) is documented in [I-D.ietf-softwire-lw4over6]. Its provisioning requirements are exactly the same as those for Public 4over6 with one addition:

• both the customer equipment and the border router are provided with a port set identifier identifying the set of ports to which the subscriber's incoming and outgoing packets on the public side are restricted. The port selection algorithm and port set identifier as such are not discussed in the draft. For the present version of this document, it is assumed that the algorithm is known in advance and the port set identifier has the form of an index ranging from zero to the number of subscribers sharing a given address less 1. This is similar to the port set identifier in MAP-E, described next.

2.4. Mapping of Address and Port with Encapsulation (MAP-E)

Mapping of Address and Port with Encapsulation (MAP-E) is described in [I-D.ietf-softwire-map]. MAP-E requires the provisioning of the following per-subscriber information at the customer edge device:

• whether the device is to operate in mesh or hub-and-spoke mode;
• the IPv6 address of one or more border routers;
• the specially constructed End-user IPv6 prefix for the customer edge device. [I-D.ietf-softwire-map] suggests that this would be supplied as part of normal IPv6 provisioning, so it can be ignored as a requirement here.
• the Basic Mapping Rule for the customer edge device. This includes the following parameters:
  • the rule IPv6 prefix and length;
  • the rule IPv4 prefix and length;
  • the number of "Extended Address" (EA) bits included in the End-user IPv6 prefix;
  • of those Extended Address bits, the number that precede the port set identifier. The default value is 6.

• in mesh mode only, zero or more Forwarding Mapping Rules, containing the same parameters as the Basic Mapping rule.
• optionally, the port set identifier if the EA bits do not carry it.

The border router needs to be configured with the superset of the Forwarding MAP Rules passed to the customer sites it serves. Since this is not subscriber-specific, even though it introduces no new requirements to this document, it is out of scope.

2.5. Summing Up

It appears that the following items are common to two or more methods and the corresponding AVPs to carry them can be reused:

• the IPv6 address of the border router;
• an IPv4 prefix and length (could be a /32);
• a port set identifier.

The remaining requirements are method-specific:

• for Public 4over6 and LW4o6, a binding between a customer IPv6 prefix or address and an IPv4 address;
• for MAP-E, the indication of whether mesh mode or hub-and-spoke mode is to be used;
• for MAP-E, a Grouped AVP expressing a MAP Rule.

3. Attribute-Value Pair Definitions

This section provides the specifications for the AVPs needed to meet the requirements summarized in Section 2.5. Within the context of their usage, all of these AVPs MUST have the M bit set and the V bit cleared.

3.1. DS-Lite Attributes

The DS-Lite-Attributes AVP is of type Grouped. It contains the IPv6 address of the AFTR and optionally the multicast-related prefixes needed for providing native IPv4 multicast over IPv6 using DS-Lite, as specified in [I-D.softwire-dslite-multicast].

                 DS-Lite-Attributes  ::= < AVP Header: TBD01 >
                          { Border-Router-IPv6-Address }
                       0*1[ ASM-Prefix64 ]
                       0*1[ SSM-Prefix64 ]
                       0*1[ Unicast-Prefix64 ]
                         *[ AVP ]
          

                 Light-Weight-4over6-Attributes  ::= < AVP Header: TBD06 >
                          { Border-Router-IPv6-Address }
                       0*1[ IPv6-Prefix-Or-Addr ]
                       0*1[ Port-Set-Identifier ]
                         *[ AVP ]
          

                 MAP-E-Attributes  ::= < AVP Header: TBD07 >
                        1*{ Border-Router-IPv6-Address }
                          { Mesh-Or-Hub-And-Spoke }
                       0*1[ IPv6-Prefix-Or-Addr ]
                        1*{ Mapping-Rule }
                         *[ AVP ]
          

         Mapping-Rule  ::= < AVP Header: TBD08 >
                          { IPv4-Prefix-Or-Addr }
                          { IPv6-Prefix-Or-Addr }
                          { EA-Field-Length     }
                          [ PSID-Offset         ]
                         *[ AVP ]