Unified IPv4-in-IPv6 Softwire CPE
draft-bfmk-softwire-unified-cpe-02

Abstract

Transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. 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 describes a specification 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 July 22, 2013.

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. Rationale
• 2. IPv4 Service Continuity Architectures: A 'Big Picture' Overview
• 2.1. Functional Elements
• 2.2. Required Provisoning Information
• 3. Unified Softwire CPE Behaviour
• 3.1. IPv4 Address Functional Requirements
• 3.2. Generic CPE Bootstrapping Logic
• 3.3. Customer Side DHCP Based Provisioning
• 3.4. Forwarding Action by the Customer End-Node
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.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. These approaches, or modes, exist in order to meet the particular deployment, scaling, addressing and other requirements of different service provider's networks. Section 2 of this document describes these approaches in more detail.

A common feature shared between all of the differing modes is the integration of softwire tunnel end-point functionality into the 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 mode enabled in order to support diverse CPE client functionality, during migration between modes 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.

This memo describes the logic required by both the CPE tunnel end-node and the service provider's provisioning infrastructure so that softwire services can be provided in mixed-mode environments.

1.1. Rationale

The following rationale has been adopted for this document:

(1)

Describe the functionality of each the different solution modes and provide clear distinctions between them

(2)

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

(3)

Deterministic CPE co-existence behavior: Specify the behavior when several modes co-exist in the CPE

(4)

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

(5)

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

(6)

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

(7)

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

(8)

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

2. IPv4 Service Continuity Architectures: A 'Big Picture' Overview

The solutions which have been proposed within the Softwire WG can be categorized into three main functional approaches, differentiated by the amount and type of state that the service provider needs to maintain within their network:

(1)

Full stateful approach (DS-Lite, [RFC6333]): Requires per-session state to be maintained in the Service Provider's network.

(2)

Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite][I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network.

(3)

Full stateless approach (MAP, [I-D.ietf-softwire-map]): Does not require per-session or per-subscriber state to be maintained in the Service Provider's network.

[RFC2473].

Several cases can be envisaged:

1. The CPE is complied to support only one mode: No issue is raised by this case.
2. The CPE supports several modes but only one mode is explicitly configured: No issue is raised by this case.
3. The CPE supports several modes but no mode is explicitly enabled: the CPE will need additional triggers to decide which mode to activate.
4. The CPE supports several modes and several modes are configured: the CPE will need additional triggers to decide which mode to activate.

As this document describes a provisioning profile whereby a single CPE could be capable of supporting any, or multiple modes, the customer should not be required to have any knowledge of the capabilities and configuration of their CPE, or of their service provider's network.

The service provider, however, may have only a single mode enabled, or may have multiple modes, but with one preferred mode. For this reason, it is necessary to approach the configuration of CPEs from the standpoint of the service provider's network capabilities.

2.1. Functional Elements

The functional elements for each of the solution modes are listed in Table 1:

  Note: Required provisioning information for each mode may also
        be represented as follows:
  DS-Lite: - Remote IPv4-in-IPv6 Tunnel Endpoint
    Lw4o6: - DS-Lite set of provisioning information
           - IPv4 address
           - Port set
    MAP-E: - Lw4o6 set of provisioning information
           - Forwarding mapping rules