Behave WG T. Savolainen Internet-Draft Nokia Intended status: Informational J. Korhonen Expires: March 28, 2011 Nokia Siemens Networks September 24, 2010 Heuristic discovery of NAT64 and Network-Specific Prefix draft-savolainen-heuristic-nat64-discovery-00.txt Abstract Advanced hosts and applications benefit of the knowledge of an IPv6 address, AAAA record, synthesis taking place in the network. This draft describes a method for detecting presence of NAT64 and for learning Network-Specific Prefix used in the access network without support from the access network. The method depends on existence of known IPv4-only domain name. The information learned enables applications and hosts to to perform local IPv6 address synthesis and in some cases avoid NAT64. 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 March 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Savolainen & Korhonen Expires March 28, 2011 [Page 1] Internet-Draft Heuristic NAT64 discovery September 2010 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 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 3. Host behavior . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Connectivity test . . . . . . . . . . . . . . . . . . . . . 4 4. Hosting of an IPv4-only name(s) . . . . . . . . . . . . . . . . 4 5. Required IPv4 addresses . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Savolainen & Korhonen Expires March 28, 2011 [Page 2] Internet-Draft Heuristic NAT64 discovery September 2010 1. Introduction As the networks transition to IPv6, connectivity to IPv4-only domains have to be provided. NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] and DNS64 [I-D.ietf-behave-dns64] technologies can be utilized to make IPv4-only peers look like being reachable over IPv6. The DNS64 utilizes IPv6 address synthesis to create local IPv6 presentations of peers having only IPv4 addresses. Applications utilizing DNS for resolving peers' IPv6 addresses can work seamlessly through protocol translation taking place at NAT64. The DNS64 cannot serve applications not using DNS, such as those receiving IPv4 addresses as referrals. Such applications could nevertheless be able to work through NAT64, provided they are able to create locally valid IPv6 presentations of peers' IPv4 addresses. This document describes a method for advanced applications to learn the information required to perform local IPv6 address synthesis. The knowledge of IPv6 address synthesizing taking place may also be useful if DNS64 is present in dual-stack network access. In such cases hosts may choose to use IPv4 addresses instead of synthesized IPv6 addresses, and hence avoid traversal through NAT64. 2. Requirements and Terminology 2.1. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Host behavior A host requiring information for local IPv6 address synthesis or for NAT64 avoidance shall send a DNS query for AAAA record of a well- known IPv4-only fully qualified domain name. This may happen, for example, at the moment the host is configured an IPv6 address of a DNS server. This may also happen at the time first DNS query for AAAA record is initiated. If a host receives negative reply, it learns there are no NAT64 in the network. The host may also have to send a DNS query for the A record of the well-known IPv4-only fully qualified domain name, unless also the Savolainen & Korhonen Expires March 28, 2011 [Page 3] Internet-Draft Heuristic NAT64 discovery September 2010 IPv4 address is well-known by the host. If a host receives AAAA reply, it knows the network is utilizing IPv6 address synthesis. If the received IPv6 address has the well-known prefix, the host can use that information for local IPv6 address synthesis. If the prefix is not a well-known the host shall search for the IPv4 address inside the received IPv6 address. The IPv4 address inside synthesized IPv6 address should be located at some of the locations described in [I-D.ietf-behave-address-format]. If the IPv4 address is not found on any of the standard locations the network must be using different formatting. In such case the host may try to find out the IPv4 address at some other location. The information required for local IPv6 address synthesis should be made available for applications to utilize. 3.1. Connectivity test Once the host has found the IPv4 address within the received synthesized IPv6 address the host should locally synthesize another IPv6 address using another IPv4 address and test connectivity with it. The connectivity test may be conducted e.g. with ICMPv6 or with a transport layer protocol. This test ensures local address synthetization results in functional and protocol translatable IPv6 addresses. 4. Hosting of an IPv4-only name(s) The required IPv4-only name for NAT64 discovery has to be hosted by someone. While IANA(?) might host one(?), it may be safest for device and/or application vendors to host IPv4-only names for their own use. Another name may be needed for connectivity test purposes. 5. Required IPv4 addresses Running a setup described herein requires two IPv4 addresses. One for the known IPv4-only name and another one for local IPv6 address synthesis and connectivity test. 6. Security Considerations No security considerations have been identified. Savolainen & Korhonen Expires March 28, 2011 [Page 4] Internet-Draft Heuristic NAT64 discovery September 2010 7. IANA Considerations IANA(?) should define a name and an IPv4 address for a well-known IPv4-only name. 8. Acknowledgements To be added. 9. Normative References [I-D.ietf-behave-address-format] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-10 (work in progress), August 2010. [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-10 (work in progress), July 2010. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-12 (work in progress), July 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland Email: teemu.savolainen@nokia.com Savolainen & Korhonen Expires March 28, 2011 [Page 5] Internet-Draft Heuristic NAT64 discovery September 2010 Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo Finland Email: jouni.nospam@gmail.com Savolainen & Korhonen Expires March 28, 2011 [Page 6]