One document matched: draft-brandt-coap-subnet-discovery-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5826 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5826.xml">
<!ENTITY RFC2080 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2080.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-coap-04.xml">
<!ENTITY I-D.vanderstok-core-bc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-vanderstok-core-bc-02.xml">
<!ENTITY I-D.ietf-core-link-format SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-link-format-02.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!--used by XSLT processors -->
<!--For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!--Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc toc="yes" tocompact="yes" tocdepth="3" tocindent="yes" symrefs="yes" sortrefs="no" comments="yes" inline="yes" compact="yes" subcompact="no"?>
<rfc category="exp" docName="draft-brandt-coap-subnet-discovery-00"
ipr="trust200902">
<front>
<title abbrev="CoAP Subnet Discovery">Discovery of CoAP servers across
subnets</title>
<author fullname="Anders Brandt" initials="A." surname="Brandt">
<organization>Sigma Designs</organization>
<address>
<postal>
<street>Emdrupvej 26A, 1.</street>
<city>Copenhagen O</city>
<code>DK-2100</code>
<country>DENMARK</country>
</postal>
<phone>+4529609501</phone>
<email>abr@sdesigns.dk</email>
</address>
</author>
<date month="March" year="2011" />
<area>Internet</area>
<workgroup>CoRE</workgroup>
<keyword>sensor network</keyword>
<keyword>CoAP</keyword>
<keyword>topology</keyword>
<keyword>Discovery</keyword>
<keyword>subnet</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>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.</t>
<t>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.</t>
<t>The document presents requirements to a home control discovery
solution and proposes a solution based on the CoAP link format <xref
target="I-D.ietf-core-link-format"></xref>.</t>
<t>CoAP Subnet Discovery Must support IPv6. An implementation MAY
implement support for both IPv4 and IPv6 .</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section title="Requirements for Discovery services for very constrained nodes">
<t>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.</t>
<t>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.</t>
<section title="Home Control network evolution - scenarios">
<t>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.</t>
<t>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.</t>
<section title="Scenario A: Retail home control starter kit">
<t>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.</t>
<t><list style="numbers">
<t>Starter kit bring-up<vspace blankLines="1" />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 <xref target="RFC4193"></xref> 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.<vspace
blankLines="0" />Prefixes and header compression CIDs have
infinite lifetime as there is no listening border router.<vspace
blankLines="1" />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.</t>
<t>Adding sensors<vspace blankLines="1" />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.</t>
<t>Adding home control to the smart phone<vspace
blankLines="1" />The user adds a border router to interface the
LLN network to the LAN (and WiFi) of the house.<vspace
blankLines="0" />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".</t>
</list></t>
</section>
<section title="Scenario B: Service provider home control offering">
<t>In this scenario, a consumer receives a pre-bundled kit from a
service provider:<vspace blankLines="0" /><list style="symbols">
<t>A combined internet access router and LLN border router with
WiFi support</t>
<t>Three plug-in modules for installation in the home</t>
<t>A personal web profile on the service provider web portal</t>
<t>A smartphone app for control via WiFi<vspace
blankLines="1" />Remote access credentials, LLN prefix and other
parameters are preconfigured by the service provider.</t>
</list><list style="numbers">
<t>Setting up the kit<vspace blankLines="1" />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.</t>
<t>Adding other technologies<vspace blankLines="1" />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.<vspace blankLines="0" />Each individual border
router manages local ULA prefixes and header compression
CIDs.</t>
<t>Re-discovering the network<vspace blankLines="1" />The
smartphone app rediscovers home control resources in both 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.<vspace blankLines="0" />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.</t>
</list></t>
</section>
</section>
<section title="Discovery">
<t>Discovery serves multiple purposes in a home control network:<list
style="numbers">
<t>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".</t>
<t>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.</t>
</list>A solution is required which<list style="symbols">
<t>Does not flood the LLN with unnecessary discovery traffic</t>
<t>Does not require multicasting in LLNs</t>
<t>Does allow the discovery of sleeping nodes</t>
</list></t>
</section>
<section title="Zero-Configuration">
<t>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 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.</t>
<t>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.</t>
</section>
<section title="Multiple unique routable subnets">
<t>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<xref
target="RFC4193"> </xref>.</t>
</section>
</section>
<section anchor="Building_blocks"
title="Building blocks of a CoAP Discovery infrastructure">
<t>CoAP defines a protocol for exchange of requests and commands between
constrained nodes. Already described in <xref
target="I-D.ietf-core-coap"></xref>, the CoAP Server is a host capable
of responding to CoAP messages. CoAP Servers may be classified into the
following sub-types:</t>
<t><list style="symbols">
<t>Stand-alone CoAP Server</t>
<t>CoAP Discovery Gateway</t>
<t>Caching CoAP Discovery Gateway</t>
</list></t>
<t>These are described in the following sections. Finally, the CoAP
Discovery Client is described.</t>
<t>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.</t>
<section anchor="Building_block_Stand-alone_CoAP_Server"
title="Stand-alone CoAP Server">
<t>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.<vspace blankLines="0" />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.</t>
</section>
<section anchor="Building_block_CoAP_gateway"
title="CoAP Discovery Gateway">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="Building_block_Caching_CoAP_gateway"
title="Caching CoAP Discovery Gateway">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<figure anchor="fig-caching_gateway"
title="Caching CoAP Discovery Gateway">
<artwork><![CDATA[
+--------------------------------+
| Caching CoAP Discovery Gateway |
| |
+---------------------+ +---------------------+
|Caching Interface | |non-caching Interface|- - +
|2001:1001::1 | |2001:1002::1 |
+---------------------+ +---------------------+ |
| |
+--------------------------------+ |
other
CoAP Servers
in this subnet
]]></artwork>
</figure>
<t>A Caching CoAP Discovery Gateway MAY report that it is a
(non-caching) CoAP Discovery Gateway on some interfaces; refer to
<xref target="Building_block_CoAP_gateway"></xref> .</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="CoAP Discovery Client">
<t>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:<vspace blankLines="1" /><list
style="numbers">
<t>Client is in a LLN domain with no multicast support<vspace
blankLines="1" />The initial request is sent to the Authoritative
Border Router of that LLN.<vspace blankLines="1" /></t>
<t>Client is in a link-local subnet domain with multicast support
(like Ethernet)<vspace blankLines="1" />The initial request is
transmitted to the link-local "all-routers" multicast
address.<vspace blankLines="1" /></t>
</list><vspace blankLines="1" />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.</t>
<t>A Discovery Client may run in remote controls, smart phone apps or
central management systems for home automation or building
control.<vspace blankLines="1" />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 <xref
target="I-D.ietf-core-link-format"></xref>.</t>
</section>
</section>
<section anchor="CoAP_discovery" title="CoAP Discovery">
<t>CoAP Discovery is a hierarchical process and involves two phases:
CoAP Topology Discovery and CoAP Server Discovery.</t>
<t>The purpose of the Topology Discovery phase is to establish a
snapshot of the available CoAP Discovery Gateways.</t>
<t>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.</t>
<t>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 <xref
target="I-D.ietf-6lowpan-nd"></xref>with the Authoritative Border
Router. Management and naming related issues of CoAP servers in building
control are discussed in <xref
target="I-D.vanderstok-core-bc"></xref>.</t>
<t>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 to avoid having to
distribute the address of the CoAP Discovery Gateway in LLNs. RAs
already convey the IP address of the default gateway.</t>
<section title="Topology Discovery">
<t>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).</t>
<t>The discovery process allows a client to discover CoAP servers
according to the classification described in <xref
target="Building_blocks"></xref>.</t>
<section title="Topology Path String definitions">
<t>A CoAP Discovery Gateway or caching CoAP Discovery Gateway MUST
support the following CoAP messages:</t>
<t><list style="symbols">
<t>GET /.well-known/core?n=DiscoveryGateway</t>
<t>GET /.well-known/core/topology</t>
<t>GET /.well-known/core/topology/device</t>
<t>GET /.well-known/core/topology/interfaces</t>
<t>GET /.well-known/core/topology/servers</t>
</list></t>
<section title="/topology/device">
<t>A CoAP Discovery Gateway MUST report one of the device types
listed in <xref target="topology_device_types"></xref>.</t>
<figure anchor="topology_device_types"
title="CoAP Discovery Device Types ">
<artwork><![CDATA[+----------+---------------------+----------------------------------+
| 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 |
+----------+---------------------+----------------------------------+
]]></artwork>
</figure>
<t>The report formats are described in the following sections.</t>
</section>
<section title="/topology/interfaces">
<t>A CoAP Discovery Gateway MUST return the structure</t>
<figure>
<artwork><![CDATA[
[interface address_1]
...
[interface address_n]
]]></artwork>
</figure>
<t>in response to a query for /topology/interfaces.</t>
<t>The processing of a discovery request depends on the receiving
interface:</t>
<t>If the request is targeting the gateway interface that
physically received the request, the response contains all subnet
interfaces of the discovery gateway.</t>
<t>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.</t>
</section>
<section title="/topology/servers">
<t>A Caching CoAP Discovery Gateway MUST return the structure</t>
<figure>
<artwork><![CDATA[
[server address_1]
...
[server address_n]
]]></artwork>
</figure>
<t>in response to a query for /topology/servers.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="?n=DiscoveryGateway">
<t>A CoAP Discovery Gateway MUST report the path /topology in
response to ?n=DiscoveryGateway. A CoAP Discovery Gateway MAY report
other paths as well.</t>
</section>
<section anchor="discovering_a_gateway_interface"
title="Discovering Gateway interfaces - an example">
<t>The query string ?n=DiscoveryGateway is used for discovering
topology information in a CoAP enabled infrastructure.</t>
<figure>
<artwork><![CDATA[[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
]]></artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Initial Topology Discovery">
<t>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.</t>
<t><list style="numbers">
<t>If a client resides in a multicast enabled environment (like
Ethernet or WiFi) the client issues a multicast message (as
described in <xref target="I-D.ietf-core-link-format"></xref> ) 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 <xref target="I-D.ietf-6lowpan-nd"></xref>
random delay before responding.</t>
<t>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.</t>
</list>The discovery client builds a list of reported subnets that
it has to discover. Duplicates MUST be omitted.</t>
</section>
<section title="Incremental Topology Discovery">
<t>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.</t>
<t>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.</t>
<section title="Multicast domain behind routers">
<t>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.</t>
<t>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.</t>
</section>
<t>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.</t>
</section>
<section title="CoAP Server Discovery">
<t>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.</t>
</section>
</section>
<section title="Examples">
<section title="Discovery across CoAP Discovery Gateways">
<t>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.</t>
<figure anchor="fig-discovery_across_gateways"
title="Discovery across CoAP Discovery Gateways">
<artwork><![CDATA[
+-------+
A, B --- PAN1| GW1 |LAN1 -+
PAN1 +-------+ |
|
+-------+ | +-------+
C, D --- PAN2| GW2 |LAN1 -+- LAN1| GW4 |LAN2 --- LAN2
PAN2 +-------+ | +-------+ client
|
+-------+ |
E, F --- PAN3| GW3 |LAN1 -+
PAN3 +-------+
]]></artwork>
</figure>
<!---->
<figure anchor="fig-discovery_sequence_diagram"
title="CoAP Discovery Process">
<artwork><![CDATA[
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) <--------------------------------------------------------- ""
]]></artwork>
</figure>
<t><list style="numbers">
<t>The client sends out a multicast "GET
/.well-known/core?n=DiscoveryGateway"</t>
<t>GW4 reports its other interfaces (GW4LAN1).</t>
<t>The client sends "GET /.well-known/core?n=DiscoveryGateway" to
GW4LAN1</t>
<t>GW4LAN1 is not caching and received request in unicast =>
"GET /.well-known/core?n=DiscoveryGateway" is forwarded as
multicast</t>
<t>Reports received from GW1LAN1, GW2LAN1 and GW3LAN1 within 2
seconds.</t>
<t>The client sends "GET /.well-known/core?n=DiscoveryGateway" to
GW1PAN1</t>
<t>GW1PAN1 reports that no other gateways were found in PAN1</t>
<t>The client sends "GET /.well-known/core?n=DiscoveryGateway" to
GW2PAN2</t>
<t>GW1PAN1 reports that no other gateways were found in PAN2</t>
<t>The client sends "GET /.well-known/core?n=DiscoveryGateway" to
GW3PAN3</t>
<t>GW1PAN1 reports that no other gateways were found in PAN3</t>
</list></t>
<t>The client now has the following list of CoAP Discovery Gateway
interfaces in unique subnets:</t>
<t><list style="numbers">
<t>(mcast in on-link subnet)</t>
<t>GW4LAN1</t>
<t>GW1PAN1</t>
<t>GW2PAN2</t>
<t>GW3PAN3</t>
</list></t>
<t>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.</t>
</section>
<section anchor="topology_uri_path_formats"
title="/topology path formats">
<t><xref target="fig-example-uri-topology"></xref> 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.</t>
<figure anchor="fig-example-uri-topology"
title="Looking for CoAP Discovery Gateways ">
<artwork><![CDATA[ DISCOVERY
CLIENT GATEWAY
| |
|--CON+GET /.well-known/core?n=DiscoveryGateway [TID=42]-->|
| |
| <----- ACK + 200 OK [TID=42, CT=0] ------ |
Payload:
<core://.../topology/device>;sh="/??";ct=0;n="DiscoveryGateway"
]]></artwork>
</figure>
<t><xref target="fig-example-uri-topology-interfaces"></xref> 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 Gateway. A CoAP Discovery Gateway MUST implement the path
/topology/interfaces.</t>
<figure anchor="fig-example-uri-topology-interfaces"
title="Using the "/topology/interfaces" path">
<artwork><![CDATA[ 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
]]></artwork>
</figure>
<t><xref target="fig-example-caching-gateway"></xref> 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.</t>
<t>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.</t>
<figure anchor="fig-example-caching-gateway"
title="Receiving addresses from a caching CoAP Discovery Gateway">
<artwork><![CDATA[ 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
]]></artwork>
</figure>
<t><xref target="fig-example-legacy-devices"></xref> 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.</t>
<t>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.</t>
<figure anchor="fig-example-legacy-devices"
title="Advertising legacy devices via CoAP Discovery">
<artwork><![CDATA[ DISCOVERY
CLIENT GATEWAY
| |
|--CON+GET /.well-known/core/topology/servers[TID=46]-->|
| |
| <----- ACK + 200 OK [TID=46, CT=0] ------ |
Payload:
<zw://2001:0db8:85a3:dood:0000:8a2e:0370:6543>
<zw://2001:0db8:85a3:dood:0000:8a2e:0370:6578>
]]></artwork>
</figure>
<t>A more advanced CoAP application gateway may provide translation
between legacy protocols and CoAP. This is out of scope of this
document.</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<reference anchor="RFC4193">
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<author fullname="Hinden, Haberman">
<organization></organization>
</author>
<date month="October" year="2005" />
</front>
</reference>
</references>
<references title="Informative References">
&I-D.shelby-core-coap-req;
&I-D.ietf-core-coap;
&I-D.ietf-core-link-format;
&I-D.vanderstok-core-bc;
<reference anchor="I-D.ietf-6lowpan-nd">
<front>
<title>Neighbor Discovery Optimization for Low-power and Lossy
Networks</title>
<author fullname="Zach Shelby" initials="Z" surname="Shelby">
<organization></organization>
</author>
<date />
</front>
</reference>
&RFC2080;
</references>
<section title="Open Issues">
<t></t>
<section title="Large reports">
<t>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.</t>
</section>
<section title="M2M Filtering">
<t>The document describes the use of ?n=DiscoveryGateway for detecting
CoAP Discovery Gateways.</t>
<t>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='.</t>
</section>
<section title="Routable subnets">
<t>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
<xref target="RFC4193"></xref> with no route entries to other
subnets.</t>
<t>RIPng <xref target="RFC2080"></xref> is considered sufficient for a
home control application space. Larger installations for building
control and the like are expected to be managed networks.</t>
<t>The following requirements could ensure successful plug-and-play
behavior when combining Border Routers with CoAP Discovery Gateways
from different vendors:</t>
<t><list style="symbols">
<t>A CoAP Discovery Gateway MUST support RIPng</t>
<t>RIPng SHOULD be enabled in all CoAP Discovery Gateways</t>
<t>A CoAP Discovery Gateway MAY implement other routing
protocols</t>
</list></t>
</section>
<section title="Compressing responses from caching CoAP Discovery Gateways">
<t>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.</t>
<t>If no prefix is specified the interface identifiers MUST be full IP
addresses or URIs.</t>
<t>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.</t>
</section>
<section title="Integrated Battery support">
<t>A caching CoAP Discovery Gateway MAY be integrated into a LLN
border router. This allows for tight integration of support services
for sleeping nodes.</t>
<t>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 application
acks.</t>
<t>A distributed routing protocol MAY distribute the mailbox services.
This is out of scope of this specification.</t>
</section>
</section>
<section title="Acknowledgements">
<t>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.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:16:56 |