svn commit: r208485 - in stable/7/contrib/bind9: . doc/draft lib/dns
Doug Barton
dougb at FreeBSD.org
Mon May 24 06:41:57 UTC 2010
Author: dougb
Date: Mon May 24 06:41:57 2010
New Revision: 208485
URL: http://svn.freebsd.org/changeset/base/208485
Log:
Upgrade to 9.4-ESV-R2, which addresses the following:
Named could return SERVFAIL for negative responses
from unsigned zones.
Added:
stable/7/contrib/bind9/doc/draft/draft-ietf-behave-address-format-07.txt
- copied unchanged from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-address-format-07.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-09.txt
- copied unchanged from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-dns64-09.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt
- copied unchanged from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-axfr-clarify-14.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt
- copied unchanged from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
- copied unchanged from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt
- copied unchanged from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt
- copied unchanged from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsop-default-local-zones-10.txt
- copied unchanged from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-dnsop-default-local-zones-10.txt
Deleted:
stable/7/contrib/bind9/doc/draft/draft-ietf-behave-dns64-06.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-02.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt
stable/7/contrib/bind9/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt
Modified:
stable/7/contrib/bind9/CHANGES
stable/7/contrib/bind9/lib/dns/api
stable/7/contrib/bind9/lib/dns/validator.c
stable/7/contrib/bind9/version
Directory Properties:
stable/7/contrib/bind9/ (props changed)
Modified: stable/7/contrib/bind9/CHANGES
==============================================================================
--- stable/7/contrib/bind9/CHANGES Mon May 24 06:33:14 2010 (r208484)
+++ stable/7/contrib/bind9/CHANGES Mon May 24 06:41:57 2010 (r208485)
@@ -1,3 +1,8 @@
+ --- 9.4-ESV-R2 released ---
+
+2876. [bug] Named could return SERVFAIL for negative responses
+ from unsigned zones. [RT #21131]
+
--- 9.4-ESV-R1 released ---
2852. [bug] Handle broken DNSSEC trust chains better. [RT #15619]
Copied: stable/7/contrib/bind9/doc/draft/draft-ietf-behave-address-format-07.txt (from r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-address-format-07.txt)
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ stable/7/contrib/bind9/doc/draft/draft-ietf-behave-address-format-07.txt Mon May 24 06:41:57 2010 (r208485, copy of r208479, vendor/bind9/dist-9.4/doc/draft/draft-ietf-behave-address-format-07.txt)
@@ -0,0 +1,1009 @@
+
+
+
+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: October 11, 2010 UC3M
+ M. Boucadair
+ France Telecom
+ X. Li
+ CERNET Center/Tsinghua University
+ April 9, 2010
+
+
+ IPv6 Addressing of IPv4/IPv6 Translators
+ draft-ietf-behave-address-format-07.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 in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ 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."
+
+ This Internet-Draft will expire on October 11, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+
+
+
+Bao, et al. Expires October 11, 2010 [Page 1]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010
+
+
+ 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 Simplified 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 October 11, 2010 [Page 2]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 3]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 4]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 5]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 6]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 7]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 8]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 9]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 10]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 11]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 12]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 13]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010
+
+
+ throughout the network that packets are coming from an authorized
+ location.
+
+4.2. Secure Configuration
+
+ The prefixes used for address translation are used by IPv6 nodes to
+ send packets to IPv6/IPv4 translators. Attackers could attempt to
+ fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong
+ values for these parameters, resulting in network disruption, denial
+ of service, and possible information disclosure. To mitigate such
+ attacks, network administrators need to ensure that prefixes are
+ configured in a secure way.
+
+ The mechanisms for achieving secure configuration of prefixes are
+ beyond the scope of this document.
+
+
+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 October 11, 2010 [Page 14]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010
+
+
+ Congxiao Bao
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing, 100084
+ China
+ Phone: +86 62785983
+ Email: congxiao at cernet.edu.cn
+
+ Dave Thaler
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ USA
+ Phone: +1 425 703 8835
+ Email: dthaler at microsoft.com
+
+ Fred Baker
+ Cisco Systems
+ Santa Barbara, California 93117
+ USA
+ Phone: +1-408-526-4257
+ Fax: +1-413-473-2403
+ Email: fred at cisco.com
+
+ Hiroshi Miyata
+ Yokogawa Electric Corporation
+ 2-9-32 Nakacho
+ Musashino-shi, Tokyo 180-8750
+ JAPAN
+ Email: h.miyata at jp.yokogawa.com
+
+ Marcelo Bagnulo
+ Universidad Carlos III de Madrid
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ ESPANA
+ Email: marcelo at it.uc3m.es
+
+ Xing Li
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing, 100084
+ China
+ Phone: +86 62785983
+ Email: xing at cernet.edu.cn
+
+
+
+
+
+
+Bao, et al. Expires October 11, 2010 [Page 15]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 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 October 11, 2010 [Page 16]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010
+
+
+Authors' Addresses
+
+ Congxiao Bao
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing, 100084
+ China
+
+ Phone: +86 10-62785983
+ Email: congxiao at cernet.edu.cn
+
+
+ Christian Huitema
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ U.S.A.
+
+ Email: huitema at microsoft.com
+
+
+ Marcelo Bagnulo
+ UC3M
+ Av. Universidad 30
+ Leganes, Madrid 28911
+ Spain
+
+ Phone: +34-91-6249500
+ Fax:
+ Email: marcelo at it.uc3m.es
+ URI: http://www.it.uc3m.es/marcelo
+
+
+ Mohamed Boucadair
+ France Telecom
+ 3, Av Francois Chateaux
+ Rennes 350000
+ France
+
+ Email: mohamed.boucadair at orange-ftgroup.com
+
+
+
+
+
+
+
+
+
+
+
+Bao, et al. Expires October 11, 2010 [Page 17]
+
+Internet-Draft IPv6 Addressing of IPv4/IPv6 Translators April 2010
+
+
+ Xing Li
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing, 100084
+ China
+
+ Phone: +86 10-62785983
+ Email: xing at cernet.edu.cn
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-src-all
mailing list