Summary

  • Revision 08 of the IETF’s IPv6 Neighbor Discovery YANG model is in Last Call until 16 September 2026. Its writable auto-resolve leaf can sit in front of three different acts: logging, packet discard and host blocking.
  • A completed INTDIR review calls the omission of enhanced-dad/auto-resolve from the draft’s writable-node sensitivity list a plausible attack vector. The open question is not whether automation is useful, but whether a consequential decision leaves evidence and a reliable way back.
  • The standardized tree exposes aggregate counters, not a per-block decision receipt. Implementations may provide more, but operators should demand attribution, separate action outcomes, expiry and unblock semantics before enabling the switch.

Last Call has found the consequential leaf

The IESG opened Last Call on draft-ietf-6man-ipv6-neighbor-discovery-yang-08 on 2 September, with comments due on 16 September. The document is intended for the Proposed Standard track. It fills a real management gap: existing IETF models cover basic IP configuration and router advertisements, while this module adds common controls and state for address resolution, redirects, proxy Neighbor Advertisements, Neighbor Unreachability Detection and both ordinary and enhanced Duplicate Address Detection.

The data model validates cleanly. That is a statement about schema correctness, not about the policy carried by every leaf. The distinction became visible in Carlos Pignataro’s 5 September Internet Area Directorate review. He rated the draft “Ready with Issues” and identified one major point: the security considerations appear to omit enhanced-dad/auto-resolve from the list of sensitive writable nodes even though the setting can trigger automatic blocking.

That comment is unusually useful because it locates the governance problem inside the configuration surface. The draft already recommends secure management transports, mutual authentication and Network Configuration Access Control Model rules. Yet controlling who may flip a bit is only the first half of accountability. The other half is showing what the device did after the bit was flipped.

Detection, suppression and exclusion are not one act

The auto-resolve description inherits a response first described in RFC 7527. In a particular trust model, a trusted router serves untrusted IPv6 hosts. Cable broadband is the worked example: an access concentrator detects a genuine duplicate involving its tentative or optimistic address, logs the event, drops the received Neighbor Discovery message and blocks the modem associated with the Layer-2 service identifier.

Those verbs carry different consequences. A log preserves evidence. A drop suppresses one message. A block can remove a customer device from service. They also fail differently. Logging may fail while blocking succeeds; a packet may be discarded without the intended host being identified; a block may outlive the condition that triggered it. A single configuration boolean says that the bundle is permitted, but it does not express which result counts as success or how partial completion should be repaired.

The scope matters as much as the mechanics. RFC 7527 does not present automated blocking as a universal response to any duplicate. It describes it for networks with the same trusted-router/untrusted-host relationship. Other environments normally return to the failure handling in RFC 4862. The YANG description retains the trusted-router language, but the leaf itself is a generic boolean in a reusable per-interface model. An operator therefore needs a deployment profile that states where the required trust model actually holds.

A signal is not an identity verdict

Enhanced DAD exists because looped-back Neighbor Discovery traffic can look like a duplicate. It adds a nonce so a node can distinguish its own reflected probe from another message. That improves classification; it does not make the signal infallible.

RFC 4862 says Duplicate Address Detection is not completely reliable. RFC 7527 adds sharper security limits: a rogue can manipulate a nonce, and a fake Neighbor Advertisement can answer DAD probes. It recommends Secure Neighbor Discovery for those threats and also points to Source Address Validation Improvement. These safeguards matter because a service-denial action asks the device to move from observing a packet to deciding which subscriber or host should bear the consequence.

For cable access, the Layer-2 service identifier supplies an attribution bridge. In another deployment, that bridge may be absent, transient or shared. The standardized model does not say that a suspicious IPv6 source address is a durable host identity. Treating it as one would turn a protocol observation into an administrative judgment without recording the join between them.

Counters cannot answer an appeal

Revision 08 provides extensive per-interface counters for received, transmitted and dropped Neighbor Discovery messages, including several drop reasons. They are valuable for operations. They can reveal that something is happening and help compare rates over time. They cannot, by themselves, reconstruct why a particular host was blocked.

The standard tree shown in the draft has no per-enforcement event record tying the detected packet class to an interface, claimed address, Layer-2 identity, policy revision, action result and release condition. Nor does it define an unblock operation or an automatic expiry. Vendors can add logs, notifications and recovery controls; many likely will. The point is narrower: those functions are not interoperable consequences of the standardized switch.

Before deployment, an operator should require a decision receipt. It should record the evidence classification, timestamp and interface; the address at issue; the attribution mechanism; the configuration origin and policy version; and separate outcomes for logging, dropping and blocking. A block should have an explicit scope, duration, reason code and tested reversal path. If the implementation cannot produce those facts, the boolean is an automation shortcut without an adequate audit surface.

Sources