]> Aalyria Technologies, Inc.

ek.ietf@gmail.com

INT IP enclave delay/disruption links ICMP ICMPv4 ICMPv6 This document defines optional ICMP extension objects that a gateway at the boundary between an IP enclave and a managed constrained long-haul link, such as a scheduled deep-space link, can attach to existing Destination Unreachable messages. On the unreachable errors generated when an admitted packet cannot be forwarded because the required link is presently unusable, the objects convey the expected time until the link becomes usable, the time the estimate was generated, and the expected one-way delay of the link. On the administrative prohibition errors generated when the link's admission policy refuses a packet, a presence-only object identifies boundary-link admission policy as the source of the refusal. The underlying codes retain their existing meanings, and this document requests no new ICMP type or code. It specifies when the objects may be attached and what they convey, not how transports, applications, or hosts react to them; making the boundary's knowledge available to senders is intended to enable experimentation with such reactions. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the INTAREA Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Some IP enclaves are connected to the rest of a network only by constrained long-haul links that are high-delay, periodically disrupted, or both: deep-space links, satellite links available only during scheduled passes, periodic store-and-forward contacts. An administrative domain, or a set of cooperating domains, manages those links: it knows from a contact plan or equivalent scheduling knowledge when each link is expected to carry traffic, it enforces an admission policy describing whose traffic each link will carry, and it can distribute routing updates to migrate long-haul traffic onto the best current or next link according to its policy. An IP sender inside such an enclave may lack this knowledge. Ordinary errors do not communicate the managed service's recovery estimate or identify boundary-link admission as the source of a policy refusal. Existing Destination Unreachable messages already report the forwarding failures that result. This document defines optional ICMP extension objects that let a gateway in such a domain supply additional information on those messages. On the unreachable errors generated when an admitted packet cannot be forwarded because the required link is presently unusable, the gateway may attach the time at which it generated the message, its estimate of the time until the link becomes usable, and the approximate one-way delay of the link. On the administrative prohibition errors generated when the link's admission policy refuses a packet, it may attach a presence-only object indicating that boundary-link admission policy, rather than some other administrative control, was the source of the refusal. The underlying code retains its existing meaning in every case (). This document specifies the network-layer signals: when a gateway may attach each object, what each asserts, and its encoding. It does not specify how a transport, application, host cache, provisioning system, or orchestrator reacts to them. Such reactions are not required for interoperability, and they are not merely out of scope: a purpose of publishing the objects is to enable experimentation with them (, ). The availability metadata is useful because the boundary is close and the condition is long-lived: gateway feedback reaches senders in local round-trip times, while the unavailability it reports lasts minutes to hours (). The policy indication is useful for a different reason: it identifies the source of the refusal and may prompt an application to reconsider its configured communication options. It does not establish that a change will succeed or that policy cannot change over time. Where an application can learn in advance which communication mechanisms suit a destination -- through configuration, provisioning, DNS, or orchestration -- selecting an appropriate mechanism before initiating unsuitable IP communication is preferable to discovering the condition reactively. Such discovery and selection mechanisms are out of scope for this document, which addresses only what a gateway reports once a packet has been sent.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Enclave:

an IP network whose connectivity to other networks passes over one or more managed constrained long-haul links.

Constrained long-haul link:

a link connecting enclaves whose usability is high-delay, scheduled, intermittent, or otherwise restricted according to knowledge held by the managing domain, and whose use is governed by admission policy. Ordinary transient interface or carrier failure does not by itself make a link a managed constrained long-haul link ().

Managed service:

the domain's knowledge that a particular constrained long-haul link, or a sequence of link opportunities, is intended to carry particular traffic, together with the associated schedule, admission policy, and forwarding state. A managed service may exist while no route to its destination is currently installed.

Orchestration function:

the logical function, possibly distributed across cooperating administrative domains and not necessarily continuously reachable, that manages the constrained long-haul links, distributes routing and policy updates for them, and supplies gateways with the knowledge on which the objects in this document are based.

Contact:

an interval during which a constrained long-haul link is planned to carry traffic between a gateway and its remote counterpart.

Contact plan:

the schedule of contacts for a link or set of links, distributed to gateways in advance of execution. A contact plan is one form of managed-service knowledge, not the only one.

Gateway:

the router at the boundary between an enclave and a constrained long-haul link, holding the managed-service knowledge for that link and attaching the objects defined in this document.

Coordination scope:

the set of links, routes, and admission policies under the same orchestration function, whose current state a gateway's assertions describe.

Disclosure scope:

the administrative boundary within which the objects are generated and within which their contents are considered appropriate to reveal. It is at most the coordination scope and may be narrower.

Trans-boundary traffic:

traffic whose path crosses a gateway onto a constrained long-haul link.

Admission:

a gateway's determination, against local policy, that particular traffic may use a constrained long-haul link.

Link Condition Object:

an ICMP extension object of the class defined in , carrying constrained long-haul link metadata on a Destination Unreachable message.

Carrier code:

an existing Destination Unreachable code on which one or more Link Condition Objects may be carried ().

Expected Time Until Link Usability (ETU):

the gateway's estimate, at generation of a notification, of the interval from generation until the relevant constrained long-haul link is expected to become usable for forwarding ().

Enclave time reference:

the shared time reference, established by the specification or provisioning of the managed deployment, against which Generation Time is expressed (). Its time scale, epoch, and discontinuity treatment are deployment choices, not protocol prerequisites; UTC is one permitted choice.

Applicability The mechanisms in this document apply to deployments in which one or more constrained long-haul links connect IP enclaves, and in which the links, the routes over them, and the admission policies governing them are managed by a common orchestration function. When several long-haul options exist for the same traffic, this document assumes they participate in the same logical orchestration. This does not require a single physical controller, a particular routing protocol, or continuous connectivity between gateways and the controller (). The objects are specified for use under a single administrative authority or cooperating authorities sharing the coordination and disclosure scopes defined below. provides broader context on limited-domain deployments. Three relationships need to be kept distinct. The first is the timing relationship between a notifying gateway and the senders it notifies. Let R be the round-trip time between a sender and the gateway, D the duration of a link unavailability being reported, and T the timescale on which the sender's transport would otherwise detect failure. Availability metadata is useful when R is small relative to T, so the notification arrives while the sender still has options, and small relative to D, so the reported condition is still in effect on arrival. In the Mars enclave of , R is milliseconds to seconds, T is seconds to minutes, and D is minutes to hours. When R approaches D, a notification describes a link state that may no longer exist on arrival; gateways therefore attach objects only into their local enclave and never across the constrained long-haul link. This timing argument is specific to availability metadata; a policy refusal applies regardless of current link usability and needs no predicted outage to be worth reporting. The second is the coordination scope: the set of links, routes, and policies whose current state the gateway's assertions describe. A gateway's assertions are about the applicable, current managed service and forwarding state for the affected traffic within this scope, not about every path that could ever exist, unprovisioned routes, unrelated domains, or application-layer alternatives. Equally, the failure of one local link is not a basis for an assertion when the current managed forwarding state provides a usable, policy-permitted alternative for that traffic. The third is the disclosure scope: the administrative boundary within which the objects are generated and considered appropriate to reveal. Cooperating domains must agree on both scopes; their agreement does not authenticate ICMP (), and a short local round-trip time does not by itself make a network part of either scope. For comparison of timescales only, the public Internet has sub-second internal round-trip times relative to a link whose unavailability is measured in minutes, but it is not thereby a cooperating or trusted signaling domain. The objects apply only to links whose availability and admission the domain deliberately manages as a long-haul service. A gateway attaches availability metadata on the basis of managed-service knowledge about the link, never on the basis of observed local carrier or interface state alone; a router that merely notices its outgoing interface is down generates whatever error ordinary ICMP rules call for and has no basis to attach Link Condition Objects to it. How the domain acquires and distributes its knowledge is not specified; the objects encode what the gateway is entitled to assert, not how it learned it. The same criteria identify deployments beyond the interplanetary case, wherever a domain manages scheduled or intermittently available links between enclaves on the basis of advance knowledge. Conversely, the mechanism offers nothing on paths that are merely lossy or congested, and high delay alone is not a reason to generate a Destination Unreachable error when forwarding is possible.

