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

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 January 22, 2015.

Copyright Notice

Copyright (c) 2014 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. Light Weight IPv4 Over IPv6 (LW4over6)
• 2.3. Mapping of Address and Port with Encapsulation (MAP-E)
• 2.4. Summary and Discussion
• 3. Derived AVP Data Formats: AddressOrPrefix
• 4. Attribute-Value Pair Definitions
• 4.1. Border-Router-Name AVP
• 4.2. Tunnel-Source-Pref-Or-Addr AVP
• 4.3. Port-Set-Identifier
• 4.4. LW4over6-Binding
• 4.5. MAP-E-Attributes
• 4.6. MAP-Mapping-Rule
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.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 a deployment in which that information is managed by AAA (Authentication, Authorization, and Accounting) servers. It further assumes that this information is delivered to intermediate network nodes for onward provisioning using the Diameter protocol [RFC6733].

As described below, in the particular case where the Light Weight IPv4 Over IPv6 (LW4o6) [I-D.ietf-softwire-lw4over6] transition method has been deployed, per-subscriber-site information almost identical to that passed to the subscriber site [I-D.ietf-softwire-map-dhcp] or collected from it [I-D.fsc-softwire-dhcp4o6-saddr-opt] also needs to be delivered to the border router serving that site. The Diameter protocol may be used for this purpose too.

This document analyzes the information required to configure the customer edge equipment for the following set of transition methods:

• Dual-Stack Lite [RFC6333],
• Light Weight IPv4 Over IPv6 (LW4over6) [I-D.ietf-softwire-lw4over6], and
• Mapping of Address and Port with Encapsulation (MAP-E) [I-D.ietf-softwire-map].

On the basis of that analysis it specifies a number of attribute-value pairs (AVPs) to allow the necessary subscriber-site-specific configuration information to be carried in Diameter.

This document is intended to be complementary to documents such as [RFC6519], [I-D.sun-softwire-lw4over6-radext], and [I-D.ietf-softwire-map-radius] which provide RADIUS attributes to carry similar configuration information for the respective transition methods. Reconciliation of the present document with these other documents is a work in progress.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

The abbreviation "CE" denotes the equipment at the customer edge that terminates the customer end of an IPv6 transitional tunnel. This will usually be a router, but could be a host directly connected to the network.

The term "tunnel source address" is used to denote the IPv6 source address used in the outer header of packets sent from the CE through an LW4over6 transitional tunnel to the border router.

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 two of the three 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. The approach taken in this document is to specify grouped AVPs specific to LW4over6 and MAP-E. The operator can control which of these two transition methods a given subscriber uses by ensuring that AAA passes only the grouped AVP relevant to that method. A grouped AVP is unnecessary for Dual-Stack Lite, since (as the next section indicates) AAA has to provide only one parameter. Hence the absence of either of the grouped AVPs indicates that the subscriber equipment will use Dual-Stack Lite.

2.1. Parameters For Dual-Stack Lite

Dual-Stack Lite is documented in [RFC6333]. The Basic Bridging BroadBand (B4) element at the customer premises needs to be provisioned with the IPv6 address of the AFTR (border router). Optionally, it could also be configured with 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. 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. Light Weight IPv4 Over IPv6 (LW4over6)

Light Weight IPv4 Over IPv6 (LW4over6) is documented in [I-D.ietf-softwire-lw4over6]. LW4over6 requires four parameters to be provisioned to the customer equipment:

• IPv6 address of the border router.
• IPv6 prefix used by the CE to construct the tunnel source address. In the terminology of [I-D.ietf-softwire-lw4over6], this is the IPv6 Binding Prefix.
• an IPv4 address to be used on the external side of the CE; and
• if the IPv4 address is shared, a specification of the port set the subscriber site is allowed to use.

As discussed in Section 4 of [I-D.ietf-softwire-lw4over6], it is necessary to synchronize this configuration with corresponding per-subscriber configuration at the border router. The border router information consists of the same public IPv4 address and port set parameters that are passed to the CE, bound together with the full /128 IPv6 address (not just the Binding Prefix) configured as the tunnel source address at the CE.

[I-D.fsc-softwire-dhcp4o6-saddr-opt] proposes a means whereby a DHCPv6 server can influence the choice of this address and collect it from the CE. Depending on the provisioning architecture deployed in a given network, it is possible that the tunnel source address is passed to AAA as an intermediate step before the binding information is passed on to the border router.

2.3. 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:

• the IPv6 address of one or more border routers;
• the unique End-user IPv6 prefix for the customer edge device;
• 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.
  • optionally, a specification of the port set the subscriber site is allowed to use if the EA bits do not convey it (final case of Section 5.2 of the MAP-E document).

• whether the device is to operate in mesh or hub-and-spoke mode;
• in mesh mode only, zero or more Forwarding Mapping Rules, described by the same set of parameters as the Basic Mapping Rule;

As indicated in Section 5, bullet 1 of the MAP-E document, a MAP CE can be provisioned with multiple End-user IPv6 prefixes, each associated with its own Basic Mapping Rule. This does not change the basic requirement for representation of the corresponding information in the form of Diameter AVPs, but adds a potential requirement for multiple instances of both types of AVP to be present.

