[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10

Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                                    B. Liu
Expires: December 23, 2019                           Huawei Technologies
                                                           June 21, 2019


                 Limited Domains and Internet Protocols
                   draft-carpenter-limited-domains-09

Abstract

   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains, also known as controlled environments, and 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 23, 2019.

Copyright Notice

   Copyright (c) 2019 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



Carpenter & Liu         Expires December 23, 2019               [Page 1]


Internet-Draft               Limited Domains                   June 2019


   (https://trustee.ietf.org/license-info) 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Failure Modes in Today's Internet . . . . . . . . . . . . . .   4
   3.  Examples of Limited Domain Requirements . . . . . . . . . . .   4
   4.  Examples of Limited Domain Solutions  . . . . . . . . . . . .   8
   5.  The Scope of Protocols in Limited Domains . . . . . . . . . .  11
   6.  Functional Requirements of Limited Domains  . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  16
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   11. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Appendix A.  Change log [RFC Editor: Please remove] . . . . . . .  22
   Appendix B.  Taxonomy of Limited Domains  . . . . . . . . . . . .  23
     B.1.  The Domain as a Whole . . . . . . . . . . . . . . . . . .  24
     B.2.  Individual Nodes  . . . . . . . . . . . . . . . . . . . .  24
     B.3.  The Domain Boundary . . . . . . . . . . . . . . . . . . .  25
     B.4.  Topology  . . . . . . . . . . . . . . . . . . . . . . . .  25
     B.5.  Technology  . . . . . . . . . . . . . . . . . . . . . . .  25
     B.6.  Connection to the Internet  . . . . . . . . . . . . . . .  26
     B.7.  Security, Trust and Privacy Model . . . . . . . . . . . .  26
     B.8.  Operations  . . . . . . . . . . . . . . . . . . . . . . .  26
     B.9.  Making use of this taxonomy . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1.  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, 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



Carpenter & Liu         Expires December 23, 2019               [Page 2]


Internet-Draft               Limited Domains                   June 2019


   "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 [RFC6950], the split might be at
   the edge of a limited domain.  A recent proposal for defining
   definite perimeters within the DNS namespace
   [I-D.dcrocker-dns-perimeter] might also be considered to be a limited
   domain mechanism.

   Another term that has been used in some contexts is "controlled
   environment".  For example, [RFC8085] uses this to delimit the
   operational scope within which a particular tunnel encapsulation
   might be used.  A specific example is GRE-in-UDP encapsulation
   [RFC8086] which explicitly states that "The controlled environment
   has less restrictive requirements than the general Internet."  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.
   [RFC6398], [RFC6455].  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.  [RFC6947].

   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



Carpenter & Liu         Expires December 23, 2019               [Page 3]


Internet-Draft               Limited Domains                   June 2019


   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.

2.  Failure Modes in Today's Internet

   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 [RFC2775],
   [RFC4924] or on the middleboxes responsible for that loss [RFC3234],
   [RFC7663], [RFC8517].  Unfortunately the problems persist, both in
   application protocols, and even in very fundamental mechanisms.  For
   example, the Internet is not transparent to IPv6 extension headers
   [RFC7872], and Path MTU Discovery has been unreliable for many years
   [RFC2923], [RFC4821].  IP fragmentation is also unreliable
   [I-D.ietf-intarea-frag-fragile], and problems in TCP MSS negotiation
   have been reported [I-D.andrews-tcp-and-ipv6-use-minmtu].

   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
   [I-D.ietf-opsec-ipv6-eh-filtering].

   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.

3.  Examples of Limited Domain Requirements

   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.



Carpenter & Liu         Expires December 23, 2019               [Page 4]


Internet-Draft               Limited Domains                   June 2019


   1.   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 [RFC7368].

   2.   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.

   3.   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
        [I-D.ietf-ipwave-vehicular-networking] for a survey of use
        cases.

   4.   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 [RFC8578] 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.

   5.   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.

   6.   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



Carpenter & Liu         Expires December 23, 2019               [Page 5]


Internet-Draft               Limited Domains                   June 2019


        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.

   7.   An important subclass of IoT networks consists of constrained
        networks [RFC7228] in which the nodes are limited in power
        consumption and communications bandwidth, and are therefore
        limited to using very frugal protocols.

   8.   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 [RFC4838].  Clearly
        the protocol requirements and possibilities are very specialised
        in such networks.

   9.   "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.  [RFC7381]).

   10.  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 [RFC8445] 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 [RFC6947].

   11.  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.

   12.  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.






Carpenter & Liu         Expires December 23, 2019               [Page 6]


Internet-Draft               Limited Domains                   June 2019


   13.  Content Delivery Networks (CDNs), comprising distributed data
        centres and the paths between them, spanning thousands of
        kilometres, with numerous connections to the Internet.

   14.  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:

   1.  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 [I-D.moulchan-nmrg-network-intent-concepts].  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.

   2.  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.

   3.  Network Slicing.  A network slice is a virtual network that
       consists of a managed set of resources carved off from a larger
       network [I-D.geng-netslices-architecture].  This is expected to
       be significant in 5G deployments
       [I-D.ietf-dmm-5g-uplane-analysis].  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).



Carpenter & Liu         Expires December 23, 2019               [Page 7]


Internet-Draft               Limited Domains                   June 2019


   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.

4.  Examples of Limited Domain Solutions

   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.

   1.   Differentiated Services.  This mechanism [RFC2474] 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).

   2.   Integrated Services.  Although it is not intrinsic in the design
        of RSVP [RFC2205], 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.

   3.   Network function virtualisation.  As described in
        [I-D.irtf-nfvrg-gaps-network-virtualization], this general
        concept is an open research topic, in which virtual network



