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