Summary

  • The proposed IPv6 Network Resource option lets a packet carry a four-octet NRP Selector ID; capable routers use it to choose local bandwidth, buffering or queue resources, while routers that do not understand it may simply ignore it.
  • Revision 16 now acknowledges that observing the selector can expose a service class and modifying it can change treatment. A trusted-domain recommendation is an operating assumption, not packet-level proof of integrity or path-wide compliance.
  • A new IETF shepherd write-up says the draft is ready to move forward but records no implementation status. Consensus, intent to deploy and a private implementation statement remain different evidence from an auditable running path.

The most consequential two bits in the proposed option are both zero. Under revision 16, a router that does not recognize the Network Resource option is instructed to skip it. The packet can continue toward its destination. Nothing in that survival proves that the requested Network Resource Partition shaped its treatment.

This is the central evidence problem in an otherwise compact design. The option carries a selector inside an IPv6 Hop-by-Hop Options header. At ingress, local classification policy decides that a packet belongs in an NRP, adds an outer IPv6 header and inserts the selector. A capable transit router combines the destination with that identifier: the destination chooses the next hop and interface; the NRP Selector ID chooses a local resource subset on that interface. That subset may be a virtual channel, reserved bandwidth, buffers or queues.

The same packet can encounter three realities. A fully capable node processes the option at line rate and applies its local mapping. A node that understands Hop-by-Hop headers but not the NR option ignores the option. A node that does not process the Hop-by-Hop header may ignore the whole header and forward by destination. All three can forward the packet. Only the first has made the resource-specific decision described by the draft.

The S flag adds another branch, but only after recognition. If a capable node cannot match the selector to provisioned resources, S=1 requires it to drop the packet. With S=0, it forwards using default resources as though the option were absent. The draft suggests strict matching as the normal NRP policy and gives OAM as a use where arrival can test whether resources and policy were instantiated along a path. That is useful test construction. It does not turn ordinary packet arrival into proof of latency, throughput or isolation.

Revision 16 makes the trust problem harder to ignore. The revision-15 text broadly said the design introduced no additional security issues. The current XML source adds two risks. An observer may infer that a flow belongs to a low-latency or high-throughput class and target it selectively. An actor able to alter the selector may send traffic to a different queue, eroding an SLA or crossing an isolation boundary.

The proposed response is to use the option inside trusted, operator-administered domains and filter on its presence. That can be a reasonable deployment boundary. It is not a field in the packet that authenticates who assigned the ID, a cryptographic guarantee that the value remained unchanged, or a receipt from each node stating what it did. Even the Option Type change bit—zero because the option is not supposed to change en route—declares semantics; it does not enforce them.

The document's new process event sharpens that distinction. On 6 September, the Datatracker history recorded a shepherd and published the protocol write-up for the current document record. The write-up says eleven people supported the work during last call, one person raised six interrelated concerns and the chairs concluded that the draft should advance without a proposed alternative encoding after the list reacted negatively to it. The alternative discussion and chair conclusion are process evidence.

Implementation evidence is thinner. The shepherd states that there is no recorded implementation status. One last-call response implied deployment, and an author privately indicated implementation. Those signals may justify asking better questions. They do not identify software versions, supported hardware, topology coverage, selector policy, conformance tests or observed service results.

The broader standards context explains why. RFC 8200 defines IPv6 option behavior; RFC 7045, RFC 9098, RFC 9099 and RFC 9673 address the uneven operational and security reality of extension-header processing. RFC 9543 and RFC 9732 define the NRP and enhanced-VPN context, while the NRP scalability draft examines how many partitions an operator may need. The current IANA IPv6 registry remains a registry surface; this draft still requests an option code and two new registries rather than documenting completed assignments.

Heng Lu's Minimum Initial Specification gives the right allocation of authority. A common format can state what an adopting node must do. Classification, identifier assignment, filtering, topology and resources remain local decisions. Reality Layers prevents the selector from impersonating the queue action. Running-Code Primacy makes deployment real only when named systems implement, expose and sustain the behavior.

The NR option can therefore be valuable without being magical. It gives cooperating routers a compact common reference. The honest claim is narrow: this packet requested a locally defined resource treatment. The stronger claim—every hop understood, trusted and obeyed it—needs a path of receipts the option does not itself provide.