CoRE A. Brandt Internet-Draft Sigma Designs Intended status: Experimental March 7, 2011 Expires: September 8, 2011 Discovery of CoAP servers across subnets draft-brandt-coap-subnet-discovery-00 Abstract The document describes the process of discovering CoAP servers distributed in multiple subnets in a non-specified topology. CoAP Discovery Gateways are used to discover one subnet from another. CoAP Discovery Gateways may provide caching to enable discovery of sleeping nodes in LLN environments. The solution scales to large installations since discovery is handled by the client in an incremental fashion. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 8, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Brandt Expires September 8, 2011 [Page 1] Internet-Draft CoAP Subnet Discovery March 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Requirements for Discovery services for very constrained nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Home Control network evolution - scenarios . . . . . . . . 4 2.1.1. Scenario A: Retail home control starter kit . . . . . 4 2.1.2. Scenario B: Service provider home control offering . . 5 2.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Zero-Configuration . . . . . . . . . . . . . . . . . . . . 6 2.4. Multiple unique routable subnets . . . . . . . . . . . . . 7 3. Building blocks of a CoAP Discovery infrastructure . . . . . . 7 3.1. Stand-alone CoAP Server . . . . . . . . . . . . . . . . . 8 3.2. CoAP Discovery Gateway . . . . . . . . . . . . . . . . . . 8 3.3. Caching CoAP Discovery Gateway . . . . . . . . . . . . . . 8 3.4. CoAP Discovery Client . . . . . . . . . . . . . . . . . . 9 4. CoAP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Topology Path String definitions . . . . . . . . . . . 11 4.1.2. ?n=DiscoveryGateway . . . . . . . . . . . . . . . . . 13 4.1.3. Discovering Gateway interfaces - an example . . . . . 13 4.2. Initial Topology Discovery . . . . . . . . . . . . . . . . 13 4.3. Incremental Topology Discovery . . . . . . . . . . . . . . 14 4.3.1. Multicast domain behind routers . . . . . . . . . . . 14 4.4. CoAP Server Discovery . . . . . . . . . . . . . . . . . . 15 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Discovery across CoAP Discovery Gateways . . . . . . . . . 15 5.2. /topology path formats . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 A.1. Large reports . . . . . . . . . . . . . . . . . . . . . . 20 A.2. M2M Filtering . . . . . . . . . . . . . . . . . . . . . . 20 A.3. Routable subnets . . . . . . . . . . . . . . . . . . . . . 21 A.4. Compressing responses from caching CoAP Discovery Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.5. Integrated Battery support . . . . . . . . . . . . . . . . 21 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Brandt Expires September 8, 2011 [Page 2] Internet-Draft CoAP Subnet Discovery March 2011 1. Introduction This document describes the process of discovering CoAP servers distributed in multiple subnets in a non-specified topology. CoAP (Constrained object Application Protocol) Discovery Gateways are used to discover one subnet from another. CoAP Discovery Gateways may provide caching to enable discovery of sleeping nodes in Low-power and Lossy Network (LLN) environments. Caching CoAP Discovery Gateways may also have the purpose of preserving bandwidth in an LLN environment. No synchronization of databases is required. The solution scales to large installations since discovery is handled by the client in an incremental fashion. CoAP servers may be running on a variety of physical layers; each implementing a subnet. A lamp module may be running over IEEE 802.15.4. A movement sensor may be running over Z-Wave. The document presents requirements to a home control discovery solution and proposes a solution based on the CoAP link format [I-D.ietf-core-link-format]. CoAP Subnet Discovery Must support IPv6. An implementation MAY implement support for both IPv4 and IPv6 . 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Requirements for Discovery services for very constrained nodes The term constrained node covers a range of nodes that are constrained with regards to memory size, power consumption, packet size or CPU capabilities. This document covers nodes for applications within home control and building control. A Low-power Lossy Network (LLN) is used for communication. The basic functionality of devices for home control and building control is the same: measure temperature, detect movement, dim light, operate locks, etc. The discovery, management and operation of networks is however somewhat different. This document addresses discovery requirements specific to the most constrained devices and outlines how proper solutions may address home control and building control technologies in the same way. Brandt Expires September 8, 2011 [Page 3] Internet-Draft CoAP Subnet Discovery March 2011 2.1. Home Control network evolution - scenarios Home control systems may be constructed from consumer products acquired in a retail store. The products may come from multiple vendors. The user may have no knowledge of network management. The user may have no existing local network. If there is a local network, it may have no DHCP or DNS infrastructure. Devices must always work; the consumer price level does not leave much margin for support hotlines. The following scenarios assume one common application protocol. Multi-protocol support may be achieved via application gateways; potentially with CoAP as the common language. This is out of scope of this document. 2.1.1. Scenario A: Retail home control starter kit This scenario outlines how LLN nodes may be used in the most simple network configurations and how such simple networks may grow from there. In such simple networks the 6LoWPAN border router is reduced to a conceptual function. The remote control acts as a coordinating master node on the link layer as well as a 6LoWPAN border router. The remote control enters a sleep state when it is not in use. 1. Starter kit bring-up A user starts with an RF remote control and three RF plug-in modules. The remote control assigns unique link-layer addresses and ULA IP addresses [RFC4193] to modules during network bootstrapping so that the remote control and the plug-in modules are in the same IP network. ULA IP addresses are needed as multi-hop routing may be used inside the LLN network. Prefixes and header compression CIDs have infinite lifetime as there is no listening border router. Remote control buttons are mapped to (groups of) IP addresses of the plug-in modules. The setup mode may be activated via a special key sequence in the remote control. 2. Adding sensors The user adds another plug-in module and a movement sensor to the network. The remote control is still used as a coordinating master node. The IP address of the target module is stored in the movement sensor. When the sensor detects a movement, it sends an "ON" command to the plug-in module. Brandt Expires September 8, 2011 [Page 4] Internet-Draft CoAP Subnet Discovery March 2011 3. Adding home control to the smart phone The user adds a border router to interface the LLN network to the LAN (and WiFi) of the house. The user connects a smartphone to the WiFi network. A home control smartphone app performs home control resource discovery. A list of LLN nodes allows the user to configure smartphone widgets for scene control of lamps; e.g. "Watch TV" or "Doing the dishes". 2.1.2. Scenario B: Service provider home control offering In this scenario, a consumer receives a pre-bundled kit from a service provider: o A combined internet access router and LLN border router with WiFi support o Three plug-in modules for installation in the home o A personal web profile on the service provider web portal o A smartphone app for control via WiFi Remote access credentials, LLN prefix and other parameters are preconfigured by the service provider. 1. Setting up the kit The LLN border router manages link-layer node properties as well as prefix assignment, etc. A web page is used to add the three plug-in modules to the LLN. The smartphone app controls the plug-in modules via WiFi. Routable addresses allow the app to reach the modules from the WiFi subnet. 2. Adding other technologies The original starter kit was a wireless LLN. The user connects a power-line LLN border router to the LAN, thus forming a backbone network for the two LLN border routers. The user includes power- line based plug-in modules with the new power-line LLN border router. Each individual border router manages local ULA prefixes and header compression CIDs. 3. Re-discovering the network The smartphone app rediscovers home control resources in both Brandt Expires September 8, 2011 [Page 5] Internet-Draft CoAP Subnet Discovery March 2011 LLNs and the backbone network. The lists of home control resources allow the user to configure smartphone widgets for scene control of lamps in both subnets. The border routers runs a routing protocol on the backbone to allow IP packets to traverse from one subnet into the other without any manual configuration of routers. 2.2. Discovery Discovery serves multiple purposes in a home control network: 1. When the home control network has grown from the original starter kit to a substantial number of nodes, the owner may get a desire for centralized management of the network. The management tool needs a way to request information from each node in the network. Typically, nodes will carry no visible identification at this time. If possible, non-functioning nodes should also be identified. Once nodes are identified, the user may locate the nodes physically and assign naming and location information, e.g. "bedroom, ceiling light" or "living room, drapes". 2. When setting up a remote control, the user may want to browse all drape controllers in the entire network - both in the wireless LLN and in the powerline LLN. The wireless drape controllers may be battery powered and sleeping most of the time. The powerline drape controllers may be in a dedicated powerline LLN subnet behind several border routers. It is a challenge to discover nodes in other subnets. A multicast-based discovery protocol like mDNS cannot have its messages forwarded by routers since it uses link-local addressing. Even if mDNS messages could be forwarded, some LLNs featuring multi-hop routing do only support multicast in a very slow and inefficient fashion. Assuming multicast messages could be distributed over a LLN, sleeping nodes would not be able to detect discovery requests. A solution is required which o Does not flood the LLN with unnecessary discovery traffic o Does not require multicasting in LLNs o Does allow the discovery of sleeping nodes 2.3. Zero-Configuration One major property of home control networks is the absence of a professional installer. When making consumer products, one cannot make any assumptions about the qualifications of the user. Simple Brandt Expires September 8, 2011 [Page 6] Internet-Draft CoAP Subnet Discovery March 2011 operation is a requirement. As an example, a user may associate a light module by activating a setup sequence on a wall switch and then pushing a button on the light module. The user never sees any data. Most users actually do not care about the IP address of the light module. No border router, DHCP server or DNS server is present in a starter kit network. Modules that were initially purchased and configured with a remote control may one day be used in a far more advanced installation with global routable prefixes and hierarchical DNS naming. 2.4. Multiple unique routable subnets Home control domains may be composed of devices communicating via one or more border routers, e.g power-line to wireless, optionally via a backbone network. A wireless home control LLN may in itself contain routers to do multihop forwarding within the home control LLN. The two subnets may host different MAC/PHYs as well as different routing protocols. The user can extend the home control starter kit with another subnet without having to re-install the original subnet. The construction of unique local subnet prefixes is described in[RFC4193]. 3. Building blocks of a CoAP Discovery infrastructure CoAP defines a protocol for exchange of requests and commands between constrained nodes. Already described in [I-D.ietf-core-coap], the CoAP Server is a host capable of responding to CoAP messages. CoAP Servers may be classified into the following sub-types: o Stand-alone CoAP Server o CoAP Discovery Gateway o Caching CoAP Discovery Gateway These are described in the following sections. Finally, the CoAP Discovery Client is described. CoAP Discovery Gateways MAY advertise legacy devices along with native CoAP servers. CoAP Discovery Gateways MAY provide access to legacy services via CoAP request and control messages. Discovery of diverse resource types enables a migration path from legacy technologies towards an all-CoAP infrastructure. Brandt Expires September 8, 2011 [Page 7] Internet-Draft CoAP Subnet Discovery March 2011 3.1. Stand-alone CoAP Server A stand-alone CoAP Server does not provide access to other CoAP Servers; physical or logical. Typically a stand-alone CoAP Server is able to perform some action, e.g. measuring a temperature or turning on light. A CoAP Server reports periodically to the Discovery Gateway via the 6LoWPAN ND address registration process, e.g. once every hour. Battery operated CoAP servers may run out of battery. Light modules may become defect. The reporting allows the Discovery gateway to monitor the availability of CoAP Servers. 3.2. CoAP Discovery Gateway A CoAP Discovery Gateway is a CoAP enabled router interconnecting different subnets, e.g. a LLN Border Router. The subnets may host stand-alone CoAP Servers as well as other CoAP Discovery Gateways. Each CoAP Discovery Gateway interface MUST respond to the CoAP Discovery request "GET /.well-known/core?n=DiscoveryGateway". When queried, the gateway MUST report all other interfaces maintained by the discovery gateway. The Discovery Gateway MAY maintain a list of CoAP Servers that recently stopped sending address registrations. How a CoAP Discovery Gateway is to advertize such CoAP Servers is TBD. 3.3. Caching CoAP Discovery Gateway A Caching CoAP Discovery Gateway performs caching of discovery information on behalf of other nodes in a given subnet. A discovery gateway interface MUST respond to the CoAP Discovery request "GET /.well-known/core?n=DiscoveryGateway". When queried, the discovery gateway MUST report all other interfaces maintained by the discovery gateway. The gateway MUST indicate if respective interfaces are of the type "CoAP Discovery Gateway" or "Caching CoAP Discovery Gateway". This information MAY be be ignored by a discovery client. CoAP Servers reporting to a Caching CoAP Discovery Gateway MAY respond to CoAP Discovery requests. A Caching CoAP Discovery Gateway MUST intercept discovery requests and respond on behalf of CoAP Servers. This allows sleeping nodes to be discovered, saves LLN bandwidth and allows the Caching CoAP Discovery Gateway to maintain connectivity state information like "online/offline/unstable" per CoAP server. The Caching CoAP Discovery Gateway MAY maintain a list of CoAP Servers that recently stopped sending address registrations. How a CoAP Discovery Gateway is to advertize such CoAP Servers is TBD. Brandt Expires September 8, 2011 [Page 8] Internet-Draft CoAP Subnet Discovery March 2011 +--------------------------------+ | Caching CoAP Discovery Gateway | | | +---------------------+ +---------------------+ |Caching Interface | |non-caching Interface|- - + |2001:1001::1 | |2001:1002::1 | +---------------------+ +---------------------+ | | | +--------------------------------+ | other CoAP Servers in this subnet Figure 1: Caching CoAP Discovery Gateway A Caching CoAP Discovery Gateway MAY report that it is a (non- caching) CoAP Discovery Gateway on some interfaces; refer to Section 3.2 . The device type "Caching CoAP Discovery Gateway" only indicates that discovery information is cached. Caching of real-time data from CoAP servers is out of scope of this document. A Caching CoAP Discovery Gateway SHOULD NOT interfere with any other traffic than Discovery Requests for Discovery Gateways or the capabilities of CoAP Servers which report to the CoAP Discovery Gateway, e.g. "Device type = Thermostat". A Caching CoAP Discovery Gateway MUST NOT cache any changing parameters. 3.4. CoAP Discovery Client A CoAP Discovery Client uses the CoAP Discovery request "GET /.well- known/core?n=DiscoveryGateway" to initiate a discovery session. The target for the discovery request depends on the properties of the actual network. Two cases apply: 1. Client is in a LLN domain with no multicast support The initial request is sent to the Authoritative Border Router of that LLN. 2. Client is in a link-local subnet domain with multicast support (like Ethernet) The initial request is transmitted to the link-local "all- routers" multicast address. Brandt Expires September 8, 2011 [Page 9] Internet-Draft CoAP Subnet Discovery March 2011 If discovery requests cause CoAP Discovery Gateways to announce other CoAP Discovery Gateways in other subnets, additional discovery requests are directed to those CoAP Discovery Gateways. A Discovery Client may run in remote controls, smart phone apps or central management systems for home automation or building control. The discovery process depends on the presence of a CoAP discovery gateway in the subnet of the discovery client. Since CoAP subnet discovery uses normal CoAP messages, link-local discovery works "out of the box" in link-local enabled environments. Refer to [I-D.ietf-core-link-format]. 4. CoAP Discovery CoAP Discovery is a hierarchical process and involves two phases: CoAP Topology Discovery and CoAP Server Discovery. The purpose of the Topology Discovery phase is to establish a snapshot of the available CoAP Discovery Gateways. CoAP messages are used to discover CoAP Discovery Gateways in a hierarchical fashion. Having completed the topology discovery phase, a CoAP client may initiate discovery of particular CoAP server resources, e.g. light dimmers, or a more general wildcard discovery may be done by the client; building a complete database. The same request MUST be sent to each discovered CoAP Discovery Gateway interface in a sequential fashion. The information may be presented, e.g. in lists of different device types. CoAP subnet discovery enables access to end nodes in multiple subnets without any manual configuration of routers. The topology discovery process may return information on Caching CoAP Discovery Gateways. Caching CoAP Discovery Gateways allow the discovery of sleeping and defective nodes but require that CoAP clients implement 6lowPAN-ND address registration [I-D.ietf-6lowpan-nd]with the Authoritative Border Router. Management and naming related issues of CoAP servers in building control are discussed in [I-D.vanderstok-core-bc]. CoAP Discovery depends on the ability to traverse subnets. Thus, all CoAP Servers MUST have routable IPv6 addresses; either in global prefixes or according to ULA principles. The border router is typically the physical device implementing the CoAP Discovery Gateway function in a LLN. This specification collapses the address of the default gateway (border router) and the discovery gateway in order to limit the number of IP addresses that LLN nodes have to manage - and Brandt Expires September 8, 2011 [Page 10] Internet-Draft CoAP Subnet Discovery March 2011 to avoid having to distribute the address of the CoAP Discovery Gateway in LLNs. RAs already convey the IP address of the default gateway. 4.1. Topology Discovery A client may be anywhere in the topology when initiating the Topology Discovery. Any topology may be traversed (if allowed by firewall policies in border routers). The discovery process allows a client to discover CoAP servers according to the classification described in Section 3. 4.1.1. Topology Path String definitions A CoAP Discovery Gateway or caching CoAP Discovery Gateway MUST support the following CoAP messages: o GET /.well-known/core?n=DiscoveryGateway o GET /.well-known/core/topology o GET /.well-known/core/topology/device o GET /.well-known/core/topology/interfaces o GET /.well-known/core/topology/servers 4.1.1.1. /topology/device A CoAP Discovery Gateway MUST report one of the device types listed in Figure 2. +----------+---------------------+----------------------------------+ | Device | Label | Interpretation | | type | | | +----------+---------------------+----------------------------------+ | 1 | Discovery Gateway | This is a CoAP Discovery Gateway | | | | interface | | 2 | Discovery Gateway, | This CoAP Discovery Gateway | | | caching | interface is caching | +----------+---------------------+----------------------------------+ Figure 2: CoAP Discovery Device Types The report formats are described in the following sections. Brandt Expires September 8, 2011 [Page 11] Internet-Draft CoAP Subnet Discovery March 2011 4.1.1.2. /topology/interfaces A CoAP Discovery Gateway MUST return the structure [interface address_1] ... [interface address_n] in response to a query for /topology/interfaces. The processing of a discovery request depends on the receiving interface: If the request is targeting the gateway interface that physically received the request, the response contains all subnet interfaces of the discovery gateway. If the request is targeting another gateway interface than the gateway interface that physically received the request, the response contains all discovery gateways known to the subnet of the targeted interface. 4.1.1.3. /topology/servers A Caching CoAP Discovery Gateway MUST return the structure [server address_1] ... [server address_n] in response to a query for /topology/servers. If the request is targeting the gateway interface that physically received the request, the response contains the identity of known CoAP Servers that report to this Caching CoAP Discovery Gateway interface. If the request is targeting another gateway interface than the gateway interface that physically received the request, a (non- caching) CoAP Discovery Gateway interface in a subnet supporting multicast MUST issue a multicast request for all CoAP Servers in response to a query for /topology/servers. The individual CoAP Server responses are returned directly to the requesting discovery Client. Brandt Expires September 8, 2011 [Page 12] Internet-Draft CoAP Subnet Discovery March 2011 4.1.2. ?n=DiscoveryGateway A CoAP Discovery Gateway MUST report the path /topology in response to ?n=DiscoveryGateway. A CoAP Discovery Gateway MAY report other paths as well. 4.1.3. Discovering Gateway interfaces - an example The query string ?n=DiscoveryGateway is used for discovering topology information in a CoAP enabled infrastructure. [Client sends multicast request to WiFi subnet] | CoAP GET /.well-known/core?n=DiscoveryGateway [LLN Border Router responds] | 200 OK | | core://2001:.../topology/device;ct=0;n="DiscoveryGateway" [Client sends unicast request to the responding CoAP Discovery Gateway] [(LLN border router)] | CoAP GET /.well-known/core/topology/interfaces [LLN Border Router responds] | 200 OK | | 2001:0db8:85a3:beef:0000:8a2e:0370:7334 | 2001:0db8:85a3:babe:0000:8a2e:0370:4321 It is seen that the initial Discovery Gateway request only returns a single string: "/topology/device/...". Since the path "/topology/ interfaces" is mandatory for CoAP Discovery Gateways, the client may request this structure as soon as it has detected the CoAP Discovery Gateway. 4.2. Initial Topology Discovery A Topology Discovery operation is initiated by a CoAP client with the CoAP message GET /.well-known/core?n=DiscoveryGateway in one of the following ways. 1. If a client resides in a multicast enabled environment (like Ethernet or WiFi) the client issues a multicast message (as described in [I-D.ietf-core-link-format] ) to the "all nodes" address. All on-link CoAP Discovery Gateways MUST respond to the GET message by returning a list of other interfaces of the respective CoAP Discovery Gateways. In order to avoid collisions, the responding CoAP Discovery Gateways MUST insert a 0..MAX_RA_DELAY_TIME [I-D.ietf-6lowpan-nd] random delay before Brandt Expires September 8, 2011 [Page 13] Internet-Draft CoAP Subnet Discovery March 2011 responding. 2. If a discovery client resides in a LLN environment (like IEEE 802.15.4 or Z-Wave) the client issues a unicast message to the border router of the LLN. The default border router of the LLN MUST respond to a CoAP Discovery request by returning a list of other interfaces of that particular CoAP Discovery Gateway. The discovery client builds a list of reported subnets that it has to discover. Duplicates MUST be omitted. 4.3. Incremental Topology Discovery The client holds a list of reported discovery gateway subnets that it has to discover; either from the Initial Topology Discovery or from a previous Topology Discovery. For each subnet interface, the client sends a unicast GET /.well- known/core?n=DiscoveryGateway message to the interface. In its default configuration, a CoAP Discovery Gateway MUST return the address of each remote interface. A CoAP Discovery Gateway MAY be configured to return URIs for identification. CoAP Discovery MUST support zero-configuration environments like home control where no DNS server can be assumed. 4.3.1. Multicast domain behind routers If a discovery client initiates discovery from a LLN environment, it may reach a backbone router interface residing in a multicast enabled network domain such as Ethernet. When a CoAP Discovery Gateway receives a unicast discovery request for a multicast enabled network interface via another discovery gateway interface, that CoAP Discovery Gateway interface MUST forward the discovery request in a multicast message for the "all nodes" multicast address. The discovery client MUST ignore a reported Discovery Gateway interface if that interface is already in the list of known Discovery Gateway interfaces. This is to prevent loops. A discovery client MAY perform hierarchical discovery by using the general /.well-known/core path. This combines the topology and server discovery phases. The downside is that a client may receive large amounts of data for each individual discovery message. This may be a problem for memory constrained nodes. By discovering the gateway topology first and using filtered server discovery, a client may achieve significant reductions in received data. Brandt Expires September 8, 2011 [Page 14] Internet-Draft CoAP Subnet Discovery March 2011 4.4. CoAP Server Discovery CoAP Server Discovery builds on network information revealed during topology discovery. Each discovered subnet must be discovered individually. As an example, if a client connected to a backbone has discovered two LLNs behind two border routers, the client must perform CoAP Server discovery in the backbone (on-link subnet) as well as each of the two LLN interfaces. 5. Examples 5.1. Discovery across CoAP Discovery Gateways Consider the following network environment: The client is located in LAN2. The discovery process has to traverse CoAP Discovery Gateway GW4 and LAN1 to locate CoAP Discovery Gateways GW1, GW2 and GW3. CoAP Discovery Gateways 1, 2 and 3 also have to be traversed. When no more new CoAP Discovery Gateways are discovered, discovery for CoAP Servers can be initiated. +-------+ A, B --- PAN1| GW1 |LAN1 -+ PAN1 +-------+ | | +-------+ | +-------+ C, D --- PAN2| GW2 |LAN1 -+- LAN1| GW4 |LAN2 --- LAN2 PAN2 +-------+ | +-------+ client | +-------+ | E, F --- PAN3| GW3 |LAN1 -+ PAN3 +-------+ Figure 3: Discovery across CoAP Discovery Gateways Brandt Expires September 8, 2011 [Page 15] Internet-Draft CoAP Subnet Discovery March 2011 Client | GW4 | GW1 | GW2 | GW3 LAN2 | LAN2 LAN1 | LAN1 PAN1 | LAN1 PAN2 | LAN1 PAN3 | | | | 1) ------X GET ?n=DiscoveryGateway (mcast) | | | | 2) <------ "GW4LAN1" | | | | 3) --------------> GET ?n=DiscoveryGateway | | | | 4) -------X-------------X-------------X GET (mcast) | | | | 5) <-------------------- "GW1PAN1" ^ | | | | 0..2s | <---------------------------------- "GW2PAN2" | | | | | | <------------------------------------------------ "GW3PAN3" v | | | | 6) ----------------------------> GET ?n=DiscoveryGateway | | | | 7) <---------------------------- "" | | | | 8) ------------------------------------------> GET ?n=Disco... | | | | 9) <------------------------------------------ "" | | | | 10) ---------------------------------------------------------> GET | | | | 11) <--------------------------------------------------------- "" Figure 4: CoAP Discovery Process 1. The client sends out a multicast "GET /.well-known/ core?n=DiscoveryGateway" 2. GW4 reports its other interfaces (GW4LAN1). 3. The client sends "GET /.well-known/core?n=DiscoveryGateway" to GW4LAN1 4. GW4LAN1 is not caching and received request in unicast => "GET /.well-known/core?n=DiscoveryGateway" is forwarded as multicast 5. Reports received from GW1LAN1, GW2LAN1 and GW3LAN1 within 2 seconds. 6. The client sends "GET /.well-known/core?n=DiscoveryGateway" to GW1PAN1 Brandt Expires September 8, 2011 [Page 16] Internet-Draft CoAP Subnet Discovery March 2011 7. GW1PAN1 reports that no other gateways were found in PAN1 8. The client sends "GET /.well-known/core?n=DiscoveryGateway" to GW2PAN2 9. GW1PAN1 reports that no other gateways were found in PAN2 10. The client sends "GET /.well-known/core?n=DiscoveryGateway" to GW3PAN3 11. GW1PAN1 reports that no other gateways were found in PAN3 The client now has the following list of CoAP Discovery Gateway interfaces in unique subnets: 1. (mcast in on-link subnet) 2. GW4LAN1 3. GW1PAN1 4. GW2PAN2 5. GW3PAN3 The client may now issue searches for other CoAP Servers by sending the request "GET /.well-known/core" to each CoAP Discovery Gateway in the list. 5.2. /topology path formats Figure 5 shows an example of a client sending a request for /.well- known/core/topology?n=DiscoveryGateway. The discovery gateway sends back a response with the matching resources in the payload. DISCOVERY CLIENT GATEWAY | | |--CON+GET /.well-known/core?n=DiscoveryGateway [TID=42]-->| | | | <----- ACK + 200 OK [TID=42, CT=0] ------ | Payload: ;sh="/??";ct=0;n="DiscoveryGateway" Figure 5: Looking for CoAP Discovery Gateways Figure 6 shows an example of a client sending a request for /.well- known/core/topology/interfaces. The discovery gateway sends back a response with the actual interfaces provided by the CoAP Discovery Brandt Expires September 8, 2011 [Page 17] Internet-Draft CoAP Subnet Discovery March 2011 Gateway. A CoAP Discovery Gateway MUST implement the path /topology/ interfaces. DISCOVERY CLIENT GATEWAY | | |--CON+GET /.well-known/core/topology/interfaces[TID=44]-->| | | | <----- ACK + 200 OK [TID=44, CT=0] ------ | Payload: 2001:0db8:85a3:beef:0000:8a2e:0370:7334 2001:0db8:85a3:babe:0000:8a2e:0370:4321 Figure 6: Using the "/topology/interfaces" path Figure 7 shows an example of a client sending a request for /.well- known/core/topology/interfaces to a caching CoAP Discovery Gateway. The discovery gateway sends back a response with the actual interfaces provided by the CoAP Discovery Gateway. Subsequently, the client may sending a request for /.well-known/core/ topology/servers to get a list CoAP servers known by the Caching CoAP Discovery Gateway. This list includes sleeping and FLN nodes. DISCOVERY CLIENT GATEWAY | | |--CON+GET /.well-known/core/topology/interfaces[TID=45]-->| | | | <----- ACK + 200 OK [TID=45, CT=0] ------ | Payload: 2001:0db8:85a3:beef:0000:8a2e:0370:7334 Figure 7: Receiving addresses from a caching CoAP Discovery Gateway Figure 8 shows an example of a client sending a request for /.well- known/core/topology/servers to a caching CoAP Discovery Gateway. The discovery gateway sends back a response with the CoAP Servers known by the Caching CoAP Discovery Gateway. In this case the Caching CoAP Discovery Gateway reports legacy devices which do not necessarily speak CoAP. The client may need to implement multiprotocol support in order to communicate to the devices. Brandt Expires September 8, 2011 [Page 18] Internet-Draft CoAP Subnet Discovery March 2011 DISCOVERY CLIENT GATEWAY | | |--CON+GET /.well-known/core/topology/servers[TID=46]-->| | | | <----- ACK + 200 OK [TID=46, CT=0] ------ | Payload: Figure 8: Advertising legacy devices via CoAP Discovery A more advanced CoAP application gateway may provide translation between legacy protocols and CoAP. This is out of scope of this document. 6. IANA Considerations This document has no actions for IANA. 7. Security Considerations If a CoAP Discovery Gateway receives a generalized CoAP GET /.well- known/core message and that interface resides in a multicast enabled environment such as Ethernet, the CoAP Discovery Gateway forwards that CoAP request in an "all nodes" multicast message. In response, the CoAP Discovery Gateway potentially receives messages from a number of CoAP Discovery Gateways connected to that link. Forwarding all responses back to the requesting client in individual messages MAY be used for an amplification attack. Coap discovery is not intended for Internet-wide operation. An internet access router SHOULD NOT forward CoAP messages to or from the Internet domain unless there is a specific application need for doing so. CoAP Discovery depends on a secure perimeter. So does many of the LLN nodes which this discovery mechanism is targeting. Triggering an amplification attack requires that an attacker has access to the LAN or has control over LLN nodes. If the LLN implements link-layer security, an attacker cannot simply inject a wireless packet. If, however, one is within radio range of a LLN, a modified microwave oven may be a more efficient jamming tool than an amplification attack. 8. References Brandt Expires September 8, 2011 [Page 19] Internet-Draft CoAP Subnet Discovery March 2011 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4193] "Unique Local IPv6 Unicast Addresses", October 2005. 8.2. Informative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-04 (work in progress), January 2011. [I-D.ietf-core-link-format] Shelby, Z., "CoRE Link Format", draft-ietf-core-link-format-02 (work in progress), December 2010. [I-D.vanderstok-core-bc] Stok, P. and K. Lynn, "CoAP Utilization for Building Control", draft-vanderstok-core-bc-02 (work in progress), October 2010. [I-D.ietf-6lowpan-nd] Shelby, Z., "Neighbor Discovery Optimization for Low-power and Lossy Networks". [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. Appendix A. Open Issues A.1. Large reports The CoAP Block transfer mode MUST be implemented in order to support large reports, e.g. from a caching CoAP Discovery Gateway responding on behalf of 100's of CoAP Servers in an LLN. A.2. M2M Filtering The document describes the use of ?n=DiscoveryGateway for detecting CoAP Discovery Gateways. It should be considered if dedicated codes or keywords should be assigned. M2M applications will benefit from shorter codes and avoid the ambiguity of the free text allowed for '?n='. Brandt Expires September 8, 2011 [Page 20] Internet-Draft CoAP Subnet Discovery March 2011 A.3. Routable subnets CoAP Discovery requires that all CoAP subnets are all reachable from a given subnet. Some application spaces, e.g. DIY home control, may be set up as off-the-shelf boxes with auto-assigned IPv6 subnets [RFC4193] with no route entries to other subnets. RIPng [RFC2080] is considered sufficient for a home control application space. Larger installations for building control and the like are expected to be managed networks. The following requirements could ensure successful plug-and-play behavior when combining Border Routers with CoAP Discovery Gateways from different vendors: o A CoAP Discovery Gateway MUST support RIPng o RIPng SHOULD be enabled in all CoAP Discovery Gateways o A CoAP Discovery Gateway MAY implement other routing protocols A.4. Compressing responses from caching CoAP Discovery Gateways A caching CoAP Discovery Gateway SHOULD omit leading bytes of each reported address if the addresses are all in the same subnet served by the CoAP Discovery Gateway. If omitting leading bytes, a responding CoAP Discovery Gateway MUST provide the prefix information that was omitted from the reported addresses. If no prefix is specified the interface identifiers MUST be full IP addresses or URIs. A Caching CoAP Discovery Gateway MAY return more than one response message. If compression is used all addresses in a response message MUST belong to the same subnet prefix. A.5. Integrated Battery support A caching CoAP Discovery Gateway MAY be integrated into a LLN border router. This allows for tight integration of support services for sleeping nodes. The Caching CoAP Discovery Server allows sleeping nodes to be discovered. The border router may implement mailbox delivery services for sleeping nodes. The border router may return "Destination Responding Slowly" ICMP messages to IP hosts sending to a sleeping node. The purpose of the ICMP message is to prevent IP applications from resending messages because they are not receiving Brandt Expires September 8, 2011 [Page 21] Internet-Draft CoAP Subnet Discovery March 2011 application acks. A distributed routing protocol MAY distribute the mailbox services. This is out of scope of this specification. Appendix B. Acknowledgements Special thanks to Klaus Hartke, Peter Bigot, Peter van der Stok, Kerry Lynn and Zach Shelby for substantial contributions to the ideas and text in the document. Author's Address Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen O DK-2100 DENMARK Phone: +4529609501 Email: abr@sdesigns.dk Brandt Expires September 8, 2011 [Page 22]