Internet DRAFT - draft-kella-6man-cache-invalid-purge
draft-kella-6man-cache-invalid-purge
6MAN Working Group Kiran Kella
Internet-Draft Broadcom, Inc.
Updates: 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-02.txt
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) 2014 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 1]
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
5.2. Informative 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 2]
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 3]
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
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
5.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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 4]
