Summary

  • RFC 5072 makes the PPP network-layer phase and IPV6CP Opened necessary before IPv6 packets can be communicated, but neither state proves that a usable global address or route exists.
  • Disabling Duplicate Address Detection for a global address is defensible only with evidence for two topology conditions; a Configure-Ack is not that evidence.

The access console shows IPV6CP in Opened. The change record turns green. Someone writes “IPv6 ready” and closes the window.

That sentence has crossed several unrecorded boundaries.

RFC 5072 defines the method for carrying IPv6 over PPP and the IPv6 Control Protocol used to configure the IPv6 modules at both ends. Before an IPv6 packet may be communicated, PPP must reach its network-layer protocol phase and IPV6CP must reach Opened. Those are meaningful preconditions. They show that a particular local control exchange reached a defined state. They do not show that a global unicast address was formed, remained unique, entered the forwarding table, found a route or reached an application peer.

The control exchange is narrower than many dashboards imply. RFC 5072 defines one option in this document: the 64-bit Interface-Identifier. A Configure-Request contains one instance. If the two non-zero values proposed for the ends differ, the peer acknowledges the request. If the values collide, the peer sends a Nak with another value. If both sides offer zero, negotiation ends with Reject. The success condition is local to one point-to-point link: the two identifiers differ there.

Even failure resists a comforting default. When no valid identifier can be negotiated, RFC 5072 says no default should be assumed and leaves recovery unspecified. Manual configuration is one possible response. An operational system that silently inserts an identifier may be useful, but the RFC receipt and the operator action are then different facts.

The most important sentence comes after negotiation. The negotiated identifier is used to form the local link-local address. It should not be assumed to be the identifier used for global unicast addresses. A peer may generate one or more different identifiers for those global addresses. A log containing only the IPV6CP transcript therefore cannot reconstruct the later address without another record.

This distinction changes the meaning of Duplicate Address Detection. On the link-local address formed from the negotiated identifier, DAD is redundant because the point-to-point exchange has already separated the two endpoint values. The global case is conditional. RFC 5072 says DAD may be redundant only when the advertised prefix is exclusive to that PPP link and the terminating access router does not itself autoconfigure a global address from that prefix.

Both conditions matter. Prefix exclusivity is a topology and provisioning claim. Router non-use is a configuration claim. Neither appears inside an IPV6CP Configure-Ack. If operations set DupAddrDetectTransmits to zero, the proof burden does not disappear; it moves from packet-based duplicate testing into the controls that establish and preserve those two conditions.

RFC 4862 supplies the default discipline. It requires DAD for unicast addresses before assignment, whether the address came from SLAAC, DHCPv6 or manual configuration, subject to its stated exceptions. It defines a zero value of DupAddrDetectTransmits as no DAD. The exception is therefore not another test. It is a decision to rely on topology invariants instead.

Global construction adds another branch. RFC 5072's appendix says stateless configuration combines a router-advertised prefix with an interface identifier, while a stateful path obtains the address from a server such as DHCPv6. The evidence needed for each branch differs. A Router Advertisement is not a DHCP lease; a prefix is not an assigned address; and an assigned address is not yet a route or successful exchange.

Later standards also changed what a stable identifier should mean. RFC 8064 formally updates RFC 5072. It recommends the semantically opaque method in RFC 7217 for stable SLAAC addresses and recommends against embedding stable link-layer addresses. That update is a standards decision, not evidence that a named host adopted it. Audits need the generation method and software policy actually used at the time.

Control-plane success is not authentication either. RFC 5072 discusses admission filters, authentication and encryption as separate link-security measures. It warns that an MD5 authentication method can expose a replay path. A session can therefore have an opened IPv6 control protocol while the assurance question remains in another layer.

A defensible activation receipt should preserve:

  1. the physical/link event and LCP state;
  2. the authentication and authorization result;
  3. the IPV6CP request, Ack/Nak/Reject history and final Opened time;
  4. both endpoint identifiers and their generation methods;
  5. the resulting link-local address;
  6. the global-address acquisition branch, prefix, identifier and lifetimes;
  7. either the DAD transcript or evidence for both RFC 5072 exception conditions;
  8. the installed address and route state;
  9. the chosen source on an observed outbound packet;
  10. the peer response; and
  11. the application result.

This list is an operating recommendation, not an extra requirement smuggled into RFC 5072. It applies Heng Lu's reality-layer discipline to access activation. Negotiated state, configured address, forwarding state, observed traffic and service outcome are adjacent facts. They are not interchangeable facts.

Sources