< draft-carpenter-limited-domains-08.txt   draft-carpenter-limited-domains-09.txt >
Network Working Group B. Carpenter Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational B. Liu Intended status: Informational B. Liu
Expires: December 14, 2019 Huawei Technologies Expires: December 23, 2019 Huawei Technologies
June 12, 2019 June 21, 2019
Limited Domains and Internet Protocols Limited Domains and Internet Protocols
draft-carpenter-limited-domains-08 draft-carpenter-limited-domains-09
Abstract Abstract
There is a noticeable trend towards network requirements, behaviours There is a noticeable trend towards network requirements, behaviours
and semantics that are specific to a limited region of the Internet and semantics that are specific to a limited region of the Internet
and a particular set of requirements. Policies, default parameters, and a particular set of requirements. Policies, default parameters,
the options supported, the style of network management and security the options supported, the style of network management and security
requirements may vary. This document reviews examples of such requirements may vary. This document reviews examples of such
limited domains, also known as controlled environments, and emerging limited domains, also known as controlled environments, and emerging
solutions, and includes a related taxonomy. It then briefly solutions, and includes a related taxonomy. It then briefly
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2019. This Internet-Draft will expire on December 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Failure Modes in Today's Internet . . . . . . . . . . . . . . 4 2. Failure Modes in Today's Internet . . . . . . . . . . . . . . 4
3. Examples of Limited Domain Requirements . . . . . . . . . . . 4 3. Examples of Limited Domain Requirements . . . . . . . . . . . 4
4. Examples of Limited Domain Solutions . . . . . . . . . . . . 8 4. Examples of Limited Domain Solutions . . . . . . . . . . . . 8
5. The Scope of Protocols in Limited Domains . . . . . . . . . . 11 5. The Scope of Protocols in Limited Domains . . . . . . . . . . 11
6. Functional Requirements of Limited Domains . . . . . . . . . 13 6. Functional Requirements of Limited Domains . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. Informative References . . . . . . . . . . . . . . . . . . . 16 11. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 22 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 22
Appendix B. Taxonomy of Limited Domains . . . . . . . . . . . . 23 Appendix B. Taxonomy of Limited Domains . . . . . . . . . . . . 23
B.1. The Domain as a Whole . . . . . . . . . . . . . . . . . . 24 B.1. The Domain as a Whole . . . . . . . . . . . . . . . . . . 24
B.2. Individual Nodes . . . . . . . . . . . . . . . . . . . . 24 B.2. Individual Nodes . . . . . . . . . . . . . . . . . . . . 24
B.3. The Domain Boundary . . . . . . . . . . . . . . . . . . . 24 B.3. The Domain Boundary . . . . . . . . . . . . . . . . . . . 25
B.4. Topology . . . . . . . . . . . . . . . . . . . . . . . . 25 B.4. Topology . . . . . . . . . . . . . . . . . . . . . . . . 25
B.5. Technology . . . . . . . . . . . . . . . . . . . . . . . 25 B.5. Technology . . . . . . . . . . . . . . . . . . . . . . . 25
B.6. Connection to the Internet . . . . . . . . . . . . . . . 26 B.6. Connection to the Internet . . . . . . . . . . . . . . . 26
B.7. Security, Trust and Privacy Model . . . . . . . . . . . . 26 B.7. Security, Trust and Privacy Model . . . . . . . . . . . . 26
B.8. Operations . . . . . . . . . . . . . . . . . . . . . . . 26 B.8. Operations . . . . . . . . . . . . . . . . . . . . . . . 26
B.9. Making use of this taxonomy . . . . . . . . . . . . . . . 26 B.9. Making use of this taxonomy . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
As the Internet continues to grow and diversify, with a realistic As the Internet continues to grow and diversify, with a realistic
prospect of tens of billions of nodes being connected directly and prospect of tens of billions of nodes being connected directly and
indirectly, there is a noticeable trend towards network-specific and indirectly, there is a noticeable trend towards network-specific and
local requirements, behaviours and semantics. The word "local" local requirements, behaviours and semantics. The word "local"
should be understood in a special sense, however. In some cases it should be understood in a special sense, however. In some cases it
may refer to geographical and physical locality - all the nodes in a may refer to geographical and physical locality - all the nodes in a
skipping to change at page 5, line 50 skipping to change at page 5, line 50
for others. for others.
5. Sensor networks. The two preceding cases will all include 5. Sensor networks. The two preceding cases will all include
sensors, but some networks may be specifically limited to sensors, but some networks may be specifically limited to
sensors and the collection and processing of sensor data. They sensors and the collection and processing of sensor data. They
may be in remote or technically challenging locations and may be in remote or technically challenging locations and
installed by non-specialists. installed by non-specialists.
6. Internet of Things (IoT) networks. While this term is very 6. Internet of Things (IoT) networks. While this term is very
flexible and covers many innovative types of network, including flexible and covers many innovative types of network, including
ad hoc networks that are formed spontaneously, it seems ad hoc networks that are formed spontaneously, and some
reasonable to expect that IoT edge networks will have special applications of 5G technology, it seems reasonable to expect
requirements and protocols that are useful only within a that IoT edge networks will have special requirements and
specific domain, and that these protocols cannot, and for protocols that are useful only within a specific domain, and
security reasons should not, run over the Internet as a whole. that these protocols cannot, and for security reasons should
not, run over the Internet as a whole.
7. An important subclass of IoT networks consists of constrained 7. An important subclass of IoT networks consists of constrained
networks [RFC7228] in which the nodes are limited in power networks [RFC7228] in which the nodes are limited in power
consumption and communications bandwidth, and are therefore consumption and communications bandwidth, and are therefore
limited to using very frugal protocols. limited to using very frugal protocols.
8. Delay tolerant networks may consist of domains that are 8. Delay tolerant networks may consist of domains that are
relatively isolated and constrained in power (e.g. deep space relatively isolated and constrained in power (e.g. deep space
networks) and are connected only intermittently to the outside, networks) and are connected only intermittently to the outside,
with a very long latency on such connections [RFC4838]. Clearly with a very long latency on such connections [RFC4838]. Clearly
skipping to change at page 7, line 33 skipping to change at page 7, line 37
2. Many of the above types of network may be extended throughout the 2. Many of the above types of network may be extended throughout the
Internet by a variety of virtual private network (VPN) Internet by a variety of virtual private network (VPN)
techniques. Therefore we argue that limited domains may overlap techniques. Therefore we argue that limited domains may overlap
each other in an arbitrary fashion by use of virtualization each other in an arbitrary fashion by use of virtualization
techniques. As noted above in the discussion of controlled techniques. As noted above in the discussion of controlled
environments, specific tunneling and encapsulation techniques may environments, specific tunneling and encapsulation techniques may
be tailored for use within a given domain. be tailored for use within a given domain.
3. Network Slicing. A network slice is a virtual network that 3. Network Slicing. A network slice is a virtual network that
consists of a managed set of resources carved off from a larger consists of a managed set of resources carved off from a larger
network [I-D.geng-netslices-architecture]. Whatever technologies network [I-D.geng-netslices-architecture]. This is expected to
are used to support slicing, they will require a clear definition be significant in 5G deployments
of the boundary of a given slice within a larger domain. [I-D.ietf-dmm-5g-uplane-analysis]. Whatever technologies are
used to support slicing, they will require a clear definition of
the boundary of a given slice within a larger domain.
While it is clearly desirable to use common solutions, and therefore While it is clearly desirable to use common solutions, and therefore
common standards, wherever possible, it is increasingly difficult to common standards, wherever possible, it is increasingly difficult to
do so while satisfying the widely varying requirements outlined do so while satisfying the widely varying requirements outlined
above. However, there is a tendency when new protocols and protocol above. However, there is a tendency when new protocols and protocol
extensions are proposed to always ask the question "How will this extensions are proposed to always ask the question "How will this
work across the open Internet?" This document suggests that this is work across the open Internet?" This document suggests that this is
not always the right question. There are protocols and extensions not always the right question. There are protocols and extensions
that are not intended to work across the open Internet. On the that are not intended to work across the open Internet. On the
contrary, their requirements and semantics are specifically limited contrary, their requirements and semantics are specifically limited
skipping to change at page 9, line 8 skipping to change at page 9, line 12
[I-D.irtf-nfvrg-gaps-network-virtualization], this general [I-D.irtf-nfvrg-gaps-network-virtualization], this general
concept is an open research topic, in which virtual network concept is an open research topic, in which virtual network
functions are orchestrated as part of a distributed system. functions are orchestrated as part of a distributed system.
Inevitably such orchestration applies to an administrative Inevitably such orchestration applies to an administrative
domain of some kind, even though cross-domain orchestration is domain of some kind, even though cross-domain orchestration is
also a research area. also a research area.
4. Service Function Chaining (SFC). This technique [RFC7665] 4. Service Function Chaining (SFC). This technique [RFC7665]
assumes that services within a network are constructed as assumes that services within a network are constructed as
sequences of individual service functions within a specific SFC- sequences of individual service functions within a specific SFC-
enabled domain. As that RFC states: "Specific features may need enabled domain such as a 5G domain. As that RFC states:
to be enforced at the boundaries of an SFC-enabled domain, for "Specific features may need to be enforced at the boundaries of
example to avoid leaking SFC information". A Network Service an SFC-enabled domain, for example to avoid leaking SFC
Header (NSH) [RFC8300] is used to encapsulate packets flowing information". A Network Service Header (NSH) [RFC8300] is used
through the service function chain: "The intended scope of the to encapsulate packets flowing through the service function
NSH is for use within a single provider's operational domain." chain: "The intended scope of the NSH is for use within a single
provider's operational domain."
5. Firewall and Service Tickets (FAST). Such tickets would 5. Firewall and Service Tickets (FAST). Such tickets would
accompany a packet to claim the right to traverse a network or accompany a packet to claim the right to traverse a network or
request a specific network service [I-D.herbert-fast]. They request a specific network service [I-D.herbert-fast]. They
would only be meaningful within a particular domain. would only be meaningful within a particular domain.
6. Data Centre Network Virtualization Overlays. A common 6. Data Centre Network Virtualization Overlays. A common
requirement in data centres that host many tenants (clients) is requirement in data centres that host many tenants (clients) is
to provide each one with a secure private network, all running to provide each one with a secure private network, all running
over the same physical infrastructure. [RFC8151] describes over the same physical infrastructure. [RFC8151] describes
skipping to change at page 17, line 9 skipping to change at page 17, line 13
herbert-fast-04 (work in progress), April 2019. herbert-fast-04 (work in progress), April 2019.
[I-D.herbert-ipv4-eh] [I-D.herbert-ipv4-eh]
Herbert, T., "IPv4 Extension Headers and Flow Label", Herbert, T., "IPv4 Extension Headers and Flow Label",
draft-herbert-ipv4-eh-01 (work in progress), May 2019. draft-herbert-ipv4-eh-01 (work in progress), May 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing- Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-20 (work in progress), June 2019. header-21 (work in progress), June 2019.
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-19 (work in progress), March 2019. plane-19 (work in progress), March 2019.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
Networking", draft-ietf-anima-reference-model-10 (work in Networking", draft-ietf-anima-reference-model-10 (work in
skipping to change at page 17, line 33 skipping to change at page 17, line 37
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-13 (work in progress), May 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.ietf-detnet-dp-sol] [I-D.ietf-detnet-dp-sol]
Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga,
B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger,
"DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp-
sol-04 (work in progress), March 2018. sol-04 (work in progress), March 2018.
[I-D.ietf-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and d.
daniel.voyer@bell.ca, "User Plane Protocol and
Architectural Analysis on 3GPP 5G System", draft-ietf-dmm-
5g-uplane-analysis-01 (work in progress), March 2019.
[I-D.ietf-homenet-simple-naming] [I-D.ietf-homenet-simple-naming]
Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming
and Service Discovery Architecture", draft-ietf-homenet- and Service Discovery Architecture", draft-ietf-homenet-
simple-naming-03 (work in progress), October 2018. simple-naming-03 (work in progress), October 2018.
[I-D.ietf-intarea-frag-fragile] [I-D.ietf-intarea-frag-fragile]
Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", draft- and F. Gont, "IP Fragmentation Considered Fragile", draft-
ietf-intarea-frag-fragile-10 (work in progress), May 2019. ietf-intarea-frag-fragile-12 (work in progress), June
2019.
[I-D.ietf-ipwave-vehicular-networking] [I-D.ietf-ipwave-vehicular-networking]
Jeong, J., "IP Wireless Access in Vehicular Environments Jeong, J., "IP Wireless Access in Vehicular Environments
(IPWAVE): Problem Statement and Use Cases", draft-ietf- (IPWAVE): Problem Statement and Use Cases", draft-ietf-
ipwave-vehicular-networking-09 (work in progress), May ipwave-vehicular-networking-09 (work in progress), May
2019. 2019.
[I-D.ietf-opsec-ipv6-eh-filtering] [I-D.ietf-opsec-ipv6-eh-filtering]
Gont, F. and W. LIU, "Recommendations on the Filtering of Gont, F. and W. LIU, "Recommendations on the Filtering of
IPv6 Packets Containing IPv6 Extension Headers", draft- IPv6 Packets Containing IPv6 Extension Headers", draft-
skipping to change at page 23, line 38 skipping to change at page 23, line 43
draft-carpenter-limited-domains-08, 2019-06-12: draft-carpenter-limited-domains-08, 2019-06-12:
Added short discussion of address scopes. Added short discussion of address scopes.
Added possibility of nested or overlapped domains. Added possibility of nested or overlapped domains.
Integrated other comments received. Integrated other comments received.
Editorial improvements Editorial improvements
draft-carpenter-limited-domains-09, 2019-06-21:
Additional 5G citations.
Appendix B. Taxonomy of Limited Domains Appendix B. Taxonomy of Limited Domains
This appendix develops a taxonomy for describing limited domains. This appendix develops a taxonomy for describing limited domains.
Several major aspects are considered in this taxonomy: Several major aspects are considered in this taxonomy:
o The domain as a whole. o The domain as a whole.
o The individual nodes. o The individual nodes.
o The domain boundary. o The domain boundary.
 End of changes. 13 change blocks. 
23 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/