]> Keio Univ./WIDE Project

5322 Endo Fujisawa Kanagawa 252-0882 JP +81 466 49 1100 osamu@wide.ad.jp

NAIST / WIDE Project

8916-5 Takayama Ikoma Nara 630-0192 JP +81 743 72 5111 hiroa-ha@is.naist.jp

Keio Univ./WIDE Project

5322 Endo Fujisawa Kanagawa 252-0882 JP +81 466 49 1100 eden@sfc.wide.ad.jp

Keio Univ. / WIDE Project

Graduate School of Media Design, 4-1-1 Hiyoshi Kohoku Yokohama 223-8526 JP +81 45 564 2490 kato@wide.ad.jp

Operation and Management IPv6 Operations Working Group (v6ops) IPv6 IPv4 URL DNS64 Stateful NAT64 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 proposes a special purpose TLD so that the IPv4 address literal is accessible from such a DNS64/NAT64 environments.

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 and a stateful NAT64 translator . The DNS64 server responds with a AAAA record of an IPv4 embedded IPv6 address with a certain IPv6 prefix assigned to the NAT64 translator, for example, the well known NAT64 prefix (64:ff9b::) or a global IPv6 prefix. The IPv6-only host sends an IPv6 packet, which is translated by the NAT64 box to an IPv4 packet. In this memo, an IPv4 embedded IPv6 address with a NAT64 prefix is described as ``Pref64::/n address''. 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. But it does not work well when the DNS response packet resulted NXDOMAIN or SERVFAIL to the AAAA query, partly described in . Resolutions of this case are 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 and others. The reason why the destination specified by above notation cannot be accessible is that no DNS lookup is performed, and no DNS64 service is able to tell a Pref64::/n address to the host. To perform DNS64/NAT64 translation against such an IPv4 address literal notation, some mechanism will be required. This memo proposes a special-purpose TLD and defines behaviors of resolvers and of the authoritative servers to treat the special-purpose TLD. This memo also considers implementation strategy of .TLD and side effects of .TLD usages to the current communications on the Internet. The special-purpose TLD is denoted as .TLD which will be replaced with an actual TLD allocated by IANA. The concept of .TLD is simple: All IPv4 address literal notations are rewritten to ``<ipv4-address-literal>.TLD'' on a host. As ``<ipv4-address-literal>.TLD'' is seemed to be a regular FQDN, ``<ipv4-address-literal>.TLD'' lets DNS64 servers resolve IPv4 address literal as a regular FQDN and translate the A record of ``<ipv4-address-literal>.TLD'' to a corresponding Pref64::/n address on each leaf network. For example, 192.0.2.10.TLD in DNS64/NAT64 environment would be translated to a Pref64::c000:020a. In an IPv4 environment, 192.0.2.10.TLD would be resolved just as an A record about 192.0.2.10. 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 .

This memo focuses only on smooth migration to an IPv6-only environment with the DNS64/NAT64 solution. Therefore, this memo focuses on only ``IPv4 address literal'' problem mentioned in . 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.

When the part of IPv4 address literal is written to form a pseudo FQDN and the pseudo FQDN is resolved as an IPv4 address, a DNS64 server can return a AAAA record with the specified IPv4 address that is mapped to an appropriate NAT64 prefix. Once a AAAA record is obtained, the IPv6-only host can send IPv6 packets to the destination. IPv6 packets will be translated back via NAT64 translator in exactly the same as a regular IPv4-only destination.

The authoritative DNS server of .TLD SHOULD be operated only for a special purpose. If a DNS query asks ``<ipv4-address-literal>.TLD '', .TLD authoritative server MUST return ``<ipv4-address-literal>'' as the A record of ``<ipv4-address-literal>.TLD ''. Otherwise, .TLD authoritative server MUST return NXDOMAIN.

When a DNS64 receives a query of <ipv4-address-literal>.TLD, it SHOULD issue a DNS query to one of the .TLD authoritative servers. The response from .TLD authoritative server will be either an A record of the issued <ipv4-address-literal> or NXDOMAIN. If the response contains an A record, the DNS64 MUST translate the IPv4 address in the A record to the AAAA record by Pref64::/n address according to . Taking into account of scalability, the DNS64 WOULD cache the AAAA record of <ipv4-address-literal>.TLD in a certain interval. As one of possible ways to get more scalability, the DNS64 CLOUD have the function of .TLD authoritative server.

