Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

RFC 9946 §6: Test Setup Request and Response

The 60 Requirements of RFC 9946 §6, each quoted from the RFC with its state and the tests that prove it. Conformance explains the states.

StateRequirements
Tested58
Deviation2

RFC9946-6-1

Tested

The client source IP address and the server destination IP address MUST NOT be a broadcast or multicast address.

Conformance Records: broadcast-means-limited-broadcast.

Proving tests:

RFC9946-6-2

Tested

Any Test Setup Request or Test Setup Response packet containing a multicast or broadcast source or destination IP address MUST be silently dropped and ignored.

Conformance Records: broadcast-means-limited-broadcast.

Proving tests:

RFC9946-6-L1

Tested

The measurement method and the protocol specified by this document are expected to function with unicast and anycast IP addresses.

Note: Replies leave from the arrival address (ADR 0007).

Proving tests:

RFC9946-6.1-1

Tested

The client SHALL begin the Control phase exchange by sending a Test Setup Request message to the server’s (standard) control port.

Proving tests:

RFC9946-6.1-2

Tested

The client SHALL simultaneously start a test initiation timer so that if the Control phase fails to complete Test Setup and Test Activation exchanges in the allocated time, the client software SHALL exit (i.e., the UDP socket will be closed and an error message will be displayed to the user).

Conformance Records: multi-connection-setup-deadline.

Proving tests:

RFC9946-6.1-3

Tested

The test initiation timer MAY reuse the test termination timeout value.

Proving tests:

RFC9946-6.1-4

Tested

Note: Any field labeled as ‘reserved for alignment’, in any PDU, MUST be set to 0 and MUST be ignored upon receipt.

Proving tests:

RFC9946-6.1-5

Tested

The UDP PDU format layout SHALL be as follows (big-endian AB, starting with the most significant byte and ending with the least significant byte):

Proving tests:

RFC9946-6.1-6

Tested

This field MAY be used to rate-limit the maximum rate the server should attempt.

Conformance Records: max-bandwidth-split-across-test-connections, search-capped-at-stated-max-bandwidth.

Proving tests:

RFC9946-6.1-7

Tested

This bit SHALL be set by default.

Proving tests:

RFC9946-6.1-8

Tested

By default, sending rates up to 1 Gbps SHALL NOT produce IP packet sizes greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set), while rates above 1 Gbps MAY produce IP packet sizes up to 9000 bytes.

Conformance Records: ipv4-based-sending-rate-structure-sizes, sending-rate-table-follows-the-server-shape.

Proving tests:

RFC9946-6.1-9

Tested

When CHSR_JUMBO_STATUS is not set, all sending rates SHALL NOT produce IP packet sizes greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set).

Conformance Records: ipv4-based-sending-rate-structure-sizes, sending-rate-table-follows-the-server-shape.

Proving tests:

RFC9946-6.1-10

Tested

This bit SHALL NOT be set by default.

Proving tests:

RFC9946-6.1-11

Tested

If set, sending rates up to 1 Gbps MAY produce IP packets up to the traditional size of 1500 bytes.

Conformance Records: ipv4-based-sending-rate-structure-sizes, sending-rate-table-follows-the-server-shape.

Proving tests:

RFC9946-6.1-12

Tested

If CHSR_JUMBO_STATUS is simultaneously not set, all sending rates SHALL NOT produce IP packets greater than the traditional size of 1500 bytes.

Conformance Records: ipv4-based-sending-rate-structure-sizes, sending-rate-table-follows-the-server-shape.

Proving tests:

RFC9946-6.1-13

Tested

This field MUST be set to 0 and MUST be ignored upon receipt.

Proving tests:

RFC9946-6.1-L1

Tested

A one-octet field indicating the index of a connection relative to all connections that make up a single test (starting at 0, incremented by 1 per connection).

Note: mcIndex field.

Conformance Records: multi-connection-agreement-checks.

Proving tests:

RFC9946-6.1-L2

Tested

An implementation may restrict the number of connections supported for a single test to a value less than or equal to 255.

Note: mcIndex field.

Proving tests:

RFC9946-6.1-L3

Tested

A two-octet field containing a pseudorandom non-zero identifier (via a Random Number Generator, source port number, …) that is common to all connections of a single test.

