Internet Engineering Task Force O. Nakamura Internet-Draft Keio Univ./WIDE Project Intended status: Informational H. Hazeyama Expires: July 16, 2014 NAIST / WIDE Project Y. Ueno Keio Univ./WIDE Project A. Kato Keio Univ. / WIDE Project January 12, 2014 IPv4 Address Literal in URL draft-osamu-v6ops-ipv4-literal-in-url-01 Abstract In an IPv6-only environment with DNS64/NAT64 based translation service, there is no way to get access a URL whose domain name part includes an IPv4 address literal. This memo discusses a few methods to rewrite the URL on an IPv6-only host so that the URL is accessible from the IPv6-only host. 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 July 16, 2014. Copyright Notice Copyright (c) 2014 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 Nakamura, et al. Expires July 16, 2014 [Page 1] Internet-Draft IPv4addr in URL January 2014 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction and Overview When a host in an IPv6 only environment (an IPv6-only host) has to access an IPv4-only destination, a translator-based approach is a powerful tool. The translator-based approach is usually composed of a DNS64 server [RFC6147] and a stateful NAT64 translator [RFC6146]. The DNS64 server responds with an AAAA record of an IPv4 embedded IPv6 address with significant IPv6 prefix assigned to the NAT64 translator. The IPv6-only host sends an IPv6 packet, which is translated by the NAT64 box to an IPv4 packet. The translation of responded IPv4 packet back into an IPv6 packet is also performed in the NAT64 translator. The NAT64 with DNS64 approach works well for most destinations. It does not work well when the DNS response packet included NXDOMAIN or SERVFAIL to the AAAA query, partly described in [RFC4074]. Resolution of this case is out of scope of this memo. It is legitimate to embed an IPv4 address literal in an URL such as follows: http://192.0.2.10/index.html In the environment described above, the destination is not accessible from an IPv6-only host. This problem has already been reported in [RFC6586] and other experiences. The reason why we cannot access the destination specified by above notation is that no DNS lookup is performed in most cases, and no DNS64 service is able to tell an IPv4 embedded IPv6 address to the host. To perform DNS64/NAT64 translation against such an IPv4 Nakamura, et al. Expires July 16, 2014 [Page 2] Internet-Draft IPv4addr in URL January 2014 address literal notation, some mechanism will be required. This memo proposes a special-use TLD. We denote the special-use TLD as ``.TLD'' which will be replaced with actual TLD based on discussion in Section 3.5. The concept of ``.TLD'' is simple; all IPv4 address literal notations are rewritten to ``.TLD'' on the IPv6-only host, letting DNS servers and translators translate the IPv4 address literal to appropriate IP address on each leaf network. For example, .TLD in DNS64/NAT64 environment would be translated to a NAT64 prefix mapped address. 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]. 2. Scope of this memo Before discussing solutions, we define the scope of this memo. We focus only on smooth migration to an IPv6-only environment with the DNS64/NAT64 solution. Therefore, we focus on only ``IPv4 address literal'' problem mentioned in [RFC6586]. The ``IPv6 address literal'' is out of scope of this memo, because an URL including IPv6 address literal can be accessible in IPv6-only networks and in dual stack networks. The solutions to keep IPv4-only hosts or IPv4-only applications in IPv6 only environment are out of scope on this memo. 3. A special-use TLD for IPv4 Address Literal When the part of IPv4 address literal is written to form a pseudo FQDN, the DNS64 server can return an AAAA record with the specified IPv4 address that is mapped to a NAT64 prefix. Once an AAAA record is obtained, the IPv6-only host can send an IPv6 packet to the destination. The IPv6 packet will be translated via NAT64 translator in the same way as a regular IPv4-only destination. Figure 1 figures out an example of the DNS query flow in the proposal of this memo. 3.1. The procedure in detail The procedure of the special-use TLD is as follows; Nakamura, et al. Expires July 16, 2014 [Page 3] Internet-Draft IPv4addr in URL January 2014 1. An host internally attaches ``.TLD'' to an IPv4 address literal. For example, is rewritten to .TLD. 2. The host gets access to .TLD instead of . 3. As .TLD looks like a regular FQDN, the IPv6-only host will query the FQDN to a recursive resolver through the local resolver. 4. The DNS server recognizes that the FQDN ``.TLD'' is a special-use TLD, then, the recursive resolver forwards the query to a special authoritative DNS server for ``.TLD'' (authoritative .TLD DNS server). 5. When the authoritative .TLD DNS server receives a DNS query, then, 1. If the query asks ``.TLD '', the authoritative .TLD DNS sever simply removes ``.TLD'' part from the FQDN and returns ``'' as the A record. 2. To avoid misuses, the authoritative .TLD DNS server MAY check whether the PTR record corresponding to exists or not. If the PTR record of exists, the authoritative .TLD DNS authoritative server MAY return a DNS response with a TXT record as well to notify the existence of the PTR record corresponding to the issued IPv4 address literal. 3. Otherwise, the authoritative .TLD DNS server returns NXDOMAIN. 6. When the recursive resolver, that issued ``.TLD '', receives the DNS response from the authoritative .TLD DNS server, then, 1. If the network is an IPv6-only network, and if the IPv6-only network has a DNS64 server (or function) and NAT64 translator(s), then, the DNS64 server WOULD convert into a NAT64 prefix mapped address and returns the NAT64 prefixmapped address as an AAAA record. 2. If the network is a dual stack network, and if the dual stack network does not have any DNS64/NAT64 function, then, DNS4 server returns as an A record. 3. If the network is a dual stack network, and if the dual stack network has any DNS64/NAT64 function, then, MAY be returned as an A record and NAT64 prefix mapped address MAY be returned as an AAAA record. 4. If the network is an IPv4 only network, then, DNS4 server returns as an A record. 7. After the name resolution procedure is completed, the host will access the through an appropriate socket. Nakamura, et al. Expires July 16, 2014 [Page 4] Internet-Draft IPv4addr in URL January 2014 +----------+ | auth DNS | | for PTR | | Record | +----------+ || (5) || +-------+ +--------+ +---------+ +----------+ | app |--(2)-->| |--(3)-->|Recursive|--(4)-->|auth .TLD | |(1)(7) |<-(6)-- |resolver|<-(6)---|Resolver |<-(5)---|DNS server| +-------+ | | | | +----------+ +--------+ | (DNS64) | +---------+ DNS Query Flow Figure 1 This solution would not require the modification of common shared libraries on Operating Systems. The DNS implementations SHOULD support the special-use TLD and the procedure mentioned above, or a special-use DNS server, that treats only ``.TLD'' domain, SHOULD be placed. The modification of NAT64 or DHCP are not required. This solution has other advantages. As drawn in Figure 2, a network operator may set DNS64 and several NAT64 nodes to handle or separate for the IPv4 only private segment and/or for multiple global IPv4 access from IPv6 only segments in the local network. In this solution, users do not need to take care of the selection of NAT64 prefixes and NAT64 nodes. Nakamura, et al. Expires July 16, 2014 [Page 5] Internet-Draft IPv4addr in URL January 2014 +-------------+ +-------+ +-------------------+ | +====| NAT64 |=====+ IPv4 ISP A | | IPv6 Only | +-------+ +-------------------+ | Segment | | | +-------+ +-------------------+ | +====| NAT64 |=====+ IPv4 ISP B | +-------------+ +-------+ +-------------------+ | +---+---+ | DNS64 | +-------+ +-------+ | DNS64 | +---+---+ | +-------------+ +--------+ +----------+ | | +-------+ | IPv6 | +-------+ | | | 192.168.0.0 +===| NAT64 |==+ Only +==| NAT64 |==+ IPv4 | | | +-------+ | Seg. | +-------+ | Internet | +-------------+ +--------+ +----------+ Example of Possible Network Diagrams with DNS64/NAT64 Figure 2 3.2. Use case 1: manual use For example, consider living on an IPv6-only network with DNS64/ NAT64, and receiving a message like ``please download a file foo.doc from a ftp server 192.0.2.10''. Usually, you may estimate the NAT64 prefix and calculate NAT64 prefix mapped address through [RFC7050] or [RFC7051]. Under the proposed mechanism, you can just type as follow; % ftp 192.0.2.10.TLD The packet would be transferred along with [RFC6384]. 3.3. Use case 2: browser plug-in An IPv4 address literal is often used in URL for the lazy DNS operation, a temporary HTTP server or a hidden (private) server. Taking into account user convenience, a browser plug-in can be developed that it converts the on the hostname part of an URL to .TLD. It may suggested to turn this on when the host is on IPv6-only network, however, it may not be easy to detect it. The sample of Google Chrome plug-in is attached in Appendix B Nakamura, et al. Expires July 16, 2014 [Page 6] Internet-Draft IPv4addr in URL January 2014 3.4. Other Possible Solutions Several possible solutions can be considered described below, however, most of them would not work between considerable fraction of IPv6 only networks and dual stack networks. 3.4.1. IPv4-Compatible IPv6 Address The literally embedded IPv4 address is converted to an IPv4- Compatible IPv6 address, and sent to the NAT64 converter as usual. This solution requires application or common shared library modification. Also, the procedure for learning about the NAT64 prefix to be used for a particular IPv4 destination is issued. Looking up to some known IPv4-only anchor host is a possible method. [RFC7050] says this anchor host solution. However, current ISC BIND DNS64 implementation can set different NAT64 prefixes to different IPv4 address prefixes. Therefore, this solution would not work well. 3.4.2. Various Heuristics and Analysis [RFC7051] analyzes pros. and cons. of various solutions to learn NAT64 prefix on a host : 1. DNS query for a well-known name, 2. EDNS0 Option Indicating AAAA Record Synthesis and Format, 3. EDNS0 Flags Indicating AAAA Record Synthesis and Format, 4. DNS Resource Record for IPv4-Embedded IPv6 Address, 5. Learning the IPv6 Prefix of a Network's NAT64 Using DNS, 6. Learning the IPv6 Prefix of a Network's NAT64 Using DHCPv6, 7. Learning the IPv6 Prefix of a Network's NAT64 Using Router Advertisements, 8. Using Application-Layer Protocols such as STUN 9. Learning the IPv6 Prefix of a Network's NAT64 Using Access- Technology-Specific Methods. The proposal of this memo likes to the 5th solution of RFC7051, however, this proposal is a much more simple DNS solution. 3.4.3. Using BIH or 464XLAT CLAT on a host Bump in the Host (BIH) [RFC6535] and 464XLAT [RFC6877] are possible solutions, both of which are aimed at retaining the usage of IPv4- only applications in IPv6-only environment. BIH has a local translator function between the socket API and the TCP/IP stack. On the other hand, 464XLAT provides PLAT (Provider side XLAT) [RFC6146] and CLAT (Customer side XLAT) [RFC6145]. Some mobile carriers have started CLAT CPE on smart phones. Therefore, some CLAT plug-in on a browser or CLAT CPE on a host may work. Nakamura, et al. Expires July 16, 2014 [Page 7] Internet-Draft IPv4addr in URL January 2014 The BIH case requires several extensions on Operating Systems, so we have to wait many independent Operating System Open Source Projects and/or commercial Operating System vendors support BIH in their Operating Systems. In case of the 464XLAT, 464XLAT assumes that a user always uses a specific CLAT and PLAT pair. If a user want to change or move various public wi-fi networks, then, a global reachable PLAT might be placed and a CLAT on a host has to equip a function that switches the CLAT function depending on the condition of the current network. 3.5. special-use TLD alternatives A few candidates of the special-use TLD is discussed here. 3.5.1. Use of .host special TLD A special string ``.host'' is attached to an IPv4 address literal notation like ``192.0.2.10'' to form a pseudo FQDN such as ``192.0.2.10.host''. Also, IPv4 address and port number literal is often used, for instance, ``192.0.2.10:8080'' becomes ``192.0.2.10.host:8080''. 3.5.2. Use of .ip4host.arpa special TLD This idea is almost the same as ``.host'', but uses ``ip4host.arpa'' top level labels rather than ``.host''. While the pseudo FQDN is expected to appear only in the DNS look up by an IPv6-only host, it may leak to the global Internet. In order to avoid the query to the Root DNS servers, use of the sub-domain of ".arpa" may be recommended. The generated pseudo FQDN looks like ``192.0.2.10.ip4host.arpa''. 3.5.3. Use of .dns64 special TLD The special-use TLD is mainly aimed to force IPv4 address literal notation to be translated by DNS64/NAT64 in IPv6-only environments. Therefore, ``.dns64'' reflects the request for DNS64/NAT64 translation against an IPv4 address. 3.5.4. Our recommendation We, authors of this memo, discussed which special-use TLD is suitable. Our recommendation is to use ``.host'' from the view of usability. Of course, we will accept any feedbacks from the community such as IETF v6ops and dnsops working groups and users community. Nakamura, et al. Expires July 16, 2014 [Page 8] Internet-Draft IPv4addr in URL January 2014 4. Discussions 4.1. Usages of IPv6 address literal The special-use TLD may be applied to IPv6 address cases in same ways, however, such notation is not required in dual stack / IPv6- only environment, generally. 4.2. Attached the special-use TLD to a regular FQDN Conceptually, the special-use TLD would be attached to only IPv4 address literals, however, the special-use TLD may be attached to a regular FQDN notation like ``foo.bar.com.TLD''. We propose that such misuses should be discarded on the DNS or applications on the host side. 4.3. An embedded IP address literal in the content part of URL In some case, may be embedded into the content part of a URL, however, it may be difficult for users or browser plug-ins to recognize unambiguously that a string like surely means some IPv4 address. From the point of view of IPv6 migration, embedded IP address literal in the content part of an URL MUST be avoided. 4.4. Prevention the leak of the special-use TLD When the special-use TLD ``.TLD'' is actually employed in the operation, ``.TLD'' will leak to the public DNS infrastructure including root DNS servers as seen in ``.local''. Therefore, once consensus is obtained, the relevant TLD SHOULD be delegated to a set of DNS servers. Two possible DNS operation methods can be considered. One is to delegate the TLD to AS112 servers [as112-servers]. When one of the AS112 servers received a query with the special-use TLD, it returns with NXDOMAIN. The other possible DNS operation is to deploy a set of special purpose DNS servers which accept queries with ``.TLD'' and synthesize an A record corresponding to the IPv4 address in the QNAME when it is a legitimate IPv4 address. Otherwise, NXDOMAIN is returned. 4.5. Possibitily to break connections with Apache VirtualHost concept Changing the URL (swapping the DNS name or adding in a Pref64) frequently breaks the connections since the application is aware of the name it expects, and connecting correctly to the correct IP Nakamura, et al. Expires July 16, 2014 [Page 9] Internet-Draft IPv4addr in URL January 2014 address is not sufficient, the name must also be the same in many cases. For example, many websites use the Apache VirtualHost concept. When a web site that changes contents along with accessed IP address family like http://www.kame.net/ or http://dual.tlund.se/ , and If some client accesses such web site by .TLD instead of FQDN, the VirtualHost may not work as intended. Therefore, such web site, that uses the Apache VirtualHost concept, SHOULD NOT use in URL and SHOULD use appropriate FQDN. 4.6. Inaffinity with HTTP/HTTPS Cookie This solution may not work with HTTP/HTTPS cookie. We should also consider the HTTP security considerations for the cases where someone puts one of the names into a URL. For example, consider http://192.0.2.10.TLD/ to an origin that sets a cookie on the domain "*.10.TLD". There are likely already plenty of ways to do the same thing out there, so this may not be a major issue. 5. Implementation Strategy It is suggested to implement the .TLD rewriting as in the following order: 1. Define .TLD Once the community agrees to accept the rewriting scheme described in this memo, it must fix the .TLD to be used. The .TLD WOULD require the update of [RFC6761]. 2. .TLD delegation DNS queries with .TLD can leak to the DNS of the global Internet, it is highly suggested to delegate .TLD to a set of authoritative DNS servers as discussed in Section 4.4. 3. DNS64 modification DNS64 implementation is suggested to modify to respond corresponding AAAA record to a query with .TLD. This process can be done in parallel to the step 2 above. 4. Start using .TLD rewriting After, at least the step 2 is completed, the TLD rewriting may be used in manually described in Section 3.2 or automatically by browser plugins described in Section 3.3. While further discussions and observation is required, we may discourage to use an URL in IPv4 literal embedded. Instead, we may encourage to use .TLD notation as a legitimate URL even Nakamura, et al. Expires July 16, 2014 [Page 10] Internet-Draft IPv4addr in URL January 2014 in the server side. 6. Security Considerations The recommendation contains security considerations related to DNS. The special DNS of this memo only treats the IPv4 address literal with ``.TLD''. Therefore, the special DNS MAY use self-signed / authorized key for DNS responses. When a client is to access an URL with IPv4 literal address embedded, it triggers a DNS query, and the query may be sent over the Internet to the nearest authoritative .TLD DNS server. It may break the confidentiality against the DNS service. 7. IANA Considerations According to the discussion with communities, this memo may call for changes or additions of special-use TLD to the IANA registry. 8. Acknowledgments The authors thank all members of WIDE Project for their active discussion, implementation, and evaluation. Especially, we thank to Atsushi Onoe for the revision of this solution, Hirochika Asai for the contribution of the proto type implementation of the special authoritative DNS, and Hirotaka Nakajima for the contribution of the Google chrome plug-in. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. Nakamura, et al. Expires July 16, 2014 [Page 11] Internet-Draft IPv4addr in URL January 2014 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011. [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013. [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013. [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013. [RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, November 2013. 9.2. Informative References [as112-servers] AS112 Project, "AS112 Project", October 2009, . Appendix A. A Test Server of the special TLD We run a prototype implementation of the special-use DNS server in the WIDE backbone (AS 2500). We use ``.v4.wide.ad.jp'' as ``.TLD''. Appendix B. Sample extension for Google Chrome We developed a sample plug-in code for Google Chrome ``IPv4 Address Literal Appender'' that automatically converts in URL to .TLD. The .TLD can be customized in the option. The ``IPv4 Address Literal Appender'' is freely Nakamura, et al. Expires July 16, 2014 [Page 12] Internet-Draft IPv4addr in URL January 2014 available in Google Chrome Web Store. var wr = chrome.webRequest; var v4Suffix = ".TLD"; var ipAddrRegex = /^(\d|[01]?\d\d|2[0-4]\d|25[0-5])\.(\d|[01]?\d\d|2[0- 4]\d|25[0-5])\.(\d|[01]?\d\d|2[0-4]\d|25[0-5])\.(\d|[01]?\d\d|2[0-4]\d|2 5[0-5])$/; function onBeforeRequest(details) { var tmpuri = new URI(details.url); var tmphost = tmpuri.host(); var finalUri = ''; tmphost.replace(ipAddrRegex,function(str, p1, p2, p3, p4, offset, s){ finalUri = tmpuri.host(p1+"."+p2+"."+p3+"."+p4+v4Suffix).toString(); }); if('' != finalUri) { console.log(finalUri); return {redirectUrl: finalUri}; } }; wr.onBeforeRequest.addListener(onBeforeRequest, {urls: ["https://*/*", "http://*/*", "ftp://*/*"]}, ["blocking"]); Authors' Addresses Osamu Nakamura Keio Univ./WIDE Project 5322 Endo Fujisawa, Kanagawa 252-0882 JP Phone: +81 466 49 1100 Email: osamu@wide.ad.jp Hiroaki Hazeyama NAIST / WIDE Project 8916-5 Takayama Ikoma, Nara 630-0192 JP Phone: +81 743 72 5111 Email: hiroa-ha@is.naist.jp Nakamura, et al. Expires July 16, 2014 [Page 13] Internet-Draft IPv4addr in URL January 2014 Yukito Ueno Keio Univ./WIDE Project 5322 Endo Fujisawa, Kanagawa 252-0882 JP Phone: +81 466 49 1100 Email: eden@sfc.wide.ad.jp Akira Kato Keio Univ. / WIDE Project Graduate School of Media Design, 4-1-1 Hiyoshi Kohoku, Yokohama 223-8526 JP Phone: +81 45 564 2490 Email: kato@wide.ad.jp Nakamura, et al. Expires July 16, 2014 [Page 14]