Concept of Operations This section is informative. It describes a representative deployment: an IP-based enclave in Mars orbit and on the Martian surface, connected to terrestrial networks through scheduled deep-space contacts. Host and application behaviors described here are illustrations of what the signals make possible, not requirements ().

Reference Scenario The enclave consists of surface assets and orbiters interconnected by conventional IP links, with propagation delays of milliseconds to low seconds and continuous or near-continuous connectivity. Standard IP routing and transports operate normally within it. The enclave connects to Earth through gateway nodes on relay orbiters equipped with deep-space links. These links are scheduled: contacts with ground stations occur in windows determined by orbital geometry and antenna allocation, known in advance through a contact plan. They are high-delay: one-way light time to Earth is roughly 3 to 22 minutes. And they are policy-managed: contact capacity is allocated to specific senders or traffic classes, and traffic outside those allocations is not authorized to use the link. A gateway may also offer a Bundle Protocol version 7 or application-layer gateway service that accepts traffic under its own policy. The ICMP cases here concern packets refused or not forwarded by the IP forwarding service; they do not describe traffic accepted for delivery by a separate service. BP is not required for this ICMP mechanism. The same structure exists on the Earth side. A terrestrial sender's traffic crosses an Earth-side gateway that holds the same contact plan and enforces its own admission policy, and that gateway generates the same signals toward terrestrial senders. This section describes the Mars side for concreteness.

Roles Enclave hosts originate and receive application traffic. Some are DTN-aware, running a BP agent or a stack extension that can hand traffic to one; others are unmodified IP hosts, including legacy instruments and commercial payloads whose stacks predate this specification. Where a performance-enhancing proxy (PEP) terminates transport sessions on behalf of such hosts, the PEP can consume these signals for them, so that the mechanism's benefit need not depend on universal host adoption. Gateways hold the managed-service knowledge for their deep-space links, enforce admission and precedence policy on contact capacity, and attach the objects defined in this document: availability metadata on the unreachable error generated when admitted trans-boundary traffic arrives while the link is not usable, and the Denied by Link Policy object on the administrative prohibition error generated when traffic arrives that policy does not admit. An orchestration function, which may be Earth-based, distributes contact plans, routing updates, and admission policy to gateways in advance (). It is intended to steer trans-boundary traffic toward whichever gateway and link can serve it. Routing, link, and policy updates are not installed atomically, however, and distribution itself crosses the deep-space link; during transitions, or when plan and reality diverge, a gateway may receive traffic that another gateway could have served. Gateways operate autonomously between management contacts on their most recent applicable knowledge and omit assertions they cannot currently support (). Intra-enclave traffic is unaffected; hosts that never originate trans-boundary traffic need not implement the objects.

Orchestration Example This subsection illustrates one feasible path by which a gateway obtains the knowledge on which it bases the objects. It describes conceptual information, not a management protocol, data model, or scheduling algorithm; any existing management channel, controller interface, or local provisioning may carry it. Times in this example are expressed in the enclave time reference () as seconds from its epoch; the deployment has chosen the reference, and nothing here depends on which one. The orchestration function determines that traffic for a terrestrial destination prefix should, for an upcoming period, leave the enclave via a particular relay orbiter's deep-space link, whose next contact begins at reference time 12,400 s. Allowing for antenna pointing, acquisition, and modem configuration, it expects the link to be ready to forward traffic at reference time 12,520 s, and it estimates the one-way delay over the link at that time as 20 minutes. It installs or schedules the routing and admission policy needed for that link, and it supplies the gateway with an associated record containing at least:

• the traffic-to-service binding: the destination prefix and the routing or policy context to which the record applies, associated with the relevant link or next managed opportunity;
• a revision identifier or equivalent coherence mechanism, an applicability period, and validity or expiry information;
• optionally, the expected data-plane-ready time, or a duration with an explicit reference time;
• optionally, a directional one-way link-delay estimate applicable to that opportunity; and
• the admission and disclosure policy that applies, together with whatever local evidence the gateway has about the link's actual usability.

Delivering this record is only part of the implementation. The gateway's error-generation path must be able to consult it when forwarding fails, including when the route to the destination has been withdrawn between contacts and the failure is reported as a no-route error. Any absolute time the controller supplies must either be expressed in, or come with a known conversion into, the gateway's enclave time reference (); alternatively the controller may supply a duration anchored to a reference time the gateway can interpret. A readiness time the gateway cannot relate to its own reference is not a basis for ETU. At reference time 10,000 s, a packet for the prefix arrives at the gateway. No usable route exists, so ordinary rules produce a Destination Unreachable error. The gateway consults its record, finds it current and applicable, confirms the traffic is admitted, and attaches Generation Time (10,000 s), ETU (the interval from 10,000 s to 12,520 s, 2,520,000 ms), and Expected Link Delay (1,200,000 ms). Generation Time is the time the ICMP message was generated, not the time the orchestrator created or distributed the plan. Several operational cases follow from this model, and draws the corresponding lessons:

• A later plan revision selects a different link or changes the readiness estimate. Subsequent notifications use the current applicable information; earlier notifications cannot be recalled.
• The planned readiness time passes but acquisition fails. The gateway does not continue reporting a countdown clamped to zero; it either has a newly supported estimate, or it omits ETU. An Expected Link Delay that remains valid for the selected link need not be omitted.
• Controller connectivity is lost. A still-valid local record remains usable unless contradicted by local evidence; when it expires or becomes incoherent, the basis for the affected objects is gone and they are omitted. Ordinary errors continue to be generated.
• Routing state and metadata revisions temporarily disagree, for instance when a route has migrated to a second gateway but the first gateway's record has not yet been updated. The gateway omits assertions it cannot support rather than describing a service opportunity other than the one applicable to the traffic.

