One document matched: draft-zhou-dime-4over6-provisioning-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 RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC6333 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6333.xml">
<!ENTITY RFC6733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.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-zhou-dime-4over6-provisioning-01" 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 abbrev="AVPs For 4over6 CPE Provisioning">Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions</title>
<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 initials="T." surname="Taylor" fullname="T. Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<author fullname="Qiong Sun" initials="Q." surname="Sun">
<organization>China Telecom</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>P.R.China</country>
</postal>
<phone>86 10 58552936</phone>
<email>sunqiong@ctbri.com.cn</email>
</address>
</author>
<date year="2013" />
<!-- 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. -->
<keyword>DS-Lite</keyword>
<keyword>Public IPv4 Over IPv6</keyword>
<keyword>Light-Weight 4over6</keyword>
<keyword>MAP-E</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>During the transition from IPv4 to IPv6, customer equipment may
have to support one of the various transition methods that have been
or are currently being defined for carrying IPv4 packets over IPv6.
Work is currently in progress to enumerate the information that needs
to be provisioned on a customer edge router to support a list of
transition techniques based on tunneling IPv4 in IPv6, with a view to
defining reusable components for a reasonable transition path between
these techniques. To the extent that the provisioning is done
dynamically, AAA support is needed to provide the information to the
network server responsible for passing the information to the customer
equipment. This document specifies Diameter attribute-value pairs to be
used for that purpose. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>A number of transition technologies have been or are being defined
to allow IPv4 packets to pass between hosts and IPv4 networks over an
intervening IPv6 network while minimizing the number of public IPv4
addresses that need to be consumed by the hosts. Different operators
will deploy different technologies, and sometimes one operator will
use more than one technology, depending on what is supported by the
available equipment and upon other factors both technical and
economic. </t>
<t>Each technique requires the provisioning of some subscriber-
specific information on the customer edge device. The provisioning may
be by DHCP or by some other method. This document is indifferent to
the specific provisioning technique used, but assumes that the
information originates in the AAA infrastructure because in some networks,
the user configuration information may be managed by AAA (Authentication,
Authorization, and Accounting) servers. In a fixed line broadband
network, the Broadband Network Gateways (BNGs) act as the access
gateway of users. When the BR and BNG are co-located in one device, the approach
defined in <xref target="I-D.ietf-softwire-map-radius"/> could be used to acquire
the subscriber-specific information via Radius. In some deployments when the
location of the BR is higher than BNG, the subscriber-specific information
will be pushed from AAA server to the BR actively via Diameter <xref target="RFC6733"/>.
To allow the information to be carried in Diameter , this
document specifies a number of attribute-value pairs (AVPs) for the
purpose. </t>
<t>This document takes as its scope the set of transition methods
provided for by <xref target="I-D.ietf-softwire-unified-cpe"/>. That
document enumerates the information that must be provisioned in the
customer edge router to support Dual-Stack Lite <xref target="RFC6333"/>,
Public IPv4 Over IPv6
<xref target="I-D.ietf-softwire-public-4over6"/>,
Light Weight IPv4 Over IPv6 (LW4o6)
<xref target="I-D.ietf-softwire-lw4over6"/>,
and Mapping of Address and Port with Encapsulation (MAP-E)
<xref target="I-D.ietf-softwire-map"/>.</t>
<t>Several documents provide related specifications for RADIUS <xref
target="RFC2865"/>, for individual transition methods. Potentially
there could be a reconciliation between the contents of those
documents and the present one, but that has not been done in the
present version of this document.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="reqts" title="Description of the Parameters Required By Each Transition Method">
<t>This section reviews the parameters that need to be provisioned for
each of the transition methods listed above. This enumeration provides
the justification for the AVPs defined in the next section. Since most
of the transition methods dealt with here are works in progress, this
section is subject to modification in future versions.</t>
<section anchor="dslite" title="Parameters For Dual-Stack Lite">
<t>Dual-Stack Lite is documented in <xref target="RFC6333"/>. It
requires the following parameters to be provisioned at the B4 at the
customer premises. This enumeration does not include the normal
provisioning of an IPv6 prefix to the customer equipment. The section
numbers shown are where these requirements are indicated in
<xref target="RFC6333"/>.
<list style="symbols">
<t>IPv6 address of the border router (AFTR) (sec. 5.4);</t>
<t>IPv6 address of a DNS recursive server (sec. 5.5). This is probably
supplied already independently of transition technology, so does not
have to be covered here.</t>
<t>an indicator that DS-Lite is to be used rather than some other
transition method (sec. 5.6). Note that <xref target="RFC6333"/>
says that the choice should be made by unspecified means during
initialization, while <xref target="I-D.ietf-softwire-unified-cpe"/>
specifies how to infer the intended method from other DHCP
parameters received. Thus the indicator suggested here may not come
from AAA.</t>
<t>optionally, the IPv4 address of the B4 interface facing the
tunnel, where the default value in the absence of provisioning is
192.0.0.2 and valid values are 192.0.0.2 through 192.0.0.7
(sec. 5.7).</t>
</list>
</t>
<t>The AFTR may also require an item of per-subscriber information
(sec. 8.1):
<list style="symbols">
<t>the identity of the NAT pool to which the subscriber is to be
assigned.</t>
</list>
</t>
</section> <!-- dslite -->
<section anchor="pub4o6" title="Public IPv4 Over IPv6">
<t>Public IPv4 Over IPv6 is described in
<xref target="I-D.ietf-softwire-public-4over6"/>. Besides the usual
IPv6 prefix or address information, it requires two parameters to be
provisioned to the customer equipment:
<list style="symbols">
<t>a public IPv4 address;</t>
<t>IPv6 address of the border router</t>
</list>
It also requires per-subscriber provisioning on the border router:
<list style="symbols">
<t>binding between the customer IPv4 address and the customer
IPv6 prefix, for routing of incoming packets to the correct tunnel.</t>
</list>
</t>
</section> <!-- pub4o6 -->
<section anchor="lw4o6" title="Light Weight IPv4 Over IPv6 (LW4o6)">
<t>Light Weight IPv4 Over IPv6 (LW4o6) is documented in
<xref target="I-D.ietf-softwire-lw4over6"/>. Its
provisioning requirements are exactly the same as those for Public
4over6 with one addition:
<list style="symbols">
<t>both the customer equipment and the border router are provided with
a port set identifier identifying the set of ports to which the
subscriber's incoming and outgoing packets on the public side are
restricted. The port selection algorithm and port set identifier as
such are not discussed in the draft. For the present version of this
document, it is assumed that the algorithm is known in advance and the
port set identifier has the form of an index ranging from zero to the
number of subscribers sharing a given address less 1. This is similar
to the port set identifier in MAP-E, described next.</t>
</list>
</t>
</section> <!-- lw4o6 -->
<section anchor="map-e" title="Mapping of Address and Port with Encapsulation (MAP-E)">
<t>Mapping of Address and Port with Encapsulation (MAP-E) is described
in <xref target="I-D.ietf-softwire-map"/>. MAP-E requires the
provisioning of the following per-subscriber information at the
customer edge device:
<list style="symbols">
<t>whether the device is to operate in mesh or hub-and-spoke mode;</t>
<t>the IPv6 address of the border router, also known as the Default
Mapping rule;</t>
<t>the specially constructed End-user IPv6 prefix for the customer
edge device. <xref target="I-D.ietf-softwire-map"/> suggests that this
would be supplied as part of normal IPv6 provisioning, so it can be
ignored as a requirement here. </t>
<t>the Basic Mapping Rule for the customer edge device. This
includes the following parameters:
<list style="symbols">
<t>the rule IPv6 prefix and length;</t>
<t>the rule IPv4 prefix and length;</t>
<t>the number of "Extended Address" (EA) bits included in the
End-user IPv6 prefix;</t>
<t>of those Extended Address bits, the number that precede the port
set identifier. This is currently a matter of discussion, whether it
should default to 4 or 6 or be fixed at either of these values.</t>
</list>
</t>
<t>in mesh mode only, zero or more Forwarding Mapping Rules,
containing the same parameters as the Basic Mapping rule.</t>
<t>optionally, the port set identifier if the EA bits do carry it.</t>
</list>
</t>
<t>The border router needs to be configured with the superset of the
Forwarding MAP Rules passed to the customer sites it serves. Since
this is not subscriber-specific, even though it introduces no new
requirements to this document, it is out of scope.</t>
</section> <!-- map-e -->
<section anchor="sumreq" title="Summing Up">
<t>It appears that the following items are common to two or more
methods and should therefore be specified in method-independent
fashion:
<list style="symbols">
<t>the IPv6 address of the border router;</t>
<t>an IPv4 prefix and length (could be a /32);</t>
<t>a port set identifier;</t>
<t>tentatively, a method indicator, indicating which of the
above transition methods the customer edge device must use.</t>
</list>
</t>
<t>The remaining requirements are method-specific:
<list style="symbols">
<t>for DS-Lite, the identity of the NAT pool to which the subscriber
is assigned;</t>
<t>for Public 4over6 and LW4o6, a binding between a customer IPv6
prefix or address and an IPv4 address;</t>
<t>for MAP-E, the indication of whether mesh mode or hub-and-spoke
mode is to be used;</t>
<t>for MAP-E, a Grouped AVP expressing a MAP Rule.</t>
</list></t>
</section> <!-- sumreq -->
</section> <!-- reqts -->
<section anchor="AVPdefs" title="Attribute-Value Pair Definitions">
<t>This section provides the specifications for the AVPs needed to
meet the requirements summarized in <xref target="sumreq"/>. Within
the context of their usage, all of these AVPs MUST have the M bit set
and the V bit cleared.</t>
<section anchor="braddr" title="Border Router IPv6 Address">
<t>The Border-Router-IPv6-Address (AVP Code TBD01) is of type Address
as defined in Section 4.3 of <xref target="RFC6733"/> and contains the
IPv6 address of a border router supporting an IPv6 transition method
which will be used by the customer edge device on which this address
is provisioned. The address MAY be an anycast address. Since the
content is an IPv6 address, the AVP Length MUST be set to 26 and the
first two octets MUST contain 0x0002 (IPv6). </t>
</section> <!-- braddr -->
<section anchor="v4pref" title="IPv4 Prefix or Address">
<t>The IPv4-Prefix-Or-Addr (AVP Code TBD02) is derived from base type
OctetString. It is a discriminated union representing the combination
of the prefix length (number of bits) in the first octet, followed by
the prefix itself, most significant octet first, padded with zeroes at
the low-order end to an octet boundary. Valid values of the prefix
length are from 0 to 32, where 0 indicates that the prefix is absent
and 32 indicates a complete address. Correspondingly, the AVP Length
can range from 9 to 13.</t>
</section> <!-- v4pref -->
<section anchor="v6pref" title="IPv6 Prefix or Address">
<t>The IPv6-Prefix-Or-Addr (AVP Code TBD03) is derived from base type
OctetString. It is a discriminated union representing the combination
of the prefix length (number of bits) in the first octet, followed by
the prefix itself, most significant octet first, padded with zeroes at
the low-order end to an octet boundary. Valid values of the prefix
length are from 0 to 128, where 0 indicates that the prefix is absent
and 128 indicates a complete address. Correspondingly, the AVP Length
can range from 9 to 25.</t>
</section> <!-- v6pref -->
<section anchor="psid" title="Port Set Identifier">
<t>The Port-Set-Identifier AVP (AVP Code TBD04) is of type Unsigned32
and indicates a set of ports defined by an otherwise-specified
algorithm. For a given shared address, each Port-Set-Identifier value
MUST identify a separate set of ports. AVP Length for the
Port-Set-Identifier AVP MUST be set to 12.</t>
</section> <!-- psid -->
<section anchor="method" title="Transition Method Indicator">
<t>The Transition-Method AVP (AVP Code TBD05) is of type Enumerated
and indicates the IPv6 transition method to be used. This document
specifies the following values:
<list style="empty">
<t>0 NO_METHOD</t>
<t>1 DUAL_STACK</t>
<t>2 DS_LITE</t>
<t>3 PUBLIC_4OVER6</t>
<t>4 LIGHT_WEIGHT_4OVER6</t>
<t>5 MAP_WITH_ENCAPSULATION</t>
</list>
NO_METHOD indicates that the network will not support any transition
method, and expects only IPv6 packets. DUAL_STACK indicates that the
network will accept either IPv4 or IPv6 packets. [Maybe references
should be added for the other values?] </t>
<t>The AVP Length for the Transition-Method AVP MUST be set to 12.</t>
</section> <!-- method -->
<section anchor="poolid" title="NAT Pool Identifier">
<t>NAT-Poolid (AVP Code TBD06) is of type Unsigned32 and indicates
the NAT pool on a network-based NAT to which a subscriber is to be
assigned. The set of valid values for this AVP is a local matter.
The AVP Length for the NAT-Poolid AVP MUST be set to 12.</t>
</section> <!-- poolid -->
<section anchor="binding" title="Binding Between An IPv4 Address and IPv6 Address/Prefix Assigned to a Customer Edge Device">
<t>4to6-Binding (AVP Code TBD07) is of type Grouped. It provides an
IPv4 address or prefix assigned to a customer edge device, a
corresponding IPv6 address or prefix assigned to the tunnel interface
at the customer edge device, and, if the IPv4 address is shared, a
port set identifier indicating the valid set of ports for this
customer edge device. The contents of the 4to6-Binding AVP are
required at the border router when Public 4over6 or Light-Weight
4over6 is being used. </t>
<t>If the port set identifier is present, the IPv4 address MUST be
a full IPv4 address. The port set identifier is relevant only if
Light-Weight 4over6 is being used.</t>
<t>The syntax of the 4to6-Binding AVP is given as follows, where
the component AVPs were defined above. The final *[ AVP ] component
is added for extensibility.</t>
<figure anchor="fig_4to6" title="">
<artwork>
4to6-Binding ::= < AVP Header: TBD07 >
{ IPv4-Prefix-Or-Addr }
{ IPv6-Prefix-Or-Addr }
0*1{ Port-Set-Identifier }
*[ AVP ]
</artwork>
</figure>
</section> <!-- binding -->
<section anchor="maprule" title="MAP Rule AVP">
<t>The MAP-Rule AVP (AVP Code TBD08) is of type Grouped, and is used
only in conjunction with the MAP-E transition method. MAP rules are
required both by the border router and by the customer edge device.
The components of the MAP-Rule AVP are the rule IPv4 prefix or
address, the rule IPv6 prefix, the length in bits of the Extended
Address field in the End-User IPv6 Prefix assigned to the customer
edge device, and the offset in a port number beyond which the port set
identifier begins.</t>
<t>The syntax of the MAP-Rule AVP is as follows:</t>
<figure anchor="fig_map" title="">
<artwork>
MAP-Rule ::= < AVP Header: TBD08 >
{ IPv4-Prefix-Or-Addr }
{ IPv6-Prefix-Or-Addr }
{ EA-Field-Length }
[ PSID-Offset ]
*[ AVP ]
</artwork>
</figure>
<t>The IPv4-Prefix-Or-Addr and IPv6-Prefix-Or-Addr AVPs were defined
above. The EA-Field-Length AVP (AVP Code TBD09) and PSID-Offset AVP
(AVP Code TBD10) are of type Unsigned32. The valid range for
EA-Field-Length extends from 0 to a maximum value defined by
<xref target="I-D.ietf-softwire-map"/>. The valid range for
PSID-Offset extends from 0 to 15, with a default value given by
<xref target="I-D.ietf-softwire-map"/> if the parameter is absent.</t>
</section> <!-- maprule -->
</section> <!-- AVPdefs -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo requests to IANA to register the following Diameter AVP
codes: </t>
<texttable anchor="tt_codes" title="">
<ttcol align="center">Code</ttcol>
<ttcol align="left">Attribute Name</ttcol>
<ttcol align="left">Reference</ttcol>
<c>TBD01</c>
<c>Border-Router-IPv6-Address</c>
<c>This document</c>
<c>TBD02</c>
<c>IPv4-Prefix-Or-Addr</c>
<c>This document</c>
<c>TBD03</c>
<c>IPv6-Prefix-Or-Addr</c>
<c>This document</c>
<c>TBD04</c>
<c>Port-Set-Identifier</c>
<c>This document</c>
<c>TBD05</c>
<c>Transition-Method</c>
<c>This document</c>
<c>TBD06</c>
<c>NAT-Poolid</c>
<c>This document</c>
<c>TBD07</c>
<c>4to6-Binding</c>
<c>This document</c>
<c>TBD08</c>
<c>MAP-Rule</c>
<c>This document</c>
<c>TBD09</c>
<c>EA-Field-Length</c>
<c>This document</c>
<c>TBD10</c>
<c>PSID-Offset</c>
<c>This document</c>
</texttable>
<t>This document further requests IANA to establish a new sub-
directory of the Diameter AVP Specific Values directory entitled
Transition-Method AVP Values (code TBD05). The initial set of values
for this registry are as follows:</t>
<texttable anchor="tt_tmval" title="">
<ttcol align="center">AVP Values</ttcol>
<ttcol align="left">Attribute Name</ttcol>
<ttcol align="left">Reference</ttcol>
<c>0</c>
<c>NO_METHOD</c>
<c>This document.</c>
<c>1</c>
<c>DUAL_STACK</c>
<c>This document.</c>
<c>2</c>
<c>DS_LITE</c>
<c>This document.</c>
<c>3</c>
<c>PUBLIC_4OVER6</c>
<c>This document.</c>
<c>4</c>
<c>LIGHT_WEIGHT_4OVER6</c>
<c>This document.</c>
<c>5</c>
<c>MAP_WITH_ENCAPSULATION</c>
<c>This document.</c>
</texttable>
</section>
<section anchor="Security" title="Security Considerations">
<t>To come.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
&RFC2119;
&RFC6333;
&RFC6733;
<reference anchor="I-D.ietf-softwire-unified-cpe">
<front>
<title>Unified IPv4-in-IPv6 Softwire CPE (work in progress)</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization>Deutsche Telekom</organization>
</author>
<date month="January" year="2013"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-lw4over6">
<front>
<title>Lightweight 4over6: An Extension to the DS-Lite Architecture (work in progress)</title>
<author initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="Q." surname="Sun">
<organization>China Telecom</organization>
</author>
<author initials="M." surname="Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="T." surname="Tsou">
<organization>Huawei Technologies</organization>
</author>
<author initials="Y." surname="Lee">
<organization>Comcast</organization>
</author>
<author initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
</author>
<date month="April" year="2013"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-map-radius">
<front>
<title>RADIUS Attribute for MAP (work in progress)</title>
<author initials="Sheng" surname="Jiang" fullname="Sheng Jiang">
<organization>Huawei Technologies Co., Ltd</organization>
</author>
<author initials="Yu" surname="Fu" fullname="Yu Fu">
<organization>Huawei Technologies Co., Ltd</organization>
</author>
<author initials="Bing" surname="Liu" fullname="Bing Liu">
<organization>Huawei Technologies Co., Ltd</organization>
</author>
<author initials="Peter" surname="Deacon" fullname="Peter Deacon">
<organization>IEA Software, Inc.</organization>
</author>
<date month="June" year="2013"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-map">
<front>
<title>Mapping of Address and Port with Encapsulation (MAP) (work in progress)</title>
<author initials="O." surname="Troan">
<organization>Cisco Systems</organization>
</author>
<author initials="W." surname="Dec">
<organization>Cisco Systems</organization>
</author>
<author initials="X." surname="Li">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="C." surname="Bao">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="S." surname="Matsushima">
<organization>SoftBank Telecom</organization>
</author>
<author initials="T." surname="Murakami">
<organization>IP Infusion</organization>
</author>
<date month="February" year="2013"/>
</front>
</reference>
<reference anchor="I-D.ietf-softwire-public-4over6">
<front>
<title>Public IPv4 over IPv6 Access Network</title>
<author initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="J." surname="Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="P." surname="Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="O." surname="Vautrin">
<organization>Juniper Networks</organization>
</author>
<author initials="Y." surname="Lee">
<organization>Comcast</organization>
</author>
<date month="October" year="2012"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC2131;
&RFC3315;
&RFC2865;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:45 |