Note: mcIdent field.

Conformance Records: mc-ident-from-a-held-port, multi-connection-agreement-checks.

Proving tests:

RFC9946-6.1-L4

Tested

A one-octet field set to CHSR_CREQ_SETUPREQ to indicate a Setup Request message.

Note: cmdRequest field.

Proving tests:

RFC9946-6.1-L5

Tested

Note that CHSR_CREQ_NONE remains unused.

Note: cmdRequest field.

Proving tests:

RFC9946-6.1-L6

Tested

All Request PDUs always have a Command Response of XXXX_CRSP_NONE (i.e., CHSR_CRSP_NONE, CHNR_CRSP_NONE, or CHTA_CRSP_NONE).

Note: cmdResponse field.

Proving tests:

RFC9946-6.1-L7

Tested

The server compares this value to its currently available configured limit for test admission control.

Note: maxBandwidth field.

Conformance Records: max-bandwidth-split-across-test-connections, admitted-rate-cap-per-direction.

Proving tests:

RFC9946-6.1-L8

Tested

The maxBandwidth field’s most significant bit, the CHSR_USDIR_BIT, is set to 0 by default to indicate “downstream” and has to be set to 1 to indicate “upstream”.

Note: maxBandwidth field.

Conformance Records: usdir-set-on-every-upstream-setup, admitted-rate-cap-per-direction, usdir-must-match-activation-direction.

Proving tests:

RFC9946-6.1-L9

Tested

A two-octet field set to zero in the Test Setup Request and populated by the server in the Test Setup Response.

Note: testPort field.

Proving tests:

RFC9946-6.1-L10

Tested

It contains the UDP ephemeral port number on the server that the client has to use for the Test Activation Request and subsequent Load or Status PDUs.

Note: testPort field.

Proving tests:

RFC9946-6.1-L11

Deviation

One of the following has to be set (see Section 5.3 for requirements and details of operation): AUTHMODE_1: Required authentication for the Control phase. AUTHMODE_2: Required authentication for the Control and Data phases (Status Feedback PDU only).

Note: authMode field. Modes 1 and 2 are met; Unauthenticated Mode (0) is the Deviation.

Recorded in unauthenticated-mode.

RFC9946-6.1-L12

Tested

A 32-bit timestamp of the current system (wall-clock) time since the Unix Epoch on January 1, 1970 at 00:00:00 UTC.

Note: authUnixTime field; the low 32 bits of the wall clock (ADR 0009).

Proving tests:

RFC9946-6.1-L13

Tested

Normally, the calculation is done as the last step of building the PDU.

Note: authDigest field.

Proving tests:

RFC9946-6.1-L14

Tested

However, if the optional checkSum field is being utilized, it becomes the penultimate step and is done just prior to the checksum calculation (with the checkSum field set to zero).

Note: authDigest field.

Proving tests:

RFC9946-6.1-L15

Tested

The calculation is done as the very last step of building the PDU, with the checkSum field set to zero.

Note: checkSum field.

Proving tests:

RFC9946-6.2-1

Tested

When the server receives the Setup Request, it SHALL first perform the following: Message Verification Procedure: 1. Verify that the size of the message is correct. 2. If the optional checkSum field is being utilized, validate the checksum as described in Section 5.6 and (if valid) zero the checkSum field prior to authentication verification. 3. Verify that the authMode value is valid and appropriate (per Section 5.3) for the message type. 4. If the authMode is valid and appropriate, authenticate the message by checking the authDigest as prescribed in Section 5.3. 5. If the message is authentic, check the authUnixTime field for acceptable immediacy.

Note: The Message Verification Procedure that later sections cite as “Section 6.2, Paragraph 2”. The authUnixTime window is +/-5 s inclusive, compared modulo 2^32 (ADR 0009).

Proving tests:

RFC9946-6.2-2

Tested

Note: If any of the above checks fail, the message SHALL be considered invalid.

Conformance Records: authentic-setup-outside-time-window-is-silent.

Proving tests:

RFC9946-6.2.1-1

Tested