Use Cases

Traffic Sent While the Link Is Unusable A surface host begins a bulk transfer toward Earth between contacts. The first packet reaches the gateway, which drops it and returns a Destination Unreachable error carrying an Expected Time Until Link Usability object. From the object, the host knows that the domain regards the path as transiently unavailable and roughly how long that is expected to last; from the bare error alone it would know only that the packet was not delivered. It might use the metadata to avoid repeated attempts that would elicit the same error, and to tell the application that the path is deferred rather than failed ().

Reconsidering the Communication Mechanism An application that learns, from a Link Condition Object, that its present IP traffic will be deferred for a long interval or was refused by boundary-link admission policy may reconsider its end-to-end communication options. A DTN-aware host might hand the affected traffic to its local BP agent, which originates bundles toward the destination for forwarding during the next contact. An application with separately provisioned knowledge of an authorized application-layer gateway might direct its traffic there. An application with its own delay tolerance might instead compare the expected wait against that tolerance and fail fast. The object is a trigger to reconsider, not a description of the alternatives. Configuration, discovery, or provisioning supplies the alternative mechanism and its authorization; the object does not prove that another mechanism exists, is admitted, or will succeed, and it does not require the application to change anything.

Traffic Denied by Link Policy A misconfigured or newly integrated payload host sends best-effort traffic toward Earth during a contact whose capacity is allocated to command and telemetry classes. The gateway classifies the traffic against its local policy, which may consider DSCP, addresses, protocol and port, or any other criteria, and drops it. Ordinary rules and local response policy call for a Destination Unreachable, Communication Administratively Prohibited error; the gateway attaches the Denied by Link Policy object to it. From the object, the host learns that the refusal came from the admission policy of the long-haul service rather than from some other administrative control such as a firewall; from the bare error it would know only that communication was administratively prohibited. The object does not say why the traffic was refused or what traffic would be admitted: admission policy is multidimensional and local, and coaching senders on acceptable markings would invert an admission model in which access is granted through the control plane. The operator debugging the flow consults the gateway's own logs and counters (); obtaining admission is a provisioning action. The application may reconsider its communication mechanism (). A flow that policy admitted at contact start and later displaces in favor of higher-precedence traffic falls under the same object. Whether an implementation regards this internally as preemption, resource allocation, or precedence enforcement is a matter of local policy; the sender learns only that the traffic is not presently admitted.

Plan/Reality Divergence Notifications that conflict with the currently applicable service expectation can be evidence of divergence between the control plane's model and the data plane's state. Examples include ETU or ELD reporting unavailability after expected data-plane readiness, or a Denied by Link Policy object for traffic that installed policy should admit. A planned contact alone does not establish readiness: preparation may continue after contact start (). Authorized traffic between contacts can legitimately elicit availability metadata. Gateway counters provide diagnostic evidence, not proof of failure ().

Interaction of the Two Signals The availability metadata and the Denied by Link Policy object answer different questions and may both be relevant to one flow over time: a link can be simultaneously restricted and unavailable. Admission is evaluated first (). Traffic that would be refused regardless of link state receives the administrative prohibition error, optionally with the Denied by Link Policy object. ETU and ELD are excluded as specified in . Generation Time without ETU remains discouraged, not prohibited. Traffic that is admitted but whose link is not presently usable receives the ordinary unreachable error, optionally with availability metadata. A sender whose denial is resolved through provisioning may then receive a metadata-bearing unreachable error for the same flow: first become admissible, then wait for the link. Ordinary Destination Unreachable errors do not by themselves establish that service is permanently absent; notes that they can result from routing transients, and has previously used them experimentally as indications of connectivity disruption. Nor does an ordinary administrative prohibition error identify which administrative control refused the packet. ETU or ELD adds to an unreachable error the domain's assertion that the failure reflects a managed transient condition of a constrained long-haul link to which the traffic was admitted; ETU also estimates its duration. Generation Time alone does not assert a failure cause. The Denied by Link Policy object adds to an administrative prohibition error the assertion that boundary-link admission policy was the source of the refusal.

Message Formats and Extension Objects This section is normative. The Link Condition Object class is shown as TBD5 pending IANA assignment (); prior to assignment, experiments use a locally coordinated Private Use class as described in . The carrier codes of are already assigned, and this document requests no new ICMP type or code.

Common Message Format The objects are carried in Destination Unreachable messages: ICMPv6 Type 1 and ICMPv4 Type 3 . already permits an ICMP Extension Structure on the existing Destination Unreachable message types of both IP versions; no new type or code is needed to carry the objects defined here. The message layout is the extended Destination Unreachable message of ; this document adds no fields. The Length field, original-datagram truncation and padding, extension header, and checksum rules follow and . Attaching extension objects to Destination Unreachable is an established pattern (, , ).

Extended Destination Unreachable (ICMPv6 layout shown; ICMPv4 places Length in the second octet of the second word)

The objects add to a Destination Unreachable message; they never change what its code means. A message that carries no Link Condition Objects, whether because the gateway attached none or because the receiver ignores or does not process extensions, is an ordinary Destination Unreachable message and means only what its code has always meant. Absence of an object supplies no inference: it does not indicate that admission succeeded or failed, that a constrained long-haul link was or was not involved, or that any prediction exists. A message carrying no objects defined here need not carry an extension structure at all, and an extension structure, when present, may also carry other independently applicable objects. Recognition of a carrier code implies nothing about extension support; the extension structure lies beyond the portion of the original datagram that extension-unaware receivers examine. A receiver that processes extensions MUST ignore Link Condition Objects with an unrecognized C-Type, and MUST process at most one object of each C-Type per message, taking the first if several are present. A receiver MUST ignore a Link Condition Object that is not applicable to the received Destination Unreachable code (), and MUST ignore a Link Condition Object whose Length is not valid for its C-Type (). An unrecognized, inapplicable, or invalid-length Link Condition Object does not by itself invalidate the underlying ICMP error; this tolerance does not extend to malformed extension framing or an invalid extension checksum, which are handled per .

Constrained Long-Haul Link Metadata on Destination Unreachable Errors When a gateway does not forward an otherwise admitted packet because the constrained long-haul link required to reach its destination is presently unusable, it generates whatever Destination Unreachable error the ordinary rules of or call for, according to its own forwarding state. This document does not change which code is generated or when. It permits the gateway to attach availability metadata -- the Generation Time, Expected Time Until Link Usability, and Expected Link Delay objects -- to that error, subject to the conditions in this section. A gateway MAY attach availability metadata to a Destination Unreachable message only when all of the following hold:

