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 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. Terminology
• 3. Description
• 4. Security Considerations
• 5. Acknowledgements
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Change History
• Authors' Addresses

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().

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

7.1. Normative References

7.2. Informative References

Appendix A. Change History

[Note to RFC Editor: Please remove this section prior to publication.]

Authors' Addresses