RFC 8799

Limited Domains and Internet Protocols

📅 published July 2020, from ietf

RFC 8799: Limited Domains and Internet Protocols 🎀

  • Who wrote it: B. Carpenter (Univ. of Auckland) and B. Liu (Huawei Technologies) 💖
  • Stream and category: Independent Submission, Category: Informational 📚
  • ISSN: 2070-1721
  • Date: July 2020 🗓️
  • Obsoletes and updates: the title block doesn't list anything this one obsoletes or updates ✨

Abstract ✨

Okay bestie, the Internet is getting a whole regional glow-up. 🌍 There's a noticeable trend toward network behaviors and semantics that are tailored to a particular set of requirements inside a limited region. Policies, default parameters, supported options, the style of network management, and security requirements can all be different from one region to the next. This document looks at examples of these limited domains (also called controlled environments), notes some emerging solutions, and includes a related taxonomy. Then it briefly talks about standardizing protocols for limited domains. Finally, it shows that we need a precise definition of "limited domain membership," plus mechanisms that let nodes join a domain securely and 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 it is not the product of IETF consensus. 🧚

Status of This Memo 📝

This one is not an Internet Standards Track specification. It's published just for informational purposes, so no pressure. 🌸

This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked it for publication at their discretion, and they make no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. 💅

Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc8799. 🔗

Copyright (c) 2020 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) as they are in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions with respect to this document. 🫶

Table of Contents 🗺️

   1.  Introduction
   2.  Failure Modes in Today's Internet
   3.  Examples of Limited Domain Requirements
   4.  Examples of Limited Domain Solutions
   5.  The Scope of Protocols in Limited Domains
   6.  Functional Requirements of Limited Domains
   7.  Security Considerations
   8.  IANA Considerations
   9.  Informative References
   Appendix A.  Taxonomy of Limited Domains
     A.1.  Domain as a Whole
     A.2.  Individual Nodes
     A.3.  Domain Boundary
     A.4.  Topology
     A.5.  Technology
     A.6.  Connection to the Internet
     A.7.  Security, Trust, and Privacy Model
     A.8.  Operations
     A.9.  Making Use of This Taxonomy
   Acknowledgements
   Contributors
   Authors' Addresses

1. Introduction 🦋

As the Internet keeps growing and diversifying, with a realistic prospect of tens of billions of nodes connected directly and indirectly, there's a noticeable trend toward network-specific and local requirements, behaviors, and semantics. 🌐 The word "local" has to be understood in a special sense here, though. Sometimes it means geographical and physical locality, like all the nodes in one building, on one campus, or in one vehicle. 🚗 Other times it means a defined set of users or nodes spread over a much wider area but pulled together by a single virtual network over the Internet, or by a single physical network running in parallel with the Internet. We'll expand on these possibilities below. To capture the topic, this document calls such networks "limited domains." 💖

A similar situation can happen for a network that's totally disconnected from the Internet, but that's not our direct concern here. Still, it shouldn't be forgotten that interoperability is needed even within a disconnected network. 🙈

Some people are worried about the Internet splintering along political or linguistic boundaries through mechanisms that block the free flow of information. That's not what this document is about. It doesn't discuss filtering mechanisms (see [RFC7754]), and it doesn't apply to protocols designed for use across the whole Internet. It's only concerned with domains that have specific technical requirements. 🎯

The word "domain" in this document does not refer to naming domains in the DNS, although sometimes a limited domain might happen to line up with a DNS domain. 🏷️ For example, with a "split horizon" DNS configuration [RFC6950], the split might sit at the edge of a limited domain. There's also a recent proposal for defining definite perimeters within the DNS namespace [DNS-PERIMETER], which might also be considered a limited domain mechanism. ✨

Another term that gets used in some contexts is "controlled environment." 🧪 For example, [RFC8085] uses it to delimit the operational scope within which a particular tunnel encapsulation might be used. A specific example is GRE-in-UDP encapsulation [RFC8086], which explicitly states that "The controlled environment has less restrictive requirements than the general Internet." 💅 So, for instance, non-congestion-controlled traffic might be acceptable within the controlled environment. The same phrase has been used to delimit the useful scope of quality-of-service protocols [RFC6398]. It's not necessarily the case that protocols will fail to operate outside the controlled environment. It's more that they might not operate optimally. In this document, we assume that "limited domain" and "controlled environment" mean the same thing in practice. The term "managed network" has been used in a similar way, e.g., [RFC6947]. And in the context of secure multicast, a "group domain of interpretation" is defined by [RFC6407]. 🔐

There are even more definitions of types of domains in the routing area, such as [RFC4397], [RFC4427], and [RFC4655]. So we conclude that the notion of a limited domain is very widespread across many aspects of Internet technology. It's giving everywhere, honestly. 👑

The requirements of limited domains depend on the deployment scenario. Policies, default parameters, and the options supported may all vary. The style of network management can also vary, between a completely unmanaged network, one with fully autonomic management, one with traditional central management, and mixtures of the above. 🤖 Finally, the requirements and solutions for security and privacy may vary too. 🔒