• the gateway holds a sufficiently current and applicable managed-service association between the invoking traffic and a constrained long-haul link, or next managed opportunity, within its coordination scope;
• according to the current coordinated forwarding state, no other policy-permitted path within the coordination scope is presently available to serve that traffic;
• the traffic is admitted to that service;
• the link is presently unusable, and the managed-service knowledge represents that unusability as a transient interruption of a service that is intended to resume;
• the invoking packet was not forwarded; and
• the message's code is an eligible availability carrier code ().

The second condition is an assertion about the current managed forwarding state for the affected traffic within the coordination scope (). The transient interruption may coincide with absence of an installed route: a domain may withdraw the route to a destination between contacts while retaining the managed-service knowledge that explains the failure, and the resulting no-route error is an eligible carrier. A gateway that meets these conditions but has no estimate to supply, or withholds estimates by policy, sends the ordinary error without the objects; the gateway need not know when the condition will clear. These assertions are carried by the Expected Time Until Link Usability and Expected Link Delay objects and attach to nothing else (). A Generation Time object supplies a timestamp and is not by itself evidence of any particular cause of failure.

Eligible Carrier Codes Link Condition Objects are applicable only to the Destination Unreachable codes listed in this section, and each object is applicable only to the carrier group indicated (). Link Condition Objects MUST NOT be attached to other Destination Unreachable codes or to other ICMP error types. In every case the code is selected by existing ICMP rules according to the gateway's forwarding state and response policy; this document neither alters that selection nor redefines any code.

Availability Carriers The availability metadata objects (Generation Time, Expected Time Until Link Usability, Expected Link Delay) may be carried on the following codes. For ICMPv6, per : Eligible ICMPv6 Availability Carrier Codes

Type 1 Code	Name	Eligibility
0	No route to destination	Eligible when the forwarding table lacks a matching entry for the destination and the gateway holds the managed-service knowledge required by .
3	Address unreachable	Eligible when the gateway retains a route whose required link is unusable and no more specific code applies. names a link-specific problem as an example of this code.

For ICMPv4, per and : Eligible ICMPv4 Availability Carrier Codes

Type 3 Code	Name	Eligibility
0	Network unreachable	Eligible when ordinary forwarding failure warrants Network Unreachable, such as absence of any route to the destination network.
1	Host unreachable	Eligible when ordinary forwarding failure warrants Host Unreachable; see the note below.

The existence of a managed service and the presence of a currently usable forwarding-table entry are distinct. A domain may withdraw the route to a destination between contacts while retaining knowledge of the future service, yielding No Route or Network Unreachable; or it may retain a route toward a presently unusable link, yielding Address Unreachable. Both are legitimate carriers. This document does not require a particular routing implementation, and a gateway that would have sent a given code before implementing this specification does not change that code because of it. Editor's note (IPv4 applicability, to be resolved before RFC publication): 's code-specific text ties Host Unreachable to a destination on a directly connected network, while its general Destination Unreachable text covers an unreachable next hop. Implementations are known to send Host Unreachable on transit-link failure, but that is precedent rather than mandate, and ICMPv4 has no residual code equivalent to ICMPv6 Address Unreachable. The retained-route, unusable-transit-link case therefore requires an explicit IPv4 applicability clarification that this document does not yet supply. The worked examples in use ICMPv6 so that their interpretation does not depend on resolving this point.

Policy Carriers The Denied by Link Policy object may be carried on the following codes, whose existing definitions already cover administrative refusal of a packet: Eligible Policy Carrier Codes

IP version	Type	Code	Existing meaning
IPv4	3	13	Communication Administratively Prohibited ()
IPv6	1	1	Communication with destination administratively prohibited ()

's reference to a firewall filter is an example of administrative prohibition, not an exclusive definition. The object identifies boundary-link admission policy as the particular administrative control that refused the packet; it does not introduce a different meaning for the base code.

Extension Objects The objects below share a single ICMP Extension Object class, the Link Condition Object class (Class-Num TBD5), distinguished by C-Type. The object header is as defined in . No object is mandatory. Which objects a message may carry depends on the Destination Unreachable code it reports (); within that set, each object is optional and absence means only that the gateway did not supply that information (). No sentinel values are defined for absent data. Because the class includes both availability metadata and a policy indication, each assertion in this document is attributed to the specific object that carries it. Each object has exactly one valid Length: 12 octets for Generation Time, 8 for Expected Time Until Link Usability and Expected Link Delay, and 4 for Denied by Link Policy. A receiver MUST ignore a Link Condition Object whose Length does not match the value for its C-Type (). The two duration objects, Expected Time Until Link Usability and Expected Link Delay, are defined and encoded independently of the Generation Time object. Their interpretation does not depend on the absolute timestamp representation, so that representation could later be revised or superseded without changing them.

Duration Format Both duration objects carry an unsigned 32-bit integer count of milliseconds. Millisecond precision is not intrinsically necessary for every value of Expected Time Until Link Usability, but a single representation for both duration-valued objects reduces implementation complexity and the risk of unit-conversion errors. defines the extension object framework but no duration datatype; the representation is defined here. The maximum representable duration, 0xFFFFFFFF milliseconds, is 4,294,967.295 seconds, approximately 49.7 days. It is a valid finite value, not a sentinel. If an otherwise available estimate exceeds the maximum representable duration, the corresponding object MUST NOT be included. No value is reserved to mean infinite, unknown, or greater than the maximum, and no saturation is defined; absence of an object means only that no representable estimate was supplied, and the protocol does not distinguish an unknown estimate from one that is known but not representable.

Generation Time

Generation Time Object

Generation Time is the gateway's reading of the applicable enclave time reference at the moment it generated the ICMP message. It is the time of the notification, not the time at which any underlying plan was created or distributed, and not an arbitrary device-local clock. Following the timestamp specification template of , this document fixes the timestamp syntax and units and leaves the remaining semantics to the deployment:

Size:

64 bits in network byte order: a 32-bit unsigned count of whole seconds followed by a 32-bit unsigned binary fraction of a second.

Units and resolution:

seconds and 2^-32 seconds respectively; 1,000 milliseconds per second, consistent with the duration objects. No planetary or calendar units are used on the wire.

Wraparound:

the seconds field wraps every 2^32 seconds. No era number is carried; era resolution is performed against the applicable enclave time reference, not against an implicit wall clock.

Epoch, time scale, and leap seconds:

supplied by the enclave time reference. The specification or provisioning of the managed deployment MUST establish the time scale, epoch, treatment of discontinuities such as leap seconds or clock resets, and era or wraparound interpretation, and MUST define the relationship needed to interpret elapsed seconds so that Generation Time can be combined with ETU. Choosing an epoch alone does not settle time-scale or discontinuity behavior. UTC with a conventional epoch is one permitted choice; it is not a protocol prerequisite, and this document does not presuppose the time scale a future deployment will adopt.

Synchronization aspects:

