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 ``<ipv4-address-
   literal>.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, <ipv4-address-
   literal>.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, <ipv4-address-literal> is rewritten to <ipv4-
       address-literal>.TLD.
   2.  The host gets access to <ipv4-address-literal>.TLD instead of
       <ipv4-address-literal>.
   3.  As <ipv4-address-literal>.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 ``<ipv4-address-
       literal>.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 ``<ipv4-address-literal>.TLD '', the
           authoritative .TLD DNS sever simply removes ``.TLD'' part
           from the FQDN and returns ``<ipv4-address-literal>'' as the A
           record.
       2.  To avoid misuses, the authoritative .TLD DNS server MAY check
           whether the PTR record corresponding to <ipv4-address-
           literal> exists or not.  If the PTR record of <ipv4-address-
           literal> 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 ``<ipv4-address-
       literal>.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 <ipv4-
           address-literal> 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 <ipv4-address-literal> 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, <ipv4-address-
           literal> 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 <ipv4-address-literal> as an A record.
   7.  After the name resolution procedure is completed, the host will
       access the <ipv4-address-literal> 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 <ipv4-address-literal> on the hostname
   part of an URL to <ipv4-address-literal>.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, <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.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 <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.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,
              <https://www.as112.net/>.


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



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]