One document matched: draft-ietf-softwire-ipv6-6rd-00.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 RFC1661 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1661.xml">
<!ENTITY RFC2516 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2516.xml">
<!ENTITY RFC1332 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1332.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 RFC3315 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.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">
]>
<?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-00" 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="">IPv6 via IPv4 Service Provider Networks</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<!--
<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>
-->
<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>
<phone>+33 15 804 3483</phone>
<email>townsley@cisco.com</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>
<phone>+47 917 38519</phone>
<email>ot@cisco.com</email>
</address>
</author>
<date month="August" year="2009" />
<!-- 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 a protocol 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 outside of the SP's IPv4
network infrastructure.</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.</t>
<t> 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 6rd is
used to refer to the new mechanisms described here and 6to4 as
that which is described in RFC 3056.</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 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 connected
to the 6rd-enabled SP network, the IPv6 service provided is equivalent
to native IPv6.</t>
<t>6rd does not translate IPv4 into IPv6, it encapsulates IPv6 in IPv4 with
a destination IPv4 address which is either encoded within the IPv6
destination address itself, or is the destination address of a
preconfigured 6rd Border Relay router that can decapsulate the IPv4 header
and route the IPv6 packet outside the SP's IPv4 network. This way, IPv6
packets follow the IPv4 routing topology within the SP network, and Border
Relays are traversed only for IPv6 packets which are destined or are
arriving outside the SP's IPv4 network. The 6rd mechanism is fully
stateless, so the Border Relay routers may be addressed via anycast within
the SP network for added resiliency. </t>
<t>The 6rd Customer Edge router (6rd CE) plays a critical role in
a 6rd deployment. 6rd decouples deployment of IPv6 on the "LAN"
side of the 6rd CE router from that on the "WAN" side, allowing
IPv6 on either side to be deployed and evolve independently. On
the LAN (e.g., "Home") side of the 6rd CE router, 6rd expects that
IPv6 is implemented as it would be for any native dual-stack IP
service delivered by the SP. On the WAN side of the 6rd CE router,
the 6rd CE WAN interface itself, the access network between it and
partnering 6rd equipment, and the OSS system including DHCP, AAA,
etc. may remain IPv4-only (e.g., there is no need to deploy <xref
target="RFC3315">DHCPv6</xref>, IPv6 Neighbor Discovery, IPv6
routing, create IPv6 address plans, etc. within the SP network to
deliver IPv6 to the customer site). </t>
<t>6rd relies on IPv4 and is designed to deliver
"production-quality" dual-stack IPv6 and IPv4 Internet access to
customer sites. IPv6 deployment within the SP network itself may
continue for the SP's own purposes outside of delivering IPv6
service to customers. Once IPv6 is fully available, 6rd may be
discontinued and IPv4 eventually turned off 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 Delegated Prefix">The IPv6 prefix determined by the
6rd CE device for use by hosts within the customer site. This prefix
can be considered logically equivalent to a DHCPv6 IPv6 Delegated
Prefix <xref target="RFC3633"></xref>, though it is calculated by
combining the 6rd SP Prefix and the end user's IPv4 address obtained
via IPv4 configuration methods.</t>
<t hangText="6rd SP Prefix">
An IPv6 prefix selected by the Service Provider for use by a given 6rd
deployment. This may be the entire IPv6 prefix obtained from an RIR
and announced to the IPv6 Internet, or a more-specific assigned just
to given 6rd deployment.</t>
<t hangText="6rd CE">The 6rd "Customer Edge" router that sits between
an IPv6-enabled site and an IPv4-enable SP network. In a residential
broadband deployment this is sometimes referred to as the "Residential
Gateway (RG)," "Customer Premises Equipment," (CPE) or "Internet
Gateway Device" (IGD). This router has a one internal 6rd Virtual
Interface acting as an endpoint for the IPv6 in IPv4 encapsulation and
forwarding, at least one "6rd CE LAN Side" interface and "6rd CE WAN
Side" interface, respectively. </t>
<t hangText="6rd CE LAN Side"> The functionality of a 6rd CE router
that serves the "Local Area Network (LAN)" or "Home" side of a
broadband service provider connection. The 6rd CE LAN Side interface
is fully IPv6 enabled.</t>
<t hangText="6rd CE WAN Side">
The functionality of a 6rd CE Router that serves the "Wide Area
Network" or "Service Provider" side of the 6rd CE Router. The
6rd CE WAN side is IPv4-only, except that it delivers IPv6
packets encapsulated in IPv4 by the 6rd Virtual Interface.
</t>
<t hangText="6rd BR">A 6rd-enabled "Border Relay" router located at
the SP premises. The 6rd BR router has at least one IPv4 interface, an
internal 6rd Virtual Interface for multi-point tunneling, and at least
one IPv6 interface that is reachable via the IPv6 Internet or
IPv6-enabled portion of the SP network.</t>
<t hangText="6rd Virtual Interface"> Internal multi-point tunnel
interface where 6rd encapsulation and decapsulation of IPv6 packets
inside IPv4 occurs. A typical 6rd CE or 6rd BR implementation requires
one 6rd Virtual Interface.</t>
<t hangText="Subscriber IPv4 address">The IPv4 address given to the
subscriber as part of normal IPv4 Internet access (i.e., configured via
DHCP, PPP, or otherwise). This address may be global or private
(RFC1918) within the 6rd domain. This address is used by 6rd to create
the 6rd IPv6 prefix, and to send and receive IPv6 packets encapsulated
in IPv4 by the 6rd mechanism.</t>
</list></t>
</section>
<section anchor="prefix_alloc" title="6rd Prefix Delegation">
<t>In 6rd, a customer site's IPv6 Delegated Prefix is derived from 2
elements:</t>
<t><list style="numbers">
<t>An IPv6 Prefix selected by the SP to be the common 6rd SP Prefix
for the given 6rd deployment (an SP can have multiple 6rd deployments
called domains). </t>
<t>An assigned IPv4 address for the subscriber. This IPv4 address may
be a global IPv4 address, or a <xref target="RFC1918">Private RFC
1918</xref> IPv4 address.</t>
</list></t>
<t>From these three items, the 6rd Delegated Prefix is automatically
created for the customer site when IPv4 service is obtained. From the
perspective of the 6rd CE LAN-Side functionality, this IPv6 delegated
prefix is used in the same manner as a prefix obtained via DHCPv6 Prefix
Delegation <xref target="RFC3633"></xref>.</t>
<t>In 6to4, the location of the stored 32-bit IPv4 address is at a fixed
location within the IPv6 address. In 6rd it varies, so the size of the SP
IPv6 prefix is important. Also, in 6rd the SP chooses how many suffix bits
of the IPv4 prefix are used in the algorithm to create the IPv6 prefix for
its subscribers. This allows the SP to adjust the balance between IPv6
addresses used by the 6rd mechanism, and how many are left to be delegated
to end user sites. To allow for stateless address auto-configuration and
sub delegation a 6rd delegated prefix MUST be shorter than a /64.</t>
<t>The 6rd Delegated Prefix is created by concatenating the 2 items above
in order. The sum of the number of bits used by each determines the size
of the prefix that is delegated to the 6rd CE router for use by the
customer site.</t>
<figure align="center" anchor="v6address">
<artwork align="left"><![CDATA[
/n + (<= 32) + (<= 16) + 64 = 128 bits
+-----------------+----------+-----------+-------------------------+
| 6rd SP Prefix |v4 address| Subnet ID | Interface ID |
+-----------------+----------+-----------+-------------------------+
|<---6rd Delegated Prefix--->|<--- End user's address space ---->|
]]></artwork></figure>
<t>For example, if the 6rd SP Prefix is a /28, the v4suffix-length for the
6rd domain is 24, and we specify a maximum of 16 6rd domains for the
deployment, the shortest possible delegated IPv6 prefix for each subscriber
is /56 (28 + 24 + 4 = 56).</t>
<t>Embedding less than the full 32 bits of an IPv4 address is possible only
with an aggregated block of IPv4 addresses for a given 6rd SP Prefix. This
may not be practical for global IPv4 addresses at a given SP, but is quite
likely in a deployment where private addresses are being assigned to end
users (for example 10.0.0.0/8). If private addresses overlap within a given
6rd deployment, the deployment may be subdivided into separate 6rd Domains,
likely along the same topology lines the NAT-based IPv4 deployment itself
would also require. In this case, each domain is addressed with a different
6rd SP Prefix. An implementation MAY expose this to the operator for
configuration as a single 6rd SP Prefix coupled with a Domain ID which is
appended to the 6rd SP Prefix during operation.</t>
<t>Multiple encodings are possible within a single 6rd deployment. For
example, if global and private IPv4 addresses are used within the same 6rd
site, and the number of IPv4 bits encoded in the IPv6 Delegated Prefix
varies between the two (e.g., 32 bits for global, and 24 bits for private),
then a different 6rd SP Prefix must be used to disambiguate the two
different encoding settings.</t>
<t>Since 6rd IPv6 prefixes are selected algorithmically from an IPv4
address, changing the IPv4 address will cause a change in the IPv6
delegated prefix which would normally ripple through the site's network
and be disruptive. As such, if possible the service provider should
utilize a long-lived IPv4 address assignment for a given end user. </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 6rd CE LAN side MUST be
equal or shorter than the IPv4 address lease time.</t>
<t> For trouble-shooting and traceability, a 6rd IPv6 address and
the associated IPv4 address for the same site can always be
determined algorithmically. This may be useful for referencing
logs and other data at an SP that may be limited to IPv4 address
assignment activity.</t>
</section>
<section title="Address selection">
<t>A 6rd delegated prefix is a native IPv6 prefix in the LAN-side of 6rd
CE. For the purpose of source and destination address selection the prefix
should be treated as native IPv6 and no changes to
the <xref target="RFC3484">source address selection or destination address
selection policy table</xref> is needed.</t>
</section>
<section anchor="provisioning" title="Provisioning the 6rd CE router">
<t>The 6rd CE router must be configured with the 6rd SP prefix, the common
IPv4 prefix length and a 6rd BR router IPv4 address. A given 6rd CE router
is expected to exist in only one 6rd Domain (as indicated by the 6rd SP
prefix).</t>
<t> This information can be configured into the device in a variety of ways
including manual configuration. DHCP and IPCP are defined here, other
automatic provisioning protocols may be used as well.</t>
<section anchor="dhcp" title="6rd DHCP 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 | len |v4suffix-length|v6prefix-length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rd Border Relay IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SP 6rd SP Prefix |
| (variable, up to 16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> <!-- -->
<t><list hangIndent="26" style="hanging">
<t hangText="option code">OPTION_6RD(TBD)</t>
<t hangText="len">Total length of option in octets.</t>
<t hangText="v4suffix-length">v4suffix-length is the number of
low-order bits that are not identical across all subscriber IPv4
addresses within a given 6rd domain.
If there are no identical bits, the v4suffix-length is 32 and the
entire subscriber IPv4 address is used to create a 6rd delegated
prefix. A value of 0, and any value greater than 32, is invalid and
should cause 6rd setup to fail.</t>
<t hangText="v6prefix-length">IPv6 Prefix length of the SP IPv6
prefix in number of bits.</t>
<t hangText="6rd BR IPv4 address">The IPv4 address of the
6rd Relay (may be anycast).</t>
<t hangText="SP 6rd IPv6 prefix">Variable length field containing
the Service Provider's 6rd IPv6 prefix for this deployment and this
6rd CE router, zero padded to at least a full octet. Length of the
field is determined by the reported length of the entire DHCP option
(len). An implementation must handle receipt of this option with
zero padding up to a full 16 octets, for deployments preferring to
send a fixed size option.</t>
</list></t>
<t>The client must validate the values received in the option as
follows:</t>
<t> The 6rd IPv6 prefix includes the domain ID embedded within it,
sizing the v6prefix-length accordingly to cover both the 6rd SP prefix
size and domain ID for this 6rd route entry.</t>
<t>The 6rd CE router MUST install a default route to the relay. It should
also install a sink route for the delegated prefix. As an example using a
subscriber IPv4 address of 10.100.100.1, a 6rd IPv4 relay address of
10.0.0.1, a v4suffix-length of 24 and 2001:ABC0::/28 as the SP 6rd IPv6
prefix, the RIB will look like:</t>
<figure><artwork align="left"><![CDATA[
::/0 -> 2001:ABC0:0000:0100:: (default route)
2001:ABC0:6464:0100::/56 -> Null0 (6rd prefix sink route)
]]></artwork></figure>
</section>
<section anchor="ipcp" title="6rd PPP IPCP option">
<t> <xref target="RFC1661">PPP</xref>, and
<xref target="RFC2516">PPPoE</xref>, remains a common way for a
residential broadband end user to obtain configuration. In such
deployments, the DHCPINFORM message may be used along with the DHCP
option described above after <xref target="RFC1332">IPCP</xref>
completes. However, PPP-based deployments often have no DHCP
infrastructure in place, obtaining IP configuration solely from RADIUS
servers and network equipment via IPCP.</t>
<t>The PPP IPCP option is identical to the DHCP option, aside of the
OPTION_6RD field, which is assigned by IANA. It's fields and their
function are identical, and not repeated here. </t>
</section>
<section anchor="tr69" title="6rd Broadband Forum TR-69 Object">
<t>A large number of 6rd CE routers are managed directly by service
providers via the Broadband Forum's "TR-69" management interface. This
section will make informational reference to the associated Broadband
Forum document that describes this object. </t>
</section>
</section>
<section anchor="relays" title="Provisioning the Service Provider 6rd Border Relay">
<t>As the 6rd IPv4 relay address is configurable, there is no need for a
well known anycast address as specified
in <xref target="RFC3068">RFC3068</xref>. For increased reliability and
load-balancing, the relay address can be an anycast address shared by all
of the SP BRs for 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 6rd CE
router.</t>
<t>Since 6rd uses provider address space, no specific routes need to be
advertised externally for 6rd to work, neither in IPv6 nor IPv4
BGP. However, the 6rd IPv4 relay anycast addresses must be advertised in
the providers IGP.</t>
<t>This example show how the 6rd prefix is created based on a /32 IPv6
prefix with a private IPv4 address were the first octet is "compressed"
out:</t>
<figure><artwork align="left"><![CDATA[
SP prefix: 2001:0DB8::/32
6rd IPv4 prefix: 10.0.0.0/8
6rd CE router IPv4 address: 10.100.100.1
6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
]]></artwork></figure>
</section>
<section anchor="encaps" title="Encapsulation considerations">
<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 6rd CE router are encapsulated in IPv4 packets when
they leave the site via its 6rd CE WAN side interface. The Subscriber IPv4
address MUST be configured to send and receive packets on this
interface.</t>
<t>MTU and fragmentation issues for IPv6 in IPv4 tunnelling is discussed in
detail in section 3.2 of <xref target="RFC4213"> RFC4213</xref>. 6rd's
scope is limited to a service provider network. If the MTU is well-managed
such that the IPv4 MTU on the 6rd CE WAN interface is set so that no
fragmentation occurs within the boundary of the SP, then the IPv6 MTU
should be set to the IPv4 MTU minus the size of the encapsulating IPv4
header (20 bytes). 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 IPv6 tunnel MTU may be explicitly configured.</t>
<t>The IPv6 tunnel MTU, whether determined automatically or configured
directly, SHOULD be advertised on the LAN-side by setting the MTU option
in <xref target="RFC4861">Router Advertisements</xref> messages to the
IPv6 tunnel MTU.</t>
<section anchor="receiving_rules" title="Receiving Rules">
<t>In order to prevent spoofing of IPv6 addresses, the BR and CE MUST
validate the source address of the encapsulated IPv6 packet with the
address of the IPv4 it is encapsulated by. If the addresses do not match,
the packet is dropped.</t>
<t>The 6rd CE router should drop packets received on the 6rd virtual
interface for destinations not covered by the 6rd Delegated prefix.</t>
</section>
</section>
<section title="Transition Considerations">
<t>6rd is intended to deliver a production-level 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 affect on the customer. When native
IPv6 is fully available, the 6rd CE router is provisioned with IPv6 on its
WAN side. 6rd and native IPv6 can coexist for a time while the customer
site is adopts the new IPv6 native prefix, and then 6rd
deprovisioned. Alternatively, the same numbering plan for 6rd may be used
for the native service, though this might require a "flag day" when the 6rd
service is turned off and native service is initialized. </t>
<t>While 6rd bears resemblance to 6to4 and utilizes the same encapsulation
and base mechanisms, it is not intended as a replacement for 6to4. 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="Address space usage">
<t>The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
IPv4 address and must be short enough so that a /56 or /60 can be given to
subscribers. Using the full IPv4 address assigning a /56 for subscribers
would mean that each service provider using 6rd would require a /24 for 6rd
in addition to other IPv6 address needs they have. Assuming that 6rd would
be stunningly successful and taken up by almost all AS number holders (32K)
then the total address usage of 6rd would be equivalent to a /9. If instead
delegated /60s to subscribers 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, and that none have moved to native
IPv6 and reclaimed the 6rd space which was being used.</t>
<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 address block like for example the 6to4 2002::/16 is
needed.</t>
<t>The 6rd address block can be reclaimed when all users of it has
transitioned out of it into native IPv6 service. This requires renumbering
and usage of additional address space during the transition period.</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>
</section>
<section anchor="Security" title="Security Considerations">
<t>A 6to4 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 6rd CE router only needs to accept packets from a single or small
set of known 6rd relay routers. 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
<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 6rd 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, routing 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 6rd 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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to assign a new DHCP Option code point for
OPTION_6RD.</t>
<t>IANA is requested to assign a new IPCP Type for 6RD_IPCP_TYPE.</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 encoruagement have been provided by many others and in particular Alain
Durand, Wojciech Dec, Thomas Clausen, Martin Gysi and Remi Despres.</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;
&RFC1661;
&RFC1332;
&RFC2516;
&RFC4213;
&RFC1918;
&RFC3964;
&RFC3315;
&RFC3633;
&RFC4861;
</references>
<references title="Informative References">
&I-D.despres-6rd;
&RFC3484;
&RFC3068;
&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
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:37 |