One document matched: draft-ietf-softwire-ipv6-6rd-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2516 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2516.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3056 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC3068 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml">
<!ENTITY RFC3964 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3964.xml">
<!ENTITY RFC3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
<!ENTITY RFC4213 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!ENTITY RFC3633 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY I-D.despres-6rd SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.despres-6rd.xml">
<!ENTITY RFC4861 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY I-D.durand-softwire-dual-stack-lite SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.durand-softwire-dual-stack-lite.xml">
<!ENTITY RFC2491 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2491.xml">
<!ENTITY RFC4291 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-softwire-ipv6-6rd-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only
necessary if the full title is longer than 39 characters -->
<title abbrev="6rd">IPv6 via IPv4 Service Provider Networks "6rd"</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Mark Townsley" initials="W. M." surname="Townsley">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city>Paris</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>mark@townsley.net</email>
</address>
</author>
<author fullname="Ole Troan" initials="O." surname="Troan">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city>Bergen</city>
<region></region>
<code></code>
<country>Norway</country>
</postal>
<email>ot@cisco.com</email>
</address>
</author>
<!--
<author fullname="Remi Despres" initials="R." surname="Despres">
<organization></organization>
<address>
<postal>
<street>3 rue du President Wilson</street>
<city>Levallois</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<phone>+33 6 72 74 94 88</phone>
<email>remi.despres@free.fr</email>
</address>
</author>
-->
<date month="January" year="2010" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current
year is specified, xml2rfc will fill in the current day and month for
you. If the year is not the current one, it is necessary to specify
at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally
sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc, IETF is fine for
individual submissions. If this element is not present, the default
is "Network Working Group", which is used by the RFC Editor as a nod
to the history of the IETF. -->
<keyword>6rd "Provider 6to4" IPv6 softwire "IPv6 Transition" 6to4</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document specifies an automatic tunneling mechanism
tailored to advance deployment of IPv6 to end users via a Service
Provider's IPv4 network infrastructure. Key aspects include
automatic IPv6 prefix delegation to sites, stateless operation,
simple provisioning, and service which is equivalent to native IPv6
at the sites which are served by the mechanism.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The original idea and the name of the mechanism (6rd) specified
in this document is described in <xref
target="I-D.despres-6rd">draft-despres-6rd</xref>, which details a
successful commercial "rapid deployment" of the 6rd mechanism by a
residential Service Provider and is recommended background
reading. This document describes the 6rd mechanism, extended for
use in more general environments, and intended for advancement on
the IETF Standards Track. Throughout this document, the term 6to4
is used to refer to the mechanism described in <xref
target="RFC3056"></xref> and 6rd the mechanism defined herein.</t>
<t>6rd specifies a protocol mechanism to deploy IPv6 to sites via a
Service Provider's (SP's) IPv4 network. It builds on 6to4 <xref
target="RFC3056"></xref>, with the key differentiator that it
utilizes an SP's own IPv6 address prefix rather than a well known
prefix (2002::/16). By using the SP's IPv6 prefix, the operational
domain of 6rd is limited to the SP network and under its direct
control. From the perspective of customer sites and the IPv6
Internet at large, the IPv6 service provided is equivalent to
native IPv6.</t>
<t>6rd as described in this document relies upon an algorithmic
mapping between the IPv6 and IPv4 addresses that are assigned for
use within the SP network. This mapping allows for automatic
determination of IPv4 tunnel endpoints from IPv6 prefixes, allowing
stateless operation of 6rd. 6rd views the IPv4 network as a link
layer for IPv6 and supports an automatic tunneling abstraction
similar to the Non-Broadcast Multiple Access (NBMA) model.</t>
<t>A 6rd domain consists of 6rd Customer Edge (CE) routers and one
or more 6rd BRs. IPv6 packets encapsulated by 6rd follow the IPv4
routing topology within the SP network among CEs and BRs. 6rd BRs
are traversed only for IPv6 packets that are destined to or are
arriving from outside the SP's 6rd domain. As 6rd is stateless, BRs
my be reached using anycast for failover and resiliency.</t>
<t>On the "customer-facing" (i.e., "LAN") side of a CE, IPv6 is
implemented as it would be for any native IP service delivered by
the SP. On the "SP-Facing" (i.e., "WAN") side of the 6rd CE, the
WAN interface itself, encapsulation over Ethernet, ATM or PPP, as
well as control protocols such as PPPoE, IPCP, DHCP, etc. all
remain unchanged from current IPv4 operation. Although 6rd was
designed primarily to support IPv6 deployment to a customer site
(such as a residential home network) by an SP, it can equally be
applied to an individual IPv6 host acting as a CE.</t>
<t>6rd relies on IPv4 and is designed to deliver production-quality
IPv6 alongside IPv4 with as little change to IPv4 networking and
operations as possible. Native IPv6 deployment within the SP
network itself may continue for the SP's own purposes aside of
delivering IPv6 service to sites supported by 6rd. Once the SP
network and operations can support fully native IPv6 access and
transport, 6rd may be discontinued. IPv4 may then be discontinued
entirely or tunneled over IPv6 as described in <xref
target="I-D.durand-softwire-dual-stack-lite">draft-ietf-softwire-dual-stack-lite</xref>.</t>
</section>
<section 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>
</section>
<section anchor="terminology" title="Terminology">
<t><list hangIndent="22" style="hanging">
<t hangText="6rd prefix">An IPv6 prefix selected by the Service
Provider for use by a 6rd domain. There is exactly one 6rd
Prefix for a given 6rd domain. An SP may deploy 6rd with a
single 6rd domain or multiple 6rd domains.</t>
<t hangText="6rd Customer Edge">A 6rd CE is a device
functioning as a Customer Edge in a 6rd deployment. In a
residential broadband deployment this type of device is
sometimes referred to as a "Residential Gateway (RG)," or
"Customer Premises Equipment" (CPE). A typical CE router
serving a residential site has one CE WAN Side interface, one
or more CE LAN Side interfaces, and a virtual 6rd interface. A
6rd CE may also be referred to simply as a "CE" within the
context of 6rd. </t>
<t hangText="6rd delegated prefix">The IPv6 prefix calculated
by the CE for use by hosts within the customer site by
combining the 6rd prefix and the CE IPv4 Address obtained via
IPv4 configuration methods. This prefix can be considered
logically equivalent to a DHCPv6 IPv6 delegated prefix <xref
target="RFC3633"></xref>. </t>
<t hangText="6rd domain">A set of 6rd CEs and BRs connected to
the same virtual 6rd link. A Service Provider may deploy 6rd
with a single 6rd domain, or may utilize multiple 6rd
domains. Each domain requires a separate 6rd prefix.</t>
<t hangText="CE LAN side"> The functionality of a 6rd CE that
serves the "Local Area Network (LAN)" or "Home-facing" side the
CE. The CE LAN Side interface is fully IPv6 enabled.</t>
<t hangText="CE WAN side">
The functionality of a 6rd CE that serves the "Wide Area
Network (WAN)" or "Service Provider-facing" side of the CE. The
CE WAN Side is IPv4-only.</t>
<t hangText="6rd Border Relay (BR)">A 6rd-enabled router
managed by the service provider at the edge of a 6rd domain. The 6rd BR
router has at least one of each of the following: an
IPv4-enabled interface, a 6rd virtual interface acting as an
endpoint for the 6rd IPv6 in IPv4 tunnel, and an IPv6 interface
reachable outside of the 6rd domain. A 6rd BR may also be
referred to simply as a "BR" within the context of 6rd.</t>
<t hangText="BR IPv4 address">The IPv4 address of the 6rd
Border Relay for a given 6rd domain. This IPv4 address is used
by the CE to send packets to a BR in order to reach IPv6
destinations outside of the 6rd domain. Typically, the BR IPv4
address will be an anycast address. </t>
<t hangText="6rd virtual interface"> Internal multi-point
tunnel interface where 6rd encapsulation and decapsulation of
IPv6 packets inside IPv4 occurs. A typical CE or BR
implementation requires only one 6rd virtual interface. A BR
operating in multiple 6rd domains may require more than one 6rd
Virtual Interface, but no more than one per 6rd domain.</t>
<t hangText="CE IPv4 address">The IPv4 address given to the CE
as part of normal IPv4 Internet access (i.e., configured via
DHCP, PPP, or otherwise). This address may be global or private
<xref target="RFC1918"></xref> within the 6rd domain. This
address is used by a 6rd CE to create the 6rd delegated prefix
as well as to send and receive IPv4 encapsulated IPv6
packets.</t>
</list></t>
</section>
<section anchor="prefix_alloc" title="6rd prefix delegation">
<t>The 6rd delegated prefix for use at a customer site is created
by combining the 6rd prefix and some or all of the CE IPv4
Address. From these elements, the 6rd delegated prefix is
automatically created by the CE for the customer site when IPv4
service is obtained. This 6rd delegated prefix is used in the same
manner as a prefix obtained via DHCPv6 Prefix Delegation <xref
target="RFC3633"></xref>.</t>
<t>In 6to4, a similar operation is performed by incorporating an
entire IPv4 address at a fixed location within a well-known /16
IPv6 prefix. In 6rd, the IPv6 prefix as well as the position and
number of bits of the IPv4 address incorporated varies from one 6rd
domain to the next. 6rd allows the SP to adjust the size of the 6rd
prefix, bits used by the 6rd mechanism, and how many bits are left
to be delegated to customer sites. To allow for stateless address
auto-configuration on the CE LAN Side, a 6rd delegated prefix MUST
be /64 or shorter.</t>
<t>The 6rd delegated prefix is created by concatenating the 6rd
prefix and a consecutive set of bits from the CE IPv4 address in
order. The sum of the number of bits used by each determines the
size of the prefix that is delegated to the CE.</t>
<figure align="center" anchor="v6address">
<artwork align="left"><![CDATA[
|<--- 6rd delegated prefix --->|<----- Customer IPv6 Addresses ----->
+------------------+-----------+-----------+------------------------+
| 6rd_Prefix | IPv4_add | Subnet ID | Interface ID |
| /n bits | 0-32 bits | 0-16 bits | 64 bits |
+------------------+-----------+-----------+------------------------+
]]></artwork></figure>
<t>For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4
address is used (e.g all CE IPv4 addresses can be aggregated by a
10.0.0.0/8), then the size of the 6rd delegated prefix for
each CE is automatically calculated to be /56 (32 + 24 = 56).</t>
<t>Embedding less than the full 32 bits of a CE IPv4 address is
possible only when an aggregated block of IPv4 addresses is
available for a given 6rd domain. This may not be practical with
global IPv4 addresses, but is quite likely in a deployment where
private addresses are being assigned to CEs. If private addresses
overlap within a given 6rd deployment, the deployment may be
divided into separate 6rd domains, likely along the same topology
lines the NAT-based IPv4 deployment itself would require. In this
case, each domain is addressed with a different 6rd prefix.</t>
<t>Each 6rd domain may use a different encoding of the embedded
IPv4 address, even within the same service provider. For example,
if multiple IPv4 address blocks with different levels of
aggregation are used at the same service provider, the number of
IPv4 bits needed to encode the 6rd delegated prefix may vary
between each block. In this case, a different 6rd prefix, and hence
separate 6rd domain, may be used to disambiguate the different
encodings. </t>
<t>Since 6rd delegated prefixes are selected algorithmically from
an IPv4 address, changing the IPv4 address will cause a change in
the IPv6 delegated prefix which would ripple through the site's
network and could be disruptive. As such, the service provider should
assign CE IPv4 addresses with relatively long lifetimes.</t>
<t>6rd IPv6 address assignment and hence the IPv6 service itself is
tied to the IPv4 address lease (whether set via DHCP, PPP, or
otherwise), thus the 6rd service is also tied to this in terms of
authorization, accounting, etc. For example, the 6rd delegated
prefix has the same DHCP lease time as its associated IPv4
address. The prefix lifetimes advertised in Router Advertisements
or used by DHCP on the CE LAN Side MUST be equal to or shorter
than the IPv4 address lease time.</t>
</section>
<section anchor="Troubleshooting" title="Troubleshooting and Traceability">
<t>A 6rd IPv6 address and associated IPv4 address for a given
customer can always be determined algorithmically by the service
provider that operates the given 6rd domain. This may be useful
for referencing logs and other data at a service provider which may
have more robust operational tools for IPv4 than IPv6. This also
allows IPv4 data path, node, and endpoint monitoring to be
applicable to IPv6.</t>
<t>The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast
address <xref target="RFC4291"></xref> for its own 6rd delegated
prefix. This allows, for example, IPv6 ping messages to be sent to
the 6rd Virtual Interface itself for additional troubleshooting of
the internal operation of 6rd at a given CE or BR, over and above
an IPv4 ping to the associated CE or BR IPv4 address. In the case
of the BR, the IPv4 address used to calculate the 6rd delegated
prefix is the configured BR IPv4 Address.</t>
</section>
<section title="Address Selection">
<t>All addresses assigned from 6rd delegated prefixes should be
treated as native IPv6. No changes to the <xref
target="RFC3484">source address selection or destination address
selection policy table</xref> are necessary.</t>
</section>
<section anchor="provisioning" title="6rd Configuration">
<t>For a given 6rd domain, the BR and CE MUST be configured with the
following four 6rd elements. The configured values for these four 6rd elements
are identical for all CEs and BRs within a given 6rd domain.</t>
<t><list hangIndent="26" style="hanging">
<t hangText="IPv4PrefixLen">The number of high-order bits
that are identical across all CE IPv4 addresses within a
given 6rd domain. For example, if there are no identical
bits, IPv4PrefixLen is 0 and the entire CE IPv4 address is
used to create the 6rd delegated prefix. If there are 8
identical bits (e.g., the Private IPv4 address range
10.0.0.0/8 is being used), IPv4PrefixLen is equal to
8.</t>
<t hangText="6rdPrefix">The 6rd IPv6 prefix for the given 6rd
domain. </t>
<t hangText="6rdPrefixLen">The length of the 6rd IPv6 prefix
for the given 6rd domain. </t>
<t hangText="6rdBRIPv4Address">The IPv4 address of the 6rd
Border Relay for a given 6rd domain (typically anycast).</t>
</list></t>
<section anchor="ce-config" title="Customer Edge Configuration">
<t>The four 6rd elements are set to values which are the same
across all CEs within a 6rd domain. The values may be configured in
a variety of manners, including automatic provisioning methods such
as the Broadband Forum's "TR-69" Residential Gateway management
interface, an XML-based object retrieved after IPv4 connectivity is
established, a DNS record, an SNMP MIB, PPP IPCP, or manual
configuration by an end-user or operator. This document describes
how to configure the necessary parameters via a single DHCP
option. For consistency and convenience, this option format may be
used by other automatic configuration methods by normative
reference to this document.
</t>
<t> The only remaining provisioning information the CE requires in
order to calculate the 6rd delegated prefix and enable IPv6
connectivity is an IPv4 address for the CE. This CE IPv4 Address is
configured as part of obtaining IPv4 Internet access (i.e.,
configured via DHCP, PPP, or otherwise). This address may be global
or private <xref target="RFC1918"></xref> within the 6rd
domain.</t>
<t> A single 6rd CE MAY be connected to more than one 6rd domain,
just as any router may have more than one IPv6-enabled service
provider facing interface and more than one set of associated
delegated prefixes assigned by DHCPv6 PD or other means. Each
domain a given CE operates within would require its own set of 6rd
configuration elements, and would generate its own 6rd delegated
prefix.</t>
<section anchor="dhcp" title="6rd DHCPv4 Option">
<figure align="center" anchor="6rd_dhcp_option">
<artwork align="left"><![CDATA[
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_6RD | option-length | IPv4PrefixLen | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 6rdPrefix |
| (variable, up to 16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list hangIndent="26" style="hanging">
<t hangText="option-code">OPTION_6RD(TBD)</t>
<t hangText="option-length">the length of the DHCP option in
octets (between 6 and 22 octets).</t>
<t hangText="IPv4PrefixLen">The number of high-order bits that
are identical across all CE IPv4 addresses within a given 6rd
domain. This may be any value between 0 and 32. Any value
greater than 32 is invalid.</t>
<t hangText="6rdPrefixLen">IPv6 Prefix length of the SP's 6rd
IPv6 prefix in number of bits. For the purpose of bounds
checking by DHCP option processing, the IPv4PrefixLen +
6rdPrefixLen MUST be less then or equal than 128. The 6rd
implementation may further limit the sum of these lengths to
64. </t>
<t hangText="6rdBRIPv4Address">The IPv4 address of the 6rd
Border Relay for a given 6rd domain (typically anycast). </t>
<t hangText="6rdPrefix">Variable length field containing the
Service Provider's 6rd IPv6 prefix. The sender of this option
MUST pad with zero to at least to a full octet, and MAY pad
with zero to the full 16 octets. Length of the 6rd_prefix is
determined from the option-length.</t>
</list></t>
<t>When 6rd is enabled, a typical CE router will install a
default route to the BR, a black hole route for the 6rd delegated
prefix, and routes for any LAN Side assigned and advertised
prefixes. For example, using a CE IPv4 address of 10.100.100.1, a
6rd BR IPv4 relay address of 10.0.0.1, an IPv4PrefixLen of 8,
2001:ABC0::/32 as the 6rdPrefix, and one /64 prefix assigned to a
LAN Side Interface, a typical CE Routing Information Base (RIB)
will look like:</t>
<figure><artwork align="left"><![CDATA[
::/0 -> 2001:ABC0:0000:0100:: (default route)
2001:ABC0::/32 -> 6rd-virtual-interface0 (direct connect to 6rd)
2001:ABC0:6464:0100::/56 -> Null0 (delegated prefix sink route)
2001:ABC0:6464:0100::/64 -> Ethernet0 (LAN interface)
]]></artwork></figure>
</section>
</section>
<section anchor="br-config" title="Border Relay Configuration">
<t>The 6rd BR MUST be configured with the same 6rd elements as the
6rd CEs operating within the same domain.</t>
<t>For increased reliability and load-balancing, the BR IPv4
address SHOULD be an anycast address shared across a given 6rd
domain. As 6rd is stateless, any BR may be used at any time. The
6rd relay MUST use its anycast IPv4 address as the source address
in packets relayed via the SP network to the CE.</t>
<t>Since 6rd uses provider address space, no specific routes need
to be advertised externally for 6rd to operate, neither in IPv6 nor
IPv4 BGP. However, the 6rd IPv4 relay anycast addresses must be
advertised in the service provider's IGP.</t>
</section>
</section>
<section anchor="nud" title="Neighbor Unreachability Detection">
<t>Neighbor Unreachability Detection (NUD) for tunnels is
described in Section 3.8 of <xref target="RFC4213"></xref>.
In 6rd, all CEs and BRs can be considered as connected to the
same virtual link and therefore neighbors to each other. This
section describes how to utilize neighbor unreachability
detection without negatively impacting the scalability of a 6rd
deployment.</t>
<t>A typical 6rd deployment may consist of a very large number of
CEs within the same domain. Reachability between CEs is based on
IPv4 routing, and sending NUD or any periodic packets between 6rd
CE devices beyond isolated troubleshooting of the 6rd mechanism
is not recommended. </t>
<t>While reachability detection between a given 6rd CE and BR is
not necessary for the proper operation of 6rd, in cases where a
CE has alternate paths for BR reachability to choose from it
could be useful. Sending NUD messages to a BR, in particular
periodic messages from a very large number of CEs, could result
in overloading of the BR control message processing path,
negatively affecting scalability of the 6rd deployment. Instead,
a CE that needs to determine BR reachability MUST utilize a
method which allows reachability detection packets to follow a
typical data forwarding path without special processing by the
BR. One such method is described below.</t>
<t><list style="numbers">
<t>The CE constructs a Payload of any size and content to be sent
to the BR (e.g., a zero length null payload, a padded payload
designed to test a certain MTU, a NUD message, etc.). The exact
format of the message payload is not important as the BR will not
be processing it directly.</t>
<t>The desired Payload is encapsulated with the inner IPv6 and
outer IPv4 headers as follows:
<list style="symbols">
<t>The IPv6 Destination Address is set to an address from the
CE's 6rd delegated prefix for which the CE itself will process
(e.g., a CE "loopback" or other type of local interface
address).</t>
<t>The IPv6 Source Address is set to an address from the CE's
6rd delegated prefix as well, including the same as used for
the IPv6 Destination Address.</t>
<t>The IPv4 header is then added as it normally would for any
packet destined for the BR. That is, the IPv4 Destination
Address is that of the BR, and Source Address is the CE IPv4
Address.</t>
</list></t>
<t>The CE sends the constructed packet out the proper
interface it is monitoring BR reachability on. On successful
receipt at the BR, the BR MUST decapsulate and forward the packet
normally. This is, the IPv4 header is decapsulated normally,
revealing the IPv6 destination as the CE, which in turn results
in the packet being forwarded to that CE via the 6rd mechanism
(i.e., the IPv4 Destination is that of the CE that originated the
packet, and the IPv4 Source is that of the BR).</t>
<t>Arrival of the constructed IPv6 packet at the CE's IPv6
address completes one round trip to and from the BR, without
causing the BR to process the message outside of its normal data
forwarding path. The CE then processes the IPv6 packet
accordingly (updating keepalive timers, metrics, etc).</t>
</list></t>
<t>The payload may be empty, or could contain values that are
meaningful to the CE. Sending a proper NUD message could be
convenient for some implementations. Since the BR forwards the
packet as any other data packet without any processing of the
payload itself, the format of the payload is left as a choice to
the implementer.</t>
</section>
<section anchor="encaps" title="IPv6 in IPv4 Encapsulation">
<t>IPv6 in IPv4 encapsulation is done as specified in 6to4 <xref
target="RFC3056"></xref> and in <xref target="RFC4213">Basic
Transition Mechanisms for IPv6 Hosts and Routers</xref>.</t>
<t>IPv6 packets from a CE are encapsulated in IPv4 packets when
they leave the site via its CE WAN Side interface. The CE IPv4
address MUST be configured to send and receive packets on this
interface.</t>
<t> The 6rd link is modeled as an NBMA<xref
target="RFC2491"></xref> link with all 6rd CEs and BRs defined to
be off-link from each other. The link-local address of a 6rd
virtual-interface performing the 6rd encapsulation would, if
needed, be formed as described in Section 3.7 of <xref
target="RFC4213"></xref>. However, no communication using
link-local addresses will occur.</t>
<section title="Maximum Transmission Unit">
<t>MTU and fragmentation issues for IPv6 in IPv4 tunneling are
discussed in detail in section 3.2 of <xref target="RFC4213">
RFC4213</xref>. 6rd's scope is limited to a service provider
network. IPv4 Path MTU discovery MAY be used to adjust the MTU of the
tunnel as described in section 3.2.2 of <xref target="RFC4213">
RFC4213</xref> or the 6rd Tunnel MTU may be explicitly
configured.</t>
<t>If the MTU is well-managed such that the IPv4 MTU on the CE
WAN Side interface is set so that no fragmentation occurs
within the boundary of the SP, then the 6rd Tunnel MTU should
be set to the known IPv4 MTU minus the size of the
encapsulating IPv4 header (20 bytes). For example, if the IPv4
MTU is known to be 1500 bytes, the 6rd Tunnel MTU may be set to
1480 bytes. Absent of more specific information the 6rd Tunnel
MTU SHOULD default to 1280 bytes.</t>
<t>A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether
determined automatically or configured directly, on the LAN
Side by setting the MTU option in <xref target="RFC4861">Router
Advertisements</xref> messages to the 6rd Tunnel MTU.</t>
</section>
<section anchor="receiving_rules" title="Receiving Rules">
<t>In order to prevent spoofing of IPv6 addresses, the 6rd BR and
CE MUST validate the source address of the encapsulated IPv6
packet with the IPv4 source address it is encapsulated by
according to the configured parameters of the 6rd domain. If the
two source addresses do not match, the packet MUST be dropped and
a counter incremented to indicate that a potential spoofing
attack may be underway. Additionally, a CE MUST allow packets
sourced by the configured BR IPv4 Address.</t>
<t>The CE router SHOULD drop packets received on the 6rd virtual
interface (i.e., after decapsulation of IPv4) for IPv6 destinations
not within its own 6rd delegated prefix.</t>
</section>
</section>
<section title="Transition Considerations">
<t>6rd is intended to deliver a production-level IPv6 service to
customer sites. Once 6rd IPv6 access is available, the SP network
can migrate to IPv6 at its own pace with little or no effect on the
customer. When native IPv6 is fully available, the CE is
provisioned with IPv6 on its WAN side. 6rd and native IPv6 can
coexist for a time while the customer site adopts the new IPv6
service, and then 6rd de-provisioned.</t>
<t>6rd utilizes the same encapsulation and base mechanism as 6to4
and could in fact be viewed as a superset of 6to4. 6to4 service can
be made with 6rd by setting the 6rd prefix to 2002::/16. Unlike
6to4, 6rd is for use only in an environment where a service
provider cooperates closely to deliver the IPv6 service. 6to4
routes with the 2002::/16 prefix may exist alongside 6rd in the 6rd
CE router, and doing so may offer some efficiencies when
communicating directly with 6to4 routers.</t>
</section>
<section title="IPv6 Address Space Usage">
<t>As 6rd uses service provider address space, 6rd uses the normal
address delegation a service provider gets from its RIR and no
global allocation of a single 6rd IANA assigned address block like
the 6to4 2002::/16 is needed.</t>
<t>The service provider's prefix must be short enough to encode the
unique bits of all IPv4 addresses within a given 6rd domain and
still provide a production-quality IPv6 service to the residential
site. Assuming a worst case scenario using the full 32 bits for the
IPv4 address, assigning a /56 for customer sites would mean that
each service provider using 6rd would require a /24 for 6rd in
addition to other IPv6 addressing needs. Assuming that 6rd would be
stunningly successful and taken up by almost all AS number holders
(32K today) then the total address usage of 6rd would be equivalent
to a /9. If the SP instead delegated /60s to sites the service
provider would require a /28 and the total global address
consumption by 6rd would be equivalent to a /13. Again, this
assumes that 6rd is used by all AS number holders in the IPv4
Internet today at the same time, none used any of 6rd's address
compression techniques, and that none have moved to native IPv6 and
reclaimed the 6rd space which was being used for other
purposes.</t>
<t>To alleviate concerns about address usage, 6rd allows for leaving out
redundant IPv4 prefix bits in the encoding of the IPv4 address inside the
6rd IPv6 address. This is most useful where the IPv4 address space is very
well aggregated. For example to provide each customer with a /60, if a
service provider has all its IPv4 customers under a /12 then only 20 bits
needs to be used to encode the IPv4 address and the service provider would
only need a /40 IPv6 allocation for 6rd. If private address space is used
then a 10/8 would require a /36. If multiple 10/8 domains are used then up
to 16 could be supported within a /32.</t>
<t>The 6rd address block can be reclaimed when all users of it have
transitioned to native IPv6 service. This may require
renumbering of customer sites and use of additional address
space during the transition period.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>A 6to4 relay router as specified in <xref target="RFC3056">RFC
3056</xref> can be used as an open relay. It can be used to relay
IPv6 traffic and as a traffic anonymizer. By restricting the 6rd
domain to within a provider network a CE only needs to accept
packets from a single or small set of known 6rd BR IPv4 Addresses. As
such, many of the threats against 6to4 as described in <xref
target="RFC3964">RFC3964</xref> do not apply.</t>
<t>When applying the receiving rules in <xref
target="receiving_rules"></xref>, IPv6 packets are as well
protected against spoofing as IPv4 packets are within an SP
network.</t>
<t>A malicious user that is aware of a 6rd domain and the BR IPv4
address could use this information to construct a packet that would cause a
Border Relay Router to reflect tunneled packets outside of the domain that
it is serving. If the attacker constructs the packet accordingly, and can
inject a packet with an IPv6 source address that looks as if it originates
from within the 6rd domain of the second border relay, forwarding loops
between 6rd domains may be created, allowing the malicious user to launch a
packet amplification attack between 6rd domains.</t>
<t>One possible mitigation for this is to simply not allow the BR IPv4
address to be reachable from outside the SP's 6rd domain. In this case,
carefully constructed IPv6 packets still may be reflected off a single BR,
but the looping condition will not occur. Tunnelled packets with the BR
IPv4 address as the source address may also be filtered to prohibit 6rd
tunnels from exiting the 6rd domain.</t>
<t>To avoid forwarding loops via other internal relays, the BR
should employ outgoing and incoming IPv4 packets filters, filtering
out all known relay addresses for internal 6rd BRs, ISATAP routers or 6to4
relays, including the well known anycast address space for
6to4.</t>
<t>The BR MUST install a sink route for its 6rd delegated prefix
created based on its BR IPv4 address, with the exception of the
IPv6 Subnet-Router anycast address.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to assign a new DHCP Option code point for
OPTION_6RD.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This draft is based on Remi Despres' original idea described in
<xref target="I-D.despres-6rd"></xref> and the work done by Rani
Assaf, Alexandre Cassen, and Maxime Bizon at Free Telecom. Brian
Carpenter and Keith Moore documented 6to4, which all of this work
is based upon. Review and encouragement have been provided by many
others and in particular Chris Chase, Thomas Clausen, Wojciech Dec,
Bruno Decraene, Remi Despres, Alain Durand, Washam Fan, Martin
Gysi, Fred Templin, Dave Thaler, Eric Voit and David Ward.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation
libraries: 1. define an ENTITY at the top, and use "ampersand
character"RFC2629; here (as shown) 2. simply use a PI "less than
character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find
included files in the same directory as the including file. You can
also define the XML_LIBRARY environment variable with a value
containing a set of directories to search. These can be either in
the local filing system or remote ones accessed by http
(http://domain/dir/... ).-->
<!-- -->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"? -->
&RFC2119;
&RFC3056;
&RFC4213;
&RFC1918;
&RFC3964;
&RFC4861;
&RFC2491;
&RFC4291;
</references>
<references title="Informative References">
&I-D.despres-6rd;
&RFC3484;
&RFC3068;
&RFC3633;
&I-D.durand-softwire-dual-stack-lite;
</references>
<!-- Change Log
v00 2009-04-15 OT Initial version
v00 2009-04-29 OT Tidied up language. Added security section.
v00 2009-04-29 OT First set of comments from Mark.
v00 2009-05-12 MT New Text & Edits
v00 2009-05-29 OT Variable length DHCP/IPCP options
v00 2009-07-06 MT/OT Drastic rush to finish before Stockholm -00 deadline
v02 2009-12-01 OT Hiroshima IETF comments. Readying for last call.
v02 2009-12-14 OT Incorporated comments from Dave Thaler.
v02 2010-01-04 MT/OT Vast cleanups and intro of NUD text
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:10 |