"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.

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
2.  Problem Statement
3.  Proposed Solution
    3.1.  Prefix Delegation
    3.2.  Troubleshooting and Traceability
    3.3.  Address Selection
    3.4.  Gateway-Initiated 6rd Configuration
    3.5.  Transition Considerations
    3.6.  IPv6 Address Space Usage
    3.7.  Security Considerations
    3.8.  IANA Considerations
4.  References
    4.1.  Normative References
    4.2.  informative References
§  Authors' Addresses

1.  Introduction

6rd [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.) 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 (6rd Deployment Topology).

   +--------------+     +-----------------+      +---------+
   |              |     |                 |      |         |
+-----+        +-----+  | Provider   +--------+  |         |
|IPv6 |        | 6rd |__|   IPv4     | Border |__|  IPv6   |
|Host |        |  CE |  |  network   | Router |  | network |
+-----+        +-----+  |            +--------+  |         |
   | Customer LAN |     |                 |      |         |
   +--------------+     +-----------------+      +---------+

In Figure 1 (6rd Deployment Topology), 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] (Despres, R., “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” January 2010.), 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 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] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.) 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:

• 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.
• 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 (Problem Statement) collocates the Gateway with the IP edge of the access network. This is shown in Figure 2 (Gateway-Initiated 6rd At the IP Edge), 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 |
+-----+ |       | +---------+         +--------+ |         |
        |       |     |                   |      |         |
        +-------+     +-------------------+      +---------+

The elements of the proposed solution are these:

• The IPv6 prefix assigned to the customer site contains the IPv4 address of the network-facing side of the Gateway.
• 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.
• 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 (Gateway-Initiated 6rd At the IP Edge), 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] (Hinden, R., Deering, S., and E. Nordmark, “IPv6 Global Unicast Address Format,” August 2003.)) is shown in Figure 3 (Suggested Customer Site Address Format).

+----------------------------------------------------------+
|001 | Global IPv6    | Subnet | Indic | IPv4 addr |  Host |
|    | routing prefix |        |       |           |   ID  |
+----+----------------+--------+-------+-----------+-------+
| 3  |    45 bits     |16 bits | N bits|  32 bits  | 32 - N|
+----------------------------------------------------------+

The first 64 bits in Figure 3 (Suggested Customer Site Address Format) are as defined in [RFC3587] (Hinden, R., Deering, S., and E. Nordmark, “IPv6 Global Unicast Address Format,” August 2003.). 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] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.). 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.

3.2.  Troubleshooting and Traceability

The first paragraph of Section 5 of [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.) 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] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.).

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] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.).

The discussion of Neighbour Unreachability Detection in [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.) is inapplicable.

The considerations on IPv6 in IPv4 encapsulation in Section 9 of [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.) apply with the substitution of the Gateway/IP edge for the CE.

3.5.  Transition Considerations

No change from [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.). 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.

3.6.  IPv6 Address Space Usage

If the 6rd address format is used, there is no change from Section 11 of [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.). If the address format follows the example given in Figure 3 (Suggested Customer Site Address Format), 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] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.).

3.8.  IANA Considerations

This memo makes no request of IANA.

4.  References

4.1. Normative References

4.2. informative References

Authors' Addresses