One document matched: draft-ietf-softwire-unified-cpe-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes"?>
<rfc category="std" docName="draft-ietf-softwire-unified-cpe-01"
ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Generic v4 in v6 CPE Provisioning Profile">Unified
IPv4-in-IPv6 Softwire CPE</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street/>
<city>Rennes</city>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Ian Farrer" initials="I." surname="Farrer">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street/>
<city/>
<country>Germany</country>
</postal>
<email>ian.farrer@telekom.de</email>
</address>
</author>
<author fullname="Simon Perreault" initials="S." surname="Perreault" role="editor">
<organization>Viagenie</organization>
<address>
<postal>
<street>246 Aberdeen</street>
<city>Quebec QC G1R 2E1</city>
<region></region>
<country>Canada</country>
</postal>
<email>simon.perreault@viagenie.ca</email>
</address>
</author>
<author fullname="Senthil Sivakumar" initials="S." surname="Sivakumar" role="editor">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7100-8 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>North Carolina</region>
<country>USA</country>
</postal>
<email>ssenthil@cisco.com</email>
</address>
</author>
<date day="24" month="May" year="2013"/>
<area>Internet</area>
<workgroup>Softwire WG</workgroup>
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<!-- ***** MIDDLE MATTER ***** -->
<middle>
<section title="Introduction">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section title="Rationale">
<t>The following rationale has been adopted for this document:</t>
<t><list style="format (%d)">
<t>Describe the functionality of each the different solution modes
and provide clear distinctions between them</t>
<t>Simplify solution migration paths: Define unified CPE behavior,
allowing for smooth migration between the different modes</t>
<t>Deterministic CPE co-existence behavior: Specify the behavior
when several modes co-exist in the CPE</t>
<t>Deterministic service provider co-existence behavior: Specify
the behavior when several modes co-exist in the service providers
network</t>
<t>Re-usability: Maximize the re-use of existing functional blocks
including tunnel end-points, port restricted NAPT44, forwarding
behavior, etc.</t>
<t>Solution agnostic: Adopt neutral terminology and avoid (as far
as possible) overloading the document with solution-specific
terms</t>
<t>Flexibility: Allow operators to compile CPE software only for
the mode(s) necessary for their chosen deployment context(s)</t>
<t>Simplicity: Provide a model that allows operators to only
implement the specific mode(s) that they require without the
additional complexity of unneeded modes.</t>
</list></t>
</section>
</section>
<section title="IPv4 Service Continuity Architectures: A 'Big Picture' Overview">
<t>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:<?rfc subcompact="yes" ?><list style="format (%d)">
<t>Full stateful approach (DS-Lite, <xref target="RFC6333"/>):
Requires per-session state to be maintained in the Service
Provider's network.</t>
<t>Binding approach (e.g., Lightweight 4over6 (Lw4o6) <xref
target="I-D.ietf-softwire-lw4over6"/><xref
target="I-D.ietf-softwire-public-4over6"/> or MAP 1:1 <xref
target="I-D.ietf-softwire-map"/> ): Requires a single per-subscriber
state (or a few) to be maintained in the Service Provider's
network.</t>
<t>Full stateless approach (MAP, <xref
target="I-D.ietf-softwire-map"/>): Does not require per-session or
per-subscriber state to be maintained in the Service Provider's
network.</t>
</list></t>
<t><?rfc subcompact="no" ?>All these approaches share a similar
architecture, with a tunnel endpoint located in the CPE and a remote
tunnel endpoint. All use IPv6 as the transport protocol for the delivery
of an IPv4 connectivity service using an IPv4-in-IPv6 encapsulation
scheme <xref target="RFC2473"/>.</t>
<t>Several cases can be envisaged:<?rfc subcompact="yes" ?><list
style="numbers">
<t>The CPE is complied to support only one mode: No issue is raised
by this case.</t>
<t>The CPE supports several modes but only one mode is explicitly
configured: No issue is raised by this case.</t>
<t>The CPE supports several modes but no mode is explicitly enabled:
the CPE will need additional triggers to decide which mode to
activate.</t>
<t>The CPE supports several modes and several modes are configured:
the CPE will need additional triggers to decide which mode to
activate.</t>
</list></t>
<t><?rfc subcompact="no" ?></t>
<t>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.</t>
<t>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.</t>
<section title="Functional Elements">
<t>The functional elements for each of the solution modes are listed
in <xref target="functional"/>:</t>
<texttable anchor="functional" title="Functional Elements">
<ttcol align="right">Mode</ttcol>
<ttcol align="center">Customer side</ttcol>
<ttcol align="center">Network side</ttcol>
<c>DS-Lite</c>
<c>B4</c>
<c>AFTR</c>
<c>Lw4o6</c>
<c>lwB4</c>
<c>lwAFTR</c>
<c>MAP</c>
<c>MAP CE</c>
<c>MAP BR</c>
</texttable>
<t><xref target="description"/> describes each functional element:</t>
<texttable anchor="description" title="Required Element Functionality">
<ttcol align="right">Functional Element</ttcol>
<ttcol>Description</ttcol>
<c>B4</c>
<c>An IPv4-in-IPv6 tunnel endpoint; the B4 creates a tunnel to a
pre-configured remote tunnel endpoint.</c>
<c>AFTR</c>
<c>Provides both an IPv4-in-IPv6 tunnel endpoint and a NAT44
function implemented in the same node.</c>
<c>lwB4</c>
<c>A B4 which supports port-restricted IPv4 addresses. An lwB4 MAY
also provide a NAT44 function.</c>
<c>lwAFTR</c>
<c>An IPv4-in-IPv6 tunnel endpoint which maintains per-subscriber
address binding. Unlike the AFTR, it MUST NOT perform a NAPT44
function.</c>
<c>MAP CE</c>
<c>A B4 which supports port-restricted IPv4 addresses. It MAY be
co-located with a NAT44. A MAP CE forwards IPv4-in-IPv6 packets
using provisioned mapping rules to derive the remote tunnel
endpoint.</c>
<c>MAP BR</c>
<c>An IPv4-in-IPv6 tunnel endpoint. A MAP BR forwards IPv4-in-IPv6
packets following pre-configured mapping rules.</c>
</texttable>
<t><vspace blankLines="5"/></t>
<t><xref target="common"/> identifies features required by the
customer end-node.</t>
<texttable anchor="common" style="all" title="Supported Features">
<ttcol align="right">Functional Element</ttcol>
<ttcol align="center">IPv4-in-IPv6 tunnel endpoint</ttcol>
<ttcol align="center">Port-restricted IPv4</ttcol>
<ttcol align="center">Port-restricted NAT44</ttcol>
<c>B4</c>
<c>Yes</c>
<c>N/A</c>
<c>No</c>
<c>lwB4</c>
<c>Yes</c>
<c>Yes</c>
<c>Optional</c>
<c>MAP-E CE</c>
<c>Yes</c>
<c>Yes</c>
<c>Optional</c>
</texttable>
<t/>
</section>
<section title="Required Provisioning Information">
<t><xref target="provisioning"/> identifies the provisioning
information required for each solution mode.</t>
<texttable anchor="provisioning" title="Provisioning Information">
<ttcol align="right">Mode</ttcol>
<ttcol>Provisioning Information</ttcol>
<c>DS-Lite</c>
<c>Remote IPv4-in-IPv6 Tunnel Endpoint Address</c>
<c>Lw4o6</c>
<c>Remote IPv4-in-IPv6 Tunnel Endpoint Address</c>
<c/>
<c>IPv4 Address</c>
<c/>
<c>Port Set</c>
<c>MAP-E</c>
<c>Mapping Rules</c>
<c/>
<c>MAP Domain Parameters</c>
</texttable>
<t>Note: MAP Mapping Rules are translated into the following
configuration parameters: Set of remote IPv4-in-IPv6 tunnel endpoint
addresses, IPv4 address and port set.</t>
<t><figure>
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="unifiedcpe" title="Unified Softwire CPE Behaviour">
<t><?rfc ?>This section specifies a unified CPE behavior capable of
supporting any one, or combination of, the three modes.</t>
<section title="IPv4 Address Functional Requirements">
<t>The following two requirements must be met by the functional
elements:</t>
<t><list style="hanging">
<t hangText="Full IPv4 Address Assignment">All the aforementioned
modes MUST be designed to allow either a full or a shared IPv4
address to be assigned to a customer end-node. DS-Lite and MAP-E
fulfil this requirement. With minor changes, the <xref
target="I-D.ietf-softwire-lw4over6"/> specification
can be updated to assign full IPv4 addresses.</t>
<t hangText="Customer End-Node NAT">A NAT function within the
customer end-node is not required for DS-Lite, while it is
optional for both MAP-E and Lw4o6. When NAT is enabled for MAP-E
or Lw4o6, the customer end-node NAT MUST be able to restrict the
external translated source ports to the set of ports that it has
been provisioned with.</t>
</list></t>
</section>
<section anchor="generic" title="Generic CPE Bootstrapping Logic">
<t>The generic provisioning logic is designed to meet the following
requirements:<list style="symbols">
<t>When several service continuity modes are supported by the same
CPE, it MUST be possible to configure a single mode for use.</t>
<t>For each network attachment, the end-node MUST NOT activate
more than one mode.</t>
<t>The CPE MAY be configured by a user or via remote device
management means (e.g., DHCP, TR-069).</t>
<t>A network which supports one or several modes MUST return valid
configuration data enabling requesting devices to unambiguously
select a single mode to use for attachment.</t>
<t>A CPE which supports only one mode or it is configured to
enable only mode MUST ignore any configuration parameter which is
not required for the mode it supports.</t>
</list></t>
<t>This section sketches a generic algorithm to be followed by a CPE
supporting one or more of the modes listed above. Based on the
retrieved information, the CPE will determine which mode to
activate.</t>
<t><list style="format (%d)">
<t>If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE
MUST be configured with the required provisioning information
listed in <xref target="provisioning"/>. If all of the required
information is not available locally, the CPE MUST use available
provisioning means (e.g., DHCP) to retrieve the missing
configuration data.</t>
<t>If the CPE supports several modes, but no mode is explicitly
enabled, the CPE MUST use available provisioning means (e.g.,
DHCP) to retrieve available configuration parameters and use the
availability of individual parameters to ascertain which
functional mode to configure:<list style="format (2.%d)">
<t>If only a Remote IPv4-in-IPv6 Tunnel Endpoint is received,
the CPE MUST proceed as follows:<?rfc subcompact="yes"?><list
style="format (2.1.%d)">
<t>IPv4-in-IPv6 tunnel endpoint initialization is defined
in <xref target="RFC6333"/>.</t>
<t>Outbound IPv4 packets are forwarded to the next hop as
specified in <xref target="forwarding"/>.<?rfc subcompact="no" ?></t>
</list></t>
<t>If a Remote IPv4-in-IPv6 Tunnel Endpoint, an IPv4 Address
and optionally a Port Set are received, the CPE MUST behave as
follows:<?rfc subcompact="yes" ?><list style="format (2.2.%d)">
<t>IPv4-in-IPv6 tunnel endpoint initialization is similar
to the B4 <xref target="RFC6333"/>.</t>
<t>When NAPT44 is required (e.g., because the CPE is a
router), a NAPT44 module is enabled.</t>
<t>The tunnel endpoint address is selected from the native
IPv6 addresses configured on the CPE. No particular
considerations are required to be taken into account to
generate the Interface Identifier.</t>
<t>When a port set is provisioned, the external source
ports MUST be restricted to the provisioned set of
ports.</t>
<t>After translation, outbound IPv4 packets are forwarded
to the next hop as specified in <xref
target="forwarding"/>.<?rfc subcompact="no" ?></t>
</list></t>
<t>If Mapping Rule(s) are received, the CPE MUST behave as
follows:<?rfc subcompact="yes" ?><list style="format (2.3.%d)">
<t>IPv4-in-IPv6 tunnel endpoint initialization is similar
to the B4 <xref target="RFC6333"/>.</t>
<t>The tunnel endpoint is assigned with an IPv6 address
which includes an IPv4 address. The MAP Interface
Identifier is based on the format specified in Section 2.2
of <xref target="RFC6052"/>.</t>
<t>When NAPT44 is required (e.g., because the CPE is a
router), a NAPT44 module is enabled.</t>
<t>When a port set is provisioned, the external source
port MUST be restricted to the provisioned set of
ports.</t>
<t>After translation, outbound IPv4 packets then forwarded
to the next hop as specified in <xref
target="forwarding"/>. <?rfc subcompact="no" ?></t>
</list></t>
</list></t>
</list></t>
</section>
<section title="Customer Side DHCP Based Provisioning">
<t><list style="empty">
<t>[DISCUSSION NOTE:<list style="numbers">
<t> This section will be updated to reflect the consensus from
DHC WG </t>
<t>As it is proposed that OPTION_MAP would be used for all new
softwire provisioning, should we rename OPTION_MAP to
OPTION_SW (incl. the associated sub-options)?]</t>
</list></t>
</list></t>
<t>This section describes how the logic is implemented using DHCPv6 to
provision the necessary parameters for Unified CPE configuration. Other
provisioning mechanisms (e.g. static, PCP etc.) may be used instead of, or
in addition to DHCPv6 to provision the CPE. DHCP-based configuration SHOULD be
implemented by the customer end-node. The following two DHCPv6
options are used:</t>
<t><list hangIndent="20" style="hanging">
<t hangText="OPTION_AFTR_NAME"><xref target="RFC6334"/> Provides
the FQDN for the remote IPv4-in-IPv6 tunnel end-point.</t>
<t hangText="OPTION_MAP"><xref
target="I-D.ietf-softwire-map-dhcp"/> Provides IPv4-related
configuration for binding mode and/or mapping rules for stateless
mode (including MAP parameters such as offset, domain prefix,
etc.).</t>
</list></t>
<t> By default, the customer end-node SHOULD support DHCPv6 MAP options to provision
IPv4-related connectivity parameters. If a dynamic port assignment scheme is
adopted, [I-D.ietf-dhc-dhcpv4-over-dhcpv6] SHOULD be supported. </t>
<t>The following additional sub-options are used to convey the different
possible configurations options for Binding Mode (using static or dynamic IPv4 addressing plus additional DHCPv6 options):</t>
<t><list hangIndent="20" style="hanging">
<t hangText="OPTION_MAP_BIND">A sub-option used to convey an IPv4
address (for example, encoded as an IPv4-mapped IPv6 address <xref
target="RFC4291"/>). This address is used when binding mode is
enabled. The receipt of OPTION_MAP_BIND is an implicit indication
to the customer side device to operate in binding, rather than
stateless mode.</t>
<t hangText="OPTION_MAP_BIND_DYN">A sub-option used to indicate
to the client that it must use the dynamic DHCPv4 over DHCPv6
process described in
<xref target="I-D.ietf-dhc-dhcpv4-over-dhcpv6"/></t>
</list>The customer end-node uses the DHCP Option Request Option
(ORO) to request either one or both of these options depending on
which modes it is capable of and configured to support.</t>
<t>The DHCP option(s) sent in the response allow the service provider
to inform the customer end-node which operating mode to enable.</t>
<t>The following table shows the different DHCP options (and
sub-options) that the service provider can supply in a response.
The CPE's interpretation of the different Binding Options parameters are
described below.</t>
<t/>
<texttable anchor="Provision" title="DHCP Option Provisioning Matrix">
<ttcol align="right">DHCP Option</ttcol>
<ttcol>Stateful Mode</ttcol>
<ttcol>Binding Mode</ttcol>
<ttcol>Stateless Mode</ttcol>
<c>OPTION_AFTR_NAME</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>Binding Option(s)</c>
<c>No</c>
<c>Yes</c>
<c>No</c>
<c>OPTION_MAP_RULE</c>
<c>No</c>
<c>No</c>
<c>Yes</c>
<c>OPTION_MAP_PORTPARAMS</c>
<c>No</c>
<c>Optional</c>
<c>Optional</c>
</texttable>
<t>The customer side device MUST interpret the received DHCP
configuration parameters according to the logic defined in <xref
target="generic"/>:</t>
<t><list style="symbols">
<t>If only OPTION_AFTR_NAME is received, then the device MUST
operate in stateful mode</t>
<t>If both OPTION_AFTR_NAME and Binding Option(s) are received then
the device MUST operate in binding mode</t>
<t>If one or more OPTION_MAP_RULE options are received, then the
customer side device MUST operate in stateless mode</t>
<t>If both OPTION_AFTR_NAME and OPTION_MAP_RULE(s) are received,
then the customer side device MUST operate as a MAP CE.
OPTION_AFTR_NAME provides the FQDN of the MAP BR.</t>
<t>If OPTION_MAP_PORTPARAMS is received as a sub-option to either
OPTION_MAP_BIND or OPTION_MAP_RULE, then NAPT44 MUST be configured
using the supplied port-set for external translated source
ports.</t>
</list></t>
<t>From the service providers side, the following rule MUST be
followed:</t>
<t><list style="symbols">
<t>The DHCP server MUST NOT send both Binding Option(s) and
OPTION_MAP_RULE in a single OPTION_MAP response.</t>
</list></t>
</section>
<section anchor="forwarding"
title="Forwarding Action by the Customer End-Node">
<t>For all modes, the longest prefix match algorithm MUST be enforced
to forward outbound IPv4 packets.</t>
<t>Specifically, this algorithm will:<?rfc ?><list style="symbols">
<t>Always return the address of the AFTR for the DS-Lite mode.</t>
<t>Always return the address of the lwAFTR for the binding
mode.</t>
<t>Return the next hop according to the pre-configured mapping
rules for the stateless mode (i.e., MAP-E).</t>
</list></t>
<t/>
</section>
</section>
<section title="Future Expansion of the Unified CPE Model">
<t>The mechanism that is described here can be extended to cater for other
IPv4 service continuity approaches, outside of those specifically
covered in this document. In order to achieve this, the following rules MUST be applied (in addition to the generic CPE bootstrapping logic described in section 3.2 above):</t>
<t>The mechanism in extended by defining a new combination of configuration parameters, unique to that mode of operation so that the CPE can unambiguously determine which service continuity mode to configure. This could be based on a new combination of existing parameters, or on new
parameters that are specific to the new continuity mode.</t>
<t>It is important to note that it is the presence, or absence of configuration parameters that are used to extend the Unified CPE model, not the value of any individual (or multiple) parameters.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Except for the less efficient port randomization and routing loops
[RFC6324], stateless 4/6 solutions are expected to introduce no more
security vulnerabilities than stateful ones. Because of their
stateless nature, they may in addition, reduce denial of service
opportunities. Security considerations defined in Section 11 of
<xref target="RFC6333"/> should be taken into account.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to T. Tsou, O. Troan, W. Dec,
M. Chen, for their review and comments.</t>
<t>Special thanks to S. Krishnan for the suggestions and guidance.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include='reference.I-D.ietf-softwire-map'?>
<?rfc include='reference.I-D.ietf-softwire-map-dhcp'?>
<?rfc include='reference.RFC.2473'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4291'?>
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.I-D.ietf-softwire-lw4over6'?>
<?rfc include='reference.RFC.6333'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6334'?>
<?rfc include='reference.I-D.ietf-softwire-public-4over6'?>
<?rfc include='reference.I-D.ietf-softwire-stateless-4v6-motivation'?>
<?rfc include='reference.I-D.ietf-dhc-dhcpv4-over-dhcpv6'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:34:44 |