+++ /dev/null
-
-
-
-Network Working Group C. Bao
-Internet-Draft CERNET Center/Tsinghua University
-Obsoletes: 2765 (if approved) C. Huitema
-Updates: 4291 (if approved) Microsoft Corporation
-Intended status: Standards Track M. Bagnulo
-Expires: September 28, 2010 UC3M
- M. Boucadair
- France Telecom
- X. Li
- CERNET Center/Tsinghua University
- March 27, 2010
-
-
- IPv6 Addressing of IPv4/IPv6 Translators
- draft-ietf-behave-address-format-06.txt
-
-Abstract
-
- This document discusses the algorithmic translation of an IPv6
- address to a corresponding IPv4 address, and vice versa, using only
- statically configured information. It defines a well-known prefix
- for use in algorithmic translations, while allowing organizations to
- also use network-specific prefixes when appropriate. Algorithmic
- 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.
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 28, 2010.
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 1]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
-Copyright Notice
-
- Copyright (c) 2010 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the BSD License.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3
- 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. IPv4-Embedded IPv6 Address Prefix and Format . . . . . . . . . 4
- 2.1. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4
- 2.2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . 4
- 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6
- 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 6
- 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7
- 3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7
- 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8
- 3.3. Choice of Prefix for Stateless Translation Deployments . . 8
- 3.4. Choice of Prefix for Stateful Translation Deployments . . 11
- 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11
- 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
- 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13
- 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
- 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
-
-
-
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 2]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
-1. Introduction
-
- This document is part of a series of IPv4/IPv6 translation documents.
- A framework for IPv4/IPv6 translation is discussed in
- [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios
- that will be used in this document. Other documents specify the
- behavior of various types of translators and gateways, including
- mechanisms for translating between IP headers and other types of
- messages that include IP addresses. This document specifies how an
- individual IPv6 address is translated to a corresponding IPv4
- address, and vice versa, in cases where an algorithmic mapping is
- used. While specific types of devices are used herein as examples,
- it is the responsibility of the specification of such devices to
- reference this document for algorithmic mapping of the addresses
- themselves.
-
- Section 2 describes the prefixes and the format of "IPv4-Embedded
- IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an
- IPv4 address. This format is common to both "IPv4-Converted" and
- "IPv4-Translatable" IPv6 addresses. This section also defines the
- algorithms for translating addresses, and the text representation of
- IPv4-Embedded IPv6 addresses.
-
- Section 3 discusses the choice of prefixes, the conditions in which
- they can be used, and the use of IPv4-Embedded IPv6 addresses with
- stateless and stateful translation.
-
- Section 4 discusses security concerns.
-
- In some scenarios, a dual-stack host will unnecessarily send its
- traffic through an IPv6/IPv4 translator. This can be caused by
- host's default address selection algorithm [RFC3484], referrals, or
- other reasons. Optimizing these scenarios for dual-stack hosts is
- for future study.
-
-1.1. Applicability Scope
-
- This document is part of a series defining address translation
- services. We understand that the address format could also be used
- by other interconnection methods between IPv6 and IPv4, e.g., methods
- based on encapsulation. If encapsulation methods are developed by
- the IETF, we expect that their descriptions will document their
- specific use of IPv4-Embedded IPv6 addresses.
-
-1.2. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 3]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1.3. Terminology
-
- This document makes use of the following terms:
-
- IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6
- packets, and vice versa. It may do "stateless" translation,
- meaning that there is no per-flow state required, or "stateful"
- translation where per-flow state is created when the first packet
- in a flow is received.
- Address translator: any entity that has to derive an IPv4 address
- from an IPv6 address or vice versa. This applies not only to
- devices that do IPv4/IPv6 packet translation, but also to other
- entities that manipulate addresses, such as name resolution
- proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other
- types of Application Layer Gateways (ALGs).
- Well-Known Prefix: the IPv6 prefix defined in this document for use
- in an algorithmic mapping.
- Network-Specific Prefix: an IPv6 prefix assigned by an organization
- for use in algorithmic mapping. Options for the Network Specific
- Prefix are discussed in Section 3.3 and Section 3.4.
- IPv4-Embedded IPv6 addresses: IPv6 addresses in which 32 bits
- contain an IPv4 address. Their format is described in
- Section 2.2.
- IPv4-Converted IPv6 addresses: IPv6 addresses used to represent IPv4
- nodes in an IPv6 network. They are a variant of IPv4-Embedded
- IPv6 addresses, and follow the format described in Section 2.2.
- IPv4-Translatable IPv6 addresses: IPv6 addresses assigned to IPv6
- nodes for use with stateless translation. They are a variant of
- IPv4-Embedded IPv6 addresses, and follow the format described in
- Section 2.2.
-
-
-2. IPv4-Embedded IPv6 Address Prefix and Format
-
-2.1. Well Known Prefix
-
- This document reserves a "Well-Known Prefix" for use in an
- algorithmic mapping. The value of this IPv6 prefix is:
-
- 64:FF9B::/96
-
-2.2. IPv4-Embedded IPv6 Address Format
-
- IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses
- follow the same format, described here as the IPv4-Embedded IPv6
- address Format. IPv4-Embedded IPv6 addresses are composed of a
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 4]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- 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-|
- +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- |32| prefix |v4(32) | u | suffix |
- +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- |40| prefix |v4(24) | u |(8)| suffix |
- +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- |48| prefix |v4(16) | u | (16) | suffix |
- +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- |56| prefix |(8)| u | v4(24) | suffix |
- +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- |64| prefix | u | v4(32) | suffix |
- +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- |96| prefix | v4(32) |
- +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
- Figure 1
-
- In these addresses, the prefix shall be either the "Well-Known
- Prefix", or a "Network-Specific Prefix" unique to the organization
- deploying the address translators. The prefixes can only have one of
- the following lengths: 32, 40, 48, 56, 64 or 96. (The Well-Known
- prefic is 96 bits long, and can only be used in the last form of the
- table.)
-
- Various deployments justify different prefix lengths with Network-
- Specific prefixes. The tradeoff between different prefix lengths are
- discussed in Section 3.3 and Section 3.4.
-
- Bits 64 to 71 of the address are reserved for compatibility with the
- host identifier format defined in the IPv6 addressing architecture
- [RFC4291]. These bits MUST be set to zero. When using a /96
- Network-Specific Prefix, the administrators MUST ensure that the bits
- 64 to 71 are set to zero. A simple way to achieve that is to
- construct the /96 Network-Specific Prefix by picking a /64 prefix,
- and then adding four octets set to zero.
-
- The IPv4 address is encoded following the prefix, most significant
- bits first. Depending of the prefix length, the 4 octets of the
- address may be separated by the reserved octet "u", whose 8 bits MUST
- be set to zero. In particular:
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 5]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- o When the prefix is 32 bits long, the IPv4 address is encoded in
- positions 32 to 63.
- o When the prefix is 40 bits long, 24 bits of the IPv4 address are
- encoded in positions 40 to 63, with the remaining 8 bits in
- position 72 to 79.
- o When the prefix is 48 bits long, 16 bits of the IPv4 address are
- encoded in positions 48 to 63, with the remaining 16 bits in
- position 72 to 87.
- o When the prefix is 56 bits long, 8 bits of the IPv4 address are
- encoded in positions 56 to 63, with the remaining 24 bits in
- position 72 to 95.
- o When the prefix is 64 bits long, the IPv4 address is encoded in
- positions 72 to 103.
- o When the prefix is 96 bits long, the IPv4 address is encoded in
- positions 96 to 127.
-
- 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
- constitute the suffix. These bits are reserved for future
- extensions, and SHOULD be set to zero.
-
-2.3. Address Translation Algorithms
-
- IPv4-Embedded IPv6 addresses are composed according to the following
- 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, insert the null octet
- "u" at the appropriate position, thus causing the least
- significant octet to be excluded, 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.4. 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-
- Specific Prefix may be represented using the alternative form
- presented in section 2.2 of [RFC4291], with the embedded IPv4 address
- represented in dotted decimal notation. Examples of such
- representations are presented in Table 1 and Table 2.
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 6]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- +-----------------------+------------+------------------------------+
- | Network-Specific | IPv4 | IPv4-Embedded IPv6 address |
- | Prefix | address | |
- +-----------------------+------------+------------------------------+
- | 2001:DB8::/32 | 192.0.2.33 | 2001:DB8:C000:221:: |
- | 2001:DB8:100::/40 | 192.0.2.33 | 2001:DB8:1C0:2:21:: |
- | 2001:DB8:122::/48 | 192.0.2.33 | 2001:DB8:122:C000:2:2100:: |
- | 2001:DB8:122:300::/56 | 192.0.2.33 | 2001:DB8:122:3C0:0:221:: |
- | 2001:DB8:122:344::/64 | 192.0.2.33 | 2001:DB8:122:344:C0:2:2100:: |
- | 2001:DB8:122:344::/96 | 192.0.2.33 | 2001:DB8:122:344::192.0.2.33 |
- +-----------------------+------------+------------------------------+
-
- Table 1: Text representation of IPv4-Embedded IPv6 addresses using
- Network-Specific Prefixes
-
- +-------------------+--------------+----------------------------+
- | 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 Prefix
-
- The Network-Specific Prefix examples in Table 1 are derived from the
- 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
- documentation in [RFC5735].
-
-
-3. Deployment Guidelines and Choices
-
-3.1. Restrictions on the use of the Well-Known Prefix
-
- The Well-Known Prefix MAY be used by organizations deploying
- translation services, as explained in Section 3.4.
-
- The Well-Known Prefix SHOULD NOT be used to construct IPv4-
- Translatable addresses. The nodes served by IPv4-Translatable IPv6
- addresses should be able to receive global IPv6 traffic bound to
- their IPv4-Translatable IPv6 address without incurring intermediate
- protocol translation. This is only possible if the specific prefix
- used to build the IPv4-Translatable IPv6 addresses is advertized in
- inter-domain routing, but the advertisement of more specific prefixes
- derived from the Well-Known Prefix is not supported, as explained in
- Section 3.2. Network-Specific Prefixes SHOULD be used in these
- scenarios, as explained in Section 3.3.
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 7]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- The Well-Known Prefix MUST NOT be used to represent non global IPv4
- addresses, such as those defined in [RFC1918].
-
-3.2. Impact on Inter-Domain Routing
-
- The Well-Known Prefix MAY appear in inter-domain routing tables, if
- service providers decide to provide IPv6-IPv4 interconnection
- services to peers. Advertisement of the Well-Known Prefix SHOULD be
- controlled either by upstream and/or downstream service providers
- owing to inter-domain routing policies, e.g., through configuration
- of BGP [RFC4271]. Organizations that advertize the Well-Known Prefix
- in inter-domain routing MUST be able to provide IPv4/IPv6 translation
- service.
-
- When the IPv4/IPv6 translation relies on the Well-Known Prefix,
- embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be
- advertised in BGP (especially e-BGP) [RFC4271] because this leads to
- importing the IPv4 routing table into the IPv6 one and therefore
- induces scalability issues to the global IPv6 routing table.
- Administrators of BGP nodes SHOULD configure filters that discard
- advertisements of embedded IPv6 prefixes longer than the Well-Known
- Prefix.
-
- When the IPv4/IPv6 translation service relies on Network-Specific
- Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless
- translation MUST be advertised with proper aggregation to the IPv6
- Internet. Similarly, if translators are configured with multiple
- Network-Specific Prefixes,these prefixes MUST be advertised to the
- IPv6 Internet with proper aggregation.
-
-3.3. Choice of Prefix for Stateless Translation Deployments
-
- Organizations may deploy translation services using stateless
- translation. In these deployments, internal IPv6 nodes are addressed
- using IPv4-Translatable IPv6 addresses, which enable them to be
- accessed by IPv4 nodes. The addresses of these external IPv4 nodes
- are then represented in IPv4-Converted IPv6 addresses.
-
- Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
- a Network-Specific Prefix to their IPv4/IPv6 translation service.
- IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be
- constructed as specified in Section 2.2. IPv4-Translatable IPv6
- addresses MUST use the selected Network-Specific Prefix. Both IPv4-
- Translatable IPv6 addresses and IPv4-Converted IPv6 addresses SHOULD
- use the same prefix.
-
- Using the same prefix ensures that IPv6 nodes internal to the
- organization will use the most efficient paths to reach the nodes
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 8]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- served by IPv4-Translatable IPv6 addresses. Specifically, if a node
- learns the IPv4 address of a target internal node without knowing
- that this target is in fact located behind the same translator that
- the node also uses, translation rules will ensure that the IPv6
- address constructed with the Network-Specific prefix is the same as
- the IPv4-Translatable IPv6 address assigned to the target. Standard
- routing preference (more specific wins) 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 nodes served by IPv4-Translatable IPv6 addresses. This may
- require routing on some or all of the embedded IPv4 address bits.
- Security considerations detailed in Section 4 require that routers
- check the validity of the IPv4-Translatable IPv6 source addresses,
- using some form of reverse path check.
-
- The management of stateless address translation can be illustrated
- with a small example. We will consider an IPv6 network with the
- prefix 2001:DB8:122::/48. The network administrator has selected the
- Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless
- 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-
- 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
- configured either manually or through DHCPv6.
-
- 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
- configured to forward to A the packets bound to 2001:DB8:122:344:C0:
- 2:2100::. To receive these packets, R will advertise reachability of
- the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain
- routing protocol -- or perhaps a shorter prefix if many hosts on link
- have IPv4-Translatable IPv6 addresses derived from the same IPv4
- subnet. If a packet bound to 192.0.2.33 reaches the translator, the
- destination address will be translated to 2001:DB8:122:344:C0:2:
- 2100::, and the packet will be routed towards R and then to A.
-
- Let's suppose now that a host B of the same domain learns the IPv4
- address of A, maybe through an application-specific referral. If B
- has translation-aware software, B can compose a destination address
- by combining the Network-Specific Prefix 2001:DB8:122:344::/64 and
- the IPv4 address 192.0.2.33, resulting in the address 2001:DB8:122:
- 344:C0:2:2100::. The packet sent by B will be forwarded towards R,
- and then to A, avoiding protocol translation.
-
- Forwarding, and reverse path checks, should be performed on the
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 9]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- combination of the prefix and the IPv4 address. In theory, routers
- should be able to route on prefixes of any length. However, routing
- on prefixes larger than 64 bits may be slower on some routers. But
- routing efficiency is not the only consideration in the choice of a
- prefix length. Organizations also need to consider the availability
- of prefixes, and the potential impact of all-zeroes identifiers.
-
- 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
- properties. These prefixes may however be hard to obtain, and
- 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
- zero suffix leads to an all-zeroes interface identifier, an issue
- that we discuss in Section 3.5.
-
- Intermediate prefix lengths such as /40, /48 or /56 appear as
- compromises. Only some of the IPv4 bits are part of the /64
- prefixes. Reverse path checks, in particular, may have a limited
- efficiency. Reverse path checks limited to the most significant bits
- of the IPv4 address will reduce the possibility of spoofing external
- IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4-
- Translatable IPv6 addresses.
-
- 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
- translation service. For example, if the organization is an Internet
- Service Provider 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 allocation could dedicate a /56 prefix to the
- translation service, or possibly a /96 prefix if all IPv4-
- Translatable IPv6 addresses are located on the same link.
-
- The recommended prefix length is also a function of the deployment
- scenario. The stateless translation can be used for Scenario 1,
- Scenario 2, Scenario 5, and Scenario 6 defined in
- [I-D.ietf-behave-v6v4-framework]. For different scenarios, the
- prefix length recommendations are:
- 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
- prefix for an ISP holding a /32 allocation, and a /56 prefix for a
- site holding a /48 allocation.
- 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
- 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-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 10]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- 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
-
- Organizations may deploy translation services based on stateful
- translation technology. An organization may decide to use either a
- Network-Specific Prefix or the Well-Known Prefix for its stateful
- IPv4/IPv6 translation service.
-
- When these services are used, IPv6 nodes are addressed through
- standard IPv6 addresses, while IPv4 nodes are represented by IPv4-
- Converted IPv6 addresses, as specified in Section 2.2.
-
- The stateful nature of the translation creates a potential stability
- issue when the organization deploys multiple translators. If several
- translators use the same prefix, there is a risk that packets
- belonging to the same connection may be routed to different
- translators as the internal routing state changes. This issue can be
- avoided either by assigning different prefixes to different
- translators, or by ensuring that all translators using same prefix
- coordinate their state.
-
- Stateful translation can be used in scenarios defined in
- [I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be
- used in these scenarios, with two exceptions:
- o In all scenarios, the translation MAY use a Network-Specific
- Prefix, if deemed appropriate for management reasons.
- 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
- Well-Known Prefix with non-global IPv4 addresses. That means a
- Network-Specific Prefix MUST be used in that scenario, for example
- a /96 prefix compatible with the Well-Known prefix format.
-
-3.5. Choice of Suffix
-
- The address format described in Section 2.2 recommends a zero suffix.
- Before making this recommendation, we considered different options:
- checksum neutrality; the encoding of a port range; and a value
- different than 0.
-
- In the case of stateless translation, there would be no need for the
- translator to recompute a one's complement checksum if both the IPv4-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 11]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- Translatable and the IPv4-Converted IPv6 addresses were constructed
- in a "checksum-neutral" manner, that is if the IPv6 addresses would
- have the same one's complement checksum as the embedded IPv4 address.
- In the case of stateful translation, checksum neutrality does not
- eliminate checksum computation during translation, as only one of the
- two addresses would be checksum neutral. We considered reserving 16
- bits in the suffix to guarantee checksum neutrality, but declined
- because it would not help with stateful translation, and because
- checksum neutrality can also be achieved by an appropriate choice of
- the Network-Specific Prefix, as was done for example with the Well-
- Known Prefix.
-
- There have been proposals to complement stateless translation with a
- port-range feature. Instead of mapping an IPv4 address to exactly
- one IPv6 prefix, the options would allow several IPv6 nodes to share
- an IPv4 address, with each node managing a different range of ports.
- If a port range extension is needed, it could be defined later, using
- bits currently reserved as null in the suffix.
-
- 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
- of RFC4291, which specifies that all zeroes are used for the subnet-
- router anycast address. However, in our specification, there would
- be only one node with an IPv4-Translatable IPv6 address in the /64
- subnet, and the anycast semantic would not create confusion. We thus
- decided to keep the null suffix for now. This issue does not exist
- for prefixes larger than 32 bits, such as the /40, /56, /64 and /96
- prefixes that we recommend in Section 3.3.
-
-3.6. Choice of the Well-Known Prefix
-
- Before making our recommendation of the Well-Known Prefix, we were
- faced with three choices:
- o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC
- 2765 Section 2.1;
- o request IANA to allocate a /32 prefix,
- o or request allocation of a new /96 prefix.
-
- We weighted the pros and cons of these choices before settling on the
- recommended /96 Well-Known Prefix.
-
- The main advantage of the existing IPv4-mapped prefix is that it is
- already defined. Reusing that prefix would require minimal
- standardization efforts. However, being already defined is not just
- an advantage, as there may be side effects of current
- implementations. When presented with the IPv4-mapped prefix, current
- versions of Windows and MacOS generate IPv4 packets, but will not
- send IPv6 packets. If we used the IPv4-mapped prefix, these nodes
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 12]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- would not be able to support translation without modification. This
- will defeat the main purpose of the translation techniques. We thus
- eliminated the first choice, and decided to not reuse the IPv4-mapped
- prefix, ::FFFF:0:0/96.
-
- A /32 prefix would have allowed the embedded IPv4 address to fit
- within the top 64 bits of the IPv6 address. This would have
- facilitated routing and load balancing when an organization deploys
- several translators. However, such destination-address based load
- balancing may not be desirable. It is not compatible with STUN in
- the deployments involving multiple stateful translators, each one
- having a different pool of IPv4 addresses. STUN compatibility would
- only be achieved if the translators managed the same pool of IPv4
- addresses and were able to coordinate their translation state, in
- which case there is no big advantage to using a /32 prefix rather
- than a /96 prefix.
-
- According to Section 2.2 of [RFC4291], in the legal textual
- representations of IPv6 addresses, dotted decimal can only appear at
- the end. The /96 prefix is compatible with that requirement. It
- enables the dotted decimal notation without requiring an update to
- [RFC4291]. This representation makes the address format easier to
- use, and log files easier to read.
-
- The prefix that we recommend has the particularity of being "checksum
- neutral". The sum of the hexadecimal numbers "0064" and "FF9B" is
- "FFFF", i.e. a value equal to zero in one's complement arithmetic.
- An IPv4-Embedded IPv6 address constructed with this prefix will have
- the same one's complement checksum as the embedded IPv4 address.
-
-
-4. Security Considerations
-
-4.1. Protection Against Spoofing
-
- By and large, IPv4/IPv6 translators can be modeled as special
- routers, are subject to the same risks, and can implement the same
- mitigations. There is however a particular risk that directly
- derives from the practice of embedding IPv4 addresses in IPv6:
- address spoofing.
-
- An attacker could use an IPv4-Embedded IPv6 address as the source
- address of malicious packets. After translation, the packets will
- appear as IPv4 packets from the specified source, and the attacker
- may be hard to track. If left without mitigation, the attack would
- allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses.
-
- The mitigation is to implement reverse path checks, and to verify
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 13]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- throughout the network that packets are coming from an authorized
- location.
-
-4.2. Secure Configuration
-
- The prefixes and formats need to be the configured consistently among
- multiple devices in the same network (e.g., nodes that need to prefer
- native over translated addresses, DNS gateways, and IPv4/IPv6
- translators). As such, the means by which they are learned/
- configured MUST be secure. Specifying a default prefix and/or format
- in implementations provides one way to configure them securely. Any
- alternative means of configuration is responsible for specifying how
- to do so securely.
-
-
-5. IANA Considerations
-
- The IANA is requested to add a note to the documentation of the
- 0000::/8 address block in
- http://www.iana.org/assignments/ipv6-address-space to document the
- assignment by the IETF of the Well Known Prefix. For example:
-
- The "Well Known Prefix" 64:FF9B::/96 used in an algorithmic
- mapping between IPv4 to IPv6 addresses is defined out of the
- 0000::/8 address block, per (this document).
-
-
-6. Acknowledgements
-
- Many people in the Behave WG have contributed to the discussion that
- led to this document, including Andrew Sullivan, Andrew Yourtchenko,
- Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata,
- Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus
- Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip
- Matthews, Remi Denis-Courmont, Remi Despres and William Waites.
-
- Marcelo Bagnulo is partly funded by Trilogy, a research project
- supported by the European Commission under its Seventh Framework
- Program.
-
-
-7. Contributors
-
- The following individuals co-authored drafts from which text has been
- incorporated, and are listed in alphabetical order.
-
-
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 14]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- Congxiao Bao
- CERNET Center/Tsinghua University
- Room 225, Main Building, Tsinghua University
- Beijing, 100084
- China
- Phone: +86 62785983
- Email: congxiao@cernet.edu.cn
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
- USA
- Phone: +1 425 703 8835
- Email: dthaler@microsoft.com
-
- Fred Baker
- Cisco Systems
- Santa Barbara, California 93117
- USA
- Phone: +1-408-526-4257
- Fax: +1-413-473-2403
- Email: fred@cisco.com
-
- Hiroshi Miyata
- Yokogawa Electric Corporation
- 2-9-32 Nakacho
- Musashino-shi, Tokyo 180-8750
- JAPAN
- Email: h.miyata@jp.yokogawa.com
-
- Marcelo Bagnulo
- Universidad Carlos III de Madrid
- Av. Universidad 30
- Leganes, Madrid 28911
- ESPANA
- Email: marcelo@it.uc3m.es
-
- Xing Li
- CERNET Center/Tsinghua University
- Room 225, Main Building, Tsinghua University
- Beijing, 100084
- China
- Phone: +86 62785983
- Email: xing@cernet.edu.cn
-
-
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 15]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
-8. References
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
-8.2. Informative References
-
- [I-D.ietf-behave-dns64]
- Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
- "DNS64: DNS extensions for Network Address Translation
- from IPv6 Clients to IPv4 Servers",
- draft-ietf-behave-dns64-04 (work in progress),
- December 2009.
-
- [I-D.ietf-behave-v6v4-framework]
- Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
- IPv4/IPv6 Translation",
- draft-ietf-behave-v6v4-framework-03 (work in progress),
- October 2009.
-
- [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
- E. Lear, "Address Allocation for Private Internets",
- BCP 5, RFC 1918, February 1996.
-
- [RFC3484] Draves, R., "Default Address Selection for Internet
- Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
- [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
- Reserved for Documentation", RFC 3849, July 2004.
-
- [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
- Protocol 4 (BGP-4)", RFC 4271, January 2006.
-
- [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
- BCP 153, RFC 5735, January 2010.
-
-
-
-
-
-
-
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 16]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
-Authors' Addresses
-
- Congxiao Bao
- CERNET Center/Tsinghua University
- Room 225, Main Building, Tsinghua University
- Beijing, 100084
- China
-
- Phone: +86 10-62785983
- 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
- UC3M
- Av. Universidad 30
- Leganes, Madrid 28911
- Spain
-
- Phone: +34-91-6249500
- Fax:
- Email: marcelo@it.uc3m.es
- URI: http://www.it.uc3m.es/marcelo
-
-
- Mohamed Boucadair
- France Telecom
- 3, Av Francois Chateaux
- Rennes 350000
- France
-
- Email: mohamed.boucadair@orange-ftgroup.com
-
-
-
-
-
-
-
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 17]
-\f
-Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators March 2010
-
-
- Xing Li
- CERNET Center/Tsinghua University
- Room 225, Main Building, Tsinghua University
- Beijing, 100084
- China
-
- Phone: +86 10-62785983
- Email: xing@cernet.edu.cn
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bao, et al. Expires September 28, 2010 [Page 18]
-\f
-
projects / thirdparty / bind9.git / commitdiff
