Internet Engineering Task Force T. Tsou
Internet-Draft C. Zhou
Intended status: Standards Track T. Taylor
Expires: June 6, 2011 Huawei Technologies
Q. Chen
China Telecom
December 8, 2010
"Gateway-Initiated" 6rd
draft-tsou-softwire-gwinit-6rd-02
Abstract
This document proposes a modification to the 6rd deployment model for
IPv6. The basic 6rd model allows IPv6 hosts to gain access to IPv6
networks across an IPv4 access network using 6-in-4 tunnels. 6rd
requires support by a device (the 6rd CE) on the customer site, which
must also be assigned an IPv4 address. The alternative model
described in this document uses tunnels from operator-owned "6rd
Gateways" collocated with the operator's IPv4 network edge. The
tunnels may be provisioned or automatic. The advantages of this
approach are that it requires no modification to customer equipment
and avoids assignment of IPv4 addresses to customer equipment. It
also allows the 6rd prefix portion of the prefixes delegated to
customer devices to be longer than can generally be achieved by basic
6rd. The gateway initiated 6rd model reuses the protocol defined in
RFC 5969.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 6, 2011.
Copyright Notice
Tsou, et al. Expires June 6, 2011 [Page 1]
Internet-Draft "Gateway-Initiated" 6rd December 2010
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5
3.1. 6rd Prefix Delegation . . . . . . . . . . . . . . . . . . 6
3.2. Troubleshooting and Traceability . . . . . . . . . . . . . 7
3.3. Address Selection . . . . . . . . . . . . . . . . . . . . 8
3.4. Gateway Initiated 6rd Configuration . . . . . . . . . . . 8
3.4.1. Configuration For IPv6-in-IPv4 Tunneling . . . . . . . 8
3.4.2. Configuration For Other Tunneling Technologies . . . . 8
3.5. Transition Considerations . . . . . . . . . . . . . . . . 9
3.6. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . 9
3.7. Security Considerations . . . . . . . . . . . . . . . . . 9
3.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 9
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Normative References . . . . . . . . . . . . . . . . . . . 9
4.2. informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Tsou, et al. Expires June 6, 2011 [Page 2]
Internet-Draft "Gateway-Initiated" 6rd December 2010
1. Introduction
6rd [RFC5969] provides a transition tool for connecting IPv6 devices
across an IPv4 network to an IPv6 network, at which point the packets
can be routed natively. The network topology is shown in Figure 1.
+--------------+ +-----------------+ +---------+
| | | | | |
+-----+ +-----+ | Provider +--------+ | |
|IPv6 | | 6rd |__| IPv4 | Border |__| IPv6 |
|Host | | CE | | network | Relay | | network |
+-----+ +-----+ | +--------+ | |
| Customer LAN | | | | |
+--------------+ +-----------------+ +---------+
Figure 1: 6rd Deployment Topology
In Figure 1, the CE is the customer edge router. It is provisioned
with a delegated IPv6 prefix, but also with an IPv4 address so that
it is reachable through the IPv4 network. As a consequence, the
routers in the IPv4 network have to carry a route for every customer
site. In a large network, this can lead to very large routing
tables. Further, the need to provision an IPv4 address for every 6rd
user will aggravate the pressure due to IPv4 address shortage for
operators faced with a high rate of growth in the number of broadband
subscribers to their network.
1.1. 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 [RFC2119].
1.2. Terminology
6rd prefix As in [RFC5969], an IPv6 prefix selected by the service
provider for use by a 6rd domain.
customer device Either a single customer-owned router serving as the
interface between the customer network and the provider
network, or, in the absence of such a device, an individual
host in the customer network.
6rd Gateway A device functioning as a gateway initiated 6rd tunnel
endpoint, collocated with the provider IPv4 network edge. A
typical 6rd Gateway has virtual or point-to-point links to
many customer devices, an interface to the provider IPv4
network, and a virtual 6rd interface.
Tsou, et al. Expires June 6, 2011 [Page 3]
Internet-Draft "Gateway-Initiated" 6rd December 2010
gateway initiated 6rd delegated prefix The prefix calculated by the
network for delegation to a customer device, obtained by
combining the 6rd prefix, a 6rd Gateway Identifier used for
routing from the 6rd Border Relay to the serving 6rd Gateway,
and a Gateway-scoped customer device identifier. Like the
6rd delegated prefix in [RFC5969], this prefix can be
considered logically equivalent to a DHCPv6 IPv6 delegated
prefix [RFC3633].
6rd domain As in [RFC5969], with the substitution of the 6rd Gateway
for the 6rd CE as a component of the domain.
6rd Border Relay (BR) As in [RFC5969].
6rd virtual interface As in [RFC5969], with the substitution of the
6rd Gateway for the 6rd CE.
6rd Gateway IPv4 address The IPv4 address configured on the 6rd
Gateway as part of the provider network. This address may be
global or private [RFC1918] within the 6rd domain. If IPv6-
in-IPv4 tunnels are used, this address is used in compressed
form as the Gateway Identifier portion of the gateway
initiated 6rd delegated prefix.
2. Problem Statement
Consider a fixed broadband operator facing a high subscriber growth
rate. As a result of this growth rate, the operator faces pressure
on its stock of available public IPv4 addresses. For this reason,
the operator is motivated to offer IPv6 access as quickly as
possible.
The backbone network will be the first part of the operator's network
to support IPv6. The metro network is not so easily upgraded to
support IPv6 since many devices need to be modified and there may be
some impact to existing services. Thus any means of providing IPv6
access has to minimize the changes required to devices in the metro
network.
In contrast to the situation described for basic 6rd [RFC5569], the
operator is assumed to be unable to manage IP devices on the customer
premises. As a result, the operator cannot assume that any of these
devices are capable of supporting 6rd.
If the customer equipment is dual-stack, it will be natural for that
equipment to request IPv4 addresses, and pretty well impossible for
the operator to avoid assigning them. However, the operator has an
Tsou, et al. Expires June 6, 2011 [Page 4]
Internet-Draft "Gateway-Initiated" 6rd December 2010
opportunity to avoid assigning IPv4 addresses to customer devices
running IPv6 only, if some other means is available for routing IPv6
traffic through the IPv4 network to and from that site.
3. Proposed Solution
For basic 6rd, the 6rd-CE described in [RFC5969] initiates a 6-in-4
tunnel to the Border Relay to carry its IPv6 traffic. To avoid the
requirement for customer premises equipment to fulfill this role, it
is necessary to move the tunneling function to a network device.
This document identifies a functional element termed the 6rd Gateway
to perform this task. The functions of the 6rd Gateway are:
o to generate and allocate gateway initiated 6rd delegated prefixes
for IPv6-capable customer devices;
o to forward outgoing IPv6 packets through a tunnel to a Border
Relay, which extracts and forwards them to an IPv6 network as for
6rd;
o to extract incoming IPv6 packets tunneled from the 6rd Border
Relay and forward them to the correct user device.
In the proposed solution, there is only one tunnel between each 6rd
Gateway and the Border Relay, which greatly reduces the number of
tunnels the Border Relay has to handle. The deployment scenario
consistent with the problem statement in Section 2 collocates the
Gateway with the IP edge of the access network. This is shown in
Figure 2, and is the typical placement of the Broadband Network
Gateway (BNG) in a fixed broadband network. By assumption, the metro
network beyond the BNG is IPv4. Transport between the customer site
and the 6rd Gateway uses layer 2.
+-------+ +---------------------+ +---------+
+-----+ | | | | | |
|IPv6 | | | +---------+ IPv4 +--------+ | IPv6 |
|Cust |_|Access |_| 6rd GW | Metro | Border |_| core |
|Dev | |network| |(IP edge)| network | Relay | | network |
+-----+ | | +---------+ +--------+ | |
| | | | | |
+-------+ +---------------------+ +---------+
Figure 2: Gateway Initiated 6rd At the IP Edge
The elements of the proposed solution are these:
Tsou, et al. Expires June 6, 2011 [Page 5]
Internet-Draft "Gateway-Initiated" 6rd December 2010
o IPv6 packets are tunneled between the 6rd Gateway and the 6rd
Border Relay. The tunnel may be provisioned or may be an
automatic IPv6-in-IPv4 tunnel as in basic 6rd, depending on the
operator's requirements. Provisioned tunnels may cost less in
smaller-scale deployments, while automatic tunneling becomes
preferable as the number of customer devices and hence 6rd
Gateways in a 6rd domain becomes large.
o The IPv6 prefix delegated to the customer device contains a
Gateway identifier which the 6rd Border Relay can map to a tunnel
connecting to the serving 6rd Gateway. In the case of IPv6-in-
IPv4 tunnels, this identifier is the compressed 6rd Gateway IPv4
address, and the Border Relay uses the expanded address as the
IPv4 destination address for the encapsulated packets.
o The IPv6 prefix delegated to the customer device also contains an
index that is unique to that customer device. As a result, the
6rd Gateway can map the IPv6 destination address uniquely to the
Layer 2 address of the customer device, either on the basis of the
complete routing prefix or by extracting the the customer device
index portion of that prefix.
Incidentally to this, the 6rd Gateway serves as an IPv4 aggregation
point for all of the customer sites it serves.
3.1. 6rd Prefix Delegation
Referring back to Figure 2, prefix delegation to the customer
equipment occurs in the normal fashion through the Gateway/IP edge,
using SLAAC or DHCPv6. Each delegated prefix MUST contain a 6rd
prefix valid for the 6rd domain, the Gateway Identifier for the 6rd
Gateway, and an index that identifies the specific customer device.
Figure 3 shows the structure of a complete IPv6 address based on the
gateway initiated 6rd delegated prefix, in a form analogous to Figure
1 of [RFC5969].
| p bits | o bits | n bits |m bits | 128-p-o-n-m bits |
+----------------+------------+---------+-------+------------------+
| | Gateway |Customer | | |
| 6rd prefix | identifier | device |subnet | interface ID |
| | | index | ID | |
+-----------+------------+--------------+--------------------------+
|<------ GI 6rd delegated prefix ------>|
Figure 3: Gateway Initiated 6rd Delegated Prefix
The 6rd Gateway is responsible for generating the 6rd delegated
Tsou, et al. Expires June 6, 2011 [Page 6]
Internet-Draft "Gateway-Initiated" 6rd December 2010
prefix. The 6rd prefix portion is a preconfigured value (see
Section 3.4). The 6rd Gateway MUST append to this its configured
Gateway Identifier. In the case of IPv6-in-IPv4 tunneling, this
identifier will be the low-order bits of its IPv4 address on the
virtual link between itself and the Border Relay, where the number of
bits is based on the length of the IPv4 address mask for 6rd Gateway
addresses within the 6rd domain. Finally, the 6rd Gateway MUST
append an index value which is unique for each customer device to
which the 6rd Gateway delegates a prefix. The length of the index
value is configured on the 6rd Gateway (see Section 3.4). The index
value MAY be assigned permanently or MAY be assigned only for the
period during which the customer device is connected to the network.
With the present proposal, there is no concern about IPv4 address
lifetimes, as there is with basic 6rd. The Gateway/IP edge will be
assigned a permanent value for its Gateway identifier (e.g., IPv4
address), using the operator's normal network provisioning processes.
However, since the customer device is never assigned an IPv4 address,
AAA has to be modified to use the delegated IPv6 prefix to track the
customer.
3.2. Troubleshooting and Traceability
The operator can apply the normal tools for troubleshooting for the
portion of the path between the 6rd Gateway and the 6rd Border Relay,
depending on the tunneling technology that has been deployed. Since
no IPv4 address is assigned to individual customer devices, however,
IPv4-based tools cannot be used to identify debug problems extending
beyond the 6rd Gateway to the customer device. If the customer
device supports IPv6 anycast, it is possible to test end-to-end
connectivity from the 6rd BR using IPv6 Echo requests and responses.
If the device does not support IPv6 anycast, end-to-end testing
requires knowledge of a specific IPv6 address that the customer
device has assigned to its interface with the network.
For the purpose of such testing, the 6rd Border Relay needs an IPv6
address that it can identify as its own either in an ICMPv6 echo
request that it receives or in an echo response from the customer
device. The 6rd Gateway must be able to select the tunnel to the
correct 6rd BR based on this address. For IPv6-in-IPv4 tunneling,
these requirements can be met in the same way as in [RFC5969] if the
6rd Gateways and Border Relays in a 6rd domain share the same IPv4
address space and a common mask. For other tunneling technologies,
IPv6 prefixes for the BRs can be generated using the same principles
as for the prefixes assigned to customer devices provided that the
BRs are assigned identifiers within the Gateway Identifier numbering
space. The 6rd Gateways need to be able to map from Gateway
Identifiers to the corresponding BR tunnels.
Tsou, et al. Expires June 6, 2011 [Page 7]
Internet-Draft "Gateway-Initiated" 6rd December 2010
3.3. Address Selection
No change from [RFC5969].
3.4. Gateway Initiated 6rd Configuration
3.4.1. Configuration For IPv6-in-IPv4 Tunneling
For IPv6-in-IPv4 tunneling, Section 7 of [RFC5969] applies, except
that the 6rd Gateway rather than the 6rd CE is configured with the
IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, and 6rdBRIPv4Address. In
addition to these values, each 6rd Gateway MUST be configured with
CustDevIndexLen, the number of bits used to represent the customer
device index portion of the gateway initiated 6rd delegated prefix.
The IPv4MaskLen is redefined to be the number of high-order bits that
are identical across all IPv4 addresses assigned to 6rd Gateways in
the 6rd domain.
No special configuration of customer equipment, in particular,
customer edge routers, is required. Hence the 6rd DHCPv4 option is
inapplicable.
Border Relay configuration is unchanged from [RFC5969].
The discussion of Neighbour Unreachability Detection in [RFC5969] is
inapplicable.
The considerations on IPv6 in IPv4 encapsulation in Section 9 of
[RFC5969] apply with the substitution of the 6rd Gateway for the 6rd
CE.
3.4.2. Configuration For Other Tunneling Technologies
For other tunneling technologies, the following differences apply
relative to the previous section.
o IPv4MaskLen is generalized to GWIDLen, defined as the number of
bits in the Gateway Identifier portion of the delegated prefix.
o Each 6rd Gateway is configured with its own Gateway Identifier
value.
o For troubleshooting purposes (see Section 3.2), each 6rd Border
Relay is configured either with a complete IPv6 prefix the use of
which is restricted to the 6rd domain, or with a Gateway
Identifier value that it can use to construct such a prefix.
Correspondingly, the 6rd Gateways are configured with mappings
Tsou, et al. Expires June 6, 2011 [Page 8]
Internet-Draft "Gateway-Initiated" 6rd December 2010
between the BR prefixes (or their Gateway Identifier portion) and
the tunnels connecting to them.
3.5. Transition Considerations
No change from [RFC5969]. This technique can co-exist with dual-
stack operation at the customer site, assuming that the 6rd Gateway
is configured as the default outgoing gateway for IPv6 traffic.
3.6. IPv6 Address Space Usage
The discussion of Section 11 of [RFC5969] is modified with the
following example. In essence, the restriction of IPv4 addressing to
the 6rd Gateways rather than individual customer devices allows for a
greater degree of address compression, even if some of that is taken
back by the need to allocate bits for a customer device index.
To give a numerical example, consider a 6rd domain containing ten
million IPv6-capable customer devices (a rather high number given
that 6rd is meant for the early stages of IPv6 deployment). The
estimated number of 6rd Gateways needed to serve this domain would be
in the order of 3,300, each serving 30,000 customer devices.
Assuming best-case compression for the Gateway addresses, the Gateway
Identifier field has length o = 12 bits. If IPv6-in-IPv4 tunneling
is being used, this best case is more likely to be achievable than it
would be if the IPv4 addresses belonged to the customer devices.
More controllably, the customer device index has length n = 15 bits.
Overall, these figures suggest that the length p of the 6rd prefix
can be 29 bits for a /56 delegated prefix, or 21 bits if /48
delegated prefixes need to be allocated.
3.7. Security Considerations
No change from [RFC5969].
3.8. IANA Considerations
This memo makes no request of IANA.
4. References
4.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.
Tsou, et al. Expires June 6, 2011 [Page 9]
Internet-Draft "Gateway-Initiated" 6rd December 2010
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
4.2. informative References
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
Authors' Addresses
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: tena@huawei.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathyzhou@huawei.com
Tsou, et al. Expires June 6, 2011 [Page 10]
Internet-Draft "Gateway-Initiated" 6rd December 2010
Tom Taylor
Huawei Technologies
1852 Lorraine Ave.t
Ottawa, Ontario K1H 6Z8
Canada
Phone:
Email: tom111.taylor@bell.net
Qi Chen
China Telecom
109, Zhongshan Ave. West,
Tianhe District, Guangzhou 510630
P.R. China
Phone:
Email: chenqi.0819@gmail.com
Tsou, et al. Expires June 6, 2011 [Page 11]