Unified IPv4-in-IPv6 Softwire CPE
draft-ietf-softwire-unified-cpe-05

Abstract

In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services.

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

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 February 26, 2017.

Copyright Notice

Copyright (c) 2016 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. Terminology
• 1.2. Rationale
• 1.3. DHCPv6 S46 Priority Option
• 1.4. DHCPv6 Client Behavior
• 1.5. DHCPv6 Server Behavior
• 2. Operator Deployment Considerations for Deploying Multiple Sotfwire Mechanisms
• 2.1. Client Address Planning
• 2.2. Backwards Compatability with Existing Softwire Clients
• 3. Security Considerations
• 4. IANA Considerations
• 4.1. S46 Mechanisms and their Identifying Option Codes
• 5. Acknowledgements
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

IPv4 service continuity is one of the major technical challenges which must be considered during IPv6 migration. Over the past few years, a number of different approaches have been developed to assist with this problem (e.g., [RFC6333], [RFC7596], or [RFC7597]). These approaches, referred to as 'S46 mechanisms' in this document, exist in order to meet the particular deployment, scaling, addressing and other requirements of different service provider's networks.

A common feature shared between all of the differing modes is the integration of softwire tunnel end-point functionality into the Customer Premise Equipment (CPE) router. Due to this inherent data plane similarity, a single CPE may be capable of supporting several different approaches. Users may also wish to configure a specific mode of operation.

A service provider's network may also have more than one S46 mechanism enabled in order to support a diverse CPE population with differing client functionality, such as during a migration between mechanisms, or where services require specific supporting softwire architectures.

For softwire based services to be successfully established, it is essential that the customer end-node, the service provider end-node and provisioning systems are able to indicate their capabilities and preferred mode of operation.

A number of DHCPv6 options for the provisioning of softwires have been standardized:

RFC6334

Defines DHCPv6 option 64 for configuring Basic Bridging BroadBand (B4, [RFC6333]) elements with the IPv6 address of the Address Family Transition Router (AFTR, [RFC6333]).

RFC7341

Defines DHCPv6 option 88 for configuring the address of a DHCPv4 over DHCPv6 server, which can then be used by a softwire client for obtaining further configuration.

RFC7598

Defines DHCPv6 options 94, 95 and 96 for provisioning Mapping of Address and Port with Encapsulation (MAP-E, [RFC7597]), Mapping of Address and Port using Translation (MAP-T, [RFC7599]), and Lightweight 4over6 [RFC7596] respectively.

This document describes a DHCPv6 based prioritization method whereby a CPE which supports several S46 mechanisms and receives configuration for more than one can prioritise which mechanism to use. The method requires no server side logic to be implemented and only uses a simple S46 mechanism prioritization to be implemented in the CPE.

The prioritization method as described here does not provide redundancy between S46 mechanisms for the client. I.e. If the highest priority S46 mechanism which has been provisioned to the client is not available for any reason, the means for identifying this and falling back to the S46 mechanism with the next highest priority is not in the scope of this document.

1.1. Terminology

This document makes use of the following terms:

• Address Family Transition Router (AFTR): is the IPv4-in-IPv6 tunnel termination point and the NAT44 function deployed in the operator's network [RFC6333].
• Border Relay (BR): a MAP-enabled router managed by the service provider at the edge of a MAP domain. A BR has at least an IPv6-enabled interface and an IPv4 interface connected to the native IPv4 network [RFC7597].
• Customer Premise Equipment (CPE): denotes the equipment at the customer edge that terminates the customer end of an IPv6 transitional tunnel. In some documents (e.g., [RFC7597]), this functional entity is called CE (Customer Edge).

1.2. Rationale

The following rationale has been adopted for this document:

(1)

Simplify solution migration paths: Define unified CPE behavior, allowing for smooth migration between the different s46 mechanisms.

(2)

Deterministic CPE co-existence behavior: Specify the behavior when several S46 mechanisms co-exist in the CPE.

(3)

Deterministic service provider co-existence behavior: Specify the behavior when several modes co-exist in the service providers network.

(4)

Re-usability: Maximize the re-use of existing functional blocks including tunnel end-points, port restricted NAPT44, forwarding behavior, etc.

(5)

Solution agnostic: Adopt neutral terminology and avoid (as far as possible) overloading the document with solution-specific terms.

(6)

Flexibility: Allow operators to compile CPE software only for the mode(s) necessary for their chosen deployment context(s).

(7)

Simplicity: Provide a model that allows operators to only implement the specific mode(s) that they require without the additional complexity of unneeded modes.

1.3. DHCPv6 S46 Priority Option

The S46 Priority Option is used to convey a priority order of IPv4 service continuity mechanisms. Figure 1 shows the format of the S46 Priority Option.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   OPTION_V6_S46_PRIORITY      |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        s46-option-code        |         s46-option-code       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                ...            |         s46-option-code       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+