Limited Domains and Internet Protocols
The University of Auckland
School of Computer Science
University of Auckland
PB 92019
Auckland
1142
New Zealand
brian.e.carpenter@gmail.com
Huawei Technologies
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing
100095
P.R. China
leo.liubing@huawei.com
There is a noticeable trend towards network requirements, behaviours
and semantics that are specific to a particular set of requirements
applied within a limited region of the Internet. Policies, default parameters,
the options supported, the style of network management and security
requirements may vary between such limited regions. This document reviews
examples of such limited domains (also known as controlled environments),
notes emerging solutions, and includes a related taxonomy. It then
briefly discusses the standardization of protocols for limited domains.
Finally, it shows the needs for a precise definition of "limited domain membership"
and for mechanisms to allow nodes to join a domain securely and to find other
members, including boundary nodes.
This document is the product of the research of the authors. It has
been produced through discussions and consultation within the IETF,
but is not the product of IETF conensus.
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,
behaviours 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 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
, the split might be at the edge of a limited domain.
A recent proposal for defining definite perimeters within the DNS namespace
might also be considered to be a limited
domain mechanism.
Another term that has been used in some contexts is "controlled environment".
For example, uses this to delimit the operational scope within
which a particular tunnel encapsulation might be used. A specific example is
GRE-in-UDP encapsulation 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 or security protocols, e.g. ,
. It is not necessarily the case that protocols will
fail to operate outside the controlled environment, but rather that they might
not operate usefully. 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. .
In the context of secure multicast, a "group domain of interpretation" is defined
by .
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 analyses and discusses some of the consequences of this
trend, and how it may impact the idea of universal interoperability in the
Internet. Firstly 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 need to be specifically limited in their applicability.
This implies that the concepts of a limited domain, and of its membership, need
to be formalised 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 conensus.
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 ,
or on the middleboxes responsible for that loss ,
, .
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 , and
Path MTU Discovery has been unreliable for many years , .
IP fragmentation is also unreliable ,
and problems in TCP MSS negotiation have been reported .
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 .
The recent discussions about the unreliability of IP fragmentation
and the filtering of IPv6 extension headers have strongly suggested 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.
This section describes various examples where limited domain requirements 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.
A home network. It will be mainly unmanaged, constructed by a non-specialist,
and will possibly include wiring errors such as physical loops.
It must work with devices "out of the box" as shipped by their manufacturers
and must create adequate security by default. Remote access may be required.
The requirements and applicable principles are summarised in .
A small office network. This is sometimes very similar to a home network, 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 professionally
constructed using recommended products and configurations, but operate unmanaged.
Remote access may be required.
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
for a survey of use cases.
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
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.
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.
Internet of Things (IoT) networks. While this term is very flexible and covers many
innovative types of network, 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.
An important subclass of IoT networks consists of constrained networks in
which the nodes are limited in power consumption and communications bandwidth, and are therefore
limited to using very frugal protocols.
Delay tolerant networks may consist of domains that are relatively 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 . Clearly the protocol
requirements and possibilities are very specialised in such networks.
"Traditional" enterprise and campus networks, which may be spread over many kilometres
and over multiple separate sites, with multiple connections to the Internet.
Interestingly, the IETF appears never to have
analysed this long-established class of networks in a general way, except in connection with
IPv6 deployment (e.g. ).
A situation that may 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 ICE 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 .
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 VPLS or EVPN, and layer 3 IP VPNs. These are generally characterized
by service level agreements for availability and packet loss. 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.
Data centres and hosting centres, or distributed services acting as such centres.
These will have high performance, security and privacy requirements and will typically
include large numbers of independent "tenant" networks overlaid on shared infrastructure.
Content Delivery Networks (CDNs), comprising distributed data centres and the paths
between them, spanning thousands of kilometres, with numerous connections to the Internet.
Massive Web Service Provider Networks. This is a small class of networks with well known
trademarked names, combining aspects
of distributed enterprise networks, data centres 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.
Three other aspects, while not tied to specific network types, also strongly
depend on the concept of limited domains:
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 .
Whatever technologies are used to support this, they
will be applied within the domain boundary, even if the services supported
in the domain are globally accessible.
Many of the above types of network 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 arbitrary
fashion by use of virtualization techniques. As noted above in the discussion of
controlled environments, specific tunneling and encapsulation techniques may
be tailored for use within a given domain.
Network Slicing. A network slice is a virtual network that consists of a managed
set of resources carved off from a larger network .
This is expected to be significant in 5G deployments .
Whatever technologies are used to
support slicing, they will require a clear definition of the boundary of a given slice
within a larger domain.
While it is clearly desirable to use common solutions, and therefore common standards,
wherever possible, it is increasingly difficult to do so while satisfying the 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 Internet?"
This document suggests that this is not always the right question. There are
protocols and extensions that are not intended to work across the open Internet.
On the contrary, their requirements and semantics are specifically limited (in the
sense defined above).
A common argument is that if a protocol is intended for limited use, the chances are
very high that it will in fact be used (or misused) in other scenarios including the
so-called open Internet. This is undoubtedly true and means that limited use is not
an excuse for bad design or poor security. In fact, a limited use requirement potentially
adds complexity to both the protocol and its security design, as discussed later.
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 domain. There will be attempts to capture each market sector,
but the market will demand standardised 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 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.
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.
Differentiated Services. This mechanism
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
codepoint values for specific per-hop queue management
behaviours, these are specifically intended to be domain-specific
codepoints with traffic being classified, conditioned and
re-marked at domain boundaries (unless there is an inter-domain
agreement that makes re-marking unnecessary).
Integrated Services. Although it is not intrinsic in
the design of RSVP , 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.
Network function virtualisation. As described in
,
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.
Service Function Chaining (SFC). This technique
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) 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."
Firewall and Service Tickets (FAST). Such tickets would accompany a packet
to claim the right to traverse a network or request a specific network
service .
They would only be meaningful within a particular domain.
Data Centre Network Virtualization Overlays. A common requirement in data
centres that host many tenants (clients) is to provide each one with a secure
private network, all running over the same physical infrastructure.
describes various use cases for this, and specifications
are under development. These include
use cases in which the tenant network is physically split over several data
centres, but which must appear to the user as a single secure domain.
Segment Routing. This is a technique which "steers a packet through
an ordered list of instructions, called segments"
. 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.
Autonomic Networking. As explained in ,
an autonomic network is also a security domain within which an autonomic
control plane
is used by autonomic service agents. These agents manage technical objectives,
which may be locally defined, subject to domain-wide policy. Thus the domain
boundary is important for both security and protocol purposes.
Homenet. As shown in , a home 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) and a naming and discovery solution
.
Creative uses of IPv6 features.
As IPv6 enters more general use, engineers notice that it has much more flexibility
than IPv4. Innovative suggestions have been made for:
The flow label, e.g. , .
Extension headers, e.g. for segment routing .
Meaningful address bits, e.g. . Also, segment routing
uses IPv6 addresses as segment identifiers with specific local meanings
.
If segment routing is used for network programming
,
IPv6 extension headers will support rather complex local functionality.
All of these suggestions are only viable within a specified domain.
The case of the extension header is particularly interesting, since its
existence has been a major "selling point" for IPv6, but it is notorious
that new extension headers are virtually impossible to deploy across
the whole Internet , .
It is worth noting that extension header filtering is considered as an
important security issue .
There is considerable appetite among vendors or operators to have flexibility
in defining extension headers for use in limited or specialised domains, e.g.
, ,
and .
Locally significant hop-by-hop options are also envisaged, that would be understood
by routers inside a domain but not elsewhere, e.g.,
.
Deterministic Networking (DetNet). The Deterministic Networking Architecture
and encapsulation
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.
Provisioning Domains (PvDs). An architecture for Multiple Provisioning
Domains has been defined to allow hosts attached
to multiple networks to learn explicit details about the services
provided by each of those networks.
Address Scopes. For completeness, we mention that, particularly in IPv6,
some addresses have explicitly limited scope. In particular, link-local addresses
are limited to a single physical link , and
Unique Local Addresses are limited
to a somewhat loosely defined local site scope. Previously, site-local addresses
were defined, but they were obsoleted precisely because of
"the fuzzy nature of the site concept" . Multicast
addresses also have explicit scoping .
As an application layer example, consider streaming services
such as IPTV infrastructures that rely on standard protocols,
but access is not globally available.
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 node will be connected to the Internet; each one
of these edge networks will be a limited domain.
It is therefore appropriate to discuss whether protocols or protocol extensions
should sometimes be standardised to interoperate only within a Limited Domain
boundary. Such protocols would not be required to interoperate across the Internet
as a whole. Several possibly overlapping scenarios could then arise:
A. If a limited 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.
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 parts
of the limited domain. This is of course nothing new in the Internet architecture.
B. 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 parts of a domain split at the IP layer.
Such a protocol could reasonably be described as an "intra-domain" protocol,
and the Internet is opaque to it.
C. If a limited-domain protocol is clearly specified to be invalid outside its
domain of origin, neither scenario A nor B applies. The two domains
need to be unified as a single virtual domain. For example, an encapsulating tunnel between
the parts of the split domain could be used. Also, nodes at the domain boundary
must drop all packets using the limited-domain protocol.
D. 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, 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. Such a protocol usually also falls into scenario C.
To provide an existing example, consider Differentiated Services
. A packet containing any value whatever in
the 6 bits of the Differentiated Service 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 to be found in
and .
To provide a provocative example, consider the proposal in
that the restrictions
in 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 they
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 disturbed.
The FAST proposal mentioned above is also an interesting case study.
The semantics of FAST tickets 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
. Whether such options can be used
reliably across the open Internet remains unclear .
We conclude that it is reasonable to explicitly define limited-domain protocols, 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 defined.
As long as all relevant standards are respected outside
the domain boundary, a well-specified limited-domain protocol is not harmful
to the Internet. However, as described in the next section, mechanisms are
needed to support domain membership operations.
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.
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 consider
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
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.
Our basic assumption is that it should be possible for domains to be created and managed
automatically, with minimal human configuration required. We therefore discuss
requirements for automating domain creation and management.
Firstly, if we drew a topology map, any 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. However,
a sending node needs to know whether it is sending to an inside or outside destination;
a receiving node needs to know whether a packet originated inside or outside; and
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.
To underline that domain boundaries need to be identifiable, consider the statement
from the Deterministic Networking Problem Statement 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 generalised.
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 attack.
Domain Identity. A domain must have a unique and verifiable identifier;
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.
Nesting. It must be possible for domains to be nested (see, for example, the
network slicing example mentioned above.
Overlapping. It must be possible for nodes to be in more than one domain (see, for example,
the case of PVDs mentioned above).
Node Eligibility. It must be possible for a node to determine which domain(s)
it can potentially join, and on which interface(s).
Secure Enrolment. A node must be able to enrol in a given domain
via secure node identfication and to acquire relevant security credentials
(authorization) for operations within the domain. If a node has multiple
physical or virtual interfaces, they may require to be individually enrolled.
Withdrawal. A node must be able to cancel enrolment in a given domain.
Dynamic Membership. Optionally, a node should be able temporarily leave or rejoin
a domain (i.e. enrolment is persistent but membership is intermittent).
Role, implying authorization to perform a certain set of actions.
A node must have a verifiable role. In the simplest case,
the choices of role are "interior node" and "boundary node". In a boundary
node, individual interfaces may have different roles, e.g. "inward
facing" and "outward facing".
Verify Peer. A node must be able to verify whether another node is a member of the domain.
Verify Role. A node must be able to learn the verified role of another node.
In particular, it must be possible for a node to find boundary nodes (interfacing
to the Internet).
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.
These requirements could form the basis for further analysis and solution design.
Another aspect is whether individual packets within a limited domain need 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 question
is whether individual packets need cryptographic authentication. This topic is
for further study.
Often, the boundary of a limited domain will also act as a security boundary.
In particular, it will serve as a trust boundary, and as a boundary of
authority for defining capabilities. For example, segment routing
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 will in
many cases be meaningless or harmful if they enter or leave the domain.
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.
This document makes no request of the IANA.
Sheng Jiang made important contributions to this document.
Useful comments were received from
Amelia Andersdotter,
Edward Birrane,
David Black,
Ron Bonica,
Mohamed Boucadair,
Tim Chown,
Darren Dukes,
Adrian Farrel,
Tom Herbert,
John Klensin,
Andy Malis,
Michael Richardson,
Mark Smith,
Rick Taylor,
Niels ten Oever,
and other members of the ANIMA and INTAREA WGs.
.
HUAWEI - Big IP Initiative.
draft-carpenter-limited-domains-00, 2018-06-11:
Initial version
draft-carpenter-limited-domains-01, 2018-07-01:
Minor terminology clarifications
draft-carpenter-limited-domains-02, 2018-08-03:
Additions following IETF102 discussions
Updated authorship/contributors
draft-carpenter-limited-domains-03, 2018-09-12:
First draft of taxonomy
Editorial improvements
draft-carpenter-limited-domains-04, 2018-10-14:
Reorganized section 3
Newly written sections 6 and 7
Editorial improvements
draft-carpenter-limited-domains-05, 2018-12-12:
Added discussion of transparency/filtering debates
Added discussion of "controlled environment"
Modified assertion about localized standards
Editorial improvements
draft-carpenter-limited-domains-06, 2019-03-02:
Minor updates, fixed reference nits
draft-carpenter-limited-domains-07, 2019-04-15:
Moved taxonomy to an appendix.
Added examples and references.
Editorial improvements
draft-carpenter-limited-domains-08, 2019-06-12:
Added short discussion of address scopes.
Added possibility of nested or overlapped domains.
Integrated other comments received.
Editorial improvements
draft-carpenter-limited-domains-09, 2019-06-21:
Additional 5G citations.
draft-carpenter-limited-domains-10, 2019-08-02:
ISE comments.
This appendix develops a taxonomy for describing limited domains.
Several major aspects are considered in this taxonomy:
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.
The following sub-sections analyse each of these aspects.
Why does the domain exist? (e.g., human choice, administrative policy,
orchestration requirements, technical requirements)
If there are special requirements, are they at Layer 2,
Layer 3 or an upper layer?
Is the domain managed by humans or fully 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?
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?
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?
Is the domain a subset of a layer 2 or 3 connectivity domain?
In IP addressing terms, is the domain Link-local, Site-local, or Global?
Does the domain overlap other domains? (In other words, a node may or may not be 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?
What routing protocol(s) are used,
or even different forwarding mechanisms (MPLS or other non-IP mechanism)?
In an overlay domain, what overlay technique is used (L2VPN, L3VPN,...)?
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 ,
are applicable?
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?
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?
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, impossible?
Software/firmware updates - possible or impossible?
This taxonomy could be used to design or analyse 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.