Softwire WG M. Boucadair
Internet-Draft Orange
Intended status: Standards Track I. Farrer
Expires: March 17, 2017 Deutsche Telekom
September 13, 2016

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

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 March 17, 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

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:

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_S46_PRIORITY      |         option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        s46-option-code        |        s46-option-code        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              ...              |        s46-option-code        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: S46 Priority Option

Each defined s46_option_code MUST NOT appear more than once within the list of S46 option codes. The option MUST contain at least one s46-option-code.

1.4. DHCPv6 Client Behavior

Clients MAY request option OPTION_S46_PRIORITY, as defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a convenience to the reader, we mention here that the client includes requested option codes in the Option Request Option.

Upon receipt of a DHCPv6 Advertise message from the server containing OPTION_S46_PRIORITY the client performs the following steps:

  1. Check the contents of the DHCPv6 message for options containing valid S46 mechanism configuration. A candidate list of possible S46 mechanisms is created from these option codes.
  2. Check the contents of OPTION_S46_PRIORITY for the DHCPv6 option codes contained in the included s46-option-code fields. From this, an S46 mechanism priority list is created, ordered from highest to lowest following the appearance order.
  3. Sequentially check the priority list against the candidate list until a match is found.
  4. When a match is found, the client MUST configure the resulting S46 mechanism.

In the event that no match is found between the priority list and the candidate list, the client MAY proceed with configuring one or more of the provisioned S46 softwire mechanism(s). In this case, which mechanism(s) are chosen by the client is implementation-specific and not defined here.

If an invalid OPTION_S46_PRIORITY option is received, the client MAY proceed with configuring the provisioned S46 mechanisms as if OPTION_S46_PRIORITY had not been received.

If an unknown option code is received in OPTION_S46_PRIORITY option, the client MUST skip it and continue processing other listed option codes if they exist. The initial option codes that are allowed to be included in a OPTION_S46_PRIORITY option are listed in Section 4.1.

1.5. DHCPv6 Server Behavior

Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in regards to option assignment. As a convenience to the reader, we mention here that the server will send a particular option code only if configured with specific values for that option code and if the client requested it.

Option OPTION_S46_PRIORITY is a singleton. Servers MUST NOT send more than one instance of the OPTION_S46_PRIORITY option.

2. Operator Deployment Considerations for Deploying Multiple Sotfwire Mechanisms

The following sub-sections describe some considerations for operators who are planning on implementing multiple softwire mechanisms in their network (e.g., during a migration between mechanisms).

2.1. Client Address Planning

As an operator's available IPv4 resources are likely to be limited, it may be desirable to use a common range of IPv4 addresses across all of the active Softwire mechanisms. However, this is likely to result in difficulties in routing ingress IPv4 traffic to the correct Border Relay (BR)/AFTR instance which is actively serving a given CE. For example, a client which is configured to use MAP-E may send its traffic to the MAP-E BR, but on the return path, the ingress IP traffic gets routed to a MAP-T BR. The resulting translated packet that gets forwarded to the MAP-E client will be dropped.

Therefore, operators are advised to use separate IPv4 pools for each of the different mechanisms to simplify planning and IPv4 routing.

For IPv6 planning there is less of a constraint as the BR/AFTR elements for the different mechanisms can contain configuration for overlapping client's IPv6 addresses, providing only one mechanism is actively serving a given client at a time. However, the IPv6 address that is used as the tunnel concentrator's endpoint (BR/AFTR address) needs to be different for each mechanisms to ensure correct operation.

2.2. Backwards Compatability with Existing Softwire Clients

Deployed clients which can support multiple softwire mechanisms, but do not implement the prioritization mechanism described here may require additional planning. In this scenario, the CPE would request configuration for all of the supported softwire mechanisms in its DHCPv6 Option Request Option (ORO), but would not request OPTION_S46_PRIORITY. By default, the DHCPv6 server will respond with configuration for all of the requested mechanisms which could result in unpredictable and unwanted client configuration.

In this scenario, it may be necessary for the operator to implement logic within the DHCPv6 server to identify such clients and only provision them with configuration for a single softwire mechanism. It should be noted that this can lead to complexity and reduced scalability in the DHCPv6 server implementation due to the addition DHCPv6 message processing overhead.

3. Security Considerations

Security considerations discussed in [RFC6334] and [RFC7598] apply for this document.

Misbehaving intermediate nodes may alter the content of the S46 Priority Option. This may lead to setting a different IPv4 service continuity mechanism than the one initially preferred by the network side.

4. IANA Considerations

IANA is kindly requested to allocate the following DHCPv6 option code:[RFC3315].

All values should be added to the DHCPv6 option code space defined in Section 24.3 of

4.1. S46 Mechanisms and their Identifying Option Codes

This document requests that IANA create a new registry entitled "Option Codes permitted in the S46 Priority Option". This registry will enumerate the set of DHCPv6 Option Codes that can be included in OPTION_S46_PRIORITY option. Options may be added to this list using the IETF Review process described in Section 4.1 of [RFC5226].

The following table shows the option codes which are currently defined and the S46 mechanisms which they represent. The contents of this table shows the format and the initial values for the new registry. Option codes that have not been requested to be added according to the stated procedure should not be mentioned at all in the table, and should not be listed as "reserved" or "unassigned". The valid range of values for the registry is the range of DHCPv6 Option Codes (1-65535).

DHCPv6 Option to S46 Mechanism Mappings
Option Code S46 Mechanism Reference
64 DS-Lite [RFC6334]
88 DHCPv4 over DHCPv6 [RFC7341]
94 MAP-E [RFC7598]
95 MAP-T [RFC7598]
96 Lightweight 4over6 [RFC7598]

5. Acknowledgements

Many thanks to O. Troan, S. Barth. A. Yourtchenko, B. Volz, T. Mrugalski, J. Scudder, P. Kyzivat, and F. Baker for their input and suggestions.

6. References

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, DOI 10.17487/RFC6334, August 2011.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S. and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014.
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L. and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015.

6.2. Informative References

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.
[RFC6333] Durand, A., Droms, R., Woodyatt, J. and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y. and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015.
[RFC7597] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T. and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015.
[RFC7599] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S. and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015.

Authors' Addresses

Mohamed Boucadair Orange Rennes, France EMail: mohamed.boucadair@orange.com
Ian Farrer Deutsche Telekom Germany EMail: ian.farrer@telekom.de