idnits 2.17.1 draft-savolainen-heuristic-nat64-discovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 24, 2010) is 4963 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave WG T. Savolainen 3 Internet-Draft Nokia 4 Intended status: Informational J. Korhonen 5 Expires: March 28, 2011 Nokia Siemens Networks 6 September 24, 2010 8 Heuristic discovery of NAT64 and Network-Specific Prefix 9 draft-savolainen-heuristic-nat64-discovery-00.txt 11 Abstract 13 Advanced hosts and applications benefit of the knowledge of an IPv6 14 address, AAAA record, synthesis taking place in the network. This 15 draft describes a method for detecting presence of NAT64 and for 16 learning Network-Specific Prefix used in the access network without 17 support from the access network. The method depends on existence of 18 known IPv4-only domain name. The information learned enables 19 applications and hosts to to perform local IPv6 address synthesis and 20 in some cases avoid NAT64. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 28, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Host behavior . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Connectivity test . . . . . . . . . . . . . . . . . . . . . 4 61 4. Hosting of an IPv4-only name(s) . . . . . . . . . . . . . . . . 4 62 5. Required IPv4 addresses . . . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 66 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 As the networks transition to IPv6, connectivity to IPv4-only domains 72 have to be provided. NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] and 73 DNS64 [I-D.ietf-behave-dns64] technologies can be utilized to make 74 IPv4-only peers look like being reachable over IPv6. The DNS64 75 utilizes IPv6 address synthesis to create local IPv6 presentations of 76 peers having only IPv4 addresses. Applications utilizing DNS for 77 resolving peers' IPv6 addresses can work seamlessly through protocol 78 translation taking place at NAT64. 80 The DNS64 cannot serve applications not using DNS, such as those 81 receiving IPv4 addresses as referrals. Such applications could 82 nevertheless be able to work through NAT64, provided they are able to 83 create locally valid IPv6 presentations of peers' IPv4 addresses. 85 This document describes a method for advanced applications to learn 86 the information required to perform local IPv6 address synthesis. 88 The knowledge of IPv6 address synthesizing taking place may also be 89 useful if DNS64 is present in dual-stack network access. In such 90 cases hosts may choose to use IPv4 addresses instead of synthesized 91 IPv6 addresses, and hence avoid traversal through NAT64. 93 2. Requirements and Terminology 95 2.1. Requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Host behavior 103 A host requiring information for local IPv6 address synthesis or for 104 NAT64 avoidance shall send a DNS query for AAAA record of a well- 105 known IPv4-only fully qualified domain name. This may happen, for 106 example, at the moment the host is configured an IPv6 address of a 107 DNS server. This may also happen at the time first DNS query for 108 AAAA record is initiated. 110 If a host receives negative reply, it learns there are no NAT64 in 111 the network. 113 The host may also have to send a DNS query for the A record of the 114 well-known IPv4-only fully qualified domain name, unless also the 115 IPv4 address is well-known by the host. 117 If a host receives AAAA reply, it knows the network is utilizing IPv6 118 address synthesis. If the received IPv6 address has the well-known 119 prefix, the host can use that information for local IPv6 address 120 synthesis. If the prefix is not a well-known the host shall search 121 for the IPv4 address inside the received IPv6 address. 123 The IPv4 address inside synthesized IPv6 address should be located at 124 some of the locations described in [I-D.ietf-behave-address-format]. 125 If the IPv4 address is not found on any of the standard locations the 126 network must be using different formatting. In such case the host 127 may try to find out the IPv4 address at some other location. 129 The information required for local IPv6 address synthesis should be 130 made available for applications to utilize. 132 3.1. Connectivity test 134 Once the host has found the IPv4 address within the received 135 synthesized IPv6 address the host should locally synthesize another 136 IPv6 address using another IPv4 address and test connectivity with 137 it. The connectivity test may be conducted e.g. with ICMPv6 or with 138 a transport layer protocol. 140 This test ensures local address synthetization results in functional 141 and protocol translatable IPv6 addresses. 143 4. Hosting of an IPv4-only name(s) 145 The required IPv4-only name for NAT64 discovery has to be hosted by 146 someone. While IANA(?) might host one(?), it may be safest for 147 device and/or application vendors to host IPv4-only names for their 148 own use. Another name may be needed for connectivity test purposes. 150 5. Required IPv4 addresses 152 Running a setup described herein requires two IPv4 addresses. One 153 for the known IPv4-only name and another one for local IPv6 address 154 synthesis and connectivity test. 156 6. Security Considerations 158 No security considerations have been identified. 160 7. IANA Considerations 162 IANA(?) should define a name and an IPv4 address for a well-known 163 IPv4-only name. 165 8. Acknowledgements 167 To be added. 169 9. Normative References 171 [I-D.ietf-behave-address-format] 172 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 173 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 174 draft-ietf-behave-address-format-10 (work in progress), 175 August 2010. 177 [I-D.ietf-behave-dns64] 178 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 179 "DNS64: DNS extensions for Network Address Translation 180 from IPv6 Clients to IPv4 Servers", 181 draft-ietf-behave-dns64-10 (work in progress), July 2010. 183 [I-D.ietf-behave-v6v4-xlate-stateful] 184 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 185 NAT64: Network Address and Protocol Translation from IPv6 186 Clients to IPv4 Servers", 187 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 188 progress), July 2010. 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, March 1997. 193 Authors' Addresses 195 Teemu Savolainen 196 Nokia 197 Hermiankatu 12 D 198 FI-33720 Tampere 199 Finland 201 Email: teemu.savolainen@nokia.com 202 Jouni Korhonen 203 Nokia Siemens Networks 204 Linnoitustie 6 205 FI-02600 Espoo 206 Finland 208 Email: jouni.nospam@gmail.com