This document analyzes and discusses some of the consequences of this trend and how it may impact the idea of universal interoperability on the Internet. 🌈 First, we list examples of limited domain scenarios and technical solutions for limited domains, with the main focus on the Internet layer of the protocol stack. An appendix provides a taxonomy of the features you'll find in limited domains. With that background, we discuss the resulting challenge to the idea that all Internet standards must be universal in scope and applicability. 💥 To the contrary, we assert that some protocols, although they need to be standardized and interoperable, also need to be specifically limited in their applicability. This means the concepts of a limited domain, and of its membership, need to be formalized and supported by secure mechanisms. 🫧 While this document doesn't propose a design for such mechanisms, it does outline some functional requirements. 🧚

This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF, but it is not the product of IETF consensus. 💜

2. Failure Modes in Today's Internet 💀

Today, the Internet doesn't have a well-defined concept of limited domains, and one result is that certain protocols and features fail on certain paths. 😭 Earlier analyses of this topic focused either on the loss of transparency of the Internet [RFC2775] [RFC4924] or on the middleboxes responsible for that loss [RFC3234] [RFC7663] [RFC8517]. Unfortunately, the problems persist both in application protocols and even in very fundamental mechanisms. 🙃 For example, the Internet is not transparent to IPv6 extension headers [RFC7872], and Path MTU Discovery has been unreliable for many years [RFC2923] [RFC4821]. IP fragmentation is also unreliable [FRAG-FRAGILE], and problems in TCP MSS negotiation have been reported [IPV6-USE-MINMTU]. 🧩

On the security side, firewalls get inserted at domain boundaries all the time. Humans can see them, but protocols don't know they're there. The result is arbitrary failure modes as far as the application layer is concerned. 🔥 There are operational recommendations and practices that effectively guarantee arbitrary failures in realistic scenarios [IPV6-EXT-HEADERS]. Not it. 💀

Domain boundaries that are defined administratively (for example, by address filtering rules in routers) are prone to leakage caused by human error. This is especially true if the limited domain traffic looks 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. 🎀

Investigations into the unreliability of IP fragmentation [FRAG-FRAGILE] and the filtering of IPv6 extension headers [RFC7872] strongly suggest that, at least for some protocol elements, transparency is a lost cause and middleboxes are here to stay. 🥀 In the following two sections, we show that some application environments require protocol features that cannot, or should not, cross the whole Internet. 🌸

3. Examples of Limited Domain Requirements 🎀

Okay so this section is a little tour of places where limited domain requirements are super obvious, either because of the app or because of a technical must-have 💅. It's not a complete list (we're not doing a whole encyclopedia here, bestie 🙈), and it's in no particular order, loosely going from smaller to bigger networks ✨.

  1. A home network 🏠. It's mainly unmanaged and built by a non-specialist. It has to work with devices "out of the box," exactly as the manufacturers ship them, and it has to create adequate security by default 🔒. Remote access may be required. The requirements and principles that apply here are summarized in [RFC7368] 🌸.
  2. A small office network 💼. This is sometimes basically a home network, if whoever is in charge has little or no specialist knowledge, but it may have different security and privacy requirements 👀. In other cases, it's professionally built with recommended products and configurations but still runs unmanaged. Remote access may be required.
  3. A vehicle network 🚗. The vehicle manufacturer designs this one, but it may include devices added by the vehicle's owner or operator. Some parts of the network have seriously demanding performance and reliability requirements, and those have implications for human safety 😭. Remote access may be required to certain functions but is absolutely forbidden for others 🚫. Communication with other vehicles, roadside infrastructure, and external data sources will be required. For a survey of use cases, check out [IPWAVE-NETWORKING] 🦋.
  4. Supervisory Control And Data Acquisition (SCADA) networks and other hard real-time networks ⚡. These have very specific technical requirements, including tough real-time performance targets. For numerous use cases, see [RFC8578] 📚. A building services network is one example. It's designed specifically for one building but uses standard components, and extra devices may need to be added at any time 🏢. Parts of the network may have demanding reliability requirements with implications for human safety. Remote access may be required to certain functions but is absolutely forbidden for others. An extreme example is a network for virtual reality or augmented reality, where the latency requirements are very stringent 🥽💜.
  5. Sensor networks 🌡️. The two preceding cases will both include sensors, but some networks may be limited specifically to sensors and to collecting and processing sensor data 🧚. They may sit in remote or technically challenging locations and be installed by non-specialists 🏔️.
  6. Internet-of-Things (IoT) networks 🌐. This term is super flexible and covers lots of innovative network types, including ad hoc networks that form spontaneously and some applications of 5G technology 📶. Still, it seems reasonable to expect that IoT edge networks will have special requirements and protocols that are only useful within one specific domain. Those protocols cannot run over the Internet as a whole, and for security reasons they should not 🔐. Main character energy for domain-limited protocols, ngl 👑.
  7. Constrained networks 🔋. An important subclass of IoT networks is the constrained networks in [RFC7228], where nodes are limited in power consumption and communications bandwidth. That means they're limited to using very frugal protocols 🍓.
  8. Delay-tolerant networks 🚀. These may be made of domains that are fairly isolated and short on power (deep space networks are a good example). They connect to the outside only now and then, and those connections have a very long latency [RFC4838] 🪐. Clearly, the protocol requirements and possibilities are very specialized in networks like this 🌌.
  9. "Traditional" enterprise and campus networks 🏫. These can be spread over many kilometers and across multiple separate sites, with several connections to the Internet. Honestly, it's kind of wild that the IETF appears never to have analyzed this long-established class of networks in a general way, except in connection with IPv6 deployment (see [RFC7381]) 🤭.
  10. Unsuitable standards 🙅‍♀️. In an enterprise network, the Internet-wide solution for a particular requirement might fail locally, or it might be way more complicated than necessary 😩. For example, the complexity that comes with Interactive Connectivity Establishment (ICE) [RFC8445] isn't justified inside a network like this. ICE also can't be used in some cases, because candidate addresses aren't known until a call is established, so a different local solution is essential [RFC6947] 💅.
  11. Managed wide-area networks run by service providers for enterprise services 🌍. These cover Layer 2 (Ethernet, etc.) point-to-point pseudowires, multipoint Layer 2 Ethernet VPNs using Virtual Private LAN Service (VPLS) or Ethernet VPN (EVPN), and Layer 3 IP VPNs 🧩. They're usually defined by service-level agreements for availability, packet loss, and possibly multicast service 📝. This is different from the previous case because they mostly run over MPLS infrastructures, and the IETF has already defined the requirements for these services well 💖.
  12. Data centers and hosting centers, or distributed services acting as such centers 🖥️. These need high performance, security, and privacy, and they typically include large numbers of independent "tenant" networks layered over shared infrastructure 🏘️.
  13. Content Delivery Networks (CDNs) 📦. These are made of distributed data centers and the paths between them, spanning thousands of kilometers, with numerous connections to the Internet 🛰️.
  14. Massive Web Service Provider Networks 👑. This is a small class of networks with famous, trademarked names. They combine aspects of distributed enterprise networks, data centers, and CDNs 🤯. They have their own international networks that bypass the generic carriers. Like CDNs, they have numerous connections to the Internet, and they typically offer a tailored service in each economy 🌈.