a receiver MAY use Generation Time for a calculation only when it knows the applicable enclave time reference and can relate it to its own clock with confidence sufficient for that calculation. A shared time-scale name alone does not establish clock synchronization, and a common orchestration function is not by itself evidence of a shared reference or a known conversion; cooperating administrative domains need one or the other before their receivers compare timestamps. Where the reference, the conversion, the era, or the effect of a clock discontinuity is unknown or ambiguous, the receiver ignores Generation Time for that calculation. No synchronization accuracy is required by this document and no synchronization protocol is specified.

The seconds/fraction layout is the same as the 64-bit timestamp format of , and implementations may reuse code that handles it. Reusing the layout is separate from adopting NTP's timestamp semantics: the NTP epoch, the UTC time scale, and NTP's era conventions are not imported by this document, and apply only where a deployment selects them as its enclave time reference. No time-scale identifier or negotiation is carried in this version; the applicable reference is established through the managed deployment context. Reference changes and clock resets require operational handling so that receivers do not unknowingly interpret timestamps generated under one reference using another (). Generation Time identifies when the notification and any estimates in it were generated. It is principally intended to allow a receiver that can interpret it to account for the time elapsed since an accompanying ETU estimate was generated (). A receiver that cannot interpret it ignores it; nothing else in the message depends on it, it remains independently parseable, and ignoring it does not invalidate ETU, any other applicable object, or the ordinary ICMP error. In the absence of ETU this document defines no use for Generation Time, so a message SHOULD NOT include Generation Time unless it also includes ETU ().

Expected Time Until Link Usability

Expected Time Until Link Usability Object

Expected Time Until Link Usability (ETU) is the gateway's estimate, at the moment it generated the notification, of the interval from generation until the constrained long-haul link selected for the invoking traffic is expected to become usable for forwarding it. It is an unsigned 32-bit integer count of milliseconds, in the format of . ETU refers to expected data-plane usability, not to the start of a scheduled contact or of preparation for one. Preparatory operations necessary to make the link usable, such as antenna pointing, modem configuration, acquisition, synchronization, or analogous link-establishment operations, are expected to have completed by the end of the reported interval and are not represented separately. ETU is measured from notification generation, not from receipt. It is an estimate, not a guarantee. It is not a retry interval and not an instruction to transmit at any particular time. It does not include Expected Link Delay, which describes traversal of the link once usable. When ETU and Expected Link Delay appear in the same message they MUST describe the same link or managed opportunity; a gateway MUST NOT combine the earliest usability of one exit with the delay of another. ETU is meaningful on its own. A receiver that can interpret a supplied Generation Time against the enclave time reference () may compute the expected usability time in that reference as Generation Time + ETU, and may thereby account for the time the notification spent in delivery; any era or wraparound considerations apply only to that interpretation and are resolved against the enclave reference. A receiver without Generation Time, or unable to interpret it, may apply ETU from the moment of receipt. Doing so is a conservative interpretation of the same forecast: it expires no earlier than the forecast itself, and later by however long the notification spent in delivery. It is not a guarantee about the link; actual recovery may occur later than either interpretation, or earlier. This document does not assume that ICMP delivery is prompt. The finite range of provides a practical horizon for this experimental network-layer signal. Unavailability on longer timescales is not represented by ETU; such timescales may instead bear on broader application, storage, provisioning, or communication-mechanism decisions, which this document does not address.

Expected Link Delay

Expected Link Delay Object

Expected Link Delay is the approximate one-way delay associated with traversal of the constrained long-haul link selected for the invoking traffic -- the link whose unavailability prevented forwarding or, where routing has migrated the traffic, the next managed opportunity that ETU describes -- as an unsigned 32-bit integer count of milliseconds in the format of . It is an estimate, not a bound; a quantity of the link, not an end-to-end path delay; and independent of ETU and of Generation Time. This document does not require receivers to combine it with other metadata or otherwise compute an end-to-end delivery time; how the estimate is used is a matter of endpoint and application policy. For perspective only, the maximum representable duration, if it were pure propagation delay at the speed of light in vacuum, would correspond to a distance of approximately 1.29 x 10^12 km, roughly 1.29 trillion km. The range is therefore very large even for the long-delay environments that motivate this document. This observation is explanatory; Expected Link Delay remains an estimated one-way link delay comprising whatever components contribute to it.

Denied by Link Policy

Denied by Link Policy Object

The Denied by Link Policy object consists of the object header alone; it has no payload, and its Length is exactly 4. It is carried only on the policy carrier codes of . Its presence asserts that the invoking packet was not forwarded because the applicable admission policy for the managed long-haul service refused it, independently of the current usability of any link. Presence alone supplies this classification; there is no Boolean, denial-reason field, allocation identifier, alternate gateway address, or retry time, and this document defines no way to convey why the traffic was refused or what would be admitted (). An error conveys this classification only when it contains a valid, applicable Denied by Link Policy object; an object of any other length does not establish it (), and absence of the object does not establish that the refusal came from some other control, that no boundary-link policy exists, or that the application has no alternatives. Generating the object is optional and subject to disclosure policy (). Its presence does not promise permanent denial, prove that waiting could never help, require the receiver to change mechanisms, or authorize evading policy.

Object Applicability by Code Each Link Condition Object is applicable to one group of carrier codes, as summarized in . Availability carriers are ICMPv4 Type 3 codes 0 and 1 and ICMPv6 Type 1 codes 0 and 3 (); policy carriers are ICMPv4 Type 3 code 13 and ICMPv6 Type 1 code 1 (). Link Condition Object Applicability by Carrier Group

Object	Availability carriers	Policy carriers
Generation Time (C-Type 1)	MAY; SHOULD NOT without ETU	SHOULD NOT; no use defined here without ETU
Expected Time Until Link Usability (C-Type 2)	MAY, subject to	MUST NOT
Expected Link Delay (C-Type 3)	MAY, subject to	MUST NOT
Denied by Link Policy (C-Type 4)	MUST NOT	MAY, subject to

A policy carrier MUST NOT carry Expected Time Until Link Usability or Expected Link Delay: they reveal characteristics of a link to which the invoking traffic was not admitted, and admission is evaluated before any link state is disclosed (). An availability carrier MUST NOT carry Denied by Link Policy. Under these rules Denied by Link Policy is never emitted with ETU or ELD. Generation Time may accompany it, subject to the guidance below. Generation Time SHOULD NOT be sent without Expected Time Until Link Usability on either carrier group, since this document defines no other use for it and unnecessary absolute-time information should not normally be disclosed. This is discouraged rather than inapplicable or prohibited: a receiver that finds Generation Time without ETU simply has no defined use for it, and experimentation or later experience may identify one. These are sender restrictions; receiver tolerance for inapplicable objects is specified in and does not relax them.

Generation Rules The rules in this section govern gateways. General ICMP generation rules apply in addition: for ICMPv6, including its rate-limiting requirements, and for ICMPv4. Nothing in this document permits generating an error in response to an ICMP error, to a packet addressed to a multicast destination, or in the other cases those documents prohibit. Nothing in this document suppresses a Destination Unreachable error that those documents otherwise require, and uncertainty about whether an optional object can be supported never suppresses the underlying error. On receiving trans-boundary traffic, a gateway proceeds as follows:

