Summary

  • RFC 3634 encoded CCC sub-option 10 as a multiple-of-four list of IPv4 KDC addresses. Multiple addresses had to appear in decreasing order of priority; the option did not carry live health, realm, transport, port, identity or a completed Kerberos exchange.
  • DHCP receipt, client retention, endpoint selection, network contact, KDC authentication, ticket issuance, application authentication and a secure SNMPv3 result are separate receipts. Promoting the first into the last creates a green dashboard with no causal trail.
  • Leadership should govern the ordered list as versioned configuration and govern actual client behavior separately: canary each change, bound retries, measure fallback load, verify realm and identity, and preserve the selection decision that produced each attempt.

Four octets can name a destination, not its condition

RFC 3634 was written for CableHome-compliant residential gateways using Kerberos as the first step toward a secure SNMPv3 relationship. Its wire object is deliberately small. Sub-option code 10 is followed by a length and then one or more four-octet IPv4 addresses. The minimum is one address; the length must remain divisible by four. With several KDCs, the sender lists them from higher to lower priority.

That is a useful coordination rule. It gives a client a candidate set without requiring DNS lookup. It also has a sharp evidence boundary. No bit says that address one answered this morning. No field binds the address to a realm, transport or port. There is no weight, TTL, probe age, certificate fingerprint, server principal, ticket result or application transaction.

The parent CCC specification reinforces the boundary by keeping other facts elsewhere. RFC 3495 has separate sub-options for Kerberos realm name, AS exchange retry and backoff, AP exchange retry and backoff, and ticket-granting-server use. RFC 3634 did not silently absorb those controls just because its addresses point toward KDCs.

Priority is an instruction, not telemetry

“Decreasing order of priority” describes an administrator’s intended order at the time the DHCP response was assembled. It does not define priority as latency, spare capacity, proximity or current health. More importantly, RFC 3634 does not specify the full client algorithm that turns the list into attempts: how long to wait, which errors permit fallback, whether to remember failure, when to return to the first address, or how to avoid synchronized retry.

Two conforming systems can therefore preserve the same bytes and still produce different operational paths because local implementation and surrounding PacketCable policy supply missing behavior. A dashboard that labels the first address “active” from configuration alone erases that local decision surface.

The comparison with DNS SRV makes the omission visible without rewriting history. RFC 4120’s discovery form includes service, transport, realm, TTL, priority, weight, port and target. RFC 2782 defines contact order and weighted selection among equal priorities. Yet RFC 2782 also warns that weight is static selection, not dynamic server health; live load changes too quickly for cached DNS data. Even the richer record is not a health check.

RFC 6784 later carried priority, weight, transport, port, IPv6 address and realm in DHCPv6 Kerberos configuration. Those fields are evidence that these dimensions are distinct. They do not retroactively add them to RFC 3634.

Misdirection can fail securely and still hurt

RFC 3634 explicitly says that it relies on DHCP security and adds nothing beyond it. Incorrect configuration can misdirect traffic, produce denial of service or create a man-in-the-middle opportunity. The RFC describes CMTS forwarding and downstream filtering, certificates, mutual Kerberos authentication, network separation and firewalls as mitigations or assumptions.

None turns the address into identity. If a malicious destination cannot complete Kerberos, that is an important security failure—not proof that the configuration path was harmless. The client has spent time, network capacity and perhaps expensive certificate-validation work. A fleet receiving the same bad first address can concentrate that work and delay every legitimate fallback.

The RFC also states an institutional assumption: service providers admitted to the access network cooperate, with redirection handled administratively. That should remain visible as an assumption. An access-control list proves that traffic came from a permitted range; it does not prove that the permitted institution still owns the intended role, that its realm mapping is correct, or that a particular ticket exchange completed.

Build the receipt chain that the list cannot carry

Start with the DHCP receipt: authenticated server if used, transaction, configuration or lease epoch, raw option bytes and parser outcome. Then record the candidate set actually installed. A successful DHCPACK is not proof that the application retained sub-option 10 after validation.

Next preserve the selection receipt. It should name the client instance, chosen address, list version, position, retry count, deadline, previous failure class and the rule that allowed advancement. Network contact then needs its own record: destination, route, transport, port and measured outcome.

Only after that can the trust chain begin. KDC identity, realm binding, cryptographic result and clock state are not supplied by the IP address. An AS or TGS reply and its correlated request establish another layer. Application authentication, the security association and the management operation are later layers again.

The final question is deliberately mundane: did the intended SNMP transaction complete against the intended entity? A ticket can be valid while the application is unavailable. A secure channel can exist while the management operation fails. The phrase “KDC configured” cannot answer either question.

Evidence boundary

This Article identifies no cable operator, gateway, CMTS, service provider, KDC, realm, subscriber, ticket, management station, outage or deployment. Standards Track status and the current IANA allocation of CCC sub-option 10 establish a specification and registry entry, not adoption.

RFC 3634 is the primary source for its wire shape and security discussion. RFC 3495 supplies the surrounding CCC fields; RFCs 2131 and 3118 distinguish DHCP transport from authenticated DHCP processing. RFC 4120 and RFC 2782 supply the comparison with Kerberos DNS discovery. RFC 6784 is later DHCPv6 lineage, while RFCs 5021 and 6251 keep transport and TLS evidence separate.

Heng Lu’s Running-Code Primacy, Minimum Initial Specification, Authority and Belief, and Reality Layers are disclosed analytical lenses. They support treating configured priority, institutional authority, running selection and observed outcome as separate layers. They do not establish RFC-author intent or any deployment fact.

The bounded conclusion is simple. Address one was written first for a reason. Preserve that reason as configuration intent. Do not call it healthy, trusted or successful until the later receipts exist.

Sources