When a client (human) wants to access an IPv4 only server by IPv4 address literal in a DNS64/NAT64 network, he / she manually attaches .TLD to the IPv4 address of the IPv4 only server. When the network has DNS64/NAT64 function, the AAAA record, that is Pref64::/n address of the issued <ipv4-address-literal> , will be return. The client COULD attach .TLD to the IPv4 address of the IPv4 only server in an IPv4 only network or a dual stack network. When the network situation is IPv4 only or dual stack, the A record of the issued <ipv4-address-literal>.TLD will be returned. If the client uses FQDN or IPv6 address literal, he / she MUST NOT attach .TLD.

A client (device or application), that has a name resolution function, SHOULD attach .TLD when the input value of getaddrinfo is an IPv4 address literal. For example, <ipv4-address-literal> SHOULD be rewritten to <ipv4-address-literal>.TLD. If the input value of getaddrinfo is not IPv4 address literal, the client MUST NOT attach .TLD. Of course, the client CAN take self-synthesizing of mapped address mentioned in , or MAY combine .TLD method and self-synthesizing method. Some access authentication may not allow any external accesses until access authentication procedure is finished, and may use an IPv4 address literal on the redirected authentication web page. Taking into account such corner case, client WOULD check the reachability to the external network initially. NOTE: migrating from IPv4 to IPv6, access authentication SHOULD avoid to use IPv4 address literal and SHOULD use FQDN for dual stack client or IPv6 only client.

shows a DNS query flow on the .TLD. An application on a client creates <ipv4-address-literal>.TLD. The application inputs the query of AAAA or ANY about <ipv4-address-literal>.TLD. to its local resolver. The local resolver forwards the query to a recursive resolver that would be a DNS64 server in DNS64/NAT64 environment. The recursive resolver sends a recursive query of <ipv4-address-literal>.TLD. .TLD authoritative server creates the A record of the issued <ipv4-address-literal>.TLD, and MAY check PTR record of the issued <ipv4-address-literal>. Then, .TLD authoritative server returns the DNS response to the recursive resolver. When the recursive resolver has DNS64 function, it creates the AAAA record according to and replies the AAAA record to the local resolver on the client. If the recursive resolver does not have DNS64 function, the recursive resolver returns the A record responded from .TLD authoritative server. The application on the client gets the appropriate IP address (IPv4 address or Pref64::/n address), then creates an appropriate socket.

| local |--(3)-->|Recursive|--(4)-->|auth .TLD | |(1)(7) |<-(6)-- |resolver|<-(6)---|Resolver |<-(5)---|DNS server| +-------+ | | | | +----------+ +--------+ | (DNS64) | +---------+ ]]> DNS Query Flow on .TLD

This solution would not require the modification of common shared libraries on any Operating Systems. The DNS implementations, SHOULD support .TLD. As the query flow mentioned above, .TLD authoritative server SHOULD be placed. The modification of NAT64 or DHCP are not required in this method.

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 Pref64::/n address through or . Under the proposed mechanism on this memo, you can just type as follow; % ftp 192.0.2.10.TLD The packet would be transferred along with .

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 <ipv4-address-literal> on the hostname part of an URL to <ipv4-address-literal>.TLD. It may be suggested to turn this function on when the host is on IPv6-only network, however, it may not be easy to detect the situation of the network (IPv4 only, dual stack or DNS64/NAT64 environment). A sample of Google Chrome plug-in is attached in

For usability in manual type-writing, the .TLD SHOULD be as short as possible, and SHOULD express the special purpose in the name space. ``.v4'' is recommended as a candidate of .TLD, because of the simplicity and the expression of IPv4.

Conceptually, the special-purpose TLD would be attached to only IPv4 address literals, however, the special-purpose TLD may be attached to a regular FQDN notation like ``foo.bar.com.TLD''. Such misuses SHOULD be avoided.

In some case, <ipv4-address-literal> 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 <ipv4-address-literal> 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.

When .TLD is actually employed in the operation, .TLD may 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 . When one of the AS112 servers received a query with .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 MUST be returned.

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 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 <ipv4-address-literal>.TLD instead of FQDN, the VirtualHost may not work as intended. Therefore, such web site, that uses the Apache VirtualHost concept, SHOULD NOT use <ipv4-address-literal> in URL and SHOULD use appropriate FQDN.

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.