The server SHALL then evaluate the other fields in the protocol header, such as the protocol version, the PDU ID (to validate the type of message), the maximum bandwidth requested for the test, and the modifierBitmap for use of options such as Jumbo datagram status and Traditional MTU (1500 bytes).

Proving tests:

RFC9946-6.2.1-2

Tested

If the client has selected options for * Jumbo datagram support (modifierBitmap), * Traditional MTU (modifierBitmap), and * Authentication mode (authMode) that do not match the server configuration, the server MUST reject the Setup Request.

Conformance Records: sending-rate-table-follows-the-server-shape.

Proving tests:

RFC9946-6.2.1-3

Deviation

If the authDigest is valid, a Test Setup Response SHALL be sent back to the client with a corresponding Command Response value indicating the reason for the rejection.

Note: Applies when a Setup Request must be rejected. Met except for the refusals the Deviation leaves unanswered; the rejection codes are recorded in docs/conformance/records/control.toml. OB-UDPST also answers authentication failures.

Recorded in authentic-setup-requests-left-unanswered.

Conformance Records: authentic-setup-outside-time-window-is-silent, server-limits-refuse-with-connfail.

Proving tests:

RFC9946-6.2.1-4

Tested

If the authDigest is invalid, then the Test Setup Request SHOULD fail silently.

Note: The RFC permits server administrators to send a Setup Response anyway, for operations and troubleshooting (Troubleshooting Mode).

Proving tests:

RFC9946-6.2.1-5

Tested

The additional circumstances when a server SHALL NOT communicate the appropriate Command Response code for an error condition (fail silently) are when: * the Setup Request PDU size is not equal to the ‘struct controlHdrSR’ size shown in Figure 3, * the PDU ID is not 0xACE1 (Test Setup PDU), or * a directed attack has been detected.

Note: Attack detection is out of scope per the RFC, so the third case is not testable.

Proving tests:

RFC9946-6.2.1-6

Tested

When the server replies to a Test Setup Request message, the Test Setup Response PDU is structured identically to the Test Setup Request PDU and SHALL retain the original values received in it, with the following exceptions: * The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a response. * The cmdResponse field is set to an error code (starting at cmdResponse 2, Bad Protocol Version; see Section 12.3.5), indicating the reason for rejection. If cmdResponse indicates a bad protocol version (CHSR_CRSP_BADVER), the protocolVer field is also updated to indicate the current expected version. * The authUnixTime field is updated to the current system (wall- clock) time and, after the authDigest and checkSum fields are zeroed, the authDigest is recalculated and inserted. If the optional checkSum field is being utilized, it is then also calculated and inserted.

Note: The rejection case: the exceptions cover cmdRequest, cmdResponse (and protocolVer for CHSR_CRSP_BADVER), authUnixTime, authDigest and checkSum. Reserved fields are still zeroed (RFC9946-6.1-4); the Server echoes keyId (ADR 0009).

Proving tests:

RFC9946-6.2.1-7

Tested

The Setup Request/Response message PDU SHALL be organized as follows (here and in all following code figures coded by programming language C [C-Prog]):

Note: Figure 3’s struct controlHdrSR follows.

Proving tests:

RFC9946-6.2.1-L1

Tested

The exception is for operations support: server administrators are permitted to send a Setup Response to support operations and troubleshooting.

Note: Troubleshooting Mode.

Conformance Records: troubleshooting-replies-unsigned-except-authtime, troubleshooting-replies-rate-limited.

Proving tests:

RFC9946-6.2.2-1

Tested

If the server finds that the Setup Request matches its configuration and is otherwise acceptable, the server SHALL initiate a new connection to receive the Test Activation Request from the client, using a new UDP socket allocated from the UDP ephemeral port range.

Proving tests:

RFC9946-6.2.2-2

Tested

Then, the server SHALL start a watchdog timer (to terminate the new connection if the client goes silent) and SHALL send the Test Setup Response back to the client.

Note: The watchdog uses the same value as on the Client side, whose timeouts are in Section 6.1; timeouts per ADR 0002.

Proving tests:

RFC9946-6.2.2-3

Tested

