One document matched: draft-tsou-softwire-gwinit-6rd-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3587 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml">
<!ENTITY RFC5569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5569.xml">
<!ENTITY RFC5969 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-tsou-softwire-gwinit-6rd-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->
<title>"Gateway-Initiated" 6rd</title>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>tena@huawei.com</email>
</address>
</author>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>cathyzhou@huawei.com</email>
</address>
</author>
<author fullname="Tom Taylor" initials="T." surname="Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>1852 Lorraine Ave.t</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K1H 6Z8</code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom111.taylor@bell.net</email>
</address>
</author>
<author fullname="Qi Chen" initials="Q." surname="Chen">
<organization>China Telecom</organization>
<address>
<postal>
<street>109, Zhongshan Ave. West,</street>
<city>Tianhe District, Guangzhou</city>
<code>510630</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>chenqi.0819@gmail.com</email>
</address>
</author>
<date year="2010" />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>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. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>6rd <xref target="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 <xref target="fig_6rd" />.
</t>
<figure anchor="fig_6rd" title="6rd Deployment Topology">
<artwork>
+--------------+ +-----------------+ +---------+
| | | | | |
+-----+ +-----+ | Provider +--------+ | |
|IPv6 | | 6rd |__| IPv4 | Border |__| IPv6 |
|Host | | CE | | network | Router | | network |
+-----+ +-----+ | +--------+ | |
| Customer LAN | | | | |
+--------------+ +-----------------+ +---------+
</artwork>
</figure>
<t> In <xref target="fig_6rd" />, 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. </t>
</section>
<section anchor="prob" title="Problem Statement">
<t>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.</t>
<t>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.</t>
<t>In contrast to the situation described for basic 6rd
<xref target="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.</t>
<t>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. </t>
<t>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. </t>
</section>
<section title="Proposed Solution">
<t> For basic 6rd, the 6rd-CE described in <xref target="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:
<list style="symbols">
<t>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.</t>
<t>to decapsulate incoming IPv6 packets and forward them to the correct
user site.</t>
</list>
</t>
<t>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 <xref target="prob"/> collocates the Gateway with the
IP edge of the access network. This is shown in <xref target="fig_BNG" />,
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. </t>
<figure anchor="fig_BNG" title="Gateway-Initiated 6rd At the IP Edge">
<artwork>
+-------+ +-------------------+ +---------+
+-----+ | | | | | |
|IPv6 | | | +---------+ IPv4 +--------+ | IPv6 |
|Cust |_|Access |_| Gateway | Metro | Border |_| core |
|site | |network| |(IP edge)| network | Router | | network |
+-----+ | | +---------+ +--------+ | |
| | | | | |
+-------+ +-------------------+ +---------+
</artwork>
</figure>
<t> The elements of the proposed solution are these:
<list style="symbols">
<t>The IPv6 prefix assigned to the customer site contains the IPv4 address
of the network-facing side of the Gateway.</t>
<t>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.</t>
<t>The Gateway can route incoming IPv6 packets to the correct link based on
the IPv6 destination address of the decapsulated packet.</t>
</list>
Incidental to this, the Gateway serves as an IPv4 aggregation point for all of
the pure IPv6 customer sites it serves.
</t>
<section title="Prefix Delegation">
<t>Referring back to <xref target="fig_BNG" />, 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 <xref target="RFC3587" />) is shown in <xref target="fig_addr" />.
</t>
<figure anchor="fig_addr" title="Suggested Customer Site Address Format">
<artwork>
+----------------------------------------------------------+
|001 | Global IPv6 | Subnet | Indic | IPv4 addr | Host |
| | routing prefix | | | | ID |
+----+----------------+--------+-------+-----------+-------+
| 3 | 45 bits |16 bits | N bits| 32 bits | 32 - N|
+----------------------------------------------------------+
</artwork>
</figure>
<t> The first 64 bits in <xref target="fig_addr" /> are as defined in
<xref target="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. </t>
<t> If the length of the prefix delegated to the customer site is a concern,
one could use the format shown in <xref target="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. </t>
<t> 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. </t>
</section>
<section title="Troubleshooting and Traceability">
<t> The first paragraph of Section 5 of <xref target="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. </t>
</section>
<section title="Address Selection">
<t> No change from <xref target="RFC5969" />. </t>
</section>
<section title="Gateway-Initiated 6rd Configuration">
<t> The Gateway/IP edge rather than the 6rd CE is
configured with the IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, and
6rdBRIPv4Address.</t>
<t> 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. </t>
<t> No special configuration of customer equipment, in particular,
customer edge routers, is required. Hence the 6rd DHCPv4 option is
inapplicable.</t>
<t> Border Relay configuration is unchanged, except if using an
alternative address format to that defined in <xref target="RFC5969"/>. </t>
<t> The discussion of Neighbour Unreachability Detection in
<xref target="RFC5969" /> is inapplicable. </t>
<t> The considerations on IPv6 in IPv4 encapsulation in Section 9 of
<xref target="RFC5969" /> apply with the substitution of the
Gateway/IP edge for the CE. </t>
</section>
<section title="Transition Considerations">
<t> No change from <xref target="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.</t>
</section>
<section title="IPv6 Address Space Usage">
<t> If the 6rd address format is used, there is no change from
Section 11 of <xref target="RFC5969" />. If the address format
follows the example given in <xref target="fig_addr" />,
the address space usage for 6rd is the same as that used for
ordinary IPv6 address assignments.</t>
</section>
<section title="Security Considerations">
<t> No change from <xref target="RFC5969" />. </t>
</section>
<section title="IANA Considerations">
<t> This memo makes no request of IANA. </t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC3587;
&RFC5969;
</references>
<references title="informative References">
&RFC5569;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:09:20 |