Neighbor Cache Entries on First-Hop Routers: Operational Considerations
draft-ietf-v6ops-nd-cache-init-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, v6ops@ietf.org, rfc-editor@rfc-editor.org, jordi.palet@theipv6company.com, draft-ietf-v6ops-nd-cache-init@ietf.org, v6ops-chairs@ietf.org, warren@kumari.net, Jordi Palet Martinez <jordi.palet@theipv6company.com>
Subject: Document Action: 'Neighbor Cache Entries on First-Hop Routers: Operational Considerations' to Informational RFC (draft-ietf-v6ops-nd-cache-init-04.txt)

The IESG has approved the following document:
- 'Neighbor Cache Entries on First-Hop Routers: Operational
   Considerations'
  (draft-ietf-v6ops-nd-cache-init-04.txt) as Informational RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Warren Kumari and Robert Wilton.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/

Ballot Text

Technical Summary

   Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
   link-layer addresses of neighboring nodes as well as to discover and
   maintain reachability information.  This document discusses how the
   neighbor discovery state machine on a first-hop router is causing
   user-visible connectivity issues when a new (not being seen on the
   network before) IPv6 address is being used.

Working Group Summary

  There were no issues during the WG process;  consensus was clear.

Document Quality

     The document reports existing and know issues and several vendors have workarounds. It is easy to read, clear, and states a real issue.
Personnel

   Jordi Palet Martinez is DS (Document Shepherd)
   Warren Kumari is RAD (Responsible Area Director -- and, yes, I *do* still giggle every-time I write that...)

RFC Editor Note