Carpenter & Liu         Expires December 23, 2019               [Page 8]


Internet-Draft               Limited Domains                   June 2019


        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.

   4.   Service Function Chaining (SFC).  This technique [RFC7665]
        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) [RFC8300] 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."

   5.   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 [I-D.herbert-fast].  They
        would only be meaningful within a particular domain.

   6.   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.  [RFC8151] 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.

   7.   Segment Routing.  This is a technique which "steers a packet
        through an ordered list of instructions, called segments"
        [RFC8402].  The semantics of these instructions are explicitly
        local to a segment routing domain or even to a single node.
        Technically, 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.

   8.   Autonomic Networking.  As explained in
        [I-D.ietf-anima-reference-model], an autonomic network is also a
        security domain within which an autonomic control plane
        [I-D.ietf-anima-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.





Carpenter & Liu         Expires December 23, 2019               [Page 9]


Internet-Draft               Limited Domains                   June 2019


   9.   Homenet.  As shown in [RFC7368], 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) [RFC7788] and a naming and
        discovery solution [I-D.ietf-homenet-simple-naming].

   10.  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.  [RFC6294],
           [I-D.fioccola-v6ops-ipv6-alt-mark].

        *  Extension headers, e.g. for segment routing
           [I-D.ietf-6man-segment-routing-header].

        *  Meaningful address bits, e.g.  [I-D.jiang-semantic-prefix].
           Also, segment routing uses IPv6 addresses as segment
           identifiers with specific local meanings [RFC8402].

        *  If segment routing is used for network programming
           [I-D.filsfils-spring-srv6-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
        [RFC7045], [RFC7872].  It is worth noting that extension header
        filtering is considered as an important security issue
        [I-D.ietf-opsec-ipv6-eh-filtering].  There is considerable
        appetite among vendors or operators to have flexibility in
        defining extension headers for use in limited or specialised
        domains, e.g.  [I-D.voyer-6man-extension-header-insertion],
        [BIGIP], and [I-D.li-6man-service-aware-ipv6-network].  Locally
        significant hop-by-hop options are also envisaged, that would be
        understood by routers inside a domain but not elsewhere, e.g.,
        [I-D.ioametal-ippm-6man-ioam-ipv6-options].

   11.  Deterministic Networking (DetNet).  The Deterministic Networking
        Architecture [I-D.ietf-detnet-architecture] and encapsulation
        [I-D.ietf-detnet-dp-sol] 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.




Carpenter & Liu         Expires December 23, 2019              [Page 10]


Internet-Draft               Limited Domains                   June 2019


   12.  Provisioning Domains (PvDs).  An architecture for Multiple
        Provisioning Domains has been defined [RFC7556] to allow hosts
        attached to multiple networks to learn explicit details about
        the services provided by each of those networks.

   13.  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 [RFC4291], and Unique Local Addresses [RFC4193]
        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" [RFC3879].  Multicast addresses also have explicit
        scoping [RFC4291].

   14.  As an application layer example, consider streaming services
        such as IPTV infrastructures that rely on standard protocols,
        but access is not globally available.

5.  The Scope of Protocols in Limited Domains

   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.




Carpenter & Liu         Expires December 23, 2019              [Page 11]


Internet-Draft               Limited Domains                   June 2019


      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
   [RFC2474].  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 [RFC2474] and [RFC8100].

   To provide a provocative example, consider the proposal in
   [I-D.voyer-6man-extension-header-insertion] that the restrictions in
   [RFC8200] 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.



Carpenter & Liu         Expires December 23, 2019              [Page 12]


Internet-Draft               Limited Domains                   June 2019


   The FAST proposal mentioned above is also an interesting case study.
   The semantics of FAST tickets [I-D.herbert-fast] 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
   [I-D.herbert-ipv4-eh].  Whether such options can be used reliably
   across the open Internet remains unclear
   [I-D.ietf-opsec-ipv6-eh-filtering].

   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.

6.  Functional Requirements of Limited Domains

   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 Appendix B 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



Carpenter & Liu         Expires December 23, 2019              [Page 13]


Internet-Draft               Limited Domains                   June 2019


   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
   [RFC8557] 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.

   1.   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.

   2.   Nesting.  It must be possible for domains to be nested (see, for
        example, the network slicing example mentioned above.

   3.   Overlapping.  It must be possible for nodes to be in more than
        one domain (see, for example, the case of PVDs mentioned above).

   4.   Node Eligibility.  It must be possible for a node to determine
        which domain(s) it can potentially join, and on which
        interface(s).

   5.   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.

   6.   Withdrawal.  A node must be able to cancel enrolment in a given
        domain.

   7.   Dynamic Membership.  Optionally, a node should be able
        temporarily leave or rejoin a domain (i.e. enrolment is
        persistent but membership is intermittent).

   8.   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



Carpenter & Liu         Expires December 23, 2019              [Page 14]


Internet-Draft               Limited Domains                   June 2019


        node".  In a boundary node, individual interfaces may have
        different roles, e.g. "inward facing" and "outward facing".

   9.   Verify Peer.  A node must be able to verify whether another node
        is a member of the domain.

   10.  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).

   11.  Domain Data.  In a domain with management requirements, it must
        be possible for a node to acquire domain policy and/or domain
        configuration data.  This would include, for example, filtering
        policy 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.

7.  Security Considerations

   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 [RFC8402] 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.

8.  IANA Considerations

   This document makes no request of the IANA.








Carpenter & Liu         Expires December 23, 2019              [Page 15]


Internet-Draft               Limited Domains                   June 2019


9.  Contributors

   Sheng Jiang made important contributions to this document.

10.  Acknowledgements

   Useful comments were received from Amelia Andersdotter, Edward
   Birrane, David Black, Ron Bonica, Mohamed Boucadair, Tim Chown,
   Darren Dukes, Tom Herbert, John Klensin, Andy Malis, Michael
   Richardson, Mark Smith, Rick Taylor, Niels ten Oever, and other
   members of the ANIMA and INTAREA WGs.

11.  Informative References

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

   [I-D.andrews-tcp-and-ipv6-use-minmtu]
              Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU",
              draft-andrews-tcp-and-ipv6-use-minmtu-04 (work in
              progress), October 2015.

   [I-D.dcrocker-dns-perimeter]
              Crocker, D. and T. Adams, "DNS Perimeter Overlay", draft-
              dcrocker-dns-perimeter-01 (work in progress), June 2019.

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              Network Programming", draft-filsfils-spring-srv6-network-
              programming-07 (work in progress), February 2019.

   [I-D.fioccola-v6ops-ipv6-alt-mark]
              Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6
              Performance Measurement with Alternate Marking Method",
              draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress),
              June 2018.

   [I-D.geng-netslices-architecture]
              67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com,
              k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing
              Architecture", draft-geng-netslices-architecture-02 (work
              in progress), July 2017.

   [I-D.herbert-fast]
              Herbert, T., "Firewall and Service Tickets", draft-
              herbert-fast-04 (work in progress), April 2019.




