idnits 2.17.1 draft-carpenter-limited-domains-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 11, 2018) is 2147 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-13 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-16 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-06 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-05 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-16 == Outdated reference: A later version (-03) exists of draft-ietf-homenet-simple-naming-01 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-02 == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-05 == Outdated reference: A later version (-10) exists of draft-irtf-nfvrg-gaps-network-virtualization-09 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-03 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 S. Jiang 5 Expires: December 13, 2018 Huawei Technologies Co., Ltd 6 June 11, 2018 8 Limited Domains and Internet Protocols 9 draft-carpenter-limited-domains-00 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 and emerging solutions. It shows the needs for a 19 precise definition of a limited domain boundary and for a 20 corresponding protocol to allow nodes to discover where such a 21 boundary exists. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 13, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Examples of Limited Domain Requirements . . . . . . . . . . . 3 59 3. Examples of Limited Domain Solutions . . . . . . . . . . . . 5 60 4. Common Aspects of Limited Domains . . . . . . . . . . . . . . 7 61 5. The Need to Define a Limited Domain Boundary . . . . . . . . 8 62 6. Defining Protocol Scope . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 10. Informative References . . . . . . . . . . . . . . . . . . . 8 67 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 As the Internet continues to grow and diversify, with a realistic 73 prospect of tens of billions of nodes being connected directly and 74 indirectly, there is a noticeable trend towards local requirements, 75 behaviours and semantics. The word "local" should be understood in a 76 special sense, however. In some cases it may refer to geographical 77 and physical locality - all the nodes in a single building, on a 78 single campus, or in a given vehicle. In other cases it may refer to 79 a defined set of users or nodes distributed over a much wider area, 80 but drawn together by a single virtual network over the Internet, or 81 a single physical network running partially in parallel with the 82 Internet. We expand on these possibilities below. To capture the 83 topic, this document refers to such networks as "limited domains". 85 The phrase "Balkanization of the Internet" has often been used to 86 criticise mechanisms that block the free flow of information across 87 the network. That is not the topic of this document, which does not 88 discuss filtering mechanisms and does not apply to protocols that are 89 designed for use across the whole Internet. 91 The requirements of limited domains will be different in different 92 scenarios. Policies, default parameters, and the options supported 93 may vary. Also, the style of network management may vary, between a 94 completely unmanaged network, one with fully autonomic management, 95 one with traditional central management, and mixtures of the above. 97 Finally, the requirements and solutions for security and privacy may 98 vary. 100 This documents analyses and discusses some of the consequences of 101 this trend, and how it impacts the idea of universal interoperability 102 in the Internet. In particular, we challenge the notion that all 103 Internet standards must be universal in scope and applicability. To 104 the contrary, we assert that some standards need to be specifically 105 limited in their applicability. This requires that the concepts of a 106 limited domain, and of its boundary, need to be formalised. 108 NOTE: This document is incomplete. Comments on the following two 109 sections are invited before we complete the later sections. 111 2. Examples of Limited Domain Requirements 113 This section describes various examples where limited domain 114 requirements can be identified. It is of course not a complete list. 116 NOTE: The authors welcome more suggestions and references for this 117 list. 119 1. A home network. It will be unmanaged, constructed by a non- 120 specialist, and will possibly include wiring errors such as 121 physical loops. It must work with devices "out of the box" as 122 shipped by their manufacturers and must create adequate security 123 by default. Remote access may be required. The requirements 124 and applicable principles are summarised in [RFC7368]. 126 2. A small office network. This is very similar to a home network, 127 since whoever is in charge will probably have little or no 128 specialist knowledge, but may have differing security and 129 privacy requirements. Remote access may be required. 131 3. A vehicle network. This will be designed by the vehicle 132 manufacturer but may include devices added by the vehicle's 133 owner or operator. Parts of the network will have demanding 134 performance and reliability requirements with implications for 135 human safety. Remote access may be required to certain 136 functions, but absolutely forbidden for others. Communication 137 with other vehicles, roadside infrastructure, and external data 138 sources will be required. See 139 [I-D.ietf-ipwave-vehicular-networking] for a survey of use 140 cases. 142 4. A building services network. This will be designed specifically 143 for a particular building, but using standard components. 144 Additional devices may need to be added at any time. Parts of 145 the network may have demanding reliability requirements with 146 implications for human safety. Remote access may be required to 147 certain functions, but absolutely forbidden for others. 148 [I-D.martocci-6lowapp-building-applications] (need current 149 reference!) 151 5. Supervisory Control And Data Acquisition (SCADA) networks in 152 general, which will exhibit widely differing requirements, 153 including tough real-time performance targets, of which building 154 networks are a simple example. See for example 155 [I-D.ietf-detnet-use-cases] 157 6. The three preceding cases will all include sensors, but some 158 networks may be specifically limited to sensors and the 159 collection and processing of sensor data. They may be in remote 160 or technically challenging locations and installed by non- 161 specialists. 163 7. "Traditional" enterprise and campus networks, which may be 164 spread over many kilometres and over multiple separate sites. 166 8. Data centres and hosting centres, or distributed services acting 167 as such centres. These will have high performance, security and 168 privacy requirements and will typically include large numbers of 169 independent "tenant" networks overlaid on shared infrastructure. 171 9. Content Delivery Networks, comprising distributed data centres 172 and the paths between them, spanning thousands of kilometres. 174 10. Internet of Things (IoT) networks. While this term is very 175 flexible and covers many innovative types of network, it seems 176 reasonable to assert that many IoT edge networks will in fact 177 have special requirements and protocols that are useful only 178 within a specific domain, and that these protocols cannot, and 179 for security reasons should not, run over the Internet as a 180 whole. 182 Two other concepts, while not tied to specific network types, also 183 strongly depend on the concept of limited domains: 185 1. Intent Based Networking. In this concept, a network domain is 186 configured and managed in accordance with an abstract policy 187 known as "Intent", to ensure that the network performs as 188 required [I-D.moulchan-nmrg-network-intent-concepts]. Whatever 189 technologies are used to support this, they will be applied 190 within the domain boundary. 192 2. Network Slicing. A network slice is a virtual network that 193 consists of a managed set of resources carved off from a larger 194 network [I-D.geng-netslices-architecture]. Whatever technologies 195 are used to support slicing, they will require a clear definition 196 of the boundary of a given slice. 198 While it is clearly desirable to use common solutions, and therefore 199 common standards, wherever possible, it is increasingly difficult to 200 do so while satisfying the widely varying requirements outlined 201 above. However, there is a tendency when new protocols and protocol 202 extensions are proposed to always ask the question "How will this 203 work across the open Internet?" This document suggests that this is 204 not always the right question. There are protocols and extensions 205 that are not intended to work across the open Internet. On the 206 contrary, their requirements and semantics are specifically limited 207 (in the sense defined above). 209 A common argument is that if a protocol is intended for limited use, 210 the chances are very high that it will in fact be used (or misused) 211 in other scenarios including the so-called open Internet. This is 212 undoubtedly true and means that limited use is not an excuse for bad 213 design or poor security. In fact, a limited use requirement 214 potentially adds complexity to both the protocol and its security 215 design, as discussed later. 217 Nevertheless, because of the diversity of limited environments with 218 specific requirements that is now emerging, specific standards will 219 necessarily emerge. There will be attempts to capture each market 220 sector, but the market will demand standardised limited solutions. 221 However, the "open Internet" must remain as the universal method of 222 interconnection. Reconciling these two aspects is a major challenge. 224 3. Examples of Limited Domain Solutions 226 This section lists various examples of specific limited domain 227 solutions that have been proposed or defined. It intentionally does 228 not include Layer 2 technology solutions, which are by definition 229 defined for limited domains. 231 NOTE: Please suggest additional items for this list. 233 1. Differentiated Services. This mechanism [RFC2474] allows a 234 network to assign locally significant values to the 6-bit 235 Differentiated Services Code Point field in any IP packet. 236 Although there are some recommended codepoint values for specific 237 per-hop queue management behaviours, these are specifically 238 intended to be domain-specific codepoints with traffic being 239 classified, conditioned and re-marked at domain boundaries 240 (unless there is an inter-domain agreement that makes re-marking 241 unnecessary). 243 2. Network function virtualisation. As described in 244 [I-D.irtf-nfvrg-gaps-network-virtualization], this general 245 concept is an open research topic, in which virtual network 246 functions are orchestrated as part of a distributed system. 247 Inevitably such orchestration applies to an administrative domain 248 of some kind, even though cross-domain orchestration is also a 249 research area. 251 3. Service Function Chaining (SFC). This technique [RFC7665] 252 assumes that services within a network are constructed as 253 sequences of individual functions within a specific SFC-enabled 254 domain. As that RFC states: "Specific features may need to be 255 enforced at the boundaries of an SFC-enabled domain, for example 256 to avoid leaking SFC information". A Network Service Header 257 (NSH) [RFC8300] is used to encapsulate packets flowing through 258 the service function chain: "The intended scope of the NSH is for 259 use within a single provider's operational domain." 261 4. Data Centre Network Virtualization Overlays. A common 262 requirement in data centres that host many tenants (clients) is 263 to provide each one with a secure private network, all running 264 over the same physical infrastructure. [RFC8151] describes 265 various use cases for this, and specifications are under 266 development. These include use cases in which the tenant network 267 is physically split over several data centres, but which must 268 appear to the user as a single secure domain. 270 5. Segment Routing. This is a technique which "steers a packet 271 through an ordered list of instructions, called segments" 272 [I-D.ietf-spring-segment-routing]. The semantics of these 273 instructions are explicitly local to a segment routing domain or 274 even to a single node. Technically, these segments or 275 instructions are represented as an MPLS label or an IPv6 address, 276 which clearly adds a semantic interpretation to them within the 277 domain. 279 6. Autonomic Networking. As explained in 280 [I-D.ietf-anima-reference-model], an autonomic network is also a 281 security domain within which an autonomic control plane 282 [I-D.ietf-anima-autonomic-control-plane] is used by service 283 agents. These service agents manage technical objectives, which 284 may be locally defined, subject to domain-wide policy. Thus the 285 domain boundary is important for both security and protocol 286 purposes. 288 7. Homenet. As shown in [RFC7368], a home networking domain has 289 specific protocol needs that differ from those in an enterprise 290 network or the Internet as a whole. These include the Home 291 Network Control Protocol (HNCP) [RFC7788] and a naming and 292 discovery solution [I-D.ietf-homenet-simple-naming]. 294 8. Creative uses of IPv6 features. As IPv6 enters more general use, 295 engineers notice that it has much more flexibility than IPv4. 296 Innovative suggestions have been made for: 298 * The flow label, e.g. [RFC6294], 299 [I-D.fioccola-v6ops-ipv6-alt-mark]. 301 * Extension headers, e.g. for segment routing 302 [I-D.ietf-6man-segment-routing-header]. 304 * Meaningful address bits, e.g. [I-D.jiang-semantic-prefix]. 305 Also, segment routing uses IPv6 addresses as segment 306 identifiers with specific local meanings 307 [I-D.ietf-spring-segment-routing]. 309 All of these suggestions are only viable within a specified 310 domain. The case of the extension header is particularly 311 interesting, since its existence has been a major "selling point" 312 for IPv6, but it is notorious that new extension headers are 313 virtually impossible to deploy across the whole Internet 314 [RFC7045], [RFC7872]. It is worth noting that extension header 315 filtering is considered as an important security issue 316 [I-D.ietf-opsec-ipv6-eh-filtering]. There is considerable 317 appetite among vendors or operators to have flexibility in 318 defining extension headers for use in limited or specialised 319 domains, e.g. [I-D.voyer-6man-extension-header-insertion] and 320 [BIGIP]. 322 9. Deterministic Networking (DetNet). The Deterministic Networking 323 Architecture [I-D.ietf-detnet-architecture] and encapsulation 324 [I-D.ietf-detnet-dp-sol] aim to support flows with extremely low 325 data loss rates and bounded latency, but only within a part of 326 the network that is "DetNet aware". Thus, as for differentiated 327 services above, the concept of a domain is fundamental. 329 4. Common Aspects of Limited Domains 331 This section derives common aspects of limited domains from the 332 examples above. 334 TBD 336 5. The Need to Define a Limited Domain Boundary 338 This section justifies the need for a precise definition of a limited 339 domain boundary and for a corresponding protocol to allow nodes to 340 discover where such a boundary exists. 342 TBD 344 6. Defining Protocol Scope 346 This section suggests that protocols or protocol extensions should, 347 when appropriate, be standardised to interoperate only within a 348 Limited Domain Boundary. Such protocols are not required to operate 349 across the Internet as a whole. 351 TBD 353 7. Security Considerations 355 Clearly, the boundary of a limited domain will almost always also act 356 as a security boundary. In particular, it will serve as a trust 357 boundary, and as a boundary of authority for defining capabilities. 358 Within the boundary, limited-domain protocols or protocol features 359 will be useful, but they will be meaningless if they enter or leave 360 the domain. 362 The security model for a limited-scope protocol must allow for the 363 boundary, and in particular for a trust model that changes at the 364 boundary. Typically, credentials will need to be signed by a domain- 365 specific authority. 367 8. IANA Considerations 369 This document makes no request of the IANA. 371 9. Acknowledgements 373 Useful comments were received from ... 375 10. Informative References 377 [BIGIP] Li, R., "HUAWEI - Big IP Initiative.", 2018, 378 . 380 [I-D.fioccola-v6ops-ipv6-alt-mark] 381 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 382 Performance Measurement with Alternate Marking Method", 383 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 384 June 2018. 386 [I-D.geng-netslices-architecture] 387 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 388 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 389 Architecture", draft-geng-netslices-architecture-02 (work 390 in progress), July 2017. 392 [I-D.ietf-6man-segment-routing-header] 393 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 394 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 395 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 396 progress), May 2018. 398 [I-D.ietf-anima-autonomic-control-plane] 399 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 400 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 401 plane-16 (work in progress), June 2018. 403 [I-D.ietf-anima-reference-model] 404 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 405 and J. Nobre, "A Reference Model for Autonomic 406 Networking", draft-ietf-anima-reference-model-06 (work in 407 progress), February 2018. 409 [I-D.ietf-detnet-architecture] 410 Finn, N., Thubert, P., Varga, B., and J. Farkas, 411 "Deterministic Networking Architecture", draft-ietf- 412 detnet-architecture-05 (work in progress), May 2018. 414 [I-D.ietf-detnet-dp-sol] 415 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 416 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 417 "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- 418 sol-04 (work in progress), March 2018. 420 [I-D.ietf-detnet-use-cases] 421 Grossman, E., "Deterministic Networking Use Cases", draft- 422 ietf-detnet-use-cases-16 (work in progress), May 2018. 424 [I-D.ietf-homenet-simple-naming] 425 Lemon, T., Migault, D., and S. Cheshire, "Simple Homenet 426 Naming and Service Discovery Architecture", draft-ietf- 427 homenet-simple-naming-01 (work in progress), March 2018. 429 [I-D.ietf-ipwave-vehicular-networking] 430 Jeong, J., "IP-based Vehicular Networking: Use Cases, 431 Survey and Problem Statement", draft-ietf-ipwave- 432 vehicular-networking-02 (work in progress), March 2018. 434 [I-D.ietf-opsec-ipv6-eh-filtering] 435 Gont, F. and W. LIU, "Recommendations on the Filtering of 436 IPv6 Packets Containing IPv6 Extension Headers", draft- 437 ietf-opsec-ipv6-eh-filtering-05 (work in progress), March 438 2018. 440 [I-D.ietf-spring-segment-routing] 441 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 442 Litkowski, S., and R. Shakir, "Segment Routing 443 Architecture", draft-ietf-spring-segment-routing-15 (work 444 in progress), January 2018. 446 [I-D.irtf-nfvrg-gaps-network-virtualization] 447 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 448 Aranda, P., and P. Lynch, "Network Virtualization Research 449 Challenges", draft-irtf-nfvrg-gaps-network- 450 virtualization-09 (work in progress), February 2018. 452 [I-D.jiang-semantic-prefix] 453 Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, 454 "Analysis of Semantic Embedded IPv6 Address Schemas", 455 draft-jiang-semantic-prefix-06 (work in progress), July 456 2013. 458 [I-D.martocci-6lowapp-building-applications] 459 Martocci, J., Schoofs, A., and P. Stok, "Commercial 460 Building Applications Requirements", draft-martocci- 461 6lowapp-building-applications-01 (work in progress), July 462 2010. 464 [I-D.moulchan-nmrg-network-intent-concepts] 465 Sivakumar, K. and M. Chandramouli, "Concepts of Network 466 Intent", draft-moulchan-nmrg-network-intent-concepts-00 467 (work in progress), October 2017. 469 [I-D.voyer-6man-extension-header-insertion] 470 daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes, 471 D., Previdi, S., and S. Matsushima, "Insertion of IPv6 472 Segment Routing Headers in a Controlled Domain", draft- 473 voyer-6man-extension-header-insertion-03 (work in 474 progress), May 2018. 476 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 477 "Definition of the Differentiated Services Field (DS 478 Field) in the IPv4 and IPv6 Headers", RFC 2474, 479 DOI 10.17487/RFC2474, December 1998, 480 . 482 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 483 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 484 2011, . 486 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 487 of IPv6 Extension Headers", RFC 7045, 488 DOI 10.17487/RFC7045, December 2013, 489 . 491 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 492 Weil, "IPv6 Home Networking Architecture Principles", 493 RFC 7368, DOI 10.17487/RFC7368, October 2014, 494 . 496 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 497 Chaining (SFC) Architecture", RFC 7665, 498 DOI 10.17487/RFC7665, October 2015, 499 . 501 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 502 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 503 2016, . 505 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 506 "Observations on the Dropping of Packets with IPv6 507 Extension Headers in the Real World", RFC 7872, 508 DOI 10.17487/RFC7872, June 2016, 509 . 511 [RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, 512 "Use Cases for Data Center Network Virtualization Overlay 513 Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017, 514 . 516 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 517 "Network Service Header (NSH)", RFC 8300, 518 DOI 10.17487/RFC8300, January 2018, 519 . 521 Appendix A. Change log [RFC Editor: Please remove] 523 draft-carpenter-limited-domains, 2018-06-11: 525 Initial version 527 Authors' Addresses 529 Brian Carpenter 530 Department of Computer Science 531 University of Auckland 532 PB 92019 533 Auckland 1142 534 New Zealand 536 Email: brian.e.carpenter@gmail.com 538 Sheng Jiang 539 Huawei Technologies Co., Ltd 540 Q14, Huawei Campus, No.156 Beiqing Road 541 Hai-Dian District, Beijing, 100095 542 P.R. China 544 Email: jiangsheng@huawei.com