When the server replies to the Test Setup Request message, the Test Setup Response PDU is structured identically to the Test Setup Request PDU and SHALL retain the original values received in it, with the following exceptions: * The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a response. * The cmdResponse field is set to CHSR_CRSP_ACKOK, indicating an acknowledgment. * The testPort field is set to the ephemeral port number to be used for the client’s Test Activation Request and all subsequent communication. * The authUnixTime field is updated to the current system (wall- clock) time and, after the authDigest and checkSum fields are zeroed, the authDigest is recalculated and inserted. If the optional checkSum field is being utilized, it is then also calculated and inserted.

Note: The acceptance case: the exceptions cover cmdRequest, cmdResponse, testPort, authUnixTime, authDigest and checkSum. Reserved fields are still zeroed (RFC9946-6.1-4); the Server echoes keyId (ADR 0009).

Proving tests:

RFC9946-6.2.2-4

Tested

To ensure that a server’s local firewall will successfully allow packets received for the new ephemeral port number, the server SHALL immediately send a Null Request with the corresponding values including the source and destination IP addresses and port numbers.

Proving tests:

RFC9946-6.2.2-5

Tested

The source port SHALL be the new ephemeral port.

Proving tests:

RFC9946-6.2.2-6

Tested

If received, the client SHALL follow the Message Verification Procedure listed in Section 6.2, Paragraph 2.

Note: The Null Request; there is no response to it.

Proving tests:

RFC9946-6.2.2-7

Tested

The UDP PDU format layout SHALL be as follows (big-endian AB):

Note: The Null Request layout (Figure 4) follows.

Proving tests:

RFC9946-6.2.2-8

Tested

If a Test Activation Request is not subsequently received from the client on the new ephemeral port number before the watchdog timer expires, the server SHALL close the socket and deallocate the associated resources.

Proving tests:

RFC9946-6.2.2-9

Tested

The Null Request message PDU SHALL be organized as follows:

Note: Figure 5’s struct controlHdrNR follows.

Proving tests:

RFC9946-6.2.2-L1

Tested

The watchdog timer is set to the same value as on the client side (see Section 6)

Note: The RFC’s sentence has no final period. Timeouts per ADR 0002.

Proving tests:

RFC9946-6.2.2-L2

Tested

Note that there is no response to a Null Request.

Proving tests:

RFC9946-6.2.2-L3

Tested

The authentication and checkSum fields follow the same methodology as with the Setup Request and Response.

Note: Null Request.

Proving tests:

RFC9946-6.2.2-L4

Tested

Set to CHNR_CREQ_NULLREQ to indicate a Null Request message.

Note: Null Request cmdRequest field.

Proving tests:

RFC9946-6.2.2-L5

Tested

Set to CHNR_CRSP_NONE.

Note: Null Request cmdResponse field.

Proving tests:

RFC9946-6.3-1

Tested

When the client receives the Test Setup Response message, it SHALL first follow the Message Verification Procedure listed in Section 6.2, Paragraph 2.

Conformance Records: setup-response-from-another-address, unverified-setup-rejection-hint.

Proving tests:

RFC9946-6.3-2

Tested

The client SHALL then proceed to evaluate the other fields in the protocol, beginning with the protocol version, PDU ID (to validate the type of message), and cmdRequest for the role of the message, which MUST be Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated by Figure 3.

Note: How the Client checks protocolVer is unspecified; record setup-response-protocol-version.

Conformance Records: setup-response-protocol-version.

Proving tests:

RFC9946-6.3-3

Tested

If the cmdResponse value indicates an error (values greater than CHSR_CRSP_ACKOK), the client SHALL display/report a relevant message to the user or management process and exit.

Conformance Records: undefined-setup-cmd-response.

Proving tests:

RFC9946-6.3-4

Tested

If the client receives a Command Response code that is not equal to one of the codes defined, the client MUST terminate the connection and terminate operation of the current Setup Request.

Note: An undefined code above the defined range also matches RFC9946-6.3-3; CHSR_CRSP_NONE (0) is defined but neither error nor success.

Conformance Records: undefined-setup-cmd-response.

Proving tests:

RFC9946-6.3-5

Tested

If the Command Response code value indicates success (CHSR_CRSP_ACKOK), the client SHALL compose a Test Activation Request with all the test parameters it desires, such as the test direction, the test duration, etc., as described below.

Proving tests: