draft-ietf-behave-address-format-05.txt   draft-ietf-behave-address-format-06.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
Intended status: Standards Track Microsoft Corporation Updates: 4291 (if approved) Microsoft Corporation
Expires: September 15, 2010 M. Bagnulo Intended status: Standards Track M. Bagnulo
UC3M Expires: September 28, 2010 UC3M
M. Boucadair M. Boucadair
France Telecom France Telecom
X. Li X. Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
March 14, 2010 March 27, 2010
IPv6 Addressing of IPv4/IPv6 Translators IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-address-format-05.txt draft-ietf-behave-address-format-06.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 49 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 September 15, 2010. This Internet-Draft will expire on September 28, 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 BSD License. described in the 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 . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . . . 4 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4
2.1. Address Translation Algorithms . . . . . . . . . . . . . . 6 2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4
2.2. Text Representation . . . . . . . . . . . . . . . . . . . 6 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 4
2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6
2.4. Text Representation . . . . . . . . . . . . . . . . . . . 6
3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 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 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11
3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13
4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 21 skipping to change at page 3, line 21
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.
This document reserves a "Well-Known Prefix" for use in an Section 2 describes the prefixes and the format of "IPv4-Embedded
algorithmic mapping. The value of this IPv6 prefix is: IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an
IPv4 address. This format is common to both "IPv4-Converted" and
64:FF9B::/96 "IPv4-Translatable" IPv6 addresses. This section also defines the
algorithms for translating addresses, and the text representation of
Section 2 describes the format of "IPv4-Embedded IPv6 addresses", IPv4-Embedded IPv6 addresses.
i.e., IPv6 addresses in which 32 bits contain an IPv4 address. This
format is common to both "IPv4-Converted" and "IPv4-Translatable"
IPv6 addresses. This section also defines the algorithms for
translating addresses, and the text representation of IPv4-Embedded
IPv6 addresses.
Section 3 discusses the choice of prefixes, the conditions of use of Section 3 discusses the choice of prefixes, the conditions in which
the Well-Known Prefix and Network-Specific Prefixes, and the use of they can be used, and the use of IPv4-Embedded IPv6 addresses with
IPv4-Embedded IPv6 addresses with stateless and stateful translation. stateless and stateful translation.
Section 4 discusses security concerns. Section 4 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
skipping to change at page 4, line 32 skipping to change at page 4, line 27
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 Well-Known Prefix: the IPv6 prefix defined in this document for use
in an algorithmic mapping. in an algorithmic mapping.
Network-Specific Prefix: an IPv6 prefix assigned by an organization Network-Specific Prefix: an IPv6 prefix assigned by an organization
for use in algorithmic mapping. Options for the Network Specific for use in algorithmic mapping. Options for the Network Specific
Prefix are discussed in Section 3.3 and Section 3.4. 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 Section 2. contain an IPv4 address. Their format is described in
Section 2.2.
IPv4-Converted IPv6 addresses: IPv6 addresses used to represent IPv4 IPv4-Converted IPv6 addresses: IPv6 addresses used to represent IPv4
nodes in an IPv6 network. They are a variant of IPv4-Embedded nodes in an IPv6 network. They are a variant of IPv4-Embedded
IPv6 addresses, and follow the format described in Section 2. IPv6 addresses, and follow the format described in Section 2.2.
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. Section 2.2.
2. IPv4-Embedded IPv6 Address Format 2. IPv4-Embedded IPv6 Address Prefix and Format
2.1. Well Known Prefix
This document reserves a "Well-Known Prefix" for use in an
algorithmic mapping. The value of this IPv6 prefix is:
64:FF9B::/96
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-|
skipping to change at page 5, line 25 skipping to change at page 5, line 28
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix | |64| prefix | u | v4(32) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96| prefix | v4(32) | |96| prefix | v4(32) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1 Figure 1
In these addresses, the prefix shall be either the "Well-Known In these addresses, the prefix shall be either the "Well-Known
Prefix", or a "Network-Specific Prefix" unique to the organization Prefix", or a "Network-Specific Prefix" unique to the organization
deploying the address translators. (The Well-Known prefic is 96 bits deploying the address translators. The prefixes can only have one of
long, and can only be used in the last form of the table.) the following lengths: 32, 40, 48, 56, 64 or 96. (The Well-Known
prefic is 96 bits long, and can only be used in the last form of the
table.)
Various deployments justify different prefix lengths with Network- Various deployments justify different prefix lengths with Network-
Specific prefixes. The tradeoff between different prefix lengths are Specific prefixes. The tradeoff between different prefix lengths are
discussed in Section 3.3 and Section 3.4. discussed in Section 3.3 and 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
[RFC4291]. These bits MUST be set to zero. When using a /96 [RFC4291]. These bits MUST be set to zero. When using a /96
Network-Specific Prefix, the administrators MUST ensure that the bits Network-Specific Prefix, the administrators MUST ensure that the bits
64 to 71 are set to zero. A simple way to achieve that is to 64 to 71 are set to zero. A simple way to achieve that is to
skipping to change at page 6, line 18 skipping to change at page 6, line 26
o When the prefix is 64 bits 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 bits 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
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.1. 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. null suffix if needed to obtain a 128 bit address.
o If the prefix length is less than 96 bits, remove the last octet o If the prefix length is less than 96 bits, insert the null octet
and insert the null octet "u" at the appropriate position, as "u" at the appropriate position, thus causing the least
documented in Figure 1. 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, extract the "u" octet to obtain a
120 bit sequence, then extract the 32 bits following the prefix. 120 bit sequence, then extract the 32 bits following the prefix.
2.2. 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 32 skipping to change at page 7, line 32
+-------------------+--------------+----------------------------+ +-------------------+--------------+----------------------------+
| 64:FF9B::/96 | 192.0.2.33 | 64:FF9B::192.0.2.33 | | 64:FF9B::/96 | 192.0.2.33 | 64:FF9B::192.0.2.33 |
+-------------------+--------------+----------------------------+ +-------------------+--------------+----------------------------+
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 [RFC3330]. documentation in [RFC5735].
3. Deployment Guidelines and Choices 3. Deployment Guidelines and Choices
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 MAY be used by organizations deploying
translation services, as explained in Section 3.4. translation services, as explained in Section 3.4.
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 addresses. The nodes served by IPv4-Translatable IPv6
skipping to change at page 8, line 46 skipping to change at page 8, line 46
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. 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
skipping to change at page 11, line 6 skipping to change at page 11, line 6
site holding a /48 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 or (an IPv4 network to an IPv6 network), we recommend using a /64 or
a /96 prefix. a /96 prefix.
IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address
architecture and SHOULD be compatible with the IPv4 address architecture and SHOULD be compatible with the IPv4 address
architecture. The first IPv4-translatable address is the subnet- architecture. The first IPv4-translatable address is the subnet-
router anycast address in IPv6 and network identifier in IPv4, the router anycast address in IPv6 and network identifier in IPv4, the
last IPv4-translatable address is the subnet broadcast addresses in last IPv4-translatable address is the subnet broadcast addresses in
IPv4. Both of them SHOULD not be used for IPv6 nodes. In addition, 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 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 interface needs a valid address for the same subnet) and this rule
SHOULD also be applied to the corresponding subnet of the IPv4- SHOULD also be applied to the corresponding subnet of the IPv4-
translatable addresses. 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. 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.
skipping to change at page 11, line 45 skipping to change at page 11, line 45
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 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 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
skipping to change at page 14, line 20 skipping to change at page 14, line 20
multiple devices in the same network (e.g., nodes that need to prefer multiple devices in the same network (e.g., nodes that need to prefer
native over translated addresses, DNS gateways, and IPv4/IPv6 native over translated addresses, DNS gateways, and IPv4/IPv6
translators). As such, the means by which they are learned/ translators). As such, the means by which they are learned/
configured MUST be secure. Specifying a default prefix and/or format configured MUST be secure. Specifying a default prefix and/or format
in implementations provides one way to configure them securely. Any in implementations provides one way to configure them securely. Any
alternative means of configuration is responsible for specifying how alternative means of configuration is responsible for specifying how
to do so securely. to do so securely.
5. IANA Considerations 5. IANA Considerations
The Well Known Prefix falls into the range ::/8 reserved by the IETF. The IANA is requested to add a note to the documentation of the
The prefix definition does not require an IANA action. 0000::/8 address block in
http://www.iana.org/assignments/ipv6-address-space to document the
assignment by the IETF of the Well Known Prefix. For example:
The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic
mapping between IPv4 to IPv6 addresses is defined out of the
0000::/8 address block, per (this document).
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, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata,
Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip
Matthews, Remi Denis-Courmont, Remi Despres and William Waites. Matthews, Remi Denis-Courmont, Remi Despres and William Waites.
skipping to change at page 16, line 34 skipping to change at page 16, line 34
[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.
[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.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002.
[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.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004. 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.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.
Authors' Addresses Authors' Addresses
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 10-62785983 Phone: +86 10-62785983
Email: congxiao@cernet.edu.cn Email: congxiao@cernet.edu.cn
 End of changes. 24 change blocks. 
45 lines changed or deleted 60 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/