< draft-ietf-core-rd-dns-sd-04.txt   draft-ietf-core-rd-dns-sd-05.txt >
CoRE K. Lynn CoRE P. van der Stok
Internet-Draft Oracle+Dyn Internet-Draft Consultant
Intended status: Standards Track P. van der Stok Intended status: Standards Track M. Koster
Expires: September 12, 2019 Consultant Expires: January 8, 2020 SmartThings
M. Koster
SmartThings
C. Amsuess C. Amsuess
Energy Harvesting Solutions Energy Harvesting Solutions
March 11, 2019 July 07, 2019
CoRE Resource Directory: DNS-SD mapping CoRE Resource Directory: DNS-SD mapping
draft-ietf-core-rd-dns-sd-04 draft-ietf-core-rd-dns-sd-05
Abstract Abstract
Resource and service discovery are complementary. Resource discovery Resource and service discovery are complementary. Resource discovery
provides fine-grained detail about the content of a web server, while provides fine-grained detail about the content of a web server, while
service discovery can provide a scalable method to locate servers in service discovery can provide a scalable method to locate servers in
large networks. This document defines a method for mapping between large networks. This document defines a method for mapping between
CoRE Link Format attributes and DNS-Based Service Discovery records CoRE Link Format attributes and DNS-Based Service Discovery records
to facilitate the use of either method to locate RESTful service to facilitate the use of either method to locate RESTful service
interfaces (APIs) in heterogeneous HTTP/CoAP environments. interfaces (APIs) in heterogeneous HTTP/CoAP environments.
skipping to change at page 1, line 41 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 27
2. New Link-Format Attributes . . . . . . . . . . . . . . . . . 6 2. New Link-Format Attributes . . . . . . . . . . . . . . . . . 6
2.1. Export attribute "exp" . . . . . . . . . . . . . . . . . 7 2.1. Export attribute "exp" . . . . . . . . . . . . . . . . . 7
2.2. Resource Instance attribute "ins=" . . . . . . . . . . . 7 2.2. Resource Instance attribute "ins=" . . . . . . . . . . . 7
2.3. Service Type attribute "st=" . . . . . . . . . . . . . . 7 2.3. Service Type attribute "st=" . . . . . . . . . . . . . . 7
3. Mapping CoRE Link Attributes to DNS-SD Record Fields . . . . 7 3. Mapping CoRE Link Attributes to DNS-SD Record Fields . . . . 7
3.1. Mapping Resource Instance attribute "ins=" to <Instance> 7 3.1. Mapping Resource Instance attribute "ins=" to <Instance> 7
3.2. Mapping Service Type attribute "st=" to <ServiceType> . . 8 3.2. Mapping Service Type attribute "st=" to <ServiceType> . . 8
3.3. <Domain> Mapping . . . . . . . . . . . . . . . . . . . . 8 3.3. <Domain> Mapping . . . . . . . . . . . . . . . . . . . . 8
3.4. TXT Record key=value strings . . . . . . . . . . . . . . 9 3.4. TXT Record key=value strings . . . . . . . . . . . . . . 9
3.5. Exporting resource links into DNS-SD . . . . . . . . . . 9 3.5. Exporting resource links into DNS-SD . . . . . . . . . . 9
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Exporting Resource Directory Service to DNS . . . . . . . . . 10
5. Security considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. RD Parameters Registry . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10 5.2. Service Name and Transport Protocol Port Number Registry 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12 6. Security considerations . . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction and Background 1. Introduction and Background
The Constrained RESTful Environments (CoRE) working group aims at The Constrained RESTful Environments (CoRE) working group aims at
realizing the [REST] architecture in a suitable form for the most realizing the [REST] architecture in a suitable form for the most
constrained devices (e.g. 8-bit microcontrollers with limited RAM and constrained devices (e.g. 8-bit microcontrollers with limited RAM and
ROM) and networks (e.g. 6LoWPAN [RFC4944]). CoRE is aimed at ROM) and networks (e.g. 6LoWPAN [RFC4944]). CoRE is aimed at
machine-to-machine (M2M) applications such as smart energy and machine-to-machine (M2M) applications such as smart energy and
building automation. The main deliverable of CoRE is the Constrained building automation. The main deliverable of CoRE is the Constrained
Application Protocol (CoAP) specification [RFC7252]. Application Protocol (CoAP) specification [RFC7252].
skipping to change at page 5, line 35 skipping to change at page 5, line 37
naming and configuring DNS PTR, SRV, and TXT resource records to naming and configuring DNS PTR, SRV, and TXT resource records to
facilitate discovery of services (such as CoAP servers in a facilitate discovery of services (such as CoAP servers in a
subdomain) using the existing DNS infrastructure. This section gives subdomain) using the existing DNS infrastructure. This section gives
a brief overview of DNS-SD; for a detailed specification see a brief overview of DNS-SD; for a detailed specification see
[RFC6763]. [RFC6763].
DNS-SD Service Names are limited to 255 bytes and are of the form: DNS-SD Service Names are limited to 255 bytes and are of the form:
Service Name = <Instance>.<ServiceType>.<Domain> Service Name = <Instance>.<ServiceType>.<Domain>
The Service Name identifies a SRV/TXT resource record (RR) pair. The The Service Name identifies a SRV/TXT Resource Record (RR) pair. The
SRV RR specifies the hostname and port of an endpoint. The TXT RR SRV RR specifies the hostname and port of an endpoint. The TXT RR
provides additional information in the form of key/value pairs. DNS- provides additional information in the form of key/value pairs. DNS-
Based Service Discovery is accomplished by sending a DNS request for Based Service Discovery is accomplished by sending a DNS request for
PTR records with the name <ServiceType>.<Domain>, which will return a PTR records with the name <ServiceType>.<Domain>, which will return a
list of zero or more Service Names. list of zero or more Service Names.
The <Domain> part of the Service Name is identical to the global (DNS The <Domain> part of the Service Name is identical to the global (DNS
subdomain) part of the authority in URIs [RFC3986] that identify the subdomain) part of the authority in URIs [RFC3986] that identify the
resources on an individual server or group of servers. resources on an individual server or group of servers.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
description MAY be exported from a resource directory to external description MAY be exported from a resource directory to external
directories. directories.
The CoRE Link Format is used for many purposes between CoAP The CoRE Link Format is used for many purposes between CoAP
endpoints. Some are useful mainly locally; for example checking the endpoints. Some are useful mainly locally; for example checking the
observability of a resource before accessing it, determining the size observability of a resource before accessing it, determining the size
of a resource, or traversing dynamic resource structures. However, of a resource, or traversing dynamic resource structures. However,
other links are very useful to be exported to other directories, for other links are very useful to be exported to other directories, for
example the entry point resource to a functional service. This example the entry point resource to a functional service. This
attribute MAY be used as a query parameter in the RD Lookup Function attribute MAY be used as a query parameter in the RD Lookup Function
Set defined in Section 7 of [I-D.ietf-core-resource-directory]. Set defined in Section 6 of [I-D.ietf-core-resource-directory].
2.2. Resource Instance attribute "ins=" 2.2. Resource Instance attribute "ins="
The Resource Instance "ins=" attribute is an identifier for this The Resource Instance "ins=" attribute is an identifier for this
resource, which makes it possible to distinguish it from other resource, which makes it possible to distinguish it from other
similar resources in a Resource Directory. This attribute specifies similar resources in a Resource Directory. This attribute specifies
the value to be used for the <Instance> portion of an exported DNS-SD the value to be used for the <Instance> portion of an exported DNS-SD
Service Name (see Section 1.4), and SHOULD be unique across resources Service Name (see Section 1.4), and SHOULD be unique across resources
with the same Resource Type "rt=" attribute in the domain in which it with the same Resource Type "rt=" attribute in the domain in which it
is used. is used.
skipping to change at page 9, line 34 skipping to change at page 9, line 34
populate the DNS-SD database in an automated fashion. CoAP resource populate the DNS-SD database in an automated fashion. CoAP resource
descriptions (links) can be exported to DNS-SD for exposure to descriptions (links) can be exported to DNS-SD for exposure to
service discovery by using the Resource Instance attribute as the service discovery by using the Resource Instance attribute as the
basis for a unique Service Name, composed with the Service Type basis for a unique Service Name, composed with the Service Type
attribute as the <ServiceType>, and registered in the appropriate attribute as the <ServiceType>, and registered in the appropriate
<Domain>. The agent responsible for exporting records to the DNS <Domain>. The agent responsible for exporting records to the DNS
zone file SHOULD be authenticated to the DNS server. The following zone file SHOULD be authenticated to the DNS server. The following
example, using the example lookup location /rd-lookup, shows an agent example, using the example lookup location /rd-lookup, shows an agent
discovering a resource to be exported: discovering a resource to be exported:
Req: GET /rd-lookup/res?exp Req: GET /rd-lookup/res?exp
Res: 2.05 Content Res: 2.05 Content
<coap://[FDFD::1234]:5683/light/1>; <coap://[FDFD::1234]:5683/light/1>;
exp;st=oic-d-light;rt="oic.d.light";ins="Spot"; exp;st=oic-d-light;rt="oic.d.light";ins="Spot";
d="office";ep="node1" d="sector";ep="node1"
The agent subsequently registers the following DNS-SD RRs, assuming a The agent subsequently registers the following DNS-SD RRs, assuming a
derived DNS zone name "office.example.com": derived DNS zone name "office.example.com":
_oic-d-light._udp.office.example.com IN PTR _oic-d-light._udp.office.example.com IN PTR
Spot._oic-d-light._udp.office.example.com Spot._oic-d-light._udp.office.example.com
Spot._oic-d-light._udp.office.example.com IN TXT Spot._oic-d-light._udp.office.example.com IN TXT
txtver=1;path=/light/1;rt=oic.d.light txtver=1;path=/light/1;rt=oic.d.light;d=sector
Spot._oic-d-light._udp.office.example.com IN SRV 0 0 5683 Spot._oic-d-light._udp.office.example.com IN SRV
node1.office.example.com. 0 0 5683 node1.office.example.com.
node1.office.example.com. IN AAAA FDFD::1234 node1.office.example.com. IN AAAA FDFD::1234
4. IANA considerations 4. Exporting Resource Directory Service to DNS
In some cases it is required that one (or more) Resource Directories
(RD) in a given DNS domain can be discoverable from DNS. The /.well-
known/core resource of the RD should reflect this by specifying the
"ins", "exp", and the "st" attributes in the the link of the RD
service. This document specifies in Section 5 two servicetypes: _rd-
lookup-res._udp and _rd-lookup-ep._udp for resource types rt =
core.rd-lookup-res and rt = core.rd-lookup-ep respectively. The
default coap and coaps ports are respectively: 5683 and 5684.
The value of the instance MAY be specified by the manager of the
resource directories. In case of an unmanaged RD (for example in a
home network) it is recommended that the ins parameter takes a value
provided by an Authorization Server during the acceptance of the RD
to the network (see for example section 7 of
[I-D.ietf-core-resource-directory]).
With the assumption that the "ins" value is attributed by
Authorization Server, and [FDFD::1234] is IP address of RD, Example
links for RD are:
Req: GET coap://[FDFD::1234]/.well-known/core?exp
Res: 2.05 Content
<rd-lookup/res>;
exp;st=rd-lookup-res;rt="core.rd-lookup-res";
ins="505567",
<rd-lookup/ep>;
exp;st=rd-lookup-ep;rt="core.rd-lookup-ep";
ins="505572"
The link atributes can be exported to RR by the mapping process
described in Section 3.
5. IANA considerations
Two registries are affected by this document: (1) "RD Parameters"
registry under "Core Parameters" registry, and (2) Service Name and
Transport Protocol Port Number Registry
5.1. RD Parameters Registry
This specification defines new parameters for the registry "RD This specification defines new parameters for the registry "RD
Parameters" provided under "CoRE Parameters" (TBD). Parameters" provided under "CoRE Parameters" (TBD).
+----------------+-------+---------------+-----+--------------------+ +----------------+-------+---------------+-----+--------------------+
| Full name | Short | Validity | Use | Description | | Full name | Short | Validity | Use | Description |
+----------------+-------+---------------+-----+--------------------+ +----------------+-------+---------------+-----+--------------------+
| ServiceType | st | | RLA | Name of the | | ServiceType | st | | RLA | Name of the |
| | | | |Service Type, | | | | | |Service Type, |
| | | | | max 63 bytes | | | | | | max 63 bytes |
| Resource | ins | | RLA | Instance identifier| | Resource | ins | | RLA | Instance identifier|
| Instance | | | | of the resource | | Instance | | | | of the resource |
| | | | | | | | | | | |
| Export | exp | | RLA | flag to indicate | | Export | exp | | RLA | flag to indicate |
| | | | | exportation | | | | | | exportation |
+----------------+-------+---------------+-----+--------------------+ +----------------+-------+---------------+-----+--------------------+
5. Security considerations 5.2. Service Name and Transport Protocol Port Number Registry
TBD This specification defines new parameters for the Service Name and
Transport Protocol Port Number Registry:
6. References * _rd-lookup-res._udp at ports 5683 and 5684
* _rd-lookup-ep._udp at ports 5683 and 5684
6.1. Normative References 6. Security considerations
Malicious nodes can export fake link attributes to DNS. It is
recommended that the RD can be authenticated, and is authorized to
both join the network and export its link attributes. Authentication
is specified in [I-D.ietf-ace-oauth-authz].
7. Contributors
Keryy lynn was the initiator of, and major contributor to this
document. This document was split out from
[I-D.ietf-core-resource-directory]. Zach Shelby was a co-author of
the original version of this draft.
8. Acknowledgments
The authors wish to thank Stuart Cheshire, Ted Lemon, and David
Thaler for their thorough reviews and clarifying suggestions.
9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
skipping to change at page 12, line 5 skipping to change at page 13, line 24
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Guidelines for Mapping Implementations: HTTP to E. Dijk, "Guidelines for Mapping Implementations: HTTP to
the Constrained Application Protocol (CoAP)", RFC 8075, the Constrained Application Protocol (CoAP)", RFC 8075,
DOI 10.17487/RFC8075, February 2017, DOI 10.17487/RFC8075, February 2017,
<https://www.rfc-editor.org/info/rfc8075>. <https://www.rfc-editor.org/info/rfc8075>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
6.2. Informative References 9.2. Informative References
[I-D.handrews-json-schema-hyperschema] [I-D.handrews-json-schema-hyperschema]
Andrews, H. and A. Wright, "JSON Hyper-Schema: A Andrews, H. and A. Wright, "JSON Hyper-Schema: A
Vocabulary for Hypermedia Annotation of JSON", draft- Vocabulary for Hypermedia Annotation of JSON", draft-
handrews-json-schema-hyperschema-01 (work in progress), handrews-json-schema-hyperschema-01 (work in progress),
January 2018. January 2018.
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
(work in progress), March 2019.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-19 (work in progress), January 2019. resource-directory-22 (work in progress), July 2019.
[I-D.sctl-service-registration] [I-D.sctl-service-registration]
Cheshire, S. and T. Lemon, "Service Registration Protocol Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service- for DNS-Based Service Discovery", draft-sctl-service-
registration-02 (work in progress), July 2018. registration-02 (work in progress), July 2018.
[OCF] Open Connectivity Foundation, "OCF Specification 2.0", [OCF] Foundation, O., "OCF Specification 2.0", 2018,
2018, <https://openconnectivity.org/developer/ <https://openconnectivity.org/developer/specifications>.
specifications>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation, Network-based Software Architectures", 2000,
University of California, Irvine, 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>. fielding_dissertation.pdf>.
[rt] IANA, "Resource Type (rt=) Link Target Attribute [rt] IANA, ., "Resource Type (rt=) Link Target Attribute
Values", 2012, <https://www.iana.org/assignments/core- Values", 2012, <https://www.iana.org/assignments/core-
parameters/ parameters/
core-parameters.xhtml#rt-link-target-att-value>. core-parameters.xhtml#rt-link-target-att-value>.
[st] IANA, "Service Name and Transport Protocol Port Number [st] IANA, ., "Service Name and Transport Protocol Port Number
Registry", 2018, <https://www.iana.org/assignments/ Registry", 2018, <https://www.iana.org/assignments/
service-names-port-numbers/ service-names-port-numbers/
service-names-port-numbers.xml>. service-names-port-numbers.xml>.
Appendix A. Acknowledgments
This document was split out from [I-D.ietf-core-resource-directory].
Zach Shelby was a co-author of the original version of this draft.
The authors wish to thank Stuart Cheshire, Ted Lemon, and David
Thaler for their thorough reviews and clarifying suggestions.
Authors' Addresses Authors' Addresses
Kerry Lynn
Oracle+Dyn
150 Dow Street, Tower Two
Manchester, NH 03101
USA
Phone: +1 978-460-4253
Email: kerlyn@ieee.org
Peter van der Stok Peter van der Stok
Consultant Consultant
Phone: +31 492474673 (Netherlands), +33 966015248 (France) Phone: +31 492474673 (Netherlands), +33 966015248 (France)
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
URI: www.vanderstok.org URI: www.vanderstok.org
Michael Koster Michael Koster
SmartThings SmartThings
665 Clyde Avenue 665 Clyde Avenue
 End of changes. 24 change blocks. 
61 lines changed or deleted 115 lines changed or added

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