[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

IPv6 Operations Working Group (v6ops)                        O. Nakamura
Internet-Draft                                   Keio Univ./WIDE Project
Intended status: Experimental                                H. Hazeyama
Expires: April 30, 2015                             NAIST / WIDE Project
                                                                 Y. Ueno
                                                 Keio Univ./WIDE Project
                                                                 A. Kato
                                               Keio Univ. / WIDE Project
                                                        October 27, 2014


  A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64
                              environments
                draft-osamu-v6ops-ipv4-literal-in-url-02

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 proposes a special
   purpose TLD so that the IPv4 address literal is accessible from such
   a DNS64/NAT64 environments.

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 April 30, 2015.

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



Nakamura, et al.         Expires April 30, 2015                 [Page 1]


Internet-Draft           TLD for IPv4addr in URL            October 2014


   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.

   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 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 [RFC4074].
   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
   [RFC6586] and others.

   The reason why the destination specified by above notation cannot be



Nakamura, et al.         Expires April 30, 2015                 [Page 2]


Internet-Draft           TLD for IPv4addr in URL            October 2014


   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 [RFC2119].


2.  Scope of this memo

   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
   [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-purpose TLD for IPv4 Address Literal

   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.



Nakamura, et al.         Expires April 30, 2015                 [Page 3]


Internet-Draft           TLD for IPv4addr in URL            October 2014


   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.

3.1.  .TLD Authoritative DNS server behavior

   The authoritative DNS server of .TLD SHOULD be operated only for a
   special purpose.
   1.  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 ''.
   2.  Otherwise, .TLD authoritative server MUST return NXDOMAIN.

3.2.  DNS64 behaviors

   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 [RFC6147].

   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.

3.3.  Client behaviors

3.3.1.  Case 1: manual type-writing

   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.





Nakamura, et al.         Expires April 30, 2015                 [Page 4]


Internet-Draft           TLD for IPv4addr in URL            October 2014


3.3.2.  Case 2: device or application

   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 [RFC7050], or MAY combine .TLD method and [RFC7050]
   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.

3.4.  DNS query flow

   Figure 1 shows a DNS query flow on the .TLD.

   1.  An application on a client creates <ipv4-address-literal>.TLD.
   2.  The application inputs the query of AAAA or ANY about <ipv4-
       address-literal>.TLD. to its local resolver.
   3.  The local resolver forwards the query to a recursive resolver
       that would be a DNS64 server in DNS64/NAT64 environment.
   4.  The recursive resolver sends a recursive query of <ipv4-address-
       literal>.TLD.
   5.  .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.
   6.  When the recursive resolver has DNS64 function, it creates the
       AAAA record according to [RFC6147] 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.
   7.  The application on the client gets the appropriate IP address
       (IPv4 address or Pref64::/n address), then creates an appropriate
       socket.





Nakamura, et al.         Expires April 30, 2015                 [Page 5]


Internet-Draft           TLD for IPv4addr in URL            October 2014


                                                          +----------+
                                                          | auth DNS |
                                                          | for PTR  |
                                                          |  Record  |
                                                          +----------+
                                                               ||
                                                               (5)
                                                               ||
    +-------+        +--------+        +---------+        +----------+
    |  app  |--(2)-->| local  |--(3)-->|Recursive|--(4)-->|auth .TLD |
    |(1)(7) |<-(6)-- |resolver|<-(6)---|Resolver |<-(5)---|DNS server|
    +-------+        |        |        |         |        +----------+
                     +--------+        | (DNS64) |
                                       +---------+




                          DNS Query Flow on .TLD

                                 Figure 1

   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.

3.5.  Use cases

3.5.1.  Use case 1: manual type-writing

   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 [RFC7050] or
   [RFC7051].  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 [RFC6384].

3.5.2.  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 <ipv4-address-literal> on the hostname



Nakamura, et al.         Expires April 30, 2015                 [Page 6]


Internet-Draft           TLD for IPv4addr in URL            October 2014


   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 Appendix B

3.6.  Recommendation

   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.


4.  Considerations

4.1.  Attached the special-purpose TLD to a regular FQDN

   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.

4.2.  An embedded IP address literal in the content part of URL

   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.

4.3.  Prevention the leak of the special-purpose TLD

   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 [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.




Nakamura, et al.         Expires April 30, 2015                 [Page 7]


Internet-Draft           TLD for IPv4addr in URL            October 2014


4.4.  Possibility 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
   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.

4.5.  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.

4.6.  TLD alternatives

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

4.6.1.  .v4.arpa

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

4.6.2.  .host

   ``.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 Section 4.6.3) delegations to this
   purpose.




Nakamura, et al.         Expires April 30, 2015                 [Page 8]


Internet-Draft           TLD for IPv4addr in URL            October 2014


4.6.3.  TLD less delegation

   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
   Section 5.

4.7.  Usages of IPv6 address literal

   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.

4.8.  RFC7050 ipv4only.arpa

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

4.8.1.  Multiple NAT64 prefixes for load balancing

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


















Nakamura, et al.         Expires April 30, 2015                 [Page 9]


Internet-Draft           TLD for IPv4addr in URL            October 2014


                +-------------+    +-------+     +-------------------+
                |             +====| NAT64 |=====+    IPv4 ISP A     |
    +------+    |  IPv6 Only  |    +-------+     +-------------------+
    |client|====|  Segment    |
    +------+    |             |    +-------+     +-------------------+
                |             +====| NAT64 |=====+    IPv4 ISP B     |
                +-------------+    +-------+     +-------------------+
                       |
                   +---+---+
                   | DNS64 |
                   +-------+

      Situation A : multiple NAT64 prefixes for optimizing routes on
                                multihoming

                                 Figure 2

4.8.2.  Multiple NAT64 prefixes for external / internal IPv4 only
        networks

   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.  Figure 3 draws this
   situation.  In this situation, the NAT64 prefix estimated by
   [RFC7050] method could not be reached to the internal IPv4 only
   network.

                                 +-------+
                                 | DNS64 |
                                 +---+---+
                                     |
    +-------------+              +--------+             +----------+
    |             |   +-------+  |  IPv6  |  +-------+  |          |
    |   internal  +===| NAT64 |==+  Only  +==| NAT64 |==+ IPv4     |
    |   network   |   +-------+  |  Seg.  |  +-------+  | Internet |
    +-------------+              +--------+             +----------+
                                     |
                                 +---+----+
                                 | client |
                                 +--------+

       Situation B : multiple NAT64 prefixes for internal / external

                                 Figure 3







Nakamura, et al.         Expires April 30, 2015                [Page 10]


Internet-Draft           TLD for IPv4addr in URL            October 2014


4.8.3.  Difficulty of conversion from octet expression to hex expression
        by human type-writing

   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.


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.3.
   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.5.1 or
          automatically by browser plugins described in Section 3.5.2.
          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.


6.  Security Considerations

   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,



Nakamura, et al.         Expires April 30, 2015                [Page 11]


Internet-Draft           TLD for IPv4addr in URL            October 2014


   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


7.  IANA Considerations

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


8.  Acknowledgments

   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.


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.

   [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.

   [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)



Nakamura, et al.         Expires April 30, 2015                [Page 12]


Internet-Draft           TLD for IPv4addr in URL            October 2014


              for IPv6-to-IPv4 Translation", RFC 6384, October 2011.

   [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.

   [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,
              <https://www.as112.net/>.


Appendix A.  A Test Server of the special TLD

   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.


Appendix B.  Sample extension for Google Chrome

   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.














Nakamura, et al.         Expires April 30, 2015                [Page 13]


Internet-Draft           TLD for IPv4addr in URL            October 2014


   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|25[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 April 30, 2015                [Page 14]


Internet-Draft           TLD for IPv4addr in URL            October 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 April 30, 2015                [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/