One document matched: draft-wing-behave-http-ip-address-literals-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.wing-behave-learn-prefix SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-behave-learn-prefix.xml">
<!ENTITY I-D.ietf-behave-v6v4-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-v6v4-framework.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="info" docName="draft-wing-behave-http-ip-address-literals-00"
     ipr="trust200902">
  <front>
    <title abbrev="Coping with HTTP IP Address Literals">Coping with IP
    Address Literals in HTTP URIs with IPv6/IPv4 Translators</title>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <date year="2009" />

    <workgroup>BEHAVE Working Group</workgroup>

    <abstract>
      <t>A small percentage of HTTP URIs contain an IPv4 address literal as
      the hostname which is not accessible to IPv6-only HTTP clients using an
      IPv6/IPv4 translator and DNS64. This document proposes a workaround for
      this problem using an HTTP proxy to handle that traffic.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Two of the translation scenarios involve IPv6-only hosts accessing
      IPv4-only hosts (Scenario 1, "an IPv6 network to the IPv4 Internet" and
      Scenario 5, "an IPv6 network to an IPv4 network" <xref
      target="I-D.ietf-behave-v6v4-framework"></xref>). For this to work, the
      IPv6-only host sends a DNS AAAA query and receives a synthesized AAAA
      response. While it is common practice to use domain names in many
      application protocols, most applications do not require using domain
      names. IPv4 address literals occur in HTTP URI hostname fields (e.g.,
      http://192.0.2.1) on the Internet (see <xref target="internet"></xref>)
      and on some corporate networks. Such occurrences do not cause problems
      today, because both IPv4 hosts and dual-stack hosts can connect to those
      addresses just fine. However, those IPv4 address literals are
      inaccessible to IPv6-only clients using an IPv6/IPv4 translator and
      DNS64.</t>

      <t>This document proposes a workaround to this problem when an HTTP
      browser, running on an IPv6-only host, encounters an HTTP URI containing
      an IPv4 address literal (instead of containing a domain name).</t>
    </section>

    <section title="Proposed Workaround">
      <t>Nearly all modern web browsers can be configured with a <xref
      target="PAC">Proxy auto-config (PAC)</xref> file. A PAC allows a browser
      to have an HTTP proxy handle traffic to a host with an IPv4 address
      literal, while allowing direct access (through the IPv6/IPv4 translator)
      for the majority of traffic, as shown in <xref
      target="example-pac"></xref>. With this workaround, an IPv6-only HTTP
      client can access HTTP URIs that contain IPv4 address literals. The HTTP
      proxy needs to be able to send packets to the IPv4 Internet, and can be
      located parallel to the translator (as shown in <xref
      target="network_diagram"></xref>) or on either side of the IPv6/IPv4
      translator, including in the host itself. To be located on the IPv6-only
      side of the translator, the proxy needs to understand how to formulate
      an IPv6 address from an IPv4 address <xref
      target="I-D.wing-behave-learn-prefix"></xref>.</t>

      <figure anchor="network_diagram"
              title="Network Diagram showing HTTP proxy and Translator">
        <preamble></preamble>

        <artwork align="center"><![CDATA[                            |
<----------IPv6------------>|<---------IPv4----------->
                            |
+-----------+ proxied  +----------+
|           +--------->|HTTP Proxy+-
|IPv6-only  |          +----------+ \     ,-----------.
|    web    |               |        >-->(IPv4 Internet)
|  browser  | direct   +----------+ /     `-----------'
|           +--------->|IPv6/IPv4 +-
+-----------+          |Translator|
                       +----------+
                            |]]></artwork>

        <postamble></postamble>
      </figure>

      <t></t>

      <t>The <xref target="I-D.ietf-wrec-wpad">Web Proxy Autodiscovery
      Protocol (WPAD)</xref> is useful to autoconfigure web browsers for
      non-technical users or for a large community of users (e.g., inside of
      an enterprise).</t>
    </section>

    <section title="Disadvantages of Workaround">
      <t>While the workaround is helpful, the PAC and WPAD workarounds have
      several disadvantages: <list style="symbols">
          <t>operating an HTTP proxy, even for the relatively small amount of
          the HTTP traffic that contains IPv4 address literals, is generally
          considered more resource-intensive than operating an IPv6/IPv4
          translator because the HTTP proxy has to terminate a TCP connection
          and originate a separate TCP connection and shuffle data between
          them. For this reason alone, the PAC workaround described in this
          document is inferior to the web browser handling IPv4 native
          addresses itself <xref
          target="I-D.wing-behave-learn-prefix"></xref>.</t>

          <t>The workaround only provides assistance to IPv4 address literals
          in hostnames. It does not help IPv4 address literals that appear,
          for various reasons, in the URL path or query string (e.g.,
          http://www.example.com?host=1.2.3.4>, Java, or Javascript.</t>

          <t>Interworking an existing PAC file with the new functionality
          described in this document may be difficult.</t>

          <t>WPAD increases the attack surface.</t>

          <t>Both PAC and WPAD are a de facto standards.</t>
        </list></t>
    </section>

    <section anchor="security_considerations" title="Security Considerations">
      <t>WPAD increases the attack surface, because of how WPAD uses
      unauthenticated DHCP or DNS to find the PAC file, searches domain names
      for PAC files, and because the PAC file is retrieved via unauthenticated
      HTTP.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document requires no IANA actions.</t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks to Stig Venaas and Andrew Yourtchenko for their review
      comments. Thanks to Shin Miyakawa for suggesting this same technique is
      useful for IPv4-only hosts to connect to IPv6 address literals.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <reference anchor="PAC"
                 target="http://en.wikipedia.org/wiki/Proxy_auto-config">
        <front>
          <title>Proxy auto-config</title>

          <author fullname="Wikipedia" surname="Wikipedia">
            <organization></organization>
          </author>

          <date month="September" year="2009" />
        </front>
      </reference>

      <reference anchor="Alexa" target="http://www.alexa.com/topsites">
        <front>
          <title>Top 1,000,000 Global Sites</title>

          <author fullname="Alexa" surname="Alexa">
            <organization></organization>
          </author>

          <date month="September" year="2009" />
        </front>
      </reference>

      <reference anchor="I-D.ietf-wrec-wpad">
        <front>
          <title>Web Proxy Auto-Discovery Protocol</title>

          <author fullname="Paul Gauthier" initials="P" surname="Gauthier">
            <organization></organization>
          </author>

          <author fullname="Josh Cohen" initials="J" surname="Cohen">
            <organization></organization>
          </author>

          <author fullname="Martin Dunsmuir" initials="M" surname="Dunsmuir">
            <organization></organization>
          </author>

          <author fullname="Charles Perkins" initials="C" surname="Perkins">
            <organization></organization>
          </author>

          <date day="1" month="July" year="1999" />
        </front>

        <seriesInfo name="Internet-Draft" value="draft-ietf-wrec-wpad-01" />

        <format target="http://tools.ietf.org/html/draft-ietf-wrec-wpad-01"
                type="TXT" />
      </reference>

      &I-D.wing-behave-learn-prefix;

      &I-D.ietf-behave-v6v4-framework;
    </references>

    <section anchor="example-pac" title="Example PAC files">
      <figure anchor="figure_for_ipv6_only_client">
        <preamble>A simple example of a PAC file that causes HTTP or HTTPS
        URIs containing IPv4 address literals to be proxied to
        v6v4-proxy.example.net on port 8080. This would be useful for an
        IPv6-only client that needs to access content with IPv4 address
        literals in the HTTP URI:</preamble>

        <artwork><![CDATA[
  function FindProxyForURL(url, host) {
  var regexpr = /^https?:\/\/\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
  if (regexpr.test(url))
      return "PROXY v6v4-proxy.example.net:8080";
  else
      return "DIRECT";
  }]]></artwork>

        <postamble></postamble>
      </figure>

      <figure anchor="figure_for_ipv4_only_client"
              title="Example PAC for IPv4-only client">
        <preamble>A simple example of a PAC file that causes HTTP or HTTPS
        URIs containing IPv6 address literals to be proxied to
        v6v4-proxy.example.net on port 8080. This would be useful for an
        IPv4-only client that needs to access content with IPv6 address
        literals in the HTTP URI.</preamble>

        <artwork><![CDATA[
  function FindProxyForURL(url, host) {
  var regexpr = /^https?:\/\/\[[0-9a-fA-F:\.\]*\]/
  if (regexpr.test(url))
      return "PROXY v4v6-proxy.example.net:8080";
  else
      return "DIRECT";
  }]]></artwork>

        <postamble></postamble>
      </figure>
    </section>

    <section anchor="internet"
             title="HTTP IPv4 Address Literals on the Internet">
      <t>There has been some doubt that HTTP URIs on the Internet contain
      hostnames with IPv4 address literals. This section provides some scripts
      which demonstrate the relatively low -- but prevalent -- existence of
      IPv4 address literals.</t>

      <figure>
        <preamble>An examination of Alexa's top 1 million domains <xref
        target="Alexa"></xref> at the end of August, 2009, showed 2.38% of the
        HTML in their home pages contained IPv4 address literals. This can be
        verified with:</preamble>

        <artwork><![CDATA[
  wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip
  unzip top-1m.csv.zip
  cat top-1m.csv | 
    cut -d "," -f 2 | 
    xargs -I % -n 1 -t wget -nv % -O - --user-agent="Mozilla/5.0" | 
    grep -E "https?://[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"]]></artwork>

        <postamble></postamble>
      </figure>

      <figure>
        <preamble>Of the top 1 million websites at the end of August, 2009,
        3455 (0.35%) of them are IPv4 address literals (e.g.,
        http://192.0.2.1). This can be verified with:</preamble>

        <artwork><![CDATA[  
  wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip
  unzip top-1m.csv.zip
  grep -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" 
    top-1m.csv | wc]]></artwork>

        <postamble></postamble>
      </figure>
    </section>
  </back>
</rfc>