Internet Engineering Task Force T. Tsou
Internet-Draft C. Zhou
Intended status: Standards Track T. Taylor
Expires: April 19, 2011 Huawei Technologies
Q. Chen
China Telecom
October 16, 2010
"Gateway-Initiated" 6rd
draft-tsou-softwire-gwinit-6rd-00
Abstract
This document proposes a modification to the 6rd deployment model for
IPv6. This model extends existing access tunnels beyond an operator-
owned gateway collocated with the operator's IPv4 network edge to the
Border Router. This modification makes it unnecessary to provide
IPv4 routes to IPv6 UEs. The gateway serves as an aggregation point
for IPv4 routing.
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 April 19, 2011.
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
(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
Tsou, et al. Expires April 19, 2011 [Page 1]
Internet-Draft "Gateway-Initiated" 6rd October 2010
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
2. An Alternative Proposal . . . . . . . . . . . . . . . . . . . . 3
2.1. Prefix Delegation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Troubleshooting and Traceability . . . . . . . . . . . . . 6
2.3. Address Selection . . . . . . . . . . . . . . . . . . . . . 6
2.4. Gateway-Initiated 6rd Configuration . . . . . . . . . . . . 6
2.5. Transition Considerations . . . . . . . . . . . . . . . . . 6
2.6. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . 6
2.7. Security Considerations . . . . . . . . . . . . . . . . . . 7
2.8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Normative References . . . . . . . . . . . . . . . . . . . 7
3.2. informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Tsou, et al. Expires April 19, 2011 [Page 2]
Internet-Draft "Gateway-Initiated" 6rd October 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 |
| UE | | CE | | network | Router | | 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. The IPv6 prefix of all the users are the same for one ISP,
which is less than 32 bits.
In 6RD [RFC5969], the IPv4 address of CPE included in the host's IPv6
address is allocated by ISP. Every host needs an IPv4 address (even
if the terminals in the Customer Network are all IPv6) which may
bring great pressure of IPv4 address shortage for the operators with
the number of broadband subscribers increasing at high speed.
2. An Alternative Proposal
To release the pressure of IPv4 address shortage, some ISP starts to
provide IPv6 access. The backbone network will first support IPv6 in
this case. The metro network is not easily to be upgraded to support
IPv6 since many devices need to be modified and there may be some
impact to the existing services. This proposal only modifies the IP
edge device to provide IPv6 access without changing other network
devices in the metro network.
The number of IPv4 routes can be drastically reduced if the customer
end of the tunnel is moved to the gateway between IPv6 on the
customer side and the IPv4 network. There is only one tunnel
initiated from each Gateway to the Border Router which greatly
reduces the tunnel numbers. There are two possible deployment
scenarios. The first, shown in Figure 2, collocates the gateway with
Tsou, et al. Expires April 19, 2011 [Page 3]
Internet-Draft "Gateway-Initiated" 6rd October 2010
the IP edge, with the IPv4 network immediately beyond. This is the
typical placement of the Broadband Network Gateway (BNG) in a fixed
broadband network, where the metro network beyond the BNG is IPv4.
Transport between the customer site and the gateway is over layer 2.
+-------+ +-------------------+ +---------+
+-----+ | | | | | |
|IPv6 | | | +---------+ IPv4 +--------+ | IPv6 |
|Cust |_|Access |_| Gateway | Metro | Border |_| core |
|site | |network| |(IP edge)| network | Router | | network |
+-----+ | | +---------+ +--------+ | |
| | | | | |
+-------+ +-------------------+ +---------+
Figure 2: Gateway-Initiated 6rd At the IP Edge
An alternative deployment assumes that the IP network closest to the
customer site is IPv6, but an IPv4 network further out has to be
traversed to reached further IPv6 networks. This is shown in
Figure 3. In terms comparable to Figure 2, in this case the metro
network is running IPv6, the core network is running IPv4, and the
Border Router is needed to pass onto adjacent IPv6 metro networks or
IPv6 networks belonging other operators. This deployment has a
relatively straightforward solution and is out of scope of the
present document.
+-------+ +------------+ +--------------+
| | | | | |
+-----+ | | +----+ IPv6 | +----+ IPv4 +--------+
|Cust |_|Access |_| IP | Metro |_| GW | core | Border |
|site | |network| |edge| network | | | network | Router |
+-----+ | | +----+ | +----+ +----+---+
| | | | | | |
+-------+ +------------+ +--------------+ |
|
+-------+ |
| Other |__|
| IPv6 |
|network|
+-------+
Figure 3: Gateway-Initiated 6rd Beyond the IP Edge
In both deployment scenarios, the Gateway serves as an IPv4
aggregation point for all of the customer sites it serves.
Tsou, et al. Expires April 19, 2011 [Page 4]
Internet-Draft "Gateway-Initiated" 6rd October 2010
2.1. Prefix Delegation
Referring back to Figure 2, prefix assignment to the customer
equipment occurs in the normal fashion through the Gateway/IP edge,
using either PPPoEv6 or DHCPv6. For the bridged mode CPE, the prefix
is delegated in the last 64 bits of IPCPv6 message in PPPoE method or
acquired through DHCP Server with the BNG's IPv4 address (or IPv4
address designated by BNG) included in the last 64 bits of the
delegated 128 bits IPv6 address. When the CPE is in routed mode,
there are two ways to delegate the prefix. The first is to allocate
128 bits IPv6 address to the host and CPE should have the IPv4
address in advance. Another way is to allocate prefix only to the
host and the host needs to know the BNG's IPv4 address (or the IPv4
address designated by BNG). In spirit of 6rd, the prefixes contain
the 32-bit IPv4 address assigned to the gateway. An example format
(derived from the IPv6 unicast address structure [RFC3587]) is shown
in Figure 4.
+----------------------------------------------------------+
|001 | Global IPv6 | Subnet | Indic | IPv4 addr | Host |
| | routing prefix | | | | ID |
+----+----------------+--------+-------+-----------+-------+
| 3 | 45 bits |16 bits | N bits| 32 bits | 32 - N|
+----------------------------------------------------------+
Figure 4: Suggested Customer Site Address Format
The first 64 bits in Figure 4 are as defined in [RFC3587]. The N-bit
Indicator field which comes next is defined for operator use. The
operator will assign a specific indicator value to designate the
customer site address format which includes the IPv4 address of the
Gateway/IP edge or the IPv4 address designated by the Gateway/IP edge
as shown above. Other indicator values could be used to designate
alternative address formats. The indicator field is followed by the
32-bit IP address of the Gateway/IP edge (e.g., the BNG) and then by
a host identifier that uses the remaining 32 - N bits.
If prefix delegation to the customer site is a concern, one could use
the format shown in [RFC5969]. However, this requires a much-
shortened global IPv6 routing prefix, and hence a much higher degree
of IPv6 route aggregation. That may or may not be practical for a
given operator.
With the present proposal, there is no concern about DHCPv6 lease
times. The Gateway/IP edge will be assigned a permanent IPv4
address, using the operator's normal network provisioning processes.
Tsou, et al. Expires April 19, 2011 [Page 5]
Internet-Draft "Gateway-Initiated" 6rd October 2010
2.2. Troubleshooting and Traceability
The first paragraph of Section 5 of [RFC5969] on traceability applies
equally well to the present proposal. The second paragraph, on
support of anycast addressing, applies with the substitution of the
Gateway for the 6rd CE, and use of the Gateway's assigned IPv4
address to derive the virtual interface address.
2.3. Address Selection
No change from [RFC5969].
2.4. Gateway-Initiated 6rd Configuration
It is the Gateway/IP edge rather than the 6rd CE that must be
configured with the IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, and
6rdBRIPv4Address.
The IPv4MaskLen is redefined to be the number of high-order bits that
are identical across all IPv4 addresses assigned to network nodes in
the IPv4 network.
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.
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 Gateway/IP edge for the
CE.
2.5. Transition Considerations
No change from [RFC5969].
2.6. IPv6 Address Space Usage
If the 6rd address format is used, there is no change from Section 11
of [RFC5969]. If the address format follows the example given in
Figure 4, the address space usage for 6rd is the same as that used
for ordinary IPv6 address assignments.
Tsou, et al. Expires April 19, 2011 [Page 6]
Internet-Draft "Gateway-Initiated" 6rd October 2010
2.7. Security Considerations
No change from [RFC5969].
2.8. IANA Considerations
This memo makes no request of IANA.
3. References
3.1. Normative References
[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.
3.2. informative References
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 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 April 19, 2011 [Page 7]
Internet-Draft "Gateway-Initiated" 6rd October 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 April 19, 2011 [Page 8]