As the Internet continues to grow and diversify, with a realistic prospect of tens of billions of nodes being connected directly and indirectly, there is a noticeable trend towards network-specific and local requirements, behaviors, and semantics. The word "local" should be understood in a special sense, however. In some cases, it may refer to geographical and physical locality -- all the nodes in a single building, on a single campus, or in a given vehicle. In other cases, it may refer to a defined set of users or nodes distributed over a much wider area, but drawn together by a single virtual network over the Internet, or a single physical network running in parallel with the Internet. We expand on these possibilities below. To capture the topic, this document refers to such networks as "limited domains". Of course, a similar situation may arise for a network that is completely disconnected from the Internet, but that is not our direct concern here. However, it should not be forgotten that interoperability is needed even within a disconnected network.
Some people have concerns about splintering of the Internet along political or linguistic boundaries by mechanisms that block the free flow of information. That is not the topic of this document, which does not discuss filtering mechanisms (see [RFC 7754
]) and does not apply to protocols that are designed for use across the whole Internet. It is 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 in some cases, a limited domain might incidentally be congruent with a DNS domain. In particular, with a "split horizon" DNS configuration [RFC 6950
], the split might be at the edge of a limited domain. A recent proposal for defining definite perimeters within the DNS namespace [DNS-PERIMETER
] might also be considered to be a limited domain mechanism.
Another term that has been used in some contexts is "controlled environment". For example, [RFC 8085
] uses this to delimit the operational scope within which a particular tunnel encapsulation might be used. A specific example is GRE-in-UDP encapsulation [RFC 8086
], which explicitly states that "The controlled environment has less restrictive requirements than the general Internet." For example, 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 [RFC 6398
]. It is not necessarily the case that protocols will fail to operate outside the controlled environment, but rather 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., [RFC 6947
]. In the context of secure multicast, a "group domain of interpretation" is defined by [RFC 6407
Yet more definitions of types of domains are to be found in the routing area, such as [RFC 4397
], [RFC 4427
], and [RFC 4655
]. We conclude that the notion of a limited domain is very widespread in many aspects of Internet technology.
The requirements of limited domains will depend on the deployment scenario. Policies, default parameters, and the options supported may vary. Also, the style of network management may 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.
This document analyzes and discusses some of the consequences of this trend and how it may impact the idea of universal interoperability in the Internet. First, we list examples of limited domain scenarios and of technical solutions for limited domains, with the main focus being the Internet layer of the protocol stack. An appendix provides a taxonomy of the features to be found in limited domains. With this 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 needing to be standardized and interoperable, also need to be specifically limited in their applicability. This implies that the concepts of a limited domain, and of its membership, need to be formalized and supported by secure mechanisms. While this document does not 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 is not the product of IETF consensus.