1. Assess the current coordinated forwarding and service state for the traffic, including whether a policy-permitted path within the coordination scope is presently available to serve it. If so, use that path and attach nothing.
2. Apply the long-haul service's admission policy before disclosing any link state or prediction.
3. If the traffic is not admitted, drop it. Where ordinary rules and local response policy call for one, generate the appropriate administrative prohibition error (); where disclosure policy permits, attach the Denied by Link Policy object (). Denial of admission to one long-haul service does not by itself mean no policy-permitted managed alternative exists; step 1 addresses that.
4. If the traffic is admitted but cannot be forwarded because the selected link is presently unusable, drop it and generate the Destination Unreachable error that ordinary ICMP rules call for. If the conditions of are satisfied and the code is an eligible availability carrier (), the gateway MAY attach Expected Time Until Link Usability, Generation Time, and Expected Link Delay objects.
5. If the traffic is admitted and the link is usable, forward it normally. A forwarded packet MUST NOT elicit a Destination Unreachable error.

The restrictions in this section govern attaching Link Condition Objects; they do not alter when ordinary Destination Unreachable errors are generated. A gateway MUST NOT attach any Link Condition Object whose assertion it cannot establish from a sufficiently current and applicable association between the traffic, the managed service, the forwarding state, the admission policy, and any advertised prediction (). In particular, a gateway MUST NOT attach availability metadata when another policy-permitted path within the coordination scope is presently available for the traffic, and MUST NOT attach it on the basis of observed local interface or carrier state alone (). Whenever an object's basis is missing, the object is withheld by policy, or an estimate is out of range (), the gateway omits that object and sends the ordinary error. A gateway MUST NOT send an ETU value not derived from its current managed-service knowledge, and MUST NOT report an expired estimate clamped to zero. A gateway MAY send ETU without Generation Time; it SHOULD NOT send Generation Time without ETU (). Attachment of every Link Condition Object MUST be configurable per policy. An operator MUST be able to configure, per source, prefix, or policy class, whether an administrative prohibition error is generated at all for refused traffic, the alternative being silent discard, and independently whether the Denied by Link Policy object is attached to it. An operator SHOULD be able to configure omission of the availability metadata objects (). A gateway MUST NOT attach Link Condition Objects to messages sent toward the constrained long-haul link, and MUST NOT attach them in response to traffic arriving from it (). ICMP delivery is unreliable and rate limited. A gateway MUST NOT assume that a sender received any particular notification; it generates a fresh notification, subject to rate limiting, for each invoking packet that meets the conditions above, using its current applicable knowledge.

Receiver Processing

Validation Ordinary validation and handling of a Destination Unreachable error are governed by the receiver's existing ICMP and transport rules; this document does not change them, and the checks below apply only to the objects. Disregarding an object never requires rejecting, or changing the ordinary handling of, the base error. Before acting on Link Condition Objects, a receiver MUST validate the message as an ICMP error per and the mitigations of : the invoking packet excerpt is matched against existing connection or flow state, and objects on a message matching nothing the receiver sent are disregarded. A receiver SHOULD disregard Link Condition Objects on a message that arrives on an interface facing outside its disclosure scope. The carrier code does not prove that a message originated inside the domain, and a filter that acts on Type and Code alone cannot selectively remove Link Condition Objects without also affecting ordinary errors of the same code. A deployment that requires selective containment of the objects at a boundary needs extension-aware enforcement; this document does not specify one and does not mandate filtering of the carrier codes.

Consumer Behavior This section is informative. This document does not specify how a host, transport, application, or management system reacts to the objects, and no such reaction is required for interoperability. Receipt of an unreachable error carrying ETU or ELD informs the receiver that the domain models the path as transiently unavailable; ETU also indicates roughly when usability is expected. Generation Time alone does not indicate a failure cause. Receipt of an administrative prohibition error carrying Denied by Link Policy informs it that boundary-link admission policy refused the traffic. What follows are possibilities that the objects enable and that the experiment of is intended to explore. A host might record availability metadata to avoid immediately repeating attempts likely to elicit the same error. How such state would be keyed, how widely it would apply, how long it would live, how it would be invalidated when the domain's knowledge changes, and how it would interact with routing are all open questions. Because ETU is an estimate reflecting the domain's coordinated state at generation time, and the gateway cannot revoke a notification, any such state is a hint and not an assurance of service at any later time. A transport might use the metadata as an input to its timeout and failure decisions, for example by comparing the expected wait against a connection's tolerance. The remote endpoint receives no corresponding notification and continues to run its own timers, which bounds the usefulness of waiting. No TCP or QUIC behavior is defined here. An application might be given the condition and its objects so that it can defer, fail fast, or reconsider its communication mechanism (). On learning that its present traffic was refused by boundary-link policy, an application with separately provisioned knowledge of an authorized application-layer gateway or bundle service might choose that mechanism instead; the object is the trigger to reconsider, and provisioning supplies the alternative and its authorization. Whether an application can receive and correlate this context at all, and whether the extra classification improves its decisions relative to an ordinary administrative prohibition error, are experiment questions. Whether an application interface should be standardized is not addressed here. Stronger reactions to unauthenticated ICMP information carry greater risk (); which reactions are worth their risk is itself an experiment question.

Legacy Host and Middlebox Behavior Every message defined by this document is an existing Destination Unreachable error, optionally carrying additional information, so a stack that does not process extensions handles it exactly as it handles the same error today (). This document does not promise identical behavior across stacks or that any connection survives. For context, classifies the availability carriers (ICMPv4 Type 3 codes 0 and 1, ICMPv6 Type 1 codes 0 and 3) as soft errors for TCP, while noting widespread implementation behavior that treats soft errors as hard errors during connection establishment; documents further divergence. This classification describes existing TCP processing; it is not the basis on which this document selects carriers and does not define permanent versus temporary failure. This document neither prescribes nor relies on a particular TCP reaction to either policy carrier. Firewalls and stateful middleboxes inside the deploying domain may strip or discard messages carrying unfamiliar extension structures, or may already filter some Destination Unreachable codes. This fails safe but silently defeats the mechanism, so deployment includes reviewing ICMP filtering policy on the paths between gateways and the hosts they serve; provides the ICMPv6 filtering framework. Legacy hosts generate nothing new and are unaffected as senders.

