One document matched: draft-ietf-behave-address-format-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1918 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
<!ENTITY rfc2026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
<!ENTITY rfc2765 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2765.xml'>
<!ENTITY rfc2766 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml'>
<!ENTITY rfc3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
<!ENTITY rfc3493 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3493.xml'>
<!ENTITY rfc4271 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml'>
<!ENTITY rfc4291 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY rfc4380 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml'>
<!ENTITY rfc4862 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>
<!ENTITY rfc5214 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5214.xml'>
<!ENTITY rfc5389 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml'>
<!ENTITY I-D.bagnulo-behave-dns64 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bagnulo-behave-dns64.xml'>
<!ENTITY I-D.baker-behave-v4v6-framework PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-behave-v4v6-framework.xml'>
<!ENTITY I-D.ietf-behave-v6v4-framework PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-v6v4-framework-03.xml'>
<!ENTITY I-D.wing-behave-nat64-referrals PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-behave-nat64-referrals.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<rfc category="std"
docName="draft-ietf-behave-address-format-01.txt"
ipr="trust200902"
obsoletes="2765">
<front>
<title abbrev="IPv6 Addressing of IPv4/IPv6 Translators">
IPv6 Addressing of IPv4/IPv6 Translators
</title>
<author fullname="Christian Huitema" initials="C." role="" surname="Huitema">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<code>98052-6399</code>
<region>WA</region>
<country>U.S.A.</country>
</postal>
<email>huitema@microsoft.com</email>
</address>
</author>
<author fullname="Congxiao Bao" initials="C." role="" surname="Bao">
<organization>CERNET Center/Tsinghua University</organization>
<address>
<postal>
<street>Room 225, Main Building, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<region></region>
<country>China</country>
</postal>
<phone>+86 10-62785983</phone>
<email>congxiao@cernet.edu.cn</email>
</address>
</author>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
<organization>UC3M</organization>
<address>
<postal>
<street>Av. Universidad 30</street>
<city>Leganes</city>
<region>Madrid</region>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34-91-6249500</phone>
<facsimile></facsimile>
<email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/marcelo</uri>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." role="" surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street> 3, Av Francois Chateaux</street>
<city>Rennes</city>
<code>350000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<author initials="X." surname="Li" fullname="Xing Li"
role="">
<organization>
CERNET Center/Tsinghua University
</organization>
<address>
<postal>
<street>Room 225, Main Building, Tsinghua University</street>
<city>Beijing</city> <region> </region> <code>100084</code>
<country>China</country>
</postal>
<phone> +86 10-62785983</phone>
<email>xing@cernet.edu.cn</email>
</address>
</author>
<date year="2009"/>
<abstract>
<t> This document discusses how an individual IPv6 address can
be algorithmically translated to a corresponding IPv4 address,
and vice versa, using only statically configured information.
This technique is used in IPv4/IPv6 translators, as well
as other types of proxies and gateways (e.g., for DNS)
used in IPv4/IPv6 scenarios.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document is part of a series of IPv4/IPv6 translation
documents. A framework for IPv4/IPv6 translation is discussed in
<xref target="I-D.ietf-behave-v6v4-framework"/>, including
a taxonomy of scenarios that will be used in this document.
Other documents specify the behavior of various types
of translators and gateways, including mechanisms for translating
between IP headers and other types of messages that include
IP addresses. This document specifies how an individual
IPv6 address is translated to a corresponding IPv4 address,
and vice versa, in cases where an algorithmic mapping is
used. While specific types of devices are used herein as examples,
it is the responsibility of the specification of such devices
to reference this document for algorithmic mapping of the addresses
themselves.
</t>
<t>
Section 2 of this document describes the format of "IPv4 Embedded IPv6 addresses", i.e.
IPv6 addresses in which 32 bits contains an IPv4 address. These
addresses can be used to represent IPv4 hosts to hosts in an IPv6
network. IPv6 addresses assigned to IPv6 hosts for use with stateless
translation are referred to as "IPv4-translatable" IPv6 addresses; they are
a variant of embedded addresses, and follow the format described in Section 2.
</t>
<t>
Section 3 discusses the choice of prefixes, the use of a well known prefix, and the
use of embedded addresses with stateless and stateful translation.
</t>
<section title="Applicability Scope">
<t>
This document is part of a series defining address translation services. We understand that
the address format could also be used by other interconnection methods between IPv6 and IPv4,
e.g. methods based on encapsulation. If the WG so decides, a future version of this document
could also discuss the use of embedded addresses and prefixes for interconnection of IPv6 and
IPv4 based on encapsulation.
</t>
</section>
<section title="Notations">
<t>
In this document, an "IPv4/IPv6 translator" is an entity that
translates IPv4 packets to IPv6 packets, and vice versa. It
may do "stateless" translation, meaning that there is no per-flow
state required, or "stateful" translation where per-flow state
is created when the first packet in a flow is received.
</t>
<t>
In this document, an "address translator" is any entity that has
to derive an IPv4 address from an IPv6 address or vice versa.
This applies not only to devices that do IPv4/IPv6 packet
translation, but also to other entities that manipulate addresses,
such as name resolution proxies (e.g.,
DNS64 <xref target="I-D.bagnulo-behave-dns64"/>) and possibly
other types of Application Layer Gateways (ALGs).
</t>
<t>
In this document, the "Well Known Prefix" is an IPv6 prefix assigned by IANA for
use in an algorithmic mapping. Options for the actual allocation of
the Well Known Prefix are discussed in Section 3.6.
</t>
<t>
In this document, a "Network Specific Prefix" is an IPv6 prefix assigned by an
organization for use in algorithmic mapping. Options for the Network Specific Prefix
are discussed in Section 3.3 and 3.4.
</t>
</section>
</section>
<section title="IPv4 Embedded IPv6 Address Format">
<t>IPv4 Embedded IPv6 Addresses are composed of a variable length prefix, the embedded
IPv4 address, and a variable length suffix, as presented in the following diagram:</t>
<figure align="center">
<artwork align="left"><![CDATA[
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127-|
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/32 | prefix |v4(32) | u | suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/40 | prefix |v4(24) | u |(8)| suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/48 | prefix |v4(16) | u | (16) | suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/56 | prefix |(8)| u | v4(24) | suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/64 | prefix | u | v4(32) | suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/96 | prefix | v4(32) |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
<t>In these addresses, the prefix shall be either the "Well Known Prefix"
defined in the addressing architecture to represent IPv4 mapped addresses,
or a "Network Specific Prefix" unique to the organization deploying the address translators.
(Options for the well known prefix are discussed in Section 3.6.)
</t>
<t>
Various deployments justify different prefix lengths. The tradeoff between
different prefix lengths are discussed in Sections 3.3 and 3.4 of this document.
</t>
<t>
Bits 64 to 71 of the address are reserved for compatibility with the host identifier
format defined in the IPv6 addressing architecture. These bits MUST be set to zero.
The corresponding octet is noted "u" in the above diagram. When using a 96 prefix,
the administrators MUST ensure that the bits 64 to 71 are compatible with the
IPv6 addressing architecture.</t>
<t>
The IPv4 address is encoded following the prefix, most significant bits first.
Depending of the prefix length, the 4 octets of the address may be separated by the
reserved octet "u". In particular:</t>
<list style='symbols'>
<t>When the prefix is 32 bit long, the IPv4 address is encoded in positions 32 to 63.</t>
<t>When the prefix is 40 bit long, 24 bits of the IPv4 address are encoded in positions
40 to 63, with the remaining 8 bits in position 72 to 79.</t>
<t>When the prefix is 48 bit long, 16 bits of the IPv4 address are encoded in positions
48 to 63, with the remaining 8 bits in position 72 to 87.</t>
<t>When the prefix is 56 bit long, 8 bits of the IPv4 address are encoded in positions
56 to 63, with the remaining 8 bits in position 72 to 95.</t>
<t>When the prefix is 64 bit long, the IPv4 address is encoded in positions 72 to 103.</t>
<t>When the prefix is 96 bit long, the IPv4 address is encoded in positions 96 to 127.</t>
</list>
<t>
There are no remaining bits, and thus no suffix, if the prefix is 96 bit long. In the other
cases, the remaining bits of the address constitute the suffix. These bits are reserved for
future extensions, and should be set to a null value. (Different options for the suffix
as discussed in Section 3.5.)</t>
</section>
<section title="Deployment Guidelines and Choices">
<section title="Deployment Using the Well Known Prefix">
<t>
The Well Known Prefix MAY be used by organizations deploying translation services.
</t>
<t>
The Well Known Prefix SHOULD NOT be used to construct IPv4 translatable addresses.
The host served by IPv4 translatable addresses should be able to receive IPv6 traffic
bound to their IPv4 translatable address without incurring intermediate protocol translation.
This is only possible if the specific prefix used to build the translatable addresses
is advertized in inter-domain routing, and this kind of specific prefix advertisement
is not supported with the Well Known Prefix, as explained in Section 3.2.
</t>
<t>
The Well Known Prefix MUST NOT be used to represent non global IPv4 addresses, such as
those defined in RFC 1918. Doing so would introduce ambiguous IPv6 address.</t>
</section>
<section title="Impact on Inter-Domain Routing">
<t>
The Well Known Prefix MAY appear in inter-domain routing tables, if service providers
decide to provide IPv6-IPv4 interconnection services to peers. Advertisement of the
Well Known Prefix SHOULD be controlled either by upstream and/or downstream service
providers owing to inter-domain routing policies, e.g., through configuration of BGP.
Organizations that advertize the Well Known Prefix in
inter-domain routing MUST be able to provide address translation service.
</t>
<t>
When the translation relies on the Well Known Prefix, IPv4-mapped IPv6 prefixes longer than the Well Known Prefix MUST NOT be advertised in BGP (especially e-BGP) [rfc4271] because this imports IPv4 routing table into IPv6 one and therefore induces scalability issues to the global IPv6 routing table. Adjacent BGP speakers MUST ignore advertisements of IPv4-mapped IPv6 prefixes longer than the Well Known Prefix. BGP speakers SHOULD be able to be configured with the default Well Known Prefix.
</t>
<t>
When the translation service relies on Network Specific Prefixes, the global IPv6 routing policy guideline MUST be followed. In particular, if stateless translation is used, the IPv4-translatable addresses MUST be advertised with proper aggregation to the IPv6 Internet. Similarly, if translators are configured with multiple Network Specific Prefixes, these prefixes MUST be advertised to the IPv6 Internet with proper aggregation.
</t>
</section>
<section title="Choice of Prefix for Stateless Translation Deployments">
<t>
Organization may deploy translation services using stateless translation. In these
deployments, internal IPv6 hosts are addressed using "IPv4 translatable" IPv6 addresses,
which enable them to be accessed by IPv4 hosts. The addresses of these external hosts are
represented in "IPv4 Embedded" IPv6 addresses.
</t>
<t>
Organizations deploying stateless translation SHOULD assign a Network Specific Prefix to
their translation service.
Both "IPv4 translatable" and "IPv4 Embedded" MUST be constructed as specified in section 2.
"IPv4 translatable" addresses MUST use the selected Network Specific Prefix. Both types of addresses SHOULD use the same prefix.
Using the same prefix ensures that
internal IPv6 hosts will use the most efficient paths to reach the hosts served by
"IPv4 translatable" addresses.
</t>
<t>
The intra-domain routing protocol must be able to deliver packets to the hosts served by
"IPv4 translatable" addresses. This may require routing on some or all of the embedded
IPv4 address bits. Security considerations detailed in the security section requires
that routers check the validity of the "IPv4 translatable" source addresses, using
some form of reverse path check.
</t>
<t>
Forwarding, and reverse path checks, should be performed on the combination of the "prefix"
and the IPv4 address. In theory, routers should be able to route on prefixes of any length.
However, there is some suspicion that routing on prefixes larger than 64 bit may be slower,
or possibly not supported by some router. But routing efficiency is not the only consideration
in the choice of a prefix length. Organization also need to consider the availability of
prefixes, and the potential impact of null identifiers.
</t>
<t>
If a /32 prefix is used, all the routing bits are contained in the top 64 bits of the IPv6
address, leading to excellent routing properties. These prefixes may however be hard to obtain,
and allocation of a /32 to a small set of IPv4 translatable addresses may be seen as wasteful.
In addition, the /32 prefix and a null suffix leads to a null identifier, an issue
that we discuss in section 3.5.
</t>
<t>
Intermediate prefixes like /40, /48 or /56 appear as compromise. Only some of the IPv4 bits
are part of the /64 addresses. Reverse checks, in particular, may have a limited efficiency.
Reverse checks limited the most significant bits of the IPv4 address will reduce the possibility
of spoofing external address, but would allow internal hosts to spoof internal addresses.
</t>
<t>
We propose here a compromise, based on using no more than 1/256th of an organization's allocation of IPv6 addresses for the translation service. For example, if the organization is an ISP, with an allocated prefix /32 or shorter, the ISP could dedicate a /40 prefix to the translation service. An end site with a /48 allocation could dedicate a /56 prefix to the translation service.
</t>
<t>
The recommended prefix length is also a function of the deployment scenario.
The stateless translation can be used for Scenario 1, Scenario 2, Scenario 5 and Scenario 6 defined in <xref target="I-D.ietf-behave-v6v4-framework" />. For different scenarios, the prefix length recommendations are:</t>
<list style="symbols">
<t>
For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario 2 (the IPv4 Internet to an IPv6 network), we recommend using a /40 prefix for an ISP holding a /32 allocation, and a /56 prefix for
a site holding a /40 allocation.
</t>
<t>
For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 (an IPv4 network to an IPv6 network), we recommend using a /64 prefix.
</t>
</list>
</section>
<section title="Choice of Prefix for Stateful Translation Deployments">
<t>
Organizations MAY deploy translation services based on stateful translation technology. The
organizations may decide to use either a Network Specific Prefix or the Well Known Prefix.
The Well Known Prefix SHOULD be used when no Network Specific Prefix is available.
</t>
<t>
When these services are used, internal hosts are addressed through standard IPv6 addresses,
while IPv4 hosts are represented by IPv4 embedded addresses, as specified in section 2.
</t>
<t>
The stateful nature of the translation creates potential stability issue when the organization
deploys multiple translators. If several translators use the same prefix, there is a risk that
packet belonging to the same connection may be routed to different translators as the internal
routing state changes. This issue can be mitigated either by assigning different prefixes to
different translators, or by ensuring that all translators using same prefix coordinate their state.
</t>
<t>
The stateful translation can be used in the scenarios defined in
<xref target="I-D.ietf-behave-v6v4-framework"/>. The general recommendation
is to use the Well Known Prefix, with two exceptions:
</t>
<list style="symbols">
<t>
In all scenarios, the translation MAY use a Network Specific Prefix, if deemed appropriate for management reasons.
</t>
<t>
The Well Known Prefix MUST NOT be used for scenario 3 (the IPv6 Internet to an IPv4 network), as this would lead to using the Well Known Prefix with non global IPv4 addresses. That means a Network Specific Prefix MUST be used in that scenario.
</t>
</list>
</section>
<section title="Choice of Suffix">
<t>
The address format described in Section 2 recommends a null suffix. Before making this recommendation,
we considered different options: checksum neutrality; the encoding of a port range;
and a value different than 0.
</t>
<t>
The "neutrality checksum" option would give a chosen value to 16 of the suffix bits to ensure that the "IPv4 embedded" IPv6 address has the same 16 bit complement to 1 checksum as the embedded IPv4 address. There have been discussion of this checksum in the working group mailing list, and some push to standardize a checksum format. However, we observed that the neutrality checksum alone does eliminate checksums computation during stateful translation, as only one of the two addresses would be checksum neutral. In the case of stateless translation, translators may want to recomputed the checksum anyhow, to verify the validity of the translated
datagrams. In doubt, we picked the simplest alternative, to not specify a neutrality checksum.
</t>
<t>
There have been proposals to complement stateless translation with a port-range feature. Instead of mapping an IPv4 address to exactly one IPv6 prefix, the options would allow several IPv6 hosts to share an IPv4 address, with each host managing a different range of ports. But these schemes are not yet specified in work group documents. If a port range extension is needed, it could be defined later, using bits currently reserved as null in the suffix.
</t>
<t>
When a /32 prefix is used, the null suffix results in a null identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet-router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix for now. (Different authors of this document have different opinions.)
</t>
</section>
<section title="Choice of the Well Known Prefix">
<t>
We are faced with three choices for the Well Known Prefix:
</t>
<list style="symbols">
<t>
reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC 2765 Section 2.1;
</t>
<t>
request allocation of a new /96 prefix;
</t>
<t>
or request IANA to allocate a /32 prefix.
</t>
</list>
<t>
Each of these choices has pros and cons.
We expect this issue to be debated and resolved by the BEHAVE working group,
and present here our analysis of the options.
</t>
<t>
The main advantage of the existing IPv4-mapped prefix is that it is already defined. Reusing that prefix will require minimal standardization efforts. However, being already defined is not just and advantage, as there may be side effects of current implementations. When presented with the IPv4-mapped prefix, several versions of
Windows and MAcOS may generate IPv4 packets, but will not send IPv6 packets. If we used the IPv4-mapped prefix, these hosts would not be able to support translation
without modification. This will defeat the main purpose of the translation techniques.
</t>
<t>
Allocating a new prefix would diminish the risk of undesirable side effects in current implementations. The main cost will be the registration cost with IANA. We will also need to update the recommendation for textual representations of IPv6 addresses, if
we want to ensure the dotted
decimal representation of the IPv4 component in the IPv4 embedded IPv6 addresses.
</t>
<t>
If we allocate a new prefix, choosing a /32 prefix would allow the embedded IPv4 address to fit within the top 64 bits of the IPv6 address. This would facilitate routing and load balancing when an organization deploys several translators. However, such destination-address based load balancing may not be desirable, as it is not compatible with STUN in the deployments involving multiple stateful
translators, each one having a different pool of IPv4 addresses. STUN compatibility
would only be achieved if the translators managed the same pool of IPv4 addresses
and were able to coordinate their translation state.
</t>
<t>
We should also note that according to Section 2.2 of RFC 4291, in the legal textual representations of IPv6 addresses, dotted
decimal can only appear at the end. We could simply forego the dotted decimal notation, but
that would make the address format harder to use, and log files harder to read.
We could also update RFC4291 to allow
textual representation of addresses using the assigned WKP and having
the interface identifier set to all zeros. We could also embed the
IPv4 address both in the last 32 bits of the interface identifier and
the last 32 bits of the 64 bit prefix, allowing to use the textual
representation as defined in RFC4291 and also have the possibility of
including the IPv4 address in the prefix part. Moreover, we could
request for IANA to assign a /32 for the WKP and then operators could
simply decide whether to use it as a /32 or pad it with zeros and use
it as a /96.
</t>
<t>
Allocating a new /96 prefix would not enable the same routing and load balancing options as a /32 prefix, but would allow for decimal notation of IPv4 addresses without requiring an update to RFC 4291.
</t>
</section>
</section>
<section title="Security Considerations">
<section title="Protection Against Spoofing">
<t>
By and large, address translators can be modeled as special routers, are subject to the same risks,
and can implement the same mitigation. There is however a particular risk that directly derived
from the practice of embedding IPv4 addresses in IPv6: address spoofing.
</t>
<t>
An attacker could use an IPv4 embedded address as the source address of malicious packets.
After translation, the packets will appear as IPv4 packets from the specified source, and
the attacker may be hard to track. If left without mitigation, the attack would allow
malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
</t>
<t>
The mitigation is to implement reverse path checks, and to verify throughout the network
that packets are coming from an authorized location.
</t>
</section>
<section title="Secure Configuration">
<t> The prefix and format need to be the same among multiple devices
in the same network (e.g., hosts that need to prefer native
over translated addresses, DNS gateways, and IPv4/IPv6 translators).
As such, the means by which they are learned/configured must be
secure. Specifying a default prefix and/or format in implementations
provides one way to configure them securely. Any alternative means
of configuration is responsible for specifying how to do so securely.
</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<t> A future version of this memo will request an IPv6 prefix
assignment as a Well-Known Mapped Prefix, that
is used to represent IPv4 hosts, and which must start with binary 000.
</t>
<t> [EDITOR'S NOTE: 0/8 is reserved by the IETF (and not allocated
by IANA), so all that is needed is to specify the prefix herein
since it is an allocation from IETF not from IANA.]
</t>
<t> OPEN ISSUE:
The prefix length of this block has not yet been determined.
Some possibilities are /16, /32, /48 or /96.
</t>
</section>
<section title="Acknowledgements">
<t> Many people in the Behave WG have contributed to the discussion
that led to this document, including Andrew Sullivan,
Andrew Yourtchenko, Brian Carpenter, Congxiao Bao, Dan Wing, Ed
Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John
Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund, Marcelo
Bagnulo Braun, Margaret Wasserman, Masahito Endo, Phil Roberts,
Philip Matthews, Remi Denis-Courmont, Remi Despres, William Waites
and Xing Li.
</t>
</section>
<section title="Contributors">
<t> The following individuals co-authored drafts from which text has been
incorporated, and are listed in alphabetical order.
</t>
<figure align="center">
<artwork align="left"><![CDATA[
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 62785983
Email: congxiao@cernet.edu.cn
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
Email: fred@cisco.com
Hiroshi Miyata
Yokogawa Electric Corporation
2-9-32 Nakacho
Musashino-shi, Tokyo 180-8750
JAPAN
Email: h.miyata@jp.yokogawa.com
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
ESPANA
Email: marcelo@it.uc3m.es
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 62785983
Email: xing@cernet.edu.cn
]]></artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2026;
&rfc4291;
</references>
<references title="Informative References">
&rfc1918;
&rfc2765;
&rfc2766;
&rfc3484;
&rfc3493;
&rfc4271;
&rfc4380;
&rfc4862;
&rfc5214;
&rfc5389;
&I-D.ietf-behave-v6v4-framework;
&I-D.bagnulo-behave-dns64;
&I-D.wing-behave-nat64-referrals;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:40 |