6MAN Working Group Kiran Kella Internet-Draft Broadcom, Inc. Updates: RFC 4861 (if approved) December 25, 2014 Intended status: Standards Track Expires: June 10, 2015 Faster cleanup of invalid NCE draft-kella-6man-cache-invalid-purge-00 Abstract When an IPv6 address is moved or removed or when it becomes invalid on an interface of an IPv6 node, the old neighbor cache entry for this address on the neighboring nodes sharing the interface link continues to be used for data forwarding till the STALE entry time out happens or till the neighbor unreachability detection algorithm runs in order to rediscover the correct link layer address or purge the incorrect neighbor cache entry. This document specifies a mechanism for the faster removal of invalid neighbor cache entries on the neighboring nodes. This document updates RFC 4861. 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 June 10, 2015. Copyright Notice Copyright (c) 2012 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. Kiran Kella, et al. Expires June 10, 2015 [Page 2] Internet-Draft Faster cleanup of invalid NCE December 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions used in this document . . . . . . . . . . . . 2 2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Retransmission of unsolicited neighbor advertisement . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction When an IPv6 address is removed on a neighboring host or router node, the neighbor cache entry corresponding to that address continues to reside in the neighbor cache of the peer IPv6 nodes. As per [RFC4861], currently there is no notification to the peer nodes to flush those invalid neighbor cache entries from the cache. As a result, the invalid entry wastes the table space and possibly avoids a new valid entry from joining the network when the table is in full condition. Traffic destined to that invalid cache entry continues to get forwarded into a possible black hole for some time. In case of IPv6 address movement too, the traffic continues to get forwarded to the wrong node for some time. These conditions continue to exist till the STALE entry timeout (1200 seconds) happens or till the NUD runs for that address on the forwarding nodes in order to discover the new link layer address or purge the invalid entry when the NUD fails. To handle this situation some implementations choose to run NUD periodically on each neighbor to detect the neighbor unavailability at the earliest and update the table accordingly. But this approach increases the load on the CPU and is not scalable. The scenarios above do not include the case where an interface link goes down. In that case the NUD or STALE timeout has to recover the situation on the nodes as before. This document updates RFC 4861 to efficiently handle the above scenarios. 1.1. Conventions used in this document 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]. Kiran Kella, et al. Expires June 10, 2015 [Page 3] Internet-Draft Faster cleanup of invalid NCE December 2014 2. Proposed solution We need a way to immediately delete the invalid neighbor cache entry from the cache of all the neighboring routers or hosts whenever the IPv6 address is administratively unconfigured. The F-bit in the Reserved field space of the Neighbor Advertisment message is used to notify the neighboring nodes about the unavailabi- lity of the IPv6 address on the sender IPv6 node's link. Neighbor Advertisement Message Format in section 4.4 of RFC 4861: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O|F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- ICMP Fields: F Flush flag. When set, the F-bit indicates that the advertisement is sent to notify other neighboring nodes that have learnt the Target Address mentioned in this advertisement in their neighbor table to flush the corresponding neighbor entry. On receiving the advertisement with F-flag set, the implementations SHOULD flush the neighbor entry from their neighbor cache if it exists. Implementations compliant to RFC 4861 ignore this F-bit as the unused fields in the Reserved field MUST be initialized to zero by the sender and MUST be ignored by the receiver. IPv6 nodes complying to this specification SHOULD send unsolicited multicast neighbor advertisement with F-bit set for the address that is no longer valid on the interface. Nodes processing the received unsolicited neighbor advertisement with F-bit set SHOULD delete the matching neighbor cache entry if it exists in the cache. Kiran Kella, et al. Expires June 10, 2015 [Page 4] Internet-Draft Faster cleanup of invalid NCE December 2014 2.1. Retransmission of unsolicited neighbor advertisement Unsolicited neighbor advertisements are unreliable mechanism to propagate information unlike solicited neighbor advertisments. To increase the chances of the neighboring IPv6 node to flush the invalid entry when the network is under stress, the sending node MAY send multiple unsolicited neighbor advertisements at reasonably time spaced intervals. 3. IANA Considerations This document does not require any IANA actions. 4. Security Considerations This document does not present any additional security issues beyond those discussed in [RFC4861]. 5. References 5.1. Normative References [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Author's Address Kiran Kella Broadcom India Pvt. Ltd, Building 9, Raheja Mind Space, Hitec City, Hyderabad - 500082, India Phone: +91 789 300 0334 Email: kkiran@broadcom.com Kiran Kella, et al. Expires June 10, 2015 [Page 6]