rfc8799xml2.original.xml		rfc8799.xml
			<?xml version="1.0" encoding="UTF-8"?>
			<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent"
			category="info" docName="draft-carpenter-limited-domains-13"
			number="8799" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
			tocInclude="true" symRefs="true" sortRefs="true" version="3">
			<front>
			<title abbrev="Limited Domains">Limited Domains and Internet
			Protocols</title>
			<seriesInfo name="RFC" value="8799"/>
			<author fullname="Brian Carpenter" initials="B." surname="Carpenter">
			<organization abbrev="Univ. of Auckland">The University of Auckland</organ
			ization>
			<address>
			<postal>
			<extaddr>School of Computer Science</extaddr>
			<extaddr>University of Auckland</extaddr>
			<street>PB 92019</street>
			<city>Auckland</city>
			<region/>
			<code>1142</code>
			<country>New Zealand</country>
			</postal>
			<email>brian.e.carpenter@gmail.com</email>
			</address>
			</author>
			<author fullname="Bing Liu" initials="B." surname="Liu">
			<organization>Huawei Technologies</organization>
			<address>
			<postal>
			<extaddr>Q14, Huawei Campus</extaddr>
			<street>No. 156 Beiqing Road</street>
			<city>Hai-Dian District, Beijing</city>
			<code>100095</code>
			<country>China</country>
			</postal>
			<email>leo.liubing@huawei.com</email>
			</address>
			</author>
			<date month="July" year="2020"/>
			<abstract>
			<t>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 paramet
			ers,
			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 mem
			bership"
			and for mechanisms to allow nodes to join a domain securely and to find ot
			her
			members, including boundary nodes.
			</t>
			<t>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.</t>
			</abstract>
			</front>
			<middle>
			<section anchor="intro" numbered="true" toc="default">
			<name>Introduction</name>
			<t>
			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.
			</t>
			<t>Some people have concerns about splintering of the Internet along polit
			ical
			or linguistic boundaries by mechanisms that block the free flow of informat
			ion.
			That is not the topic of this document, which does not discuss filtering me
			chanisms
			(see <xref target="RFC7754" format="default"/>) and does not apply to proto
			cols that
			are designed for use across the whole Internet. It is only concerned with d
			omains
			that have specific technical requirements.</t>
			<t>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 wi
			th
			a DNS domain. In particular, with a "split horizon" DNS configuration
			<xref target="RFC6950" format="default"/>, the split might be at the edge o
			f a limited domain.
			A recent proposal for defining definite perimeters within the DNS namespace
			<xref target="I-D.dcrocker-dns-perimeter" format="default"/> might also be
			considered to be a limited
			domain mechanism.</t>
			<t>Another term that has been used in some contexts is "controlled
			environment". For example, <xref target="RFC8085" format="default"/>
			uses this to delimit the operational scope within which a particular
			tunnel encapsulation might be used. A specific example is GRE-in-UDP
			encapsulation <xref target="RFC8086" format="default"/>, 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 <xref target="RFC6398"
			format="default"/>. 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., <xref target="RFC6947" format="default"/>. In the context of
			secure multicast, a "group domain of interpretation" is defined by <xref
			target="RFC6407" format="default"/>.</t>
			<t>Yet more definitions of types of domains are to be found in the routing
			area,
			such as <xref target="RFC4397" format="default"/>, <xref target="RFC4427" f
			ormat="default"/>, and <xref target="RFC4655" format="default"/>.
			We conclude that the notion of a limited domain is very widespread in many
			aspects
			of Internet technology.</t>
			<t>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.
			</t>
			<t>
			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 do
			es
			not propose a design for such mechanisms, it does outline some
			functional requirements.
			</t>
			<t>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.</t>
			</section>
			<section anchor="fail" numbered="true" toc="default">
			<name>Failure Modes in Today's Internet</name>
			<t>Today, the Internet does not have a well-defined concept of limited
			domains. One result of this is that certain protocols and features fail
			on certain paths. Earlier analyses of this topic have focused either on
			the loss of transparency of the Internet <xref target="RFC2775"
			format="default"/> <xref target="RFC4924" format="default"/> or on the
			middleboxes responsible for that loss <xref target="RFC3234"
			format="default"/> <xref target="RFC7663" format="default"/> <xref
			target="RFC8517" format="default"/>. 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 <xref target="RFC7872" format="default"/>, and Path
			MTU Discovery has been unreliable for many years <xref target="RFC2923"
			format="default"/> <xref target="RFC4821" format="default"/>. IP
			fragmentation is also unreliable <xref
			target="I-D.ietf-intarea-frag-fragile" format="default"/>, and problems
			in TCP MSS negotiation have been reported <xref
			target="I-D.andrews-tcp-and-ipv6-use-minmtu" format="default"/>.
			</t>
			<t>On the security side, the widespread insertion of firewalls at domain
			boundaries that are perceived by humans but unknown to protocols results
			in 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 <xref
			target="I-D.ietf-opsec-ipv6-eh-filtering" format="default"/>.</t>
			<t>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.</t>
			<t>Investigations of the unreliability of IP fragmentation
			<xref target="I-D.ietf-intarea-frag-fragile" format="default"/>
			and the filtering of IPv6 extension headers <xref target="RFC7872" format="d
			efault"/>
			strongly suggest that at least for
			some protocol elements, transparency is a lost cause and middleboxes are her
			e to stay.
			In the following two sections, we show that some application environments re
			quire
			protocol features that cannot, or should not, cross the whole Internet.
			</t>
			</section>
			<section anchor="example-req" numbered="true" toc="default">
			<name>Examples of Limited Domain Requirements</name>
			<t>This section describes various examples where limited domain requiremen
			ts can
			easily be identified, either based on an application scenario or on a
			technical imperative. It is, of course, not a complete list, and it is
			presented in an arbitrary order, loosely from smaller to bigger.</t>
			<ol spacing="normal" type="1">
			<li>A home network. It will be mainly unmanaged, constructed by a non-sp
			ecialist.
			It must work with devices "out of the box" as shipped by their manufacture
			rs
			and must create adequate security by default. Remote access may be require
			d.
			The requirements and applicable principles are summarized in <xref target=
			"RFC7368" format="default"/>.
			</li>
			<li>A small office network. This is sometimes very similar to a home net
			work, if whoever
			is in charge has little or no specialist knowledge, but may have
			differing security and privacy requirements. In other cases, it may be pro
			fessionally
			constructed using recommended products and configurations but operate unma
			naged.
			Remote access may be required.
			</li>
			<li>A vehicle network. This will be designed by the vehicle
			manufacturer but may include devices added by the vehicle's owner or
			operator. Parts of the network will have demanding performance and
			reliability requirements with implications for human safety. Remote
			access may be required to certain functions but absolutely forbidden
			for others. Communication with other vehicles, roadside
			infrastructure, and external data sources will be required. See <xref
			target="I-D.ietf-ipwave-vehicular-networking" format="default"/> for a
			survey of use cases.</li>
			<li>Supervisory Control And Data Acquisition (SCADA) networks and other hard
			real-time networks. These will exhibit specific technical requirements,
			including tough real-time performance targets. See, for example, <xref
			target="RFC8578" format="default"/> for numerous use cases. An example is a
			building services network. This will be designed specifically for a
			particular building but using standard components. Additional 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 absolutely forbidden for others. An
			extreme example is a network used for virtual reality or augmented reality
			applications where the latency requirements are very stringent.</li>
			<li>Sensor networks. The two preceding cases will all include sensors,
			but some networks may be specifically limited to sensors and the
			collection and processing of sensor data. They may be in remote or
			technically challenging locations and installed by
			non-specialists.</li>
			<li>Internet-of-Things (IoT) networks. While this term is very
			flexible and covers many innovative types of networks, including ad hoc
			networks that are formed spontaneously and some applications of 5G
			technology, it seems reasonable to expect that IoT edge networks will
			have special requirements and protocols that are useful only within a
			specific domain, and that these protocols cannot, and for security
			reasons should not, run over the Internet as a whole.</li>
			<li>Constrained Networks. An important subclass of IoT networks consists
			of constrained
			networks <xref target="RFC7228" format="default"/> in which the nodes
			are limited in power consumption and communications bandwidth and are
			therefore limited to using very frugal protocols.</li>
			<li>Delay-tolerant networks. These may consist of domains that are relat
			ively
			isolated and constrained in power (e.g., deep space networks) and are
			connected only intermittently to the outside, with a very long latency
			on such connections <xref target="RFC4838" format="default"/>. Clearly,
			the protocol requirements and possibilities are very specialized in
			such networks.</li>
			<li>"Traditional" enterprise and campus networks, which may be spread
			over many kilometers and over multiple separate sites, with multiple
			connections to the Internet. Interestingly, the IETF appears never to
			have analyzed this long-established class of networks in a general
			way, except in connection with IPv6 deployment (e.g., <xref
			target="RFC7381" format="default"/>).</li>
			<li>Unsuitable standards. A situation that can arise in an enterprise
			network is that the Internet-wide solution for a particular
			requirement may either fail locally or be much more complicated than
			is necessary. An example is that the complexity induced by a mechanism
			such as Interactive Connectivity Establishment (ICE) <xref
			target="RFC8445" format="default"/> is not justified within such a
			network. Furthermore, ICE cannot be used in some cases because
			candidate addresses are not known before a call is established, so a
			different local solution is essential <xref target="RFC6947"
			format="default"/>.</li>
			<li>Managed wide-area networks run by service providers for enterprise
			services such as 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. These are generally
			characterized
			by service-level agreements for availability, packet loss, and
			possibly multicast service. These are different from the previous
			case in that they mostly run over MPLS infrastructures, and the
			requirements for these services are well defined by the IETF.</li>
			<li>Data centers and hosting centers, or distributed services acting
			as such centers. These will have high performance, security, and
			privacy requirements and will typically include large numbers of
			independent "tenant" networks overlaid on shared infrastructure.</li>
			<li>Content Delivery Networks (CDNs), comprising distributed data center
			s and the paths
			between them, spanning thousands of kilometers, with numerous connections
			to the Internet.</li>
			<li>Massive Web Service Provider Networks. This is a small class of
			networks with well-known trademarked names, combining aspects of
			distributed enterprise networks, data centers, and CDNs. They have
			their own international networks bypassing the generic carriers. Like
			CDNs, they have numerous connections to the Internet, typically
			offering a tailored service in each economy. </li>
			</ol>
			<t>Three other aspects, while not tied to specific network types, also str
			ongly
			depend on the concept of limited domains:</t>
			<ol spacing="normal" type="1">
			<li>Many of the above types of networks may be extended throughout
			the Internet by a variety of virtual private network (VPN) techniques.
			Therefore, we argue that limited domains may overlap each other in an arbitr
			ary
			fashion by use of virtualization techniques. As noted above in the discussio
			n of
			controlled environments, specific tunneling and encapsulation techniques may
			be tailored for use within a given domain.</li>
			<li>Intent-Based Networking. In this concept, a network domain is
			configured and managed in accordance with an abstract policy known as
			"Intent" to ensure that the network performs as required <xref
			target="I-D.irtf-nmrg-ibn-concepts-definitions" format="default"/>.
			Whatever technologies are used to support this will be applied
			within the domain boundary, even if the services supported in the
			domain are globally accessible.</li>
			<li>Network Slicing. A network slice is a form of virtual network that
			consists of a managed set of resources carved off from a larger
			network <xref target="I-D.ietf-teas-enhanced-vpn" format="default"/>.
			This is expected to be significant in 5G deployments <xref
			target="I-D.ietf-dmm-5g-uplane-analysis" format="default"/>. Whatever
			technologies are used to support slicing will require a clear
			definition of the boundary of a given slice within a larger
			domain.</li>
			</ol>
			<t>While it is clearly desirable to use common solutions, and therefore co
			mmon standards,
			wherever possible, it is increasingly difficult to do so while satisfying th
			e widely varying
			requirements outlined above.
			However, there is a tendency when new protocols and protocol extensions are
			proposed to always ask the question "How will this work across the open Inte
			rnet?"
			This document suggests that this is not always the best question. There are
			protocols and extensions that are not intended to work across the open Inter
			net.
			On the contrary, their requirements and semantics are specifically limited (
			in the
			sense defined above).
			</t>
			<t>A common argument is that if a protocol is intended for limited use, th
			e chances are
			very high that it will in fact be used (or misused) in other scenarios inclu
			ding 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 requiremen
			t potentially
			adds complexity to both the protocol and its security design, as discussed l
			ater.</t>
			<t>Nevertheless, because of the diversity of limited domains with
			specific requirements that is now emerging, specific standards (and ad
			hoc standards) will probably emerge for different types of domains. There
			will be attempts to capture each market sector, but the market will
			demand standardized solutions within each sector. In addition,
			operational choices will be made that can in fact only work within a
			limited domain. The history of RSVP <xref target="RFC2205"
			format="default"/> illustrates that a standard defined as if it could
			work over the open Internet might not in fact do so. In general, we can
			no longer assume that a protocol designed according to classical
			Internet guidelines will in fact work reliably across the network as a
			whole. However, the "open Internet" must remain as the universal method
			of interconnection. Reconciling these two aspects is a major
			challenge.</t>
			</section>
			<section anchor="example-sol" numbered="true" toc="default">
			<name>Examples of Limited Domain Solutions</name>
			<t>This section lists various examples of specific limited domain
			solutions that have been proposed or defined. It intentionally does not
			include Layer 2 technology solutions, which by definition apply to
			limited domains. It is worth noting, however, that with recent
			developments such as Transparent Interconnection of Lots of Links
			(TRILL) <xref target="RFC6325" format="default"/> or Shortest Path
			Bridging <xref target="SPB" format="default"/>, Layer 2 domains may
			become very large.</t>
			<ol spacing="normal" type="1">
			<li>Differentiated Services. This mechanism <xref target="RFC2474" forma
			t="default"/>
			allows a network to assign locally significant
			values to the 6-bit Differentiated Services Code Point
			field in any IP packet.
			Although there are some recommended code point values for specific per-hop
			queue management behaviors, these are specifically intended to be
			domain-specific code points with traffic being classified, conditioned, and
			mapped or re-marked at domain boundaries (unless there is an inter-domain
			agreement that makes mapping or re-marking unnecessary).</li>
			<li>Integrated Services. Although it is not intrinsic in
			the design of RSVP <xref target="RFC2205" format="default"/>, it is clear
			from many years' experience that Integrated Services can only
			be deployed successfully within a limited domain that is
			configured with adequate equipment and resources.</li>
			<li>Network function virtualization. As described in
			<xref target="RFC8568" format="default"/>,
			this general concept is an open research topic in which
			virtual network functions are orchestrated as part of
			a distributed system. Inevitably, such orchestration applies
			to an administrative domain of some kind, even though
			cross-domain orchestration is also a research area.
			</li>
			<li>Service Function Chaining (SFC). This technique <xref
			target="RFC7665" format="default"/> assumes that services within a
			network are constructed as sequences of individual service functions
			within a specific SFC-enabled domain such as a 5G domain. As that RFC
			states: "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) <xref target="RFC8300"
			format="default"/> is used to encapsulate packets flowing through the
			service function chain: "The intended scope of the NSH is for use
			within a single provider's operational domain."
			</li>
			<li anchor="fast">Firewall and Service Tickets (FAST). Such tickets woul
			d accompany a packet
			to claim the right to traverse a network or request a specific network
			service <xref target="I-D.herbert-fast" format="default"/>.
			They would only be meaningful within a particular domain.</li>
			<li>Data Center Network Virtualization Overlays. A common requirement in
			data
			centers that host many tenants (clients) is to provide each one with a secur
			e
			private network, all running over the same physical infrastructure.
			<xref target="RFC8151" format="default"/> describes various use cases for th
			is, and specifications
			are under development. These include
			use cases in which the tenant network is physically split over several data
			centers, but which must appear to the user as a single secure domain.
			</li>
			<li>Segment Routing. This is a technique that "steers a packet through
			an ordered list of instructions, called segments"
			<xref target="RFC8402" format="default"/>. The semantics of
			these instructions are explicitly local to a segment routing domain
			or even to a single node. Technically, these segments or instructions
			are represented as an MPLS label or an IPv6 address, which clearly
			adds a semantic interpretation to them within the domain.</li>
			<li>Autonomic Networking. As explained in <xref target="I-D.ietf-anima-r
			eference-model" format="default"/>,
			an autonomic network is also a security domain within which an autonomic
			control plane <xref target="I-D.ietf-anima-autonomic-control-plane" format="
			default"/>
			is used by autonomic service agents. These agents manage technical objective
			s,
			which may be locally defined, subject to domain-wide policy. Thus, the domai
			n
			boundary is important for both security and protocol purposes.</li>
			<li>Homenet. As shown in <xref target="RFC7368" format="default"/>, a ho
			me networking
			domain has specific protocol needs that differ from those in an enterprise
			network or the Internet as a whole. These include the Home Network Control
			Protocol (HNCP) <xref target="RFC7788" format="default"/> and a naming and d
			iscovery solution
			<xref target="I-D.ietf-homenet-simple-naming" format="default"/>.
			</li>
			<li>
			<t>Creative uses of IPv6 features.
			As IPv6 enters more general use, engineers notice that it has much more flex
			ibility
			than IPv4. Innovative suggestions have been made for:
			</t>
			<ul spacing="normal">
			<li>The flow label, e.g., <xref target="RFC6294" format="default"/>.
			</li>
			<li>Extension headers, e.g., for segment routing <xref
			target="RFC8754" format="default"/> or Operations, Administration,
			and Maintenance (OAM) marking <xref
			target="I-D.ietf-6man-ipv6-alt-mark" format="default"/>.</li>
			<li>Meaningful address bits, e.g., <xref
			target="I-D.jiang-semantic-prefix" format="default"/>. Also,
			segment routing uses IPv6 addresses as segment identifiers with
			specific local meanings <xref target="RFC8402"
			format="default"/>.</li>
			<li>If segment routing is used for network programming <xref
			target="I-D.ietf-spring-srv6-network-programming"
			format="default"/>, IPv6 extension headers can support rather
			complex local functionality.</li>
			</ul>
			<t>
			The case of the extension header is particularly interesting, since its
			existence has been a major "selling point" for IPv6, but new extension
			headers are notorious for being virtually impossible to deploy across the wh
			ole Internet <xref
			target="RFC7045" format="default"/> <xref target="RFC7872"
			format="default"/>. It is worth noting that extension header filtering is
			considered an important security issue <xref
			target="I-D.ietf-opsec-ipv6-eh-filtering" format="default"/>. There is
			considerable appetite among vendors or operators to have flexibility in
			defining extension headers for use in limited or specialized domains,
			e.g., <xref target="I-D.voyer-6man-extension-header-insertion"
			format="default"/>, <xref target="BIGIP" format="default"/>, and <xref
			target="I-D.li-6man-app-aware-ipv6-network" format="default"/>. Locally
			significant hop-by-hop options are also envisaged, that would be
			understood by routers inside a domain but not elsewhere, e.g., <xref
			target="I-D.ietf-ippm-ioam-ipv6-options" format="default"/>.</t>
			</li>
			<li>Deterministic Networking (DetNet). The Deterministic Networking Arch
			itecture
			<xref target="RFC8655" format="default"/> and encapsulation
			<xref target="I-D.ietf-detnet-data-plane-framework" format="default"/>
			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". Thus, as for
			Differentiated Services above, the concept of a domain is fundamental.
			</li>
			<li>Provisioning Domains (PvDs). An architecture for Multiple Provisioni
			ng
			Domains has been defined <xref target="RFC7556" format="default"/> to allow
			hosts attached
			to multiple networks to learn explicit details about the services
			provided by each of those networks. </li>
			<li>Address Scopes. For completeness, we mention that, particularly in I
			Pv6,
			some addresses have explicitly limited scope. In particular, link-local addr
			esses
			are limited to a single physical link <xref target="RFC4291" format="default
			"/>, and
			Unique Local Addresses <xref target="RFC4193" format="default"/> are limited
			to a somewhat loosely defined local site scope. Previously, site-local addre
			sses
			were defined, but they were obsoleted precisely because of
			"the fuzzy nature of the site concept" <xref target="RFC3879" format="defaul
			t"/>. Multicast
			addresses also have explicit scoping <xref target="RFC4291" format="default"
			/>. </li>
			<li>As an application-layer example, consider streaming services
			such as IPTV infrastructures that rely on standard protocols,
			but for which access is not globally available.</li>
			</ol>
			<t>All of these suggestions are only viable within a specified domain. Nev
			ertheless,
			all of them are clearly intended for multivendor implementation on thousands
			or millions of network domains, so interoperable standardization would be
			beneficial. This argument might seem irrelevant to private or proprietary
			implementations, but these have a strong tendency to become de facto
			standards if they succeed, so the arguments of this document still apply.</t
			>
			</section>
			<section anchor="scope" numbered="true" toc="default">
			<name>The Scope of Protocols in Limited Domains</name>
			<t>One consequence of the deployment of limited domains in the Internet
			is that some protocols will be designed, extended, or configured so that
			they only work correctly between end systems in such domains. This is
			to some extent encouraged by some existing standards and by the
			assignment of code points for local or experimental use. In any case, it
			cannot be prevented. Also, by endorsing efforts such as Service Function
			Chaining, Segment Routing, and Deterministic Networking, the IETF is in
			effect encouraging such deployments. Furthermore, it seems inevitable,
			if the Internet of Things becomes reality, that millions of edge
			networks containing completely novel types of nodes will be connected to
			the Internet; each one of these edge networks will be a limited
			domain.</t>
			<t>It is therefore appropriate to discuss whether protocols or protocol
			extensions should sometimes be standardized to interoperate only within
			a limited-domain boundary. Such protocols would not be required to
			interoperate across the Internet as a whole. Various scenarios could
			then arise if there are multiple domains using the limited-domain
			protocol in question:</t>
			<ol type="A">
			<li><t> If a domain is split into two parts connected over the Internet
			directly at the IP layer (i.e., with no tunnel encapsulating the packets), a
			limited-domain protocol could be operated between those two parts regardless
			of its special nature, as long as it respects standard IP formats and is not
			arbitrarily blocked by firewalls. A simple example is any protocol using a
			port number assigned to a specific non-IETF protocol.
			</t>
			<t>Such a protocol could reasonably be described as an "inter-domain"
			protocol because the Internet is transparent to it, even if it is meaningless
			except in the two limited domains. This is, of course, nothing new in the
			Internet architecture.
			</t>
			</li>
			<li><t>If a limited-domain protocol does not respect standard IP formats (for
			example, if it includes a non-standard IPv6 extension header), it could not be
			operated between two domains connected over the Internet directly at the IP
			layer.
			</t>
			<t>
			Such a protocol could reasonably be described as an "intra-domain" protocol,
			and the Internet is opaque to it.
			</t>
			</li>
			<li>
			<t>
			If a limited-domain protocol is clearly specified to be invalid outside its
			domain of origin, neither scenario A nor B applies. The only solution would be
			a single virtual domain. For example, an encapsulating tunnel between two
			domains could be used to create the virtual domain. Also, nodes at the domain
			boundary must drop all packets using the limited-domain protocol.
			</t>
			</li>
			<li>
			<t>
			If a limited-domain protocol has domain-specific variants, such that
			implementations in different domains could not interoperate if those domains
			were unified by some mechanism as in scenario C, the protocol is not
			interoperable in the normal sense. If two domains using it were 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
			<xref target="RFC5704" format="default"/>, including the complex example of
			Transport MPLS.
			</t>
			</li>
			</ol>
			<t>To provide a widespread example, consider Differentiated Services
			<xref target="RFC2474" format="default"/>. A packet containing any value
			whatsoever in the 6 bits of the Differentiated Services Code Point (DSCP)
			is well formed and falls into scenario A. However, because the semantics
			of DSCP values are locally significant, the packet also falls into
			scenario D. In fact, Differentiated Services are only interoperable
			across domain boundaries if there is a corresponding agreement between
			the operators; otherwise, a specific gateway function is required for
			meaningful interoperability. Much more detailed discussion is
			found in <xref target="RFC2474" format="default"/> and <xref
			target="RFC8100" format="default"/>.
			</t>
			<t>To provide a provocative example, consider the proposal in
			<xref target="I-D.voyer-6man-extension-header-insertion" format="default"/>
			that the restrictions
			in <xref target="RFC8200" format="default"/> should be relaxed to allow IPv6
			extension headers to
			be inserted on the fly in IPv6 packets. If this is done in such a way that
			the affected packets can never leave the specific limited domain in which th
			ey
			were modified, scenario C applies. If the semantic content of the inserted
			headers is locally defined, scenario D also applies. In neither case is
			the Internet outside the limited domain disturbed. However, inside the
			domain, nodes must understand the variant protocol. Unless it is standardize
			d
			as a formal version, with all the complexity that implies <xref target="RFC6
			709" format="default"/>,
			the nodes must all be non-standard to the extent of understanding
			the variant protocol. For the example of IPv6 header insertion, that
			means non-compliance with <xref target="RFC8200" format="default"/> within t
			he domain, even if the
			inserted headers are themselves fully compliant. Apart from the issue
			of formal compliance, such deviations from documented standard behavior
			might lead to significant debugging issues. The possible practical impact
			of the header insertion example is explored in
			<xref target="I-D.smith-6man-in-flight-eh-insertion-harmful" format="default
			"/>.</t>
			<t>The FAST proposal mentioned in <xref target="fast" format="default"/>
			is also an interesting case study. The semantics of FAST tickets <xref
			target="I-D.herbert-fast" format="default"/> have limited scope. However,
			they are designed in a way that, in principle, allows them to traverse the
			open Internet, as standardized IPv6 hop-by-hop options or even as a
			proposed form of IPv4 extension header <xref target="I-D.herbert-ipv4-eh"
			format="default"/>. Whether such options can be used reliably across the
			open Internet remains unclear <xref
			target="I-D.ietf-opsec-ipv6-eh-filtering" format="default"/>.</t>
			<t>We conclude that it is reasonable to explicitly define limited-domain p
			rotocols, either
			as standards or as proprietary mechanisms, as long as they describe
			which of the above scenarios apply and they clarify how the domain is define
			d.
			As long as all relevant standards are respected outside
			the domain boundary, a well-specified limited-domain protocol need not
			damage the rest of the Internet. However, as described in the next section,
			mechanisms are
			needed to support domain membership operations.</t>
			<t>Note that this conclusion is not a recommendation to abandon the normal
			goal that a standardized protocol should be global in scope and able to
			interoperate across the open Internet. It is simply a recognition
			that this will not always be the case.</t>
			</section>
			<section anchor="func" numbered="true" toc="default">
			<name>Functional Requirements of Limited Domains</name>
			<t>Noting that limited-domain protocols have been defined in the past,
			and that others will undoubtedly be defined in the future, it is useful to c
			onsider
			how a protocol can be made aware of the domain within which it operates and
			how
			the domain boundary nodes can be identified. As the taxonomy in <xref target
			="taxo" format="default"/>
			shows, there are numerous aspects to a domain. However,
			we can identify some generally required features and functions that would
			apply partially or completely to many cases.</t>
			<t>Today, where limited domains exist, they are essentially created by car
			eful
			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 combina
			tion
			of configuration errors and default routing can lead to unwanted traffic esc
			aping
			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.</t>
			<t>First, if we drew a topology map, any given domain -- virtual or
			physical -- will have a well-defined boundary between "inside" and
			"outside". However, that boundary in itself has no technical meaning.
			What matters in reality is whether a node is a member of the
			domain and whether it is at the boundary between the domain and
			the rest of the Internet. Thus, the boundary in itself does not need to
			be identified, but boundary nodes face both inwards and outwards. Inside
			the domain, a sending node needs to know whether it is sending to an
			inside or outside destination, and a receiving node needs to know
			whether a packet originated inside or outside. Also, a boundary node
			needs to know which of its interfaces are inward facing or
			outward facing. It is irrelevant whether the interfaces involved are
			physical or virtual.</t>
			<t>To underline that domain boundaries need to be identifiable, consider
			the statement from the Deterministic Networking Problem Statement <xref
			target="RFC8557" format="default"/> that "there is still a lack of
			clarity regarding the limits of a domain where a deterministic path can
			be set up". This remark can certainly be generalized.</t>
			<t>With this perspective, we can list some general functional requirements
			.
			An underlying assumption here is that domain membership operations should be
			cryptographically
			secured; a domain without such security cannot be reliably protected from at
			tack.</t>
			<ol spacing="normal" type="1">
			<li>Domain Identity. A domain must have a unique and verifiable identifi
			er;
			effectively, this should be a public key for the domain. Without this,
			there is no way to secure domain operations and domain membership.
			The holder of the corresponding private key becomes the trust anchor for the
			domain.</li>
			<li>Nesting. It must be possible for domains to be nested (see, for exam
			ple, the
			network-slicing example mentioned above).</li>
			<li>Overlapping. It must be possible for nodes and links to be in more t
			han one domain
			(see, for example, the case of PvDs mentioned above).</li>
			<li>Node Eligibility. It must be possible for a node to determine which
			domain(s)
			it can potentially join and on which interface(s).</li>
			<li>Secure Enrollment. A node must be able to enroll in a given domain
			via secure node identification and to acquire relevant security
			credentials (authorization) for operations within the domain. If a
			node has multiple physical or virtual interfaces, individual
			enrollment for each interface may be required.</li>
			<li>Withdrawal. A node must be able to cancel enrollment in a given
			domain.</li>
			<li>Dynamic Membership. Optionally, a node should be able to
			temporarily leave or rejoin a domain (i.e., enrollment is persistent
			but membership is intermittent).</li>
			<li>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". In a boundary
			node, individual interfaces may have different roles, e.g., "inward
			facing" and "outward facing".</li>
			<li>Peer Verification. A node must be able to verify whether another
			node is a member of the domain.</li>
			<li>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 (inte
			rfacing
			to the Internet).</li>
			<li>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
			to ensure that inappropriate packets do not leave the domain.</li>
			</ol>
			<t>These requirements could form the basis for further analysis and soluti
			on design.</t>
			<t>Another aspect is whether individual packets within a limited domain ne
			ed to
			carry any sort of indicator that they belong to that domain or whether this
			information will be implicit in the IP addresses of the packet. A related qu
			estion
			is whether individual packets need cryptographic authentication. This topic
			is
			for further study.</t>
			</section>
			<section anchor="security" numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>As noted above, a protocol intended for limited use may well be
			inadvertently used on the open Internet, so limited use is not an excuse f
			or
			poor security. In fact, a limited use requirement potentially adds
			complexity to the security design.</t>
			<t>Often, the boundary of a limited domain will also act as a security bou
			ndary.
			In particular, it will serve as a trust boundary and as a boundary of
			authority for defining capabilities. For example, segment routing <xref ta
			rget="RFC8402" format="default"/>
			explicitly uses the concept of a "trusted domain" in this way. Within the
			boundary,
			limited-domain protocols or protocol features will be useful, but they wil
			l in
			many cases be meaningless or harmful if they enter or leave the domain.</t
			>
			<t>The boundary also serves to provide confidentiality and privacy for ope
			rational
			parameters that the operator does not wish to reveal. Note that this is di
			stinct from
			privacy protection for individual users within the domain.</t>
			<t>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.</t>
			</section>
			<section anchor="iana" numbered="true" toc="default">
			<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
			<t/>
			</section>
			</middle>
			<back>
			<displayreference target="I-D.andrews-tcp-and-ipv6-use-minmtu" to="IPV6-USE-MINM
			TU"/>
			<displayreference target="I-D.ietf-6man-ipv6-alt-mark" to="IPV6-ALT-MARK"/>
			<displayreference target="I-D.ietf-anima-autonomic-control-plane" to="ACP"/>
			<displayreference target="I-D.jiang-semantic-prefix" to="EMBEDDED-SEMANTICS"/>
			<displayreference target="I-D.ietf-detnet-data-plane-framework" to="DETNET-DATA-
			PLANE"/>
			<displayreference target="I-D.voyer-6man-extension-header-insertion" to="IPV6-SR
			H"/>
			<displayreference target="I-D.ietf-homenet-simple-naming" to="HOMENET-NAMING"/>
			<displayreference target="I-D.ietf-ipwave-vehicular-networking" to="IPWAVE-NETWO
			RKING"/>
			<displayreference target="I-D.ietf-teas-enhanced-vpn" to="ENHANCED-VPN"/>
			<displayreference target="I-D.ietf-opsec-ipv6-eh-filtering" to="IPV6-EXT-HEADERS
			"/>
			<displayreference target="I-D.herbert-fast" to="FAST"/>
			<displayreference target="I-D.dcrocker-dns-perimeter" to="DNS-PERIMETER"/>
			<displayreference target="I-D.herbert-ipv4-eh" to="IPV4-EXT-HEADERS"/>
			<displayreference target="I-D.ietf-spring-srv6-network-programming" to="SRV6-NET
			WORK"/>
			<displayreference target="I-D.ietf-dmm-5g-uplane-analysis" to="USER-PLANE-PROTOC
			OL"/>
			<displayreference target="I-D.smith-6man-in-flight-eh-insertion-harmful" to="IN-
			FLIGHT-IPV6"/>
			<displayreference target="I-D.irtf-nmrg-ibn-concepts-definitions" to="IBN-CONCEP
			TS"/>
			<displayreference target="I-D.li-6man-app-aware-ipv6-network" to="APP-AWARE"/>
			<displayreference target="I-D.ietf-ippm-ioam-ipv6-options" to="IN-SITU-OAM"/>
			<displayreference target="I-D.ietf-intarea-frag-fragile" to="FRAG-FRAGILE"/>
			<displayreference target="I-D.ietf-anima-reference-model" to="REF-MODEL"/>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.2474.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.6294.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7368.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7665.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7045.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7788.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7872.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8300.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8151.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.2775.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.4924.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.3234.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7663.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7556.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.2923.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.4821.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7228.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.4838.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8100.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8200.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7381.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8085.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8086.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.6398.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.7754.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.2205.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.6950.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8402.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8517.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8578.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8557.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.4291.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.4193.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.3879.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.6947.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8445.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.6407.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8655.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.6325.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.6709.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.5704.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.4397.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.4427.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.4655.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8568.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8754.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.andrews-tcp-and-ipv6-use-minmtu.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-intarea-frag-fragile.xml"/>
			<xi:include
			href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
			etf-6man-ipv6-alt-mark.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-anima-autonomic-control-plane.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-anima-reference-model.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.jiang-semantic-prefix.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-detnet-data-plane-framework.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.voyer-6man-extension-header-insertion.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-homenet-simple-naming.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-ipwave-vehicular-networking.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-teas-enhanced-vpn.xml"/>
			<xi:include
			href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.i
			rtf-nmrg-ibn-concepts-definitions.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-opsec-ipv6-eh-filtering.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.herbert-fast.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.li-6man-app-aware-ipv6-network.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-ippm-ioam-ipv6-options.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.dcrocker-dns-perimeter.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.herbert-ipv4-eh.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-spring-srv6-network-programming.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.ietf-dmm-5g-uplane-analysis.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
			nce.I-D.smith-6man-in-flight-eh-insertion-harmful.xml"/>
			<reference anchor="SPB" target="https://ieeexplore.ieee.org/document/8403927">
			<front>
			<title>IEEE Standard for Local and metropolitan area networks - Bridge
			s and Bridged Networks</title>
			<seriesInfo name="IEEE" value="802.1Q-2018"/>
			<seriesInfo name='DOI' value='10.1109/IEEESTD.2018.8403927' />
			<author>
			<organization/>
			</author>
			<date month="July" year="2018"/>
			</front>
			</reference>
			<reference anchor="BIGIP" target="https://www.iaria.org/announcements/Huaw
			eiBigIP.pdf">
			<front>
			<title>HUAWEI - Big IP Initiative</title>
			<author fullname="Renwei Li" initials="R." surname="Li"/>
			<date year="2018"/>
			</front>
			</reference>
			</references>
			<section anchor="taxo" numbered="true" toc="default">
			<name>Taxonomy of Limited Domains</name>
			<t>This appendix develops a taxonomy for describing limited domains.
			Several major aspects are considered in this taxonomy:
			</t>
			<ul spacing="normal">
			<li>The domain as a whole</li>
			<li>The individual nodes</li>
			<li>The domain boundary</li>
			<li>The domain's topology</li>
			<li>The domain's technology</li>
			<li>How the domain connects to the Internet</li>
			<li>The security, trust, and privacy model</li>
			<li>Operations</li>
			</ul>
			<t>The following sub-sections analyze each of these aspects.</t>
			<section anchor="tax-whole" numbered="true" toc="default">
			<name>Domain as a Whole</name>
			<ul spacing="normal">
			<li>Why does the domain exist? (e.g., human choice, administrative pol
			icy,
			orchestration requirements, technical requirements such as
			operational partitioning for scaling reasons)</li>
			<li>If there are special requirements, are they at Layer 2,
			Layer 3, or an upper layer?</li>
			<li>Where does the domain lie on the spectrum between completely manag
			ed by humans and completely autonomic?</li>
			<li>If managed, what style of management applies? (Manual configuratio
			n,
			automated configuration, orchestration?)</li>
			<li>Is there a policy model? (Intent, configuration policies?)</li>
			<li>Does the domain provide controlled or paid service or open access?
			</li>
			</ul>
			</section>
			<section anchor="tax-nodes" numbered="true" toc="default">
			<name>Individual Nodes</name>
			<ul spacing="normal">
			<li>Is a domain member a complete node or only one interface of a node
			?</li>
			<li>Are nodes permanent members of a given domain, or are join and
			leave operations possible?</li>
			<li>Are nodes physical or virtual devices?</li>
			<li>Are virtual nodes general purpose or limited to specific
			functions, applications, or users?</li>
			<li>Are nodes constrained (by battery, etc.)?</li>
			<li>Are devices installed "out of the box" or pre-configured?</li>
			</ul>
			</section>
			<section anchor="tax-boundary" numbered="true" toc="default">
			<name>Domain Boundary</name>
			<ul spacing="normal">
			<li>How is the domain boundary identified or defined?</li>
			<li>Is the domain boundary fixed or dynamic? </li>
			<li>Are boundary nodes special, or can any node be at the boundary?</l
			i>
			</ul>
			</section>
			<section anchor="tax-topo" numbered="true" toc="default">
			<name>Topology</name>
			<ul spacing="normal">
			<li>Is the domain a subset of a Layer 2 or 3 connectivity domain?</li>
			<li>Does the domain overlap other domains? (In other words, is a
			node allowed to be a member of multiple domains?)</li>
			<li>Does the domain match physical topology, or does it have a virtual
			(overlay) topology?</li>
			<li>Is the domain in a single building, vehicle, or campus? Or is it
			distributed?</li>
			<li>If distributed, are the interconnections private or over the Inter
			net?</li>
			<li>In IP addressing terms, is the domain Link local, Site local, or G
			lobal?</li>
			<li>Does the scope of IP unicast or multicast addresses map to the dom
			ain boundary?</li>
			</ul>
			</section>
			<section anchor="tax-tech" numbered="true" toc="default">
			<name>Technology</name>
			<ul spacing="normal">
			<li>What routing protocol(s) or different forwarding mechanisms
			(MPLS or other non-IP mechanism) are used?</li>
			<li>In an overlay domain, what overlay technique is used (L2VPN,
			L3VPN, etc.)?</li>
			<li>Are there specific QoS requirements?</li>
			<li>Link latency - Normal or long latency links?</li>
			<li>Mobility - Are nodes mobile? Is the whole network mobile?</li>
			<li>Which specific technologies, such as those in <xref target="exampl
			e-sol" format="default"/>,
			are applicable?</li>
			</ul>
			</section>
			<section anchor="tax-connect" numbered="true" toc="default">
			<name>Connection to the Internet</name>
			<ul spacing="normal">
			<li>Is the Internet connection permanent or intermittent?
			(Never connected is out of scope.)</li>
			<li>What traffic is blocked, in and out?</li>
			<li>What traffic is allowed, in and out?</li>
			<li>What traffic is transformed, in and out?</li>
			<li>Is secure and privileged remote access needed?</li>
			<li>Does the domain allow unprivileged remote sessions?</li>
			</ul>
			</section>
			<section anchor="tax-sec" numbered="true" toc="default">
			<name>Security, Trust, and Privacy Model</name>
			<ul spacing="normal">
			<li>Must domain members be authorized?</li>
			<li>Are all nodes in the domain at the same trust level?</li>
			<li>Is traffic authenticated?</li>
			<li>Is traffic encrypted?</li>
			<li>What is hidden from the outside?</li>
			</ul>
			</section>
			<section anchor="tax-ops" numbered="true" toc="default">
			<name>Operations</name>
			<ul spacing="normal">
			<li>Safety level - Does the domain have a critical (human) safety role
			?</li>
			<li>Reliability requirement - Normal or 99.999%?</li>
			<li>Environment - Hazardous conditions?</li>
			<li>Installation - Are specialists needed?</li>
			<li>Service visits - Easy, difficult, or impossible?</li>
			<li>Software/firmware updates - Possible or impossible?</li>
			</ul>
			</section>
			<section anchor="tax-usage" numbered="true" toc="default">
			<name>Making Use of This Taxonomy</name>
			<t>This taxonomy could be used to design or analyze a specific type of l
			imited 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.
			</t>
			</section>
			</section>
			<section anchor="ack" numbered="false" toc="default">
			<name>Acknowledgements</name>
			<t>Useful comments were received from
			<contact fullname="Amelia Andersdotter"/>,
			<contact fullname="Edward Birrane"/>,
			<contact fullname="David Black"/>,
			<contact fullname="Ron Bonica"/>,
			<contact fullname="Mohamed Boucadair"/>,
			<contact fullname="Tim Chown"/>,
			<contact fullname="Darren Dukes"/>,
			<contact fullname="Donald Eastlake"/>,
			<contact fullname="Adrian Farrel"/>,
			<contact fullname="Tom Herbert"/>,
			<contact fullname="Ben Kaduk"/>,
			<contact fullname="John Klensin"/>,
			<contact fullname="Mirja Kuehlewind"/>,
			<contact fullname="Warren Kumari"/>,
			<contact fullname="Andy Malis"/>,
			<contact fullname="Michael Richardson"/>,
			<contact fullname="Mark Smith"/>,
			<contact fullname="Rick Taylor"/>,
			<contact fullname="Niels ten Oever"/>,
			and others.
			</t>
			</section>
			<section anchor="contr" numbered="false" toc="default">
			<name>Contributors</name>
			<author fullname="Sheng Jiang">
			<organization>Huawei Technologies</organization>
			<address>
			<postal>
			<extaddr>Q14, Huawei Campus</extaddr>
			<street>No. 156 Beiqing Road</street>
			<city>Hai-Dian District, Beijing</city>
			<code>100095</code>
			<country>China</country>
			</postal>
			<email>jiangsheng@huawei.com</email>
			</address>
			</author>
			</section>
			</back>
			</rfc>
End of changes. 1 change blocks.
	lines changed or deleted		lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/