Three other aspects aren't tied to specific network types, but they still depend heavily on the concept of limited domains 🦄:

  1. Many of the network types above can be extended throughout the Internet using a variety of virtual private network (VPN) techniques 🔗. So limited domains can overlap each other in arbitrary ways by using virtualization. As noted above in the discussion of controlled environments, specific tunneling and encapsulation techniques may be tailored for use within a given domain 🎁.
  2. Intent-Based Networking 🧠. In this concept, a network domain is configured and managed according to an abstract policy known as "Intent," so the network performs as required [IBN-CONCEPTS] ✨. Whatever technologies support this get applied within the domain boundary, even if the services in the domain are globally accessible 🌏.
  3. Network Slicing 🍰. A network slice is a form of virtual network made of a managed set of resources carved off from a larger network [ENHANCED-VPN]. This is expected to be a big deal in 5G deployments [USER-PLANE-PROTOCOL] 📱. Whatever technologies support slicing will need a clear definition of a given slice's boundary within a larger domain 🪄.

Okay, so common solutions and common standards are obviously the dream whenever possible 💖. But it's getting harder and harder to do that while still meeting the wildly different requirements listed above 😵‍💫. Still, whenever new protocols and protocol extensions get proposed, there's a tendency to always ask, "How will this work across the open Internet?" 🌐 This document suggests that this isn't always the best question 🙃. Some protocols and extensions aren't meant to work across the open Internet at all. Their requirements and semantics are deliberately limited (in the sense defined above) 🔒.

A common argument is that if a protocol is meant for limited use, there's a very high chance it will actually get used, or misused, in other scenarios, including the so-called open Internet 👀. That's undoubtedly true, and it means limited use is not an excuse for bad design or poor security 🚨. In fact, a limited use requirement can add complexity to both the protocol and its security design, as discussed later 💀.

Even so, because of how many limited domains with specific requirements are emerging, specific standards (and ad hoc standards) will probably show up for different types of domains 🧩. There will be attempts to capture each market sector, but the market will demand standardized solutions within each sector 🛍️. On top of that, operational choices will be made that can only work within a limited domain 🛠️. The history of RSVP [RFC2205] shows that a standard defined as if it could work over the open Internet might not actually do so 😬. In general, we can no longer assume that a protocol designed under classical Internet guidelines will work reliably across the network as a whole 💔. However, the "open Internet" must remain the universal method of interconnection 🌍✨. Reconciling those two things is a major challenge, bestie 🫶.

4. Examples of Limited Domain Solutions 🦋

