]> Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Internet-Draft "Limited Domains" are parts of an internet that may have notable differences or are just convenient to separate from the general Internet and can be delimited from that and from other Limited Domains by a defined boundary (the "border"). This memo focuses on the case where the nodes inside the Limited Domain want to interact with nodes on (or reachable via) the general Internet, but need some assistance at the border that is cognizant about the specific properties of the nodes in the Limited Domain. Self-Descriptions can provide the information needed for this assistance. About This Document Status information for this document may be found at . Discussion of this document takes place on the Thing-to-Thing Research Group mailing list (), which is archived at .

Introduction introduces the concept of "Limited Domains", i.e., parts of an internet that may have notable differences or are just convenient to separate from the general Internet and can be delimited from that and from other Limited Domains by a defined boundary (the "border"). Limited Domains are not a new concept, but they recently have gained significant attention as a way to accelerate innovation without always having to wait for the whole Internet to accept a new feature . Some Limited Domains can be directly connected to or interconnected via the Internet -- rules they use internally simply lose their force outside the Limited Domain. Some require stripping off some structures or translating some fields on the border to the Internet. Some can only be interconnected by running tunnels on top of the Internet. This memo focuses on the case where the nodes inside the Limited Domain want to interact with nodes on (or reachable via) the general Internet, but need some assistance at the border that is cognizant about the specific properties of the nodes in the Limited Domain. 6LoWPAN header compression actually is such an example, which can be considered a very small Limited Domain -- initially just the link and adaptation layer between two LoWPAN nodes, which themselves otherwise feel like standard Internet nodes. (6LoWPAN neighbor discovery already extends the Limited Domain out to the border router (6LBR), but let's focus on header compression itself for now.) Extending the Limited Domain to more than two nodes may allow the nodes inside the Limited Domain to make use of the knowledge that all of them share some common procedures, such as using the routing header (6LoRH); it is then the job of the border router (6LBR) to decapsulate this form into packets that can be used in the global Internet and to appropriately encapsulate global Internet packets on the way in. (Virtual Reassembly Buffers (VRBs, ) simulate a subnet-size Limited Domain based on 's hop-by-hop ones.) This memo uses examples from the area of the Internet of Things (IoT), both because the author is most familiar with it and because a concept of self-descriptions has already been developed for this area, which provide new opportunities for organizing Limited Domains (). (To do: add more examples from outside the IoT core.)

Terminology

Limited Domain:

An area in a network that is separate from others by notable internal differences and/or by a strong administrative demarcation. Examples are found in , however this document is not limiting itself to those or to the definition in . In contrast to some other usage, the nodes in a Limited Domain are expected to normally form a connected graph, possibly by employing tunnels between them. However, not all nodes in a Limited Domain always need to be aware of their situation or implement all the internal differences.

Illustration for terms

illustrates the following additional terms:

Border:

qualifier for network elements (B) (as in "border router" etc.) that are situated on the boundary between a Limited Domain and a different one and/or the general Internet.

Internally interoperable Limited Domains:

Limited Domains that can accommodate nodes that can operate as if they were in the Internet (Z).

Globally interoperable Limited Domains:

Limited Domains that can interoperate with nodes in the global Internet (X).

Externally interoperable Limited Domains:

Limited Domains that can interoperate via the Internet (LD1), but possibly limited to interoperation with other Limited Domains (LD3) or with specially equipped Internet nodes (Limited Domains of size 1, Y logically containing a B).

Internet, Global Internet, General Internet:

(TBD, clarify usage here)

Desirable Communication All the examples so far presume an environment where it is desirable that any node can communicate with any other node. This has certainly served well as a guiding principle for quickly improving the value of a network: Leaving open the potential to communicate maximizes the potential network effect . However, firewalls are then widely used to suppress some of these potential communication paths . MUD was designed to aid routers and switches in setting up limited connectivity to this end. In the MUD architecture, we first build a system that fundamentally supports unlimited connectivity from everyone to everyone and then restrict it based on self-descriptions of the nodes. An alternative approach would be an architecture that does not provide any connectivity unless and until that is authorized by declared communication requirements that have in turn been authorized by some management entity.

