One document matched: draft-tsou-softwire-gwinit-6rd-05.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 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="info" submissionType="independent" docName="draft-tsou-softwire-gwinit-6rd-05" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
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>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone></phone>
<email>Tina.Tsou.Zouting@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>cathy.zhou@huawei.com</email>
</address>
</author>
<author fullname="Tom Taylor" initials="T." surname="Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region>Ontario</region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<author initials="O." surname="Troan" fullname="Ole Troan">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Telemarksvingen 20</street>
<code>N-0655</code>
<city>Oslo</city>
<region></region>
<country>Norway</country>
</postal>
<phone></phone>
<email>ot@cisco.com</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="2012" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the
year is not the current one, it is necessary to specify at least a month
(xml2rfc assumes day="1" if not specified for the purpose of calculating
the expiry date). With drafts it is normally sufficient to specify just
the year. -->
<!-- Meta-data Declarations -->
<area>General</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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> 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
<xref target="fig_topol"/>.</t>
<figure anchor="fig_topol" 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_topol"/>, 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. If a public IPv4 address
is provisioned to every customer, it 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. The use of private
addresses with 6rd avoids this particular difficulty, but brings other
complications. </t>
<section title="Requirements Language">
<t>This document uses no requirements language.</t>
</section>
</section>
<section anchor="probStat" 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. <xref target="fig_netCtxt"/> shows the
sort of network situation envisioned in the present document.</t>
<figure anchor="fig_netCtxt" title="Typical Network Scenario For IPv6 Transition">
<artwork>
+----+ +-------------------+ +----------------+
|Host|\ | | | |
+----+ \_+---+ +----+ Metro +----+ | Backbone |
_|CPE|----| GW | Network | BR |--| Network |
+----+ / +---+ +----+ (IPv4) +----+ | (IPv6) |
|Host|/ | | | |
+----+ +-------------------+ +----------------+
Host = IPv6 customer host device
CPE = customer edge device (customer-provided)
GW = provider edge device (Gateway)
BR = border router (dual stack)
</artwork>
<postamble>Specialized GW and BR functions are described in the next
section.</postamble>
</figure>
<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 have no control over
the capabilities of the 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 public IPv4 address in 6to4 or 6rd,
which puts great address pressure on the operators.</t>
<t>If the CPE in the above figure is acting in bridging mode, each host
behind it needs to be directly assigned an IPv6 prefix so it can access
IPv6 services. If the CPE is acting in routing mode, only the CPE needs
to be assigned an IPv6 prefix, and it delegates prefixes to the hosts
behind it.</t>
<t>If the Gateway supports IPv4 only, then an IPv4 address must also
be assigned to each host (bridging mode) or to the CPE (routing mode).
Both cases, but bridging mode in particular, put pressure on the
provider's stock of IPv4 addresses.</t>
<t>If the Gateway is dual stack, an arrangement may be possible whereby
all communication between the Gateway and the customer site uses IPv6
and the need to assign IPv4 addresses to customer devices is avoided.
A possible solution is presented in the next section.</t>
</section><!-- probStat -->
<section anchor="propSol" title="Proposed Solution">
<t>For basic 6rd <xref target="RFC5969"/>, the 6rd CE initiates
the 6-in-4 tunnel to the 6rd 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. In what follows, the 6rd
Gateway and 6rd Border Relay are referred to simply as the Gateway and
Border Relay respectively.</t>
<t>The functions of Gateway are:
<list style="symbols">
<t>to generate and allocate Gateway initiated 6rd delegated prefixes
for IPv6-capable customer devices, as described in
<xref target="prefix"/>.</t>
<t>to forward outgoing IPv6 packets through a tunnel to a Border Relay,
which extracts and forwards them to an IPv6 network as for 6rd;</t>
<t>to extract incoming IPv6 packets tunneled from the Border Relay
and forward them to the correct user device.</t>
</list>
</t>
<t>In the proposed solution, there is only one tunnel initiated from
each Gateway to 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 <xref target="probStat"/>
collocates the Gateway with the IP edge of the access network. This
is shown in <xref target="fig_netCtxt"/> above, 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>
<t>The elements of the proposed solution are these:
<list style="symbols">
<t>The IPv6 prefix assigned to the customer site contains the
compressed IPv4 address of the network-facing side of the Gateway,
plus a manually provisioned or Gateway-generated customer site
identifier. This is illustrated in <xref target="fig_addrFmt"/>
below.</t>
<t>The Border Relay is able to route incoming IPv6 packets to the
correct Gateway by extracting the compressed Gateway address from
the IPv6 destination address of the incoming packet, expanding it
to a full 32-bit IPv4 address, and setting it as the destination
address of the encapsulated packet.</t>
<t>The Gateway can route incoming packets to the correct link after
decapsulation using a mapping from either the full IPv6 prefix or
the customer site identifier extracted from that prefix to the
appropriate link.</t>
</list>
</t>
<section anchor="prefix" title="Prefix Delegation">
<t>Referring back to <xref target="fig_netCtxt"/>, prefix assignment to
the customer equipment occurs in the normal fashion through the Gateway/IP
edge, using either DHCPv6 or SLAAC. <xref target="fig_addrFmt"/>
illustrates the structure of the assigned prefix, and how the components
are derived, within the context of a complete address.</t>
<figure anchor="fig_addrFmt" title="Gateway-Initiated 6rd Address Format for a Customer Site">
<artwork>
+--------------------+-----------+
| 32 bit Gateway IPv4 address |
+--------------------+-----------+
|<---IPv4MaskLen --->| o bits | Gateway or manually
/ / generated value, unique
Configured / / / for the gateway
| / / |
| / / V
| V p bits | o bits | n bits |m bits | 64 bits |
+----------------+------------+---------+-------+----------------+
| | Gateway |Customer | | |
| Common prefix | identifier | site |subnet | interface ID |
| | | index | ID | |
+----------------+------------+---------+-------+----------------+
|<------ GI 6rd delegated prefix ------>|
</artwork>
</figure>
<t>The common prefix, i.e., the first p bits of the GI 6rd delegated
prefix, is configured in the Gateway. This part of the prefix is
common across multiple customers and multiple Gateways. Multiple
common prefix values may be used in a network either for service
separation or for scalability.</t>
<t>The Gateway Identifier is equal to the o low-order bits of the Gateway
IPv4 address on the virtual link to the Border Relay. The number of bits
o is equal to 32 - IPv4MaskLen, where the latter is the length of the IPv4
prefix from which the Gateway IPv4 addresses are derived. The value of
IPv4MaskLen is configured in both the Gateways and the Border Relays.</t>
<t>The Customer Site Index is effectively a sequence number assigned to an
individual customer site served by the Gateway. The value of the index for
a given customer site must be unique across the Gateway. The length n of
the Customer Site Index is provisioned in the Gateway, and must be large
enough to accommodate the number of customer sites that the Gateway is
expected to serve.</t>
<t>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.</t>
<t>Overall, these figures suggest that the length p of the common prefix
can be 29 bits for a /56 delegated prefix, or 21 bits if /48 delegated
prefixes need to be allocated.</t>
</section><!-- prefix -->
<section anchor="diffs" title="Relevant Differences From Basic 6rd">
<t>A number of the points in <xref target="RFC5969"/> apply with the
simple substitution of the Gateway for the 6rd CE. When it comes to
configuration, the definition of IPv4MaskLen changes, and there are
other differences as indicated in the previous section. Since special
configuration of customer equipment is not required, the 6rd DHCPv6
option is inapplicable.</t>
<t>Since the link for the customer site to the network now extends only
as far as the Gateway, Neighbour Unreachability Detection on the part of
customer devices is similarly limited in scope.</t>
</section><!-- diffs -->
</section><!-- propSol -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>No change from <xref target="RFC5969"/>.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
&RFC5969;
</references>
<references title="Informative References">
&RFC5569;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:09:30 |