Common Option Format for Host-Network Signaling
draft-herbert-hnsigopt-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tom Herbert | ||
| Last updated | 2024-03-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-herbert-hnsigopt-00
Network Working Group T. Herbert
Internet-Draft SiPanda
Intended status: Standards Track 20 March 2024
Expires: 21 September 2024
Common Option Format for Host-Network Signaling
draft-herbert-hnsigopt-00
Abstract
This specification describes an option format for Hop-by-Hop and
Destination Options for host-net signaling (host to network and
network to host signaling). The format supports a uniform mechanism
for sending signals and reflecting received signals back to an
originating sender. While this document describes a format for IPv6
Hop-by-Hop options or Destination options, the base format for
carrying signals is generic and could be the payload of other options
mechanisms such as UDP Options or Geneve options.
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 21 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Herbert Expires 21 September 2024 [Page 1]
Internet-Draft HNSIGOPT March 2024
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol format . . . . . . . . . . . . . . . . . . . . . . . 4
3. Reflection properties . . . . . . . . . . . . . . . . . . . . 5
3.1. Don't reflect . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Actionable in the forward path and return path . . . . . 6
3.3. Forward path actionable, return path not actionable . . . 6
3.4. Forward path not actionable, return path actionable . . . 7
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Sender operation . . . . . . . . . . . . . . . . . . . . 7
4.2. Intermediate node operation . . . . . . . . . . . . . . . 7
4.3. Receiver operation . . . . . . . . . . . . . . . . . . . 8
4.3.1. Receiving a don't reflect option . . . . . . . . . . 8
4.3.2. Receiving an option to be reflected . . . . . . . . . 8
4.3.3. Reflecting signals . . . . . . . . . . . . . . . . . 8
4.3.4. Receiving a reflected signal . . . . . . . . . . . . 9
5. Implementation Considerations for Reflection . . . . . . . . 9
5.1. Reflection with TCP . . . . . . . . . . . . . . . . . . . 9
5.2. Reflection with UDP . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
This specification describes a simple and extensible option format
for in-situ signaling between hosts and the network. The format is
applicable to host to network as well as network to host signaling,
and we refer to the union of both use cases as "host-net signaling".
Herbert Expires 21 September 2024 [Page 2]
Internet-Draft HNSIGOPT March 2024
Signaling has two facets: "signal carrier" and "signal content".
This specification focuses on creating a common carrier format for
host-net signaling. The format must be extensible to support use
cases for different types of host-net signal content.
Host-net signals are expressed in IPv6 Hop-by-Hop or Destination
Options before the Routing Header [RFC8200]. A sender may
"piggyback" host-net signals on application packets using these
options. Host to network signals are not modified by intermediate
nodes and so use an "unmodifiable" option type (the third high order
bit in the type is zero). Network to host signals are modified by
intermediate nodes and therefore use a "modifiable" option type (the
third high order bit in the type is one).
A common technique of signaling is for a receiver to "reflect" the
signal back to the host. We refer to path from a sender to a
receiver as the "forward path" of a signal, and the reverse path from
the receiver to the sender as the "return path". A non-reflected
signal is sent on the forward path, and a reflected signal is sent on
the return path.
When signal reflection is used, the signal sent on the forward path
or return path may be "actionable" or "not actionable". An
actionable signal is one that is processed by on-path elements, a
non-actionable signal is ignored by on-path elements. The purpose of
non-actionable signals is to transport a signal without
interpretation by intermediate nodes. For instance, in the case of
IOAM a non-actionable signal is reflected to report the telemetry
gathered in the forward path.
Actionable signals are carried in Hop-by-Hop Options or Destination
Options before the Routing Header. Hop-by-Hop Options are used to
signal all on-path elements, and Destination Options before the
Routing Header are used to signal intermediate destinations in a
Routing Header. Non-actionable signals are carried in Destination
Options after the Routing Header (or just Destination Options if
there is no Routing Header in the packet).
1.1. Related work
There have been a number of proposals for Hop-by-Hop and Destination
Options formats for both host to network and network to host
signaling. [I-D.eckert-6man-qos-exthdr-discuss] proposes a common
option format for QoS as a form of host to network signaling.
[I-D.shi-ippm-congestion-measurement-ipv6-options] proposes a common
format for congestion measurement as a form of network to host
signaling. [I-D.herbert-fast] proposes a format for a Hop-by-Hop
option to carry Firewall and Service Tickets as a form of host to
Herbert Expires 21 September 2024 [Page 3]
Internet-Draft HNSIGOPT March 2024
network signaling.
In this draft, we consolidate the ideas of previous work into one
general proposal for conveying host to network and network to host
signaling. The format should be compatible with all proposed use
cases of host-net signaling, and includes procedures and protocol for
reflecting signals.
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Protocol format
Host-net signals may be carried in Hop-by-Hop or Destination options.
We refer to an option for carrying a signal as a "signal option".
The base format of a signal option is a single byte composed of a Pr
field and a Type field. The Pr fields indicates the reflection
properties of the signal as discussed in Section 3. The Type field
indicates the type and format of the payload following the first byte
The format of this byte is shown below:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Pr | Type |
+-+-+-+-+-+-+-+-+
The format of a signal option in a Hop-by-Hop or Destination option
is illustrated below:
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 |Pr| Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
* Option Type=0xf [TBD]: Type of Hop-by-Hop or the Destination
Herbert Expires 21 September 2024 [Page 4]
Internet-Draft HNSIGOPT March 2024
option. Two option types are requested, one with third high order
bit set to indicate that the option is modifiable en route (i.e.
it is a network to host signal), and one type where the third high
order bit is not set to indicate that the option is not modifiable
en route (i.e. it is a host to network signal). The high order
two bits of the option type are 00 to indicate that an unknown
option should be skipped and no ICMP error is sent.
* Opt Data Len: Length of the option data field. The option data is
comprised the Pr-Type byte, and the Data.
* Pr: Indicates properties of the signal option for reflection and
path processing. Handling of the reflection property is described
in Section 3. Possible values are:
0: Don't reflect
1: Reflect as actionable
2: Reflect as non-actionable
3: Reflected
* Type: Type of the host-net signal. This field determines the
format of the following payload in the option
* Data: The signal content. The format is indicated by the Type
field
3. Reflection properties
There are four basic reflection properties of signal options:
* Don't reflect
* Actionable in the forward path and return path
* Forward path actionable, return path not actionable
* Forward path not actionable, return path actionable
3.1. Don't reflect
A signal option with this property is sent in Hop-by-Hop Options or
Destination Options before a Routing Header with Pr set to 0 (Don't
reflect). Intermediate nodes may process the option. At a receiver,
the signal option is not reflected.
Herbert Expires 21 September 2024 [Page 5]
Internet-Draft HNSIGOPT March 2024
Signal options with this property are uni-directional signals that
are always actionable in the forward path. This property is useful
in host to network signaling to affect the forward path of
communications, for instance to request QoS or other services in the
forward path of a flow.
3.2. Actionable in the forward path and return path
A signal option with this property is sent in Hop-by-Hop Options or
Destination Options before a Routing Header with Pr set to 1 (Reflect
as actionable). Intermediate nodes may process the option in the
forward path. At a receiver, the option is reflected in Hop-by-Hop
Options or Destination Options before a Routing Header and
intermediate nodes may process the reflected option in the return
path.
When an option with this property is reflected by a receivers, it is
sent in a Hop-by-Hop Options or Destination Options before the
Routing Header. If the original signal option was received in a Hop-
by-Hop option, then it is reflected in a Hop-by-Hop option. If the
original signal was received in Destination Options before the
Routing Header then the signal is reflected in Destination Options
before the Routing Header, except if packets sent on the return path
don't contain a Routing Header in which case the signal option is not
reflected.
Signal options with this property are useful in host to network
signaling to affect both directions of communications, for instance
to request that the same QoS be applied bidirectionally. They may
also be useful in network to host signaling to gather telemetry for
both directions of a communication in the same option.
3.3. Forward path actionable, return path not actionable
A signal option with this property is sent in Hop-by-Hop Options or
Destination Options before a Routing Header with Pr set to 2 (Reflect
as non-actionable). Intermediate nodes may process the option in the
forward path. At a receiver, the option is reflected in Destination
Options after the Routing Header and intermediate nodes do not
process the reflected option in the return path.
When the option is reflected by a receivers, it is sent in
Destination Options after the Routing Header or just Destination
Options if there is no Routing Header being sent in the packet.
Herbert Expires 21 September 2024 [Page 6]
Internet-Draft HNSIGOPT March 2024
Signal options with this property are useful in network to host
signaling to return information gathered in the forward path, for
instance an IOAM option might be reflected to report telemetry
collected from routers in the forward path.
3.4. Forward path not actionable, return path actionable
A signal option with this property is sent in Destination Options
after the Routing Header with Pr set to 1 (Reflect as actionable).
Intermediate nodes do not process the option in the forward path. At
a receiver, the option is reflected in Hop-by-Hop Options and
intermediate nodes may process the reflected option in the return
path.
When the option is reflected by a receivers, it is sent in Hop-by-Hop
Options. Note that there is no means to request that a signal option
is not actionable in the forward path and should be reflected in
Destination Options before the Routing Header (this mode does not
seem particularly useful).
Signal options with this property are useful in network to host
signaling to gather information in the return path, for instance an
IOAM option might be reflected to gather telemetry in the forward
path. The property may also be used in host to network signaling to
affect only the return path of communications, for instance to
request QoS or other services only for the return path of a flow.
4. Operation
4.1. Sender operation
A sender MAY include one or more signal options in a packet. A
sender SHOULD apply extension header limits in
[I-D.ietf-6man-eh-limits]. If a sender includes more than one
actionable signal option in a packet, it SHOULD order them in
decreasing order of importance [I-D.ietf-6man-hbh-processing]. A
sender SHOULD send at most one signal option for each type and
reflection property.
4.2. Intermediate node operation
An intermediate node MAY process actionable signal options it
receives. These are signal options in Hop-by-Hop Options or signal
options in Destination Options before the Routing Header at an
intermediate destination in the Routing Header. An intermediate node
may apply applicable processing limits in [I-D.ietf-6man-eh-limits].
Herbert Expires 21 September 2024 [Page 7]
Internet-Draft HNSIGOPT March 2024
If an intermediate node recognizes the Type in the signal option then
it MAY process the option and take appropriate action. If an
intermediate node does not recognize the Type then it should skip the
rest of the option and continue processing the header.
4.3. Receiver operation
4.3.1. Receiving a don't reflect option
If a receiver receives a signal option with Pr field set to 0 (Don't
reflect) then the receiver MAY process the option as part of receive
option processing but otherwise SHOULD ignore the signal option.
4.3.2. Receiving an option to be reflected
If a receiver receives a signal option with Pr field set to 1
(Reflect as actionable) or 2 (Reflect as non-actionable) then the
receiver SHOULD save the option in the state context of the
corresponding flow to subsequently reflect it in packets sent on the
return path. A receiver SHOULD also note if the option was received
in Destination Options before the Routing Header or not. If the
option is actionable, that is the option was in Hop-by-Hop Options or
Destination Options before the routing header, then the receiver MAY
process the option as part of receive processing.
4.3.3. Reflecting signals
If a signal option was saved in the context for a flow to be
reflected then the reflected option is included when packets are sent
in the return path of the option. A host does this by creating a
signal option per properties of the original received signal.
If the reflection property of the original signal option is "Forward
path not actionable, return path actionable" then the signal option
is reflected in Destination Options after the Routing header or just
Destination Options if there is no Routing Header in the packet being
sent.
If the reflection property of the original signal is "Actionable in
the forward path and return path" or "Forward path not actionable,
return path actionable" then the signal is reflected depending on how
it was received:
* If the original signal was not received in Destination Options
before the Routing Header then it is reflected in Hop-by-Hop
Options.
* If the original signal was received in Destination Options before
Herbert Expires 21 September 2024 [Page 8]
Internet-Draft HNSIGOPT March 2024
the Routing Header then it is reflected in Destination Options
before the Routing Header only if the packet would otherwise
contain a Routing Header. If the packet being sent does not
contain a Routing Header then the signal option is not reflected.
When a host sends a reflected signal option it MUST set the Pr to 3
(Reflected signal). A host SHOULD continue to reflect the saved
signal until a different signal to be reflected with the same type is
received from the peer for the flow, or a packet is received that
doesn't contain a signal of the same type to be reflected. Note that
reflection is optional at a receiver, and a receiver MAY reflect one
or more signal options for the same flow. A receiver MAY choose to
only save one signal option to reflect per flow, and in the case that
more than one option is received to be reflected a receiver SHOULD
save only the first found signal option to be reflected in the flow's
context.
Note that a receiver can reflect a signal option even if it doesn't
recognize its Type.
4.3.4. Receiving a reflected signal
When a host receives a reflected signal it MAY process it. In the
case of a network to host signal the contents MAY be consumed by the
application. For instance, if the signal indicates a report of
router congestion in forward path, the host may adjust congestion
avoidance algorithms for the flow.
5. Implementation Considerations for Reflection
5.1. Reflection with TCP
When a TCP packet is received with a signal option to be reflected,
the option is saved in the TCP Protocol Control Block (or PCB) for
the connection. When a TCP packet is sent, the saved signal option
in the PCB is checked. If there is a saved option then it is
included in the packet per the requirements of Section 3.
If a TCP packet is received that is different from the currently
saved option, then the new option overwrites the saved option. Note
that this is done without respect to the transport layer ordering.
For instance a signal option may reflected that does not reflect the
the signal option received with the greatest TCP sequence number
(this can happen when a sender retransmits a packet that has a
different signal option that a packet that was sent with a larger
sequence number).
Herbert Expires 21 September 2024 [Page 9]
Internet-Draft HNSIGOPT March 2024
5.2. Reflection with UDP
When a UDP packet is received with a signal option to be reflected,
the option would normally be passed the application. In the sockets
API this could be done via ancillary data in the recvmsg function.
The application could save the signal option in its context for the
flow, and when sending on the flow it includes a signal option if one
has been saved.
6. Security Considerations
Signal reflection introduces a potential security risk for
amplification or spoofing attacks. In its nature, signal reflection
is best effort, so it can be suppressed to mitigate the risks. Also,
since signal reflection is stateful, the state itself could be used
to mitigate the risk. For instance, for a TCP connection signal
reflection might only be allowed in Established state. Furthermore
the peer that sent a signal option could be considered, for instance
if the peer address is in the same limited domain as the receiver
then that is a good indicator that it is safe to reflect a signal
option.
7. IANA Considerations
IANA is requested to assign the following Hop-By-Hop and Destination
options for signal options:
+-----------+---------------+-------------+---------------+
| Hex Value | Binary value | Description | Reference |
| | act chg rest | | |
+-----------+---------------+-------------+---------------+
| 0x0F [TBD]| 00 0 01111 | Unmodifiable| This document |
| | | signal | |
| | | option | |
+-----------+---------------+-------------+---------------+
| 0x0F [TBD]| 00 1 01111 | Modifiable | This document |
| | | signal | |
| | | option | |
+-----------+---------------+-------------+---------------+
IANA is requested to set up a registry for the reflection property
(Pr) of signal options. This is a 2 bit value:
Herbert Expires 21 September 2024 [Page 10]
Internet-Draft HNSIGOPT March 2024
+----------------+----------------------+---------------+
| Ticket property| Description | Reference |
+----------------+----------------------+---------------+
| 0x0 | Don't reflect | This document |
+----------------+----------------------+---------------+
| 0x1 | Reflect as | This document |
| | actionable | |
+----------------+----------------------+---------------+
| 0x2 | Reflect as | This document |
| | not actionable | |
+----------------+----------------------+---------------+
| 0x3 | Reflected | This document |
+----------------+----------------------+---------------+
IANA is requested to set up a registry for the Signal Option Type.
These are 6 bit values. Values 0 to 0x3b are reserved for assignment
via Standards Action [RFC8126]. Values 0x3c to 0x3f are for
experimentation or private use.
+----------------+--------------------+---------------+
| Ticket type | Description | Reference |
+----------------+--------------------+---------------+
| 0x0-0x3b | Assignable | This document |
+----------------+--------------------+---------------+
| 0x3c-0x3f | Private use | This document |
+----------------+--------------------+---------------+
8. References
8.1. Normative References
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References
[I-D.eckert-6man-qos-exthdr-discuss]
Eckert, T. T., Joung, J., Peng, S., and X. Geng,
"Considerations for common QoS IPv6 extension header(s)",
Work in Progress, Internet-Draft, draft-eckert-6man-qos-
exthdr-discuss-00, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-eckert-6man-
qos-exthdr-discuss-00>.
Herbert Expires 21 September 2024 [Page 11]
Internet-Draft HNSIGOPT March 2024
[I-D.herbert-fast]
Herbert, T., "Firewall and Service Tickets", Work in
Progress, Internet-Draft, draft-herbert-fast-07, 7 October
2023, <https://datatracker.ietf.org/doc/html/draft-
herbert-fast-07>.
[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-12, 18 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-12>.
[I-D.ietf-6man-hbh-processing]
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-14, 25 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-14>.
[I-D.shi-ippm-congestion-measurement-ipv6-options]
Shi, H., Zhou, T., Ying, and M. Han, "IPv6 Options for
Congestion Measurement", Work in Progress, Internet-Draft,
draft-shi-ippm-congestion-measurement-ipv6-options-00, 3
March 2024, <https://datatracker.ietf.org/doc/html/draft-
shi-ippm-congestion-measurement-ipv6-options-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Author's Address
Tom Herbert
SiPanda
Santa Clara, CA,
United States of America
Email: tom@herbertland.com
Herbert Expires 21 September 2024 [Page 12]