Limited Domains and Internet ProtocolsThe University of AucklandSchool of Computer ScienceUniversity of AucklandPB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.comHuawei TechnologiesQ14, Huawei CampusNo. 156 Beiqing RoadHai-Dian District, Beijing100095Chinaleo.liubing@huawei.comThere 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 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 need 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 consensus.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
. Introduction
. Failure Modes in Today's Internet
. Examples of Limited Domain Requirements
. Examples of Limited Domain Solutions
. The Scope of Protocols in Limited Domains
. Functional Requirements of Limited Domains
. Security Considerations
. IANA Considerations
. Informative References
. Taxonomy of Limited Domains
. Domain as a Whole
. Individual Nodes
. Domain Boundary
. Topology
. Technology
. Connection to the Internet
. Security, Trust, and Privacy Model
. Operations
. Making Use of This Taxonomy
Acknowledgements
Contributors
Authors' Addresses
Introduction
As the Internet continues to grow and diversify, with a realistic
prospect of tens of billions of nodes being connected directly and
indirectly, there is a noticeable trend towards network-specific and
local requirements, behaviors, and semantics. The word "local" should
be understood in a special sense, however. In some cases, it may refer to
geographical and physical locality -- all the nodes in a single building,
on a single campus, or in a given vehicle. In other cases, it may refer
to a defined set of users or nodes distributed over a much wider area,
but drawn together by a single virtual network over the Internet, or a
single physical network running in parallel with the Internet. We expand
on these possibilities below. To capture the topic, this document refers
to such networks as "limited domains". Of course, a similar situation may
arise for a network that is completely disconnected from the Internet,
but that is not our direct concern here. However, it should not be
forgotten that interoperability is needed even within a disconnected
network.
Some people have concerns about splintering of the Internet along political
or linguistic boundaries by mechanisms that block the free flow of information.
That is not the topic of this document, which does not discuss filtering mechanisms
(see ) 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 protocols . 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., . In the context of
secure multicast, a "group domain of interpretation" is defined by .Yet more definitions of types of domains are to be found in the routing area,
such as , , and .
We conclude that the notion of a limited domain is very widespread in many aspects
of Internet technology.The requirements of limited domains will depend on the deployment
scenario. Policies, default parameters, and the options supported may
vary. Also, the style of network management may vary between a
completely unmanaged network, one with fully autonomic management, one
with traditional central management, and mixtures of the above. Finally,
the requirements and solutions for security and privacy may vary.
This document analyzes and discusses some of the consequences of this
trend and how it may impact the idea of universal interoperability in the
Internet. First, we list examples of limited domain scenarios and of
technical solutions for limited domains, with the main focus being
the Internet layer of the protocol stack. An appendix provides a taxonomy
of the features to be found in limited domains. With this background, we
discuss the resulting challenge to the idea that all Internet standards
must be universal in scope and applicability. To the contrary, we assert
that some protocols, although needing to be standardized and interoperable,
also need to be specifically limited in their applicability.
This implies that the concepts of a limited domain, and of its membership, need
to be formalized and supported by secure mechanisms. While this document does
not propose a design for such mechanisms, it does outline some
functional requirements.
This document is the product of the research of the authors. It has
been produced through discussions and consultation within the IETF
but is not the product of IETF consensus.Failure Modes in Today's InternetToday, 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 .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.Investigations of the unreliability of IP fragmentation
and the filtering of IPv6 extension headers
strongly suggest that at least for
some protocol elements, transparency is a lost cause and middleboxes are here to stay.
In the following two sections, we show that some application environments require
protocol features that cannot, or should not, cross the whole Internet.
Examples of Limited Domain RequirementsThis 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.
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 summarized 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. An
extreme example is a network used for virtual reality or augmented reality
applications where the latency requirements are very stringent.
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 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.
Constrained Networks. 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. These 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 specialized in
such networks.
"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., ).
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) 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 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.
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.
Content Delivery Networks (CDNs), comprising distributed data centers and the paths
between them, spanning thousands of kilometers, 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 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.
Three other aspects, while not tied to specific network types, also strongly
depend on the concept of limited domains:
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 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.
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 will be applied
within the domain boundary, even if the services supported in the
domain are globally accessible.
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 .
This is expected to be significant in 5G deployments . Whatever
technologies are used to support slicing 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 best 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 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 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.Examples of Limited Domain SolutionsThis 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) or Shortest Path
Bridging , Layer 2 domains may
become very large.
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 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).
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 virtualization. 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 Center Network Virtualization Overlays. A common requirement in data
centers 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
centers, but which must appear to the user as a single secure domain.
Segment Routing. This is a technique that "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 or Operations, Administration,
and Maintenance (OAM) marking .
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 can support rather
complex local functionality.
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 whole Internet . It is worth noting that extension header filtering is
considered an important security issue . There is
considerable appetite among vendors or operators to have flexibility in
defining extension headers for use in limited or specialized 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 for which access is not globally available.
All of these suggestions are only viable within a specified domain. Nevertheless,
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.The Scope of Protocols in Limited DomainsOne 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.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:
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.
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.
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.
Such a protocol could reasonably be described as an "intra-domain" protocol,
and the Internet is opaque to it.
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.
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
, including the complex example of
Transport MPLS.
To provide a widespread example, consider Differentiated Services
. 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 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 outside the limited domain disturbed. However, inside the
domain, nodes must understand the variant protocol. Unless it is standardized
as a formal version, with all the complexity that implies ,
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 within the 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
.The FAST proposal mentioned in
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 need not
damage the rest of 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.Functional Requirements of Limited DomainsNoting 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.Today, where limited domains exist, they are essentially created by careful
configuration of boundary routers and firewalls. If a domain is
characterized by one or more address prefixes, address assignment to hosts
must also be carefully managed. This is an error-prone method, and a combination
of configuration errors and default routing can lead to unwanted traffic escaping
the domain. Our basic assumption is therefore that it should be possible for domains
to be created and managed
automatically, with minimal human configuration. We now discuss
requirements for automating domain creation and management.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.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 generalized.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 and links 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 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.
Withdrawal. A node must be able to cancel enrollment in a given
domain.
Dynamic Membership. Optionally, a node should be able to
temporarily leave or rejoin a domain (i.e., enrollment 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 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".
Peer Verification. A node must be able to verify whether another
node is a member of the domain.
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 (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.Security ConsiderationsAs noted above, a protocol intended for limited use may well be
inadvertently used on the open Internet, so limited use is not an excuse for
poor security. In fact, a limited use requirement potentially adds
complexity to the security design.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 boundary also serves to provide confidentiality and privacy for operational
parameters that the operator does not wish to reveal. Note that this is distinct from
privacy protection for individual users within 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.IANA ConsiderationsThis document has no IANA actions.Informative ReferencesAn Autonomic Control Plane (ACP)Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured.Work in ProgressApplication-aware IPv6 Networking (APN6) EncapsulationApplication-aware IPv6 Networking (APN6) framework makes use of IPv6 encapsulation in order to convey the application-aware information along with the data packet to the network so to facilitate the service deployment and SLA guarantee. This document defines the encodings of the application characteristic information, for the APN6 framework, that can be exchanged between an application and the network infrastructure through the use of IPv6 extension headers.Work in ProgressHUAWEI - Big IP InitiativeDetNet Data Plane FrameworkThis document provides an overall framework for the DetNet data plane. It covers concepts and considerations that are generally common to any Deterministic Networking data plane specification. It describes related controller plane considerations as well.Work in ProgressDNS Perimeter OverlayThe Domain Name System (DNS) naming syntax provides no meta-data for indicating administrative transitions through the hierarchy. For example, it does not distinguish the higher-level portions that operate as public registries, versus those that operate as private organizations. This specification creates a basic overlay mechanism for defining a logical Perimeter between administrative entities through the naming hierarchy. The mechanism can then be applied for a variety of independent administrative indications.Work in ProgressAnalysis of Semantic Embedded IPv6 Address SchemasThis informational document discusses the use of embedded semantics within IPv6 address schemas. Network operators who have large IPv6 address space may choose to embed some semantics into their IPv6 addressing by assigning additional significance to specific bits within the prefix. By embedding semantics into IPv6 prefixes, the semantics of packets can be easily inspected. This can simplify the packet differentiation process. However, semantic embedded IPv6 address schemas have their own operational cost and even potential pitfalls. Some complex semantic embedded IPv6 address schemas may also require new technologies in addition to existing Internet protocols. The document aims to understand the usage of semantic embedded IPv6 address schemas, and neutrally analyze on the associated advantages, drawbacks and technical gaps for more complex address schemas.Work in ProgressA Framework for Enhanced Virtual Private Networks (VPN+) ServiceThis document describes the framework for Enhanced Virtual Private Network (VPN+) service. The purpose is to support the needs of new applications, particularly applications that are associated with 5G services, by utilizing an approach that is based on existing VPN and Traffic Engineering (TE) technologies and adds features that specific services require over and above traditional VPNs. Typically, VPN+ will be used to form the underpinning of network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. It is envisaged that enhanced VPNs will be delivered using a combination of existing, modified, and new networking technologies. This document provides an overview of relevant technologies and identifies some areas for potential new work. Comparing to traditional VPNs, It is not envisaged that quite large numbers of VPN+ services will be deployed in a network. In other word, it is not intended that all existing VPNs supported by a network will use VPN+ related techniques.Work in ProgressFirewall and Service TicketsThis document describes the Firewalls and Service Tickets protocol. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network services to be applied. Applications request tickets from a local agent in the network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to a packets. A single ticket may provide both firewall and service ticket information. Tickets are sent in IPv6 Hop-by-Hop options.Work in ProgressIP Fragmentation Considered FragileThis document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.Work in ProgressHomenet Naming and Service Discovery ArchitectureThis document describes how names are published and resolved on homenets, and how hosts are configured to use these names to discover services on homenets. It presents the complete architecture, and describes a simple subset of that architecture that can be used in low-cost homenet routers.Work in ProgressIntent-Based Networking - Concepts and DefinitionsIntent and Intent-Based Networking (IBN) are taking the industry by storm. At the same time, those terms are used loosely and often inconsistently, in many cases overlapping and confused with other concepts such as "Policy". This document clarifies the concept of "Intent" and provides an overview of functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as foundation to guide further definition of associated research and engineering problems and their solutions.Work in ProgressIn-Flight IPv6 Extension Header Insertion Considered HarmfulIn the past few years, as well as currently, there have and are a number of proposals to insert IPv6 Extension Headers into existing IPv6 packets while in-flight. This contradicts explicit prohibition of this type of IPv6 packet proccessing in the IPv6 standard. This memo describes the possible failures that can occur with EH insertion, the harm they can cause, and the existing model that is and should continue to be used to add new information to an existing IPv6 and other packets.Work in ProgressIn-situ OAM IPv6 OptionsIn-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6.Work in ProgressIPv4 Extension Headers and Flow LabelThis specification defines extension headers for IPv4 and a definition of an IPv4 flow label. The goal is to provide a uniform and feasible method of extensibility that is shared between IPv4 and IPv6.Work in ProgressIPv6 Application of the Alternate Marking MethodThis document describes how the Alternate Marking Method can be used as the passive performance measurement tool in an IPv6 domain and reports implementation considerations. It proposes how to define a new Extension Header Option to encode alternate marking technique and both Hop-by-Hop Options Header and Destination Options Header are considered.Work in ProgressRecommendations on the Filtering of IPv6 Packets Containing IPv6 Extension HeadersIt is common operator practice to mitigate security risks by enforcing appropriate packet filtering. This document analyzes both the general security implications of IPv6 Extension Headers and the specific security implications of each Extension Header and Option type. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic *not* directed to them, for those cases in which such filtering is deemed as necessary.Work in ProgressDeployments With Insertion of IPv6 Segment Routing HeadersSRv6 is deployed in multiple provider networks. This document describes the usage of SRH insertion and deletion within the SR domain and how security and end-to-end integrity is guaranteed.Work in ProgressTCP Fails To Respect IPV6_USE_MIN_MTUThe IPV6_USE_MIN_MTU socket option directs the IP layer to limit the IPv6 packet size to the minimum required supported MTU from the base IPv6 specification, i.e. 1280 bytes. Many implementations of TCP running over IPv6 neglect to check the IPV6_USE_MIN_MTU value when performing MSS negotiation and when constructing a TCP segment despite MSS being defined to be the MTU less the IP and TCP header sizes (60 bytes for IPv6). This leads to oversized IPv6 packets being sent resulting in unintended Path Maximum Transport Unit Discovery (PMTUD) being performed and to fragmented IPv6 packets being sent.Work in ProgressIPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use CasesThis document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy), and then lists up requirements for the extensions of those IPv6 protocols for IPv6-based vehicular networking.Work in ProgressA Reference Model for Autonomic NetworkingThis document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.Work in ProgressResource ReSerVation Protocol (RSVP) -- Version 1 Functional SpecificationThis memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 HeadersThis document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]Internet TransparencyThis document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.TCP Problems with Path MTU DiscoveryThis memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. This memo provides information for the Internet community.Middleboxes: Taxonomy and IssuesThis document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.Deprecating Site Local AddressesThis document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. [STANDARDS-TRACK]Unique Local IPv6 Unicast AddressesThis document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]IP Version 6 Addressing ArchitectureThis specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) ArchitectureGeneralized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. This memo provides information for the Internet community.Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.A Path Computation Element (PCE)-Based ArchitectureConstraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.Packetization Layer Path MTU DiscoveryThis document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]Delay-Tolerant Networking ArchitectureThis document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community.Reflections on Internet TransparencyThis document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts. This memo provides information for the Internet community.Uncoordinated Protocol Development Considered HarmfulIABThis document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.Survey of Proposed Use Cases for the IPv6 Flow LabelThe IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised. This document is not an Internet Standards Track specification; it is published for informational purposes.Routing Bridges (RBridges): Base Protocol SpecificationRouting Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]IP Router Alert Considerations and UsageThe IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers. This memo documents an Internet Best Current Practice.The Group Domain of InterpretationThis document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. [STANDARDS-TRACK]Design Considerations for Protocol ExtensionsThis document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.The Session Description Protocol (SDP) Alternate Connectivity (ALTC) AttributeThis document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, provides such a solution.Architectural Considerations on Application Features in the DNSA number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.Transmission and Processing of IPv6 Extension HeadersVarious IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.Terminology for Constrained-Node NetworksThe Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.IPv6 Home Networking Architecture PrinciplesThis text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.Enterprise IPv6 Deployment GuidelinesEnterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.Multiple Provisioning Domain ArchitectureThis document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.Service Function Chaining (SFC) ArchitectureThis document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.Technical Considerations for Internet Service Blocking and FilteringThe Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.Home Networking Control ProtocolThis document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.Observations on the Dropping of Packets with IPv6 Extension Headers in the Real WorldThis document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.UDP Usage GuidelinesThe User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.GRE-in-UDP EncapsulationThis document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet.Diffserv-Interconnection Classes and PracticeThis document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.Use Cases for Data Center Network Virtualization Overlay NetworksThis document describes Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve different data-center applications.Internet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.Network Service Header (NSH)This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).Segment Routing ArchitectureSegment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) TraversalThis document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).This document obsoletes RFC 5245.An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator PerspectiveThis document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.Deterministic Networking Problem StatementThis paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties.Network Virtualization Research ChallengesThis document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG).Deterministic Networking Use CasesThis document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.Deterministic Networking ArchitectureThis document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.IPv6 Segment Routing Header (SRH)Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.IEEE Standard for Local and metropolitan area networks - Bridges and Bridged NetworksSRv6 Network ProgrammingThe SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization (Service Level Agreements).Work in ProgressUser Plane Protocol and Architectural Analysis on 3GPP 5G SystemThis document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side.Work in ProgressTaxonomy of Limited DomainsThis 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 analyze each of these aspects.Domain as a Whole
Why does the domain exist? (e.g., human choice, administrative policy,
orchestration requirements, technical requirements such as
operational partitioning for scaling reasons)
If there are special requirements, are they at Layer 2,
Layer 3, or an upper layer?
Where does the domain lie on the spectrum between completely managed by humans and completely autonomic?
If managed, what style of management applies? (Manual configuration,
automated configuration, orchestration?)
Is there a policy model? (Intent, configuration policies?)
Does the domain provide controlled or paid service or open access?
Individual Nodes
Is a domain member a complete node or only one interface of a node?
Are nodes permanent members of a given domain, or are join and
leave operations possible?
Are nodes physical or virtual devices?
Are virtual nodes general purpose or limited to specific
functions, applications, or users?
Are nodes constrained (by battery, etc.)?
Are devices installed "out of the box" or pre-configured?
Domain Boundary
How is the domain boundary identified or defined?
Is the domain boundary fixed or dynamic?
Are boundary nodes special, or can any node be at the boundary?
Topology
Is the domain a subset of a Layer 2 or 3 connectivity domain?
Does the domain overlap other domains? (In other words, is a
node allowed to be a member of multiple domains?)
Does the domain match physical topology, or does it have a virtual (overlay) topology?
Is the domain in a single building, vehicle, or campus? Or is it
distributed?
If distributed, are the interconnections private or over the Internet?
In IP addressing terms, is the domain Link local, Site local, or Global?
Does the scope of IP unicast or multicast addresses map to the domain boundary?
Technology
What routing protocol(s) or different forwarding mechanisms
(MPLS or other non-IP mechanism) are used?
In an overlay domain, what overlay technique is used (L2VPN,
L3VPN, etc.)?
Are there specific QoS requirements?
Link latency - Normal or long latency links?
Mobility - Are nodes mobile? Is the whole network mobile?
Which specific technologies, such as those in ,
are applicable?
Connection to the Internet
Is the Internet connection permanent or intermittent?
(Never connected is out of scope.)
What traffic is blocked, in and out?
What traffic is allowed, in and out?
What traffic is transformed, in and out?
Is secure and privileged remote access needed?
Does the domain allow unprivileged remote sessions?
Security, Trust, and Privacy Model
Must domain members be authorized?
Are all nodes in the domain at the same trust level?
Is traffic authenticated?
Is traffic encrypted?
What is hidden from the outside?
Operations
Safety level - Does the domain have a critical (human) safety role?
Reliability requirement - Normal or 99.999%?
Environment - Hazardous conditions?
Installation - Are specialists needed?
Service visits - Easy, difficult, or impossible?
Software/firmware updates - Possible or impossible?
Making Use of This TaxonomyThis taxonomy could be used to design or analyze a specific type of limited domain.
For the present document, it is intended only to form a background to the
scope of protocols used in limited domains and the mechanisms
required to securely define domain membership and properties.
AcknowledgementsUseful comments were received from
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
and others.
ContributorsHuawei TechnologiesQ14, Huawei CampusNo. 156 Beiqing RoadHai-Dian District, Beijing100095Chinajiangsheng@huawei.comAuthors' AddressesThe University of AucklandSchool of Computer ScienceUniversity of AucklandPB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.comHuawei TechnologiesQ14, Huawei CampusNo. 156 Beiqing RoadHai-Dian District, Beijing100095Chinaleo.liubing@huawei.com