okay so this section is a tour of real limited domain solutions that people have proposed or already defined 💅 It intentionally skips Layer 2 technology, because by definition that stuff only applies to limited domains. ngl though, with things like Transparent Interconnection of Lots of Links (TRILL) [RFC6325] or Shortest Path Bridging [SPB], Layer 2 domains might get really big 😭

  1. Differentiated Services. This mechanism [RFC2474] lets a network assign locally significant values to the 6-bit Differentiated Services Code Point field in any IP packet 🎀 There are some recommended code point values for specific per-hop queue management behaviors, but they're specifically meant to be domain-specific code points. Traffic gets classified, conditioned, and mapped or re-marked at domain boundaries, unless there's an inter-domain agreement that makes mapping or re-marking unnecessary.
  2. Integrated Services. It's not intrinsic to the design of RSVP [RFC2205], but after many years of experience it's clear that Integrated Services can only be deployed successfully within a limited domain that's configured with adequate equipment and resources 🔥
  3. Network function virtualization. As described in [RFC8568], this general concept is an open research topic where virtual network functions get orchestrated as part of a distributed system 🧚 Orchestration inevitably applies to an administrative domain of some kind, even though cross-domain orchestration is also a research area.
  4. Service Function Chaining (SFC). This technique [RFC7665] assumes services in a network are built as sequences of individual service functions inside a specific SFC-enabled domain, like a 5G domain 🌈 As that RFC puts it: "Specific features may need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC information". A Network Service Header (NSH) [RFC8300] encapsulates packets flowing through the service function chain, and the RFC says: "The intended scope of the NSH is for use within a single provider's operational domain." very scoped, very intentional 💜
  5. Firewall and Service Tickets (FAST). These tickets would ride along with a packet to claim the right to traverse a network or request a specific network service [FAST]. They'd only be meaningful within one particular domain 🎫
  6. Data Center Network Virtualization Overlays. A common requirement in data centers that host lots of tenants (clients) is giving each one its own secure private network, all running over the same physical infrastructure 🏢 [RFC8151] describes various use cases for this, and specifications are under development. These include use cases where the tenant network is physically split across several data centers, but it has to appear to the user as one single secure domain 🫶
  7. Segment Routing. This is a technique that "steers a packet through an ordered list of instructions, called segments" [RFC8402] 🛤️ The semantics of these instructions are explicitly local to a segment routing domain, or even to a single node. Technically, the segments are represented as an MPLS label or an IPv6 address, which clearly adds a semantic interpretation to them inside the domain 🤓
  8. Autonomic Networking. As explained in [REF-MODEL], an autonomic network is also a security domain, with an autonomic control plane [ACP] used by autonomic service agents 🤖 These agents manage technical objectives, which may be locally defined, subject to domain-wide policy. So the domain boundary matters for both security and protocol purposes, no cap 🔐
  9. Homenet. As shown in [RFC7368], a home networking domain has specific protocol needs that are different from an enterprise network or the Internet as a whole 🏠 These include the Home Network Control Protocol (HNCP) [RFC7788] and a naming and discovery solution [HOMENET-NAMING].
  10. Creative uses of IPv6 features. As IPv6 enters more general use, engineers notice it has way more flexibility than IPv4 🦄 Innovative suggestions have been made for:
    • The flow label, e.g., [RFC6294].
    • Extension headers, e.g., for segment routing [RFC8754] or Operations, Administration, and Maintenance (OAM) marking [IPV6-ALT-MARK].
    • Meaningful address bits, e.g., [EMBEDDED-SEMANTICS]. Also, segment routing uses IPv6 addresses as segment identifiers with specific local meanings [RFC8402].
    • If segment routing is used for network programming [SRV6-NETWORK], IPv6 extension headers can support rather complex local functionality.

The extension header is especially interesting, because its existence has been a major "selling point" for IPv6 🛍️ But new extension headers are notorious for being virtually impossible to deploy across the whole Internet [RFC7045] [RFC7872] 😭 It's worth noting that extension header filtering is considered an important security issue [IPV6-EXT-HEADERS]. There's considerable appetite among vendors and operators for flexibility in defining extension headers for use in limited or specialized domains, e.g., [IPV6-SRH], [BIGIP], and [APP-AWARE] 💅 Locally significant hop-by-hop options are also envisaged, ones that would be understood by routers inside a domain but not elsewhere, e.g., [IN-SITU-OAM] 👀

  1. Deterministic Networking (DetNet). The Deterministic Networking Architecture [RFC8655] and encapsulation [DETNET-DATA-PLANE] aim to support flows with extremely low data loss rates and bounded latency, but only within a part of the network that is "DetNet aware" ⏱️ So, just like Differentiated Services above, the concept of a domain is fundamental ✨
  2. Provisioning Domains (PvDs). An architecture for Multiple Provisioning Domains has been defined [RFC7556] so hosts attached to multiple networks can learn explicit details about the services each of those networks provides 🧩
  3. Address Scopes. For completeness, particularly in IPv6, some addresses have explicitly limited scope 📍 Link-local addresses are limited to a single physical link [RFC4291], and Unique Local Addresses [RFC4193] are limited to a somewhat loosely defined local site scope. Site-local addresses were defined before, but they got obsoleted precisely because of "the fuzzy nature of the site concept" [RFC3879] 🙈 Multicast addresses also have explicit scoping [RFC4291].
  4. Application-layer example. Think streaming services like IPTV infrastructures that rely on standard protocols, but where access isn't available globally 📺

All of these suggestions are only viable within a specified domain. Nevertheless, all of them are clearly intended for multivendor implementation across thousands or millions of network domains, so interoperable standardization would be beneficial 🌸 This argument might seem irrelevant to private or proprietary implementations, but those have a strong tendency to become de facto standards if they succeed, so the arguments of this document still apply 💖

5. The Scope of Protocols in Limited Domains ✨

okay so, one big thing that's happening is that some protocols are going to get designed, extended, or configured so they only work properly between end systems inside these limited domains 🏠. Some existing standards kind of encourage this, and so does handing out code points for local or experimental use 🧪. Either way, it can't really be stopped 🤷‍♀️. Also, when the IETF gets behind things like Service Function Chaining, Segment Routing, and Deterministic Networking, it's basically cheering these deployments on 📣. And if the Internet of Things really takes off, it seems inevitable that millions of edge networks full of totally new kinds of nodes will hop onto the Internet 🤖. Every single one of those edge networks will be its own limited domain 💅.