The border router needs to be configured with the superset of the Mapping Rules passed to the customer sites it serves. Since this requirement does not require direct coordination with CE configuration in the way LW4over6 does, it is out of scope of the present document.

2.4. Summary and Discussion

It appears that one item is common to the different transition methods and the corresponding AVP to carry it can be reused:

• a representation of the IPv6 address of a border router;

[RFC6519] sets a precedent for representation of the IPv6 address of a border router as an FQDN. This can be dereferenced to one or more IP addresses by the provisioning system before being passed to the customer equipment, or left as an FQDN as it is in [RFC6334].

The remaining requirements are transition-method-specific:

• for LW4over6, a representation of a binding between either the IPv6 Binding Prefix or a full /128 IPv6 address, a public IPv4 address, and a port set identifier;
• for MAP-E, a representation of a Mapping Rule;
• for MAP-E, an indication of whether mesh mode or hub-and-spoke mode is to be used.

3. Derived AVP Data Formats: AddressOrPrefix

The above requirements involve IP addresses and prefixes in a number of contexts. To simplify specification of these attributes, this section defines a new derived AVP data format, AddressOrPrefix, according to the rules given in Section 4.3 of [RFC6733].

AddressOrPrefix

• The AddressOrPrefix data format is an extension of the Address data format defined in Section 4.3.1 of [RFC6733]. Like the Address data format, it is derived from the OctetString basic AVP format. As well as an AddressType, it contains a PrefixLength field. The detailed specification is as follows:
  • As with the Address AVP, the first two octets represent the AddressType, which contains an Address Family, defined in [IANAADFAM].
  • The next two octets are interpreted as a 16-bit unsigned integer representing the PrefixLength. Valid values of PrefixLength are from 0 to 32 for IPv4 and from 0 to 128 for IPv6. The value 0 is included in each range to allow for presentation of a "null prefix", the meaning of which must be defined by applications that use AVPs based on the AddressOrPrefix data format.
  • The remaining octets present the prefix or address, most significant octet first. If the prefix does not extend to an octet boundary, the low-order bits of the final octet are padded with zeroes.

4. Attribute-Value Pair Definitions

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

4.1. Border-Router-Name AVP

Following on the precedent set by [RFC6334] and [RFC6519], this document identifies a border router using an FQDN rather than an address. The Border-Router-Name AVP (AVP Code TBD01) is of type OctetString. The rules for encoding the FQDN are the same as those for the FQDN variant of the derived type DiameterIdentity (Section 4.3.1 of [RFC6733]).

4.2. Tunnel-Source-Pref-Or-Addr AVP

The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) is of type AddressOrPrefix. It conveys either a prefix or a full address that is configured as the tunnel source address on the CE. Within the scope of application of this document it is intended for use to convey the LW4over6 Binding Prefix from AAA to the provisioning system or to carry a full IPv6 tunnel source address that has been collected from the CE, either from the provisioning system to AAA or from AAA to the border router. This AVP is defined separately from the LW4over6-Binding AVP (which includes it) to provide flexibility in the transport of the tunnel source address from the provisioning system to AAA.

The Tunnel-Endpoint-Pref-Or-Addr AVP

4.3. Port-Set-Identifier

The Port-Set-Identifier AVP (AVP Code TBD03) is a structured OctetString with four octets of data, hence a total AVP length of 12. The description of the structure which follows refers to quantities illustrated in Figure 9, Appendix B of [I-D.ietf-softwire-map]. The derivation of port numbers from these parameters is described in that appendix.

• The first (high-order) octet is the Offset field. It is interpreted as an 8-bit unsigned integer giving the offset 'a' from the beginning of a port number to the beginning of the port set identifier (PSID) to which that port belongs. Valid values are from 0 to 15.
• The next octet, the PSIDLength, is also interpreted as an 8-bit unsigned integer and gives the length in bits of the port set identifier (PSID). This corresponds to the value 'k' in the figure referred to above. Valid values are from 1 to (16 - a).
• The final two octets constitute the PSIDValue field and are interpreted as a 16-bit unsigned integer. They give the value of the PSID itself, right-justified within the field. That is, the value of the PSID occupies the 'k' lowest-order bits of the PSIDValue field.

4.4. LW4over6-Binding

The LW4over6-Binding AVP (AVP Code TBD04) is of type Grouped. It contains the elements of configuration that constitute the binding between an LW4over6 tunnel and IPv4 packets sent through that tunnel.

                 LW4over6-Binding  ::= < AVP Header: TBD04 >
                          { Tunnel-Source-Pref-Or-Addr }
                          { LW4over6-External-IPv4-Addr }
                          [ Port-Set-Identifier ]
                         *[ AVP ]
          

                 MAP-E-Attributes  ::= < AVP Header: TBD06 >
                        1*{ Border-Router-Name }
                        1*{ MAP-Mapping-Rule }
                          [ MAP-Mesh-Mode ]
                          [ MAP-End-User-IPv6-Prefix ]
                         *[ AVP ]
          

         MAP-Mapping-Rule  ::= < AVP Header: TBD09 >
                          { Rule-IPv4-Addr-Or-Prefix }
                          { Rule-IPv6-Prefix    }
                          { EA-Field-Length     }
                          [ Port-Set-Identifier ]
                         *[ AVP ]