Carpenter & Liu         Expires December 23, 2019              [Page 16]


Internet-Draft               Limited Domains                   June 2019


   [I-D.herbert-ipv4-eh]
              Herbert, T., "IPv4 Extension Headers and Flow Label",
              draft-herbert-ipv4-eh-01 (work in progress), May 2019.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
              Routing Header (SRH)", draft-ietf-6man-segment-routing-
              header-21 (work in progress), June 2019.

   [I-D.ietf-anima-autonomic-control-plane]
              Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
              Control Plane (ACP)", draft-ietf-anima-autonomic-control-
              plane-19 (work in progress), March 2019.

   [I-D.ietf-anima-reference-model]
              Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
              and J. Nobre, "A Reference Model for Autonomic
              Networking", draft-ietf-anima-reference-model-10 (work in
              progress), November 2018.

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-13 (work in progress), May 2019.

   [I-D.ietf-detnet-dp-sol]
              Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga,
              B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger,
              "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp-
              sol-04 (work in progress), March 2018.

   [I-D.ietf-dmm-5g-uplane-analysis]
              Homma, S., Miyasaka, T., Matsushima, S., and d.
              daniel.voyer@bell.ca, "User Plane Protocol and
              Architectural Analysis on 3GPP 5G System", draft-ietf-dmm-
              5g-uplane-analysis-01 (work in progress), March 2019.

   [I-D.ietf-homenet-simple-naming]
              Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming
              and Service Discovery Architecture", draft-ietf-homenet-
              simple-naming-03 (work in progress), October 2018.

   [I-D.ietf-intarea-frag-fragile]
              Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
              and F. Gont, "IP Fragmentation Considered Fragile", draft-
              ietf-intarea-frag-fragile-12 (work in progress), June
              2019.



