draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt   draft-ietf-6tisch-enrollment-enhanced-beacon-01.txt 
6lo Working Group D. Dujovne 6lo Working Group D. Dujovne
Internet-Draft Universidad Diego Portales Internet-Draft Universidad Diego Portales
Intended status: Informational M. Richardson Intended status: Standards Track M. Richardson
Expires: January 18, 2019 Sandelman Software Works Expires: July 21, 2019 Sandelman Software Works
July 17, 2018 January 17, 2019
IEEE802.15.4 Informational Element encapsulation of 6tisch Join and IEEE802.15.4 Informational Element encapsulation of 6tisch Join and
Enrollment Information Enrollment Information
draft-ietf-6tisch-enrollment-enhanced-beacon-00 draft-ietf-6tisch-enrollment-enhanced-beacon-01
Abstract Abstract
In TSCH mode of IEEE802.15.4, as described by [RFC8180], In TSCH mode of IEEE802.15.4, as described by [RFC8180],
opportunities for broadcasts are limited to specific times and opportunities for broadcasts are limited to specific times and
specific channels. Nodes in a TSCH network typically frequently send specific channels. Nodes in a TSCH network typically frequently send
Enhanced Beacon (EB) frames to announce the presence of the network. Enhanced Beacon (EB) frames to announce the presence of the network.
This document provides a mechanism by which small details critical This document provides a mechanism by which small details critical
for new nodes (pledges) and long sleeping nodes may be carried within for new nodes (pledges) and long sleeping nodes may be carried within
the Enhanced Beacon. the Enhanced Beacon.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 January 18, 2019. This Internet-Draft will expire on July 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Layer-2 Synchronization . . . . . . . . . . . . . . . . . 3 1.2. Layer-2 Synchronization . . . . . . . . . . . . . . . . . 3
1.3. Layer-3 synchronization IPv6 Router solicitations and 1.3. Layer-3 synchronization IPv6 Router solicitations and
advertisements . . . . . . . . . . . . . . . . . . . . . 3 advertisements . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Example . . . . . . . . . . . . . . . . . . . . 5 2.1. Protocol Example . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Change history . . . . . . . . . . . . . . . . . . . 7 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
[RFC7554] describes the use of the time-slotted channel hopping [RFC7554] describes the use of the time-slotted channel hopping
(TSCH) mode of [ieee802154]. As further details in [RFC8180], an (TSCH) mode of [ieee802154]. As further details in [RFC8180], an
Enhanced Beacon is transmitted during a slot designated a broadcast Enhanced Beacon is transmitted during a slot designated a broadcast
slot. slot.
EDNOTE: Explain why broadcasts are rare, and why we need them. What EDNOTE: Explain why broadcasts are rare, and why we need them. What
the Enhanced Beacon is, and what Information Elements are, and how the Enhanced Beacon is, and what Information Elements are, and how
skipping to change at page 3, line 37 skipping to change at page 3, line 37
routers by listening for multicasted Router Advertisements (RA). If routers by listening for multicasted Router Advertisements (RA). If
no RA is heard within a set time, then a Router Solicitation (RS) may no RA is heard within a set time, then a Router Solicitation (RS) may
be multicast, to which an RA will be received, usually unicast. be multicast, to which an RA will be received, usually unicast.
Although [RFC6775] reduces the amount of multicast necessary to do Although [RFC6775] reduces the amount of multicast necessary to do
address resolution via Neighbor Solicitation messages, it still address resolution via Neighbor Solicitation messages, it still
requires multicast of either RAs or RS. This is an expensive requires multicast of either RAs or RS. This is an expensive
operation for two reasons: there are few multicast timeslots for operation for two reasons: there are few multicast timeslots for
unsolicited RAs; if a pledge node does not hear an RA, and decides to unsolicited RAs; if a pledge node does not hear an RA, and decides to
send a RS (consuming a broadcast aloha slot with unencrypted send a RS (consuming a broadcast aloha slot with unencrypted
traffic), many unicast RS may be sent in response. traffic), unicast RS may be sent in response. XXX
This is a particularly acute issue for the join process for the This is a particularly acute issue for the join process for the
following reasons: following reasons:
1. use of a multicast slot by even a non-malicious unauthenticated 1. use of a multicast slot by even a non-malicious unauthenticated
node for a Router Solicitation may overwhelm that time slot. node for a Router Solicitation may overwhelm that time slot.
2. it may require many seconds of on-time before a new pledge hears 2. it may require many seconds of on-time before a new pledge hears
a Router Soliciation that it can use. a Router Soliciation that it can use.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
[RFC8137] creates a registry for new IETF IE subtypes. This document [RFC8137] creates a registry for new IETF IE subtypes. This document
allocates a new subtype TBD-XXX. allocates a new subtype TBD-XXX.
This document documents a new IE subtype structure is as follows. As This document documents a new IE subtype structure is as follows. As
explained in [RFC8137] the length of the Sub-Type Content can be explained in [RFC8137] the length of the Sub-Type Content can be
calculated from the container, so no length information is necessary. calculated from the container, so no length information is necessary.
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD-XXX |R| proxy prio. | rank priority | | TBD-XXX |R|P| res | proxy prio | rank priority |
+-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+ +-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+
| pan priority | | | pan priority | |
+---------------+ + +---------------+ +
| network ID | | Join Proxy lower-64 |
+ + + (present if P=1) +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ +
| network ID |
+ variable length, up to 16 bytes +
~ ~
+ + + +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
proxy priority the proxy prority value contains a number from 0 to proxy priority the proxy prority value contains a number from 0 to
0x7f. Lower numbers are considered to be a higher preference. A 0x7f. Lower numbers are considered to be a higher preference. A
priority of 0x7f indicates that the announcer should never be priority of 0x7f indicates that the announcer should never be
considered as a viable enrollment proxy. Lower value indicates considered as a viable enrollment proxy. Lower value indicates
skipping to change at page 5, line 4 skipping to change at page 5, line 11
Unenrolled pledges MAY consider this value when selecting a PAN to Unenrolled pledges MAY consider this value when selecting a PAN to
join. Enrolled devices MAY consider this value when looking for join. Enrolled devices MAY consider this value when looking for
an eligible parent device. an eligible parent device.
rank priority the rank "priority" is set by the 6LR which sent the rank priority the rank "priority" is set by the 6LR which sent the
beacon and is an indication of how willing this 6LR is to serve as beacon and is an indication of how willing this 6LR is to serve as
an RPL parent within a particular network ID. This is a local an RPL parent within a particular network ID. This is a local
value to be determined in other work. It might be calculated from value to be determined in other work. It might be calculated from
RPL rank, and it may include some modifications based upon current RPL rank, and it may include some modifications based upon current
number of children, or number of neighbor cache entries available. number of children, or number of neighbor cache entries available.
This value MUST be ignored by pledges, it is for enrolled devices This value MUST be ignored by pledges, it is for enrolled devices
only. only.
R the Router Advertisement flag is set if the sending node will act R the Router Advertisement flag is set if the sending node will act
as a Router for host-only nodes that need addressing via unicast as a Router for host-only nodes that need addressing via unicast
Router Solicitation messages. Router Solicitation messages.
network ID this is an opaque 16-byte identifier that uniquely P if the Proxy Address bit is set, then the lower 64-bits of the
identifies this network, potentially among many networks that are Join Proxy's Link Layer address follows the network ID. If the
operating in the same frequencies in overlapping physical space. Proxy Address bit is not set, then the Link Layer address of the
Join Proxy is identical to the Layer-2 8-byte address used to
originate this enhanced beacon. In either case, the layer-2
address of any IPv6 traffic to the originator of this beacon may
use the layer-2 address which was used to originate the beacon.
join-proxy lower-64 if the P bit is set, then 64 bits (8 bytes) of
address are present. The Link Layer address of the Join Proxy is
fe80 (as for any Link Layer address), and the bits given in this
field.
network ID this is an variable length field, up to 16-bytes in size
that uniquely identifies this network, potentially among many
networks that are operating in the same frequencies in overlapping
physical space. The length of this field can be calculated as
being whatever is left in the Information Element.
In a 6tisch network, where RPL is used as the mesh routing protocol, In a 6tisch network, where RPL is used as the mesh routing protocol,
the network ID can be constructed from a SHA256 hash of the prefix the network ID can be constructed from a SHA256 hash of the prefix
(/64) of the network. That is just a suggestion for a default value. (/64) of the network. That is just a suggestion for a default value.
In some LLNs where multiple PANIDs may lead to the same management In some LLNs where multiple PANIDs may lead to the same management
device (the JRC), then a common value that is the same across all device (the JRC), then a common value that is the same across all
PANs MUST be configured. PANs MUST be configured.
2.1. Protocol Example 2.1. Protocol Example
skipping to change at page 6, line 21 skipping to change at page 6, line 40
Thomas Watteyne provided extensive editorial comments on the Thomas Watteyne provided extensive editorial comments on the
document. document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work
in progress), April 2018. in progress), December 2018.
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Minimal Security Framework for 6TiSCH", draft-ietf- "Minimal Security Framework for 6TiSCH", draft-ietf-
6tisch-minimal-security-06 (work in progress), May 2018. 6tisch-minimal-security-09 (work in progress), November
2018.
[ieee802154] [ieee802154]
IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low-
Rate Wireless Personal Area Networks (WPANs)", 2015, Rate Wireless Personal Area Networks (WPANs)", 2015,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/802.15.4-2015.html>. standard/802.15.4-2015.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
 End of changes. 14 change blocks. 
20 lines changed or deleted 41 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/