From owner-svn-src-stable-7@FreeBSD.ORG Mon May 24 06:41:57 2010 Return-Path: Delivered-To: svn-src-stable-7@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ACD01065674; Mon, 24 May 2010 06:41:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from svn.freebsd.org (unknown [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 762808FC12; Mon, 24 May 2010 06:41:57 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id o4O6fvEZ017178; Mon, 24 May 2010 06:41:57 GMT (envelope-from dougb@svn.freebsd.org) Received: (from dougb@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id o4O6fvqJ017175; Mon, 24 May 2010 06:41:57 GMT (envelope-from dougb@svn.freebsd.org) Message-Id: <201005240641.o4O6fvqJ017175@svn.freebsd.org> From: Doug Barton Date: Mon, 24 May 2010 06:41:57 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-7@freebsd.org X-SVN-Group: stable-7 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r208485 - in stable/7/contrib/bind9: . doc/draft lib/dns X-BeenThere: svn-src-stable-7@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 7-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 06:41:57 -0000 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@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 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@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 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@cernet.edu.cn + + + + + + + + + + + + + + + + + + + + + + + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***