One document matched: draft-tsou-softwire-gwinit-6rd-01.txt
Differences from draft-tsou-softwire-gwinit-6rd-00.txt
Internet Engineering Task Force T. Tsou
Internet-Draft C. Zhou
Intended status: Standards Track T. Taylor
Expires: April 28, 2011 Huawei Technologies
Q. Chen
China Telecom
October 25, 2010
"Gateway-Initiated" 6rd
draft-tsou-softwire-gwinit-6rd-01
Abstract
This document proposes an alternative 6rd deployment model to that of
RFC 5969. 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 initiates the 6-in-4 tunnels from an
operator-owned gateway collocated with the operator's IPv4 network
edge, rather than from customer equipment. The advantages of this
approach are that it requires no modification to customer equipment
and avoids assignment of IPv4 addresses to customer equipment. The
latter point means less pressure on IPv4 addresses in a high-growth
environment, as well as smaller IPv4 routing tables.
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 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Tsou, et al. Expires April 28, 2011 [Page 1]
Internet-Draft "Gateway-Initiated" 6rd October 2010
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
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Prefix Delegation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Troubleshooting and Traceability . . . . . . . . . . . . . 6
3.3. Address Selection . . . . . . . . . . . . . . . . . . . . . 6
3.4. Gateway-Initiated 6rd Configuration . . . . . . . . . . . . 6
3.5. Transition Considerations . . . . . . . . . . . . . . . . . 6
3.6. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . 7
3.7. Security Considerations . . . . . . . . . . . . . . . . . . 7
3.8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Normative References . . . . . . . . . . . . . . . . . . . 7
4.2. informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Tsou, et al. Expires April 28, 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 |
|Host | | 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. 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.
2. Problem Statement
Consider an 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 in bridged mode and IPv6 is deployed to
Tsou, et al. Expires April 28, 2011 [Page 3]
Internet-Draft "Gateway-Initiated" 6rd October 2010
sites via a Service Provider's (SP's) IPv4 network, the IPv6-only
host needs a IPv6 address to visit the IPv6 service. In this
scenario, 6to4 or 6RD can be used. However, each IPv6-only host may
need one corresponding IPv4 address when using 6to4 or 6RD, which
brings great address pressure to the operators.
If the customer equipment is in routing mode, the operator has an
opportunity to avoid assigning IPv4 addresses to sites running IPv6
only. Some other means is available for routing IPv6 traffic through
the IPv4 network to that site.
3. Proposed Solution
For basic 6rd, the 6rd-CE described in [RFC5969] initiates the 6-in-4
tunnel to the Border Router 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 Gateway to
perform this task. The functions of the Gateway are:
o to encapsulate outgoing IPv6 packets in an IPv4 tunnel to a Border
Router, whence it is decapsulated and forwarded to an IPv6 network
as for 6rd.
o to decapsulate incoming IPv6 packets and forward them to the
correct user site.
In the proposed solution, there is only one tunnel initiated from
each Gateway to the Border Router which greatly reduces the number of
tunnels the Border Router 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 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
Tsou, et al. Expires April 28, 2011 [Page 4]
Internet-Draft "Gateway-Initiated" 6rd October 2010
The elements of the proposed solution are these:
o The IPv6 prefix assigned to the customer site contains the IPv4
address of the network-facing side of the Gateway.
o The Border Router is able to route incoming IPv6 packets to the
correct Gateway by extracting the Gateway's address from the IPv6
destination address before encapsulating the packet.
o The Gateway can route incoming IPv6 packets to the correct link
based on the IPv6 destination address of the decapsulated packet.
Incidental to this, the Gateway serves as an IPv4 aggregation point
for all of the pure IPv6 customer sites it serves.
3.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 or SLAAC. In the 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 3.
+----------------------------------------------------------+
|001 | Global IPv6 | Subnet | Indic | IPv4 addr | Host |
| | routing prefix | | | | ID |
+----+----------------+--------+-------+-----------+-------+
| 3 | 45 bits |16 bits | N bits| 32 bits | 32 - N|
+----------------------------------------------------------+
Figure 3: Suggested Customer Site Address Format
The first 64 bits in Figure 3 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. 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 the length of the prefix delegated 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.
Tsou, et al. Expires April 28, 2011 [Page 5]
Internet-Draft "Gateway-Initiated" 6rd October 2010
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.
3.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.
3.3. Address Selection
No change from [RFC5969].
3.4. Gateway-Initiated 6rd Configuration
The Gateway/IP edge rather than the 6rd CE is 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, except if using an
alternative address format to that defined in [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 Gateway/IP edge for the
CE.
3.5. Transition Considerations
No change from [RFC5969]. This technique can co-exist with dual-
stack operation at the customer site, assuming that the Gateway is
configured as the default outgoing gateway for IPv6 traffic.
Tsou, et al. Expires April 28, 2011 [Page 6]
Internet-Draft "Gateway-Initiated" 6rd October 2010
3.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 3, the address space usage for 6rd is the same as that used
for ordinary IPv6 address assignments.
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
[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.
[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
Tsou, et al. Expires April 28, 2011 [Page 7]
Internet-Draft "Gateway-Initiated" 6rd October 2010
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathyzhou@huawei.com
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 28, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 02:47:54 |