DTLS Multicast
draft-lucas-dtls-multicast-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Roger Lucas | ||
| Last updated | 2018-04-19 (Latest revision 2017-09-13) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This proposal to provide a secure multicast 1-to-N or M-to-N device capability, with the same level of reliability as the underlying multicast network, also aims to be light-weight and supported by a very constrained device. Guaranteed reliability would be provided by an additional protocol working in co-operation with it. The aim is to support end to end secure communications in the edge device world of IoT where the transport methods will vary or at least change once the IP realm is left. Hence there is no dependence on Ipv6 or IP or CoAP and no restrictions that might be introduced if too specific an end node application was implied. It is network independent, it just must be possible to transmit and receive frames in multicast. This can be achieved with simply a minimal change to the DTLS behavior and using current DTLS libraries. DTLS headers are not changed, additional headers are used in the packets before the DTLS traffic. DTLS Multicast keeps the layer concept pure and independent, hence it can be used for routing something that is not CoAP.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)