idnits 2.17.1 draft-carpenter-limited-domains-07.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 (April 15, 2019) is 1809 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-dcrocker-dns-perimeter-00 == Outdated reference: A later version (-07) exists of draft-herbert-fast-04 == Outdated reference: A later version (-03) exists of draft-herbert-ipv4-eh-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-19 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-12 == Outdated reference: A later version (-17) exists of draft-ietf-intarea-frag-fragile-09 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-08 == 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 (~~), 11 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: October 17, 2019 Huawei Technologies 6 April 15, 2019 8 Limited Domains and Internet Protocols 9 draft-carpenter-limited-domains-07 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 October 17, 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 . . . . . . . . . . 10 64 6. Functional Requirements of Limited Domains . . . . . . . . . 12 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 69 11. Informative References . . . . . . . . . . . . . . . . . . . 15 70 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 21 71 Appendix B. Taxonomy of Limited Domains . . . . . . . . . . . . 22 72 B.1. The Domain as a Whole . . . . . . . . . . . . . . . . . . 22 73 B.2. Individual Nodes . . . . . . . . . . . . . . . . . . . . 23 74 B.3. The Domain Boundary . . . . . . . . . . . . . . . . . . . 23 75 B.4. Topology . . . . . . . . . . . . . . . . . . . . . . . . 23 76 B.5. Technology . . . . . . . . . . . . . . . . . . . . . . . 24 77 B.6. Connection to the Internet . . . . . . . . . . . . . . . 24 78 B.7. Security, Trust and Privacy Model . . . . . . . . . . . . 24 79 B.8. Operations . . . . . . . . . . . . . . . . . . . . . . . 25 80 B.9. Making use of this taxonomy . . . . . . . . . . . . . . . 25 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 local requirements, 88 behaviours and semantics. The word "local" should be understood in a 89 special sense, however. In some cases it may refer to geographical 90 and physical locality - all the nodes in a single building, on a 91 single campus, or in a given vehicle. In other cases it may refer to 92 a defined set of users or nodes distributed over a much wider area, 93 but drawn together by a single virtual network over the Internet, or 94 a single physical network running partially in parallel with the 95 Internet. We expand on these possibilities below. To capture the 96 topic, this document refers to such networks as "limited domains". 98 Some people have concerns about splintering of the Internet along 99 political or linguistic boundaries by mechanisms that block the free 100 flow of information across the network. That is not the topic of 101 this document, which does not discuss filtering mechanisms and does 102 not apply to protocols that are designed for use across the whole 103 Internet. It is only concerned with domains that have specific 104 technical requirements. 106 The word "domain" in this document does not refer to naming domains 107 in the DNS, although in some cases a limited domain might 108 incidentally be congruent with a DNS domain. In particular, with a 109 "split horizon" DNS configuration [RFC6950], the split might be at 110 the edge of a limited domain. A recent proposal for defining 111 definite perimeters within the DNS namespace 112 [I-D.dcrocker-dns-perimeter] might also be considered to be a limited 113 domain mechanism. 115 Another term that has been used in some contexts is "controlled 116 environment". For example, [RFC8085] uses this to delimit the 117 operational scope within which a particular tunnel encapsulation 118 might be used. A specific example is GRE-in-UDP encapsulation 119 [RFC8086] which explicitly states that "The controlled environment 120 has less restrictive requirements than the general Internet." For 121 example, non-congestion-controlled traffic might be acceptable within 122 the controlled environment. The same phrase has been used to delimit 123 the useful scope of quality of service or security protocols, e.g. 124 [RFC6398], [RFC6455]. It is not necessarily the case that protocols 125 will fail to operate outside the controlled environment, but rather 126 that they might not operate usefully. In this document, we assume 127 that "limited domain" and "controlled environment" mean the same 128 thing in practice. 130 The requirements of limited domains will be different in different 131 scenarios. Policies, default parameters, and the options supported 132 may vary. Also, the style of network management may vary, between a 133 completely unmanaged network, one with fully autonomic management, 134 one with traditional central management, and mixtures of the above. 135 Finally, the requirements and solutions for security and privacy may 136 vary. 138 This documents analyses and discusses some of the consequences of 139 this trend, and how it impacts the idea of universal interoperability 140 in the Internet. Firstly we list examples of limited domain 141 scenarios and of technical solutions for limited domains, with the 142 main focus being the Internet layer of the protocol stack. An 143 appendix provides a taxonomy of the features to be found in limited 144 domains. With this background, we discuss the resulting challenge to 145 the idea that all Internet standards must be universal in scope and 146 applicability. To the contrary, we assert that some protocols need 147 to be specifically limited in their applicability. This implies that 148 the concepts of a limited domain, and of its membership, need to be 149 formalised and supported by secure mechanisms. While this document 150 does not propose a design for such mechanisms, it does outline some 151 functional requirements. 153 2. Failure Modes in Today's Internet 155 Today, the Internet does not have a well-defined concept of limited 156 domains. One result of this is that certain protocols and features 157 fail on certain paths. Earlier analyses of this topic have focused 158 either on the loss of transparency of the Internet [RFC2775], 159 [RFC4924] or on the middleboxes responsible for that loss [RFC3234], 160 [RFC7663], [RFC8517]. Unfortunately the problems persist, both in 161 application protocols, and even in very fundamental mechanisms. For 162 example, the Internet is not transparent to IPv6 extension headers 163 [RFC7872], and Path MTU Discovery has been unreliable for many years 164 [RFC2923], [RFC4821]. IP fragmentation is also unreliable 165 [I-D.ietf-intarea-frag-fragile], and problems in TCP MSS negotiation 166 have been reported [I-D.andrews-tcp-and-ipv6-use-minmtu]. 168 On the security side, the widespread insertion of firewalls at domain 169 boundaries that are perceived by humans but unknown to protocols 170 results in arbitrary failure modes as far as the application layer is 171 concerned. There are operational recommendations and practices that 172 effectively guarantee arbitrary failures in realistic scenarios 173 [I-D.ietf-opsec-ipv6-eh-filtering]. 175 The recent discussions about the unreliability of IP fragmentation 176 and the filtering of IPv6 extension headers have strongly suggested 177 that at least for some protocol elements, transparency is a lost 178 cause and middleboxes are here to stay. In the following two 179 sections, we show that some application environments require protocol 180 features that cannot, or should not, cross the whole Internet. 182 3. Examples of Limited Domain Requirements 184 This section describes various examples where limited domain 185 requirements can easily be identified, either based on an application 186 scenario or on a technical imperative. It is of course not a 187 complete list, and it is presented in an arbitrary order, loosely 188 from smaller to bigger. 190 1. A home network. It will be unmanaged, constructed by a non- 191 specialist, and will possibly include wiring errors such as 192 physical loops. It must work with devices "out of the box" as 193 shipped by their manufacturers and must create adequate security 194 by default. Remote access may be required. The requirements 195 and applicable principles are summarised in [RFC7368]. 197 2. A small office network. This is sometimes very similar to a 198 home network, if whoever is in charge has little or no 199 specialist knowledge, but may have differing security and 200 privacy requirements. In other cases it may be professionally 201 constructed using recommended products and configurations, but 202 operate unmanaged. Remote access may be required. 204 3. A vehicle network. This will be designed by the vehicle 205 manufacturer but may include devices added by the vehicle's 206 owner or operator. Parts of the network will have demanding 207 performance and reliability requirements with implications for 208 human safety. Remote access may be required to certain 209 functions, but absolutely forbidden for others. Communication 210 with other vehicles, roadside infrastructure, and external data 211 sources will be required. See 212 [I-D.ietf-ipwave-vehicular-networking] for a survey of use 213 cases. 215 4. Supervisory Control And Data Acquisition (SCADA) networks, and 216 other hard real time networks. These will exhibit specific 217 technical requirements, including tough real-time performance 218 targets. See for example [I-D.ietf-detnet-use-cases] for 219 numerous use cases. An example is a building services network. 220 This will be designed specifically for a particular building, 221 but using standard components. Additional devices may need to 222 be added at any time. Parts of the network may have demanding 223 reliability requirements with implications for human safety. 224 Remote access may be required to certain functions, but 225 absolutely forbidden for others. 227 5. Sensor networks. The two preceding cases will all include 228 sensors, but some networks may be specifically limited to 229 sensors and the collection and processing of sensor data. They 230 may be in remote or technically challenging locations and 231 installed by non-specialists. 233 6. Internet of Things (IoT) networks. While this term is very 234 flexible and covers many innovative types of network, including 235 ad hoc networks that are formed spontaneously, it seems 236 reasonable to expect that IoT edge networks will have special 237 requirements and protocols that are useful only within a 238 specific domain, and that these protocols cannot, and for 239 security reasons should not, run over the Internet as a whole. 241 7. An important subclass of IoT networks consists of constrained 242 networks [RFC7228] in which the nodes are limited in power 243 consumption and communications bandwidth, and are therefore 244 limited to using very frugal protocols. 246 8. Delay tolerant networks may consist of domains that are 247 relatively isolated and constrained in power (e.g. deep space 248 networks) and are connected only intermittently to the outside, 249 with a very long latency on such connections [RFC4838]. Clearly 250 the protocol requirements and possibilities are very specialised 251 in such networks. 253 9. "Traditional" enterprise and campus networks, which may be 254 spread over many kilometres and over multiple separate sites, 255 with multiple connections to the Internet. Interestingly, the 256 IETF appears never to have analysed this long-established class 257 of networks in a general way, except in connection with IPv6 258 deployment (e.g. [RFC7381]). 260 10. Managed wide area networks run by service providers for 261 enterprise services such as layer 2 (Ethernet, etc.) point-to- 262 point pseudowires, multipoint layer 2 Ethernet VPNs using VPLS 263 or EVPN, and layer 3 IP VPNs. These are generally characterized 264 by service level agreements for availability and packet loss. 265 These are different from the previous case in that they mostly 266 run over MPLS infrastructures and the requirements for these 267 services are well-defined by the IETF. 269 11. Data centres and hosting centres, or distributed services acting 270 as such centres. These will have high performance, security and 271 privacy requirements and will typically include large numbers of 272 independent "tenant" networks overlaid on shared infrastructure. 274 12. Content Delivery Networks (CDNs), comprising distributed data 275 centres and the paths between them, spanning thousands of 276 kilometres, with numerous connections to the Internet. 278 13. Massive Web Service Provider Networks. This is a small class of 279 networks with well known trademarked names, combining aspects of 280 distributed enterprise networks, data centres and CDNs. They 281 have their own international networks bypassing the generic 282 carriers. Like CDNs, they have numerous connections to the 283 Internet, typically offering a tailored service in each economy. 285 Three other aspects, while not tied to specific network types, also 286 strongly depend on the concept of limited domains: 288 1. Intent Based Networking. In this concept, a network domain is 289 configured and managed in accordance with an abstract policy 290 known as "Intent", to ensure that the network performs as 291 required [I-D.moulchan-nmrg-network-intent-concepts]. Whatever 292 technologies are used to support this, they will be applied 293 within the domain boundary. 295 2. Many of the above types of network may be extended throughout the 296 Internet by a variety of virtual private network (VPN) 297 techniques. Therefore we argue that limited domains may overlap 298 each other in an arbitrary fashion by use of virtualization 299 techniques. As noted above in the discussion of controlled 300 environments, specific tunneling and encapsulation techniques may 301 only be usable within a given domain. 303 3. Network Slicing. A network slice is a virtual network that 304 consists of a managed set of resources carved off from a larger 305 network [I-D.geng-netslices-architecture]. Whatever technologies 306 are used to support slicing, they will require a clear definition 307 of the boundary of a given slice. 309 While it is clearly desirable to use common solutions, and therefore 310 common standards, wherever possible, it is increasingly difficult to 311 do so while satisfying the widely varying requirements outlined 312 above. However, there is a tendency when new protocols and protocol 313 extensions are proposed to always ask the question "How will this 314 work across the open Internet?" This document suggests that this is 315 not always the right question. There are protocols and extensions 316 that are not intended to work across the open Internet. On the 317 contrary, their requirements and semantics are specifically limited 318 (in the sense defined above). 320 A common argument is that if a protocol is intended for limited use, 321 the chances are very high that it will in fact be used (or misused) 322 in other scenarios including the so-called open Internet. This is 323 undoubtedly true and means that limited use is not an excuse for bad 324 design or poor security. In fact, a limited use requirement 325 potentially adds complexity to both the protocol and its security 326 design, as discussed later. 328 Nevertheless, because of the diversity of limited domains with 329 specific requirements that is now emerging, specific standards (and 330 ad hoc standards) will probably emerge for different types of domain. 331 There will be attempts to capture each market sector, but the market 332 will demand standardised solutions within each sector. In addition, 333 operational choices will be made that can in fact only work within a 334 limited domain. The history of RSVP illustrates that a standard 335 defined as if it could work over the open Internet might not in fact 336 do so. In general we can no longer assume that a protocol designed 337 according to classical Internet guidelines will in fact work reliably 338 across the network as a whole. However, the "open Internet" must 339 remain as the universal method of interconnection. Reconciling these 340 two aspects is a major challenge. 342 4. Examples of Limited Domain Solutions 344 This section lists various examples of specific limited domain 345 solutions that have been proposed or defined. It intentionally does 346 not include Layer 2 technology solutions, which by definition apply 347 to limited domains. 349 1. Differentiated Services. This mechanism [RFC2474] allows a 350 network to assign locally significant values to the 6-bit 351 Differentiated Services Code Point field in any IP packet. 352 Although there are some recommended codepoint values for 353 specific per-hop queue management behaviours, these are 354 specifically intended to be domain-specific codepoints with 355 traffic being classified, conditioned and re-marked at domain 356 boundaries (unless there is an inter-domain agreement that makes 357 re-marking unnecessary). 359 2. Integrated Services. Although it is not intrinsic in the design 360 of RSVP [RFC2205], it is clear from many years' experience that 361 Integrated Services can only be deployed successfully within a 362 limited domain that is configured with adequate equipment and 363 resources. 365 3. Network function virtualisation. As described in 366 [I-D.irtf-nfvrg-gaps-network-virtualization], this general 367 concept is an open research topic, in which virtual network 368 functions are orchestrated as part of a distributed system. 369 Inevitably such orchestration applies to an administrative 370 domain of some kind, even though cross-domain orchestration is 371 also a research area. 373 4. Service Function Chaining (SFC). This technique [RFC7665] 374 assumes that services within a network are constructed as 375 sequences of individual functions within a specific SFC-enabled 376 domain. As that RFC states: "Specific features may need to be 377 enforced at the boundaries of an SFC-enabled domain, for example 378 to avoid leaking SFC information". A Network Service Header 379 (NSH) [RFC8300] is used to encapsulate packets flowing through 380 the service function chain: "The intended scope of the NSH is 381 for use within a single provider's operational domain." 383 5. Firewall and Service Tickets (FAST). Such tickets would 384 accompany a packet to claim the right to traverse a network or 385 request a specific network service [I-D.herbert-fast]. They 386 would only be meaningful within a particular domain. 388 6. Data Centre Network Virtualization Overlays. A common 389 requirement in data centres that host many tenants (clients) is 390 to provide each one with a secure private network, all running 391 over the same physical infrastructure. [RFC8151] describes 392 various use cases for this, and specifications are under 393 development. These include use cases in which the tenant 394 network is physically split over several data centres, but which 395 must appear to the user as a single secure domain. 397 7. Segment Routing. This is a technique which "steers a packet 398 through an ordered list of instructions, called segments" 399 [RFC8402]. The semantics of these instructions are explicitly 400 local to a segment routing domain or even to a single node. 401 Technically, these segments or instructions are represented as 402 an MPLS label or an IPv6 address, which clearly adds a semantic 403 interpretation to them within the domain. 405 8. Autonomic Networking. As explained in 406 [I-D.ietf-anima-reference-model], an autonomic network is also a 407 security domain within which an autonomic control plane 408 [I-D.ietf-anima-autonomic-control-plane] is used by autonomic 409 service agents. These agents manage technical objectives, which 410 may be locally defined, subject to domain-wide policy. Thus the 411 domain boundary is important for both security and protocol 412 purposes. 414 9. Homenet. As shown in [RFC7368], a home networking domain has 415 specific protocol needs that differ from those in an enterprise 416 network or the Internet as a whole. These include the Home 417 Network Control Protocol (HNCP) [RFC7788] and a naming and 418 discovery solution [I-D.ietf-homenet-simple-naming]. 420 10. Creative uses of IPv6 features. As IPv6 enters more general 421 use, engineers notice that it has much more flexibility than 422 IPv4. Innovative suggestions have been made for: 424 * The flow label, e.g. [RFC6294], 425 [I-D.fioccola-v6ops-ipv6-alt-mark]. 427 * Extension headers, e.g. for segment routing 428 [I-D.ietf-6man-segment-routing-header]. 430 * Meaningful address bits, e.g. [I-D.jiang-semantic-prefix]. 431 Also, segment routing uses IPv6 addresses as segment 432 identifiers with specific local meanings [RFC8402]. 434 * If segment routing is used for network programming 435 [I-D.filsfils-spring-srv6-network-programming], IPv6 436 extension headers will support rather complex local 437 functionality. 439 All of these suggestions are only viable within a specified 440 domain. The case of the extension header is particularly 441 interesting, since its existence has been a major "selling 442 point" for IPv6, but it is notorious that new extension headers 443 are virtually impossible to deploy across the whole Internet 444 [RFC7045], [RFC7872]. It is worth noting that extension header 445 filtering is considered as an important security issue 446 [I-D.ietf-opsec-ipv6-eh-filtering]. There is considerable 447 appetite among vendors or operators to have flexibility in 448 defining extension headers for use in limited or specialised 449 domains, e.g. [I-D.voyer-6man-extension-header-insertion], 450 [BIGIP], and [I-D.li-6man-service-aware-ipv6-network]. Locally 451 significant hop-by-hop options are also envisaged, that would be 452 understood by routers inside a domain but not elsewhere, e.g., 453 [I-D.ioametal-ippm-6man-ioam-ipv6-options]. 455 11. Deterministic Networking (DetNet). The Deterministic Networking 456 Architecture [I-D.ietf-detnet-architecture] and encapsulation 457 [I-D.ietf-detnet-dp-sol] aim to support flows with extremely low 458 data loss rates and bounded latency, but only within a part of 459 the network that is "DetNet aware". Thus, as for differentiated 460 services above, the concept of a domain is fundamental. 462 12. Provisioning Domains (PvDs). An architecture for Multiple 463 Provisioning Domains has been defined [RFC7556] to allow hosts 464 attached to multiple networks to learn explicit details about 465 the services provided by each of those networks. 467 5. The Scope of Protocols in Limited Domains 469 One consequence of the deployment of limited domains in the Internet 470 is that some protocols will be designed, extended or configured so 471 that they only work correctly between end systems in such domains. 472 This is to some extent encouraged by some existing standards and by 473 the assignment of code points for local or experimental use. In any 474 case it cannot be prevented. Also, by endorsing efforts such as 475 Service Function Chaining, Segment Routing and Deterministic 476 Networking, the IETF is in effect encouraging such deployments. 477 Furthermore, it seems inevitable, if the "Internet of Things" becomes 478 reality, that millions of edge networks containing completely novel 479 types of node will be connected to the Internet; each one of these 480 edge networks will be a limited domain. 482 It is therefore appropriate to discuss whether protocols or protocol 483 extensions should sometimes be standardised to interoperate only 484 within a Limited Domain Boundary. Such protocols would not be 485 required to interoperate across the Internet as a whole. Several 486 possibly overlapping scenarios could then arise: 488 A. If a limited domain is split into two parts connected over the 489 Internet directly at the IP layer (i.e. with no tunnel 490 encapsulating the packets), a limited-domain protocol could be 491 operated between those two parts regardless of its special nature, 492 as long as it respects standard IP formats and is not arbitrarily 493 blocked by firewalls. A simple example is any protocol using a 494 port number assigned to a specific non-IETF protocol. 496 Such a protocol could reasonably be described as an "inter-domain" 497 protocol because the Internet is transparent to it, even if it is 498 meaningless except in the two parts of the limited domain. This 499 is of course nothing new in the Internet architecture. 501 B. If a limited-domain protocol does not respect standard IP 502 formats (for example, if it includes a non-standard IPv6 extension 503 header), it could not be operated between two parts of a domain 504 split at the IP layer. 506 Such a protocol could reasonably be described as an "intra-domain" 507 protocol, and the Internet is opaque to it. 509 C. If a limited-domain protocol is clearly specified to be 510 invalid outside its domain of origin, neither scenario A nor B 511 applies. The two domains need to be unified as a single virtual 512 domain. For example, an encapsulating tunnel between the parts of 513 the split domain could be used. Also, nodes at the domain 514 boundary must drop all packets using the limited-domain protocol. 516 D. If a limited-domain protocol has domain-specific variants, 517 such that implementations in different domains could not 518 interoperate if those domains were unified by some mechanism, the 519 protocol is not interoperable in the normal sense. If two domains 520 using it were merged, the protocol might fail unpredictably. A 521 simple example is any protocol using a port number assigned for 522 experimental use. Such a protocol usually also falls into 523 scenario C. 525 To provide an existing example, consider Differentiated Services 526 [RFC2474]. A packet containing any value whatever in the 6 bits of 527 the Differentiated Service Code Point (DSCP) is well-formed and falls 528 into scenario A. However, because the semantics of DSCP values are 529 locally significant, the packet also falls into scenario D. In fact, 530 differentiated services are only interoperable across domain 531 boundaries if there is a corresponding agreement between the 532 operators; otherwise a specific gateway function is required for 533 meaningful interoperability. Much more detailed discussion is to be 534 found in [RFC2474] and [RFC8100]. 536 To provide a provocative example, consider the proposal in 537 [I-D.voyer-6man-extension-header-insertion] that the restrictions in 538 [RFC8200] should be relaxed to allow IPv6 extension headers to be 539 inserted on the fly in IPv6 packets. If this is done in such a way 540 that the affected packets can never leave the specific limited domain 541 in which they were modified, scenario C applies. If the semantic 542 content of the inserted headers is locally defined, scenario D also 543 applies. In neither case is the Internet disturbed. 545 The FAST proposal mentioned above is also an interesting case study. 546 The semantics of FAST tickets [I-D.herbert-fast] have limited scope. 547 However, they are designed in a way that in principle allows them to 548 traverse the open Internet, as standardized IPv6 hop-by-hop options 549 or even as a proposed form of IPv4 extension header 550 [I-D.herbert-ipv4-eh]. Whether such options can be used reliably 551 across the open Internet remains unclear 552 [I-D.ietf-opsec-ipv6-eh-filtering]. 554 We conclude that it is reasonable to explicitly define limited-domain 555 protocols, either as standards or as proprietary mechanisms, as long 556 as they describe which of the above scenarios apply and they clarify 557 how the domain is defined. As long as all relevant standards are 558 respected outside the domain boundary, a well-specified limited- 559 domain protocol is not harmful to the Internet. However, as 560 described in the next section, mechanisms are needed to support 561 domain membership operations. 563 Note that this conclusion is not a recommendation to abandon the 564 normal goal that a standardized protocol should be global in scope 565 and able to interoperate across the open Internet. It is simply a 566 recognition that this will not always be the case. 568 6. Functional Requirements of Limited Domains 570 Noting that limited-domain protocols have been defined in the past, 571 and that others will undoubtedly be defined in the future, it is 572 useful to consider how a protocol can be made aware of the domain 573 within which it operates, and how the domain boundary nodes can be 574 identified. As the taxonomy in Appendix B shows, there are numerous 575 aspects to a domain. However, we can identify some generally 576 required features and functions. 578 A basic assumption is that domains should be created and managed as 579 automatically as possible, with minimal human configuration required. 580 We therefore discuss requirements for automating domain creation and 581 management. 583 Firstly, if we drew a topology map, any domain -- virtual or physical 584 -- will have a well defined boundary between "inside" and "outside". 585 However, that boundary in itself has no technical meaning. What 586 matters in reality is whether a node is a member of the domain, and 587 whether it is at the boundary between the domain and the rest of the 588 Internet. Thus the boundary in itself does not need to be 589 identified. However, a sending node needs to know whether it is 590 sending to an inside or outside destination; a receiving node needs 591 to know whether a packet originated inside or outside; and a boundary 592 node needs to know which of its interfaces are inward-facing or 593 outward-facing. It is irrelevant whether the interfaces involved are 594 physical or virtual. 596 With this perspective, we can list some general functional 597 requirements. An underlying assumption here is that domain 598 membership operations should be cryptographically secured; a domain 599 without such security cannot be reliably protected from attack. 601 1. Domain Identity. A domain must have a unique and verifiable 602 identifier; effectively this should be a public key for the 603 domain. Without this, there is no way to secure domain 604 operations and domain membership. The holder of the 605 corresponding private key becomes the trust anchor for the 606 domain. 608 2. Node Eligibility. It must be possible for a node to determine 609 which domain(s) it can potentially join, and on which 610 interface(s). 612 3. Secure Enrolment. A node must be able to enrol in a given domain 613 via secure node identfication and to acquire relevant security 614 credentials (authorization) for operations within the domain. If 615 a node has multiple physical or virtual interfaces, they may 616 require to be individually enrolled. 618 4. Withdrawal. A node must be able to cancel enrolment in a given 619 domain. 621 5. Dynamic Membership. Optionally, a node should be able 622 temporarily leave or rejoin a domain (i.e. enrolment is 623 persistent but membership is intermittent). 625 6. Role, implying authorization to perform a certain set of actions. 626 A node must have a verifiable role. In the simplest case, the 627 choices of role are "interior node" and "boundary node". In a 628 boundary node, individual interfaces may have different roles, 629 e.g. "inward facing" and "outward facing". 631 7. Verify Peer. A node must be able to verify whether another node 632 is a member of the domain. 634 8. Verify Role. A node must be able to learn the verified role of 635 another node. In particular, it must be possible for a node to 636 find boundary nodes (interfacing to the Internet). 638 9. Domain Data. In a domain with management requirements, it must 639 be possible for a node to acquire domain policy and/or domain 640 configuration data. This would include, for example, filtering 641 policy to ensure that inappropriate packets do not leave the 642 domain. 644 These requirements could form the basis for further analysis and 645 solution design. 647 Another aspect is whether individual packets within a limited domain 648 need to carry any sort of indicator that they belong to that domain, 649 or whether this information will be implicit in the IP addresses of 650 the packet. A related question is whether individual packets need 651 cryptographic authentication. This topic is for further study. 653 7. Security Considerations 655 Clearly, the boundary of a limited domain will almost always also act 656 as a security boundary. In particular, it will serve as a trust 657 boundary, and as a boundary of authority for defining capabilities. 658 Within the boundary, limited-domain protocols or protocol features 659 will be useful, but they will be meaningless if they enter or leave 660 the domain. 662 The security model for a limited-scope protocol must allow for the 663 boundary, and in particular for a trust model that changes at the 664 boundary. Typically, credentials will need to be signed by a domain- 665 specific authority. 667 8. IANA Considerations 669 This document makes no request of the IANA. 671 9. Contributors 673 Sheng Jiang made important contributions to this document. 675 10. Acknowledgements 677 Useful comments were received from Amelia Andersdotter, Edward 678 Birrane, David Black, Ron Bonica, Tim Chown, Darren Dukes, Tom 679 Herbert, John Klensin, Andy Malis, Michael Richardson, Rick Taylor, 680 Niels ten Oever, and other members of the ANIMA and INTAREA WGs. 682 11. Informative References 684 [BIGIP] Li, R., "HUAWEI - Big IP Initiative.", 2018, 685 . 687 [I-D.andrews-tcp-and-ipv6-use-minmtu] 688 Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", 689 draft-andrews-tcp-and-ipv6-use-minmtu-04 (work in 690 progress), October 2015. 692 [I-D.dcrocker-dns-perimeter] 693 Crocker, D. and T. Adams, "DNS Perimeter Overlay", draft- 694 dcrocker-dns-perimeter-00 (work in progress), April 2019. 696 [I-D.filsfils-spring-srv6-network-programming] 697 Filsfils, C., Camarillo, P., Leddy, J., 698 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 699 Network Programming", draft-filsfils-spring-srv6-network- 700 programming-07 (work in progress), February 2019. 702 [I-D.fioccola-v6ops-ipv6-alt-mark] 703 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 704 Performance Measurement with Alternate Marking Method", 705 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 706 June 2018. 708 [I-D.geng-netslices-architecture] 709 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 710 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 711 Architecture", draft-geng-netslices-architecture-02 (work 712 in progress), July 2017. 714 [I-D.herbert-fast] 715 Herbert, T., "Firewall and Service Tickets", draft- 716 herbert-fast-04 (work in progress), April 2019. 718 [I-D.herbert-ipv4-eh] 719 Herbert, T., "IPv4 Extension Headers and Flow Label", 720 draft-herbert-ipv4-eh-00 (work in progress), April 2019. 722 [I-D.ietf-6man-segment-routing-header] 723 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 724 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 725 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 726 progress), April 2019. 728 [I-D.ietf-anima-autonomic-control-plane] 729 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 730 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 731 plane-19 (work in progress), March 2019. 733 [I-D.ietf-anima-reference-model] 734 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 735 and J. Nobre, "A Reference Model for Autonomic 736 Networking", draft-ietf-anima-reference-model-10 (work in 737 progress), November 2018. 739 [I-D.ietf-detnet-architecture] 740 Finn, N., Thubert, P., Varga, B., and J. Farkas, 741 "Deterministic Networking Architecture", draft-ietf- 742 detnet-architecture-12 (work in progress), March 2019. 744 [I-D.ietf-detnet-dp-sol] 745 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 746 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 747 "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- 748 sol-04 (work in progress), March 2018. 750 [I-D.ietf-detnet-use-cases] 751 Grossman, E., "Deterministic Networking Use Cases", draft- 752 ietf-detnet-use-cases-20 (work in progress), December 753 2018. 755 [I-D.ietf-homenet-simple-naming] 756 Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming 757 and Service Discovery Architecture", draft-ietf-homenet- 758 simple-naming-03 (work in progress), October 2018. 760 [I-D.ietf-intarea-frag-fragile] 761 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 762 and F. Gont, "IP Fragmentation Considered Fragile", draft- 763 ietf-intarea-frag-fragile-09 (work in progress), February 764 2019. 766 [I-D.ietf-ipwave-vehicular-networking] 767 Jeong, J., "IP Wireless Access in Vehicular Environments 768 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 769 ipwave-vehicular-networking-08 (work in progress), March 770 2019. 772 [I-D.ietf-opsec-ipv6-eh-filtering] 773 Gont, F. and W. LIU, "Recommendations on the Filtering of 774 IPv6 Packets Containing IPv6 Extension Headers", draft- 775 ietf-opsec-ipv6-eh-filtering-06 (work in progress), July 776 2018. 778 [I-D.ioametal-ippm-6man-ioam-ipv6-options] 779 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 780 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 781 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 782 "In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam- 783 ipv6-options-02 (work in progress), March 2019. 785 [I-D.irtf-nfvrg-gaps-network-virtualization] 786 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 787 Aranda, P., and P. Lynch, "Network Virtualization Research 788 Challenges", draft-irtf-nfvrg-gaps-network- 789 virtualization-10 (work in progress), September 2018. 791 [I-D.jiang-semantic-prefix] 792 Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, 793 "Analysis of Semantic Embedded IPv6 Address Schemas", 794 draft-jiang-semantic-prefix-06 (work in progress), July 795 2013. 797 [I-D.li-6man-service-aware-ipv6-network] 798 Li, Z. and S. Peng, "Service-aware IPv6 Network", draft- 799 li-6man-service-aware-ipv6-network-00 (work in progress), 800 March 2019. 802 [I-D.moulchan-nmrg-network-intent-concepts] 803 Sivakumar, K. and M. Chandramouli, "Concepts of Network 804 Intent", draft-moulchan-nmrg-network-intent-concepts-00 805 (work in progress), October 2017. 807 [I-D.voyer-6man-extension-header-insertion] 808 daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes, 809 D., Previdi, S., and S. Matsushima, "Insertion of IPv6 810 Segment Routing Headers in a Controlled Domain", draft- 811 voyer-6man-extension-header-insertion-05 (work in 812 progress), January 2019. 814 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 815 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 816 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 817 September 1997, . 819 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 820 "Definition of the Differentiated Services Field (DS 821 Field) in the IPv4 and IPv6 Headers", RFC 2474, 822 DOI 10.17487/RFC2474, December 1998, 823 . 825 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 826 DOI 10.17487/RFC2775, February 2000, 827 . 829 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 830 RFC 2923, DOI 10.17487/RFC2923, September 2000, 831 . 833 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 834 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 835 . 837 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 838 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 839 . 841 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 842 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 843 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 844 April 2007, . 846 [RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet 847 Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, 848 . 850 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 851 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 852 2011, . 854 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 855 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 856 2011, . 858 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 859 RFC 6455, DOI 10.17487/RFC6455, December 2011, 860 . 862 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 863 "Architectural Considerations on Application Features in 864 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 865 . 867 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 868 of IPv6 Extension Headers", RFC 7045, 869 DOI 10.17487/RFC7045, December 2013, 870 . 872 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 873 Constrained-Node Networks", RFC 7228, 874 DOI 10.17487/RFC7228, May 2014, 875 . 877 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 878 Weil, "IPv6 Home Networking Architecture Principles", 879 RFC 7368, DOI 10.17487/RFC7368, October 2014, 880 . 882 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 883 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 884 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 885 . 887 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 888 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 889 . 891 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 892 IAB Workshop on Stack Evolution in a Middlebox Internet 893 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 894 . 896 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 897 Chaining (SFC) Architecture", RFC 7665, 898 DOI 10.17487/RFC7665, October 2015, 899 . 901 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 902 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 903 2016, . 905 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 906 "Observations on the Dropping of Packets with IPv6 907 Extension Headers in the Real World", RFC 7872, 908 DOI 10.17487/RFC7872, June 2016, 909 . 911 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 912 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 913 March 2017, . 915 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 916 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 917 March 2017, . 919 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 920 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 921 March 2017, . 923 [RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, 924 "Use Cases for Data Center Network Virtualization Overlay 925 Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017, 926 . 928 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 929 (IPv6) Specification", STD 86, RFC 8200, 930 DOI 10.17487/RFC8200, July 2017, 931 . 933 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 934 "Network Service Header (NSH)", RFC 8300, 935 DOI 10.17487/RFC8300, January 2018, 936 . 938 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 939 Decraene, B., Litkowski, S., and R. Shakir, "Segment 940 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 941 July 2018, . 943 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 944 Jacquenet, "An Inventory of Transport-Centric Functions 945 Provided by Middleboxes: An Operator Perspective", 946 RFC 8517, DOI 10.17487/RFC8517, February 2019, 947 . 949 Appendix A. Change log [RFC Editor: Please remove] 951 draft-carpenter-limited-domains-00, 2018-06-11: 953 Initial version 955 draft-carpenter-limited-domains-01, 2018-07-01: 957 Minor terminology clarifications 959 draft-carpenter-limited-domains-02, 2018-08-03: 961 Additions following IETF102 discussions 963 Updated authorship/contributors 965 draft-carpenter-limited-domains-03, 2018-09-12: 967 First draft of taxonomy 969 Editorial improvements 971 draft-carpenter-limited-domains-04, 2018-10-14: 973 Reorganized section 3 975 Newly written sections 6 and 7 977 Editorial improvements 979 draft-carpenter-limited-domains-05, 2018-12-12: 981 Added discussion of transparency/filtering debates 983 Added discussion of "controlled environment" 985 Modified assertion about localized standards 987 Editorial improvements 989 draft-carpenter-limited-domains-06, 2019-03-02: 991 Minor updates, fixed reference nits 993 draft-carpenter-limited-domains-07, 2019-04-15: 995 Moved taxonomy to an appendix. 997 Added examples and references. 999 Editorial improvements 1001 Appendix B. Taxonomy of Limited Domains 1003 This appendix develops a taxonomy for describing limited domains. 1004 Several major aspects are considered in this taxonomy: 1006 o The domain as a whole. 1008 o The individual nodes. 1010 o The domain boundary. 1012 o The domain's topology. 1014 o The domain's technology. 1016 o How the domain connects to the Internet. 1018 o The security, trust and privacy model. 1020 o Operations. 1022 The following sub-sections analyse each of these aspects. 1024 B.1. The Domain as a Whole 1026 o Why does the domain exist? (e.g., human choice, administrative 1027 policy, orchestration requirements, technical requirements) 1029 o If there are special requirements, are they at Layer 2, Layer 3 or 1030 an upper layer? 1032 o Is the domain managed by humans or fully autonomic? 1034 o If managed, what style of management applies? (Manual 1035 configuration, automated configuration, orchestration?) 1037 o Is there a policy model? (Intent, configuration policies?) 1039 o Does the domain provide controlled or paid service or open access? 1041 B.2. Individual Nodes 1043 o Is a domain member a complete node, or only one interface of a 1044 node? 1046 o Are nodes permanent members of a given domain, or are join and 1047 leave operations possible? 1049 o Are nodes physical or virtual devices? 1051 o Are virtual nodes general-purpose, or limited to specific 1052 functions, applications or users? 1054 o Are nodes constrained (by battery etc)? 1056 o Are devices installed "out of the box" or pre-configured? 1058 B.3. The Domain Boundary 1060 o How is the domain boundary identified or defined? 1062 o Is the domain boundary fixed or dynamic? 1064 o Are boundary nodes special? Or can any node be at the boundary? 1066 B.4. Topology 1068 o Is the domain a subset of a layer 2 or 3 connectivity domain? 1070 o In IP addressing terms, is the domain Link-local, Site-local, or 1071 Global? 1073 o Does the domain overlap other domains? (In other words, a node 1074 may or may not be allowed to be a member of multiple domains.) 1076 o Does the domain match physical topology, or does it have a virtual 1077 (overlay) topology? 1079 o Is the domain in a single building, vehicle or campus? Or is it 1080 distributed? 1082 o If distributed, are the interconnections private or over the 1083 Internet? 1085 o In IP addressing terms, is the domain Link-local, Site-local, or 1086 Global? 1088 B.5. Technology 1090 o What routing protocol(s) are used, or even different forwarding 1091 mechanisms (MPLS or other non-IP mechanism)? 1093 o In an overlay domain, what overlay technique is used (L2VPN, 1094 L3VPN,...)? 1096 o Are there specific QoS requirements? 1098 o Link latency - normal or long latency links? 1100 o Mobility - are nodes mobile? Is the whole network mobile? 1102 o Which specific technologies, such as those in Section 4, are 1103 applicable? 1105 B.6. Connection to the Internet 1107 o Is the Internet connection permanent or intermittent? (Never 1108 connected is out of scope.) 1110 o What traffic is blocked, in and out? 1112 o What traffic is allowed, in and out? 1114 o What traffic is transformed, in and out? 1116 o Is secure and privileged remote access needed? 1118 o Does the domain allow unprivileged remote sessions? 1120 B.7. Security, Trust and Privacy Model 1122 o Must domain members be authorized? 1124 o Are all nodes in the domain at the same trust level? 1126 o Is traffic authenticated? 1128 o Is traffic encrypted? 1130 o What is hidden from the outside? 1132 B.8. Operations 1134 o Safety level - does the domain have a critical (human) safety 1135 role? 1137 o Reliability requirement - normal or 99.999% ? 1139 o Environment - hazardous conditions? 1141 o Installation - are specialists needed? 1143 o Service visits - easy, difficult, impossible? 1145 o Software/firmware updates - possible or impossible? 1147 B.9. Making use of this taxonomy 1149 This taxonomy could be used to design or analyse a specific type of 1150 limited domain. For the present document, it is intended only to 1151 form a background to the scope of protocols used in limited domains, 1152 and the mechanisms required to securely define domain membership and 1153 properties. 1155 Authors' Addresses 1157 Brian Carpenter 1158 The University of Auckland 1159 School of Computer Science 1160 University of Auckland 1161 PB 92019 1162 Auckland 1142 1163 New Zealand 1165 Email: brian.e.carpenter@gmail.com 1167 Bing Liu 1168 Huawei Technologies 1169 Q14, Huawei Campus 1170 No.156 Beiqing Road 1171 Hai-Dian District, Beijing 100095 1172 P.R. China 1174 Email: leo.liubing@huawei.com