draft-ietf-behave-address-format-04.txt   draft-ietf-behave-address-format-05.txt 
Network Working Group C. Huitema Network Working Group C. Bao
Internet-Draft Microsoft Corporation Internet-Draft CERNET Center/Tsinghua University
Obsoletes: 2765 (if approved) C. Bao Obsoletes: 2765 (if approved) C. Huitema
Intended status: Standards Track CERNET Center/Tsinghua University Intended status: Standards Track Microsoft Corporation
Expires: July 19, 2010 M. Bagnulo Expires: September 15, 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
January 15, 2010 March 14, 2010
IPv6 Addressing of IPv4/IPv6 Translators IPv6 Addressing of IPv4/IPv6 Translators
draft-ietf-behave-address-format-04.txt draft-ietf-behave-address-format-05.txt
Abstract Abstract
This document discusses the algorithmic translation of an IPv6 This document discusses the algorithmic translation of an IPv6
address to a corresponding IPv4 address, and vice versa, using only address to a corresponding IPv4 address, and vice versa, using only
statically configured information. It defines a well-known prefix statically configured information. It defines a well-known prefix
for use in algorithmic translations, while allowing organizations to for use in algorithmic translations, while allowing organizations to
also use network-specific prefixes when appropriate. Algorithmic also use network-specific prefixes when appropriate. Algorithmic
translation is used in IPv4/IPv6 translators, as well as other types translation is used in IPv4/IPv6 translators, as well as other types
of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 19, 2010. This Internet-Draft will expire on September 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
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 Format . . . . . . . . . . . . . . 4 2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . . . 4
2.1. Address Translation Algorithms . . . . . . . . . . . . . . 6 2.1. Address Translation Algorithms . . . . . . . . . . . . . . 6
2.2. Text Representation . . . . . . . . . . . . . . . . . . . 6 2.2. Text Representation . . . . . . . . . . . . . . . . . . . 6
3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7
3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7 3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7
3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
3.3. Choice of Prefix for Stateless Translation Deployments . . 8 3.3. Choice of Prefix for Stateless Translation Deployments . . 8
3.4. Choice of Prefix for Stateful Translation Deployments . . 10 3.4. Choice of Prefix for Stateful Translation Deployments . . 11
3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11
3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13
4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 13 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
skipping to change at page 8, line 40 skipping to change at page 8, line 40
translation MUST be advertised with proper aggregation to the IPv6 translation MUST be advertised with proper aggregation to the IPv6
Internet. Similarly, if translators are configured with multiple Internet. Similarly, if translators are configured with multiple
Network-Specific Prefixes,these prefixes MUST be advertised to the Network-Specific Prefixes,these prefixes MUST be advertised to the
IPv6 Internet with proper aggregation. IPv6 Internet with proper aggregation.
3.3. Choice of Prefix for Stateless Translation Deployments 3.3. Choice of Prefix for Stateless Translation Deployments
Organizations may deploy translation services using stateless Organizations may deploy translation services using stateless
translation. In these deployments, internal IPv6 nodes are addressed translation. In these deployments, internal IPv6 nodes are addressed
using IPv4-Translatable IPv6 addresses, which enable them to be using IPv4-Translatable IPv6 addresses, which enable them to be
accessed by IPv4 nodes. The addresses of these external nodes are accessed by IPv4 nodes. The addresses of these external IPv4 nodes
then represented in IPv4-Converted IPv6 addresses. are then represented in IPv4-Converted IPv6 addresses.
Organizations deploying stateless IPv4/IPv6 translation SHOULD assign Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
a Network-Specific Prefix to their IPv4/IPv6 translation service. a Network-Specific Prefix to their IPv4/IPv6 translation service.
IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be
constructed as specified in Section 2. IPv4-Translatable IPv6 constructed as specified in Section 2. IPv4-Translatable IPv6
addresses MUST use the selected Network-Specific Prefix. Both types addresses MUST use the selected Network-Specific Prefix. Both IPv4-
of addresses SHOULD use the same prefix. Translatable IPv6 addresses and IPv4-Converted IPv6 addresses SHOULD
use the same prefix.
Using the same prefix ensures that IPv6 nodes internal to the Using the same prefix ensures that IPv6 nodes internal to the
organization will use the most efficient paths to reach the nodes organization will use the most efficient paths to reach the nodes
served by IPv4-Translatable IPv6 addresses. Specifically, if a node served by IPv4-Translatable IPv6 addresses. Specifically, if a node
learns the IPv4 address of a target internal node without knowing learns the IPv4 address of a target internal node without knowing
that this target is in fact located behind the same translator that that this target is in fact located behind the same translator that
the node also uses, translation rules will ensure that the IPv6 the node also uses, translation rules will ensure that the IPv6
address constructed with the Network-Specific prefix is the same as address constructed with the Network-Specific prefix is the same as
the IPv4-Translatable IPv6 address assigned to the target. Standard the IPv4-Translatable IPv6 address assigned to the target. Standard
routing preference will then ensure that the IPv6 packets are routing preference (more specific wins) will then ensure that the
delivered directly, without requiring "hair-pinning" at the IPv6 packets are delivered directly, without requiring "hair-pinning"
translator. 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 nodes served by IPv4-Translatable IPv6 addresses. This may the nodes served by IPv4-Translatable IPv6 addresses. This may
require routing on some or all of the embedded IPv4 address bits. require routing on some or all of the embedded IPv4 address bits.
Security considerations detailed in Section 4 require that routers Security considerations detailed in Section 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.
The management of stateless address translation can be illustrated The management of stateless address translation can be illustrated
with a small example. We will consider an IPv6 network with the with a small example. We will consider an IPv6 network with the
prefix 2001:DB8:122::/48. The network administrator has selected the prefix 2001:DB8:122::/48. The network administrator has selected the
Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless
IPv4/IPv6 translation. The network is visible in IPv4 as the subnet IPv4/IPv6 translation. The IPv4-Translatable address block is 2001:
DB8:122:344:C0:2::/96 and this block is visible in IPv4 as the subnet
192.0.2.0/24. In this network, the host A is assigned the IPv4- 192.0.2.0/24. In this network, the host A is assigned the IPv4-
Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which
corresponds to the IPv4 address 192.0.2.33. Host A's address is corresponds to the IPv4 address 192.0.2.33. Host A's address is
configured either manually or through DHCPv6. configured either manually or through DHCPv6.
In this example, host A is not directly connected to the translator, In this example, host A is not directly connected to the translator,
but instead to a link managed by a router R. The router R is but instead to a link managed by a router R. The router R is
configured to forward to A the packets bound to 2001:DB8:122:344:C0: 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 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 the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain
skipping to change at page 10, line 22 skipping to change at page 10, line 24
allocation of a /32 to a small set of IPv4-Translatable IPv6 allocation of a /32 to a small set of IPv4-Translatable IPv6
addresses may be seen as wasteful. In addition, the /32 prefix and a addresses may be seen as wasteful. In addition, the /32 prefix and a
zero suffix leads to an all-zeroes interface identifier, an issue zero suffix leads to an all-zeroes interface identifier, an issue
that we discuss in Section 3.5. that we discuss in Section 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 path checks limited to the most significant bits efficiency. Reverse path checks limited to the most significant bits
of the IPv4 address will reduce the possibility of spoofing external of the IPv4 address will reduce the possibility of spoofing external
IPv4 address, but would allow IPv6 nodes to spoof internal IPv4- IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4-
Translatable addresses. Translatable IPv6 addresses.
We propose here a compromise, based on using no more than 1/256th of We propose here a compromise, based on using no more than 1/256th of
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 Internet translation service. For example, if the organization is an Internet
Service Provider with an allocated IPv6 prefix /32 or shorter, the Service Provider with an allocated IPv6 prefix /32 or shorter, the
ISP could dedicate a /40 prefix to the translation service. An end ISP could dedicate a /40 prefix to the translation service. An end
site with a /48 allocation could dedicate a /56 prefix to the site with a /48 allocation could dedicate a /56 prefix to the
translation service, or possibly a /96 prefix if all IPv4- translation service, or possibly a /96 prefix if all IPv4-
Translatable IPv6 addresses are located on the same link. Translatable IPv6 addresses are located on the same link.
skipping to change at page 10, line 47 skipping to change at page 10, line 49
[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.
IPv4-Translatable IPv6 addresses SHOULD follow the IPv6 address
architecture and SHOULD be compatible with the IPv4 address
architecture. The first IPv4-translatable address is the subnet-
router anycast address in IPv6 and network identifier in IPv4, the
last IPv4-translatable address is the subnet broadcast addresses in
IPv4. Both of them SHOULD not be used for IPv6 nodes. In addition,
the minimum IPv4 subnet can be used for hosts is /30 (the router
interface needs a valid address for the same subnet) and this rule
SHOULD also be applied to the corresponding subnet of the IPv4-
translatable addresses.
3.4. Choice of Prefix for Stateful Translation Deployments 3.4. Choice of Prefix for Stateful Translation Deployments
Organizations may deploy translation services based on stateful Organizations may deploy translation services based on stateful
translation technology. An organization may decide to use either a translation technology. An organization may decide to use either a
Network-Specific Prefix or the Well-Known Prefix for its stateful Network-Specific Prefix or the Well-Known Prefix for its stateful
IPv4/IPv6 translation service. IPv4/IPv6 translation service.
When these services are used, IPv6 nodes are addressed through When these services are used, IPv6 nodes are addressed through
standard IPv6 addresses, while IPv4 nodes are represented by IPv4- standard IPv6 addresses, while IPv4 nodes are represented by IPv4-
Converted IPv6 addresses, as specified in Section 2. Converted IPv6 addresses, as specified in Section 2.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
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.
Authors' Addresses Authors' Addresses
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
U.S.A.
Email: huitema@microsoft.com
Congxiao Bao Congxiao Bao
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University Room 225, Main Building, Tsinghua University
Beijing, 100084 Beijing, 100084
China China
Phone: +86 10-62785983 Phone: +86 10-62785983
Email: congxiao@cernet.edu.cn Email: congxiao@cernet.edu.cn
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
U.S.A.
Email: huitema@microsoft.com
Marcelo Bagnulo Marcelo Bagnulo
UC3M UC3M
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Phone: +34-91-6249500 Phone: +34-91-6249500
Fax: Fax:
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo URI: http://www.it.uc3m.es/marcelo
 End of changes. 14 change blocks. 
28 lines changed or deleted 41 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/