In , we propose .v4 as the TLD, and comparisons with other candidates are discussed as follows.

``v4.arpa'' may be a candidate of .TLD that does not require new TLD, however, it may be confued with ``ipv4only.arpa'', and the length (8 characters) of ``.v4.arpa'' is bit longer than the length (3 characters) of ``.v4'' for type-writing usages.

``.host'' has already been assigned as one of the new gTLDs, and not considered a candidate here unless the authority of .host offers 256 (or 356 -- see discussion in ) delegations to this purpose.

When it is feasible to "delegate" 256 TLDs (from ".0" through ".255") or 366 TLDs (".00", ".000", and others are added) for this particular purpose, it is possible to implement the functionality described in this memo without assigning a particular .TLD. It contributes 256 (or 356) extra TLDs in the Root zone. It is known that DNS queries with such TLDs have been observed, and this delegation may interfere with undocumented usage of such TLDs. If such 256 (or 366) delegations is suitable, bogus such queries to the root servers will be redirected to the DNS server described in .

The special-purpose TLD may be applied to IPv6 address cases in same ways, however, such notation is not required in dual stack / IPv6-only environment, generally.

defines a method to estimate a NAT64 prefix by querying Well-Known IPv4-only Name ``ipv4only.arpa''. does not cover several situations. .TLD method is aimed to solve such situations as follows:

One of situations is multihoming, illustrated in . In this situation, the NAT64 prefix estimated by method may be different from the one that the operator intends.

Situation A : multiple NAT64 prefixes for optimizing routes on multihoming

Another situation is where multiple NAT64 prefixes are operated for accessing the external IPv4 Internet and an internal private IPv4 only network from an internal IPv6 only network. draws this situation. In this situation, the NAT64 prefix estimated by method could not be reached to the internal IPv4 only network.

Situation B : multiple NAT64 prefixes for internal / external

As the initial motivation of this memo, IPv4 address literal is often used for a personal / private server that is not registered in DNS record because of lazy operation, temporal usage, or the intention to hide from DNS query scans. ``ipv4only.arpa'' solution can be available to synthesize the Pref64::/n address for the private server, however, the owner of the private server has to convert the octet expression of the IPv4 address on his/her private server to the hex expression by manual. Usually, conversion from octet expression to hex expression by manual is difficult or tiresome operation.

It is suggested to implement the .TLD rewriting as in the following order: 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 . .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 . 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. Start using .TLD rewriting After, at least the step 2 is completed, the TLD rewriting may be used in manually described in or automatically by browser plugins described in . While further discussions and observation is required, the use of an URL in IPv4 literal embedded might be discouraged. Instead, the use of .TLD notation as a legitimate URL might be encouraged even in the server side.

The recommendation contains security considerations related to DNS. The special purpose DNS servers 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. TBD

This memo calls for ``.v4'' as the special-purpose TLD to the IANA registry.

Authors thank to WIDE Project members for their active discussion, implementations, and evaluations. Especially, we thank to Atsushi ONOE for the revision of this solution, Hirochika ASAI for the contribution of the prototype implementation of the special purpose authoritative DNS, and Hirotaka NAKAJIMA for the contribution of the Google chrome plug-in. We also thank to Yoshiaki KITAGUCHI, Yu-ya KAWAKAMI and others who evaluated our proof of concept special purpose DNS (.v4.wide.ad.jp) and the Google Chrome plugin-in at JANOG34 DNS64/NAT64 experiment networks. Teeme Savolainen, Cameron Byrne, Dan Wing, Erik Nygren gave us various considerations on the actual operation of .TLD.

&RFC2119; &RFC4074; &RFC6146; &RFC6147; &RFC6384; &RFC6586; &RFC6761; &RFC7050; &RFC7051; AS112 Project

We run a prototype implementation of the special-purpose DNS server in the WIDE backbone (AS 2500). We use ``.v4.wide.ad.jp'' as .TLD.

We developed a sample plug-in code for Google Chrome ``IPv4 Address Literal Appender'' that automatically converts <ipv4-address-literal> in URL to <ipv4-address-literal>.TLD. The .TLD can be customized in the option. The ``IPv4 Address Literal Appender'' is freely available in Google Chrome Web Store, and also in github https://github.com/nunnun/nat64-v4-literal-extension.