The Transit Measurement Option

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 February 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

2. Conventions

3. Transit Measurement Option

This document defines a new IPv6 Option type, the Transit Measurement type, which can be included either in the Hop-by-Hop Options header or in the Destination Options header. Figure 1 presents the format of the Transit Measurement option type.¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Accumulated Delay                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hop Count   |            Status Bitmap                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A node that complies to this draft MUST support the following fields, as depicted in Figure 1:¶

Option Type:

This document assigns the value TBD-type, which indicates that this is the Transit Measurement option. The two highest order bits are "00", indicating that nodes that cannot process this option skip over it and continue processing the header, as defined in [RFC8200]. The third-highest-order bit is set to "1", indicating that this option may change en route.¶

Opt Data Len:

The length in octets of the two fields that follow, which is 8.¶

Accumulated Delay:

represents the sum of the transit delay values in nanoseconds along the path of the packet, including the current node. This field is a 4-octet unsigned integer in the range 0 to 2^31-1. A transit node that receives the Accumulated Delay field updates its value by adding the transit delay of the current node to the value of the Accumulated Delay field in the received packet. The 'transit delay' in this context is the time in nanoseconds the packet spent in the transit node. If the Accumulated Delay exceeds 2^31-1 nanoseconds then the most significant bit is set to indicate overflow and the value is set to 0x80000000. If a transit node receives this field with the value 0x80000000 or if the node is not able to update the value of the field it SHOULD forward the packet with the unmodified field.¶

Hop Count/Status Bitmap:

indicates the devices along the path that have experienced congestion.¶

Hop Count:

a one-octet field that indicates the number of hops since the source node. The source node initializes this field to 0. Every transit node that supports this option increments this field by 1. A maximum of 24 hops is supported. If a transit node receives this field with the value 24 it assigns the value of all '1's (0xFF = 255), which indicates that the number of hops has exceeded the maximum.¶

Status Bitmap:

a three octet field that represents the congestion status of each transit node along the path. The value '1' indicates that the current packet was enqueued in a queue that is congested. The criterion for whether a queue is congested or not is identical to the "Congestion Experienced" trigger in ECN. Every transit node that supports the Transit Measurement option updates the bit corresponding to the current Hop Count, after having updated the value of the Hop Count. For example, the first transit node along the path updates the Hop Count to 1, and then updates the first (most significant bit) of the Status Bitmap. The source and destination nodes do not update the Status Bitmap. If a node detects that the Hop Count has exceeded its maximal value (24), it does not update the Status Bitmap field.¶

4. IANA Considerations

5. Security Considerations

The Transit Option, and specifically the Accumulated Delay field, which is defined in this document, may be used for reconnaissance, which in turn can facilitate other types of attacks. As in other types of Operations, Administration and Maintenance (OAM) protocols, a malicious attacker can manipulate the Accumulated Delay value in order to create a false illusion of nonexistent network issues or prevent the detection of actual ones.¶

Authors' Addresses