draft-ietf-behave-address-format-09.txt   draft-ietf-behave-address-format-10.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 Updates: 4291 (if approved) C. Huitema
Updates: 4291 (if approved) Microsoft Corporation Intended status: Standards Track Microsoft Corporation
Intended status: Standards Track M. Bagnulo Expires: February 17, 2011 M. Bagnulo
Expires: January 11, 2011 UC3M UC3M
M. Boucadair M. Boucadair
France Telecom France Telecom
X. Li X. Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
July 10, 2010 August 16, 2010
IPv6 Addressing of IPv4/IPv6 Translators IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-address-format-09.txt draft-ietf-behave-address-format-10.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 January 11, 2011. This Internet-Draft will expire on February 17, 2011.
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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Protection Against Spoofing . . . . . . . . . . . . . . . 14 5.1. Protection Against Spoofing . . . . . . . . . . . . . . . 14
5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14 5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14
5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 14 5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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.
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---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|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) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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 prefixes can only have one of deploying the address translators. The prefixes can only have one of
the following lengths: 32, 40, 48, 56, 64 or 96. (The Well-Known 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 Prefix is 96 bits long, and can only be used in the last form of the
table.) 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
skipping to change at page 7, line 19 skipping to change at page 7, line 19
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.
+-----------------------+------------+------------------------------+ +-----------------------+------------+------------------------------+
| Network-Specific | IPv4 | IPv4-Embedded IPv6 address | | Network-Specific | IPv4 | IPv4-Embedded IPv6 address |
| Prefix | address | | | Prefix | address | |
+-----------------------+------------+------------------------------+ +-----------------------+------------+------------------------------+
| 2001:DB8::/32 | 192.0.2.33 | 2001:DB8:C000:221:: | | 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: |
| 2001:DB8:100::/40 | 192.0.2.33 | 2001:DB8:1C0:2:21:: | | 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: |
| 2001:DB8:122::/48 | 192.0.2.33 | 2001:DB8:122:C000:2:2100:: | | 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: |
| 2001:DB8:122:300::/56 | 192.0.2.33 | 2001:DB8:122:3C0:0:221:: | | 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: |
| 2001:DB8:122:344::/64 | 192.0.2.33 | 2001:DB8:122:344:C0:2:2100:: | | 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: |
| 2001:DB8:122:344::/96 | 192.0.2.33 | 2001:DB8:122:344::192.0.2.33 | | 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 |
+-----------------------+------------+------------------------------+ +-----------------------+------------+------------------------------+
Table 1: Text representation of IPv4-Embedded IPv6 addresses using Table 1: Text representation of IPv4-Embedded IPv6 addresses using
Network-Specific Prefixes Network-Specific Prefixes
+-------------------+--------------+----------------------------+ +-------------------+--------------+----------------------------+
| Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address | | Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+-------------------+--------------+----------------------------+ +-------------------+--------------+----------------------------+
| 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 [RFC5735]. documentation in [RFC5735]. The representation of IPv6 addresses is
compatible with [I-D.ietf-6man-text-addr-representation].
3. Deployment Guidelines 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 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 [RFC1918] or listed in section 3 addresses, such as those defined in [RFC1918] or listed in section 3
of [RFC5735]. Address translators MUST NOT translate packets in of [RFC5735]. Address translators MUST NOT translate packets in
which an address is composed of the Well-Known Prefix and a non which an address is composed of the Well-Known Prefix and a non
global IPv4 address, they MUST drop these packets. global IPv4 address, they MUST drop these packets.
skipping to change at page 9, line 38 skipping to change at page 9, line 39
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 5 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: with a small example:
We will consider an IPv6 network with the prefix 2001:DB8: We will consider an IPv6 network with the prefix 2001:db8:
122::/48. The network administrator has selected the Network- 122::/48. The network administrator has selected the Network-
Specific prefix 2001:DB8:122:344::/64 for managing stateless IPv4/ Specific prefix 2001:db8:122:344::/64 for managing stateless IPv4/
IPv6 translation. The IPv4-Translatable address block for IPv4 IPv6 translation. The IPv4-Translatable address block for IPv4
subnet 192.0.2.0/24 is 2001:DB8:122:344:C0:2::/96. In this subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96. In this
network, the host A is assigned the IPv4-Translatable IPv6 address network, the host A is assigned the IPv4-Translatable IPv6 address
2001:DB8:122:344:C0:2:2100::, which corresponds to the IPv4 2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4
address 192.0.2.33. Host A's address is configured either address 192.0.2.33. Host A's address is configured either
manually or through DHCPv6. manually or through DHCPv6.
In this example, host A is not directly connected to the In this example, host A is not directly connected to the
translator, but instead to a link managed by a router R. The translator, but instead to a link managed by a router R. The
router R is configured to forward to A the packets bound to 2001: router R is configured to forward to A the packets bound to 2001:
DB8:122:344:C0:2:2100::. To receive these packets, R will
advertise reachability of the prefix 2001:DB8:122:344:C0:2:2100::/ db8:122:344:c0:2:2100::. To receive these packets, R will
advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/
104 in the intra-domain routing protocol -- or perhaps a shorter 104 in the intra-domain routing protocol -- or perhaps a shorter
prefix if many hosts on link have IPv4-Translatable IPv6 addresses prefix if many hosts on link have IPv4-Translatable IPv6 addresses
derived from the same IPv4 subnet. If a packet bound to derived from the same IPv4 subnet. If a packet bound to
192.0.2.33 reaches the translator, the destination address will be 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 translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
routed towards R and then to A. routed towards R and then to A.
Let's suppose now that a host B of the same domain learns the IPv4 Let's suppose now that a host B of the same domain learns the IPv4
address of A, maybe through an application-specific referral. If address of A, maybe through an application-specific referral. If
B has translation-aware software, B can compose a destination B has translation-aware software, B can compose a destination
address by combining the Network-Specific Prefix 2001:DB8:122: address by combining the Network-Specific Prefix 2001:db8:122:
344::/64 and the IPv4 address 192.0.2.33, resulting in the address 344::/64 and the IPv4 address 192.0.2.33, resulting in the address
2001:DB8:122:344:C0:2:2100::. The packet sent by B will be 2001:db8:122:344:c0:2:2100::. The packet sent by B will be
forwarded towards R, and then to A, avoiding protocol translation. forwarded towards R, and then to A, avoiding protocol translation.
Forwarding, and reverse path checks, are more efficient when Forwarding, and reverse path checks, are more efficient when
performed on the combination of the prefix and the IPv4 address. In 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 theory, routers are able to route on prefixes of any length, but in
practice there may be routers for which routing on prefixes larger practice there may be routers for which routing on prefixes larger
than 64 bits is slower. But routing efficiency is not the only than 64 bits is slower. But routing efficiency is not the only
consideration in the choice of a prefix length. Organizations also consideration in the choice of a prefix length. Organizations also
need to consider the availability of prefixes, and the potential need to consider the availability of prefixes, and the potential
impact of all-zeroes identifiers. impact of all-zeroes identifiers.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
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, i.e. selecting a prefix whose one's the Network-Specific Prefix, i.e. selecting a prefix whose one's
complement checksum equals either 0 or 0xFFFF. 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
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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.
4.2. 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.
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 would require minimal already defined. Reusing that prefix would require minimal
standardization efforts. However, being already defined is not just standardization efforts. However, being already defined is not just
an advantage, as there may be side effects of current an advantage, as there may be side effects of current
implementations. When presented with the IPv4-mapped prefix, current implementations. When presented with the IPv4-mapped prefix, current
versions of Windows and MacOS 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 nodes send IPv6 packets. If we used the IPv4-mapped prefix, these nodes
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. We thus will defeat the main purpose of the translation techniques. We thus
eliminated the first choice, and decided to not reuse the IPv4-mapped eliminated the first choice, and decided to not reuse the IPv4-mapped
prefix, ::FFFF:0:0/96. prefix, ::ffff:0:0/96.
A /32 prefix would have allowed the embedded IPv4 address to fit A /32 prefix would have allowed the embedded IPv4 address to fit
within the top 64 bits of the IPv6 address. This would have within the top 64 bits of the IPv6 address. This would have
facilitated routing and load balancing when an organization deploys facilitated routing and load balancing when an organization deploys
several translators. However, such destination-address based load several translators. However, such destination-address based load
balancing may not be desirable. It is not compatible with STUN balancing may not be desirable. It is not compatible with STUN
[RFC5389] in the deployments involving multiple stateful translators, [RFC5389] in the deployments involving multiple stateful translators,
each one having a different pool of IPv4 addresses. STUN each one having a different pool of IPv4 addresses. STUN
compatibility would only be achieved if the translators managed the compatibility would only be achieved if the translators managed the
same pool of IPv4 addresses and were able to coordinate their same pool of IPv4 addresses and were able to coordinate their
skipping to change at page 13, line 45 skipping to change at page 13, line 45
/32 prefix rather than a /96 prefix. /32 prefix rather than a /96 prefix.
According to Section 2.2 of [RFC4291], in the legal textual According to Section 2.2 of [RFC4291], in the legal textual
representations of IPv6 addresses, dotted decimal can only appear at representations of IPv6 addresses, dotted decimal can only appear at
the end. The /96 prefix is compatible with that requirement. It the end. The /96 prefix is compatible with that requirement. It
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.
5. Security Considerations 5. Security Considerations
5.1. Protection Against Spoofing 5.1. Protection Against Spoofing
IPv4/IPv6 translators can be modeled as special routers, are subject IPv4/IPv6 translators can be modeled as special routers, are subject
to the same risks, and can implement the same mitigations. (The to the same risks, and can implement the same mitigations. (The
discussion of generic threats to routers and their mitigations is discussion of generic threats to routers and their mitigations is
skipping to change at page 15, line 23 skipping to change at page 15, line 23
IPv6 Prefix Allocation Reference Note IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ---------------- ----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5] 0000::/8 Reserved by IETF [RFC4291] [1][5]
NEW: NEW:
IPv6 Prefix Allocation Reference Note IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ---------------- ----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5][TBD] 0000::/8 Reserved by IETF [RFC4291] [1][5][TBD]
[TBD] The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic [TBD] 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 [RFC-ietf-behave-address-format]. 0000::/8 address block, per [RFC-ietf-behave-address-format].
7. 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,
Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler, Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler,
David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch
van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
skipping to change at page 17, line 17 skipping to change at page 17, line 17
9.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.
9.2. Informative References 9.2. Informative References
[I-D.ietf-6man-text-addr-representation]
Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation",
draft-ietf-6man-text-addr-representation-07 (work in
progress), February 2010.
[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-10 (work in progress), July 2010.
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
IPv4/IPv6 Translation", IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-03 (work in progress), draft-ietf-behave-v6v4-framework-09 (work in progress),
October 2009. May 2010.
[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.
[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.
 End of changes. 27 change blocks. 
38 lines changed or deleted 45 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/