IPv6 Application of the Alternate-Marking Method
Extracted elements (28)
A dedicated Hop-by-Hop or Destination Option was chosen over reusing an existing Extension Header, the IPv6 destination address, or the Flow Label. Reusing existing headers is non-optimized; using the destination address is expensive; using the Flow Label conflicts with load-distribution use (RFC 6438).
FlowMonID is defined as 20 bits as a good compromise: it provides a low collision rate acceptable for most deployments and can be disambiguated by combining it with source and destination addresses. Reusing the IPv6 Flow Label was rejected because it may change en route and alters application forwarding intent.
The three high-order bits of the AltMark Option Type are set to 000 (skip if unrecognized, data does not change en route) to minimize throughput impact on nodes that do not support the Option, ensuring measurement-unaware nodes simply ignore it without disrupting packet flow.
Hop-by-Hop Options are not strongly recommended by RFC 7045 and RFC 8200 in general; however, their use is justified here for OAM purposes. In practice, packets with Hop-by-Hop Options may be processed in the slow path or dropped by some implementations, a known deployment risk noted by the authors.
The AltMark Option can be used with Segment Routing over IPv6 (SRv6). When a Routing Header is present, Destination Options placed before the Routing Header are processed by each waypoint in the route list, enabling per-segment measurement.
A consistent approach MUST be used in the Alternate-Marking deployment to avoid mixing different identification methods; all nodes along the path SHOULD use the same mode for identification.
AltMark Option configuration MUST be secured in a way that authenticates authorized users and verifies the integrity of configuration procedures, and channels used to report flow statistics MUST be secured.
Delay metrics MAY be calculated using either the single-marking methodology (L bit only) or the double-marking methodology (L bit for loss, D bit for delay).
For packet loss measurement, clocks in different nodes MUST be synchronized to the same clock reference with an accuracy of +/- B/2 time units (where B is the fixed batch duration), and batch lengths MUST be chosen large enough to avoid clock-skew and network-delay artifacts.
Intermediate nodes and destination node MUST only read the marking values of the AltMark Option without modifying the Options Header; the source node is the only one that writes the Options Header.
It is RECOMMENDED to use FlowMonID for identification in combination with source and destination addresses. This allows monitoring of 145 concurrent flows per host pair with 1% collision probability (pseudo-random) or 1,048,576 flows with a centralized controller.
The Alternate-Marking Method MUST be applied to IPv6 only in a controlled domain, as defined in Section 2.1.
The FlowMonID MUST be set pseudo-randomly by the source node or by a centralized controller.
The FlowMonID MUST only be used as a monitored flow identifier to determine a monitored flow within the measurement domain.
The IPv6 application of the Alternate-Marking Method MUST be deployed in a controlled domain, and an implementation MUST filter packets that carry Alternate-Marking data entering or leaving the controlled domain.
The three high-order bits of the AltMark Option Type MUST be set to 000, meaning nodes skip this Option if unrecognized and Option Data does not change en route.
When multiple administrative domains are traversed, it is RECOMMENDED that they create a whole controlled domain by employing IPsec authentication and encryption or other VPN technology providing full packet confidentiality and integrity protection.
When using the single-marking methodology for delay measurement, the D flag MUST be set to zero on transmit and ignored by monitoring points.
The AltMark Option can be carried as either a Hop-by-Hop Options Header (readable by any configured node along the path) or a Destination Options Header (processed only by the destination, or by routing-header waypoints if placed before the Routing Header).
The AltMark TLV is a 32-bit IPv6 Extension Header Option (Hop-by-Hop or Destination) carrying a 20-bit FlowMonID, a 1-bit Loss flag (L), a 1-bit Delay flag (D), and reserved bits. The Option Type is 0x12 (binary 000 10010).
The Flow Monitoring Identification (FlowMonID) is a 20-bit field that identifies the monitored flow. It is distinct from the IPv6 Flow Label and is used solely for measurement correlation within the Alternate-Marking domain.
Two delay measurement methodologies are defined: single-marking (uses only the L bit for both loss and delay via batch-boundary timestamps) and double-marking (L bit for loss batches, D bit marks specific packets for per-packet delay measurement).
IANA allocated Option Type 0x12 (binary act=00, chg=0, rest=10010) for 'AltMark' in the 'Destination Options and Hop-by-Hop Options' subregistry of the 'Internet Protocol Version 6 (IPv6) Parameters' registry.
An on-path attacker can modify the L/D flags or FlowMonID, insert or delete the AltMark Option, causing false loss/delay appearances or invalidating measurements. Mitigation requires deployment strictly within a controlled domain with boundary filtering of external packets carrying the AltMark Option.
The Alternate-Marking method depends on time synchronization; attacking the time protocol (or GPS clock source) can compromise measurement integrity. RFC 7384 discusses time-protocol threats, and RFC 8915 Network Time Security is recommended as a mitigation.
The AltMark Option fields could theoretically serve as a covert channel for an on-path observer. Deployment in a controlled domain reduces this risk by limiting the set of nodes with access to the marked traffic.
The FlowMonID field can enable flow-tracking attacks, allowing an attacker to collect information about network paths. The marking bits alone are insufficient for single-point reconnaissance, but multi-point passive eavesdropping could yield performance data. Controlled-domain deployment mitigates these risks.
The AltMark Option data fields are 4 bytes (Opt Data Len = 4): bits 0–19 are the FlowMonID (20-bit unsigned integer), bit 20 is the L (Loss) flag, bit 21 is the D (Delay) flag, and bits 22–31 are Reserved (MUST be set to zero on transmission, ignored on receipt).