Network Working Group A. Yourtchenko Internet-Draft cisco Intended status: Standards Track O. DeLong Expires: November 11, 2013 May 10, 2013 Disable "Proxy ARP for Everything" on IPv4 link-local in the presence of IPv6 global address draft-yourtchenko-ipv6-disable-ipv4-proxyarp-00 Abstract 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. 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 November 11, 2013. Copyright Notice Copyright (c) 2013 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 Yourtchenko & DeLong Expires November 11, 2013 [Page 1] Internet-DrafDisable Proxy ARP on IPv4 Link-local With IPv6 May 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 4 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction Section 2.6.2 of Dynamic Configuration of IPv4 Link-Local Addresses [RFC3927] 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"." 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. 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 RFC 6555 [RFC6555] and always using only IPv4 as the "fallback" connection, possibly even preferring it over IPv6. 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(). Yourtchenko & DeLong Expires November 11, 2013 [Page 2] Internet-DrafDisable Proxy ARP on IPv4 Link-local With IPv6 May 2013 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. 2. Terminology 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 [RFC2119]. 3. Description This proposal suggests to change the wording of the Section 2.6.2 of the Dynamic Configuration of IPv4 Link-Local Addresses [RFC3927] 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." 4. Security Considerations 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. 5. Acknowledgements This document was born after a discussion at gogoNET LIVE! 3 conference held November 12 - 14, 2012 at San Jose State University 6. IANA Considerations None. 7. References Yourtchenko & DeLong Expires November 11, 2013 [Page 3] Internet-DrafDisable Proxy ARP on IPv4 Link-local With IPv6 May 2013 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. 7.2. Informative References [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. Appendix A. Change History [Note to RFC Editor: Please remove this section prior to publication.] Authors' Addresses Andrew Yourtchenko Cisco Systems, Inc. 6a de Kleetlaan Diegem 1831 BE Phone: +32 2 704 5494 Email: ayourtch@cisco.com Owen DeLong 3251 Firth Way San Jose CA 95121 US Phone: +32 2 704 5494 Email: owen@delong.com Yourtchenko & DeLong Expires November 11, 2013 [Page 4]