Operational Considerations Gateways SHOULD count generation of object-bearing Destination Unreachable messages, including which Link Condition Objects were included, and expose the counters through network management; counts of the carrier codes alone do not identify this experiment's activity, since those codes are generated for other reasons as well. A gateway attaching Denied by Link Policy knows which policy dimension refused the traffic even though the object does not convey it, and MAY log or report that detail through local operational telemetry, which is where operators debugging a refused flow should look. This document does not prescribe a management or telemetry mechanism. Operators can use the counters as diagnostic evidence of possible divergence from applicable service expectations, not as proof of failure (). The orchestration model of yields several operational lessons. Gateways need their managed-service records to carry revision and validity information so that stale records are recognized rather than acted on. When a readiness estimate passes without the link becoming usable, gateways should have a supported new estimate or omit ETU; a countdown clamped to zero is not an estimate. Loss of controller connectivity is expected, and a gateway should continue to use a still-valid record until it expires or local evidence contradicts it, while ordinary error generation continues regardless. During routing migrations, the record consulted for a notification must be the one applicable to the traffic's current selected exit; describing a different opportunity is worse than attaching nothing. Operators should expect notifications to be less informative during transitions and after plan revisions, and should treat that as normal rather than as a fault. ICMP rate limiters deserve attention at contact boundaries. When a link becomes unusable, every active trans-boundary flow can elicit an unreachable error within a short interval, and a token-bucket limiter tuned for steady-state error rates may suppress most of the burst. Because ICMP is unreliable and a gateway cannot know which notifications were received, operators SHOULD size gateway ICMP rate limits for the expected flow fan-out at gap onset. Hosts that act on the metadata to avoid repeated attempts reduce the offered load that would otherwise sustain the burst. ETU is only as meaningful as the gateway's knowledge of the link. Using Generation Time additionally depends on the receiver knowing the enclave time reference and being able to relate it to its own clock (); receivers that cannot may apply ETU from receipt (). The deployment is responsible for establishing and distributing the reference. When the reference changes or a gateway's clock is reset, operators need to ensure that receivers do not interpret timestamps generated under the old reference using the new one; until that is assured, receivers fall back to ignoring Generation Time. Cooperating administrative domains need a shared reference or a known conversion before their receivers compare timestamps; sharing an orchestration function does not by itself provide either. Hosts that maintain state derived from these objects SHOULD expose it to local diagnostics, since such state changes transmission behavior in ways otherwise invisible to troubleshooting.

Experimental Status and Goals This document is published as Experimental. The objects are specified normatively so that independent implementations interoperate at the ICMP layer. The value of the mechanism, however, rests on two kinds of questions that only deployment can answer: whether gateways can generate the objects correctly and usefully, and whether the objects let consumers make better decisions than the ordinary unreachable or administrative prohibition error alone would allow. Consumer behaviors are deliberately not standardized here (); the experiment is intended to produce the experience on which later specification of such behaviors might be based. An extension object, like a new code, requires implementation support to expose a new meaning to applications; neither inherently solves application delivery.

Scope of the Experiment The experiment runs within domains meeting the criteria of : space networking testbeds and missions, other networks with scheduled or intermittently available managed links between enclaves, and laboratory emulations of the same topologies. Link Condition Objects are not intended to be exchanged across uncontrolled networks (). No behavior in this document affects hosts whose traffic never requires a trans-boundary link. Prior to IANA assignment of the Link Condition Object class, experiments use a class value from the Private Use range 247-255 of the "ICMP Extension Object Classes and Class Sub-types" registry , with its interpretation and scope explicitly configured among the participants. Such a value is not globally unique, is not a claim on any permanent assignment, and is used only within the experiment's coordination scope. The carrier codes are already assigned and are used as is; no experimental ICMP type or code is involved. Interoperability reports from this phase are in scope for the experiment.

Network Signal Evaluation The first layer of the experiment concerns the objects themselves:

• Generation correctness: whether gateways attach each object only under the conditions of , whether the coordination-scope determination can be made reliably in deployed routing architectures and during transitions, and which carrier codes gateways actually produce for the long-haul conditions in each IP version ().
• Distinction: whether availability metadata usefully distinguishes managed transient unavailability from ordinary unreachable errors of the same code, and whether the Denied by Link Policy object usefully distinguishes boundary-link admission refusal from other administrative prohibition ().
• Prediction accuracy and usefulness: how closely ETU tracks actual link usability, how often it is available at all, how often plan revisions or acquisition failures invalidate it, and whether Generation Time and Expected Link Delay are populated and used.
• Orchestration feasibility: whether the information path of can be realized with existing management channels, and whether gateways can consult applicable records on the error-generation path, including after route withdrawal.
• Generation rate: gateway ICMP generation rates at gap onset under realistic fan-out, and the effect of rate limiting on which senders receive a notification.
• Legacy and middlebox behavior: how unmodified hosts respond to object-bearing carrier errors across the stacks present in target environments, including embedded and flight-heritage implementations (); and what filtering changes deployments required, including whether middleboxes strip or discard extension structures.
• Security and disclosure: whether the information disclosed by the objects is operationally acceptable, whether the disclosure controls of are sufficient, and whether forged or stale objects caused harm.
• Whether a coarse boundary-policy object is useful beyond the ordinary administrative refusal, and whether experience establishes a need for richer policy-denial metadata. This document does not speculate about the format of any such metadata.

Consumer Behavior Exploration The second layer concerns what receivers do with the objects. None of these behaviors is specified here; the experiment is intended to discover which are worthwhile:

• Whether hosts that record availability metadata to avoid repeated attempts reduce futile retransmission and offered load during link-unavailable periods, relative to hosts receiving the same ordinary errors without objects, and what keying, scope, lifetime, and invalidation rules work.
• What transport reactions are appropriate, including whether comparing expected wait against connection tolerance is useful and whether connections that wait survive the peer's own timers.
• Whether applications can receive and correlate the objects with their traffic at all, and whether the Denied by Link Policy classification improves their decisions relative to an ordinary administrative prohibition error, including selection among separately provisioned mechanisms such as IP transports, application-layer gateways, and bundle services.
• Whether provisioning and orchestration systems can use the objects, and whether divergence telemetry () exposed real faults ahead of existing monitoring.

Evidence for Advancement Later consideration of the mechanism for the standards track could be informed by evidence of: at least two independent interoperable implementations of the Link Condition Objects, including extension object processing on both carrier groups; generation accuracy in at least one operational, non-laboratory domain; usefulness of the objects beyond the ordinary errors they ride on, with unused objects removed rather than carried forward; manageable legacy and middlebox behavior; acceptable security and disclosure properties; consumer behaviors independently demonstrated to benefit from the objects, without presupposing any one receiver strategy; and evidence that the semantics apply across more than one class of long-haul network without special-case changes to the wire format. Reports of failed or inconclusive experiments are requested to the same degree as successful ones.

