Registries for the One-Way Active Measurement Protocol (OWAMP)
updates
- rfc-4656 — A One-way Active Measurement Protocol (OWAMP)
Extracted elements (15)
In the OWAMP-Modes registry, assignments are made purely by bit position with no associated value references, unlike the comparable TWAMP-Modes registry. This difference is noted as a topic for potential improvement in the TWAMP registry (reconciled in RFC 7717).
No attempt is made to keep the OWAMP and TWAMP Modes registries synchronized, because one-way and two-way measurement configurations have inherent differences and may need different features. The sole exception is bit position 3, which is reserved in OWAMP to allow future alignment with a potential mixed-security mode analogous to RFC 5618 for TWAMP.
OWAMP had no new feature proposals until RFC 7717, whereas TWAMP accumulated feature requests during its final review and established registries earlier. This document retroactively establishes equivalent registries for OWAMP to support future extensions in the same manner.
A Control-Client conforming to RFC 4656 MAY ignore the 29 most significant bits of the Modes field, or it MAY support features communicated in those bit positions (e.g., the IKEv2-derived Shared Secret Key extension from RFC 7717).
IANA SHOULD allocate monotonically increasing bit positions in the OWAMP-Modes registry when new assignments are requested.
The OWAMP-Control Command Numbers registry MUST be updated only by 'IETF Review' as specified in RFC 5226, because the registry has a fixed capacity of 256 values and OWAMP is an IETF protocol.
The OWAMP-Modes registry MUST be updated only by 'IETF Review' as specified in RFC 5226, given the 32-bit positional constraint and IETF protocol status.
When no features beyond the base security modes are activated, the 27 most significant bits of the 32-bit Modes field MUST be zero.
The OWAMP-Control Command Numbers initial contents define: 0 (Reserved), 1 (Request-Session), 2 (Start-Sessions), 3 (Stop-Sessions), 4 (Fetch-Sessions), 5–253 (Unassigned), 254 (Experimentation), 255 (Reserved). Semantics follow RFC 4656 Section 3.5 and related sections.
The OWAMP-Modes bit assignments are: bit 0 (Unauthenticated), bit 1 (Authenticated), bit 2 (Encrypted) from RFC 4656; bit 3 (Reserved); bit 4 (IKEv2-derived Shared Secret Key, added by RFC 7717); bits 5–31 (Unassigned).
IANA has established the OWAMP-Control Command Number registry. Command numbers are specified in the first octet of OWAMP-Control-Client messages; the registry can contain a maximum of 256 values (0–255).
IANA has established the OWAMP-Modes registry. Modes are indicated by setting single bits in a 32-bit Modes field exchanged in Server Greeting and Set-up Response messages, with initial assignments for Unauthenticated (bit 0), Authenticated (bit 1), Encrypted (bit 2), Reserved (bit 3), and IKEv2-derived Shared Secret Key (bit 4).
This document itself introduces no new security or privacy issues, as it only creates registries. However, the security considerations for active measurement of live networks from RFC 4656 and RFC 5357 remain applicable, and privacy considerations for measurement systems (especially where Internet users participate) are addressed in RFC 7594.
OWAMP-Control Command Numbers are encoded in the first octet of OWAMP-Control-Client command messages, yielding a maximum of 256 distinct command values (0x00–0xFF).
The OWAMP-Modes field is a 32-bit field carried in Server Greeting and Set-up Response messages. Each bit position conveys a distinct feature; the Server sends the bitwise OR of all modes it is willing to support.