draft-ietf-behave-address-format-01.txt   draft-ietf-behave-address-format-02.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Obsoletes: 2765 (if approved) C. Bao Obsoletes: 2765 (if approved) C. Bao
Intended status: Standards Track CERNET Center/Tsinghua University Intended status: Standards Track CERNET Center/Tsinghua University
Expires: April 29, 2010 M. Bagnulo Expires: June 17, 2010 M. Bagnulo
UC3M UC3M
M. Boucadair M. Boucadair
France Telecom France Telecom
X. Li X. Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
October 26, 2009 December 14, 2009
IPv6 Addressing of IPv4/IPv6 Translators IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-address-format-01.txt draft-ietf-behave-address-format-02.txt
Abstract
This document discusses the algorithmic translated to a corresponding
IPv4 address, and vice versa, using only statically configured
information. It defines a Well-Known Prefix for use in algorithmic
translations, while allowing organizations to also use Network
Specific Prefixes when appropriate. Algorithmic translation is used
in IPv4/IPv6 translators, as well as other types of proxies and
gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on June 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document discusses how an individual IPv6 address can be described in the BSD License.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv4 Embedded IPv6 Address Format . . . . . . . . . . . . . . 4 2. IPv4 Embedded IPv6 Address Format . . . . . . . . . . . . . . 4
3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 5 2.1. Text Representation . . . . . . . . . . . . . . . . . . . 5
3.1. Deployment Using the Well Known Prefix . . . . . . . . . . 5 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 6
3.1. Deployment Using the Well-Known Prefix . . . . . . . . . . 6
3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 6 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 6
3.3. Choice of Prefix for Stateless Translation Deployments . . 6 3.3. Choice of Prefix for Stateless Translation Deployments . . 7
3.4. Choice of Prefix for Stateful Translation Deployments . . 8 3.4. Choice of Prefix for Stateful Translation Deployments . . 8
3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 8 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 9
3.6. Choice of the Well Known Prefix . . . . . . . . . . . . . 9 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 10 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 11
4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 11 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document is part of a series of IPv4/IPv6 translation documents. This document is part of a series of IPv4/IPv6 translation documents.
A framework for IPv4/IPv6 translation is discussed in A framework for IPv4/IPv6 translation is discussed in
[I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios
that will be used in this document. Other documents specify the that will be used in this document. Other documents specify the
behavior of various types of translators and gateways, including behavior of various types of translators and gateways, including
mechanisms for translating between IP headers and other types of mechanisms for translating between IP headers and other types of
messages that include IP addresses. This document specifies how an messages that include IP addresses. This document specifies how an
individual IPv6 address is translated to a corresponding IPv4 individual IPv6 address is translated to a corresponding IPv4
address, and vice versa, in cases where an algorithmic mapping is address, and vice versa, in cases where an algorithmic mapping is
used. While specific types of devices are used herein as examples, used. While specific types of devices are used herein as examples,
it is the responsibility of the specification of such devices to it is the responsibility of the specification of such devices to
reference this document for algorithmic mapping of the addresses reference this document for algorithmic mapping of the addresses
themselves. themselves.
Section 2 of this document describes the format of "IPv4 Embedded This document reserves a "Well-Known Prefix" for use in an
IPv6 addresses", i.e. IPv6 addresses in which 32 bits contains an algorithmic mapping. The value of this IPv6 prefix is:
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.
Section 3 discusses the choice of prefixes, the use of a well known 64:FF9B::/96
prefix, and the use of embedded addresses with stateless and stateful
Section 2 describes the format of "IPv4 Embedded IPv6 addresses",
i.e. - IPv6 addresses in which 32 bits contain an IPv4 address.
Section 3 discusses the choice of prefixes, the use of the Well-Known
Prefix, and the use of embedded addresses with stateless and stateful
translation. translation.
Section 4 discusses security concerns.
1.1. Applicability Scope 1.1. Applicability Scope
This document is part of a series defining address translation This document is part of a series defining address translation
services. We understand that the address format could also be used services. We understand that the address format could also be used
by other interconnection methods between IPv6 and IPv4, e.g. methods by other interconnection methods between IPv6 and IPv4, e.g. methods
based on encapsulation. If the WG so decides, a future version of based on encapsulation. If encapsulation methods are developed by
this document could also discuss the use of embedded addresses and the IETF, we expect that their descriptions will document their
prefixes for interconnection of IPv6 and IPv4 based on encapsulation. specific use of IPv4 Embedded IPv6 Addresses.
1.2. Notations 1.2. Notations
In this document, an "IPv4/IPv6 translator" is an entity that This document makes use of the following terms:
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.
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 [I-D.bagnulo-behave-dns64]) and
possibly other types of Application Layer Gateways (ALGs).
In this document, the "Well Known Prefix" is an IPv6 prefix assigned IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6
by IANA for use in an algorithmic mapping. Options for the actual packets, and vice versa. It may do "stateless" translation,
allocation of the Well Known Prefix are discussed in Section 3.6. 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.
In this document, a "Network Specific Prefix" is an IPv6 prefix Address translator: any entity that has to derive an IPv4 address
assigned by an organization for use in algorithmic mapping. Options from an IPv6 address or vice versa. This applies not only to
for the Network Specific Prefix are discussed in Section 3.3 and 3.4. devices that do IPv4/IPv6 packet translation, but also to other
entities that manipulate addresses, such as name resolution
proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other
types of Application Layer Gateways (ALGs).
Well-Known Prefix: the IPv6 prefix defined in this document for use
in an algorithmic mapping.
Network Specific Prefix: 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 Section 3.4.
IPv4 Embedded IPv6 addresses: IPv6 addresses in which 32 bits
contain an IPv4 address. These addresses can be used to represent
IPv4 hosts to hosts in an IPv6 network. Their format is described
in Section 2.
IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6
hosts for use with stateless translation. They are a variant of
embedded addresses, and follow the format described in Section 2.
2. IPv4 Embedded IPv6 Address Format 2. IPv4 Embedded IPv6 Address Format
IPv4 Embedded IPv6 Addresses are composed of a variable length IPv4 Embedded IPv6 Addresses are composed of a variable length
prefix, the embedded IPv4 address, and a variable length suffix, as prefix, the embedded IPv4 address, and a variable length suffix, as
presented in the following diagram: presented in the following diagram, in which PL designates the prefix
length:
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PLEN| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-127-| |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-|
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/32 | prefix |v4(32) | u | suffix | |32| prefix |v4(32) | u | suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/40 | prefix |v4(24) | u |(8)| suffix | |40| prefix |v4(24) | u |(8)| suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/48 | prefix |v4(16) | u | (16) | suffix | |48| prefix |v4(16) | u | (16) | suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/56 | prefix |(8)| u | v4(24) | suffix | |56| prefix |(8)| u | v4(24) | suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/64 | prefix | u | v4(32) | suffix | |64| prefix | u | v4(32) | suffix |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|/96 | prefix | v4(32) | |96| prefix | v4(32) |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
In these addresses, the prefix shall be either the "Well Known In these addresses, the prefix shall be either the "Well-Known
Prefix" defined in the addressing architecture to represent IPv4 Prefix", or a "Network Specific Prefix" unique to the organization
mapped addresses, or a "Network Specific Prefix" unique to the deploying the address translators.
organization deploying the address translators. (Options for the
well known prefix are discussed in Section 3.6.)
Various deployments justify different prefix lengths. The tradeoff Various deployments justify different prefix lengths. The tradeoff
between different prefix lengths are discussed in Sections 3.3 and between different prefix lengths are discussed in Section 3.3 and
3.4 of this document. Section 3.4.
Bits 64 to 71 of the address are reserved for compatibility with the Bits 64 to 71 of the address are reserved for compatibility with the
host identifier format defined in the IPv6 addressing architecture. host identifier format defined in the IPv6 addressing architecture
These bits MUST be set to zero. The corresponding octet is noted "u" [RFC4291]. These bits MUST be set to zero. When using a /96 prefix,
in the above diagram. When using a 96 prefix, the administrators the administrators MUST ensure that the bits 64 to 71 are set to
MUST ensure that the bits 64 to 71 are compatible with the IPv6 zero. A simple way to achieve that is to construct the /96 Network
addressing architecture. Specific Prefix by picking a /64 prefix, and then adding four octets
set to zero.
The IPv4 address is encoded following the prefix, most significant The IPv4 address is encoded following the prefix, most significant
bits first. Depending of the prefix length, the 4 octets of the bits first. Depending of the prefix length, the 4 octets of the
address may be separated by the reserved octet "u". In particular: address may be separated by the reserved octet "u", whose 8 bits MUST
o When the prefix is 32 bit long, the IPv4 address is encoded in be set to zero. In particular:
o When the prefix is 32 bits long, the IPv4 address is encoded in
positions 32 to 63. positions 32 to 63.
o When the prefix is 40 bit long, 24 bits of the IPv4 address are o When the prefix is 40 bits long, 24 bits of the IPv4 address are
encoded in positions 40 to 63, with the remaining 8 bits in encoded in positions 40 to 63, with the remaining 8 bits in
position 72 to 79. position 72 to 79.
o When the prefix is 48 bit long, 16 bits of the IPv4 address are o When the prefix is 48 bits long, 16 bits of the IPv4 address are
encoded in positions 48 to 63, with the remaining 8 bits in encoded in positions 48 to 63, with the remaining 16 bits in
position 72 to 87. position 72 to 87.
o When the prefix is 56 bit long, 8 bits of the IPv4 address are o When the prefix is 56 bits long, 8 bits of the IPv4 address are
encoded in positions 56 to 63, with the remaining 8 bits in encoded in positions 56 to 63, with the remaining 24 bits in
position 72 to 95. position 72 to 95.
o When the prefix is 64 bit long, the IPv4 address is encoded in o When the prefix is 64 bits long, the IPv4 address is encoded in
positions 72 to 103. positions 72 to 103.
o When the prefix is 96 bit long, the IPv4 address is encoded in o When the prefix is 96 bits long, the IPv4 address is encoded in
positions 96 to 127. positions 96 to 127.
There are no remaining bits, and thus no suffix, if the prefix is 96 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 bits long. In the other cases, the remaining bits of the address
constitute the suffix. These bits are reserved for future constitute the suffix. These bits are reserved for future
extensions, and should be set to a null value. (Different options extensions, and SHOULD be set to a zero.
for the suffix as discussed in Section 3.5.)
2.1. Text Representation
IPv4 embedded IPv6 addresses will be represented in text in
conformity with section 2.2 of [RFC4291]. IPv4 embedded IPv6
addresses constructed using the Well Known Prefix or a /96 Network
Specific Prefix may be represented using the alternative form
presented in section 2.2 of [RFC4291], with the embedded IPv4 address
represented in dotted decimal notation. Examples of such
representations are presented in Table 1.
+-----------------------+------------+------------------------------+
| Prefix | IPv4 | IPv4 embedded IPv6 address |
| | address | |
+-----------------------+------------+------------------------------+
| 2001:DB8:100::/32 | 13.1.68.3 | 2001:DB8:D01:4403:: |
| 2001:DB8:100::/40 | 13.1.68.3 | 2001:DB8:10D:0144:3:: |
| 2001:DB8:102::/48 | 13.1.68.3 | 2001:DB8:102:D01:44:300:: |
| 2001:DB8:102::/48 | 13.1.68.3 | 2001:DB8:102:D01:44:300:: |
| 2001:DB8:102:300::/56 | 13.1.68.3 | 2001:DB8:102:30D:1:4403:: |
| 2001:DB8:102:304::/64 | 13.1.68.3 | 2001:DB8:102:304:D:144:300:: |
| 2001:DB8:102:304::/96 | 13.1.68.3 | 2001:DB8:102:304::13.1.68.3 |
| 64:FF9B::/96 | 13.1.68.3 | 64:FF9B::13.1.68.3 |
+-----------------------+------------+------------------------------+
Table 1: Text representation of IPv4 embedded IPv6 addresses
The Network Specific Prefixes in Table 1 are derived from the IPv6
Prefix reserved for doocumentation in [RFC3849].
3. Deployment Guidelines and Choices 3. Deployment Guidelines and Choices
3.1. Deployment Using the Well Known Prefix 3.1. Deployment Using the Well-Known Prefix
The Well Known Prefix MAY be used by organizations deploying The Well-Known Prefix MAY be used by organizations deploying
translation services. translation services.
The Well Known Prefix SHOULD NOT be used to construct IPv4 The Well-Known Prefix SHOULD NOT be used to construct IPv4
translatable addresses. The host served by IPv4 translatable translatable addresses. The host served by IPv4 translatable IPv6
addresses should be able to receive IPv6 traffic bound to their IPv4 addresses should be able to receive IPv6 traffic bound to their IPv4
translatable address without incurring intermediate protocol translatable IPv6 address without incurring intermediate protocol
translation. This is only possible if the specific prefix used to translation. This is only possible if the specific prefix used to
build the translatable addresses is advertized in inter-domain build the IPv4 translatable IPv6 addresses is advertized in inter-
routing, and this kind of specific prefix advertisement is not domain routing, and this kind of specific prefix advertisement is not
supported with the Well Known Prefix, as explained in Section 3.2. supported with the Well-Known Prefix, as explained in Section 3.2.
The Well Known Prefix MUST NOT be used to represent non global IPv4 The Well-Known Prefix MUST NOT be used to represent non global IPv4
addresses, such as those defined in RFC 1918. Doing so would addresses, such as those defined in [RFC1918]. Doing so would
introduce ambiguous IPv6 address. introduce ambiguous IPv6 addresses.
3.2. Impact on Inter-Domain Routing 3.2. Impact on Inter-Domain Routing
The Well Known Prefix MAY appear in inter-domain routing tables, if The Well-Known Prefix MAY appear in inter-domain routing tables, if
service providers decide to provide IPv6-IPv4 interconnection service providers decide to provide IPv6-IPv4 interconnection
services to peers. Advertisement of the Well Known Prefix SHOULD be services to peers. Advertisement of the Well-Known Prefix SHOULD be
controlled either by upstream and/or downstream service providers controlled either by upstream and/or downstream service providers
owing to inter-domain routing policies, e.g., through configuration owing to inter-domain routing policies, e.g., through configuration
of BGP. Organizations that advertize the Well Known Prefix in inter- of BGP [RFC4271]. Organizations that advertize the Well-Known Prefix
domain routing MUST be able to provide address translation service. in inter-domain routing MUST be able to provide IPv4/IPv6 address
translation service.
When the translation relies on the Well Known Prefix, IPv4-mapped When the IPv4/IPv6 translation relies on the Well-Known Prefix,
IPv6 prefixes longer than the Well Known Prefix MUST NOT be embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be
advertised in BGP (especially e-BGP) [rfc4271] because this imports advertised in BGP (especially e-BGP) [RFC4271] because this leads to
IPv4 routing table into IPv6 one and therefore induces scalability importing IPv4 routing table into IPv6 one and therefore induces
issues to the global IPv6 routing table. Adjacent BGP speakers MUST scalability issues to the global IPv6 routing table. Adjacent BGP
ignore advertisements of IPv4-mapped IPv6 prefixes longer than the speakers MUST ignore advertisements of embedded IPv6 prefixes longer
Well Known Prefix. BGP speakers SHOULD be able to be configured with than the Well-Known Prefix. BGP speakers SHOULD be able to be
the default Well Known Prefix. configured with the default Well-Known Prefix.
When the translation service relies on Network Specific Prefixes, the When the IPv4/IPv6 translation service relies on Network Specific
global IPv6 routing policy guideline MUST be followed. In Prefixes and stateless translation is used, the IPv4-translatable
particular, if stateless translation is used, the IPv4-translatable IPv6 prefixes MUST be advertised with proper aggregation to the IPv6
addresses MUST be advertised with proper aggregation to the IPv6
Internet. Similarly, if translators are configured with multiple Internet. Similarly, if translators are configured with multiple
Network Specific Prefixes, these prefixes MUST be advertised to the Network Specific Prefixes, these prefixes MUST be advertised to the
IPv6 Internet with proper aggregation. IPv6 Internet with proper aggregation.
3.3. Choice of Prefix for Stateless Translation Deployments 3.3. Choice of Prefix for Stateless Translation Deployments
Organization may deploy translation services using stateless Organization may deploy translation services using stateless
translation. In these deployments, internal IPv6 hosts are addressed translation. In these deployments, internal IPv6 hosts are addressed
using "IPv4 translatable" IPv6 addresses, which enable them to be using "IPv4 translatable" IPv6 addresses, which enable them to be
accessed by IPv4 hosts. The addresses of these external hosts are accessed by IPv4 hosts. The addresses of these external hosts are
represented in "IPv4 Embedded" IPv6 addresses. then represented in "IPv4 Embedded" IPv6 addresses.
Organizations deploying stateless translation SHOULD assign a Network Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
Specific Prefix to their translation service. Both "IPv4 a Network Specific Prefix to their IPv4/IPv6 translation service.
translatable" and "IPv4 Embedded" MUST be constructed as specified in "IPv4 translatable" and "IPv4 Embedded" addresses MUST be constructed
section 2. "IPv4 translatable" addresses MUST use the selected as specified in Section 2. IPv4 translatable IPv6 addresses MUST use
Network Specific Prefix. Both types of addresses SHOULD use the same the selected Network Specific Prefix. Both types of addresses SHOULD
prefix. Using the same prefix ensures that internal IPv6 hosts will use the same prefix. Using the same prefix ensures that internal
use the most efficient paths to reach the hosts served by "IPv4 IPv6 hosts will use the most efficient paths to reach the hosts
translatable" addresses. served by "IPv4 translatable" addresses.
The intra-domain routing protocol must be able to deliver packets to The intra-domain routing protocol must be able to deliver packets to
the hosts served by "IPv4 translatable" addresses. This may require the hosts served by IPv4 translatable IPv6 addresses. This may
routing on some or all of the embedded IPv4 address bits. Security require routing on some or all of the embedded IPv4 address bits.
considerations detailed in the security section requires that routers Security considerations detailed in Section 4 require that routers
check the validity of the "IPv4 translatable" source addresses, using check the validity of the IPv4 translatable IPv6 source addresses,
some form of reverse path check. using some form of reverse path check.
Forwarding, and reverse path checks, should be performed on the Forwarding, and reverse path checks, should be performed on the
combination of the "prefix" and the IPv4 address. In theory, routers combination of the "prefix" and the IPv4 address. In theory, routers
should be able to route on prefixes of any length. However, there is should be able to route on prefixes of any length. However, routing
some suspicion that routing on prefixes larger than 64 bit may be on prefixes larger than 64 bits may be slower. But routing
slower, or possibly not supported by some router. But routing
efficiency is not the only consideration in the choice of a prefix efficiency is not the only consideration in the choice of a prefix
length. Organization also need to consider the availability of length. Organizations also need to consider the availability of
prefixes, and the potential impact of null identifiers. prefixes, and the potential impact of all-zeroes identifiers.
If a /32 prefix is used, all the routing bits are contained in the 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 top 64 bits of the IPv6 address, leading to excellent routing
properties. These prefixes may however be hard to obtain, and properties. These prefixes may however be hard to obtain, and
allocation of a /32 to a small set of IPv4 translatable addresses may 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 be seen as wasteful. In addition, the /32 prefix and a zero suffix
leads to a null identifier, an issue that we discuss in section 3.5. leads to an all-zeroes interface identifier, an issue that we discuss
in Section 3.5.
Intermediate prefixes like /40, /48 or /56 appear as compromise. Intermediate prefix lengths such as /40, /48 or /56 appear as
Only some of the IPv4 bits are part of the /64 addresses. Reverse compromises. Only some of the IPv4 bits are part of the /64
checks, in particular, may have a limited efficiency. Reverse checks prefixes. Reverse path checks, in particular, may have a limited
limited the most significant bits of the IPv4 address will reduce the efficiency. Reverse checks limited to the most significant bits of
possibility of spoofing external address, but would allow internal the IPv4 address will reduce the possibility of spoofing external
hosts to spoof internal addresses. IPv4 address, but would allow IPv6 hosts to spoof internal IPv4
translatable addresses.
We propose here a compromise, based on using no more than 1/256th of We propose here a compromise, based on using no more than 1/256th of
an organization's allocation of IPv6 addresses for the translation an organization's allocation of IPv6 addresses for the IPv4/IPv6
service. For example, if the organization is an ISP, with an translation service. For example, if the organization is an ISP,
allocated prefix /32 or shorter, the ISP could dedicate a /40 prefix with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate
to the translation service. An end site with a /48 allocation could a /40 prefix to the translation service. An end site with a /48
dedicate a /56 prefix to the translation service. allocation could dedicate a /56 prefix to the translation service, or
possibly a /96 prefix if all IPv4 Translatable IPv4 Addresses are
located on the same link.
The recommended prefix length is also a function of the deployment The recommended prefix length is also a function of the deployment
scenario. The stateless translation can be used for Scenario 1, scenario. The stateless translation can be used for Scenario 1,
Scenario 2, Scenario 5 and Scenario 6 defined in Scenario 2, Scenario and Scenario 6 defined in
[I-D.ietf-behave-v6v4-framework]. For different scenarios, the [I-D.ietf-behave-v6v4-framework]. For different scenarios, the
prefix length recommendations are: prefix length recommendations are:
o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario o 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 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 prefix for an ISP holding a /32 allocation, and a /56 prefix for a
site holding a /40 allocation. site holding a /48 allocation.
o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 o 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 (an IPv4 network to an IPv6 network), we recommend using a /64 or
prefix. a /96 prefix.
3.4. Choice of Prefix for Stateful Translation Deployments 3.4. Choice of Prefix for Stateful Translation Deployments
Organizations MAY deploy translation services based on stateful Organizations may deploy translation services based on stateful
translation technology. The organizations may decide to use either a translation technology. An organization may decide to use either a
Network Specific Prefix or the Well Known Prefix. The Well Known Network Specific Prefix or the Well-Known Prefix for its stateful
Prefix SHOULD be used when no Network Specific Prefix is available. IPv4/IPv6 translation service.
When these services are used, internal hosts are addressed through When these services are used, IPv6 hosts are addressed through
standard IPv6 addresses, while IPv4 hosts are represented by IPv4 standard IPv6 addresses, while IPv4 hosts are represented by IPv4
embedded addresses, as specified in section 2. embedded addresses, as specified in Section 2.
The stateful nature of the translation creates potential stability The stateful nature of the translation creates a potential stability
issue when the organization deploys multiple translators. If several issue when the organization deploys multiple translators. If several
translators use the same prefix, there is a risk that packet translators use the same prefix, there is a risk that packets
belonging to the same connection may be routed to different belonging to the same connection may be routed to different
translators as the internal routing state changes. This issue can be translators as the internal routing state changes. This issue can be
mitigated either by assigning different prefixes to different mitigated either by assigning different prefixes to different
translators, or by ensuring that all translators using same prefix translators, or by ensuring that all translators using same prefix
coordinate their state. coordinate their state.
The stateful translation can be used in the scenarios defined in Stateful translation can be used in scenarios defined in
[I-D.ietf-behave-v6v4-framework]. The general recommendation is to [I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be
use the Well Known Prefix, with two exceptions: used in most scenarios, with two exceptions:
o In all scenarios, the translation MAY use a Network Specific o In all scenarios, the translation MAY use a Network Specific
Prefix, if deemed appropriate for management reasons. Prefix, if deemed appropriate for management reasons.
o The Well Known Prefix MUST NOT be used for scenario 3 (the IPv6 o 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 Internet to an IPv4 network), as this would lead to using the
Known Prefix with non global IPv4 addresses. That means a Network Well-Known Prefix with non global IPv4 addresses. That means a
Specific Prefix MUST be used in that scenario. Network Specific Prefix MUST be used in that scenario, for example
a /96 prefix compatible with the Well Known prefix format.
3.5. Choice of Suffix 3.5. Choice of Suffix
The address format described in Section 2 recommends a null suffix. The address format described in Section 2 recommends a zero suffix.
Before making this recommendation, we considered different options: Before making this recommendation, we considered different options:
checksum neutrality; the encoding of a port range; and a value checksum neutrality; the encoding of a port range; and a value
different than 0. different than 0.
The "neutrality checksum" option would give a chosen value to 16 of 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 suffix bits to ensure that the "IPv4 embedded" IPv6 address has
the same 16 bit complement to 1 checksum as the embedded IPv4 the same 16 bit 1's complement checksum as the embedded IPv4 address.
address. There have been discussion of this checksum in the working There have been discussion of this checksum in the working group
group mailing list, and some push to standardize a checksum format. mailing list, and some push to standardize a checksum format.
However, we observed that the neutrality checksum alone does However, we observed that a neutral checksum alone does not eliminate
eliminate checksums computation during stateful translation, as only checksums computation during stateful translation, as only one of the
one of the two addresses would be checksum neutral. In the case of two addresses would be checksum neutral. In the case of stateless
stateless translation, translators may want to recomputed the translation, translators may want to recompute the checksum anyhow,
checksum anyhow, to verify the validity of the translated datagrams. to verify the validity of the translated datagrams. In the case of
In doubt, we picked the simplest alternative, to not specify a stateful translation, the Well Known Prefix was chosen to provide
neutrality checksum. checksum neutrality. We thus chose the simplest alternative, to not
specify a neutrality checksum.
There have been proposals to complement stateless translation with a There have been proposals to complement stateless translation with a
port-range feature. Instead of mapping an IPv4 address to exactly port-range feature. Instead of mapping an IPv4 address to exactly
one IPv6 prefix, the options would allow several IPv6 hosts to share one IPv6 prefix, the options would allow several IPv6 hosts to share
an IPv4 address, with each host managing a different range of ports. an IPv4 address, with each host managing a different range of ports.
But these schemes are not yet specified in work group documents. If But these schemes are not yet specified in work group documents. If
a port range extension is needed, it could be defined later, using a port range extension is needed, it could be defined later, using
bits currently reserved as null in the suffix. bits currently reserved as null in the suffix.
When a /32 prefix is used, the null suffix results in a null When a /32 prefix is used, an all-zero suffix results in an all-zero
identifier. We understand the conflict with Section 2.6.1 of interface identifier. We understand the conflict with Section 2.6.1
RFC4291, which specifies that all zeroes are used for the subnet- of RFC4291, which specifies that all zeroes are used for the subnet-
router anycast address. However, in our specification, there would router anycast address. However, in our specification, there would
be only one IPv4 translatable host in the /64 subnet, and the anycast be only one IPv4 translatable node in the /64 subnet, and the anycast
semantic would not create confusion. We thus decided to keep the semantic would not create confusion. We thus decided to keep the
null suffix for now. (Different authors of this document have null suffix for now. (This issue does not exist for prefixes larger
different opinions.) than 32 bits, such as the /40, /56, /64 and /96 prefixes that we
recommend in Section 3.3.)
3.6. Choice of the Well Known Prefix 3.6. Choice of the Well-Known Prefix
We are faced with three choices for the Well Known Prefix: Before making our recommendation of the Well-Known Prefix, we were
faced with three choices:
o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC
2765 Section 2.1; 2765 Section 2.1;
o request allocation of a new /96 prefix; o request IANA to allocate a /32 prefix,
o or request IANA to allocate a /32 prefix. o or request allocation of a new /96 prefix.
Each of these choices has pros and cons. We expect this issue to be We weighted the pros and cons of these choices before settling on the
debated and resolved by the BEHAVE working group, and present here recommended /96 Well-Known Prefix.
our analysis of the options.
The main advantage of the existing IPv4-mapped prefix is that it is The main advantage of the existing IPv4-mapped prefix is that it is
already defined. Reusing that prefix will require minimal already defined. Reusing that prefix will require minimal
standardization efforts. However, being already defined is not just standardization efforts. However, being already defined is not just
and advantage, as there may be side effects of current and advantage, as there may be side effects of current
implementations. When presented with the IPv4-mapped prefix, several implementations. When presented with the IPv4-mapped prefix, current
versions of Windows and MAcOS may generate IPv4 packets, but will not versions of Windows and MacOS generate IPv4 packets, but will not
send IPv6 packets. If we used the IPv4-mapped prefix, these hosts send IPv6 packets. If we used the IPv4-mapped prefix, these hosts
would not be able to support translation without modification. This would not be able to support translation without modification. This
will defeat the main purpose of the translation techniques. will defeat the main purpose of the translation techniques. We thus
eliminated the first choice, and decided to not reuse the IPv4-mapped
Allocating a new prefix would diminish the risk of undesirable side prefix, ::FFFF:0:0/96.
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.
If we allocate a new prefix, choosing a /32 prefix would allow the A /32 prefix would have allowed the embedded IPv4 address to fit
embedded IPv4 address to fit within the top 64 bits of the IPv6 within the top 64 bits of the IPv6 address. This would have
address. This would facilitate routing and load balancing when an facilitated routing and load balancing when an organization deploys
organization deploys several translators. However, such destination- several translators. However, such destination-address based load
address based load balancing may not be desirable, as it is not balancing may not be desirable. It is not compatible with STUN in
compatible with STUN in the deployments involving multiple stateful the deployments involving multiple stateful translators, each one
translators, each one having a different pool of IPv4 addresses. having a different pool of IPv4 addresses. STUN compatibility would
STUN compatibility would only be achieved if the translators managed only be achieved if the translators managed the same pool of IPv4
the same pool of IPv4 addresses and were able to coordinate their addresses and were able to coordinate their translation state, in
translation state. which case there is no big advantage to using a /32 prefix rather
than a /96 prefix.
We should also note that according to Section 2.2 of RFC 4291, in the According to Section 2.2 of [RFC4291], in the legal textual
legal textual representations of IPv6 addresses, dotted decimal can representations of IPv6 addresses, dotted decimal can only appear at
only appear at the end. We could simply forego the dotted decimal the end. The /96 prefix is compatible with that requirement. It
notation, but that would make the address format harder to use, and enables the dotted decimal notation without requiring an update to
log files harder to read. We could also update RFC4291 to allow [RFC4291]. This representation makes the address format easier to
textual representation of addresses using the assigned WKP and having use, and log files easier to read.
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.
Allocating a new /96 prefix would not enable the same routing and The prefix that we recommend has the particularity of being "checksum
load balancing options as a /32 prefix, but would allow for decimal neutral". The sum of the hexadecimal numbers "0064" and "FF9B" is
notation of IPv4 addresses without requiring an update to RFC 4291. "FFFF", i.e. a value equal to zero in complement to 1 arithmetic. An
IPv4 embedded IPv6 address constructed with this prefix will have the
same complement to 1 checksum as the embedded IPv4 address.
4. Security Considerations 4. Security Considerations
4.1. Protection Against Spoofing 4.1. Protection Against Spoofing
By and large, address translators can be modeled as special routers, By and large, address translators can be modeled as special routers,
are subject to the same risks, and can implement the same mitigation. are subject to the same risks, and can implement the same
There is however a particular risk that directly derived from the mitigations. There is however a particular risk that directly
practice of embedding IPv4 addresses in IPv6: address spoofing. derives from the practice of embedding IPv4 addresses in IPv6:
address spoofing.
An attacker could use an IPv4 embedded address as the source address An attacker could use an IPv4 embedded address as the source address
of malicious packets. After translation, the packets will appear as of malicious packets. After translation, the packets will appear as
IPv4 packets from the specified source, and the attacker may be hard IPv4 packets from the specified source, and the attacker may be hard
to track. If left without mitigation, the attack would allow to track. If left without mitigation, the attack would allow
malicious IPv6 nodes to spoof arbitrary IPv4 addresses. malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
The mitigation is to implement reverse path checks, and to verify The mitigation is to implement reverse path checks, and to verify
throughout the network that packets are coming from an authorized throughout the network that packets are coming from an authorized
location. location.
4.2. Secure Configuration 4.2. Secure Configuration
The prefix and format need to be the same among multiple devices in The prefixes and formats need to be the configured consistently among
the same network (e.g., hosts that need to prefer native over multiple devices in the same network (e.g., hosts that need to prefer
translated addresses, DNS gateways, and IPv4/IPv6 translators). As native over translated addresses, DNS gateways, and IPv4/IPv6
such, the means by which they are learned/configured must be secure. translators). As such, the means by which they are learned/
Specifying a default prefix and/or format in implementations provides configured MUST be secure. Specifying a default prefix and/or format
one way to configure them securely. Any alternative means of in implementations provides one way to configure them securely. Any
configuration is responsible for specifying how to do so securely. alternative means of configuration is responsible for specifying how
to do so securely.
5. IANA Considerations 5. IANA Considerations
A future version of this memo will request an IPv6 prefix assignment The Well Known Prefix falls into the range ::/8 reserved by the IETF.
as a Well-Known Mapped Prefix, that is used to represent IPv4 hosts, The prefix definition does not require an IANA action.
and which must start with binary 000.
[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.]
OPEN ISSUE: The prefix length of this block has not yet been
determined. Some possibilities are /16, /32, /48 or /96.
6. Acknowledgements 6. Acknowledgements
Many people in the Behave WG have contributed to the discussion that Many people in the Behave WG have contributed to the discussion that
led to this document, including Andrew Sullivan, Andrew Yourtchenko, led to this document, including Andrew Sullivan, Andrew Yourtchenko,
Brian Carpenter, Congxiao Bao, Dan Wing, Ed Jankiewicz, Fred Baker, Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata,
Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore, Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
Kevin Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip
Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis- Matthews, Remi Denis-Courmont, Remi Despres and William Waites.
Courmont, Remi Despres, William Waites and Xing Li.
Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program.
7. Contributors 7. Contributors
The following individuals co-authored drafts from which text has been The following individuals co-authored drafts from which text has been
incorporated, and are listed in alphabetical order. incorporated, and are listed in alphabetical order.
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Congxiao Bao Congxiao Bao
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University Room 225, Main Building, Tsinghua University
Beijing, 100084 Beijing, 100084
China China
Phone: +86 62785983 Phone: +86 62785983
Email: congxiao@cernet.edu.cn Email: congxiao@cernet.edu.cn
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Phone: +1-408-526-4257 Phone: +1-408-526-4257
Fax: +1-413-473-2403 Fax: +1-413-473-2403
Email: fred@cisco.com Email: fred@cisco.com
Hiroshi Miyata Hiroshi Miyata
Yokogawa Electric Corporation Yokogawa Electric Corporation
skipping to change at page 13, line 17 skipping to change at page 14, line 17
8.1. Normative References 8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
8.2. Informative References 8.2. Informative References
[I-D.bagnulo-behave-dns64] [I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
M. Endo, "DNS64: DNS extensions for Network Address "DNS64: DNS extensions for Network Address Translation
Translation from IPv6 Clients to IPv4 Servers", from IPv6 Clients to IPv4 Servers",
draft-bagnulo-behave-dns64-02 (work in progress), draft-ietf-behave-dns64-02 (work in progress),
March 2009. October 2009.
[I-D.ietf-behave-v6v4-framework] [I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-03 (work in progress), draft-ietf-behave-v6v4-framework-03 (work in progress),
October 2009. October 2009.
[I-D.wing-behave-nat64-referrals]
Wing, D., "Referrals Across an IPv6/IPv4 Translator",
draft-wing-behave-nat64-referrals-01 (work in progress),
October 2009.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000. (SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766, Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000. February 2000.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003. RFC 3493, February 2003.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
 End of changes. 83 change blocks. 
293 lines changed or deleted 318 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/