ICMPv6 Secure Segment Treatment Notifications
draft-pelov-icmpv6-sec-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Alexander Pelov | ||
| Last updated | 2026-06-23 | ||
| 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-pelov-icmpv6-sec-01
Network Working Group A. Pelov
Internet-Draft IMT Atlantique
Intended status: Standards Track 23 June 2026
Expires: 25 December 2026
ICMPv6 Secure Segment Treatment Notifications
draft-pelov-icmpv6-sec-01
Abstract
A packet can cross an IPv6 segment whose properties - long delay,
scheduled contacts, a strict size budget - defeat the feedback an
endpoint normally relies on. This document defines ICMPv6-SEC
(SECure Segment Treatment), an ICMPv6 message that a segment boundary
sends to a packet's source when the packet is not prepared for such a
segment. The message carries a COSE-signed Segment Descriptor: a
compact CBOR object stating which segment is meant, how long the
statement is valid, and what treatment future packets require. A
receiver applies a descriptor only after verifying the signature, the
validity window, and that the signer is authorized for the segment.
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 25 December 2026.
Copyright Notice
Copyright (c) 2026 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
Pelov Expires 25 December 2026 [Page 1]
Internet-Draft ICMPv6-SEC June 2026
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 3
4. Segment Descriptor . . . . . . . . . . . . . . . . . . . . . 5
5. Receiver Processing . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
A source sends a packet toward a destination, and the packet crosses
a constrained segment the source did not know about - a deep-space
relay, a scheduled link, an LPWAN (such as LoRaWAN) reached through a
SCHC [RFC8724] gateway, a policy-controlled region. The constraint
may be delay - at a one-way delay of minutes, end-to-end feedback
(Path MTU Discovery [RFC8201], congestion signals) arrives far too
late - or a strict size or duty-cycle budget that a packet must
already respect on entry. In either case the source needed the
segment's properties before it sent the first packet.
ICMPv6-SEC turns that silent failure into a signed, actionable
notification. When a Segment Boundary sees a packet that is not
prepared for the segment ahead, it returns one ICMPv6-SEC message to
the source carrying a Code, a quote of the packet for correlation,
and a Segment Descriptor: a COSE-signed CBOR object stating what the
segment is and what treatment future packets require (for example a
Traffic Class value, a SCHC [RFC8724] Header Format [SCHC-HDR-FMT],
or an admission token). The descriptor is signed by an operator
authority, not by the forwarding device, so the source can verify and
cache it independently of the path it took. The exchange is fast
because it does not cross the segment it describes: the boundary is
at the near edge, so the notification is a local round trip.
The pattern is not specific to interplanetary links; it applies to
any segment whose far side is a special network - a delay- or
disruption-tolerant (DTN) relay, or an LPWAN such as LoRaWAN reached
Pelov Expires 25 December 2026 [Page 2]
Internet-Draft ICMPv6-SEC June 2026
through a SCHC gateway, which filters entering traffic just as a
deep-space boundary does. In each case the boundary tells the source
the same thing: be aware that a special network lies ahead, adjust
your behaviour, and mark your traffic as prepared for it (for example
with a SCHC Header Format [SCHC-HDR-FMT] or an admission token).
ICMPv6-SEC is an exception mechanism for use in limited domains
[RFC8799] or trust federations, where operators can pre-provision
trust anchors. A source MUST operate safely when no ICMPv6-SEC
message is received; ordinary IPv6 operation remains in effect
regardless.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Segment: A portion of an IPv6 path with operational treatment
requirements.
Segment Boundary: A node that observes packets entering a Segment
and generates ICMPv6-SEC messages for packets that do not satisfy
the Segment treatment policy.
Invoking Packet: The packet that caused a Segment Boundary to
generate an ICMPv6-SEC message.
Segment Treatment Indicator: A marking, profile, or credential
indicating that traffic is prepared for a Segment - for example a
Traffic Class value, a SCHC Header Format, or an admission token.
Segment Descriptor: A COSE-signed CBOR object that identifies a
Segment and the treatment required to cross it.
Authorized Signer: An entity whose signature validates and that
local policy accepts as speaking for the described Segment or
prefix.
3. Message Format
ICMPv6-SEC is an ICMPv6 informational message (Type assigned by
IANA). It consists of the four-octet ICMPv6 header, a four-octet
fixed header (Data Length and Reserved), a Quoted Invoking Packet,
and an ICMP Extension Structure [RFC4884] containing exactly one
Segment Descriptor Object.
Pelov Expires 25 December 2026 [Page 3]
Internet-Draft ICMPv6-SEC June 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Quoted Invoking Packet (Data Length octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ICMP Extension Structure (RFC 4884) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ICMPv6-SEC Message Format
Data Length gives the length in octets of the Quoted Invoking Packet,
which MUST be zero-padded to an 8-octet boundary before the Extension
Structure and MUST include at least the IPv6 header (40 octets). The
Quoted Invoking Packet is used only for correlation and is not
authenticated. The Extension Structure MUST contain exactly one
Segment Descriptor Object (Section 4); a message with none, or more
than one, MUST be discarded. An ICMPv6-SEC message SHOULD NOT exceed
1280 octets.
+======+===========+========================================+
| Code | Name | Meaning |
+======+===========+========================================+
| 0 | Segment | The Invoking Packet lacked a required |
| | Treatment | indicator; it MAY have been forwarded. |
| | Required | Future packets without the indicated |
| | | treatment may be dropped. |
+------+-----------+----------------------------------------+
| 1 | Segment | The Invoking Packet was dropped; |
| | Treatment | future packets without the indicated |
| | Rejected | treatment will not be admitted. |
+------+-----------+----------------------------------------+
Table 1: ICMPv6-SEC Code Values
The Code is outside the COSE signature and is therefore not
authenticated. A receiver MUST NOT infer that a specific packet was
lost or delivered from the Code; loss detection remains the transport
layer's responsibility.
Pelov Expires 25 December 2026 [Page 4]
Internet-Draft ICMPv6-SEC June 2026
A Segment Boundary MAY generate ICMPv6-SEC when a packet entering a
Segment lacks a required indicator. It MUST rate-limit generation
per source address and per Segment, and MUST NOT generate ICMPv6-SEC
in response to an ICMPv6 error or another ICMPv6-SEC message, nor to
a packet with a multicast or otherwise invalid source or a multicast
destination.
4. Segment Descriptor
The Segment Descriptor is a COSE_Sign1 object [RFC9052] whose payload
is a CBOR-encoded [RFC8949] map, defined with CDDL [RFC8610] in
Figure 2 and carried as a single ICMP extension object [RFC4884]
(Class-Num TBD1, C-Type 1). An Authorized Signer creates and signs
it; the Segment Boundary carries it unmodified and SHOULD use pre-
signed descriptors.
The COSE_Sign1 MUST set alg in the protected header; signers SHOULD
use ES256 [RFC9053]. The Sig_structure external_aad MUST be the
13-octet ASCII string "ICMPv6-SEC-v1" (domain separation; not carried
on the wire). The protected header SHOULD include a key identifier.
ICMPv6SecDescriptor = {
0: uint, ; version (1)
1: bstr .size 16, ; descriptor-id
2: SegmentId, ; segment
3: Validity, ; [not-before, not-after]
4: [1* Treatment], ; required treatment
* uint => any ; future keys (IANA-registered)
}
SegmentId = {0: IPv6Prefix, ?1: tstr}
IPv6Prefix = [bstr .size 16, uint .le 128]
Validity = [#6.1(uint), #6.1(uint)] ; not-before, not-after (UTC)
Treatment = { 0: IndicatorType, ? 1: bstr }
IndicatorType = uint .le 255
Figure 2: Segment Descriptor CDDL
Receivers MUST ignore unrecognized map keys and discard descriptors
whose version is not 1. The segment MUST contain an IPv6 prefix (key
0), which is the signed anchor that binds the descriptor to traffic.
A segment name (key 1), when present, is operator metadata and MUST
NOT be used by itself to select affected traffic.
Each Treatment carries an IndicatorType (Segment Treatment Indicator
Types, Section 7) and, for the initial types defined by this
document, a required value:
Pelov Expires 25 December 2026 [Page 5]
Internet-Draft ICMPv6-SEC June 2026
* Type 0 (IPv6 Traffic Class or DSCP): the value is one octet. It
carries the IPv6 Traffic Class value; when a deployment uses only
DSCP, the DSCP is carried in the six most significant bits.
* Type 1 (SCHC Header Format): the value is an opaque identifier for
a SCHC Header Format binding or profile. The exact identifier
syntax is defined by the SCHC Header Format binding or deployment
profile.
* Type 2 (Admission Token or Credential Reference): the value is an
opaque token or credential reference whose syntax and lifecycle
are defined by the using deployment profile.
A receiver MUST ignore an indicator it does not recognize. A
receiver MUST discard a descriptor if a recognized indicator is
missing a required value or if the value length is invalid for that
indicator. Optional descriptor fields (for example expected delay,
contact windows, or a maximum packet size) are carried under keys
registered in the Segment Descriptor Keys registry (Section 7).
5. Receiver Processing
On receiving an ICMPv6-SEC message a host MUST, in order:
1. Apply base ICMPv6 checks [RFC4443]: checksum, and a valid unicast
source.
2. Discard the message if Data Length is less than 40 octets, or if
Data Length and its required padding do not leave a complete ICMP
Extension Structure.
3. Validate the ICMP Extension Structure according to [RFC4884],
including the Extension Header Version and Checksum fields;
discard the message if the structure is malformed or fails
validation.
4. Locate the single Segment Descriptor Object; discard the message
if it is absent or if more than one Segment Descriptor Object is
present.
5. Verify the COSE_Sign1 signature with external_aad = "ICMPv6-SEC-
v1". Implementations MUST support ES256. Discard if
verification fails.
6. Check the Validity window; discard if the current time is outside
it (a local clock-skew margin SHOULD be applied).
Pelov Expires 25 December 2026 [Page 6]
Internet-Draft ICMPv6-SEC June 2026
7. Verify, by local policy, that the signer is authorized for the
segment prefix. A valid signature from an unauthorized signer
MUST NOT cause any treatment change.
If all checks pass the receiver MAY apply the descriptor, anchored to
the signed prefix: it applies the treatment to traffic it sends
toward destinations the prefix covers. The Quoted Invoking Packet
MUST NOT be used to decide which traffic is affected. Performance-
affecting prior information SHOULD be treated as superseded by end-
to-end observations when those are available; for a maximum packet
size, a receiver SHOULD use the smaller of the descriptor value and a
Path MTU Discovery result [RFC8201]. Receivers SHOULD cache a valid
descriptor until the earliest of its not-after time and a locally
configured maximum lifetime.
6. Security Considerations
A valid signature is necessary but not sufficient: the receiver MUST
also verify that the signer is authorized for the segment (step 5).
The Quoted Invoking Packet and the Code are not authenticated and are
advisory only.
The Validity window bounds replay; there is no revocation, which
argues for short windows, and receivers SHOULD cap the cache lifetime
below the signed window where the context permits. A genuine
descriptor can still be replayed off-path to a host it does not apply
to; anchoring to the signed prefix and subordinating prior
information to end-to-end observations limit the damage.
ICMPv6-SEC can be a reflection/amplification vector: a Segment
Boundary MUST rate-limit generation, SHOULD keep messages within the
1280-octet minimum MTU, SHOULD NOT embed certificate chains (use pre-
provisioned trust anchors), and SHOULD restrict generation to sources
within the limited domain. Rate limits SHOULD also key on a property
the attacker cannot spoof, such as the ingress interface.
Segment Descriptors reveal operational metadata (accepted treatments,
SCHC Header Formats, schedules). Deployments SHOULD disclose only
what a receiver needs and SHOULD avoid exposing detailed policy to
unauthorized sources.
7. IANA Considerations
IANA is requested to assign a new ICMPv6 informational Type
"ICMPv6-SEC" from the "ICMPv6 Type Numbers" registry, and to create
the registries below.
Pelov Expires 25 December 2026 [Page 7]
Internet-Draft ICMPv6-SEC June 2026
ICMPv6-SEC Code Values (under the assigned Type): 0 = Segment
Treatment Required, 1 = Segment Treatment Rejected (both, This
document); 2-255 by Standards Action [RFC8126].
ICMP Extension Object: Class-Num TBD1, C-Type 1, "Segment Descriptor
Object", This document.
Segment Descriptor Keys: a registry for the integer map keys of the
descriptor (Figure 2): 0 version, 1 descriptor-id, 2 segment, 3
validity, 4 treatment (all This document). Keys 5-255 by
Specification Required [RFC8126]. A registration MUST NOT define a
key whose omission would change the meaning of the keys defined here.
Segment Treatment Indicator Types: 0 = IPv6 Traffic Class or DSCP
[RFC2474]; 1 = SCHC Header Format [SCHC-HDR-FMT]; 2 = Admission Token
or Credential Reference (all This document). Values 3-255 by
Specification Required [RFC8126]; a registration MUST state whether
the value field is required and what it carries.
8. References
8.1. Normative References
[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>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<https://www.rfc-editor.org/info/rfc4884>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Pelov Expires 25 December 2026 [Page 8]
Internet-Draft ICMPv6-SEC June 2026
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
8.2. Informative References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[SCHC-HDR-FMT]
Pelov, A., "SCHC Header Format", Work in Progress,
Internet-Draft, draft-pelov-schc-header-format-00, 2026,
<https://datatracker.ietf.org/doc/draft-pelov-schc-header-
format/>.
Pelov Expires 25 December 2026 [Page 9]
Internet-Draft ICMPv6-SEC June 2026
Acknowledgements
The author thanks contributors discussing ICMPv6, SCHC, COSE, and the
SCHC Header Format for the observations that shaped this revision.
Author's Address
Alexander Pelov
IMT Atlantique
2bis rue de la Chataigneraie
35536 Cesson-Sevigne
France
Email: alexander.pelov@imt-atlantique.fr
Pelov Expires 25 December 2026 [Page 10]