So it's totally fair to ask whether some protocols or protocol extensions should be standardized to interoperate only inside a limited-domain boundary 🦋. These protocols wouldn't need to interoperate across the whole Internet 🌍. Once you have multiple domains running the same limited-domain protocol, a few different scenarios can happen 👀:

A. If a domain gets split into two parts that talk to each other directly over the Internet at the IP layer (so no tunnel is wrapping the packets) 🌐, a limited-domain protocol can run between those two parts no matter how special it is, as long as it follows standard IP formats and firewalls don't block it 🛡️. A simple example is any protocol using a port number assigned to a specific non-IETF protocol 🔌.

This kind of protocol could reasonably be called an "inter-domain" protocol, because the Internet is transparent to it 🪟. Even if it only makes sense inside those two limited domains, the Internet just lets it pass through. Honestly, this is nothing new for the Internet architecture 😌.

B. If a limited-domain protocol doesn't follow standard IP formats (like, say, if it has a non-standard IPv6 extension header) 🙈, it can't be run between two domains connected directly over the Internet at the IP layer 🚫.

This could reasonably be called an "intra-domain" protocol, and for it the Internet is opaque 🧱.

C. If a limited-domain protocol is clearly specified to be invalid outside its domain of origin, then neither scenario A nor scenario B applies 🚧. The only solution left is a single virtual domain 🧚. For example, an encapsulating tunnel between two domains could be used to create that virtual domain 🎀. Also, nodes at the domain boundary must drop all packets that use the limited-domain protocol 🗑️.

D. If a limited-domain protocol has domain-specific variants, so implementations in different domains couldn't interoperate even if those domains got unified some way like in scenario C 😬, then the protocol isn't interoperable in the normal sense 💔. If two domains using it got merged, the protocol might fail unpredictably 💀. A simple example is any protocol using a port number assigned for experimental use 🧪. Related issues are discussed in [RFC5704], including the complex example of Transport MPLS 🧵.

Let's look at a super widespread example: Differentiated Services [RFC2474] 💁‍♀️. Any value at all in the 6 bits of the Differentiated Services Code Point (DSCP) makes a packet well formed, so it falls into scenario A ✅. BUT, because the semantics of DSCP values are only locally significant, that same packet also falls into scenario D 😭. Honestly, Differentiated Services only work across domain boundaries if the operators have a matching agreement with each other 🤝. Otherwise, you need a specific gateway function for it to mean anything 🚪. Way more detail on this is in [RFC2474] and [RFC8100] 📚.

Now for a more provocative example 🌶️: take the proposal in [IPV6-SRH] that the restrictions in [RFC8200] should be relaxed so IPv6 extension headers can be inserted on the fly into IPv6 packets 🪄. If this gets done so the affected packets can never leave the specific limited domain where they were modified, scenario C applies 🔒. And if the meaning of the inserted headers is defined locally, scenario D also applies 📍. In neither case does the Internet outside the limited domain get disturbed 🌸. But inside the domain, nodes have to understand the variant protocol 🧠. Unless it gets standardized as a formal version, with all the complexity that comes with that [RFC6709], the nodes all have to be non-standard to the extent of understanding the variant protocol 😵‍💫. For the IPv6 header insertion example, that means not complying with [RFC8200] inside the domain, even if the inserted headers are fully compliant themselves 🙃. Setting formal compliance aside, deviations like this from documented standard behavior might lead to some serious debugging headaches 🤯. The possible practical impact of the header insertion example is explored in [IN-FLIGHT-IPV6] 🔍.

The FAST proposal mentioned in Section 4, Paragraph 2, Item 5 is also a really interesting case study 🧐. The semantics of FAST tickets [FAST] have limited scope 🎟️. But they're designed in a way that, in principle, lets them traverse the open Internet 🌊. They could work as standardized IPv6 hop-by-hop options, or even as a proposed form of IPv4 extension header [IPV4-EXT-HEADERS]. Whether these options can be used reliably across the open Internet is still unclear 🤔 [IPV6-EXT-HEADERS].

So here's the takeaway: it's reasonable to explicitly define limited-domain protocols, either as standards or as proprietary mechanisms 🫶, as long as the definition says which of the above scenarios apply and clarifies how the domain is defined 📝. As long as all relevant standards are respected outside the domain boundary, a well-specified limited-domain protocol doesn't need to damage the rest of the Internet 💖. However, as the next section describes, mechanisms are needed to support domain membership operations 🪪.

Note that this isn't a recommendation to ditch the normal goal that a standardized protocol should be global in scope and able to interoperate across the open Internet 🌈. It's just recognizing that this won't always be the case 💅✨.

6. Functional Requirements of Limited Domains ✨

okay so bestie, this part is where things get really fun 🎀 Limited-domain protocols have already been defined in the past, and there are definitely going to be more in the future 🔮 So it's useful to think about how a protocol can know which domain it's running in, and how the boundary nodes can be spotted. There are so many aspects to a domain (the taxonomy in Appendix A is wild 🤯), but there are some features and functions that show up over and over again, so let's look at those 💅

