Internet DRAFT - draft-ietf-softwire-unified-cpe
draft-ietf-softwire-unified-cpe
Softwire WG M. Boucadair
Internet-Draft Orange
Intended status: Standards Track I. Farrer
Expires: October 23, 2016 Deutsche Telekom
April 21, 2016
Unified IPv4-in-IPv6 Softwire CPE
draft-ietf-softwire-unified-cpe-04
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
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 October 23, 2016.
Boucadair & Farrer Expires October 23, 2016 [Page 1]
Internet-Draft Generic v4inv6 CPE Provisioning Profile April 2016
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. S46 Priority Option . . . . . . . . . . . . . . . . . . . 4
1.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 5
1.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6
1.5. S46 Mechanisms and their Identifying Option Codes . . . . 6
2. Operator Deployment Considerations for Deploying Multiple
Sotfwire Mechanisms . . . . . . . . . . . . . . . . . . . . . 6
2.1. Client Address Planning . . . . . . . . . . . . . . . . . 6
2.2. Backwards Compatability with Existing Softwire Clients . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 CPE
router. Due to this inherent data plane similarity, a single CPE may
Boucadair & Farrer Expires October 23, 2016 [Page 2]
Internet-Draft Generic v4inv6 CPE Provisioning Profile April 2016
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 prioritisation 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 prioritisation 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. Rationale
The following rationale has been adopted for this document:
Boucadair & Farrer Expires October 23, 2016 [Page 3]
Internet-Draft Generic v4inv6 CPE Provisioning Profile April 2016
(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.2. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: S46 Priority Option
o option-code: OPTION_V6_S46_PRIORITY (TBD)
o option-length: variable-length
o s46-option-code: 16-bits long IANA registered option code of the
DHCPv6 option which is used to identify the softwire mechanism.
S46 mechanism are prioritized in the appearance order in the 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.
Boucadair & Farrer Expires October 23, 2016 [Page 4]
Internet-Draft Generic v4inv6 CPE Provisioning Profile April 2016
1.3. Client Behavior
Clients MAY request option OPTION_V6_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_V6_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_V6_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 SHOULD configure the resulting
S46 mechanism. Configuration for other S46 mechanisms MUST be
discarded.
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.
In the event that the client receives OPTION_V6_S46_PRIORITY with the
following errors, it MUST be discarded:
o No s46-option-code field is included.
o Multiple s46-option-code fields with the same value are included.
If an invalid OPTION_V6_S46_PRIORITY option is received, the client
MAY proceed with configuring the provisioned S46 mechanisms as if
OPTION_V6_S46_PRIORITY had not been received.
In the event that a client receives an OPTION_V6_S46_PRIORITY option
containing a value in s46-option-code representing an S46 mechanism
which the client has not implemented, this is not considered an
error.
Boucadair & Farrer Expires October 23, 2016 [Page 5]
Internet-Draft Generic v4inv6 CPE Provisioning Profile April 2016
1.4. 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 option foo only if configured
with specific values for foo and if the client requested it.
Option OPTION_V6_S46_PRIORITY is a singleton. Servers MUST NOT send
more than one instance of the OPTION_V6_S46_PRIORITY option.
1.5. S46 Mechanisms and their Identifying Option Codes
The following table shows the currently defined option codes and the
S46 mechanisms which they represent. This list is complete at the
time of writing, but should not be considered definitive as new S46
mechanisms may be defined in the future.
+-------------+--------------------+-----------+
| 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] |
+-------------+--------------------+-----------+
Table 1: DHCPv6 Option to S46 Mechanism Mappings
2. Operator Deployment Considerations for Deploying Multiple Sotfwire
Mechanisms
The following sub-sections describe some considerations for operators
who are planning on implementing multiple sofwire 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
BR/AFTR instance which is actively serving a given CE. For example,
a client which is configured to use MAP-E may send it's 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.
Boucadair & Farrer Expires October 23, 2016 [Page 6]
Internet-Draft Generic v4inv6 CPE Provisioning Profile April 2016
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 mutliple softwire mechanisms, but
do not implement the prioritisation 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 ORO message, but would not request OPTION_V6_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 complextity 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:
TBD for OPTION_V6_S46_PRIORITY
All values should be added to the DHCPv6 option code space defined in
Section 24.3 of [RFC3315].
Boucadair & Farrer Expires October 23, 2016 [Page 7]
Internet-Draft Generic v4inv6 CPE Provisioning Profile April 2016
5. Acknowledgements
Many thanks to O. Troan, S. Barth. A. Yourtchenko, B. Volz, T.
Mrugalski 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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., 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, <http://www.rfc-editor.org/info/rfc3315>.
[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,
<http://www.rfc-editor.org/info/rfc6334>.
[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,
<http://www.rfc-editor.org/info/rfc7341>.
[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,
<http://www.rfc-editor.org/info/rfc7598>.
6.2. Informative References
[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,
<http://www.rfc-editor.org/info/rfc6333>.
[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, <http://www.rfc-editor.org/info/rfc7596>.
Boucadair & Farrer Expires October 23, 2016 [Page 8]
Internet-Draft Generic v4inv6 CPE Provisioning Profile April 2016
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <http://www.rfc-editor.org/info/rfc7599>.
Authors' Addresses
Mohamed Boucadair
Orange
Rennes
France
Email: mohamed.boucadair@orange.com
Ian Farrer
Deutsche Telekom
Germany
Email: ian.farrer@telekom.de
Boucadair & Farrer Expires October 23, 2016 [Page 9]