Carpenter & Liu         Expires December 23, 2019              [Page 17]


Internet-Draft               Limited Domains                   June 2019


   [I-D.ietf-ipwave-vehicular-networking]
              Jeong, J., "IP Wireless Access in Vehicular Environments
              (IPWAVE): Problem Statement and Use Cases", draft-ietf-
              ipwave-vehicular-networking-09 (work in progress), May
              2019.

   [I-D.ietf-opsec-ipv6-eh-filtering]
              Gont, F. and W. LIU, "Recommendations on the Filtering of
              IPv6 Packets Containing IPv6 Extension Headers", draft-
              ietf-opsec-ipv6-eh-filtering-06 (work in progress), July
              2018.

   [I-D.ioametal-ippm-6man-ioam-ipv6-options]
              Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B.,
              Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati,
              "In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam-
              ipv6-options-02 (work in progress), March 2019.

   [I-D.irtf-nfvrg-gaps-network-virtualization]
              Bernardos, C., Rahman, A., Zuniga, J., Contreras, L.,
              Aranda, P., and P. Lynch, "Network Virtualization Research
              Challenges", draft-irtf-nfvrg-gaps-network-
              virtualization-10 (work in progress), September 2018.

   [I-D.jiang-semantic-prefix]
              Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang,
              "Analysis of Semantic Embedded IPv6 Address Schemas",
              draft-jiang-semantic-prefix-06 (work in progress), July
              2013.

   [I-D.li-6man-service-aware-ipv6-network]
              Li, Z. and S. Peng, "Service-aware IPv6 Network", draft-
              li-6man-service-aware-ipv6-network-00 (work in progress),
              March 2019.

   [I-D.moulchan-nmrg-network-intent-concepts]
              Sivakumar, K. and M. Chandramouli, "Concepts of Network
              Intent", draft-moulchan-nmrg-network-intent-concepts-00
              (work in progress), October 2017.

   [I-D.voyer-6man-extension-header-insertion]
              daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes,
              D., Previdi, S., and S. Matsushima, "Insertion of IPv6
              Segment Routing Headers in a Controlled Domain", draft-
              voyer-6man-extension-header-insertion-05 (work in
              progress), January 2019.




Carpenter & Liu         Expires December 23, 2019              [Page 18]