Security Considerations ICMP carries no authentication, and the objects are actionable by implementations that choose to act on them, so the principal threats are forgery by off-path attackers and information disclosure to the senders these messages answer. The mitigations are the scoping of , validation against sender state (), rate limiting, and agreed disclosure policy among the cooperating authorities. None of them authenticates the carrier code or the objects; filtering and invoking-packet validation raise the cost of injection without confining it to trusted parties, and none is dependable across the open internet. Three forgery cases arise. A forged ordinary Destination Unreachable or administrative prohibition error is an existing threat with existing mitigations (); this document does not change it. Forged availability metadata on an otherwise plausible error could induce an implementation that acts on it to withhold trans-boundary traffic for the advertised interval. A forged Denied by Link Policy object could induce an application to abandon a working IP path for another mechanism, or to conclude that provisioning is needed; this influence on application choices is a capability beyond what forging the bare administrative prohibition error provides. This document does not require receivers to act on any object, and stronger reactions to unauthenticated ICMP information carry correspondingly greater risk; an implementation that does act should bound the effect of any single notification, treat ETU as an estimate that may be stale or wrong, treat Denied by Link Policy as a classification that may be forged, and consider that the gateway cannot revoke a notification whose basis has changed. Because the objects ride on ordinary codes, containing them at a boundary requires extension-aware enforcement (). The absence of Link Condition Objects from a message is not a trustworthy indication that no long-haul condition exists (), since objects may be omitted by policy, by rate limiting, by middleboxes, or by an attacker. The Denied by Link Policy object, although it has no payload, discloses that boundary-link admission policy refused particular traffic, and a gateway that attaches it is a probing oracle: an attacker varying markings, sources, and destinations can map which traffic the long-haul service admits, even without being told why any particular packet was refused. therefore requires per-policy control over whether the object is attached and, independently, whether the base error is generated at all; toward any sender the operator does not trust, silent discard is the expected posture, consistent with existing firewall practice. The availability metadata objects disclose link schedule information, which in some deployments is sensitive operational information. permits omitting them per policy; operators of such deployments should protect the metadata as they protect the underlying schedule. Evaluating admission before link state () prevents disclosure of schedule information to traffic that would not be admitted regardless. Ordinary ICMP generation restrictions and rate limiting (, ) apply to all of these messages. Quoting and padding of the invoking packet and the optional objects affect response size; a message carrying all three availability objects is larger than a minimal Destination Unreachable error. This document makes no claim about the absence of amplification beyond what those restrictions provide.

IANA Considerations This document requests no new ICMP type and no new Destination Unreachable code. It requests one assignment, shown as a TBD value throughout; no numeric value is proposed. From the "ICMP Extension Object Classes and Class Sub-types" registry : a new class TBD5, Link Condition Object, with C-Type 1, Generation Time; C-Type 2, Expected Time Until Link Usability; C-Type 3, Expected Link Delay; and C-Type 4, Denied by Link Policy, assigned by this document. Further C-Types are Specification Required. The class registry's procedure is First Come First Served for values 0-246. This document requests no change to the already-assigned Destination Unreachable codes on which Link Condition Objects may be carried: ICMPv6 Type 1 codes 0, 1, and 3, and ICMPv4 Type 3 codes 0, 1, and 13 (). Their existing meanings are unchanged.

References Normative References This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK] Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. This memo provides information for the Internet community. This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. [STANDARDS-TRACK] This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. This memo provides information for the Internet community. This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. [STANDARDS-TRACK] The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes. Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission. This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. This document defines an Experimental Protocol for the Internet community. There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets. This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards. This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.

Worked Examples

Availability Metadata Times in this example are expressed in the enclave time reference () as seconds from its epoch. A gateway whose deep-space link is presently unusable receives an IPv6 packet for a trans-boundary destination at reference time 10,000 s. According to its current coordinated forwarding state, no other policy-permitted path within the coordination scope is available for the traffic. The packet is admitted under the service's policy. The gateway retains a route toward the destination, but the next hop over the deep-space link is unusable; under this is a link-specific problem not covered by another code, so the gateway generates ICMPv6 Destination Unreachable, Code 3 (Address unreachable). Its managed-service record () shows the link expected to be ready to forward at reference time 12,520 s, and its one-way delay estimate for the link is 20 minutes, so it attaches three Link Condition Objects. The Class-Num octet of each is TBD5 and is omitted from the listing. Availability Metadata Example

Object	C-Type	Length	Wire value	Decoded
Generation Time	1	12	0x00002710 0x00000000	10,000 s in the enclave reference
Expected Time Until Link Usability	2	8	0x002673C0	2,520,000 ms (42 min)
Expected Link Delay	3	8	0x00124F80	1,200,000 ms (20 min)

The Generation Time seconds word is 10,000 and the fraction word is zero. ETU is the interval from reference time 10,000 s to 12,520 s. If this deployment had chosen UTC as its enclave time reference, the seconds word would instead be the corresponding count of seconds from the epoch the deployment specified; that is the deployment's choice and is not required by this document. Had the gateway attached no objects, or had the receiver not processed them, the message would be an ordinary Address Unreachable error (). A receiver that processes the objects but does not know the enclave time reference, cannot relate it to its own clock, or did not receive Generation Time needs no timestamp arithmetic: it knows that, as of generation, the link was expected to become usable in 42 minutes, and it may apply that interval from the moment of receipt. If the notification spent time in delivery, this interpretation expires later than the original forecast; it remains a conservative reading of the same forecast, not a guarantee, and the link may in fact become usable later than either. A receiver that knows the enclave time reference and can relate it to its own clock may compute Generation Time + ETU = 12,520 s and, on receiving the message at reference time 10,003 s, understand that about 2,517 s remain, subject to its own clock uncertainty and to the accuracy of the forecast. Had the gateway instead generated a notification at 10,003 s against the same forecast, that notification would carry Generation Time 10,003 s and ETU 2,517,000 ms: ETU is recomputed for each notification from the current reference time, not copied from the plan. Either receiver might, as a matter of local policy, use the 20-minute link delay estimate in deciding whether the destination suits its traffic once the link is usable ().

Denied by Link Policy The same gateway, during an active contact, receives an IPv6 packet whose traffic class is not admitted by the service's policy. It drops the packet. Local response policy calls for an error, so it generates ICMPv6 Destination Unreachable, Code 1 (Communication with destination administratively prohibited), and, disclosure policy permitting, attaches a single Link Condition Object: Denied by Link Policy Example

Object	C-Type	Length	Payload
Denied by Link Policy	4	4	none

The object occupies one 32-bit word: Length 0x0004, Class-Num TBD5, C-Type 0x04. It is preceded by the extension header and by the invoking packet, padded to at least 128 octets. No Expected Time Until Link Usability or Expected Link Delay is attached, and Generation Time is omitted because no ETU accompanies it. A receiver that processes the object learns that boundary-link admission policy refused the traffic and may, for instance, reconsider its communication mechanism (). A receiver that ignores extensions, or that disregards the object, has an ordinary administrative prohibition error and nothing more ().

Acknowledgments The author used AI-assisted tooling in preparing this document, including drafting and editing text and converting it to the kramdown-rfc source format. All technical content, design decisions, and the final text are the responsibility of the author.