idnits 2.17.1 draft-carpenter-limited-domains-13.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 (2 February 2020) is 1516 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-fz-6man-ipv6-alt-mark-05 == 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 (-30) exists of draft-ietf-anima-autonomic-control-plane-21 == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-03 == Outdated reference: A later version (-04) exists of draft-ietf-dmm-5g-uplane-analysis-03 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-13 == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-08 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-04 == Outdated reference: A later version (-02) exists of draft-smith-6man-in-flight-eh-insertion-harmful-01 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-08 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational B. Liu 5 Expires: 5 August 2020 Huawei Technologies 6 2 February 2020 8 Limited Domains and Internet Protocols 9 draft-carpenter-limited-domains-13 11 Abstract 13 There is a noticeable trend towards network behaviours and semantics 14 that are specific to a particular set of requirements applied within 15 a limited region of the Internet. Policies, default parameters, the 16 options supported, the style of network management and security 17 requirements may vary between such limited regions. This document 18 reviews examples of such limited domains (also known as controlled 19 environments), notes emerging solutions, and includes a related 20 taxonomy. It then briefly discusses the standardization of protocols 21 for limited domains. Finally, it shows the needs for a precise 22 definition of "limited domain membership" and for mechanisms to allow 23 nodes to join a domain securely and to find other members, including 24 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 5 August 2020. 47 Copyright Notice 49 Copyright (c) 2020 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 (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Failure Modes in Today's Internet . . . . . . . . . . . . . . 4 65 3. Examples of Limited Domain Requirements . . . . . . . . . . . 5 66 4. Examples of Limited Domain Solutions . . . . . . . . . . . . 9 67 5. The Scope of Protocols in Limited Domains . . . . . . . . . . 12 68 6. Functional Requirements of Limited Domains . . . . . . . . . 14 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 71 9. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 73 11. Informative References . . . . . . . . . . . . . . . . . . . 17 74 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 26 75 Appendix B. Taxonomy of Limited Domains . . . . . . . . . . . . 27 76 B.1. The Domain as a Whole . . . . . . . . . . . . . . . . . . 28 77 B.2. Individual Nodes . . . . . . . . . . . . . . . . . . . . 28 78 B.3. The Domain Boundary . . . . . . . . . . . . . . . . . . . 28 79 B.4. Topology . . . . . . . . . . . . . . . . . . . . . . . . 28 80 B.5. Technology . . . . . . . . . . . . . . . . . . . . . . . 29 81 B.6. Connection to the Internet . . . . . . . . . . . . . . . 29 82 B.7. Security, Trust and Privacy Model . . . . . . . . . . . . 30 83 B.8. Operations . . . . . . . . . . . . . . . . . . . . . . . 30 84 B.9. Making use of this taxonomy . . . . . . . . . . . . . . . 30 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 87 1. Introduction 89 As the Internet continues to grow and diversify, with a realistic 90 prospect of tens of billions of nodes being connected directly and 91 indirectly, there is a noticeable trend towards network-specific and 92 local requirements, behaviours and semantics. The word "local" 93 should be understood in a special sense, however. In some cases it 94 may refer to geographical and physical locality - all the nodes in a 95 single building, on a single campus, or in a given vehicle. In other 96 cases it may refer to a defined set of users or nodes distributed 97 over a much wider area, but drawn together by a single virtual 98 network over the Internet, or a single physical network running in 99 parallel with the Internet. We expand on these possibilities below. 100 To capture the topic, this document refers to such networks as 101 "limited domains". Of course a similar situation may arise for a 102 network that is completely disconnected from the Internet, but that 103 is not our direct concern here. However, it should not be forgotten 104 that interoperability is needed even within a disconnected network. 106 Some people have concerns about splintering of the Internet along 107 political or linguistic boundaries by mechanisms that block the free 108 flow of information. That is not the topic of this document, which 109 does not discuss filtering mechanisms (see [RFC7754]) and does not 110 apply to protocols that are designed for use across the whole 111 Internet. It is only concerned with domains that have specific 112 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 protocols [RFC6398]. It is 132 not necessarily the case that protocols will fail to operate outside 133 the controlled environment, but rather that they might not operate 134 optimally. In this document, we assume that "limited domain" and 135 "controlled environment" mean the same thing in practice. The term 136 "managed network" has been used in a similar way, e.g. [RFC6947]. 137 In the context of secure multicast, a "group domain of 138 interpretation" is defined by [RFC6407]. 140 Yet more definitions of types of domain are to be found in the 141 routing area, such as [RFC4397], [RFC4427], and [RFC4655]. We 142 conclude that the notion of a limited domain is very widespread in 143 many aspects of Internet technology. 145 The requirements of limited domains will depend on the deployment 146 scenario. Policies, default parameters, and the options supported 147 may vary. Also, the style of network management may vary, between a 148 completely unmanaged network, one with fully autonomic management, 149 one with traditional central management, and mixtures of the above. 150 Finally, the requirements and solutions for security and privacy may 151 vary. 153 This document analyses and discusses some of the consequences of this 154 trend, and how it may impact the idea of universal interoperability 155 in the Internet. Firstly we list examples of limited domain 156 scenarios and of technical solutions for limited domains, with the 157 main focus being the Internet layer of the protocol stack. An 158 appendix provides a taxonomy of the features to be found in limited 159 domains. With this background, we discuss the resulting challenge to 160 the idea that all Internet standards must be universal in scope and 161 applicability. To the contrary, we assert that some protocols, 162 although needing to be standardized and interoperable, also need to 163 be specifically limited in their applicability. This implies that 164 the concepts of a limited domain, and of its membership, need to be 165 formalised and supported by secure mechanisms. While this document 166 does not propose a design for such mechanisms, it does outline some 167 functional requirements. 169 This document is the product of the research of the authors. It has 170 been produced through discussions and consultation within the IETF, 171 but is not the product of IETF conensus. 173 2. Failure Modes in Today's Internet 175 Today, the Internet does not have a well-defined concept of limited 176 domains. One result of this is that certain protocols and features 177 fail on certain paths. Earlier analyses of this topic have focused 178 either on the loss of transparency of the Internet [RFC2775], 179 [RFC4924] or on the middleboxes responsible for that loss [RFC3234], 180 [RFC7663], [RFC8517]. Unfortunately the problems persist, both in 181 application protocols, and even in very fundamental mechanisms. For 182 example, the Internet is not transparent to IPv6 extension headers 183 [RFC7872], and Path MTU Discovery has been unreliable for many years 184 [RFC2923], [RFC4821]. IP fragmentation is also unreliable 185 [I-D.ietf-intarea-frag-fragile], and problems in TCP MSS negotiation 186 have been reported [I-D.andrews-tcp-and-ipv6-use-minmtu]. 188 On the security side, the widespread insertion of firewalls at domain 189 boundaries that are perceived by humans but unknown to protocols 190 results in arbitrary failure modes as far as the application layer is 191 concerned. There are operational recommendations and practices that 192 effectively guarantee arbitrary failures in realistic scenarios 193 [I-D.ietf-opsec-ipv6-eh-filtering]. 195 Domain boundaries that are defined administratively (e.g. by address 196 filtering rules in routers) are prone to leakage caused by human 197 error, especially if the limited domain traffic appears otherwise 198 normal to the boundary routers. In this case, the network operator 199 needs to take active steps to protect the boundary. This form of 200 leakage is much less likely if nodes must be explicitly configured to 201 handle a given limited domain protocol, for example by installing a 202 specific protocol handler. 204 Investigations of the unreliability of IP fragmentation 205 [I-D.ietf-intarea-frag-fragile] and the filtering of IPv6 extension 206 headers [RFC7872] strongly suggest that at least for some protocol 207 elements, transparency is a lost cause and middleboxes are here to 208 stay. In the following two sections, we show that some application 209 environments require protocol features that cannot, or should not, 210 cross the whole Internet. 212 3. Examples of Limited Domain Requirements 214 This section describes various examples where limited domain 215 requirements can easily be identified, either based on an application 216 scenario or on a technical imperative. It is of course not a 217 complete list, and it is presented in an arbitrary order, loosely 218 from smaller to bigger. 220 1. A home network. It will be mainly unmanaged, constructed by a 221 non-specialist. It must work with devices "out of the box" as 222 shipped by their manufacturers and must create adequate security 223 by default. Remote access may be required. The requirements 224 and applicable principles are summarised in [RFC7368]. 226 2. A small office network. This is sometimes very similar to a 227 home network, if whoever is in charge has little or no 228 specialist knowledge, but may have differing security and 229 privacy requirements. In other cases it may be professionally 230 constructed using recommended products and configurations, but 231 operate unmanaged. Remote access may be required. 233 3. A vehicle network. This will be designed by the vehicle 234 manufacturer but may include devices added by the vehicle's 235 owner or operator. Parts of the network will have demanding 236 performance and reliability requirements with implications for 237 human safety. Remote access may be required to certain 238 functions, but absolutely forbidden for others. Communication 239 with other vehicles, roadside infrastructure, and external data 240 sources will be required. See 241 [I-D.ietf-ipwave-vehicular-networking] for a survey of use 242 cases. 244 4. Supervisory Control And Data Acquisition (SCADA) networks, and 245 other hard real time networks. These will exhibit specific 246 technical requirements, including tough real-time performance 247 targets. See for example [RFC8578] for numerous use cases. An 248 example is a building services network. This will be designed 249 specifically for a particular building, but using standard 250 components. Additional devices may need to be added at any 251 time. Parts of the network may have demanding reliability 252 requirements with implications for human safety. Remote access 253 may be required to certain functions, but absolutely forbidden 254 for others. An extreme example is a network used for Virtual 255 Reality or Augmented Reality applications, where the latency 256 requirements are very stringent. 258 5. Sensor networks. The two preceding cases will all include 259 sensors, but some networks may be specifically limited to 260 sensors and the collection and processing of sensor data. They 261 may be in remote or technically challenging locations and 262 installed by non-specialists. 264 6. Internet of Things (IoT) networks. While this term is very 265 flexible and covers many innovative types of network, including 266 ad hoc networks that are formed spontaneously, and some 267 applications of 5G technology, it seems reasonable to expect 268 that IoT edge networks will have special requirements and 269 protocols that are useful only within a specific domain, and 270 that these protocols cannot, and for security reasons should 271 not, run over the Internet as a whole. 273 7. An important subclass of IoT networks consists of constrained 274 networks [RFC7228] in which the nodes are limited in power 275 consumption and communications bandwidth, and are therefore 276 limited to using very frugal protocols. 278 8. Delay tolerant networks may consist of domains that are 279 relatively isolated and constrained in power (e.g. deep space 280 networks) and are connected only intermittently to the outside, 281 with a very long latency on such connections [RFC4838]. Clearly 282 the protocol requirements and possibilities are very specialised 283 in such networks. 285 9. "Traditional" enterprise and campus networks, which may be 286 spread over many kilometres and over multiple separate sites, 287 with multiple connections to the Internet. Interestingly, the 288 IETF appears never to have analysed this long-established class 289 of networks in a general way, except in connection with IPv6 290 deployment (e.g. [RFC7381]). 292 10. Unsuitable standards. A situation that can arise in an 293 enterprise network is that the Internet-wide solution for a 294 particular requirement may either fail locally, or be much more 295 complicated than is necessary. An example is that the 296 complexity induced by a mechanism such as ICE [RFC8445] is not 297 justified within such a network. Furthermore, ICE cannot be 298 used in some cases because candidate addresses are not known 299 before a call is established, so a different local solution is 300 essential [RFC6947]. 302 11. Managed wide area networks run by service providers for 303 enterprise services such as layer 2 (Ethernet, etc.) point-to- 304 point pseudowires, multipoint layer 2 Ethernet VPNs using VPLS 305 or EVPN, and layer 3 IP VPNs. These are generally characterized 306 by service level agreements for availability and packet loss, 307 and possibly for multicast service. These are different from 308 the previous case in that they mostly run over MPLS 309 infrastructures and the requirements for these services are 310 well-defined by the IETF. 312 12. Data centres and hosting centres, or distributed services acting 313 as such centres. These will have high performance, security and 314 privacy requirements and will typically include large numbers of 315 independent "tenant" networks overlaid on shared infrastructure. 317 13. Content Delivery Networks (CDNs), comprising distributed data 318 centres and the paths between them, spanning thousands of 319 kilometres, with numerous connections to the Internet. 321 14. Massive Web Service Provider Networks. This is a small class of 322 networks with well known trademarked names, combining aspects of 323 distributed enterprise networks, data centres and CDNs. They 324 have their own international networks bypassing the generic 325 carriers. Like CDNs, they have numerous connections to the 326 Internet, typically offering a tailored service in each economy. 328 Three other aspects, while not tied to specific network types, also 329 strongly depend on the concept of limited domains: 331 1. Many of the above types of network may be extended throughout the 332 Internet by a variety of virtual private network (VPN) 333 techniques. Therefore we argue that limited domains may overlap 334 each other in an arbitrary fashion by use of virtualization 335 techniques. As noted above in the discussion of controlled 336 environments, specific tunneling and encapsulation techniques may 337 be tailored for use within a given domain. 339 2. Intent Based Networking. In this concept, a network domain is 340 configured and managed in accordance with an abstract policy 341 known as "Intent", to ensure that the network performs as 342 required [I-D.clemm-nmrg-dist-intent]. Whatever technologies are 343 used to support this, they will be applied within the domain 344 boundary, even if the services supported in the domain are 345 globally accessible. 347 3. Network Slicing. A network slice is a form of virtual network 348 that consists of a managed set of resources carved off from a 349 larger network [I-D.ietf-teas-enhanced-vpn]. This is expected to 350 be significant in 5G deployments 351 [I-D.ietf-dmm-5g-uplane-analysis]. Whatever technologies are 352 used to support slicing, they will require a clear definition of 353 the boundary of a given slice within a larger domain. 355 While it is clearly desirable to use common solutions, and therefore 356 common standards, wherever possible, it is increasingly difficult to 357 do so while satisfying the widely varying requirements outlined 358 above. However, there is a tendency when new protocols and protocol 359 extensions are proposed to always ask the question "How will this 360 work across the open Internet?" This document suggests that this is 361 not always the best question. There are protocols and extensions 362 that are not intended to work across the open Internet. On the 363 contrary, their requirements and semantics are specifically limited 364 (in the sense defined above). 366 A common argument is that if a protocol is intended for limited use, 367 the chances are very high that it will in fact be used (or misused) 368 in other scenarios including the so-called open Internet. This is 369 undoubtedly true and means that limited use is not an excuse for bad 370 design or poor security. In fact, a limited use requirement 371 potentially adds complexity to both the protocol and its security 372 design, as discussed later. 374 Nevertheless, because of the diversity of limited domains with 375 specific requirements that is now emerging, specific standards (and 376 ad hoc standards) will probably emerge for different types of domain. 377 There will be attempts to capture each market sector, but the market 378 will demand standardized solutions within each sector. In addition, 379 operational choices will be made that can in fact only work within a 380 limited domain. The history of RSVP [RFC2205] illustrates that a 381 standard defined as if it could work over the open Internet might not 382 in fact do so. In general we can no longer assume that a protocol 383 designed according to classical Internet guidelines will in fact work 384 reliably across the network as a whole. However, the "open Internet" 385 must remain as the universal method of interconnection. Reconciling 386 these two aspects is a major challenge. 388 4. Examples of Limited Domain Solutions 390 This section lists various examples of specific limited domain 391 solutions that have been proposed or defined. It intentionally does 392 not include Layer 2 technology solutions, which by definition apply 393 to limited domains. It is worth noting, however, that with recent 394 developments such as TRILL [RFC6325] or Shortest Path Bridging [SPB], 395 Layer 2 domains may become very large. 397 1. Differentiated Services. This mechanism [RFC2474] allows a 398 network to assign locally significant values to the 6-bit 399 Differentiated Services Code Point field in any IP packet. 400 Although there are some recommended codepoint values for 401 specific per-hop queue management behaviours, these are 402 specifically intended to be domain-specific codepoints with 403 traffic being classified, conditioned and mapped or re-marked at 404 domain boundaries (unless there is an inter-domain agreement 405 that makes mapping or re-marking unnecessary). 407 2. Integrated Services. Although it is not intrinsic in the design 408 of RSVP [RFC2205], it is clear from many years' experience that 409 Integrated Services can only be deployed successfully within a 410 limited domain that is configured with adequate equipment and 411 resources. 413 3. Network function virtualisation. As described in 414 [I-D.irtf-nfvrg-gaps-network-virtualization], this general 415 concept is an open research topic, in which virtual network 416 functions are orchestrated as part of a distributed system. 417 Inevitably such orchestration applies to an administrative 418 domain of some kind, even though cross-domain orchestration is 419 also a research area. 421 4. Service Function Chaining (SFC). This technique [RFC7665] 422 assumes that services within a network are constructed as 423 sequences of individual service functions within a specific SFC- 424 enabled domain such as a 5G domain. As that RFC states: 425 "Specific features may need to be enforced at the boundaries of 426 an SFC-enabled domain, for example to avoid leaking SFC 427 information". A Network Service Header (NSH) [RFC8300] is used 428 to encapsulate packets flowing through the service function 429 chain: "The intended scope of the NSH is for use within a single 430 provider's operational domain." 432 5. Firewall and Service Tickets (FAST). Such tickets would 433 accompany a packet to claim the right to traverse a network or 434 request a specific network service [I-D.herbert-fast]. They 435 would only be meaningful within a particular domain. 437 6. Data Centre Network Virtualization Overlays. A common 438 requirement in data centres that host many tenants (clients) is 439 to provide each one with a secure private network, all running 440 over the same physical infrastructure. [RFC8151] describes 441 various use cases for this, and specifications are under 442 development. These include use cases in which the tenant 443 network is physically split over several data centres, but which 444 must appear to the user as a single secure domain. 446 7. Segment Routing. This is a technique which "steers a packet 447 through an ordered list of instructions, called segments" 448 [RFC8402]. The semantics of these instructions are explicitly 449 local to a segment routing domain or even to a single node. 450 Technically, these segments or instructions are represented as 451 an MPLS label or an IPv6 address, which clearly adds a semantic 452 interpretation to them within the domain. 454 8. Autonomic Networking. As explained in 455 [I-D.ietf-anima-reference-model], an autonomic network is also a 456 security domain within which an autonomic control plane 457 [I-D.ietf-anima-autonomic-control-plane] is used by autonomic 458 service agents. These agents manage technical objectives, which 459 may be locally defined, subject to domain-wide policy. Thus the 460 domain boundary is important for both security and protocol 461 purposes. 463 9. Homenet. As shown in [RFC7368], a home networking domain has 464 specific protocol needs that differ from those in an enterprise 465 network or the Internet as a whole. These include the Home 466 Network Control Protocol (HNCP) [RFC7788] and a naming and 467 discovery solution [I-D.ietf-homenet-simple-naming]. 469 10. Creative uses of IPv6 features. As IPv6 enters more general 470 use, engineers notice that it has much more flexibility than 471 IPv4. Innovative suggestions have been made for: 473 * The flow label, e.g. [RFC6294]. 475 * Extension headers, e.g. for segment routing 477 [I-D.ietf-6man-segment-routing-header] or OAM marking 478 [I-D.fz-6man-ipv6-alt-mark]. 480 * Meaningful address bits, e.g. [I-D.jiang-semantic-prefix]. 481 Also, segment routing uses IPv6 addresses as segment 482 identifiers with specific local meanings [RFC8402]. 484 * If segment routing is used for network programming 485 [I-D.ietf-spring-srv6-network-programming], IPv6 extension 486 headers can support rather complex local functionality. 488 The case of the extension header is particularly interesting, 489 since its existence has been a major "selling point" for IPv6, 490 but it is notorious that new extension headers are virtually 491 impossible to deploy across the whole Internet [RFC7045], 492 [RFC7872]. It is worth noting that extension header filtering 493 is considered as an important security issue 494 [I-D.ietf-opsec-ipv6-eh-filtering]. There is considerable 495 appetite among vendors or operators to have flexibility in 496 defining extension headers for use in limited or specialised 497 domains, e.g. [I-D.voyer-6man-extension-header-insertion], 498 [BIGIP], and [I-D.li-6man-service-aware-ipv6-network]. Locally 499 significant hop-by-hop options are also envisaged, that would be 500 understood by routers inside a domain but not elsewhere, e.g., 501 [I-D.ioametal-ippm-6man-ioam-ipv6-options]. 503 11. Deterministic Networking (DetNet). The Deterministic Networking 504 Architecture [RFC8655] and encapsulation 505 [I-D.ietf-detnet-data-plane-framework] aim to support flows with 506 extremely low data loss rates and bounded latency, but only 507 within a part of the network that is "DetNet aware". Thus, as 508 for differentiated services above, the concept of a domain is 509 fundamental. 511 12. Provisioning Domains (PvDs). An architecture for Multiple 512 Provisioning Domains has been defined [RFC7556] to allow hosts 513 attached to multiple networks to learn explicit details about 514 the services provided by each of those networks. 516 13. Address Scopes. For completeness, we mention that, particularly 517 in IPv6, some addresses have explicitly limited scope. In 518 particular, link-local addresses are limited to a single 519 physical link [RFC4291], and Unique Local Addresses [RFC4193] 520 are limited to a somewhat loosely defined local site scope. 521 Previously, site-local addresses were defined, but they were 522 obsoleted precisely because of "the fuzzy nature of the site 523 concept" [RFC3879]. Multicast addresses also have explicit 524 scoping [RFC4291]. 526 14. As an application layer example, consider streaming services 527 such as IPTV infrastructures that rely on standard protocols, 528 but for which access is not globally available. 530 All of these suggestions are only viable within a specified domain. 531 Neverthless, all of them are clearly intended for multivendor 532 implementation on thousands or millions of network domains, so 533 interoperable standardization would be beneficial. This argument 534 might seem irrelevant to private or proprietary implementations, but 535 these have a strong tendency to become de facto standards if they 536 succeed, so the arguments of this document still apply. 538 5. The Scope of Protocols in Limited Domains 540 One consequence of the deployment of limited domains in the Internet 541 is that some protocols will be designed, extended or configured so 542 that they only work correctly between end systems in such domains. 543 This is to some extent encouraged by some existing standards and by 544 the assignment of code points for local or experimental use. In any 545 case it cannot be prevented. Also, by endorsing efforts such as 546 Service Function Chaining, Segment Routing and Deterministic 547 Networking, the IETF is in effect encouraging such deployments. 548 Furthermore, it seems inevitable, if the "Internet of Things" becomes 549 reality, that millions of edge networks containing completely novel 550 types of node will be connected to the Internet; each one of these 551 edge networks will be a limited domain. 553 It is therefore appropriate to discuss whether protocols or protocol 554 extensions should sometimes be standardized to interoperate only 555 within a Limited Domain boundary. Such protocols would not be 556 required to interoperate across the Internet as a whole. Various 557 scenarios could then arise if there are multiple domains using the 558 limited-domain protocol in question: 560 * A. If a domain is split into two parts connected over the 561 Internet directly at the IP layer (i.e. with no tunnel 562 encapsulating the packets), a limited-domain protocol could be 563 operated between those two parts regardless of its special nature, 564 as long as it respects standard IP formats and is not arbitrarily 565 blocked by firewalls. A simple example is any protocol using a 566 port number assigned to a specific non-IETF protocol. 568 * Such a protocol could reasonably be described as an "inter-domain" 569 protocol because the Internet is transparent to it, even if it is 570 meaningless except in the two limited domains. This is of course 571 nothing new in the Internet architecture. 573 * B. If a limited-domain protocol does not respect standard IP 574 formats (for example, if it includes a non-standard IPv6 extension 575 header), it could not be operated between two domains connected 576 over the Internet directly at the IP layer. 578 * Such a protocol could reasonably be described as an "intra-domain" 579 protocol, and the Internet is opaque to it. 581 * C. If a limited-domain protocol is clearly specified to be 582 invalid outside its domain of origin, neither scenario A nor B 583 applies. The only solution would be a single virtual domain. For 584 example, an encapsulating tunnel between two domains could be used 585 to create the virtual domain. Also, nodes at the domain boundary 586 must drop all packets using the limited-domain protocol. 588 * D. If a limited-domain protocol has domain-specific variants, 589 such that implementations in different domains could not 590 interoperate if those domains were unified by some mechanism as in 591 scenario C, the protocol is not interoperable in the normal sense. 592 If two domains using it were merged, the protocol might fail 593 unpredictably. A simple example is any protocol using a port 594 number assigned for experimental use. Related issues are 595 discussed in [RFC5704], including the complex example of Transport 596 MPLS. 598 To provide a widespread example, consider Differentiated Services 599 [RFC2474]. A packet containing any value whatever in the 6 bits of 600 the Differentiated Service Code Point (DSCP) is well-formed and falls 601 into scenario A. However, because the semantics of DSCP values are 602 locally significant, the packet also falls into scenario D. In fact, 603 differentiated services are only interoperable across domain 604 boundaries if there is a corresponding agreement between the 605 operators; otherwise a specific gateway function is required for 606 meaningful interoperability. Much more detailed discussion is to be 607 found in [RFC2474] and [RFC8100]. 609 To provide a provocative example, consider the proposal in 610 [I-D.voyer-6man-extension-header-insertion] that the restrictions in 611 [RFC8200] should be relaxed to allow IPv6 extension headers to be 612 inserted on the fly in IPv6 packets. If this is done in such a way 613 that the affected packets can never leave the specific limited domain 614 in which they were modified, scenario C applies. If the semantic 615 content of the inserted headers is locally defined, scenario D also 616 applies. In neither case is the Internet outside the limited domain 617 disturbed. However, inside the domain nodes must understand the 618 variant protocol. Unless it is standardized as a formal version, 619 with all the complexity that implies [RFC6709], the nodes must all be 620 non-standard to the extent of understanding the variant protocol. 622 For the example of IPv6 header insertion, that means non-compliance 623 with [RFC8200] within the domain, even if the inserted headers are 624 themselves fully compliant. Apart from the issue of formal 625 compliance, such deviations from documented standard behaviour might 626 lead to significant debugging issues. The possible practical impact 627 of the header insertion example is explored in 628 [I-D.smith-6man-in-flight-eh-insertion-harmful]. 630 The FAST proposal mentioned in Section 4, Paragraph 2, Item 5 is also 631 an interesting case study. The semantics of FAST tickets 632 [I-D.herbert-fast] have limited scope. However, they are designed in 633 a way that in principle allows them to traverse the open Internet, as 634 standardized IPv6 hop-by-hop options or even as a proposed form of 635 IPv4 extension header [I-D.herbert-ipv4-eh]. Whether such options 636 can be used reliably across the open Internet remains unclear 637 [I-D.ietf-opsec-ipv6-eh-filtering]. 639 We conclude that it is reasonable to explicitly define limited-domain 640 protocols, either as standards or as proprietary mechanisms, as long 641 as they describe which of the above scenarios apply and they clarify 642 how the domain is defined. As long as all relevant standards are 643 respected outside the domain boundary, a well-specified limited- 644 domain protocol need not damage the rest of the Internet. However, 645 as described in the next section, mechanisms are needed to support 646 domain membership operations. 648 Note that this conclusion is not a recommendation to abandon the 649 normal goal that a standardized protocol should be global in scope 650 and able to interoperate across the open Internet. It is simply a 651 recognition that this will not always be the case. 653 6. Functional Requirements of Limited Domains 655 Noting that limited-domain protocols have been defined in the past, 656 and that others will undoubtedly be defined in the future, it is 657 useful to consider how a protocol can be made aware of the domain 658 within which it operates, and how the domain boundary nodes can be 659 identified. As the taxonomy in Appendix B shows, there are numerous 660 aspects to a domain. However, we can identify some generally 661 required features and functions that would apply partially or 662 completely to many cases. 664 Today, where limited domains exist, they are essentially created by 665 careful configuration of boundary routers and firewalls. If a domain 666 is characterized by one or more address prefixes, address assignment 667 to hosts must also be carefully managed. This is an error-prone 668 method and a combination of configuration errors and default routing 669 can lead to unwanted traffic escaping the domain. Our basic 670 assumption is therefore that it should be possible for domains to be 671 created and managed automatically, with minimal human configuration. 672 We now discuss requirements for automating domain creation and 673 management. 675 Firstly, if we drew a topology map, any given domain -- virtual or 676 physical -- will have a well defined boundary between "inside" and 677 "outside". However, that boundary in itself has no technical 678 meaning. What matters in reality is whether a node is a member of 679 the domain, and whether it is at the boundary between the domain and 680 the rest of the Internet. Thus the boundary in itself does not need 681 to be identified, but boundary nodes face both inwards and outwards. 682 Inside the domain, a sending node needs to know whether it is sending 683 to an inside or outside destination; and a receiving node needs to 684 know whether a packet originated inside or outside. Also, a boundary 685 node needs to know which of its interfaces are inward-facing or 686 outward-facing. It is irrelevant whether the interfaces involved are 687 physical or virtual. 689 To underline that domain boundaries need to be identifiable, consider 690 the statement from the Deterministic Networking Problem Statement 691 [RFC8557] that "there is still a lack of clarity regarding the limits 692 of a domain where a deterministic path can be set up". This remark 693 can certainly be generalised. 695 With this perspective, we can list some general functional 696 requirements. An underlying assumption here is that domain 697 membership operations should be cryptographically secured; a domain 698 without such security cannot be reliably protected from attack. 700 1. Domain Identity. A domain must have a unique and verifiable 701 identifier; effectively this should be a public key for the 702 domain. Without this, there is no way to secure domain 703 operations and domain membership. The holder of the 704 corresponding private key becomes the trust anchor for the 705 domain. 707 2. Nesting. It must be possible for domains to be nested (see, for 708 example, the network slicing example mentioned above). 710 3. Overlapping. It must be possible for nodes and links to be in 711 more than one domain (see, for example, the case of PVDs 712 mentioned above). 714 4. Node Eligibility. It must be possible for a node to determine 715 which domain(s) it can potentially join, and on which 716 interface(s). 718 5. Secure Enrolment. A node must be able to enrol in a given 719 domain via secure node identfication and to acquire relevant 720 security credentials (authorization) for operations within the 721 domain. If a node has multiple physical or virtual interfaces, 722 they may require to be individually enrolled. 724 6. Withdrawal. A node must be able to cancel enrolment in a given 725 domain. 727 7. Dynamic Membership. Optionally, a node should be able 728 temporarily leave or rejoin a domain (i.e. enrolment is 729 persistent but membership is intermittent). 731 8. Role, implying authorization to perform a certain set of 732 actions. A node must have a verifiable role. In the simplest 733 case, the choices of role are "interior node" and "boundary 734 node". In a boundary node, individual interfaces may have 735 different roles, e.g. "inward facing" and "outward facing". 737 9. Verify Peer. A node must be able to verify whether another node 738 is a member of the domain. 740 10. Verify Role. A node should be able to learn the verified role 741 of another node. In particular, it should be possible for a 742 node to find boundary nodes (interfacing to the Internet). 744 11. Domain Data. In a domain with management requirements, it must 745 be possible for a node to acquire domain policy and/or domain 746 configuration data. This would include, for example, filtering 747 policy to ensure that inappropriate packets do not leave the 748 domain. 750 These requirements could form the basis for further analysis and 751 solution design. 753 Another aspect is whether individual packets within a limited domain 754 need to carry any sort of indicator that they belong to that domain, 755 or whether this information will be implicit in the IP addresses of 756 the packet. A related question is whether individual packets need 757 cryptographic authentication. This topic is for further study. 759 7. Security Considerations 761 As noted above, a protocol intended for limited use may well be 762 inadvertently used on the open Internet, so limited use is not an 763 excuse for poor security. In fact, a limited use requirement 764 potentially adds complexity to the security design. 766 Often, the boundary of a limited domain will also act as a security 767 boundary. In particular, it will serve as a trust boundary, and as a 768 boundary of authority for defining capabilities. For example, 769 segment routing [RFC8402] explicitly uses the concept of a "trusted 770 domain" in this way. Within the boundary, limited-domain protocols 771 or protocol features will be useful, but they will in many cases be 772 meaningless or harmful if they enter or leave the domain. 774 The boundary also serves to provide confidentiality and privacy of 775 operational parameters that the operator does not wish to reveal. 776 Note that this is distinct from privacy protection for individual 777 users within the domain. 779 The security model for a limited-scope protocol must allow for the 780 boundary, and in particular for a trust model that changes at the 781 boundary. Typically, credentials will need to be signed by a domain- 782 specific authority. 784 8. IANA Considerations 786 This document makes no request of the IANA. 788 9. Contributor 790 Sheng Jiang 791 Huawei Technologies 792 Q14, Huawei Campus 793 No.156 Beiqing Road 794 Hai-Dian District, Beijing 100095 795 P.R. China 797 Email: jiangsheng@huawei.com 799 10. Acknowledgements 801 Useful comments were received from Amelia Andersdotter, Edward 802 Birrane, David Black, Ron Bonica, Mohamed Boucadair, Tim Chown, 803 Darren Dukes, Donald Eastlake, Adrian Farrel, Tom Herbert, Ben Kaduk, 804 Mirja Kuehlewind, Warren Kumari, John Klensin, Andy Malis, Michael 805 Richardson, Mark Smith, Rick Taylor, Niels ten Oever, and others. 807 11. Informative References 809 [BIGIP] Li, R., "HUAWEI - Big IP Initiative.", 2018, 810 . 812 [I-D.andrews-tcp-and-ipv6-use-minmtu] 813 Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", Work 814 in Progress, Internet-Draft, draft-andrews-tcp-and-ipv6- 815 use-minmtu-04, 18 October 2015, 816 . 819 [I-D.clemm-nmrg-dist-intent] 820 Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura, 821 "Intent-Based Networking - Concepts and Overview", Work in 822 Progress, Internet-Draft, draft-clemm-nmrg-dist-intent-03, 823 4 November 2019, . 826 [I-D.dcrocker-dns-perimeter] 827 Crocker, D. and T. Adams, "DNS Perimeter Overlay", Work in 828 Progress, Internet-Draft, draft-dcrocker-dns-perimeter-01, 829 11 June 2019, . 832 [I-D.fz-6man-ipv6-alt-mark] 833 Fioccola, G., Zhou, T., Cociglio, M., and F. Qin, "IPv6 834 Application of the Alternate Marking Method", Work in 835 Progress, Internet-Draft, draft-fz-6man-ipv6-alt-mark-05, 836 28 January 2020, . 839 [I-D.herbert-fast] 840 Herbert, T., "Firewall and Service Tickets", Work in 841 Progress, Internet-Draft, draft-herbert-fast-04, 10 April 842 2019, . 844 [I-D.herbert-ipv4-eh] 845 Herbert, T., "IPv4 Extension Headers and Flow Label", Work 846 in Progress, Internet-Draft, draft-herbert-ipv4-eh-01, 2 847 May 2019, 848 . 850 [I-D.ietf-6man-segment-routing-header] 851 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 852 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 853 (SRH)", Work in Progress, Internet-Draft, draft-ietf-6man- 854 segment-routing-header-26, 22 October 2019, 855 . 858 [I-D.ietf-anima-autonomic-control-plane] 859 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 860 Control Plane (ACP)", Work in Progress, Internet-Draft, 861 draft-ietf-anima-autonomic-control-plane-21, 3 November 862 2019, . 865 [I-D.ietf-anima-reference-model] 866 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 867 and J. Nobre, "A Reference Model for Autonomic 868 Networking", Work in Progress, Internet-Draft, draft-ietf- 869 anima-reference-model-10, 22 November 2018, 870 . 873 [I-D.ietf-detnet-data-plane-framework] 874 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 875 Bryant, S., and J. Korhonen, "DetNet Data Plane 876 Framework", Work in Progress, Internet-Draft, draft-ietf- 877 detnet-data-plane-framework-03, 28 October 2019, 878 . 881 [I-D.ietf-dmm-5g-uplane-analysis] 882 Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, 883 "User Plane Protocol and Architectural Analysis on 3GPP 5G 884 System", Work in Progress, Internet-Draft, draft-ietf-dmm- 885 5g-uplane-analysis-03, 3 November 2019, 886 . 889 [I-D.ietf-homenet-simple-naming] 890 Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming 891 and Service Discovery Architecture", Work in Progress, 892 Internet-Draft, draft-ietf-homenet-simple-naming-03, 23 893 October 2018, . 896 [I-D.ietf-intarea-frag-fragile] 897 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 898 and F. Gont, "IP Fragmentation Considered Fragile", Work 899 in Progress, Internet-Draft, draft-ietf-intarea-frag- 900 fragile-17, 30 September 2019, 901 . 904 [I-D.ietf-ipwave-vehicular-networking] 905 Jeong, J., "IPv6 Wireless Access in Vehicular Environments 906 (IPWAVE): Problem Statement and Use Cases", Work in 907 Progress, Internet-Draft, draft-ietf-ipwave-vehicular- 908 networking-13, 6 January 2020, 909 . 912 [I-D.ietf-opsec-ipv6-eh-filtering] 913 Gont, F. and W. LIU, "Recommendations on the Filtering of 914 IPv6 Packets Containing IPv6 Extension Headers", Work in 915 Progress, Internet-Draft, draft-ietf-opsec-ipv6-eh- 916 filtering-06, 2 July 2018, . 919 [I-D.ietf-spring-srv6-network-programming] 920 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 921 Matsushima, S., and Z. Li, "SRv6 Network Programming", 922 Work in Progress, Internet-Draft, draft-ietf-spring-srv6- 923 network-programming-08, 10 January 2020, 924 . 927 [I-D.ietf-teas-enhanced-vpn] 928 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 929 Framework for Enhanced Virtual Private Networks (VPN+) 930 Services", Work in Progress, Internet-Draft, draft-ietf- 931 teas-enhanced-vpn-04, 23 January 2020, 932 . 935 [I-D.ioametal-ippm-6man-ioam-ipv6-options] 936 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 937 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 938 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 939 "In-situ OAM IPv6 Options", Work in Progress, Internet- 940 Draft, draft-ioametal-ippm-6man-ioam-ipv6-options-02, 28 941 March 2019, . 944 [I-D.irtf-nfvrg-gaps-network-virtualization] 945 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 946 Aranda, P., and P. Lynch, "Network Virtualization Research 947 Challenges", Work in Progress, Internet-Draft, draft-irtf- 948 nfvrg-gaps-network-virtualization-10, 2 September 2018, 949 . 952 [I-D.jiang-semantic-prefix] 953 Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, 954 "Analysis of Semantic Embedded IPv6 Address Schemas", Work 955 in Progress, Internet-Draft, draft-jiang-semantic-prefix- 956 06, 15 July 2013, . 959 [I-D.li-6man-service-aware-ipv6-network] 960 Li, Z. and S. Peng, "Service-aware IPv6 Network", Work in 961 Progress, Internet-Draft, draft-li-6man-service-aware- 962 ipv6-network-00, 11 March 2019, 963 . 966 [I-D.smith-6man-in-flight-eh-insertion-harmful] 967 Smith, M., Kottapalli, N., Bonica, R., Gont, F., and T. 968 Herbert, "In-Flight IPv6 Extension Header Insertion 969 Considered Harmful", Work in Progress, Internet-Draft, 970 draft-smith-6man-in-flight-eh-insertion-harmful-01, 3 971 November 2019, . 974 [I-D.voyer-6man-extension-header-insertion] 975 Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy, 976 J., Li, Z., and J. Guichard, "Deployments With Insertion 977 of IPv6 Segment Routing Headers", Work in Progress, 978 Internet-Draft, draft-voyer-6man-extension-header- 979 insertion-08, 19 November 2019, 980 . 983 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 984 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 985 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 986 September 1997, . 988 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 989 "Definition of the Differentiated Services Field (DS 990 Field) in the IPv4 and IPv6 Headers", RFC 2474, 991 DOI 10.17487/RFC2474, December 1998, 992 . 994 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 995 DOI 10.17487/RFC2775, February 2000, 996 . 998 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 999 RFC 2923, DOI 10.17487/RFC2923, September 2000, 1000 . 1002 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1003 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1004 . 1006 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1007 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 1008 2004, . 1010 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1011 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1012 . 1014 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1015 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1016 2006, . 1018 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 1019 Interpretation of Generalized Multiprotocol Label 1020 Switching (GMPLS) Terminology within the Context of the 1021 ITU-T's Automatically Switched Optical Network (ASON) 1022 Architecture", RFC 4397, DOI 10.17487/RFC4397, February 1023 2006, . 1025 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery 1026 (Protection and Restoration) Terminology for Generalized 1027 Multi-Protocol Label Switching (GMPLS)", RFC 4427, 1028 DOI 10.17487/RFC4427, March 2006, 1029 . 1031 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1032 Computation Element (PCE)-Based Architecture", RFC 4655, 1033 DOI 10.17487/RFC4655, August 2006, 1034 . 1036 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1037 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1038 . 1040 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1041 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1042 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 1043 April 2007, . 1045 [RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet 1046 Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, 1047 . 1049 [RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated 1050 Protocol Development Considered Harmful", RFC 5704, 1051 DOI 10.17487/RFC5704, November 2009, 1052 . 1054 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 1055 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 1056 2011, . 1058 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1059 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1060 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 1061 . 1063 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1064 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1065 2011, . 1067 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1068 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1069 October 2011, . 1071 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 1072 Considerations for Protocol Extensions", RFC 6709, 1073 DOI 10.17487/RFC6709, September 2012, 1074 . 1076 [RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. 1077 Veikkolainen, "The Session Description Protocol (SDP) 1078 Alternate Connectivity (ALTC) Attribute", RFC 6947, 1079 DOI 10.17487/RFC6947, May 2013, 1080 . 1082 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 1083 "Architectural Considerations on Application Features in 1084 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 1085 . 1087 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1088 of IPv6 Extension Headers", RFC 7045, 1089 DOI 10.17487/RFC7045, December 2013, 1090 . 1092 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1093 Constrained-Node Networks", RFC 7228, 1094 DOI 10.17487/RFC7228, May 2014, 1095 . 1097 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 1098 Weil, "IPv6 Home Networking Architecture Principles", 1099 RFC 7368, DOI 10.17487/RFC7368, October 2014, 1100 . 1102 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 1103 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 1104 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 1105 . 1107 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 1108 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 1109 . 1111 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 1112 IAB Workshop on Stack Evolution in a Middlebox Internet 1113 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 1114 . 1116 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1117 Chaining (SFC) Architecture", RFC 7665, 1118 DOI 10.17487/RFC7665, October 2015, 1119 . 1121 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 1122 Nordmark, "Technical Considerations for Internet Service 1123 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 1124 March 2016, . 1126 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1127 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1128 2016, . 1130 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1131 "Observations on the Dropping of Packets with IPv6 1132 Extension Headers in the Real World", RFC 7872, 1133 DOI 10.17487/RFC7872, June 2016, 1134 . 1136 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1137 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1138 March 2017, . 1140 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1141 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 1142 March 2017, . 1144 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1145 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1146 March 2017, . 1148 [RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, 1149 "Use Cases for Data Center Network Virtualization Overlay 1150 Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017, 1151 . 1153 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1154 (IPv6) Specification", STD 86, RFC 8200, 1155 DOI 10.17487/RFC8200, July 2017, 1156 . 1158 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1159 "Network Service Header (NSH)", RFC 8300, 1160 DOI 10.17487/RFC8300, January 2018, 1161 . 1163 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1164 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1165 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1166 July 2018, . 1168 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1169 Connectivity Establishment (ICE): A Protocol for Network 1170 Address Translator (NAT) Traversal", RFC 8445, 1171 DOI 10.17487/RFC8445, July 2018, 1172 . 1174 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1175 Jacquenet, "An Inventory of Transport-Centric Functions 1176 Provided by Middleboxes: An Operator Perspective", 1177 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1178 . 1180 [RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem 1181 Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, 1182 . 1184 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 1185 RFC 8578, DOI 10.17487/RFC8578, May 2019, 1186 . 1188 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1189 "Deterministic Networking Architecture", RFC 8655, 1190 DOI 10.17487/RFC8655, October 2019, 1191 . 1193 [SPB] "IEEE Standard for Local and metropolitan area networks - 1194 Bridges and Bridged Networks", IEEE Standard 802.1Q-2018, 1195 2018, . 1198 Appendix A. Change log [RFC Editor: Please remove] 1200 draft-carpenter-limited-domains-00, 2018-06-11: 1202 * Initial version 1204 draft-carpenter-limited-domains-01, 2018-07-01: 1206 * Minor terminology clarifications 1208 draft-carpenter-limited-domains-02, 2018-08-03: 1210 * Additions following IETF102 discussions 1211 * Updated authorship/contributors 1213 draft-carpenter-limited-domains-03, 2018-09-12: 1215 * First draft of taxonomy 1216 * Editorial improvements 1218 draft-carpenter-limited-domains-04, 2018-10-14: 1220 * Reorganized section 3 1221 * Newly written sections 6 and 7 1222 * Editorial improvements 1224 draft-carpenter-limited-domains-05, 2018-12-12: 1226 * Added discussion of transparency/filtering debates 1227 * Added discussion of "controlled environment" 1228 * Modified assertion about localized standards 1229 * Editorial improvements 1231 draft-carpenter-limited-domains-06, 2019-03-02: 1233 * Minor updates, fixed reference nits 1235 draft-carpenter-limited-domains-07, 2019-04-15: 1237 * Moved taxonomy to an appendix. 1238 * Added examples and references. 1239 * Editorial improvements 1241 draft-carpenter-limited-domains-08, 2019-06-12: 1243 * Added short discussion of address scopes. 1244 * Added possibility of nested or overlapped domains. 1245 * Integrated other comments received. 1246 * Editorial improvements 1248 draft-carpenter-limited-domains-09, 2019-06-21: 1250 * Additional 5G citations. 1252 draft-carpenter-limited-domains-10, 2019-08-02: 1254 * ISE comments. 1256 draft-carpenter-limited-domains-11, 2019-10-31: 1258 * Incorporate review comments. 1259 * Editorial improvements. 1261 draft-carpenter-limited-domains-12, 2019-11-30: 1263 * Incorporate ISE comments. 1265 draft-carpenter-limited-domains-13, 2020-02-03: 1267 * Incorporate IESG comments. 1268 * Convert to v3 format. 1270 Appendix B. Taxonomy of Limited Domains 1272 This appendix develops a taxonomy for describing limited domains. 1273 Several major aspects are considered in this taxonomy: 1275 * The domain as a whole. 1277 * The individual nodes. 1279 * The domain boundary. 1281 * The domain's topology. 1283 * The domain's technology. 1285 * How the domain connects to the Internet. 1287 * The security, trust, and privacy model. 1289 * Operations. 1291 The following sub-sections analyse each of these aspects. 1293 B.1. The Domain as a Whole 1295 * Why does the domain exist? (e.g., human choice, administrative 1296 policy, orchestration requirements, technical requirements such as 1297 operational partitioning for scaling reasons) 1299 * If there are special requirements, are they at Layer 2, Layer 3 or 1300 an upper layer? 1302 * Where does the domain lie on the spectrum between completely 1303 managed by humans and completely autonomic? 1305 * If managed, what style of management applies? (Manual 1306 configuration, automated configuration, orchestration?) 1308 * Is there a policy model? (Intent, configuration policies?) 1310 * Does the domain provide controlled or paid service or open access? 1312 B.2. Individual Nodes 1314 * Is a domain member a complete node, or only one interface of a 1315 node? 1317 * Are nodes permanent members of a given domain, or are join and 1318 leave operations possible? 1320 * Are nodes physical or virtual devices? 1322 * Are virtual nodes general-purpose, or limited to specific 1323 functions, applications or users? 1325 * Are nodes constrained (by battery etc)? 1327 * Are devices installed "out of the box" or pre-configured? 1329 B.3. The Domain Boundary 1331 * How is the domain boundary identified or defined? 1333 * Is the domain boundary fixed or dynamic? 1335 * Are boundary nodes special? Or can any node be at the boundary? 1337 B.4. Topology 1338 * Is the domain a subset of a layer 2 or 3 connectivity domain? 1340 * Does the domain overlap other domains? (In other words, a node 1341 may or may not be allowed to be a member of multiple domains.) 1343 * Does the domain match physical topology, or does it have a virtual 1344 (overlay) topology? 1346 * Is the domain in a single building, vehicle or campus? Or is it 1347 distributed? 1349 * If distributed, are the interconnections private or over the 1350 Internet? 1352 * In IP addressing terms, is the domain Link-local, Site-local, or 1353 Global? 1355 * Does the scope of IP unicast or multicast addresses map to the 1356 domain boundary? 1358 B.5. Technology 1360 * What routing protocol(s) are used, or even different forwarding 1361 mechanisms (MPLS or other non-IP mechanism)? 1363 * In an overlay domain, what overlay technique is used (L2VPN, 1364 L3VPN,...)? 1366 * Are there specific QoS requirements? 1368 * Link latency - normal or long latency links? 1370 * Mobility - are nodes mobile? Is the whole network mobile? 1372 * Which specific technologies, such as those in Section 4, are 1373 applicable? 1375 B.6. Connection to the Internet 1377 * Is the Internet connection permanent or intermittent? (Never 1378 connected is out of scope.) 1380 * What traffic is blocked, in and out? 1382 * What traffic is allowed, in and out? 1384 * What traffic is transformed, in and out? 1385 * Is secure and privileged remote access needed? 1387 * Does the domain allow unprivileged remote sessions? 1389 B.7. Security, Trust and Privacy Model 1391 * Must domain members be authorized? 1393 * Are all nodes in the domain at the same trust level? 1395 * Is traffic authenticated? 1397 * Is traffic encrypted? 1399 * What is hidden from the outside? 1401 B.8. Operations 1403 * Safety level - does the domain have a critical (human) safety 1404 role? 1406 * Reliability requirement - normal or 99.999% ? 1408 * Environment - hazardous conditions? 1410 * Installation - are specialists needed? 1412 * Service visits - easy, difficult, impossible? 1414 * Software/firmware updates - possible or impossible? 1416 B.9. Making use of this taxonomy 1418 This taxonomy could be used to design or analyse a specific type of 1419 limited domain. For the present document, it is intended only to 1420 form a background to the scope of protocols used in limited domains, 1421 and the mechanisms required to securely define domain membership and 1422 properties. 1424 Authors' Addresses 1426 Brian Carpenter 1427 The University of Auckland 1428 School of Computer Science 1429 University of Auckland 1430 PB 92019 1431 Auckland 1142 1432 New Zealand 1434 Email: brian.e.carpenter@gmail.com 1436 Bing Liu 1437 Huawei Technologies 1438 Q14, Huawei Campus 1439 No.156 Beiqing Road 1440 Hai-Dian District, Beijing 1441 100095 1442 P.R. China 1444 Email: leo.liubing@huawei.com