idnits 2.17.1 draft-carpenter-limited-domains-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2019) is 1700 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-herbert-fast-04 == Outdated reference: A later version (-03) exists of draft-herbert-ipv4-eh-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-20 == Outdated reference: A later version (-04) exists of draft-ietf-dmm-5g-uplane-analysis-02 == Outdated reference: A later version (-17) exists of draft-ietf-intarea-frag-fragile-15 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-11 == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-06 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-06 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational B. Liu 5 Expires: February 3, 2020 Huawei Technologies 6 August 2, 2019 8 Limited Domains and Internet Protocols 9 draft-carpenter-limited-domains-10 11 Abstract 13 There is a noticeable trend towards network requirements, behaviours 14 and semantics that are specific to a particular set of requirements 15 applied within a limited region of the Internet. Policies, default 16 parameters, the options supported, the style of network management 17 and security requirements may vary between such limited regions. 18 This document reviews examples of such limited domains (also known as 19 controlled environments), notes emerging solutions, and includes a 20 related taxonomy. It then briefly discusses the standardization of 21 protocols for limited domains. Finally, it shows the needs for a 22 precise definition of "limited domain membership" and for mechanisms 23 to allow nodes to join a domain securely and to find other members, 24 including boundary nodes. 26 This document is the product of the research of the authors. It has 27 been produced through discussions and consultation within the IETF, 28 but is not the product of IETF conensus. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 3, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Failure Modes in Today's Internet . . . . . . . . . . . . . . 4 66 3. Examples of Limited Domain Requirements . . . . . . . . . . . 5 67 4. Examples of Limited Domain Solutions . . . . . . . . . . . . 8 68 5. The Scope of Protocols in Limited Domains . . . . . . . . . . 11 69 6. Functional Requirements of Limited Domains . . . . . . . . . 13 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 74 11. Informative References . . . . . . . . . . . . . . . . . . . 16 75 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 23 76 Appendix B. Taxonomy of Limited Domains . . . . . . . . . . . . 24 77 B.1. The Domain as a Whole . . . . . . . . . . . . . . . . . . 25 78 B.2. Individual Nodes . . . . . . . . . . . . . . . . . . . . 25 79 B.3. The Domain Boundary . . . . . . . . . . . . . . . . . . . 25 80 B.4. Topology . . . . . . . . . . . . . . . . . . . . . . . . 25 81 B.5. Technology . . . . . . . . . . . . . . . . . . . . . . . 26 82 B.6. Connection to the Internet . . . . . . . . . . . . . . . 26 83 B.7. Security, Trust and Privacy Model . . . . . . . . . . . . 27 84 B.8. Operations . . . . . . . . . . . . . . . . . . . . . . . 27 85 B.9. Making use of this taxonomy . . . . . . . . . . . . . . . 27 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 88 1. Introduction 90 As the Internet continues to grow and diversify, with a realistic 91 prospect of tens of billions of nodes being connected directly and 92 indirectly, there is a noticeable trend towards network-specific and 93 local requirements, behaviours and semantics. The word "local" 94 should be understood in a special sense, however. In some cases it 95 may refer to geographical and physical locality - all the nodes in a 96 single building, on a single campus, or in a given vehicle. In other 97 cases it may refer to a defined set of users or nodes distributed 98 over a much wider area, but drawn together by a single virtual 99 network over the Internet, or a single physical network running in 100 parallel with the Internet. We expand on these possibilities below. 101 To capture the topic, this document refers to such networks as 102 "limited domains". Of course a similar situation may arise for a 103 network that is completely disconnected from the Internet, but that 104 is not our direct concern here. However, it should not be forgotten 105 that interoperability is needed even within a disconnected network. 107 Some people have concerns about splintering of the Internet along 108 political or linguistic boundaries by mechanisms that block the free 109 flow of information. That is not the topic of this document, which 110 does not discuss filtering mechanisms and does not apply to protocols 111 that are designed for use across the whole Internet. It is only 112 concerned with domains that have specific technical requirements. 114 The word "domain" in this document does not refer to naming domains 115 in the DNS, although in some cases a limited domain might 116 incidentally be congruent with a DNS domain. In particular, with a 117 "split horizon" DNS configuration [RFC6950], the split might be at 118 the edge of a limited domain. A recent proposal for defining 119 definite perimeters within the DNS namespace 120 [I-D.dcrocker-dns-perimeter] might also be considered to be a limited 121 domain mechanism. 123 Another term that has been used in some contexts is "controlled 124 environment". For example, [RFC8085] uses this to delimit the 125 operational scope within which a particular tunnel encapsulation 126 might be used. A specific example is GRE-in-UDP encapsulation 127 [RFC8086] which explicitly states that "The controlled environment 128 has less restrictive requirements than the general Internet." For 129 example, non-congestion-controlled traffic might be acceptable within 130 the controlled environment. The same phrase has been used to delimit 131 the useful scope of quality of service or security protocols, e.g. 132 [RFC6398], [RFC6455]. It is not necessarily the case that protocols 133 will fail to operate outside the controlled environment, but rather 134 that they might not operate usefully. In this document, we assume 135 that "limited domain" and "controlled environment" mean the same 136 thing in practice. The term "managed network" has been used in a 137 similar way, e.g. [RFC6947]. In the context of secure multicast, a 138 "group domain of interpretation" is defined by [RFC6407]. 140 The requirements of limited domains will depend on the deployment 141 scenario. Policies, default parameters, and the options supported 142 may vary. Also, the style of network management may vary, between a 143 completely unmanaged network, one with fully autonomic management, 144 one with traditional central management, and mixtures of the above. 145 Finally, the requirements and solutions for security and privacy may 146 vary. 148 This document analyses and discusses some of the consequences of this 149 trend, and how it may impact the idea of universal interoperability 150 in the Internet. Firstly we list examples of limited domain 151 scenarios and of technical solutions for limited domains, with the 152 main focus being the Internet layer of the protocol stack. An 153 appendix provides a taxonomy of the features to be found in limited 154 domains. With this background, we discuss the resulting challenge to 155 the idea that all Internet standards must be universal in scope and 156 applicability. To the contrary, we assert that some protocols need 157 to be specifically limited in their applicability. This implies that 158 the concepts of a limited domain, and of its membership, need to be 159 formalised and supported by secure mechanisms. While this document 160 does not propose a design for such mechanisms, it does outline some 161 functional requirements. 163 This document is the product of the research of the authors. It has 164 been produced through discussions and consultation within the IETF, 165 but is not the product of IETF conensus. 167 2. Failure Modes in Today's Internet 169 Today, the Internet does not have a well-defined concept of limited 170 domains. One result of this is that certain protocols and features 171 fail on certain paths. Earlier analyses of this topic have focused 172 either on the loss of transparency of the Internet [RFC2775], 173 [RFC4924] or on the middleboxes responsible for that loss [RFC3234], 174 [RFC7663], [RFC8517]. Unfortunately the problems persist, both in 175 application protocols, and even in very fundamental mechanisms. For 176 example, the Internet is not transparent to IPv6 extension headers 177 [RFC7872], and Path MTU Discovery has been unreliable for many years 178 [RFC2923], [RFC4821]. IP fragmentation is also unreliable 179 [I-D.ietf-intarea-frag-fragile], and problems in TCP MSS negotiation 180 have been reported [I-D.andrews-tcp-and-ipv6-use-minmtu]. 182 On the security side, the widespread insertion of firewalls at domain 183 boundaries that are perceived by humans but unknown to protocols 184 results in arbitrary failure modes as far as the application layer is 185 concerned. There are operational recommendations and practices that 186 effectively guarantee arbitrary failures in realistic scenarios 187 [I-D.ietf-opsec-ipv6-eh-filtering]. 189 The recent discussions about the unreliability of IP fragmentation 190 and the filtering of IPv6 extension headers have strongly suggested 191 that at least for some protocol elements, transparency is a lost 192 cause and middleboxes are here to stay. In the following two 193 sections, we show that some application environments require protocol 194 features that cannot, or should not, cross the whole Internet. 196 3. Examples of Limited Domain Requirements 198 This section describes various examples where limited domain 199 requirements can easily be identified, either based on an application 200 scenario or on a technical imperative. It is of course not a 201 complete list, and it is presented in an arbitrary order, loosely 202 from smaller to bigger. 204 1. A home network. It will be mainly unmanaged, constructed by a 205 non-specialist, and will possibly include wiring errors such as 206 physical loops. It must work with devices "out of the box" as 207 shipped by their manufacturers and must create adequate security 208 by default. Remote access may be required. The requirements 209 and applicable principles are summarised in [RFC7368]. 211 2. A small office network. This is sometimes very similar to a 212 home network, if whoever is in charge has little or no 213 specialist knowledge, but may have differing security and 214 privacy requirements. In other cases it may be professionally 215 constructed using recommended products and configurations, but 216 operate unmanaged. Remote access may be required. 218 3. A vehicle network. This will be designed by the vehicle 219 manufacturer but may include devices added by the vehicle's 220 owner or operator. Parts of the network will have demanding 221 performance and reliability requirements with implications for 222 human safety. Remote access may be required to certain 223 functions, but absolutely forbidden for others. Communication 224 with other vehicles, roadside infrastructure, and external data 225 sources will be required. See 226 [I-D.ietf-ipwave-vehicular-networking] for a survey of use 227 cases. 229 4. Supervisory Control And Data Acquisition (SCADA) networks, and 230 other hard real time networks. These will exhibit specific 231 technical requirements, including tough real-time performance 232 targets. See for example [RFC8578] for numerous use cases. An 233 example is a building services network. This will be designed 234 specifically for a particular building, but using standard 235 components. Additional devices may need to be added at any 236 time. Parts of the network may have demanding reliability 237 requirements with implications for human safety. Remote access 238 may be required to certain functions, but absolutely forbidden 239 for others. 241 5. Sensor networks. The two preceding cases will all include 242 sensors, but some networks may be specifically limited to 243 sensors and the collection and processing of sensor data. They 244 may be in remote or technically challenging locations and 245 installed by non-specialists. 247 6. Internet of Things (IoT) networks. While this term is very 248 flexible and covers many innovative types of network, including 249 ad hoc networks that are formed spontaneously, and some 250 applications of 5G technology, it seems reasonable to expect 251 that IoT edge networks will have special requirements and 252 protocols that are useful only within a specific domain, and 253 that these protocols cannot, and for security reasons should 254 not, run over the Internet as a whole. 256 7. An important subclass of IoT networks consists of constrained 257 networks [RFC7228] in which the nodes are limited in power 258 consumption and communications bandwidth, and are therefore 259 limited to using very frugal protocols. 261 8. Delay tolerant networks may consist of domains that are 262 relatively isolated and constrained in power (e.g. deep space 263 networks) and are connected only intermittently to the outside, 264 with a very long latency on such connections [RFC4838]. Clearly 265 the protocol requirements and possibilities are very specialised 266 in such networks. 268 9. "Traditional" enterprise and campus networks, which may be 269 spread over many kilometres and over multiple separate sites, 270 with multiple connections to the Internet. Interestingly, the 271 IETF appears never to have analysed this long-established class 272 of networks in a general way, except in connection with IPv6 273 deployment (e.g. [RFC7381]). 275 10. A situation that may arise in an enterprise network is that the 276 Internet-wide solution for a particular requirement may either 277 fail locally, or be much more complicated than is necessary. An 278 example is that the complexity induced by a mechanism such as 279 ICE [RFC8445] is not justified within such a network. 280 Furthermore, ICE cannot be used in some cases because candidate 281 addresses are not known before a call is established, so a 282 different local solution is essential [RFC6947]. 284 11. Managed wide area networks run by service providers for 285 enterprise services such as layer 2 (Ethernet, etc.) point-to- 286 point pseudowires, multipoint layer 2 Ethernet VPNs using VPLS 287 or EVPN, and layer 3 IP VPNs. These are generally characterized 288 by service level agreements for availability and packet loss. 289 These are different from the previous case in that they mostly 290 run over MPLS infrastructures and the requirements for these 291 services are well-defined by the IETF. 293 12. Data centres and hosting centres, or distributed services acting 294 as such centres. These will have high performance, security and 295 privacy requirements and will typically include large numbers of 296 independent "tenant" networks overlaid on shared infrastructure. 298 13. Content Delivery Networks (CDNs), comprising distributed data 299 centres and the paths between them, spanning thousands of 300 kilometres, with numerous connections to the Internet. 302 14. Massive Web Service Provider Networks. This is a small class of 303 networks with well known trademarked names, combining aspects of 304 distributed enterprise networks, data centres and CDNs. They 305 have their own international networks bypassing the generic 306 carriers. Like CDNs, they have numerous connections to the 307 Internet, typically offering a tailored service in each economy. 309 Three other aspects, while not tied to specific network types, also 310 strongly depend on the concept of limited domains: 312 1. Intent Based Networking. In this concept, a network domain is 313 configured and managed in accordance with an abstract policy 314 known as "Intent", to ensure that the network performs as 315 required [I-D.moulchan-nmrg-network-intent-concepts]. Whatever 316 technologies are used to support this, they will be applied 317 within the domain boundary, even if the services supported in the 318 domain are globally accessible. 320 2. Many of the above types of network may be extended throughout the 321 Internet by a variety of virtual private network (VPN) 322 techniques. Therefore we argue that limited domains may overlap 323 each other in an arbitrary fashion by use of virtualization 324 techniques. As noted above in the discussion of controlled 325 environments, specific tunneling and encapsulation techniques may 326 be tailored for use within a given domain. 328 3. Network Slicing. A network slice is a virtual network that 329 consists of a managed set of resources carved off from a larger 330 network [I-D.geng-netslices-architecture]. This is expected to 331 be significant in 5G deployments 332 [I-D.ietf-dmm-5g-uplane-analysis]. Whatever technologies are 333 used to support slicing, they will require a clear definition of 334 the boundary of a given slice within a larger domain. 336 While it is clearly desirable to use common solutions, and therefore 337 common standards, wherever possible, it is increasingly difficult to 338 do so while satisfying the widely varying requirements outlined 339 above. However, there is a tendency when new protocols and protocol 340 extensions are proposed to always ask the question "How will this 341 work across the open Internet?" This document suggests that this is 342 not always the right question. There are protocols and extensions 343 that are not intended to work across the open Internet. On the 344 contrary, their requirements and semantics are specifically limited 345 (in the sense defined above). 347 A common argument is that if a protocol is intended for limited use, 348 the chances are very high that it will in fact be used (or misused) 349 in other scenarios including the so-called open Internet. This is 350 undoubtedly true and means that limited use is not an excuse for bad 351 design or poor security. In fact, a limited use requirement 352 potentially adds complexity to both the protocol and its security 353 design, as discussed later. 355 Nevertheless, because of the diversity of limited domains with 356 specific requirements that is now emerging, specific standards (and 357 ad hoc standards) will probably emerge for different types of domain. 358 There will be attempts to capture each market sector, but the market 359 will demand standardised solutions within each sector. In addition, 360 operational choices will be made that can in fact only work within a 361 limited domain. The history of RSVP illustrates that a standard 362 defined as if it could work over the open Internet might not in fact 363 do so. In general we can no longer assume that a protocol designed 364 according to classical Internet guidelines will in fact work reliably 365 across the network as a whole. However, the "open Internet" must 366 remain as the universal method of interconnection. Reconciling these 367 two aspects is a major challenge. 369 4. Examples of Limited Domain Solutions 371 This section lists various examples of specific limited domain 372 solutions that have been proposed or defined. It intentionally does 373 not include Layer 2 technology solutions, which by definition apply 374 to limited domains. 376 1. Differentiated Services. This mechanism [RFC2474] allows a 377 network to assign locally significant values to the 6-bit 378 Differentiated Services Code Point field in any IP packet. 379 Although there are some recommended codepoint values for 380 specific per-hop queue management behaviours, these are 381 specifically intended to be domain-specific codepoints with 382 traffic being classified, conditioned and re-marked at domain 383 boundaries (unless there is an inter-domain agreement that makes 384 re-marking unnecessary). 386 2. Integrated Services. Although it is not intrinsic in the design 387 of RSVP [RFC2205], it is clear from many years' experience that 388 Integrated Services can only be deployed successfully within a 389 limited domain that is configured with adequate equipment and 390 resources. 392 3. Network function virtualisation. As described in 393 [I-D.irtf-nfvrg-gaps-network-virtualization], this general 394 concept is an open research topic, in which virtual network 395 functions are orchestrated as part of a distributed system. 396 Inevitably such orchestration applies to an administrative 397 domain of some kind, even though cross-domain orchestration is 398 also a research area. 400 4. Service Function Chaining (SFC). This technique [RFC7665] 401 assumes that services within a network are constructed as 402 sequences of individual service functions within a specific SFC- 403 enabled domain such as a 5G domain. As that RFC states: 404 "Specific features may need to be enforced at the boundaries of 405 an SFC-enabled domain, for example to avoid leaking SFC 406 information". A Network Service Header (NSH) [RFC8300] is used 407 to encapsulate packets flowing through the service function 408 chain: "The intended scope of the NSH is for use within a single 409 provider's operational domain." 411 5. Firewall and Service Tickets (FAST). Such tickets would 412 accompany a packet to claim the right to traverse a network or 413 request a specific network service [I-D.herbert-fast]. They 414 would only be meaningful within a particular domain. 416 6. Data Centre Network Virtualization Overlays. A common 417 requirement in data centres that host many tenants (clients) is 418 to provide each one with a secure private network, all running 419 over the same physical infrastructure. [RFC8151] describes 420 various use cases for this, and specifications are under 421 development. These include use cases in which the tenant 422 network is physically split over several data centres, but which 423 must appear to the user as a single secure domain. 425 7. Segment Routing. This is a technique which "steers a packet 426 through an ordered list of instructions, called segments" 427 [RFC8402]. The semantics of these instructions are explicitly 428 local to a segment routing domain or even to a single node. 430 Technically, these segments or instructions are represented as 431 an MPLS label or an IPv6 address, which clearly adds a semantic 432 interpretation to them within the domain. 434 8. Autonomic Networking. As explained in 435 [I-D.ietf-anima-reference-model], an autonomic network is also a 436 security domain within which an autonomic control plane 437 [I-D.ietf-anima-autonomic-control-plane] is used by autonomic 438 service agents. These agents manage technical objectives, which 439 may be locally defined, subject to domain-wide policy. Thus the 440 domain boundary is important for both security and protocol 441 purposes. 443 9. Homenet. As shown in [RFC7368], a home networking domain has 444 specific protocol needs that differ from those in an enterprise 445 network or the Internet as a whole. These include the Home 446 Network Control Protocol (HNCP) [RFC7788] and a naming and 447 discovery solution [I-D.ietf-homenet-simple-naming]. 449 10. Creative uses of IPv6 features. As IPv6 enters more general 450 use, engineers notice that it has much more flexibility than 451 IPv4. Innovative suggestions have been made for: 453 * The flow label, e.g. [RFC6294], 454 [I-D.fioccola-v6ops-ipv6-alt-mark]. 456 * Extension headers, e.g. for segment routing 457 [I-D.ietf-6man-segment-routing-header]. 459 * Meaningful address bits, e.g. [I-D.jiang-semantic-prefix]. 460 Also, segment routing uses IPv6 addresses as segment 461 identifiers with specific local meanings [RFC8402]. 463 * If segment routing is used for network programming 464 [I-D.filsfils-spring-srv6-network-programming], IPv6 465 extension headers will support rather complex local 466 functionality. 468 All of these suggestions are only viable within a specified 469 domain. The case of the extension header is particularly 470 interesting, since its existence has been a major "selling 471 point" for IPv6, but it is notorious that new extension headers 472 are virtually impossible to deploy across the whole Internet 473 [RFC7045], [RFC7872]. It is worth noting that extension header 474 filtering is considered as an important security issue 475 [I-D.ietf-opsec-ipv6-eh-filtering]. There is considerable 476 appetite among vendors or operators to have flexibility in 477 defining extension headers for use in limited or specialised 478 domains, e.g. [I-D.voyer-6man-extension-header-insertion], 479 [BIGIP], and [I-D.li-6man-service-aware-ipv6-network]. Locally 480 significant hop-by-hop options are also envisaged, that would be 481 understood by routers inside a domain but not elsewhere, e.g., 482 [I-D.ioametal-ippm-6man-ioam-ipv6-options]. 484 11. Deterministic Networking (DetNet). The Deterministic Networking 485 Architecture [I-D.ietf-detnet-architecture] and encapsulation 486 [I-D.ietf-detnet-dp-sol] aim to support flows with extremely low 487 data loss rates and bounded latency, but only within a part of 488 the network that is "DetNet aware". Thus, as for differentiated 489 services above, the concept of a domain is fundamental. 491 12. Provisioning Domains (PvDs). An architecture for Multiple 492 Provisioning Domains has been defined [RFC7556] to allow hosts 493 attached to multiple networks to learn explicit details about 494 the services provided by each of those networks. 496 13. Address Scopes. For completeness, we mention that, particularly 497 in IPv6, some addresses have explicitly limited scope. In 498 particular, link-local addresses are limited to a single 499 physical link [RFC4291], and Unique Local Addresses [RFC4193] 500 are limited to a somewhat loosely defined local site scope. 501 Previously, site-local addresses were defined, but they were 502 obsoleted precisely because of "the fuzzy nature of the site 503 concept" [RFC3879]. Multicast addresses also have explicit 504 scoping [RFC4291]. 506 14. As an application layer example, consider streaming services 507 such as IPTV infrastructures that rely on standard protocols, 508 but access is not globally available. 510 5. The Scope of Protocols in Limited Domains 512 One consequence of the deployment of limited domains in the Internet 513 is that some protocols will be designed, extended or configured so 514 that they only work correctly between end systems in such domains. 515 This is to some extent encouraged by some existing standards and by 516 the assignment of code points for local or experimental use. In any 517 case it cannot be prevented. Also, by endorsing efforts such as 518 Service Function Chaining, Segment Routing and Deterministic 519 Networking, the IETF is in effect encouraging such deployments. 520 Furthermore, it seems inevitable, if the "Internet of Things" becomes 521 reality, that millions of edge networks containing completely novel 522 types of node will be connected to the Internet; each one of these 523 edge networks will be a limited domain. 525 It is therefore appropriate to discuss whether protocols or protocol 526 extensions should sometimes be standardised to interoperate only 527 within a Limited Domain boundary. Such protocols would not be 528 required to interoperate across the Internet as a whole. Several 529 possibly overlapping scenarios could then arise: 531 A. If a limited domain is split into two parts connected over the 532 Internet directly at the IP layer (i.e. with no tunnel 533 encapsulating the packets), a limited-domain protocol could be 534 operated between those two parts regardless of its special nature, 535 as long as it respects standard IP formats and is not arbitrarily 536 blocked by firewalls. A simple example is any protocol using a 537 port number assigned to a specific non-IETF protocol. 539 Such a protocol could reasonably be described as an "inter-domain" 540 protocol because the Internet is transparent to it, even if it is 541 meaningless except in the two parts of the limited domain. This 542 is of course nothing new in the Internet architecture. 544 B. If a limited-domain protocol does not respect standard IP 545 formats (for example, if it includes a non-standard IPv6 extension 546 header), it could not be operated between two parts of a domain 547 split at the IP layer. 549 Such a protocol could reasonably be described as an "intra-domain" 550 protocol, and the Internet is opaque to it. 552 C. If a limited-domain protocol is clearly specified to be 553 invalid outside its domain of origin, neither scenario A nor B 554 applies. The two domains need to be unified as a single virtual 555 domain. For example, an encapsulating tunnel between the parts of 556 the split domain could be used. Also, nodes at the domain 557 boundary must drop all packets using the limited-domain protocol. 559 D. If a limited-domain protocol has domain-specific variants, 560 such that implementations in different domains could not 561 interoperate if those domains were unified by some mechanism, the 562 protocol is not interoperable in the normal sense. If two domains 563 using it were merged, the protocol might fail unpredictably. A 564 simple example is any protocol using a port number assigned for 565 experimental use. Such a protocol usually also falls into 566 scenario C. 568 To provide an existing example, consider Differentiated Services 569 [RFC2474]. A packet containing any value whatever in the 6 bits of 570 the Differentiated Service Code Point (DSCP) is well-formed and falls 571 into scenario A. However, because the semantics of DSCP values are 572 locally significant, the packet also falls into scenario D. In fact, 573 differentiated services are only interoperable across domain 574 boundaries if there is a corresponding agreement between the 575 operators; otherwise a specific gateway function is required for 576 meaningful interoperability. Much more detailed discussion is to be 577 found in [RFC2474] and [RFC8100]. 579 To provide a provocative example, consider the proposal in 580 [I-D.voyer-6man-extension-header-insertion] that the restrictions in 581 [RFC8200] should be relaxed to allow IPv6 extension headers to be 582 inserted on the fly in IPv6 packets. If this is done in such a way 583 that the affected packets can never leave the specific limited domain 584 in which they were modified, scenario C applies. If the semantic 585 content of the inserted headers is locally defined, scenario D also 586 applies. In neither case is the Internet disturbed. 588 The FAST proposal mentioned above is also an interesting case study. 589 The semantics of FAST tickets [I-D.herbert-fast] have limited scope. 590 However, they are designed in a way that in principle allows them to 591 traverse the open Internet, as standardized IPv6 hop-by-hop options 592 or even as a proposed form of IPv4 extension header 593 [I-D.herbert-ipv4-eh]. Whether such options can be used reliably 594 across the open Internet remains unclear 595 [I-D.ietf-opsec-ipv6-eh-filtering]. 597 We conclude that it is reasonable to explicitly define limited-domain 598 protocols, either as standards or as proprietary mechanisms, as long 599 as they describe which of the above scenarios apply and they clarify 600 how the domain is defined. As long as all relevant standards are 601 respected outside the domain boundary, a well-specified limited- 602 domain protocol is not harmful to the Internet. However, as 603 described in the next section, mechanisms are needed to support 604 domain membership operations. 606 Note that this conclusion is not a recommendation to abandon the 607 normal goal that a standardized protocol should be global in scope 608 and able to interoperate across the open Internet. It is simply a 609 recognition that this will not always be the case. 611 6. Functional Requirements of Limited Domains 613 Noting that limited-domain protocols have been defined in the past, 614 and that others will undoubtedly be defined in the future, it is 615 useful to consider how a protocol can be made aware of the domain 616 within which it operates, and how the domain boundary nodes can be 617 identified. As the taxonomy in Appendix B shows, there are numerous 618 aspects to a domain. However, we can identify some generally 619 required features and functions that would apply partially or 620 completely to many cases. 622 Our basic assumption is that it should be possible for domains to be 623 created and managed automatically, with minimal human configuration 624 required. We therefore discuss requirements for automating domain 625 creation and management. 627 Firstly, if we drew a topology map, any domain -- virtual or physical 628 -- will have a well defined boundary between "inside" and "outside". 629 However, that boundary in itself has no technical meaning. What 630 matters in reality is whether a node is a member of the domain, and 631 whether it is at the boundary between the domain and the rest of the 632 Internet. Thus the boundary in itself does not need to be 633 identified. However, a sending node needs to know whether it is 634 sending to an inside or outside destination; a receiving node needs 635 to know whether a packet originated inside or outside; and a boundary 636 node needs to know which of its interfaces are inward-facing or 637 outward-facing. It is irrelevant whether the interfaces involved are 638 physical or virtual. 640 To underline that domain boundaries need to be identifiable, consider 641 the statement from the Deterministic Networking Problem Statement 642 [RFC8557] that "there is still a lack of clarity regarding the limits 643 of a domain where a deterministic path can be set up". This remark 644 can certainly be generalised. 646 With this perspective, we can list some general functional 647 requirements. An underlying assumption here is that domain 648 membership operations should be cryptographically secured; a domain 649 without such security cannot be reliably protected from attack. 651 1. Domain Identity. A domain must have a unique and verifiable 652 identifier; effectively this should be a public key for the 653 domain. Without this, there is no way to secure domain 654 operations and domain membership. The holder of the 655 corresponding private key becomes the trust anchor for the 656 domain. 658 2. Nesting. It must be possible for domains to be nested (see, for 659 example, the network slicing example mentioned above. 661 3. Overlapping. It must be possible for nodes to be in more than 662 one domain (see, for example, the case of PVDs mentioned above). 664 4. Node Eligibility. It must be possible for a node to determine 665 which domain(s) it can potentially join, and on which 666 interface(s). 668 5. Secure Enrolment. A node must be able to enrol in a given 669 domain via secure node identfication and to acquire relevant 670 security credentials (authorization) for operations within the 671 domain. If a node has multiple physical or virtual interfaces, 672 they may require to be individually enrolled. 674 6. Withdrawal. A node must be able to cancel enrolment in a given 675 domain. 677 7. Dynamic Membership. Optionally, a node should be able 678 temporarily leave or rejoin a domain (i.e. enrolment is 679 persistent but membership is intermittent). 681 8. Role, implying authorization to perform a certain set of 682 actions. A node must have a verifiable role. In the simplest 683 case, the choices of role are "interior node" and "boundary 684 node". In a boundary node, individual interfaces may have 685 different roles, e.g. "inward facing" and "outward facing". 687 9. Verify Peer. A node must be able to verify whether another node 688 is a member of the domain. 690 10. Verify Role. A node must be able to learn the verified role of 691 another node. In particular, it must be possible for a node to 692 find boundary nodes (interfacing to the Internet). 694 11. Domain Data. In a domain with management requirements, it must 695 be possible for a node to acquire domain policy and/or domain 696 configuration data. This would include, for example, filtering 697 policy to ensure that inappropriate packets do not leave the 698 domain. 700 These requirements could form the basis for further analysis and 701 solution design. 703 Another aspect is whether individual packets within a limited domain 704 need to carry any sort of indicator that they belong to that domain, 705 or whether this information will be implicit in the IP addresses of 706 the packet. A related question is whether individual packets need 707 cryptographic authentication. This topic is for further study. 709 7. Security Considerations 711 Often, the boundary of a limited domain will also act as a security 712 boundary. In particular, it will serve as a trust boundary, and as a 713 boundary of authority for defining capabilities. For example, 714 segment routing [RFC8402] explicitly uses the concept of a "trusted 715 domain" in this way. Within the boundary, limited-domain protocols 716 or protocol features will be useful, but they will in many cases be 717 meaningless or harmful if they enter or leave the domain. 719 The security model for a limited-scope protocol must allow for the 720 boundary, and in particular for a trust model that changes at the 721 boundary. Typically, credentials will need to be signed by a domain- 722 specific authority. 724 8. IANA Considerations 726 This document makes no request of the IANA. 728 9. Contributors 730 Sheng Jiang made important contributions to this document. 732 10. Acknowledgements 734 Useful comments were received from Amelia Andersdotter, Edward 735 Birrane, David Black, Ron Bonica, Mohamed Boucadair, Tim Chown, 736 Darren Dukes, Adrian Farrel, Tom Herbert, John Klensin, Andy Malis, 737 Michael Richardson, Mark Smith, Rick Taylor, Niels ten Oever, and 738 other members of the ANIMA and INTAREA WGs. 740 11. Informative References 742 [BIGIP] Li, R., "HUAWEI - Big IP Initiative.", 2018, 743 . 745 [I-D.andrews-tcp-and-ipv6-use-minmtu] 746 Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", 747 draft-andrews-tcp-and-ipv6-use-minmtu-04 (work in 748 progress), October 2015. 750 [I-D.dcrocker-dns-perimeter] 751 Crocker, D. and T. Adams, "DNS Perimeter Overlay", draft- 752 dcrocker-dns-perimeter-01 (work in progress), June 2019. 754 [I-D.filsfils-spring-srv6-network-programming] 755 Filsfils, C., Camarillo, P., Leddy, J., 756 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 757 Network Programming", draft-filsfils-spring-srv6-network- 758 programming-07 (work in progress), February 2019. 760 [I-D.fioccola-v6ops-ipv6-alt-mark] 761 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 762 Performance Measurement with Alternate Marking Method", 763 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 764 June 2018. 766 [I-D.geng-netslices-architecture] 767 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 768 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 769 Architecture", draft-geng-netslices-architecture-02 (work 770 in progress), July 2017. 772 [I-D.herbert-fast] 773 Herbert, T., "Firewall and Service Tickets", draft- 774 herbert-fast-04 (work in progress), April 2019. 776 [I-D.herbert-ipv4-eh] 777 Herbert, T., "IPv4 Extension Headers and Flow Label", 778 draft-herbert-ipv4-eh-01 (work in progress), May 2019. 780 [I-D.ietf-6man-segment-routing-header] 781 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 782 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 783 Routing Header (SRH)", draft-ietf-6man-segment-routing- 784 header-21 (work in progress), June 2019. 786 [I-D.ietf-anima-autonomic-control-plane] 787 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 788 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 789 plane-20 (work in progress), July 2019. 791 [I-D.ietf-anima-reference-model] 792 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 793 and J. Nobre, "A Reference Model for Autonomic 794 Networking", draft-ietf-anima-reference-model-10 (work in 795 progress), November 2018. 797 [I-D.ietf-detnet-architecture] 798 Finn, N., Thubert, P., Varga, B., and J. Farkas, 799 "Deterministic Networking Architecture", draft-ietf- 800 detnet-architecture-13 (work in progress), May 2019. 802 [I-D.ietf-detnet-dp-sol] 803 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 804 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 805 "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- 806 sol-04 (work in progress), March 2018. 808 [I-D.ietf-dmm-5g-uplane-analysis] 809 Homma, S., Miyasaka, T., Matsushima, S., and d. 810 daniel.voyer@bell.ca, "User Plane Protocol and 811 Architectural Analysis on 3GPP 5G System", draft-ietf-dmm- 812 5g-uplane-analysis-02 (work in progress), July 2019. 814 [I-D.ietf-homenet-simple-naming] 815 Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming 816 and Service Discovery Architecture", draft-ietf-homenet- 817 simple-naming-03 (work in progress), October 2018. 819 [I-D.ietf-intarea-frag-fragile] 820 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 821 and F. Gont, "IP Fragmentation Considered Fragile", draft- 822 ietf-intarea-frag-fragile-15 (work in progress), July 823 2019. 825 [I-D.ietf-ipwave-vehicular-networking] 826 Jeong, J., "IP Wireless Access in Vehicular Environments 827 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 828 ipwave-vehicular-networking-11 (work in progress), July 829 2019. 831 [I-D.ietf-opsec-ipv6-eh-filtering] 832 Gont, F. and W. LIU, "Recommendations on the Filtering of 833 IPv6 Packets Containing IPv6 Extension Headers", draft- 834 ietf-opsec-ipv6-eh-filtering-06 (work in progress), July 835 2018. 837 [I-D.ioametal-ippm-6man-ioam-ipv6-options] 838 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 839 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 840 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 841 "In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam- 842 ipv6-options-02 (work in progress), March 2019. 844 [I-D.irtf-nfvrg-gaps-network-virtualization] 845 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 846 Aranda, P., and P. Lynch, "Network Virtualization Research 847 Challenges", draft-irtf-nfvrg-gaps-network- 848 virtualization-10 (work in progress), September 2018. 850 [I-D.jiang-semantic-prefix] 851 Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, 852 "Analysis of Semantic Embedded IPv6 Address Schemas", 853 draft-jiang-semantic-prefix-06 (work in progress), July 854 2013. 856 [I-D.li-6man-service-aware-ipv6-network] 857 Li, Z. and S. Peng, "Service-aware IPv6 Network", draft- 858 li-6man-service-aware-ipv6-network-00 (work in progress), 859 March 2019. 861 [I-D.moulchan-nmrg-network-intent-concepts] 862 Sivakumar, K. and M. Chandramouli, "Concepts of Network 863 Intent", draft-moulchan-nmrg-network-intent-concepts-00 864 (work in progress), October 2017. 866 [I-D.voyer-6man-extension-header-insertion] 867 daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes, 868 D., Previdi, S., and S. Matsushima, "Insertion of IPv6 869 Segment Routing Headers in a Controlled Domain", draft- 870 voyer-6man-extension-header-insertion-06 (work in 871 progress), July 2019. 873 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 874 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 875 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 876 September 1997, . 878 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 879 "Definition of the Differentiated Services Field (DS 880 Field) in the IPv4 and IPv6 Headers", RFC 2474, 881 DOI 10.17487/RFC2474, December 1998, 882 . 884 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 885 DOI 10.17487/RFC2775, February 2000, 886 . 888 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 889 RFC 2923, DOI 10.17487/RFC2923, September 2000, 890 . 892 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 893 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 894 . 896 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 897 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 898 2004, . 900 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 901 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 902 . 904 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 905 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 906 2006, . 908 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 909 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 910 . 912 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 913 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 914 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 915 April 2007, . 917 [RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet 918 Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, 919 . 921 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 922 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 923 2011, . 925 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 926 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 927 2011, . 929 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 930 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 931 October 2011, . 933 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 934 RFC 6455, DOI 10.17487/RFC6455, December 2011, 935 . 937 [RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. 938 Veikkolainen, "The Session Description Protocol (SDP) 939 Alternate Connectivity (ALTC) Attribute", RFC 6947, 940 DOI 10.17487/RFC6947, May 2013, 941 . 943 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 944 "Architectural Considerations on Application Features in 945 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 946 . 948 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 949 of IPv6 Extension Headers", RFC 7045, 950 DOI 10.17487/RFC7045, December 2013, 951 . 953 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 954 Constrained-Node Networks", RFC 7228, 955 DOI 10.17487/RFC7228, May 2014, 956 . 958 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 959 Weil, "IPv6 Home Networking Architecture Principles", 960 RFC 7368, DOI 10.17487/RFC7368, October 2014, 961 . 963 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 964 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 965 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 966 . 968 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 969 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 970 . 972 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 973 IAB Workshop on Stack Evolution in a Middlebox Internet 974 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 975 . 977 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 978 Chaining (SFC) Architecture", RFC 7665, 979 DOI 10.17487/RFC7665, October 2015, 980 . 982 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 983 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 984 2016, . 986 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 987 "Observations on the Dropping of Packets with IPv6 988 Extension Headers in the Real World", RFC 7872, 989 DOI 10.17487/RFC7872, June 2016, 990 . 992 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 993 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 994 March 2017, . 996 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 997 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 998 March 2017, . 1000 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1001 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1002 March 2017, . 1004 [RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, 1005 "Use Cases for Data Center Network Virtualization Overlay 1006 Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017, 1007 . 1009 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1010 (IPv6) Specification", STD 86, RFC 8200, 1011 DOI 10.17487/RFC8200, July 2017, 1012 . 1014 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1015 "Network Service Header (NSH)", RFC 8300, 1016 DOI 10.17487/RFC8300, January 2018, 1017 . 1019 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1020 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1021 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1022 July 2018, . 1024 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1025 Connectivity Establishment (ICE): A Protocol for Network 1026 Address Translator (NAT) Traversal", RFC 8445, 1027 DOI 10.17487/RFC8445, July 2018, 1028 . 1030 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1031 Jacquenet, "An Inventory of Transport-Centric Functions 1032 Provided by Middleboxes: An Operator Perspective", 1033 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1034 . 1036 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 1037 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 1038 . 1040 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 1041 RFC 8578, DOI 10.17487/RFC8578, May 2019, 1042 . 1044 Appendix A. Change log [RFC Editor: Please remove] 1046 draft-carpenter-limited-domains-00, 2018-06-11: 1048 Initial version 1050 draft-carpenter-limited-domains-01, 2018-07-01: 1052 Minor terminology clarifications 1054 draft-carpenter-limited-domains-02, 2018-08-03: 1056 Additions following IETF102 discussions 1058 Updated authorship/contributors 1060 draft-carpenter-limited-domains-03, 2018-09-12: 1062 First draft of taxonomy 1064 Editorial improvements 1066 draft-carpenter-limited-domains-04, 2018-10-14: 1068 Reorganized section 3 1070 Newly written sections 6 and 7 1072 Editorial improvements 1074 draft-carpenter-limited-domains-05, 2018-12-12: 1076 Added discussion of transparency/filtering debates 1078 Added discussion of "controlled environment" 1080 Modified assertion about localized standards 1082 Editorial improvements 1084 draft-carpenter-limited-domains-06, 2019-03-02: 1086 Minor updates, fixed reference nits 1088 draft-carpenter-limited-domains-07, 2019-04-15: 1090 Moved taxonomy to an appendix. 1092 Added examples and references. 1094 Editorial improvements 1096 draft-carpenter-limited-domains-08, 2019-06-12: 1098 Added short discussion of address scopes. 1100 Added possibility of nested or overlapped domains. 1102 Integrated other comments received. 1104 Editorial improvements 1106 draft-carpenter-limited-domains-09, 2019-06-21: 1108 Additional 5G citations. 1110 draft-carpenter-limited-domains-10, 2019-08-02: 1112 ISE comments. 1114 Appendix B. Taxonomy of Limited Domains 1116 This appendix develops a taxonomy for describing limited domains. 1117 Several major aspects are considered in this taxonomy: 1119 o The domain as a whole. 1121 o The individual nodes. 1123 o The domain boundary. 1125 o The domain's topology. 1127 o The domain's technology. 1129 o How the domain connects to the Internet. 1131 o The security, trust and privacy model. 1133 o Operations. 1135 The following sub-sections analyse each of these aspects. 1137 B.1. The Domain as a Whole 1139 o Why does the domain exist? (e.g., human choice, administrative 1140 policy, orchestration requirements, technical requirements) 1142 o If there are special requirements, are they at Layer 2, Layer 3 or 1143 an upper layer? 1145 o Is the domain managed by humans or fully autonomic? 1147 o If managed, what style of management applies? (Manual 1148 configuration, automated configuration, orchestration?) 1150 o Is there a policy model? (Intent, configuration policies?) 1152 o Does the domain provide controlled or paid service or open access? 1154 B.2. Individual Nodes 1156 o Is a domain member a complete node, or only one interface of a 1157 node? 1159 o Are nodes permanent members of a given domain, or are join and 1160 leave operations possible? 1162 o Are nodes physical or virtual devices? 1164 o Are virtual nodes general-purpose, or limited to specific 1165 functions, applications or users? 1167 o Are nodes constrained (by battery etc)? 1169 o Are devices installed "out of the box" or pre-configured? 1171 B.3. The Domain Boundary 1173 o How is the domain boundary identified or defined? 1175 o Is the domain boundary fixed or dynamic? 1177 o Are boundary nodes special? Or can any node be at the boundary? 1179 B.4. Topology 1181 o Is the domain a subset of a layer 2 or 3 connectivity domain? 1183 o In IP addressing terms, is the domain Link-local, Site-local, or 1184 Global? 1186 o Does the domain overlap other domains? (In other words, a node 1187 may or may not be allowed to be a member of multiple domains.) 1189 o Does the domain match physical topology, or does it have a virtual 1190 (overlay) topology? 1192 o Is the domain in a single building, vehicle or campus? Or is it 1193 distributed? 1195 o If distributed, are the interconnections private or over the 1196 Internet? 1198 o In IP addressing terms, is the domain Link-local, Site-local, or 1199 Global? 1201 o Does the scope of IP unicast or multicast addresses map to the 1202 domain boundary? 1204 B.5. Technology 1206 o What routing protocol(s) are used, or even different forwarding 1207 mechanisms (MPLS or other non-IP mechanism)? 1209 o In an overlay domain, what overlay technique is used (L2VPN, 1210 L3VPN,...)? 1212 o Are there specific QoS requirements? 1214 o Link latency - normal or long latency links? 1216 o Mobility - are nodes mobile? Is the whole network mobile? 1218 o Which specific technologies, such as those in Section 4, are 1219 applicable? 1221 B.6. Connection to the Internet 1223 o Is the Internet connection permanent or intermittent? (Never 1224 connected is out of scope.) 1226 o What traffic is blocked, in and out? 1228 o What traffic is allowed, in and out? 1230 o What traffic is transformed, in and out? 1232 o Is secure and privileged remote access needed? 1233 o Does the domain allow unprivileged remote sessions? 1235 B.7. Security, Trust and Privacy Model 1237 o Must domain members be authorized? 1239 o Are all nodes in the domain at the same trust level? 1241 o Is traffic authenticated? 1243 o Is traffic encrypted? 1245 o What is hidden from the outside? 1247 B.8. Operations 1249 o Safety level - does the domain have a critical (human) safety 1250 role? 1252 o Reliability requirement - normal or 99.999% ? 1254 o Environment - hazardous conditions? 1256 o Installation - are specialists needed? 1258 o Service visits - easy, difficult, impossible? 1260 o Software/firmware updates - possible or impossible? 1262 B.9. Making use of this taxonomy 1264 This taxonomy could be used to design or analyse a specific type of 1265 limited domain. For the present document, it is intended only to 1266 form a background to the scope of protocols used in limited domains, 1267 and the mechanisms required to securely define domain membership and 1268 properties. 1270 Authors' Addresses 1272 Brian Carpenter 1273 The University of Auckland 1274 School of Computer Science 1275 University of Auckland 1276 PB 92019 1277 Auckland 1142 1278 New Zealand 1280 Email: brian.e.carpenter@gmail.com 1281 Bing Liu 1282 Huawei Technologies 1283 Q14, Huawei Campus 1284 No.156 Beiqing Road 1285 Hai-Dian District, Beijing 100095 1286 P.R. China 1288 Email: leo.liubing@huawei.com