draft-ietf-behave-address-format-02.txt   draft-ietf-behave-address-format-03.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Obsoletes: 2765 (if approved) C. Bao Obsoletes: 2765 (if approved) C. Bao
Intended status: Standards Track CERNET Center/Tsinghua University Intended status: Standards Track CERNET Center/Tsinghua University
Expires: June 17, 2010 M. Bagnulo Expires: June 20, 2010 M. Bagnulo
UC3M UC3M
M. Boucadair M. Boucadair
France Telecom France Telecom
X. Li X. Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
December 14, 2009 December 17, 2009
IPv6 Addressing of IPv4/IPv6 Translators IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-address-format-02.txt draft-ietf-behave-address-format-03.txt
Abstract Abstract
This document discusses the algorithmic translated to a corresponding This document discusses the algorithmic translation of an IPv6
IPv4 address, and vice versa, using only statically configured address to a corresponding IPv4 address, and vice versa, using only
information. It defines a Well-Known Prefix for use in algorithmic statically configured information. It defines a Well-Known Prefix
translations, while allowing organizations to also use Network for use in algorithmic translations, while allowing organizations to
Specific Prefixes when appropriate. Algorithmic translation is used also use Network Specific Prefixes when appropriate. Algorithmic
in IPv4/IPv6 translators, as well as other types of proxies and translation is used in IPv4/IPv6 translators, as well as other types
gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 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 June 17, 2010. This Internet-Draft will expire on June 20, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv4 Embedded IPv6 Address Format . . . . . . . . . . . . . . 4 1.3. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Text Representation . . . . . . . . . . . . . . . . . . . 5 2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . . . 4
3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 6 2.1. Address Translation Algorithms . . . . . . . . . . . . . . 6
3.1. Deployment Using the Well-Known Prefix . . . . . . . . . . 6 2.2. Text Representation . . . . . . . . . . . . . . . . . . . 6
3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 6 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7
3.3. Choice of Prefix for Stateless Translation Deployments . . 7 3.1. Restrictions to the use of the Well-Known Prefix . . . . . 7
3.4. Choice of Prefix for Stateful Translation Deployments . . 8 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 9 3.3. Choice of Prefix for Stateless Translation Deployments . . 8
3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 10 3.4. Choice of Prefix for Stateful Translation Deployments . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 10
4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 11 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 11
4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 13
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document is part of a series of IPv4/IPv6 translation documents. This document is part of a series of IPv4/IPv6 translation documents.
A framework for IPv4/IPv6 translation is discussed in A framework for IPv4/IPv6 translation is discussed in
[I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios
that will be used in this document. Other documents specify the that will be used in this document. Other documents specify the
behavior of various types of translators and gateways, including behavior of various types of translators and gateways, including
mechanisms for translating between IP headers and other types of mechanisms for translating between IP headers and other types of
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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 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
Section 2 describes the format of "IPv4 Embedded IPv6 addresses", Section 2 describes the format of "IPv4-Embedded IPv6 addresses",
i.e. - IPv6 addresses in which 32 bits contain an IPv4 address. 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
addresses.
Section 3 discusses the choice of prefixes, the use of the Well-Known Section 3 discusses the choice of prefixes, the conditions of use of
Prefix, and the use of embedded addresses with stateless and stateful the Well-Known Prefix and the Network Specific Prefixes, and the use
translation. of embedded addresses with stateless and stateful translation.
Section 4 discusses security concerns. Section 4 discusses security concerns.
1.1. Applicability Scope 1.1. Applicability Scope
This document is part of a series defining address translation This document is part of a series defining address translation
services. We understand that the address format could also be used services. We understand that the address format could also be used
by other interconnection methods between IPv6 and IPv4, e.g. methods by other interconnection methods between IPv6 and IPv4, e.g. methods
based on encapsulation. If encapsulation methods are developed by based on encapsulation. If encapsulation methods are developed by
the IETF, we expect that their descriptions will document their the IETF, we expect that their descriptions will document their
specific use of IPv4 Embedded IPv6 Addresses. specific use of IPv4-Embedded IPv6 Addresses.
1.2. Notations 1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Notations
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 IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6
packets, and vice versa. It may do "stateless" translation, packets, and vice versa. It may do "stateless" translation,
meaning that there is no per-flow state required, or "stateful" meaning that there is no per-flow state required, or "stateful"
translation where per-flow state is created when the first packet translation where per-flow state is created when the first packet
in a flow is received. 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 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
skipping to change at page 4, line 16 skipping to change at page 4, line 25
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 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. These addresses can be used to represent contain an IPv4 address. Their format is described in Section 2.
IPv4 hosts to hosts in an IPv6 network. Their format is described IPv4-Converted IPv6 addresses: IPv6 addresses used to represent IPv4
in Section 2. hosts in an IPv6 network. They are a variant of IPv4-Embedded
IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6 addresses, and follow the format described in Section 2.
IPv4-Translatable IPv6 addresses: IPv6 addresses assigned to IPv6
hosts for use with stateless translation. They are a variant of hosts for use with stateless translation. They are a variant of
embedded addresses, and follow the format described in Section 2. IPv4-Embedded addresses, and follow the format described in
Section 2.
2. IPv4 Embedded IPv6 Address Format 2. IPv4-Embedded IPv6 Address Format
IPv4 Embedded IPv6 Addresses are composed of a variable length IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses
prefix, the embedded IPv4 address, and a variable length suffix, as follow the same format, described here as the IPv4-Embedded IPv6
presented in the following diagram, in which PL designates the prefix Address Format. IPv4-Embedded IPv6 Addresses are composed of a
length: variable length prefix, the embedded IPv4 address, and a variable
length suffix, as presented in the following diagram, in which PL
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 |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|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
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. deploying the address translators.
Various deployments justify different prefix lengths. The tradeoff Various deployments justify different prefix lengths. The tradeoff
between different prefix lengths are discussed in Section 3.3 and between different prefix lengths are discussed in Section 3.3 and
Section 3.4. 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
skipping to change at page 5, line 42 skipping to change at page 6, line 18
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 a zero. extensions, and SHOULD be set to a zero.
2.1. Text Representation 2.1. Address Translation Algorithms
IPv4 embedded IPv6 addresses will be represented in text in IPv4-Embedded IPv6 addresses are composed according to the following
conformity with section 2.2 of [RFC4291]. IPv4 embedded IPv6 algorithm:
o Concatenate the prefix, the 32 bits of the IPv4 address and the
null suffix if needed to obtain a 128 bit address.
o if the prefix length is less than 96 bits, remove the last octet
insert the null octet "U" at the appropriate position, as
documented in Figure 1.
The IPv4 addresses are extracted from the IPv4-Embedded IPv6
addresses according to the following algorithm:
o if the prefix is 96 bit long, extract the last 32 bits of the IPv6
address;
o for the other prefix lengths, extract the U octet to obtain a 120
bit sequence, then extract the 32 bits following the prefix.
2.2. Text Representation
IPv4-Embedded IPv6 addresses will be represented in text in
conformity with section 2.2 of [RFC4291]. IPv4-Embedded IPv6
addresses constructed using the Well Known Prefix or a /96 Network 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. representations are presented in Table 1 and Table 2.
+-----------------------+------------+------------------------------+ +-----------------------+------------+------------------------------+
| Prefix | IPv4 | IPv4 embedded IPv6 address | | Network Specific | IPv4 | IPv4-Embedded IPv6 address |
| | address | | | Prefix | address | |
+-----------------------+------------+------------------------------+ +-----------------------+------------+------------------------------+
| 2001:DB8:100::/32 | 13.1.68.3 | 2001:DB8:D01:4403:: | | 2001:DB8::/32 | 192.0.2.33 | 2001:DB8:C000:221:: |
| 2001:DB8:100::/40 | 13.1.68.3 | 2001:DB8:10D:0144:3:: | | 2001:DB8:100::/40 | 192.0.2.33 | 2001:DB8:1C0:2:21:: |
| 2001:DB8:102::/48 | 13.1.68.3 | 2001:DB8:102:D01:44:300:: | | 2001:DB8:122::/48 | 192.0.2.33 | 2001:DB8:122:C000:2:2100:: |
| 2001:DB8:102::/48 | 13.1.68.3 | 2001:DB8:102:D01:44:300:: | | 2001:DB8:122:300::/56 | 192.0.2.33 | 2001:DB8:122:3C0:0:221:: |
| 2001:DB8:102:300::/56 | 13.1.68.3 | 2001:DB8:102:30D:1:4403:: | | 2001:DB8:122:344::/64 | 192.0.2.33 | 2001:DB8:122:344:C0:2:2100:: |
| 2001:DB8:102:304::/64 | 13.1.68.3 | 2001:DB8:102:304:D:144:300:: | | 2001:DB8:122:344::/96 | 192.0.2.33 | 2001:DB8:122:344::192.0.2.33 |
| 2001:DB8:102:304::/96 | 13.1.68.3 | 2001:DB8:102:304::13.1.68.3 |
| 64:FF9B::/96 | 13.1.68.3 | 64:FF9B::13.1.68.3 |
+-----------------------+------------+------------------------------+ +-----------------------+------------+------------------------------+
Table 1: Text representation of IPv4 embedded IPv6 addresses Table 1: Text representation of IPv4-Embedded IPv6 addresses using
Network Specific Prefixes
The Network Specific Prefixes in Table 1 are derived from the IPv6 +-------------------+--------------+----------------------------+
Prefix reserved for doocumentation in [RFC3849]. | Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address |
+-------------------+--------------+----------------------------+
| 64:FF9B::/96 | 192.0.2.33 | 64:FF9B::192.0.2.33 |
+-------------------+--------------+----------------------------+
Table 2: Text representation of IPv4-Embedded IPv6 addresses using
the Well Known Prefixes
The Network Specific Prefixes examples in Table 1 are derived from
the IPv6 Prefix reserved for doocumentation in [RFC3849]. The IPv4
address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for
documentation in [RFC3330].
3. Deployment Guidelines and Choices 3. Deployment Guidelines and Choices
3.1. Deployment Using the Well-Known Prefix 3.1. Restrictions to 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. 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 host served by IPv4 translatable IPv6 Translatable addresses. The host served by IPv4-Translatable IPv6
addresses should be able to receive IPv6 traffic bound to their IPv4 addresses should be able to receive IPv6 traffic bound to their IPv4-
translatable IPv6 address without incurring intermediate protocol Translatable IPv6 address without incurring intermediate protocol
translation. This is only possible if the specific prefix used to translation. This is only possible if the specific prefix used to
build the IPv4 translatable IPv6 addresses is advertized in inter- build the IPv4-Translatable IPv6 addresses is advertized in inter-
domain routing, and this kind of specific prefix advertisement is not domain routing, and this kind of specific prefix advertisement is not
supported with the Well-Known Prefix, as explained in Section 3.2. supported with the Well-Known Prefix as explained in Section 3.2.
Network Specific Prefixes SHOULD be used in these scenarios, as
explained in Section 3.3.
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]. Doing so would addresses, such as those defined in [RFC1918]. Doing so would
introduce ambiguous IPv6 addresses. introduce ambiguous IPv6 addresses.
3.2. Impact on Inter-Domain Routing 3.2. Impact on Inter-Domain Routing
The Well-Known Prefix MAY appear in inter-domain routing tables, if The Well-Known Prefix MAY appear in inter-domain routing tables, if
service providers decide to provide IPv6-IPv4 interconnection service providers decide to provide IPv6-IPv4 interconnection
services to peers. Advertisement of the Well-Known Prefix SHOULD be services to peers. Advertisement of the Well-Known Prefix SHOULD be
skipping to change at page 7, line 17 skipping to change at page 8, line 30
When the IPv4/IPv6 translation relies on the Well-Known Prefix, When the IPv4/IPv6 translation relies on the Well-Known Prefix,
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 IPv4 routing table into IPv6 one and therefore induces importing IPv4 routing table into IPv6 one and therefore induces
scalability issues to the global IPv6 routing table. Adjacent BGP scalability issues to the global IPv6 routing table. Adjacent BGP
speakers MUST ignore advertisements of embedded IPv6 prefixes longer speakers MUST ignore advertisements of embedded IPv6 prefixes longer
than the Well-Known Prefix. BGP speakers SHOULD be able to be than the Well-Known Prefix. BGP speakers SHOULD be able to be
configured with the default Well-Known Prefix. configured with the default Well-Known Prefix.
When the IPv4/IPv6 translation service relies on Network Specific When the IPv4/IPv6 translation service relies on Network Specific
Prefixes and stateless translation is used, the IPv4-translatable Prefixes and stateless translation is used, the IPv4-Translatable
IPv6 prefixes MUST be advertised with proper aggregation to the IPv6 IPv6 prefixes MUST be advertised with proper aggregation to the IPv6
Internet. Similarly, if translators are configured with multiple Internet. Similarly, if translators are configured with multiple
Network Specific Prefixes, these prefixes MUST be advertised to the Network Specific Prefixes, these prefixes MUST be advertised to the
IPv6 Internet with proper aggregation. IPv6 Internet with proper aggregation.
3.3. Choice of Prefix for Stateless Translation Deployments 3.3. Choice of Prefix for Stateless Translation Deployments
Organization may deploy translation services using stateless Organization may deploy translation services using stateless
translation. In these deployments, internal IPv6 hosts are addressed translation. In these deployments, internal IPv6 hosts are addressed
using "IPv4 translatable" IPv6 addresses, which enable them to be using "IPv4-Translatable" IPv6 addresses, which enable them to be
accessed by IPv4 hosts. The addresses of these external hosts are accessed by IPv4 hosts. The addresses of these external hosts are
then represented in "IPv4 Embedded" IPv6 addresses. 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 Embedded" addresses MUST be constructed "IPv4-Translatable" and "IPv4-Converted" addresses MUST be
as specified in Section 2. IPv4 translatable IPv6 addresses MUST use constructed as specified in Section 2. IPv4-Translatable IPv6
the selected Network Specific Prefix. Both types of addresses SHOULD addresses MUST use the selected Network Specific Prefix. Both types
use the same prefix. Using the same prefix ensures that internal of addresses SHOULD use the same prefix.
IPv6 hosts will use the most efficient paths to reach the hosts
served by "IPv4 translatable" addresses. Using the same prefix ensures that internal IPv6 hosts will use the
most efficient paths to reach the hosts served by "IPv4-Translatable"
addresses. Specifically, if an internal host learns the IPv4 address
of a target internal host without knowing that this target is in fact
located behind the same translator, translation rules will ensure
that the IPv6 address constructed with the network specific prefix is
the same as the IPv4-Translatable address assigned to the target.
Standard routing preference will then ensure that the IPv6 packets
are delivered directly, without requiring "hair-pinning" at the
translator.
The intra-domain routing protocol must be able to deliver packets to The intra-domain routing protocol must be able to deliver packets to
the hosts served by IPv4 translatable IPv6 addresses. This may the hosts 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 4 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.
Forwarding, and reverse path checks, should be performed on the Forwarding, and reverse path checks, should be performed on the
combination of the "prefix" and the IPv4 address. In theory, routers combination of the "prefix" and the IPv4 address. In theory, routers
should be able to route on prefixes of any length. However, routing should be able to route on prefixes of any length. However, routing
on prefixes larger than 64 bits may be slower. But routing on prefixes larger than 64 bits may be slower. But routing
efficiency is not the only consideration in the choice of a prefix efficiency is not the only consideration in the choice of a prefix
length. Organizations also need to consider the availability of length. Organizations also need to consider the availability of
prefixes, and the potential impact of all-zeroes identifiers. prefixes, and the potential impact of all-zeroes identifiers.
If a /32 prefix is used, all the routing bits are contained in the If a /32 prefix is used, all the routing bits are contained in the
top 64 bits of the IPv6 address, leading to excellent routing top 64 bits of the IPv6 address, leading to excellent routing
properties. These prefixes may however be hard to obtain, and properties. These prefixes may however be hard to obtain, and
allocation of a /32 to a small set of IPv4 translatable addresses may allocation of a /32 to a small set of IPv4-Translatable addresses may
be seen as wasteful. In addition, the /32 prefix and a zero suffix be seen as wasteful. In addition, the /32 prefix and a zero suffix
leads to an all-zeroes interface identifier, an issue that we discuss leads to an all-zeroes interface identifier, an issue that we discuss
in Section 3.5. in Section 3.5.
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 checks limited to the most significant bits of efficiency. Reverse checks limited to the most significant bits of
the IPv4 address will reduce the possibility of spoofing external the IPv4 address will reduce the possibility of spoofing external
IPv4 address, but would allow IPv6 hosts to spoof internal IPv4 IPv4 address, but would allow IPv6 hosts to spoof internal IPv4-
translatable addresses. Translatable addresses.
We propose here a compromise, based on using no more than 1/256th of We propose here a compromise, based on using no more than 1/256th of
an organization's allocation of IPv6 addresses for the IPv4/IPv6 an organization's allocation of IPv6 addresses for the IPv4/IPv6
translation service. For example, if the organization is an ISP, translation service. For example, if the organization is an ISP,
with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate
a /40 prefix to the translation service. An end site with a /48 a /40 prefix to the translation service. An end site with a /48
allocation could dedicate a /56 prefix to the translation service, or allocation could dedicate a /56 prefix to the translation service, or
possibly a /96 prefix if all IPv4 Translatable IPv4 Addresses are possibly a /96 prefix if all IPv4-Translatable IPv6 Addresses are
located on the same link. 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 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), we recommend using a /40
prefix for an ISP holding a /32 allocation, and a /56 prefix for a prefix for an ISP holding a /32 allocation, and a /56 prefix for a
site holding a /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.
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 hosts are addressed through When these services are used, IPv6 hosts are addressed through
standard IPv6 addresses, while IPv4 hosts are represented by IPv4 standard IPv6 addresses, while IPv4 hosts are represented by IPv4-
embedded addresses, as specified in Section 2. Converted addresses, as specified in Section 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
mitigated either by assigning different prefixes to different mitigated either by assigning different prefixes to different
translators, or by ensuring that all translators using same prefix translators, or by ensuring that all translators using same prefix
coordinate their state. coordinate their state.
skipping to change at page 9, line 33 skipping to change at page 11, line 4
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 recommends a zero suffix.
Before making this recommendation, we considered different options: Before making this recommendation, we considered different options:
checksum neutrality; the encoding of a port range; and a value checksum neutrality; the encoding of a port range; and a value
different than 0. different than 0.
The "neutrality checksum" option would give a chosen value to 16 of In the case of stateless translation, there would be no need for the
the suffix bits to ensure that the "IPv4 embedded" IPv6 address has translator to recompute complement to 1 checksum if both the IPv4-
the same 16 bit 1's complement checksum as the embedded IPv4 address. Translatable addresses and the IPv4-Converted address were
There have been discussion of this checksum in the working group constructed in a "checksum-neutral" manner, that is if the IPv6
mailing list, and some push to standardize a checksum format. addresses would have the some complement to 1 checksum as the
However, we observed that a neutral checksum alone does not eliminate embedded IPv4 address. In the case of stateful translation, checksum
checksums computation during stateful translation, as only one of the neutrality does eliminate checksums computation during translation,
two addresses would be checksum neutral. In the case of stateless as only one of the two addresses would be checksum neutral. We
translation, translators may want to recompute the checksum anyhow, considered reserving 16 bits in the suffix to guarantee checksum
to verify the validity of the translated datagrams. In the case of neutrality, but declined because it would not help with stateful
stateful translation, the Well Known Prefix was chosen to provide translation, because checksum neutrality can also be achieved by an
checksum neutrality. We thus chose the simplest alternative, to not appropriate choice of the Network Specific Prefix. The Well Known
specify a neutrality checksum. Prefix was chosen to provide checksum neutrality.
There have been proposals to complement stateless translation with a There have been proposals to complement stateless translation with a
port-range feature. Instead of mapping an IPv4 address to exactly port-range feature. Instead of mapping an IPv4 address to exactly
one IPv6 prefix, the options would allow several IPv6 hosts to share one IPv6 prefix, the options would allow several IPv6 hosts to share
an IPv4 address, with each host managing a different range of ports. an IPv4 address, with each host managing a different range of ports.
But these schemes are not yet specified in work group documents. If But these schemes are not yet specified in work group documents. If
a port range extension is needed, it could be defined later, using a port range extension is needed, it could be defined later, using
bits currently reserved as null in the suffix. bits currently reserved as null in the suffix.
When a /32 prefix is used, 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 IPv4 translatable node in the /64 subnet, and the anycast be only one IPv4-Translatable node in the /64 subnet, and the anycast
semantic would not create confusion. We thus decided to keep the semantic would not create confusion. We thus decided to keep the
null suffix for now. (This issue does not exist for prefixes larger null suffix for now. (This issue does not exist for prefixes larger
than 32 bits, such as the /40, /56, /64 and /96 prefixes that we than 32 bits, such as the /40, /56, /64 and /96 prefixes that we
recommend in Section 3.3.) recommend in Section 3.3.)
3.6. Choice of the Well-Known Prefix 3.6. 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
skipping to change at page 11, line 17 skipping to change at page 12, line 37
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 complement to 1 arithmetic. An "FFFF", i.e. a value equal to zero in complement to 1 arithmetic. An
IPv4 embedded IPv6 address constructed with this prefix will have the IPv4-Embedded IPv6 address constructed with this prefix will have the
same complement to 1 checksum as the embedded IPv4 address. same complement to 1 checksum as the embedded IPv4 address.
4. Security Considerations 4. Security Considerations
4.1. Protection Against Spoofing 4.1. Protection Against Spoofing
By and large, address translators can be modeled as special routers, By and large, address translators can be modeled as special routers,
are subject to the same risks, and can implement the same are subject to the same risks, and can implement the same
mitigations. There is however a particular risk that directly mitigations. There is however a particular risk that directly
derives from the practice of embedding IPv4 addresses in IPv6: derives from the practice of embedding IPv4 addresses in IPv6:
address spoofing. address spoofing.
An attacker could use an IPv4 embedded address as the source address An attacker could use an IPv4-Embedded address as the source address
of malicious packets. After translation, the packets will appear as of malicious packets. After translation, the packets will appear as
IPv4 packets from the specified source, and the attacker may be hard IPv4 packets from the specified source, and the attacker may be hard
to track. If left without mitigation, the attack would allow to track. If left without mitigation, the attack would allow
malicious IPv6 nodes to spoof arbitrary IPv4 addresses. malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
The mitigation is to implement reverse path checks, and to verify The mitigation is to implement reverse path checks, and to verify
throughout the network that packets are coming from an authorized throughout the network that packets are coming from an authorized
location. location.
4.2. Secure Configuration 4.2. Secure Configuration
skipping to change at page 14, line 9 skipping to change at page 15, line 9
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 8. References
8.1. Normative References 8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3", BCP 9, RFC 2026, October 1996. 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 8.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-02 (work in progress), draft-ietf-behave-dns64-04 (work in progress),
October 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
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.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
(SIIT)", RFC 2765, February 2000. September 2002.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, 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.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
U.S.A. U.S.A.
Email: huitema@microsoft.com Email: huitema@microsoft.com
 End of changes. 48 change blocks. 
132 lines changed or deleted 170 lines changed or added

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