Internet DRAFT - draft-nalluri-dhc-dhcpv6-mqtt-config-options
draft-nalluri-dhc-dhcpv6-mqtt-config-options
DHC working group S. Nalluri
Internet-Draft Ericsson
Intended status: Standards Track October 20, 2017
Expires: April 23, 2018
DHCPv6 options for MQTT client configuration
draft-nalluri-dhc-dhcpv6-mqtt-config-options-00
Abstract
This document defines Dynamic Host Configuration Protocol and Dynamic
Host Configuration Protocol version 6 (DHCPv6) Options for MQTT
client configuration information, which are used to carry Uniform
Resource Locater of MQTT broker and MQTT topic prefix that should be
used as prefix for any topic published by MQTT client.
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 April 23, 2018.
Copyright Notice
Copyright (c) 2017 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Nalluri Expires April 23, 2018 [Page 1]
Internet-Draft DHCPv6 Options for MQTT October 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. MQTT client configuration through DHCP . . . . . . . . . . . 3
2.1. DHCPv6 option for MQTT broker URI . . . . . . . . . . . . 3
2.2. DHCPv6 option for MQTT topic prefix . . . . . . . . . . . 4
2.3. DHCPv4 option for MQTT broker URI . . . . . . . . . . . . 4
2.4. DHCPv4 option for MQTT topic prefix . . . . . . . . . . . 5
3. Appearance of Option . . . . . . . . . . . . . . . . . . . . 5
3.1. Appearance of options in DHCPv6 control messages . . . . 5
3.2. Appearance of options in DHCPv4 control messages . . . . 6
4. Configuration Guidelines for the Server . . . . . . . . . . . 6
5. DHCPv4/DHCPv6 Client Behavior . . . . . . . . . . . . . . . . 6
6. Relay agent Behavior . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The Message Queue Telemetry Transport (MQTT) protocol is a light-
weight IoT protocol, based on the publish/subscribe communication
model. MQTT clients, that can be publishers or subscribers,
communicate with each other via a broker. The broker hosts a set of
"topics" and clients can publish and subscribe to these topics. All
data published to a topic is delivered to all clients who are
subscribed to the same topic. In communications network using MQTT
clients commonly use a preconfigured address information, such as
Uniform Resource Identifier (URI), to register with a MQTT broker.
The URI might be configured by a user or an operator through a local
device interface. Alternatively, the URI might be provided as a
hardcoded value by manufacturer of the MQTT client device.
Hard coding configuration by device manufacturer forces device
operator to use same configuration as hard coded. It is possible
that reachability information of MQTT broker that is hard coded may
be outdated and MQTT broker reachability might fail during first use
of device. In such cases connectivity with MQTT broker is possible
only through device software upgrade.
Subscribers who are interested in specific data of a specific topic
registers the topic with the MQTT broker. MQTT clients acting as
publishers register/create topics, and MQTT clients acting as
subscribers register for a specific existing topic. In general
Nalluri Expires April 23, 2018 [Page 2]
Internet-Draft DHCPv6 Options for MQTT October 2017
terms, a topic can represented by a hierarchical string defined by
MQTT service or device operator. Before operation every MQTT client
that wishes to publish data on a specific topic should be aware of
the corresponding hierarchical strings that are supposed to be used
for the topics for the MQTT client to publish topic specific data.
However, uniqueness of topics in the MQTT network is not guaranteed
as there is no standard guideline that guarantees uniqueness. In the
same MQTT network, using the same MQTT broker, different MQTT clients
can accidentally use the same topic to publish data, which results in
invalid operation. In such scenarios, subscribers might receive
wrong data and publishers may change data they were not supposed to
change. Network or device operators therefore have to take care of
the topic name space across the MQTT network so that topic identities
are unique across the MQTT network. This manual operation is error-
prone and costly.
This draft propose DHCP and DHCPv6 options to dynamically configure
MQTT client with MQTT broker URI and one or more topic prefixs to
guarantee uniqueness of topic used across MQTT network.
2. MQTT client configuration through DHCP
MQTT broker URI and topic prefix can be collected during dynamic host
configuration phase. DHCPv4 and DHCPv6 options can be extended to
collect MQTT broker URI and MQTT topic prefix for IPv4 and IPv6
networks respectively. DHCPv4 or DHCPv6 client requests MQTT broker
URI and MQTT topic prefix using new options proposed in sections
below
2.1. DHCPv6 option for MQTT broker URI
DHCPv6 option OPTION_MQTT_BROKER_URI conveys URI through which MQTT
client can reach MQTT broker in IPv6 network. The format of MQTT
broker URI option is as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MQTT-broker-URI |
| (variable length data) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_MQTT_BROKER_URI
Nalluri Expires April 23, 2018 [Page 3]
Internet-Draft DHCPv6 Options for MQTT October 2017
option-len: Length of the 'MQTT-broker-URI' field in octets
MQTT-broker-URI: This string is URI of MQTT broker. The string is
not null-terminated.
2.2. DHCPv6 option for MQTT topic prefix
DHCPv6 option OPTION_MQTT_TOPIC_PREFIX conveys prefix string which
can be used by MQTT client as prefix of each topic used for
publishing data. The format of MQTT topic prefix option is as shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MQTT-topic-prefix |
| (variable length data) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_MQTT_TOPIC_PREFIX
option-len: Length of the 'MQTT-topic-prefix' field in octets
MQTT-topic-prefix: MQTT topic prefix string that can be used by MQTT
client as prefix to each topic used for publishing data
2.3. DHCPv4 option for MQTT broker URI
DHCPv4 option OPTION_MQTT_BROKER_URI conveys URI through which MQTT
client can reach MQTT broker that is reachable through IPv4 network.
The format of MQTT broker URI option is as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| MQTT-broker-URI(variable length data) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_MQTT_BROKER_URI
Nalluri Expires April 23, 2018 [Page 4]
Internet-Draft DHCPv6 Options for MQTT October 2017
option-len: Length of the 'MQTT-broker-URI' field in octets
MQTT-broker-URI: This string is URI of MQTT broker. The string is
not null-terminated.
2.4. DHCPv4 option for MQTT topic prefix
DHCPv4 option OPTION_MQTT_TOPIC_PREFIX conveys prefix string which
can be used by MQTT client as prefix of each topic used for
publishing data. The format of MQTT topic prefix option is as shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| MQTT-topic-prefix |
| (variable length data) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_MQTT_TOPIC_PREFIX
option-len: Length of the 'MQTT-topic-prefix' field in octets
MQTT-topic-prefix: MQTT topic prefix string that can be used by MQTT
client as prefix to each topic used for publishing data
3. Appearance of Option
3.1. Appearance of options in DHCPv6 control messages
The OPTION_MQTT_BROKER_URI and OPTION_MQTT_TOPIC_PREFIX options MUST
NOT appear in messages other than the following: SOLICIT (1),
ADVERTISE (2), REQUEST (3),REPLY (4) RENEW (5), REBIND (6),
INFORMATION-REQUEST (11). If this option appears in messages other
than those specified above, the receiver MUST ignore it.
The option number for OPTION_MQTT_BROKER_URI and
OPTION_MQTT_TOPIC_PREFIX options MAY appear in the "Option Request"
option [RFC3315] in the following messages: SOLICIT (1), REQUEST (3),
RENEW (5), REBIND (6), INFORMATION-REQUEST (11) and RECONFIGURE (10).
If this option number appears in the "Option Request" option in
messages other than those specified above, the receiver SHOULD ignore
it.
Nalluri Expires April 23, 2018 [Page 5]
Internet-Draft DHCPv6 Options for MQTT October 2017
3.2. Appearance of options in DHCPv4 control messages
The OPTION_MQTT_BROKER_URI and OPTION_MQTT_TOPIC_PREFIX options MUST
NOT appear in messages other than the following: DHCPDISCOVER (1),
DHCPOFFER (2), DHCPREQUEST (3), DHCPACK (5) and DHCPINFORM (8). If
this option appears in messages other than those specified above, the
receiver MUST ignore it.
The option number for OPTION_MQTT_BROKER_URI and
OPTION_MQTT_TOPIC_PREFIX options MAY appear in the "Parameter Request
List" option [RFC2132] in the following messages: DHCPDISCOVER (1),
DHCPOFFER (2), DHCPREQUEST (3), DHCPACK (5) and DHCPINFORM (8). If
this option number appears in the "Parameter Request List" option in
messages other than those specified above, the receiver SHOULD ignore
it.
Maximum possible value of DHCPv4 "option-len" is 255. MQTT-topic-
prefix MAY be of length more than 255. To accommodate larger
certificate, DHCP server SHOULD follow encoding as mentioned in
[RFC3396].
4. Configuration Guidelines for the Server
DHCPv4 or DHCPv6 server that supports OPTION_MQTT_BROKER_URI and
OPTION_MQTT_TOPIC_PREFIX SHOULD be configured with one or more MQTT
broker URI, and one or moretopic prefix for each MQTT client. DHCP
server may use statically configured topic prefixes or algorithem
genrated topic prefixes. Algorithems to generate MQTT topic prefix
for an MQTT client might use client attributes like data link layer
address. Details of algorithems to generate topic prefix and
guidelines to manage topic prefixes are not included in the scope of
this draft
In the absence of MQTT broker URI configuration, DHCP server SHOULD
ignore option OPTION_MQTT_BROKER_URI, and SHOULD continue processing
of DHCP control message
In the absence of MQTT topic prefix configuration and topic prefix
generation algorithem, DHCP server SHOULD ignore option
OPTION_MQTT_TOPIC_PREFIX, and SHOULD continue processing of DHCP
control message
5. DHCPv4/DHCPv6 Client Behavior
DHCP or DHCPv6 client MAY decide need for inclusion of
OPTION_MQTT_BROKER_URI and OPTION_MQTT_TOPIC_PREFIX options in DHCPv4
or DHCPv6 control messages if device is capable of supporting MQTT
client functionality irrespective of state of MQTT client. It is
Nalluri Expires April 23, 2018 [Page 6]
Internet-Draft DHCPv6 Options for MQTT October 2017
possible that MQTT client MAY not be active before DHCPv4 or DHCPv6
message exchanges happens. In such scenario, DHCPv4 or DHCPv6 client
MAY collect MQTT broker URI and MQTT topic prefix and keep ready for
MQTT client initialization
DHCPv4 or DHCPv6 client MAY prefer collecting MQTT broker URI and
MQTT topic prefix by including OPTION_MQTT_BROKER_URI and
OPTION_MQTT_TOPIC_PREFIX options in DHCPINFORM or INFORMATION-REQUEST
message which MAY be send during MQTT client initialization
MQTT client devices running with IPv6 stack MAY use stateless auto
address configuration to get IPv6 address. Such clients MAY use
DHCPv6 INFORMATION-REQUEST to get MQTT broker URI and MQTT topic
prefix through options OPTION_MQTT_BROKER_URI and
OPTION_MQTT_TOPIC_PREFIX
6. Relay agent Behavior
This draft does not impose any new requirements on DHCPv4 or DHCPv6
relay agent functionality
7. Security Considerations
OPTION_MQTT_BROKER_URI option could be used by an intruder to
advertise the URI of a malicious MQTT broker which results in data
reporting by MQTT clients to an unwanted MQTT broker. As an example,
an attacker could collect data from secure locations by deploying
malicious servers.
Intuders might use OPTION_MQTT_TOPIC_PREFIX option to advertise
unwanted topic prefixes which results in duplicate MQTT topics As an
example, an attacker could collect data from secure locations by
deploying malicious servers.
To prevent these attacks, it is strongly advisable to secure the use
of these options by either:
o Using authenticated DHCP as described in [RFC3315], Section 21.
o Using options OPTION_MQTT_BROKER_URI and OPTION_MQTT_TOPIC_PREFIX
only with trusted DHCP server
The security considerations documented in [RFC3315] are to be
considered.
Nalluri Expires April 23, 2018 [Page 7]
Internet-Draft DHCPv6 Options for MQTT October 2017
8. Acknowledgement
Particular thanks to A. Keraenen and S. Krishnan for inputs and
review.
9. IANA Considerations
IANA is requested to assign new DHCPv6 option codes in the registry
maintained in http://www.iana.org/assignments/dhcpv6-parameters:
| Option Name | Value |
|---------------------------------+----------|
| OPTION_MQTT_BROKER_URI | TBA |
| OPTION_MQTT_TOPIC_PREFIX | TBA |
IANA is requested to assign new DHCPv4 option codes in the registry
maintained in http://www.iana.org/assignments/bootp-dhcp-parameters:
| Option Name | Value |
|--------------------------------+---------|
| OPTION_MQTT_BROKER_URI | TBA |
| OPTION_MQTT_TOPIC_PREFIX | TBA |
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
Nalluri Expires April 23, 2018 [Page 8]
Internet-Draft DHCPv6 Options for MQTT October 2017
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
DOI 10.17487/RFC3396, November 2002, <https://www.rfc-
editor.org/info/rfc3396>.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005,
<https://www.rfc-editor.org/info/rfc4306>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<https://www.rfc-editor.org/info/rfc7227>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
10.2. Informative References
[MQTT-SPEC]
"MQTT Version 3.1.1, OASIS Standard", n.d.,
<http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/
mqtt-v3.1.1-os.html>.
Author's Address
Srinivas Rao Nalluri
Ericsson
Bangalore
India
Email: srinivasa.rao.nalluri@ericsson.com
Nalluri Expires April 23, 2018 [Page 9]