Internet-Draft               Limited Domains                   June 2019


   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/info/rfc2205>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              DOI 10.17487/RFC2775, February 2000,
              <https://www.rfc-editor.org/info/rfc2775>.

   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery",
              RFC 2923, DOI 10.17487/RFC2923, September 2000,
              <https://www.rfc-editor.org/info/rfc2923>.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
              <https://www.rfc-editor.org/info/rfc3234>.

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, DOI 10.17487/RFC3879, September
              2004, <https://www.rfc-editor.org/info/rfc3879>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <https://www.rfc-editor.org/info/rfc4821>.

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
              April 2007, <https://www.rfc-editor.org/info/rfc4838>.

   [RFC4924]  Aboba, B., Ed. and E. Davies, "Reflections on Internet
              Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007,
              <https://www.rfc-editor.org/info/rfc4924>.




Carpenter & Liu         Expires December 23, 2019              [Page 19]


Internet-Draft               Limited Domains                   June 2019


   [RFC6294]  Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for
              the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June
              2011, <https://www.rfc-editor.org/info/rfc6294>.

   [RFC6398]  Le Faucheur, F., Ed., "IP Router Alert Considerations and
              Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
              2011, <https://www.rfc-editor.org/info/rfc6398>.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <https://www.rfc-editor.org/info/rfc6455>.

   [RFC6947]  Boucadair, M., Kaplan, H., Gilman, R., and S.
              Veikkolainen, "The Session Description Protocol (SDP)
              Alternate Connectivity (ALTC) Attribute", RFC 6947,
              DOI 10.17487/RFC6947, May 2013,
              <https://www.rfc-editor.org/info/rfc6947>.

   [RFC6950]  Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
              "Architectural Considerations on Application Features in
              the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
              <https://www.rfc-editor.org/info/rfc6950>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045,
              DOI 10.17487/RFC7045, December 2013,
              <https://www.rfc-editor.org/info/rfc7045>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 2014,
              <https://www.rfc-editor.org/info/rfc7368>.

   [RFC7381]  Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
              Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
              Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014,
              <https://www.rfc-editor.org/info/rfc7381>.

   [RFC7556]  Anipko, D., Ed., "Multiple Provisioning Domain
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
              <https://www.rfc-editor.org/info/rfc7556>.





Carpenter & Liu         Expires December 23, 2019              [Page 20]


