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]