Internet Engineering Task Force W. Townsley
Internet-Draft O. Troan
Intended status: Standards Track Cisco
Expires: July 10, 2010 January 6, 2010
IPv6 via IPv4 Service Provider Networks "6rd"
draft-ietf-softwire-ipv6-6rd-03
Abstract
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 10, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Townsley & Troan Expires July 10, 2010 [Page 1]
Internet-Draft 6rd January 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 6rd prefix delegation . . . . . . . . . . . . . . . . . . . . 6
5. Troubleshooting and Traceability . . . . . . . . . . . . . . . 7
6. Address Selection . . . . . . . . . . . . . . . . . . . . . . 7
7. 6rd Configuration . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Customer Edge Configuration . . . . . . . . . . . . . . . 8
7.1.1. 6rd DHCPv4 Option . . . . . . . . . . . . . . . . . . 9
7.2. Border Relay Configuration . . . . . . . . . . . . . . . . 10
8. Neighbor Unreachability Detection . . . . . . . . . . . . . . 10
9. IPv6 in IPv4 Encapsulation . . . . . . . . . . . . . . . . . . 12
9.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . 12
9.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 13
10. Transition Considerations . . . . . . . . . . . . . . . . . . 13
11. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Townsley & Troan Expires July 10, 2010 [Page 2]
Internet-Draft 6rd January 2010
1. Introduction
The original idea and the name of the mechanism (6rd) specified in
this document is described in draft-despres-6rd [I-D.despres-6rd],
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
[RFC3056] and 6rd the mechanism defined herein.
6rd specifies a protocol mechanism to deploy IPv6 to sites via a
Service Provider's (SP's) IPv4 network. It builds on 6to4 [RFC3056],
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.
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.
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 may be
reached using anycast for failover and resiliency.
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.
6rd relies on IPv4 and is designed to deliver production-quality IPv6
alongside IPv4 with as little change to IPv4 networking and
Townsley & Troan Expires July 10, 2010 [Page 3]
Internet-Draft 6rd January 2010
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
draft-ietf-softwire-dual-stack-lite
[I-D.durand-softwire-dual-stack-lite].
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology
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.
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.
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 [RFC3633].
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.
Townsley & Troan Expires July 10, 2010 [Page 4]
Internet-Draft 6rd January 2010
CE LAN side The functionality of a 6rd CE that serves the
"Local Area Network (LAN)" or "customer-facing"
side of the CE. The CE LAN Side interface is
fully IPv6 enabled.
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.
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
connected to the native IPv6 network. A 6rd BR
may also be referred to simply as a "BR" within
the context of 6rd.
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.
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.
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 [RFC1918] 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.
Townsley & Troan Expires July 10, 2010 [Page 5]
Internet-Draft 6rd January 2010
4. 6rd prefix delegation
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 [RFC3633].
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.
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.
|<--- 6rd delegated prefix --->|<----- Customer IPv6 Addresses ----->
+------------------+-----------+-----------+------------------------+
| 6rd_Prefix | IPv4_add | Subnet ID | Interface ID |
| /n bits | 0-32 bits | 0-16 bits | 64 bits |
+------------------+-----------+-----------+------------------------+
Figure 1
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).
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.
Townsley & Troan Expires July 10, 2010 [Page 6]
Internet-Draft 6rd January 2010
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.
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.
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.
5. Troubleshooting and Traceability
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.
The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast
address [RFC4291] 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.
6. Address Selection
All addresses assigned from 6rd delegated prefixes should be treated
as native IPv6. No changes to the source address selection or
destination address selection policy table [RFC3484] are necessary.
Townsley & Troan Expires July 10, 2010 [Page 7]
Internet-Draft 6rd January 2010
7. 6rd Configuration
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.
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.
6rdPrefix The 6rd IPv6 prefix for the given 6rd
domain.
6rdPrefixLen The length of the 6rd IPv6 prefix for the
given 6rd domain.
6rdBRIPv4Address The IPv4 address of the 6rd Border Relay
for a given 6rd domain (typically anycast).
7.1. Customer Edge Configuration
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.
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 [RFC1918]
within the 6rd domain.
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
Townsley & Troan Expires July 10, 2010 [Page 8]
Internet-Draft 6rd January 2010
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.
7.1.1. 6rd DHCPv4 Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_6RD | option-length | IPv4PrefixLen | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 6rdPrefix |
| (variable, up to 16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
option-code OPTION_6RD(TBD)
option-length the length of the DHCP option in octets
(between 7 and 22 octets).
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.
6rdPrefixLen The 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 sum of (32 - IPv4PrefixLen)
+ 6rdPrefixLen MUST be less than or equal
to 128. The 6rd implementation may further
limit the sum of these lengths to 64.
Townsley & Troan Expires July 10, 2010 [Page 9]
Internet-Draft 6rd January 2010
6rdBRIPv4Address The IPv4 address of the 6rd Border Relay
for a given 6rd domain (typically anycast).
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
6rdPrefix field (in octets) is determined
solely from the "option-length" field, by
subtracting 6 from the "option-length"
value.
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:
::/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)
7.2. Border Relay Configuration
The 6rd BR MUST be configured with the same 6rd elements as the 6rd
CEs operating within the same domain.
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.
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.
8. Neighbor Unreachability Detection
Neighbor Unreachability Detection (NUD) for tunnels is described in
Section 3.8 of [RFC4213]. In 6rd, all CEs and BRs can be considered
as connected to the same virtual link and therefore neighbors to each
Townsley & Troan Expires July 10, 2010 [Page 10]
Internet-Draft 6rd January 2010
other. This section describes how to utilize neighbor unreachability
detection without negatively impacting the scalability of a 6rd
deployment.
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.
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.
1. 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.
2. The desired Payload is encapsulated with the inner IPv6 and outer
IPv4 headers as follows:
* 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).
* 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.
* 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.
3. 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.
Townsley & Troan Expires July 10, 2010 [Page 11]
Internet-Draft 6rd January 2010
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).
4. 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).
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.
9. IPv6 in IPv4 Encapsulation
IPv6 in IPv4 encapsulation is done as specified in 6to4 [RFC3056] and
in Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213].
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.
The 6rd link is modeled as an NBMA[RFC2491] 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 [RFC4213]. However,
no communication using link-local addresses will occur.
9.1. Maximum Transmission Unit
MTU and fragmentation issues for IPv6 in IPv4 tunneling are discussed
in detail in section 3.2 of RFC4213 [RFC4213]. 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
RFC4213 [RFC4213] or the 6rd Tunnel MTU may be explicitly configured.
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
Townsley & Troan Expires July 10, 2010 [Page 12]
Internet-Draft 6rd January 2010
the 6rd Tunnel MTU SHOULD default to 1280 bytes.
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 Router Advertisements [RFC4861] messages to the 6rd
Tunnel MTU.
9.2. Receiving Rules
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.
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.
10. Transition Considerations
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.
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.
11. IPv6 Address Space Usage
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
Townsley & Troan Expires July 10, 2010 [Page 13]
Internet-Draft 6rd January 2010
2002::/16 is needed.
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.
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.
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.
12. Security Considerations
A 6to4 relay router as specified in RFC 3056 [RFC3056] 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 RFC3964 [RFC3964] do not apply.
When applying the receiving rules in Section 9.2, IPv6 packets are as
well protected against spoofing as IPv4 packets are within an SP
network.
Townsley & Troan Expires July 10, 2010 [Page 14]
Internet-Draft 6rd January 2010
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.
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.
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.
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.
13. IANA Considerations
IANA is requested to assign a new DHCP Option code point for
OPTION_6RD.
14. Acknowledgements
This draft is based on Remi Despres' original idea described in
[I-D.despres-6rd] 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, Jerry Huang, Fred
Templin, Dave Thaler, Eric Voit and David Ward.
15. References
Townsley & Troan Expires July 10, 2010 [Page 15]
Internet-Draft 6rd January 2010
15.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, January 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
15.2. Informative References
[I-D.despres-6rd]
Despres, R., "IPv6 Rapid Deployment on IPv4
infrastructures (6rd)", draft-despres-6rd-03 (work in
progress), April 2009.
[I-D.durand-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
"Dual-stack lite broadband deployments post IPv4
exhaustion", draft-durand-softwire-dual-stack-lite-01
(work in progress), November 2008.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
Townsley & Troan Expires July 10, 2010 [Page 16]
Internet-Draft 6rd January 2010
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Authors' Addresses
Mark Townsley
Cisco
Paris,
France
Email: mark@townsley.net
Ole Troan
Cisco
Bergen,
Norway
Email: ot@cisco.com
Townsley & Troan Expires July 10, 2010 [Page 17]