Example: Addressing Desirable Peers Only There may be other reasons for pursuing an architecture that limits itself to desirable communication only. A trivial, but maybe not overly useful example would be to number all the addresses of correspondent hosts allowed by the self-descriptions and replace the IP addresses in the packets by these numbers. If this limitation becomes part of the architecture, protocols used inside the Limited Domains could completely get rid of IP addresses and use just the correspondent numbers (possibly packaged in something that looks like an IP address, but is limited in its variability to just encapsulating that number). The border router would become a NAT, but one that is acting based on extensive, precomputable information about the communication requirements inside the Limited Domain, instead of learning and potentially losing dynamic state that becomes a single point of failure. Again, this is a trivial example, but it should be sufficient as a motivation for having a look at employing knowledge about the nodes and their communication requirements in a Limited Domain for interconnecting this with the Internet (and thus possibly to like-minded (Limited Domains on the other side of an Internet path).

Self-Descriptions Note that not all of the information that may be needed as a description of Limited Domain nodes can come from MUD-like class definitions. Limited Domain nodes are instantiations of these classes, where the instantiations will differ between each other in details. Different Limited Domain nodes may also be assigned a different purpose in life, causing a need to further parameterize the self-description. Alongside a discussion of an interconnection architecture that can make use of self-descriptions would therefore need to be a discussion on how to structure self-description classes with this purpose in mind and how to parameterize these and derive description instances. For the Internet of Things (IoT), additional self-description techniques have been defined that can provide information for Limited Domain network elements. A fully instance-oriented description of an IoT device is provided by a W3C WoT (Web of Things) Thing Description . W3C WoT is presently in the process of adding a class-based description technique to TDs, the Thing Model (previously called Thing Description Template, TDT) . The communication patterns offered by the device are detailed in Protocol Bindings, which can contain URIs combined with protocol-specific vocabulary (, currently defined for HTTP, CoAP, MQTT). An experimental extension to TDs that enables deriving the configuration of Time-Sensitive Networking (TSN) networks from the self-description is described in . An IoT-oriented description technique that, unlike TD, is class-based from the outset is the Semantic Definition Format (SDF) for Data and Interactions of Things . A concept similar to WoT Protocol Bindings is not defined yet, but a combination of MUD and SDF descriptions could provide a basic description of a device situated in a Limited Domain. The Constrained RESTful Environments (CoRE) architecture also provides instance-oriented self-descriptions in the form of the CoRE Link Format , an instance of which is provided by each CoAP server under /.well-known/core. Link-format information, as well as self-describing information in the newer CoRAL format , can be stored in the CoRE Resource Directory . All these potential sources of (self-)description only provide meager information about purpose-in-life, i.e., beyond the intrinsic properties of the device. Obtaining a full description of the communication requirements of a node (including its desirable correspondence nodes) will therefore require additional input, beyond the class-based self-descriptions of the devices.

Directions of Work The above discussion leads us to the following interrelated areas for further exploration:

1. Extending the self-description mechanisms to provide more information that may be useful in a Limited Domain.
2. Merging the self-description information with other configuration/management information (such as purpose-in-life) that may be available for the Limited Domain.
3. Defining Limited Domain architectures that can benefit from information made available by (1) and (2), including defining the operation of network elements and nodes inside the Limited Domain.
4. Defining border network element functionality that makes such a Limited Domain a Globally Interoperable Limited Domain.
5. Defining border network element functionality that makes such a Limited Domain an Externally Interoperable Limited Domain.
6. Discovery between Limited Domains, between Limited Domain nodes (Rendezvous problem); establishment of communications (cf. ).
7. Defining appropriate security workflows and the supporting security mechanisms for items to .
8. Addressing operational considerations for items to .
9. Addressing privacy considerations for items to .

IANA Considerations This document contains no requests to IANA.

Security Considerations The security considerations of apply. Item of raises the need for security work, one example of which might be: Self-descriptions of nodes in many cases need to undergo an authorization process before they can be used as the basis of network configuration. The authorization process sketched by may be too simplistic, in particular the simplified number of stakeholders assumed. The present document is not providing answers in this space, but needs to raise the issue.

Informative References This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK] The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK] This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications. This document provides generic rules to enable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (VRBs). This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. ARM The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as a compact serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata. PassiveLogic Universität Bremen TZI The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models in the Internet of Things. An SDF specification describes definitions of SDF Objects and their associated interactions (Events, Actions, Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed. // A JSON format representation of SDF 1.0 was defined in version // (-00) of this document; version (-05) was designated as an // _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of // the ASDF WG (2021-03-11). The present version (-12) collects // smaller changes up to 2022-06-30. It also removes deprecated // elements from SDF 1.0. (Link errors corrected 23 June 2020) University of Bologna, Bologna, Italy Huawei Technologies, Munich, Germany Huawei Technologies, Munich, Germany The University of Auckland University of Cambridge Huawei

Acknowledgments Adrian Farrel provided substantive comments as well as the basis for .