Right now, when limited domains exist, they're basically built by carefully configuring boundary routers and firewalls 🧱 And if the domain is defined by one or more address prefixes, the address assignment to hosts also has to be managed really carefully. Honestly? That's super error-prone 😭 A mix of configuration mistakes and default routing can let unwanted traffic slip right out of the domain. So our main assumption is that domains should be able to get created and managed automatically, with minimal human configuration 🦋 Let's talk about what that automation needs.

First up, picture a topology map. Any domain, virtual or physical, has a clear boundary between "inside" and "outside" 🗺️ But here's the tea: that boundary doesn't mean anything technically on its own ☕ What actually matters is whether a node is a member of the domain, and whether it sits on the edge between the domain and the rest of the Internet. So the boundary itself doesn't need an identifier, but boundary nodes face both ways, inward and outward 🫶 Inside the domain, a sending node needs to know if it's sending to something inside or outside, and a receiving node needs to know whether a packet came from inside or outside. A boundary node also needs to know which of its interfaces face inward and which face outward. And it doesn't matter whether those interfaces are physical or virtual 🌸

To really drive home that domain boundaries need to be identifiable, look at what the Deterministic Networking Problem Statement [RFC8557] says: "there is still a lack of clarity regarding the limits of a domain where a deterministic path can be set up". Honestly, that point works for way more than just deterministic networking 🙈

So with that in mind, here are some general functional requirements 📋 One assumption underpins all of them: domain membership operations should be cryptographically secured. A domain without that security can't be reliably protected from attack 🔐

Quick note: a domain without cryptographic security is basically a party with no bouncer 💀
  1. Domain Identity. A domain MUST have a unique and verifiable identifier, and effectively, this should be a public key for the domain 🔑 Without it, there's no way to secure domain operations or membership. The holder of the matching private key becomes the trust anchor for the domain 👑
  2. Nesting. It MUST be possible for domains to be nested (the network-slicing example from earlier is a good one to look at) 🪆
  3. Overlapping. It MUST be possible for nodes and links to be in more than one domain (the PvDs case mentioned above is a perfect example) 🌈
  4. Node Eligibility. It MUST be possible for a node to figure out which domain(s) it can potentially join, and on which interface(s) 🔍
  5. Secure Enrollment. A node MUST be able to enroll in a given domain through secure node identification, and acquire the relevant security credentials (authorization) for operations inside the domain 🎟️ If a node has multiple physical or virtual interfaces, enrolling each interface individually may be REQUIRED 💖
  6. Withdrawal. A node MUST be able to cancel its enrollment in a given domain 👋
  7. Dynamic Membership. Optionally, a node SHOULD be able to temporarily leave or rejoin a domain (so enrollment is persistent, but membership comes and goes) 🧚
  8. Role, implying authorization to perform a certain set of actions. A node MUST have a verifiable role. In the simplest case, the role choices are "interior node" and "boundary node" 🏠 On a boundary node, individual interfaces may have different roles, like "inward facing" and "outward facing" 🚪
  9. Peer Verification. A node MUST be able to verify whether another node is a member of the domain 🕵️‍♀️
  10. Role Verification. A node SHOULD be able to learn the verified role of another node. In particular, it should be possible for a node to find boundary nodes (the ones that interface with the Internet) 🌐
  11. Domain Data. In a domain with management requirements, it MUST be possible for a node to acquire domain policy and/or domain configuration data 📜 This would include, for example, filtering policy so inappropriate packets don't leave the domain 🛑

These requirements could form the basis for further analysis and solution design 🧠

Another question is whether individual packets inside a limited domain need to carry some kind of indicator that they belong to that domain, or whether that information will just be implicit in the IP addresses of the packet 🤔 A related question is whether individual packets need cryptographic authentication. Both of these are for further study 🔬

7. Security Considerations 🔐

Okay, this section is SO important, so pay attention bestie 😤 As noted above, a protocol meant for limited use may well get used on the open Internet by accident, so limited use is NOT an excuse for poor security 🚨 In fact, a limited-use requirement can actually add complexity to the security design 💀

Often, the boundary of a limited domain also acts as a security boundary. Specifically, it serves as a trust boundary and as a boundary of authority for defining capabilities ✨ For example, segment routing [RFC8402] explicitly uses the concept of a "trusted domain" in exactly this way 🙌 Inside the boundary, limited-domain protocols or protocol features will be useful, but in many cases they'll be meaningless or even harmful if they enter or leave the domain 😱

The boundary also provides confidentiality and privacy for operational parameters that the operator doesn't want to reveal 🤫 Note that this is different from privacy protection for individual users inside the domain, so don't mix those two up 🙅‍♀️

The security model for a limited-scope protocol MUST allow for the boundary, and in particular for a trust model that changes at the boundary 🚧 Typically, credentials will need to be signed by a domain-specific authority 🖋️

8. IANA Considerations 📚

This document has no IANA actions 🦋

9. Informative References 📖

[ACP]      Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
           Control Plane (ACP)", Work in Progress, Internet-Draft,
           draft-ietf-anima-autonomic-control-plane-27, 2 July 2020,
           <https://tools.ietf.org/html/draft-ietf-anima-autonomic-
           control-plane-27>.

[APP-AWARE]
           Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu,
           P., Liu, C., and K. Ebisawa, "Application-aware IPv6
           Networking (APN6) Encapsulation", Work in Progress,
           Internet-Draft, draft-li-6man-app-aware-ipv6-network-02, 2
           July 2020, <https://tools.ietf.org/html/draft-li-6man-app-
           aware-ipv6-network-02>.

