draft-ietf-behave-address-format-07.txt   draft-ietf-behave-address-format-08.txt 
Network Working Group C. Bao Network Working Group C. Bao
Internet-Draft CERNET Center/Tsinghua University Internet-Draft CERNET Center/Tsinghua University
Obsoletes: 2765 (if approved) C. Huitema Obsoletes: 2765 (if approved) C. Huitema
Updates: 4291 (if approved) Microsoft Corporation Updates: 4291 (if approved) Microsoft Corporation
Intended status: Standards Track M. Bagnulo Intended status: Standards Track M. Bagnulo
Expires: October 11, 2010 UC3M Expires: November 17, 2010 UC3M
M. Boucadair M. Boucadair
France Telecom France Telecom
X. Li X. Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
April 9, 2010 May 16, 2010
IPv6 Addressing of IPv4/IPv6 Translators IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-address-format-07.txt draft-ietf-behave-address-format-08.txt
Abstract Abstract
This document discusses the algorithmic translation of an IPv6 This document discusses the algorithmic translation of an IPv6
address to a corresponding IPv4 address, and vice versa, using only address to a corresponding IPv4 address, and vice versa, using only
statically configured information. It defines a well-known prefix statically configured information. It defines a well-known prefix
for use in algorithmic translations, while allowing organizations to for use in algorithmic translations, while allowing organizations to
also use network-specific prefixes when appropriate. Algorithmic also use network-specific prefixes when appropriate. Algorithmic
translation is used in IPv4/IPv6 translators, as well as other types 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. of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on October 11, 2010. This Internet-Draft will expire on November 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4
2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4 2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4
2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 4 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5
2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6
2.4. Text Representation . . . . . . . . . . . . . . . . . . . 6 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 6
3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7 3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 7
3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7 3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7
3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
3.3. Choice of Prefix for Stateless Translation Deployments . . 8 3.3. Choice of Prefix for Stateless Translation Deployments . . 8
3.4. Choice of Prefix for Stateful Translation Deployments . . 11 3.4. Choice of Prefix for Stateful Translation Deployments . . 11
3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11 4. Design choices . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12 4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12
4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14 5.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 describes the prefixes and the format of "IPv4-Embedded Section 2 describes the prefixes and the format of "IPv4-Embedded
IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an
IPv4 address. This format is common to both "IPv4-Converted" and IPv4 address. This format is common to both "IPv4-converted" and
"IPv4-Translatable" IPv6 addresses. This section also defines the "IPv4-Translatable" IPv6 addresses. This section also defines the
algorithms for translating addresses, and the text representation of algorithms for translating addresses, and the text representation of
IPv4-Embedded IPv6 addresses. IPv4-Embedded IPv6 addresses.
Section 3 discusses the choice of prefixes, the conditions in which Section 3 discusses the choice of prefixes, the conditions in which
they can be used, and the use of IPv4-Embedded IPv6 addresses with they can be used, and the use of IPv4-Embedded IPv6 addresses with
stateless and stateful translation. stateless and stateful translation.
Section 4 discusses security concerns. Section 4 provides a summary of the discussions behind two specific
design decisions, the choice of a null suffix and the specific value
of the selected prefix.
Section 5 discusses security concerns.
In some scenarios, a dual-stack host will unnecessarily send its In some scenarios, a dual-stack host will unnecessarily send its
traffic through an IPv6/IPv4 translator. This can be caused by traffic through an IPv6/IPv4 translator. This can be caused by
host's default address selection algorithm [RFC3484], referrals, or host's default address selection algorithm [RFC3484], referrals, or
other reasons. Optimizing these scenarios for dual-stack hosts is other reasons. Optimizing these scenarios for dual-stack hosts is
for future study. for future study.
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
skipping to change at page 4, line 10 skipping to change at page 4, line 15
1.2. Conventions 1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Terminology 1.3. Terminology
This document makes use of the following terms: This document makes use of the following terms:
IPv4/IPv6 translator: 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.
Address translator: any entity that has to derive an IPv4 address Address translator: any entity that has to derive an IPv4 address
from an IPv6 address or vice versa. This applies not only to from an IPv6 address or vice versa. This applies not only to
devices that do IPv4/IPv6 packet translation, but also to other devices that do IPv4/IPv6 packet translation, but also to other
entities that manipulate addresses, such as name resolution entities that manipulate addresses, such as name resolution
proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other
types of Application Layer Gateways (ALGs). types of Application Layer Gateways (ALGs).
Well-Known Prefix: the IPv6 prefix defined in this document for use IPv4-converted IPv6 addresses: IPv6 addresses used to represent IPv4
in an algorithmic mapping. nodes in an IPv6 network. They are a variant of IPv4-Embedded
Network-Specific Prefix: an IPv6 prefix assigned by an organization IPv6 addresses, and follow the format described in Section 2.2.
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 IPv4-Embedded IPv6 addresses: IPv6 addresses in which 32 bits
contain an IPv4 address. Their format is described in contain an IPv4 address. Their format is described in
Section 2.2. Section 2.2.
IPv4-Converted IPv6 addresses: IPv6 addresses used to represent IPv4 IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6
nodes in an IPv6 network. They are a variant of IPv4-Embedded packets, and vice versa. It may do "stateless" translation,
IPv6 addresses, and follow the format described in Section 2.2. 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.
IPv4-Translatable IPv6 addresses: IPv6 addresses assigned to IPv6 IPv4-Translatable IPv6 addresses: IPv6 addresses assigned to IPv6
nodes for use with stateless translation. They are a variant of nodes for use with stateless translation. They are a variant of
IPv4-Embedded IPv6 addresses, and follow the format described in IPv4-Embedded IPv6 addresses, and follow the format described in
Section 2.2. Section 2.2.
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.
Well-Known Prefix: the IPv6 prefix defined in this document for use
in an algorithmic mapping.
2. IPv4-Embedded IPv6 Address Prefix and Format 2. IPv4-Embedded IPv6 Address Prefix and Format
2.1. Well Known Prefix 2.1. Well Known Prefix
This document reserves a "Well-Known Prefix" for use in an This document reserves a "Well-Known Prefix" for use in an
algorithmic mapping. The value of this IPv6 prefix is: algorithmic mapping. The value of this IPv6 prefix is:
64:FF9B::/96 64:FF9B::/96
2.2. IPv4-Embedded IPv6 Address Format 2.2. IPv4-Embedded IPv6 Address Format
IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses IPv4-converted IPv6 addresses and IPv4-Translatable IPv6 addresses
follow the same format, described here as the IPv4-Embedded IPv6 follow the same format, described here as the IPv4-Embedded IPv6
address Format. IPv4-Embedded IPv6 addresses are composed of a address Format. IPv4-Embedded IPv6 addresses are composed of a
variable length prefix, the embedded IPv4 address, and a variable variable length prefix, the embedded IPv4 address, and a variable
length suffix, as presented in the following diagram, in which PL length suffix, as presented in the following diagram, in which PL
designates the prefix length: designates the prefix length:
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| |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 |
skipping to change at page 6, line 31 skipping to change at page 6, line 35
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
bits 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 zero. extensions, and SHOULD be set to zero.
2.3. Address Translation Algorithms 2.3. Address Translation Algorithms
IPv4-Embedded IPv6 addresses are composed according to the following IPv4-Embedded IPv6 addresses are composed according to the following
algorithm: algorithm:
o Concatenate the prefix, the 32 bits of the IPv4 address and the o Concatenate the prefix, the 32 bits of the IPv4 address and the
null suffix if needed to obtain a 128 bit address. suffix if needed to obtain a 128 bit address.
o If the prefix length is less than 96 bits, insert the null octet o If the prefix length is less than 96 bits, insert the null octet
"u" at the appropriate position, thus causing the least "u" at the appropriate position (bits 64 to 71), thus causing the
significant octet to be excluded, as documented in Figure 1. least significant octet to be excluded, as documented in Figure 1.
The IPv4 addresses are extracted from the IPv4-Embedded IPv6 The IPv4 addresses are extracted from the IPv4-Embedded IPv6
addresses according to the following algorithm: addresses according to the following algorithm:
o If the prefix is 96 bit long, extract the last 32 bits of the IPv6 o If the prefix is 96 bit long, extract the last 32 bits of the IPv6
address; address;
o for the other prefix lengths, extract the "u" octet to obtain a o for the other prefix lengths, remove the "u" octet to obtain a 120
120 bit sequence, then extract the 32 bits following the prefix. bit sequence (effectively shifting bits 72-127 to positions 64-
119), then extract the 32 bits following the prefix.
2.4. Text Representation 2.4. Text Representation
IPv4-Embedded IPv6 addresses will be represented in text in IPv4-Embedded IPv6 addresses will be represented in text in
conformity with section 2.2 of [RFC4291]. IPv4-Embedded IPv6 conformity with section 2.2 of [RFC4291]. IPv4-Embedded IPv6
addresses constructed using the Well-Known Prefix or a /96 Network- addresses constructed using the Well-Known Prefix or a /96 Network-
Specific Prefix may be represented using the alternative form Specific Prefix may be represented using the alternative form
presented in section 2.2 of [RFC4291], with the embedded IPv4 address presented in section 2.2 of [RFC4291], with the embedded IPv4 address
represented in dotted decimal notation. Examples of such represented in dotted decimal notation. Examples of such
representations are presented in Table 1 and Table 2. representations are presented in Table 1 and Table 2.
skipping to change at page 7, line 34 skipping to change at page 7, line 38
+-------------------+--------------+----------------------------+ +-------------------+--------------+----------------------------+
Table 2: Text representation of IPv4-Embedded IPv6 addresses using Table 2: Text representation of IPv4-Embedded IPv6 addresses using
the Well-Known Prefix the Well-Known Prefix
The Network-Specific Prefix examples in Table 1 are derived from the The Network-Specific Prefix examples in Table 1 are derived from the
IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 IPv6 prefix reserved for documentation in [RFC3849]. The IPv4
address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for
documentation in [RFC5735]. documentation in [RFC5735].
3. Deployment Guidelines and Choices 3. Deployment Guidelines
3.1. Restrictions on the use of the Well-Known Prefix 3.1. Restrictions on the use of the Well-Known Prefix
The Well-Known Prefix MAY be used by organizations deploying The Well-Known Prefix MUST NOT be used to represent non global IPv4
translation services, as explained in Section 3.4. addresses, such as those defined in [RFC1918].
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 nodes served by IPv4-Translatable IPv6 Translatable IPv6 addresses. The nodes served by IPv4-Translatable
addresses should be able to receive global IPv6 traffic bound to IPv6 addresses should be able to receive global IPv6 traffic bound to
their IPv4-Translatable IPv6 address without incurring intermediate their IPv4-Translatable IPv6 address without incurring intermediate
protocol translation. This is only possible if the specific prefix protocol translation. This is only possible if the specific prefix
used to build the IPv4-Translatable IPv6 addresses is advertized in used to build the IPv4-Translatable IPv6 addresses is advertized in
inter-domain routing, but the advertisement of more specific prefixes inter-domain routing, but the advertisement of more specific prefixes
derived from the Well-Known Prefix is not supported, as explained in derived from the Well-Known Prefix is not supported, as explained in
Section 3.2. Network-Specific Prefixes SHOULD be used in these Section 3.2. Network-Specific Prefixes SHOULD be used in these
scenarios, as explained in Section 3.3. scenarios, as explained in Section 3.3.
The Well-Known Prefix MUST NOT be used to represent non global IPv4 The Well-Known Prefix MAY be used by organizations deploying
addresses, such as those defined in [RFC1918]. translation services, as explained in Section 3.4.
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 according to inter-domain routing policies, e.g., through
of BGP [RFC4271]. Organizations that advertize the Well-Known Prefix configuration of BGP [RFC4271]. Organizations that advertize the
in inter-domain routing MUST be able to provide IPv4/IPv6 translation Well-Known Prefix in inter-domain routing MUST be able to provide
service. IPv4/IPv6 translation service.
When the IPv4/IPv6 translation relies on the Well-Known Prefix, When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4
embedded 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 leads to advertised in BGP (especially e-BGP) [RFC4271] because this leads to
importing the IPv4 routing table into the IPv6 one and therefore importing the IPv4 routing table into the IPv6 one and therefore
induces scalability issues to the global IPv6 routing table. introduces scalability issues to the global IPv6 routing table.
Administrators of BGP nodes SHOULD configure filters that discard Administrators of BGP nodes SHOULD configure filters that discard
advertisements of embedded IPv6 prefixes longer than the Well-Known advertisements of embedded IPv6 prefixes longer than the Well-Known
Prefix. Prefix.
When the IPv4/IPv6 translation service relies on Network-Specific When the IPv4/IPv6 translation service relies on Network-Specific
Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless
translation MUST be advertised with proper aggregation to the IPv6 translation 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
Organizations may deploy translation services using stateless Organizations may deploy translation services using stateless
translation. In these deployments, internal IPv6 nodes are addressed translation. In these deployments, internal IPv6 nodes 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 nodes. The addresses of these external IPv4 nodes accessed by IPv4 nodes. The addresses of these external IPv4 nodes
are then represented in IPv4-Converted IPv6 addresses. are then represented in IPv4-converted IPv6 addresses.
Organizations deploying stateless IPv4/IPv6 translation SHOULD assign Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
a Network-Specific Prefix to their IPv4/IPv6 translation service. a Network-Specific Prefix to their IPv4/IPv6 translation service.
IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be IPv4-Translatable and IPv4-converted IPv6 addresses MUST be
constructed as specified in Section 2.2. IPv4-Translatable IPv6 constructed as specified in Section 2.2. IPv4-Translatable IPv6
addresses MUST use the selected Network-Specific Prefix. Both IPv4- addresses MUST use the selected Network-Specific Prefix. Both IPv4-
Translatable IPv6 addresses and IPv4-Converted IPv6 addresses SHOULD Translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD
use the same prefix. use the same prefix.
Using the same prefix ensures that IPv6 nodes internal to the Using the same prefix ensures that IPv6 nodes internal to the
organization will use the most efficient paths to reach the nodes organization will use the most efficient paths to reach the nodes
served by IPv4-Translatable IPv6 addresses. Specifically, if a node served by IPv4-Translatable IPv6 addresses. Specifically, if a node
learns the IPv4 address of a target internal node without knowing learns the IPv4 address of a target internal node without knowing
that this target is in fact located behind the same translator that that this target is in fact located behind the same translator that
the node also uses, translation rules will ensure that the IPv6 the node also uses, translation rules will ensure that the IPv6
address constructed with the Network-Specific prefix is the same as address constructed with the Network-Specific prefix is the same as
the IPv4-Translatable IPv6 address assigned to the target. Standard the IPv4-Translatable IPv6 address assigned to the target. Standard
routing preference (more specific wins) will then ensure that the routing preference (more specific wins) will then ensure that the
IPv6 packets are delivered directly, without requiring "hair-pinning" IPv6 packets are delivered directly, without requiring that
at the translator. translators receive the packets and then return them message in the
direction they came from.
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 nodes served by IPv4-Translatable IPv6 addresses. This may the nodes served by IPv4-Translatable IPv6 addresses. This may
require routing on some or all of the embedded IPv4 address bits. require routing on some or all of the embedded IPv4 address bits.
Security considerations detailed in Section 4 require that routers Security considerations detailed in Section 5 require that routers
check the validity of the IPv4-Translatable IPv6 source addresses, check the validity of the IPv4-Translatable IPv6 source addresses,
using some form of reverse path check. using some form of reverse path check.
The management of stateless address translation can be illustrated The management of stateless address translation can be illustrated
with a small example. We will consider an IPv6 network with the with a small example:
prefix 2001:DB8:122::/48. The network administrator has selected the
Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless
IPv4/IPv6 translation. The IPv4-Translatable address block is 2001:
DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the subnet
192.0.2.0/24. In this network, the host A is assigned the IPv4-
Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which
corresponds to the IPv4 address 192.0.2.33. Host A's address is
configured either manually or through DHCPv6.
In this example, host A is not directly connected to the translator, We will consider an IPv6 network with the prefix 2001:DB8:
but instead to a link managed by a router R. The router R is 122::/48. The network administrator has selected the Network-
configured to forward to A the packets bound to 2001:DB8:122:344:C0: Specific prefix 2001:DB8:122:344::/64 for managing stateless IPv4/
2:2100::. To receive these packets, R will advertise reachability of IPv6 translation. The IPv4-Translatable address block is 2001:
the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the
routing protocol -- or perhaps a shorter prefix if many hosts on link subnet 192.0.2.0/24. In this network, the host A is assigned the
have IPv4-Translatable IPv6 addresses derived from the same IPv4 IPv4-Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which
subnet. If a packet bound to 192.0.2.33 reaches the translator, the corresponds to the IPv4 address 192.0.2.33. Host A's address is
destination address will be translated to 2001:DB8:122:344:C0:2: configured either manually or through DHCPv6.
2100::, and the packet will be routed towards R and then to A.
Let's suppose now that a host B of the same domain learns the IPv4 In this example, host A is not directly connected to the
address of A, maybe through an application-specific referral. If B translator, but instead to a link managed by a router R. The
has translation-aware software, B can compose a destination address router R is configured to forward to A the packets bound to 2001:
by combining the Network-Specific Prefix 2001:DB8:122:344::/64 and DB8:122:344:C0:2:2100::. To receive these packets, R will
the IPv4 address 192.0.2.33, resulting in the address 2001:DB8:122: advertise reachability of the prefix 2001:DB8:122:344:C0:2:2100::/
344:C0:2:2100::. The packet sent by B will be forwarded towards R, 104 in the intra-domain routing protocol -- or perhaps a shorter
and then to A, avoiding protocol translation. prefix if many hosts on link have IPv4-Translatable IPv6 addresses
derived from the same IPv4 subnet. If a packet bound to
192.0.2.33 reaches the translator, the destination address will be
translated to 2001:DB8:122:344:C0:2:2100::, and the packet will be
routed towards R and then to A.
Forwarding, and reverse path checks, should be performed on the Let's suppose now that a host B of the same domain learns the IPv4
combination of the prefix and the IPv4 address. In theory, routers address of A, maybe through an application-specific referral. If
should be able to route on prefixes of any length. However, routing B has translation-aware software, B can compose a destination
on prefixes larger than 64 bits may be slower on some routers. But address by combining the Network-Specific Prefix 2001:DB8:122:
routing efficiency is not the only consideration in the choice of a 344::/64 and the IPv4 address 192.0.2.33, resulting in the address
prefix length. Organizations also need to consider the availability 2001:DB8:122:344:C0:2:2100::. The packet sent by B will be
of prefixes, and the potential impact of all-zeroes identifiers. forwarded towards R, and then to A, avoiding protocol translation.
Forwarding, and reverse path checks, are more efficient when
performed on the combination of the prefix and the IPv4 address. In
theory, routers are able to route on prefixes of any length, but in
practice there may be routers for which routing on prefixes larger
than 64 bits is slower. But routing efficiency is not the only
consideration in the choice of a prefix length. Organizations also
need to consider the availability of 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 IPv6 allocation of a /32 to a small set of IPv4-Translatable IPv6
addresses may be seen as wasteful. In addition, the /32 prefix and a addresses may be seen as wasteful. In addition, the /32 prefix and a
zero suffix leads to an all-zeroes interface identifier, an issue zero suffix leads to an all-zeroes interface identifier, an issue
that we discuss in Section 3.5. that we discuss in Section 4.1.
Intermediate prefix lengths such as /40, /48 or /56 appear as Intermediate prefix lengths such as /40, /48 or /56 appear as
compromises. Only some of the IPv4 bits are part of the /64 compromises. Only some of the IPv4 bits are part of the /64
prefixes. Reverse path checks, in particular, may have a limited prefixes. Reverse path checks, in particular, may have a limited
efficiency. Reverse path checks limited to the most significant bits efficiency. Reverse path checks limited to the most significant bits
of the IPv4 address will reduce the possibility of spoofing external of the IPv4 address will reduce the possibility of spoofing external
IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4- IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4-
Translatable IPv6 addresses. Translatable IPv6 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
skipping to change at page 10, line 42 skipping to change at page 11, line 6
site with a /48 allocation could dedicate a /56 prefix to the site with a /48 allocation could dedicate a /56 prefix to the
translation service, or possibly a /96 prefix if all IPv4- translation service, or possibly a /96 prefix if all IPv4-
Translatable IPv6 addresses are located on the same link. Translatable IPv6 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 5, 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), an ISP holding a /32
prefix for an ISP holding a /32 allocation, and a /56 prefix for a allocation SHOULD use a /40 prefix , and a site holding a /48
site holding a /48 allocation. allocation SHOULD use a /56 prefix.
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 or (an IPv4 network to an IPv6 network), the deployment SHOULD use a
a /96 prefix. /64 or a /96 prefix.
IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address
architecture and SHOULD be compatible with the IPv4 address
architecture. The first IPv4-translatable address is the subnet-
router anycast address in IPv6 and network identifier in IPv4, the
last IPv4-translatable address is the subnet broadcast addresses in
IPv4. Both of them SHOULD NOT be used for IPv6 nodes. In addition,
the minimum IPv4 subnet can be used for hosts is /30 (the router
interface needs a valid address for the same subnet) and this rule
SHOULD also be applied to the corresponding subnet of the IPv4-
translatable addresses.
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. An organization may decide to use either a translation technology. An organization may decide to use either a
Network-Specific Prefix or the Well-Known Prefix for its stateful Network-Specific Prefix or the Well-Known Prefix for its stateful
IPv4/IPv6 translation service. IPv4/IPv6 translation service.
When these services are used, IPv6 nodes are addressed through When these services are used, IPv6 nodes are addressed through
standard IPv6 addresses, while IPv4 nodes are represented by IPv4- standard IPv6 addresses, while IPv4 nodes are represented by IPv4-
Converted IPv6 addresses, as specified in Section 2.2. converted IPv6 addresses, as specified in Section 2.2.
The stateful nature of the translation creates a 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 packets 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
avoided either by assigning different prefixes to different avoided 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.
Stateful translation can be used in scenarios defined in Stateful translation can be used in scenarios defined in
[I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be [I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be
used in these scenarios, with two exceptions: used in these 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 Internet to an IPv4 network), as this would lead to using the
Well-Known Prefix with non-global IPv4 addresses. That means a Well-Known Prefix with non-global IPv4 addresses. That means a
Network-Specific Prefix MUST be used in that scenario, for example Network-Specific Prefix MUST be used in that scenario, for example
a /96 prefix compatible with the Well-Known prefix format. a /96 prefix.
3.5. Choice of Suffix 4. Design choices
The prefix that we have chosen reflects two design choices, the null
suffix and the specific value of the Well Known Prefix. We provide
here a summary of the discussions leading to those two choices.
4.1. Choice of Suffix
The address format described in Section 2.2 recommends a zero suffix. The address format described in Section 2.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.
In the case of stateless translation, there would be no need for the In the case of stateless translation, there would be no need for the
translator to recompute a one's complement checksum if both the IPv4- translator to recompute a one's complement checksum if both the IPv4-
Translatable and the IPv4-Converted IPv6 addresses were constructed Translatable and the IPv4-converted IPv6 addresses were constructed
in a "checksum-neutral" manner, that is if the IPv6 addresses would in a "checksum-neutral" manner, that is if the IPv6 addresses would
have the same one's complement checksum as the embedded IPv4 address. have the same one's complement checksum as the embedded IPv4 address.
In the case of stateful translation, checksum neutrality does not In the case of stateful translation, checksum neutrality does not
eliminate checksum computation during translation, as only one of the eliminate checksum computation during translation, as only one of the
two addresses would be checksum neutral. We considered reserving 16 two addresses would be checksum neutral. We considered reserving 16
bits in the suffix to guarantee checksum neutrality, but declined bits in the suffix to guarantee checksum neutrality, but declined
because it would not help with stateful translation, and because because it would not help with stateful translation, and because
checksum neutrality can also be achieved by an appropriate choice of checksum neutrality can also be achieved by an appropriate choice of
the Network-Specific Prefix, as was done for example with the Well- the Network-Specific Prefix, i.e. selecting a prefix whose one's
Known Prefix. complement checksum equals either 0 or 0xFFFF.
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 nodes to share one IPv6 prefix, the options would allow several IPv6 nodes to share
an IPv4 address, with each node managing a different range of ports. an IPv4 address, with each node managing a different range of ports.
If a port range extension is needed, it could be defined later, using If 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, an all-zero suffix results in an all-zero When a /32 prefix is used, an all-zero suffix results in an all-zero
interface identifier. We understand the conflict with Section 2.6.1 interface identifier. We understand the conflict with Section 2.6.1
of 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 node with an IPv4-Translatable IPv6 address in the /64 be only one node with an IPv4-Translatable IPv6 address in the /64
subnet, and the anycast semantic would not create confusion. We thus subnet, and the anycast semantic would not create confusion. We thus
decided to keep the null suffix for now. This issue does not exist decided to keep the null suffix for now. This issue does not exist
for prefixes larger than 32 bits, such as the /40, /56, /64 and /96 for prefixes larger than 32 bits, such as the /40, /56, /64 and /96
prefixes that we recommend in Section 3.3. prefixes that we recommend in Section 3.3.
3.6. Choice of the Well-Known Prefix 4.2. Choice of the Well-Known Prefix
Before making our recommendation of the Well-Known Prefix, we were Before making our recommendation of the Well-Known Prefix, we were
faced with three choices: 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 IANA to allocate a /32 prefix, o request IANA to allocate a /32 prefix,
o or request allocation of a new /96 prefix. o or request allocation of a new /96 prefix.
We weighted the pros and cons of these choices before settling on the We weighted the pros and cons of these choices before settling on the
recommended /96 Well-Known Prefix. recommended /96 Well-Known Prefix.
skipping to change at page 13, line 34 skipping to change at page 13, line 43
enables the dotted decimal notation without requiring an update to enables the dotted decimal notation without requiring an update to
[RFC4291]. This representation makes the address format easier to [RFC4291]. This representation makes the address format easier to
use, and log files easier to read. use, and log files easier to read.
The prefix that we recommend has the particularity of being "checksum The prefix that we recommend has the particularity of being "checksum
neutral". The sum of the hexadecimal numbers "0064" and "FF9B" is neutral". The sum of the hexadecimal numbers "0064" and "FF9B" is
"FFFF", i.e. a value equal to zero in one's complement arithmetic. "FFFF", i.e. a value equal to zero in one's complement arithmetic.
An IPv4-Embedded IPv6 address constructed with this prefix will have An IPv4-Embedded IPv6 address constructed with this prefix will have
the same one's complement checksum as the embedded IPv4 address. the same one's complement checksum as the embedded IPv4 address.
4. Security Considerations 5. Security Considerations
4.1. Protection Against Spoofing 5.1. Protection Against Spoofing
By and large, IPv4/IPv6 translators can be modeled as special IPv4/IPv6 translators can be modeled as special routers, are subject
routers, are subject to the same risks, and can implement the same to the same risks, and can implement the same mitigations. (The
mitigations. There is however a particular risk that directly discussion of generic threats to routers and their mitigations is
derives from the practice of embedding IPv4 addresses in IPv6: beyond the scope of this document.) There is however a particular
address spoofing. risk that directly derives from the practice of embedding IPv4
addresses in IPv6: address spoofing.
An attacker could use an IPv4-Embedded IPv6 address as the source An attacker could use an IPv4-Embedded IPv6 address as the source
address of malicious packets. After translation, the packets will address of malicious packets. After translation, the packets will
appear as IPv4 packets from the specified source, and the attacker appear as IPv4 packets from the specified source, and the attacker
may be hard to track. If left without mitigation, the attack would may be hard to track. If left without mitigation, the attack would
allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. allow 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 5.2. Secure Configuration
The prefixes used for address translation are used by IPv6 nodes to The prefixes used for address translation are used by IPv6 nodes to
send packets to IPv6/IPv4 translators. Attackers could attempt to send packets to IPv6/IPv4 translators. Attackers could attempt to
fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
values for these parameters, resulting in network disruption, denial values for these parameters, resulting in network disruption, denial
of service, and possible information disclosure. To mitigate such of service, and possible information disclosure. To mitigate such
attacks, network administrators need to ensure that prefixes are attacks, network administrators need to ensure that prefixes are
configured in a secure way. configured in a secure way.
The mechanisms for achieving secure configuration of prefixes are The mechanisms for achieving secure configuration of prefixes are
beyond the scope of this document. beyond the scope of this document.
5. IANA Considerations 6. IANA Considerations
The IANA is requested to add a note to the documentation of the The IANA is requested to add a note to the documentation of the
0000::/8 address block in 0000::/8 address block in
http://www.iana.org/assignments/ipv6-address-space to document the http://www.iana.org/assignments/ipv6-address-space to document the
assignment by the IETF of the Well Known Prefix. For example: assignment by the IETF of the Well Known Prefix. For example:
The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic
mapping between IPv4 to IPv6 addresses is defined out of the mapping between IPv4 to IPv6 addresses is defined out of the
0000::/8 address block, per (this document). 0000::/8 address block, per (this document).
6. Acknowledgements 7. 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, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Brian Carpenter, Dan Wing, Dave Thaler, David Harrington, Ed
Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John
Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund, Margaret
Matthews, Remi Denis-Courmont, Remi Despres and William Waites. Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-
Courmont, Remi Despres and William Waites.
Marcelo Bagnulo is partly funded by Trilogy, a research project Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework supported by the European Commission under its Seventh Framework
Program. Program.
7. Contributors 8. 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.
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
skipping to change at page 16, line 5 skipping to change at page 17, line 5
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
Xing Li Xing Li
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: xing@cernet.edu.cn Email: xing@cernet.edu.cn
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 9.2. Informative References
[I-D.ietf-behave-dns64] [I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation "DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers", from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-04 (work in progress), draft-ietf-behave-dns64-04 (work in progress),
December 2009. December 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
 End of changes. 55 change blocks. 
136 lines changed or deleted 144 lines changed or added

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