draft-ietf-behave-address-format-08.txt   draft-ietf-behave-address-format-09.txt 
Network Working Group C. Bao Network Working Group C. Bao
Internet-Draft CERNET Center/Tsinghua University Internet-Draft CERNET Center/Tsinghua University
Obsoletes: 2765 (if approved) C. Huitema Obsoletes: 2765 (if approved) C. Huitema
Updates: 4291 (if approved) Microsoft Corporation Updates: 4291 (if approved) Microsoft Corporation
Intended status: Standards Track M. Bagnulo Intended status: Standards Track M. Bagnulo
Expires: November 17, 2010 UC3M Expires: January 11, 2011 UC3M
M. Boucadair M. Boucadair
France Telecom France Telecom
X. Li X. Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
May 16, 2010 July 10, 2010
IPv6 Addressing of IPv4/IPv6 Translators IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-address-format-08.txt draft-ietf-behave-address-format-09.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 November 17, 2010. This Internet-Draft will expire on January 11, 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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4
2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4 2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4
2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 5
2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6
2.4. Text Representation . . . . . . . . . . . . . . . . . . . 6 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7
3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 7 3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 7
3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7 3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7
3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
3.3. Choice of Prefix for Stateless Translation Deployments . . 8 3.3. Choice of Prefix for Stateless Translation Deployments . . 8
3.4. Choice of Prefix for Stateful Translation Deployments . . 11 3.4. Choice of Prefix for Stateful Translation Deployments . . 11
4. Design choices . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Design choices . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12 4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12
4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12 4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13 5.1. Protection Against Spoofing . . . . . . . . . . . . . . . 14
5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14 5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document is part of a series of IPv4/IPv6 translation documents. This document is part of a series of IPv4/IPv6 translation documents.
A framework for IPv4/IPv6 translation is discussed in A framework for IPv4/IPv6 translation is discussed in
skipping to change at page 6, line 28 skipping to change at page 6, line 28
encoded in positions 56 to 63, with the remaining 24 bits in encoded in positions 56 to 63, with the remaining 24 bits in
position 72 to 95. position 72 to 95.
o When the prefix is 64 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. Address translators who
receive IPv4 embedded IPv6 addresses where these bits are not zero
SHOULD ignore the bits' value and proceed as if the bits' value was
zero. (Future extensions may specify a different behavior.)
2.3. Address Translation Algorithms 2.3. Address Translation Algorithms
IPv4-Embedded IPv6 addresses are composed according to the following IPv4-Embedded IPv6 addresses are composed according to the following
algorithm: algorithm:
o Concatenate the prefix, the 32 bits of the IPv4 address and the o Concatenate the prefix, the 32 bits of the IPv4 address and the
suffix if needed to obtain a 128 bit address. suffix if needed to obtain a 128 bit address.
o If the prefix length is less than 96 bits, insert the null octet o If the prefix length is less than 96 bits, insert the null octet
"u" at the appropriate position (bits 64 to 71), thus causing the "u" at the appropriate position (bits 64 to 71), thus causing the
least significant octet to be excluded, as documented in Figure 1. least significant octet to be excluded, as documented in Figure 1.
skipping to change at page 7, line 43 skipping to change at page 7, line 49
The Network-Specific Prefix examples in Table 1 are derived from the The Network-Specific Prefix examples in Table 1 are derived from the
IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 IPv6 prefix reserved for documentation in [RFC3849]. The IPv4
address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for
documentation in [RFC5735]. documentation in [RFC5735].
3. Deployment Guidelines 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]. addresses, such as those defined in [RFC1918] or listed in section 3
of [RFC5735]. Address translators MUST NOT translate packets in
which an address is composed of the Well-Known Prefix and a non
global IPv4 address, they MUST drop these packets.
The Well-Known Prefix SHOULD NOT be used to construct IPv4- The Well-Known Prefix SHOULD NOT be used to construct IPv4-
Translatable IPv6 addresses. The nodes served by IPv4-Translatable Translatable IPv6 addresses. The nodes served by IPv4-Translatable
IPv6 addresses should be able to receive global IPv6 traffic bound to IPv6 addresses should be able to receive global IPv6 traffic bound to
their IPv4-Translatable IPv6 address without incurring intermediate their IPv4-Translatable IPv6 address without incurring intermediate
protocol translation. This is only possible if the specific prefix protocol translation. This is only possible if the specific prefix
used to build the IPv4-Translatable IPv6 addresses is advertized in used to build the IPv4-Translatable IPv6 addresses is advertized in
inter-domain routing, but the advertisement of more specific prefixes inter-domain routing, but the advertisement of more specific prefixes
derived from the Well-Known Prefix is not supported, as explained in derived from the Well-Known Prefix is not supported, as explained in
Section 3.2. Network-Specific Prefixes SHOULD be used in these Section 3.2. Network-Specific Prefixes SHOULD be used in these
skipping to change at page 9, line 17 skipping to change at page 9, line 25
Using the same prefix ensures that IPv6 nodes internal to the Using the same prefix ensures that IPv6 nodes internal to the
organization will use the most efficient paths to reach the nodes organization will use the most efficient paths to reach the nodes
served by IPv4-Translatable IPv6 addresses. Specifically, if a node served by IPv4-Translatable IPv6 addresses. Specifically, if a node
learns the IPv4 address of a target internal node without knowing learns the IPv4 address of a target internal node without knowing
that this target is in fact located behind the same translator that that this target is in fact located behind the same translator that
the node also uses, translation rules will ensure that the IPv6 the node also uses, translation rules will ensure that the IPv6
address constructed with the Network-Specific prefix is the same as address constructed with the Network-Specific prefix is the same as
the IPv4-Translatable IPv6 address assigned to the target. Standard the IPv4-Translatable IPv6 address assigned to the target. Standard
routing preference (more specific wins) will then ensure that the routing preference (more specific wins) will then ensure that the
IPv6 packets are delivered directly, without requiring that IPv6 packets are delivered directly, without requiring that
translators receive the packets and then return them message in the translators receive the packets and then return them in the direction
direction they came from. they came from.
The intra-domain routing protocol must be able to deliver packets to The intra-domain routing protocol must be able to deliver packets to
the nodes served by IPv4-Translatable IPv6 addresses. This may the nodes served by IPv4-Translatable IPv6 addresses. This may
require routing on some or all of the embedded IPv4 address bits. require routing on some or all of the embedded IPv4 address bits.
Security considerations detailed in Section 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 is 2001: IPv6 translation. The IPv4-Translatable address block for IPv4
DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the subnet 192.0.2.0/24 is 2001:DB8:122:344:C0:2::/96. In this
subnet 192.0.2.0/24. In this network, the host A is assigned the network, the host A is assigned the IPv4-Translatable IPv6 address
IPv4-Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which 2001:DB8:122:344:C0:2:2100::, which corresponds to the IPv4
corresponds to the IPv4 address 192.0.2.33. Host A's address is address 192.0.2.33. Host A's address is configured either
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 DB8:122:344:C0:2:2100::. To receive these packets, R will
advertise reachability of the prefix 2001:DB8:122:344:C0:2:2100::/ 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
skipping to change at page 13, line 22 skipping to change at page 13, line 29
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 in balancing may not be desirable. It is not compatible with STUN
the deployments involving multiple stateful translators, each one [RFC5389] in the deployments involving multiple stateful translators,
having a different pool of IPv4 addresses. STUN compatibility would each one having a different pool of IPv4 addresses. STUN
only be achieved if the translators managed the same pool of IPv4 compatibility would only be achieved if the translators managed the
addresses and were able to coordinate their translation state, in same pool of IPv4 addresses and were able to coordinate their
which case there is no big advantage to using a /32 prefix rather translation state, in which case there is no big advantage to using a
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
skipping to change at page 14, line 30 skipping to change at page 14, line 39
send packets to IPv6/IPv4 translators. Attackers could attempt to send packets to IPv6/IPv4 translators. Attackers could attempt to
fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
values for these parameters, resulting in network disruption, denial values for these parameters, resulting in network disruption, denial
of service, and possible information disclosure. To mitigate such of service, and possible information disclosure. To mitigate such
attacks, network administrators need to ensure that prefixes are attacks, network administrators need to ensure that prefixes are
configured in a secure way. configured in a secure way.
The mechanisms for achieving secure configuration of prefixes are The mechanisms for achieving secure configuration of prefixes are
beyond the scope of this document. beyond the scope of this document.
5.3. Firewall Configuration
Many firewalls and other security devices filter traffic based on
IPv4 addresses. Attackers could attempt to fool these firewalls by
sending IPv6 packets to or from IPv6 addresses that translate to the
filtered IPv4 addresses. If the attack is successful, traffic that
was previously blocked might be able to pass through the firewalls
disguised as IPv6 packets. In all such scenarios, administrators
should assure that packets that send to or from IPv4 embedded IPv6
addresses are subject to the same filtering as those directly sent to
or from the embedded IPv4 addresses.
The mechanisms for configuring firewalls and security devices to
achieve this filtering are beyond the scope of this document.
6. IANA Considerations 6. IANA Considerations
The IANA is requested to add a note to the documentation of the Upon approval of this document, IANA will make the following changes
0000::/8 address block in in the "Internet Protocol Version 6 Address Space" registry located
http://www.iana.org/assignments/ipv6-address-space to document the at http://www.iana.org/assignments/ipv6-address-space:
assignment by the IETF of the Well Known Prefix. For example:
The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic OLD:
IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5]
NEW:
IPv6 Prefix Allocation Reference Note
----------- ---------------- ------------ ----------------
0000::/8 Reserved by IETF [RFC4291] [1][5][TBD]
[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 (this document). 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,
Brian Carpenter, Dan Wing, Dave Thaler, David Harrington, Ed Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler,
Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch van Beijnum, John David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch
Schnizlein, Keith Moore, Kevin Yin, Magnus Westerlund, Margaret van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis- Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip
Courmont, Remi Despres and William Waites. Matthews, Remi Denis-Courmont, Remi Despres and William Waites.
Marcelo Bagnulo is partly funded by Trilogy, a research project Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework supported by the European Commission under its Seventh Framework
Program. Program.
8. Contributors 8. Contributors
The following individuals co-authored drafts from which text has been The following individuals co-authored drafts from which text has been
incorporated, and are listed in alphabetical order. incorporated, and are listed in alphabetical order.
skipping to change at page 17, line 43 skipping to change at page 17, line 43
[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.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010. 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
 End of changes. 19 change blocks. 
38 lines changed or deleted 75 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/