[BIGIP]    Li, R., "HUAWEI - Big IP Initiative", 2018,
           <https://www.iaria.org/announcements/HuaweiBigIP.pdf>.

[DETNET-DATA-PLANE]
           Varga, B., Farkas, J., Berger, L., Malis, A., and S.
           Bryant, "DetNet Data Plane Framework", Work in Progress,
           Internet-Draft, draft-ietf-detnet-data-plane-framework-06,
           6 May 2020, <https://tools.ietf.org/html/draft-ietf-
           detnet-data-plane-framework-06>.

[DNS-PERIMETER]
           Crocker, D. and T. Adams, "DNS Perimeter Overlay", Work in
           Progress, Internet-Draft, draft-dcrocker-dns-perimeter-01,
           11 June 2019, <https://tools.ietf.org/html/draft-dcrocker-
           dns-perimeter-01>.

[EMBEDDED-SEMANTICS]
           Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang,
           "Analysis of Semantic Embedded IPv6 Address Schemas", Work
           in Progress, Internet-Draft, draft-jiang-semantic-prefix-
           06, 15 July 2013, <https://tools.ietf.org/html/draft-
           jiang-semantic-prefix-06>.

[ENHANCED-VPN]
           Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A
           Framework for Enhanced Virtual Private Networks (VPN+)
           Service", Work in Progress, Internet-Draft, draft-ietf-
           teas-enhanced-vpn-06, 13 July 2020,
           <https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-
           06>.

[FAST]     Herbert, T., "Firewall and Service Tickets", Work in
           Progress, Internet-Draft, draft-herbert-fast-04, 10 April
           2019, <https://tools.ietf.org/html/draft-herbert-fast-04>.

[FRAG-FRAGILE]
           Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
           and F. Gont, "IP Fragmentation Considered Fragile", Work
           in Progress, Internet-Draft, draft-ietf-intarea-frag-
           fragile-17, 30 September 2019,
           <https://tools.ietf.org/html/draft-ietf-intarea-frag-
           fragile-17>.

[HOMENET-NAMING]
           Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming
           and Service Discovery Architecture", Work in Progress,
           Internet-Draft, draft-ietf-homenet-simple-naming-03, 23
           October 2018, <https://tools.ietf.org/html/draft-ietf-
           homenet-simple-naming-03>.

[IBN-CONCEPTS]
           Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura,
           "Intent-Based Networking - Concepts and Definitions", Work
           in Progress, Internet-Draft, draft-irtf-nmrg-ibn-concepts-
           definitions-01, 9 March 2020,
           <https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts-
           definitions-01>.

[IN-FLIGHT-IPV6]
           Smith, M., Kottapalli, N., Bonica, R., Gont, F., and T.
           Herbert, "In-Flight IPv6 Extension Header Insertion
           Considered Harmful", Work in Progress, Internet-Draft,
           draft-smith-6man-in-flight-eh-insertion-harmful-02, 30 May
           2020, <https://tools.ietf.org/html/draft-smith-6man-in-
           flight-eh-insertion-harmful-02>.

[IN-SITU-OAM]
           Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
           Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B.,
           Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati,
           "In-situ OAM IPv6 Options", Work in Progress, Internet-
           Draft, draft-ietf-ippm-ioam-ipv6-options-02, 13 July 2020,
           <https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-
           options-02>.

[IPV4-EXT-HEADERS]
           Herbert, T., "IPv4 Extension Headers and Flow Label", Work
           in Progress, Internet-Draft, draft-herbert-ipv4-eh-01, 2
           May 2019,
           <https://tools.ietf.org/html/draft-herbert-ipv4-eh-01>.

[IPV6-ALT-MARK]
           Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
           Pang, "IPv6 Application of the Alternate Marking Method",
           Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
           alt-mark-01, 22 June 2020, <https://tools.ietf.org/html/
           draft-ietf-6man-ipv6-alt-mark-01>.

Okay bestie, the reference shelf is absolutely stacked 📚✨ Here's the rest of the list, with every title, number, and link kept exactly as it was 💖

   [RFC8557]  Finn, N. and P. Thubert, "Deterministic Networking Problem
              Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
              <https://www.rfc-editor.org/info/rfc8557>.

   [RFC8568]  Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM.,
              Aranda, P., and P. Lynch, "Network Virtualization Research
              Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019,
              <https://www.rfc-editor.org/info/rfc8568>.

   [RFC8578]  Grossman, E., Ed., "Deterministic Networking Use Cases",
              RFC 8578, DOI 10.17487/RFC8578, May 2019,
              <https://www.rfc-editor.org/info/rfc8578>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [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/info/rfc8754>.

   [SPB]      "IEEE Standard for Local and metropolitan area networks -
              Bridges and Bridged Networks",
              DOI 10.1109/IEEESTD.2018.8403927, IEEE 802.1Q-2018, July
              2018, <https://ieeexplore.ieee.org/document/8403927>.

   [SRV6-NETWORK]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
              network-programming-16, 27 June 2020,
              <https://tools.ietf.org/html/draft-ietf-spring-srv6-
              network-programming-16>.

   [USER-PLANE-PROTOCOL]
              Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,
              "User Plane Protocol and Architectural Analysis on 3GPP 5G
              System", Work in Progress, Internet-Draft, draft-ietf-dmm-
              5g-uplane-analysis-03, 3 November 2019,
              <https://tools.ietf.org/html/draft-ietf-dmm-5g-uplane-
              analysis-03>.