Internet-Draft               Limited Domains                   June 2019


   [RFC7663]  Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the
              IAB Workshop on Stack Evolution in a Middlebox Internet
              (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015,
              <https://www.rfc-editor.org/info/rfc7663>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <https://www.rfc-editor.org/info/rfc7788>.

   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
              "Observations on the Dropping of Packets with IPv6
              Extension Headers in the Real World", RFC 7872,
              DOI 10.17487/RFC7872, June 2016,
              <https://www.rfc-editor.org/info/rfc7872>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <https://www.rfc-editor.org/info/rfc8085>.

   [RFC8086]  Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
              in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
              March 2017, <https://www.rfc-editor.org/info/rfc8086>.

   [RFC8100]  Geib, R., Ed. and D. Black, "Diffserv-Interconnection
              Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
              March 2017, <https://www.rfc-editor.org/info/rfc8100>.

   [RFC8151]  Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral,
              "Use Cases for Data Center Network Virtualization Overlay
              Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017,
              <https://www.rfc-editor.org/info/rfc8151>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.





Carpenter & Liu         Expires December 23, 2019              [Page 21]


Internet-Draft               Limited Domains                   June 2019


   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
              Connectivity Establishment (ICE): A Protocol for Network
              Address Translator (NAT) Traversal", RFC 8445,
              DOI 10.17487/RFC8445, July 2018,
              <https://www.rfc-editor.org/info/rfc8445>.

   [RFC8517]  Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
              Jacquenet, "An Inventory of Transport-Centric Functions
              Provided by Middleboxes: An Operator Perspective",
              RFC 8517, DOI 10.17487/RFC8517, February 2019,
              <https://www.rfc-editor.org/info/rfc8517>.

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

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

Appendix A.  Change log [RFC Editor: Please remove]

   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:



Carpenter & Liu         Expires December 23, 2019              [Page 22]


Internet-Draft               Limited Domains                   June 2019


   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.

Appendix B.  Taxonomy of Limited Domains

   This appendix develops a taxonomy for describing limited domains.
   Several major aspects are considered in this taxonomy:

   o  The domain as a whole.



Carpenter & Liu         Expires December 23, 2019              [Page 23]


Internet-Draft               Limited Domains                   June 2019


   o  The individual nodes.

   o  The domain boundary.

   o  The domain's topology.

   o  The domain's technology.

   o  How the domain connects to the Internet.

   o  The security, trust and privacy model.

   o  Operations.

   The following sub-sections analyse each of these aspects.

B.1.  The Domain as a Whole

   o  Why does the domain exist? (e.g., human choice, administrative
      policy, orchestration requirements, technical requirements)

   o  If there are special requirements, are they at Layer 2, Layer 3 or
      an upper layer?

   o  Is the domain managed by humans or fully autonomic?

   o  If managed, what style of management applies?  (Manual
      configuration, automated configuration, orchestration?)

   o  Is there a policy model?  (Intent, configuration policies?)

   o  Does the domain provide controlled or paid service or open access?

B.2.  Individual Nodes

   o  Is a domain member a complete node, or only one interface of a
      node?

   o  Are nodes permanent members of a given domain, or are join and
      leave operations possible?

   o  Are nodes physical or virtual devices?

   o  Are virtual nodes general-purpose, or limited to specific
      functions, applications or users?

   o  Are nodes constrained (by battery etc)?




Carpenter & Liu         Expires December 23, 2019              [Page 24]


Internet-Draft               Limited Domains                   June 2019


   o  Are devices installed "out of the box" or pre-configured?

B.3.  The Domain Boundary

   o  How is the domain boundary identified or defined?

   o  Is the domain boundary fixed or dynamic?

   o  Are boundary nodes special?  Or can any node be at the boundary?

B.4.  Topology

   o  Is the domain a subset of a layer 2 or 3 connectivity domain?

   o  In IP addressing terms, is the domain Link-local, Site-local, or
      Global?

   o  Does the domain overlap other domains?  (In other words, a node
      may or may not be allowed to be a member of multiple domains.)

   o  Does the domain match physical topology, or does it have a virtual
      (overlay) topology?

   o  Is the domain in a single building, vehicle or campus?  Or is it
      distributed?

   o  If distributed, are the interconnections private or over the
      Internet?

   o  In IP addressing terms, is the domain Link-local, Site-local, or
      Global?

   o  Does the scope of IP unicast or multicast addresses map to the
      domain boundary?

B.5.  Technology

   o  What routing protocol(s) are used, or even different forwarding
      mechanisms (MPLS or other non-IP mechanism)?

   o  In an overlay domain, what overlay technique is used (L2VPN,
      L3VPN,...)?

   o  Are there specific QoS requirements?

   o  Link latency - normal or long latency links?

   o  Mobility - are nodes mobile?  Is the whole network mobile?



Carpenter & Liu         Expires December 23, 2019              [Page 25]


Internet-Draft               Limited Domains                   June 2019


   o  Which specific technologies, such as those in Section 4, are
      applicable?

B.6.  Connection to the Internet

   o  Is the Internet connection permanent or intermittent?  (Never
      connected is out of scope.)

   o  What traffic is blocked, in and out?

   o  What traffic is allowed, in and out?

   o  What traffic is transformed, in and out?

   o  Is secure and privileged remote access needed?

   o  Does the domain allow unprivileged remote sessions?

B.7.  Security, Trust and Privacy Model

   o  Must domain members be authorized?

   o  Are all nodes in the domain at the same trust level?

   o  Is traffic authenticated?

   o  Is traffic encrypted?

   o  What is hidden from the outside?

B.8.  Operations

   o  Safety level - does the domain have a critical (human) safety
      role?

   o  Reliability requirement - normal or 99.999% ?

   o  Environment - hazardous conditions?

   o  Installation - are specialists needed?

   o  Service visits - easy, difficult, impossible?

   o  Software/firmware updates - possible or impossible?







Carpenter & Liu         Expires December 23, 2019              [Page 26]


Internet-Draft               Limited Domains                   June 2019


B.9.  Making use of this taxonomy

   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.

Authors' Addresses

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

   Email: brian.e.carpenter@gmail.com


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

   Email: leo.liubing@huawei.com






















Carpenter & Liu         Expires December 23, 2019              [Page 27]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/