[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/