Safe(r) Limited Domains
draft-wkumari-intarea-safe-limited-domains-07
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) | |
|---|---|---|---|
| Authors | Warren Kumari , Andrew Alston , Éric Vyncke , Suresh Krishnan , Donald E. Eastlake 3rd | ||
| Last updated | 2026-08-30 | ||
| 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-wkumari-intarea-safe-limited-domains-07
Internet Area Working Group W. Kumari
Internet-Draft Google, LLC
Intended status: Informational A. Alston
Expires: 3 March 2027 Alston Networks
É. Vyncke
S. Krishnan
Cisco
D. Eastlake
Independent
30 August 2026
Safe(r) Limited Domains
draft-wkumari-intarea-safe-limited-domains-07
Abstract
Documents describing protocols intended solely for use within
"limited domains" often rely on edge filtering at every boundary node
to prevent domain-internal traffic from leaking to the global
Internet (and vice versa). Relying purely on administrative
filtering creates "fail-open" designs that are susceptible to
configuration errors, ACL bypass, and hardware table exhaustion.
This document describes design principles and concrete mechanisms
that allow limited-domain protocols to "fail-closed" by default. By
leveraging Layer-2 encapsulation identifiers (such as dedicated or
extended EtherTypes), link-local address scoping, and / or Hop-Limit
boundaries, protocol designers can significantly reduce the
operational and security risks associated with limited domain
protocols.
These mechanisms are not applicable to all protocols intended for use
in a limited domain, but if implemented on certain classes of
protocols, can significantly reduce the risks.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Internet Area Working
Group Working Group mailing list (int-area@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/int-area/.
Source for this draft and an issue tracker can be found at
https://github.com/wkumari/draft-wkumari-intarea-safe-limited-
domains.
Kumari, et al. Expires 3 March 2027 [Page 1]
Internet-Draft safer-limited-domains August 2026
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 3 March 2027.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Some types of limited domain protocols . . . . . . . . . . . 4
4. Fail-open versus Fail-closed . . . . . . . . . . . . . . . . 5
5. IP Hop-Limit Limiting . . . . . . . . . . . . . . . . . . . . 5
6. IPv4 Multicast Addressing . . . . . . . . . . . . . . . . . . 6
7. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . . . 6
8. Making a layer-3 type limited-domain protocol fail-closed . . 6
9. Ethernet Protocol Identification . . . . . . . . . . . . . . 7
9.1. Extended EtherType Protocol Identification . . . . . . . 8
9.1.1. Hardware Forwarding Considerations . . . . . . . . . 8
9.2. Specific EtherType Protocol Identification . . . . . . . 9
10. Non-Ethernet Encapsulations and Layer-3 Overlays . . . . . . 9
10.1. The Fragility of IP-Level Filtering in Overlays . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Kumari, et al. Expires 3 March 2027 [Page 2]
Internet-Draft safer-limited-domains August 2026
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A: Structural vs. Policy-Enforced Boundaries (MPLS vs.
SRv6) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
MPLS: Structural Fail-Closed Isolation . . . . . . . . . . . . 14
SRv6: Policy-Enforced Fail-Open Exposure . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
[RFC8799] discusses the concept of "limited domains", provides
examples of limited domains, as well as Examples of Limited Domain
Solutions, including Service Function Chaining (SFC [RFC7665] ),
Segment Routing, "Creative uses of IPv6 features" (including
Extension headers, e.g., for in situ Operations, Administration, and
maintenance [RFC9378]).
In order to provide context, this document will quote extensively
from [RFC8799], but it is assumed that the reader will actually read
[RFC8799] in its entirety.
[RFC8799] Section 3, notes:
A common argument is that if a protocol is intended for limited
use, the chances are very high that it will in fact be used (or
misused) in other scenarios including the so-called open Internet.
This is undoubtedly true and means that limited use is not an
excuse for bad design or poor security. In fact, a limited use
requirement potentially adds complexity to both the protocol and
its security design, as discussed later.
Notably, in [RFC8799] Section 2, states:
Domain boundaries that are defined administratively (e.g., by
address filtering rules in routers) are prone to leakage caused by
human error, especially if the limited domain traffic appears
otherwise normal to the boundary routers. In this case, the
network operator needs to take active steps to protect the
boundary. This form of leakage is much less likely if nodes must
be explicitly configured to handle a given limited-domain
protocol, for example, by installing a specific protocol handler.
In addition, [RFC8799] Section 6, notes:
Kumari, et al. Expires 3 March 2027 [Page 3]
Internet-Draft safer-limited-domains August 2026
Today, where limited domains exist, they are essentially created
by careful configuration of boundary routers and firewalls. If a
domain is characterized by one or more address prefixes, address
assignment to hosts must also be carefully managed. This is an
error-prone method, and a combination of configuration errors and
default routing can lead to unwanted traffic escaping the domain.
Our basic assumption is therefore that it should be possible for
domains to be created and managed automatically, with minimal
human configuration. We now discuss requirements for automating
domain creation and management.
This document discusses some of the mechanisms which protocol
designers can use to limit the scope of their protocols to a single
link. If the protocol is intended to be used across multiple links,
but should not be forwarded beyond a single administrative domain,
then the protocol designer should consider making the protocol "fail-
closed" rather than "fail-open", as described below.
This is primarily targeted towards protocols which are intended to
primarily be used within a single layer-2 broadcast domain, or for
protocols which provide a transport type service (similar to MPLS or
SRv6) and are not intended to remain within a single administrative
domain.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Some types of limited domain protocols
[RFC8799] Section 3 discusses some examples of Limited Domains, based
mainly on the network type (e.g. Home, Sensor Networks, Data Centers,
etc).
This section instead classifies the types of limited domain protocols
based more on their intended use, and technology.
Broadly speaking, there are two types of limited domain protocols:
* Layer-2 type limited domain protocols: These are protocols that
are intended to be used within a single LAN segment.
Kumari, et al. Expires 3 March 2027 [Page 4]
Internet-Draft safer-limited-domains August 2026
* Transport type service (for example MPLS and SRv6): These
protocols are intended to provide a transport service, and are
intended to remain within a single administrative domain such as
an Enterprise or a Service Provider network.
4. Fail-open versus Fail-closed
Protocols can be broadly classified as either "fail-open" or "fail-
closed". Fail-closed protocols are those that require explicit
interface or device-wide configuration to enable them to be accepted
or processed when received on an interface. A classic example of a
fail-closed protocol is MPLS ([RFC3031]): In order to allow MPLS to
transit an interface, the operator must enable the MPLS protocol on
that interface and on the device itself. This ensures that outside
MPLS traffic does not leak in or out of the network / domain.
Fail-open protocols are those that require explicit configuration in
order to ensure that they do not leak out of a domain, for example,
through the application of filters. An example of a fail-open
protocol is SRv6 - in order to ensure that SRv6 traffic does not leak
out of a network, the operator must explicitly filter this traffic,
and, in order to ensure that SRv6 traffic does not leak in, the
operator must explicitly filter SRv6 traffic.
Fail-open protocols are inherently riskier than fail-closed
protocols, as they rely on perfect configuration of filters on all
interfaces at the boundary of a domain, and, if the filters are
removed for any reason (for example, during troubleshooting), there
is a risk of inbound or outbound leaks. In addition, some devices or
interfaces may have limitations in the size and complexity of filters
that can be applied, and so adding new filter entries to limit leaks
of a new protocol may not be possible.
Fail-closed protocols, on the other hand, do not require any explicit
filtering. In order for the protocol to be accepted and processed
when received on an interface, the operator must explicitly enable
the protocol on that interface and on the device itself. In
addition, there is less risk of operational mistakes, as it does not
rely on filters that may be limited in number and complexity.
Finally, fail-closed protocols do not require that operators of
networks outside of the limited domain implement filters to protect
their networks from the limited domain traffic.
5. IP Hop-Limit Limiting
-=-=-=- # IP Hop-Limit Limiting
Kumari, et al. Expires 3 March 2027 [Page 5]
Internet-Draft safer-limited-domains August 2026
Some limited-domain protocols are intended to operate strictly within
a single IP subnet or link. In these cases, protocol specifications
SHOULD require that the IP Hop-Limit (or IPv4 TTL) to be set to 1
upon transmission.
As standard routers decrement the Hop-Limit upon forwarding and
discard packets when the count reaches zero, setting the Hop-Limit to
1 ensures that the traffic cannot be forwarded off-link. This
differs from the Generalized TTL Security Mechanism (GTSM,
[RFC3682]), which sets the Hop-Limit to 255 to verify that the sender
is on-link and protect against off-link spoofing.
Which option to choose (if either) depends on the specific
requirements of the protocol.
6. IPv4 Multicast Addressing
Some protocols (e.g OSPF) use addresses from the IP Local Network
Control Block [RFC5771], (224.0.0/24). In addition to providing a
discovery mechanism, this traffic is not forwarded off-link,
providing a simple and effective way to limit the scope of the
protocol.
In some (rare) cases, IPv4 "Link Local" addresses [RFC3927] may be an
appropriate mechanism to limit the scope of the protocol, but this
such a niche case that it is not discussed further here.
7. IPv6 Link Local Addresses
Link-Local IPv6 Unicast Addresses ([RFC4291] Section 2.5.6) are used
for communication between nodes on a single link. They are not
routable and are not forwarded by routers. In cases where a limited-
domain protocol is intended to be used only within a single link, the
use of IPv6 Link-Local addresses can be an effective way to limit the
scope of the protocol.
8. Making a layer-3 type limited-domain protocol fail-closed
One way to make a limited-domain protocol fail-closed is to assign it
a unique layer-2 protocol identifier, usually an EtherType. This
mechanism is used by MPLS. In modern router and hosts, if such a
protocol identifier is not enabled on an interface, then the Ethernet
chip-set will ignore the frame, and the node will not see or process
it. Thus, it is necessary to specifically enable the layer-2
protocol identifier on all relevant interfaces inside the limited
domain, and the protocol will be blocked at the domain boundary where
the protocol has not been so enabled. This is a simple and effective
mechanism to ensure that the protocol does not leak out of the
Kumari, et al. Expires 3 March 2027 [Page 6]
Internet-Draft safer-limited-domains August 2026
limited domain if and when an operator makes a mistake in configuring
filters based on identifiers appearing deeper in the frame such as IP
addresses or IP protocol or header options.
This layer-2 protocol identifier technique only works for transport-
type limited domain protocols (i.e., protocols running at layer 3).
Higher layer protocols cannot necessarily be protected in this way,
and so cryptographically enforced mechanisms may need to be used
instead (e.g., as done by ANIMA in [RFC8994] and [RFC8995]).
9. Ethernet Protocol Identification
Figure 1 shows the general format of Ethernet frames. The relevant
protocol identification field occurs after the destination and source
MAC addresses and any tags (such a VLAN tags). The alternatives for
protocol identification are discussed in Section 3 of [RFC9542].
+-----------+-----------+- - - - +----------+--------- - - -+-------+
|Destination| Source |Optional| Protocol | Body of |Trailer|
|MAC Address|MAC Address| Tags |Identifier| Frame | |
+-----------+-----------+ - - - -+----------+--------- - - -+-------|
Figure 1: Ethernet Frame Format
This document considers EtherType protocol identification. An
EtherType is an unsigned 16-bit field in an Ethernet frame with a
value in the range of 0x0600 to 0xFFFF, and so it is a somewhat
limited resource; however, there exists a special Extended EtherType
(0x88B7) that can be suffixed by an Organizationally Unique
Identifier (OUI) followed by a further 16-bits identifying the
protocol relative to that OUI as discussed in Section 3 of [RFC9542].
These alternatives of a direct EtherType or use of the Extended
EtherType for the case of the IANA OUI are illustrated in Figure 2.
The following subsections discuss the factors which may influence the
choice between these alternatives when use of such layer 2 protocol
identification, to make the isolation of a limited domain more
robust, is warranted.
Kumari, et al. Expires 3 March 2027 [Page 7]
Internet-Draft safer-limited-domains August 2026
01234567 01234567
+--------+--------+
| EtherType |
+--------+--------+
Specific EtherType
01234567 01234567 01234567 01234567 01234567 01234567 01234567
+--------+--------+--------+--------+--------+--------+--------+
| 0x88 | 0xB7 | 0x00 | 0x00 | 0x5E | Protocol Number |
+--------+--------+--------+--------+--------+--------+--------+
Extended EtherType| IANA OUI |IANA Protocol Number
Figure 2: EtherType Based Protocol Identification
Because specific EtherTypes are a limited resource, an Extended
EtherType SHOULD be used unless there is a strong reason why it will
not work satisfactorily and a specific EtherType is required.
9.1. Extended EtherType Protocol Identification
The main advantage of using an Extended EtherType with an IANA
Protocol Number, as shown in Figure 2, is that such a number can be
allocated by IANA with Expert Review based on an Internet Draft and
is thus relatively easy to obtain. The main disadvantage is that the
protocol identification is 5 bytes longer than a specific dedicated
EtherType.
9.1.1. Hardware Forwarding Considerations
While Extended EtherTypes ([RFC9542]) solve the namespace exhaustion
issue for 16-bit EtherTypes, protocol designers must remain mindful
of hardware parsing pipeline constraints.
High-throughput "merchant silicon" and network processor ASICs are
heavily optimized to parse standard 16-bit Layer-2 EtherTypes at line
rate within a fixed-depth initial parsing window. In contrast,
variable-length or extended EtherType encapsulations (e.g., SNAP
headers or 8-octet Extended EtherTypes) can introduce forwarding
trade-offs on certain switching silicon:
* *Parser Depth and Recirculation*: Some existing hardware engines
cannot parse beyond a fixed offset in a single pass. Having an
Extended EtherType before inner headers may trigger packet
recirculation or force packets into a slower software/microcode
exception path.
Kumari, et al. Expires 3 March 2027 [Page 8]
Internet-Draft safer-limited-domains August 2026
* *TCAM and Flow Matching*: Many Access Control Lists (ACLs) and
flow-match engines have native primitives for matching 16-bit
EtherTypes (e.g., IPv4, IPv6, MPLS), whereas matching on an OUI
plus extended protocol ID may consume multiple TCAM lookups, or
exceed key-generation capabilities.
Protocol designers should therefore balance the scarcity of standard
16-bit EtherTypes against the line-rate hardware parsing requirements
of high-speed transit nodes.
9.2. Specific EtherType Protocol Identification
The primary disadvantage of using a specific EtherType, as opposed to
an Extended EtherType, is that assignment of such an EtherType is
significantly more difficult than assignment of an Extended EtherType
IANA protocol number. As discussed in [RFC9542], a specific
EtherType can only be assigned by the IEEE Registration Authority
under the following policy: "Since EtherTypes are a fairly scarce
resource, the IEEE RAC has let us know that they will not assign a
new EtherType to a new IETF protocol specification until the IESG has
approved the protocol specification for publication as an RFC. In
exceptional cases, the IEEE RA is willing to consider "early
allocation" of an EtherType for an IETF protocol that is still under
development as long as the request comes from and has been vetted by
the IESG." ([RFC9542] Appendix B.1, citing [IESG_EtherType])
During development and testing, a protocol can use a "Local
Experimental Ethertype" (0x88b5 and 0x88b6 - [IANA_EtherType]). Once
the protocol is approved for publication, the IESG can request an
EtherType from the IEEE. However, there is always a risk of some
implementation using a Local Experimental EtherType not getting
updated causing conflicts with a later different use of that
experimental EtherType.
The primary advantage of using a specific EtherType is the saving of
5 bytes relative to the use of the Extended EtherType with a protocol
number under the IANA OUI.
10. Non-Ethernet Encapsulations and Layer-3 Overlays
Many modern data centers, enterprise networks, and WANs deploy
limited-domain features across routed multi-hop IP underlays using
Layer-3 encapsulations (such as Geneve [RFC8926], VXLAN-GPE
[RFC9674], GRE [RFC2784], or generic UDP encapsulation [RFC8085]).
When designing limited-domain protocols for Layer-3 overlay
environments, the same fundamental tension between fail-open and
fail-closed designs applies:
Kumari, et al. Expires 3 March 2027 [Page 9]
Internet-Draft safer-limited-domains August 2026
10.1. The Fragility of IP-Level Filtering in Overlays
Tunneling limited-domain traffic inside standard unicast IP/UDP
packets without domain-specific transport identifiers exposes the
traffic to the same leakage risks as native IP:
1. *Routability by Default*: If an inner packet is encapsulated in a
standard UDP/IP header destined for an IP address that leaks into
the global routing table, intermediate underlay routers will
forward the encapsulated frame across domain boundaries unless
explicitly filtered.
2. *Transit Inspection Invisibility*: Intermediate nodes that
inspect only the outer IP/UDP headers cannot distinguish between
legitimate transit traffic and sensitive limited-domain control
payloads.
11. Security Considerations
Protocols are designated as "limited domain" because something
unexpected might happen if they leak outside of a domain with unified
management. For example, VLAN or VPN or overlay identifiers may be
misinterpreted resulting in the delivery of data to or the acceptance
of data from unauthorized network nodes violating intended security
constraints. The use of a layer-2 protocol identifier to provide a
"fail closed" barrier at the domain border can significantly improve
security by eliminating the opportunity for such misinterpretation.
12. IANA Considerations
This document has no IANA actions.
13. References
13.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/rfc/rfc2119>.
[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/rfc/rfc8174>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/rfc/rfc8799>.
Kumari, et al. Expires 3 March 2027 [Page 10]
Internet-Draft safer-limited-domains August 2026
13.2. Informative References
[IANA_EtherType]
"IANA EtherType Registry", Web
<https://www.iana.org/assignments/ieee-802-numbers/ieee-
802-numbers.xhtml#ieee-802-numbers-1>.
[IESG_EtherType]
"IESG Statement on EtherTypes", Web
<https://www.ietf.org/about/groups/iesg/statements/
ethertypes>, 1 May 2023.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/rfc/rfc2784>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/rfc/rfc3031>.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682,
DOI 10.17487/RFC3682, February 2004,
<https://www.rfc-editor.org/rfc/rfc3682>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/rfc/rfc3927>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/rfc/rfc4291>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010,
<https://www.rfc-editor.org/rfc/rfc5771>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/rfc/rfc7665>.
Kumari, et al. Expires 3 March 2027 [Page 11]
Internet-Draft safer-limited-domains August 2026
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/rfc/rfc8926>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/rfc/rfc8994>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.
[RFC9378] Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T.
Mizrahi, Ed., "In Situ Operations, Administration, and
Maintenance (IOAM) Deployment", RFC 9378,
DOI 10.17487/RFC9378, April 2023,
<https://www.rfc-editor.org/rfc/rfc9378>.
[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA
Considerations and IETF Protocol and Documentation Usage
for IEEE 802 Parameters", BCP 141, RFC 9542,
DOI 10.17487/RFC9542, April 2024,
<https://www.rfc-editor.org/rfc/rfc9542>.
[RFC9674] Snijders, J., "Same-Origin Policy for the RPKI Repository
Delta Protocol (RRDP)", RFC 9674, DOI 10.17487/RFC9674,
December 2024, <https://www.rfc-editor.org/rfc/rfc9674>.
Acknowledgments
Much thanks to Deborah Brungard and Brian Carpenter, for their review
and comments.
Kumari, et al. Expires 3 March 2027 [Page 12]
Internet-Draft safer-limited-domains August 2026
Also much thanks to everyone else with whom we have discussed this
topic; I've had numerous discussions with many many people on this,
and I'm sure that I've forgotten some of them. Apologies if you were
one of them.
Changelog
* - 02-07:
- Add Security Considerations text about the risks of fail-open
protocols and the benefits of fail-closed protocols.
- Added Appendix contrasting MPLS and SRv6.
- Added hardware processing notes.
o Used Gemini to help me reformulate mess into something
readable.
- Rewrite Abstract.
* -02-03:
- Add Security Considerations text about the risks of fail-open
protocols and the benefits of fail-closed protocols.
* 01-02:
- Add Donald Eastlake as an author.
- Substantial re-write and expansion of material concerning
specific and Extended EtherType protocol identification.
- Add initial Security Considerations text.
* 00-01:
- Deborah pointed out that "this only works for transport-type
limited domain protocols (e.g., SRv6)" could be read as SRv6
fails-closed.
Appendix A: Structural vs. Policy-Enforced Boundaries (MPLS vs. SRv6)
To illustrate the difference between fail-open and fail-closed
designs, consider MPLS and Segment Routing over IPv6 (SRv6,
[RFC8754]).
Kumari, et al. Expires 3 March 2027 [Page 13]
Internet-Draft safer-limited-domains August 2026
MPLS: Structural Fail-Closed Isolation
MPLS provides an automatic fail-closed boundary by virtue of its
Layer-2 encapsulation:
* *Distinct Protocol Identifier*: MPLS frames utilize dedicated
EtherTypes (0x8847 for unicast, 0x8848 for multicast).
* *Interface Enablement Requirement*: A node will only process or
forward MPLS frames on interfaces where MPLS forwarding is
explicitly enabled.
* *Drop by Default*: If an MPLS-encapsulated packet is accidentally
transmitted across a domain boundary to an un-configured
interface, transit provider, or peering exchange, the receiving
hardware cannot parse the payload as native IP and discards the
frame at line rate.
Because the forwarding plane requires explicit protocol support and
state at each hop, MPLS fails closed in the presence of configuration
errors or interface miswiring.
SRv6: Policy-Enforced Fail-Open Exposure
In contrast, SRv6 encapsulates domain-internal routing instructions
within standard IPv6 headers:
* *Standard Layer-2 Demuxing*: SRv6 packets utilize standard IPv6
EtherType (0x86DD) and standard IPv6 Next Header values.
* *Global Forwarding Compatibility*: Any standard IPv6 router along
a path will forward an SRv6 packet using ordinary routing
procedures on the IPv6 Destination Address, regardless of whether
that router participates in or recognizes Segment Routing.
* *Reliance on Perimeter ACLs*: As described in Section 5 of
[RFC8754], preventing SRv6 packets from leaking outside the
trusted domain (or preventing external packets from injecting
unauthorized SIDs into the domain) requires strict, comprehensive
ingress and egress filtering at every perimeter boundary.
If an edge filter is omitted, truncated due to TCAM limits, or
temporarily removed during debugging, the network fails open: domain-
internal packets are forwarded across the public Internet, and
untrusted external entities may address internal function SIDs
directly.
Kumari, et al. Expires 3 March 2027 [Page 14]
Internet-Draft safer-limited-domains August 2026
Authors' Addresses
Warren Kumari
Google, LLC
Email: warren@kumari.net
Andrew Alston
Alston Networks
Email: alston.networks@gmail.com
Éric Vyncke
Cisco
Email: evyncke@cisco.com
Suresh Krishnan
Cisco
Email: suresh.krishnan@gmail.com
Donald Eastlake
Independent
Email: d3e3e3@gmail.com
Kumari, et al. Expires 3 March 2027 [Page 15]