One document matched: draft-yourtchenko-ipv6-disable-ipv4-proxyarp-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3927 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml">
<!ENTITY rfc6555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6555.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="std" docName="draft-yourtchenko-ipv6-disable-ipv4-proxyarp-00"
     ipr="trust200902">
  <front>
    <title abbrev="Disable Proxy ARP on IPv4 Link-local With IPv6">
    Disable "Proxy ARP for Everything" on IPv4 link-local in the presence of IPv6 global address</title>

    <author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
      <organization abbrev="cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>6a de Kleetlaan</street>

          <city>Diegem</city>

          <code>1831</code>

          <country>BE</country>
        </postal>

        <phone>+32 2 704 5494</phone>

        <email>ayourtch@cisco.com</email>
      </address>
    </author>
    <author fullname="Owen DeLong" initials="O." surname="DeLong">

      <address>
        <postal>
          <street>3251 Firth Way</street>

          <city>San Jose</city>

          <code>CA 95121</code>

          <country>US</country>
        </postal>

        <phone>+32 2 704 5494</phone>

        <email>owen@delong.com</email>
      </address>
    </author>

    <date year="2013" />

    <workgroup></workgroup>

    <abstract>
      <t>rfc3927 defines the behavior "Proxy ARP for Everything" in case 
      the only address present on the host is IPv4 link-local.
      However, it does not specify anything about the presence or absence
      of IPv6 global addressing. This results in the hosts assuming it has 
      both IPv4 and IPv6 connectivity in the scenario where the host itself
      is dualstack-enabled, but the network supplies only IPv6 configuration
      information.  Some implementations in this case may decide to use IPv4,
      which results in long connection delays. 
      This document proposes to avoid the "Proxy ARP for Everything" behavior
      if the host has been assigned an IPv6 address.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Section 2.6.2 of <xref target="RFC3927">Dynamic Configuration of 
      IPv4 Link-Local Addresses</xref> says: "In the case 
      of a device with a single interface and only a Link-Local IPv4 
      address, this requirement can be paraphrased as "ARP for everything"."
      </t>
      <t>In the case of dualstack-enabled host, which is only supplied
      the IPv6 configuration from the network, this behavior still
      causes the application layers to believe that they have both
      IPv4 and IPv6 connectivity.
      </t>
      <t>This results in undesirable behavior in two cases: applications
      that are IPv4-only, and applications that are assuming that
      IPv4 is always available (i.e. those incorrectly implementing 
      <xref target="RFC6555">RFC 6555</xref> and always using only IPv4 as 
      the "fallback" connection, possibly even preferring it over IPv6.
      </t>
      <t>Especially problematic are the cases where the OS stack will
      return the list of addresses in the getaddrinfo() call sorted with
      IPv4 in the beginning, and the application would assume that the
      getaddrinfo() always returns IPv6 first. While one can argue that 
      the applications implementing "happy eyeballs" algorithms should
      not depend on the sort order of the entries, this behavior would break
      a lot of "legacy" applications that sequentially try the addresses
      returned by getaddrinfo().
      </t>
      <t>The "ARP for everything" rule causes an interface route to 0.0.0.0/0
      to be installed by the hosts, and IPv4 connection attempt will then
      take a very long time to time out, without any recourse to intervene 
      from the network side - short of either replying on each ARP request 
      and then spoofing the rejection of the connection by the remote host,
      or assigning bogus IPv4 addresses, with the default gateway rejecting
      all of the IPv4 traffic with ICMP Unreachable messages.
      </t>
    </section>

    <section title="Terminology">
      <t>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 <xref
      target="RFC2119">RFC2119</xref>.</t>

    </section>

    <section title="Description">
      <t>This proposal suggests to change the wording of the Section 2.6.2
      of the <xref target="RFC3927">Dynamic Configuration of
      IPv4 Link-Local Addresses</xref> to include the clarification:
      "If the host has any interface with a global unicast IPv6 address assigned
      and any IPv6 route to any non-connected network (including default), then
      the host MUST immediately return an error rather than transmit any packet with a
      link-local IPv4 source address unless the destination is also an IPv4
      link-local address."
      </t>
    </section>

    <section title="Security Considerations">

      <t>The proposed behavior adjustment does create a potential for a DoS if 
      the host uses IPv4 link-local only addressing, and the attacker forces IPv6
      configuration by e.g. sending a rogue RA. The authors believe this scenario 
      is a comparatively much more infrequent than the IPv6-only scenario - especially
      as the transition to IPv6 progresses. During the transition period the network 
      administrators will have to secure both protocols, regardless of whether 
      the addressing information is supplied by the network or not.</t>
    </section>

    <section title="Acknowledgements">
      <t>This document was born after a discussion at gogoNET LIVE! 3 conference held November 12 - 14, 2012 at San Jose State University </t>
    </section>

    <section title="IANA Considerations">
      <t>None.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;

      &rfc6555;
    </references>

    <references title="Informative References">
      &rfc3927;




    </references>

    <section title="Change History">
      <t>[Note to RFC Editor: Please remove this section prior to
      publication.]</t>
<!--
      <section title="Changes from -00 to -01">
        <t><list style="symbols">
            <t>Some change here</t>
          </list></t>
      </section>
-->
    </section>
  </back>
</rfc>