Appendix A. Taxonomy of Limited Domains 🎀

okay bestie, this appendix is basically a giant checklist for describing a limited domain 📋✨ it's giving "here are all the questions you should ask before you build anything." the aspects we're looking at are:

  • The domain as a whole
  • The individual nodes
  • The domain boundary
  • The domain's topology
  • The domain's technology
  • How the domain connects to the Internet
  • The security, trust, and privacy model
  • Operations

we're going to go through each one, one sub-section at a time 💅

A.1. Domain as a Whole 🌸

  • Why does the domain exist? (e.g., human choice, administrative policy, orchestration requirements, technical requirements such as operational partitioning for scaling reasons)
  • If there are special requirements, are they at Layer 2, Layer 3, or an upper layer?
  • Where does the domain lie on the spectrum between completely managed by humans and completely autonomic?
  • If managed, what style of management applies? (Manual configuration, automated configuration, orchestration?)
  • Is there a policy model? (Intent, configuration policies?)
  • Does the domain provide controlled or paid service or open access?

A.2. Individual Nodes 🦋

  • Is a domain member a complete node or only one interface of a node?
  • Are nodes permanent members of a given domain, or are join and leave operations possible?
  • Are nodes physical or virtual devices?
  • Are virtual nodes general purpose or limited to specific functions, applications, or users?
  • Are nodes constrained (by battery, etc.)?
  • Are devices installed "out of the box" or pre-configured?

A.3. Domain Boundary 🧚

  • How is the domain boundary identified or defined?
  • Is the domain boundary fixed or dynamic?
  • Are boundary nodes special, or can any node be at the boundary?

A.4. Topology 🍓

  • Is the domain a subset of a Layer 2 or 3 connectivity domain?
  • Does the domain overlap other domains? (In other words, is a node allowed to be a member of multiple domains?)
  • Does the domain match physical topology, or does it have a virtual (overlay) topology?
  • Is the domain in a single building, vehicle, or campus? Or is it distributed?
  • If distributed, are the interconnections private or over the Internet?
  • In IP addressing terms, is the domain Link local, Site local, or Global?
  • Does the scope of IP unicast or multicast addresses map to the domain boundary?

A.5. Technology ⚡

  • What routing protocol(s) or different forwarding mechanisms (MPLS or other non-IP mechanism) are used?
  • In an overlay domain, what overlay technique is used (L2VPN, L3VPN, etc.)?
  • Are there specific QoS requirements?
  • Link latency - Normal or long latency links?
  • Mobility - Are nodes mobile? Is the whole network mobile?
  • Which specific technologies, such as those in Section 4, are applicable?

A.6. Connection to the Internet 🌐

  • Is the Internet connection permanent or intermittent? (Never connected is out of scope.)
  • What traffic is blocked, in and out?
  • What traffic is allowed, in and out?
  • What traffic is transformed, in and out?
  • Is secure and privileged remote access needed?
  • Does the domain allow unprivileged remote sessions?

A.7. Security, Trust, and Privacy Model 🔐

  • Must domain members be authorized?
  • Are all nodes in the domain at the same trust level?
  • Is traffic authenticated?
  • Is traffic encrypted?
  • What is hidden from the outside?

A.8. Operations 🛠️

  • Safety level - Does the domain have a critical (human) safety role?
  • Reliability requirement - Normal or 99.999%?
  • Environment - Hazardous conditions?
  • Installation - Are specialists needed?
  • Service visits - Easy, difficult, or impossible?
  • Software/firmware updates - Possible or impossible?

A.9. Making Use of This Taxonomy 💜

This taxonomy could be used to design or analyze a specific type of limited domain. For the present document, it is intended only to form a background to the scope of protocols used in limited domains and the mechanisms required to securely define domain membership and properties.

Acknowledgements 🫶

Useful comments were received from Amelia Andersdotter, Edward Birrane, David Black, Ron Bonica, Mohamed Boucadair, Tim Chown, Darren Dukes, Donald Eastlake, Adrian Farrel, Tom Herbert, Ben Kaduk, John Klensin, Mirja Kuehlewind, Warren Kumari, Andy Malis, Michael Richardson, Mark Smith, Rick Taylor, Niels ten Oever, and others. so many brilliant people, periodt 👑

Contributors ✨

   Sheng Jiang
   Huawei Technologies
   Q14, Huawei Campus
   No. 156 Beiqing Road
   Hai-Dian District, Beijing
   100095
   China

   Email: jiangsheng@huawei.com

Authors' Addresses 🎀

   Brian Carpenter
   The University of Auckland
   School of Computer Science
   University of Auckland
   PB 92019
   Auckland 1142
   New Zealand

   Email: brian.e.carpenter@gmail.com


   Bing Liu
   Huawei Technologies
   Q14, Huawei Campus
   No. 156 Beiqing Road
   Hai-Dian District, Beijing
   100095
   China

   Email: leo.liubing@huawei.com

that's the whole RFC, bestie, we made it 🌈💖

📦 where this page comes from