One document matched: draft-richardson-6lo-ra-in-ie-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.36 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7228 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
<!ENTITY I-D.ietf-6tisch-minimal SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-minimal.xml">
<!ENTITY I-D.kivinen-802-15-ie SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kivinen-802-15-ie.xml">
<!ENTITY RFC6775 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC6282 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC2461 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2461.xml">
<!ENTITY I-D.ietf-6lo-dispatch-iana-registry SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-dispatch-iana-registry.xml">
<!ENTITY I-D.ietf-6tisch-architecture SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-architecture.xml">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC7554 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7554.xml">
<!ENTITY RFC4191 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4191.xml">
<!ENTITY RFC2460 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4861 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4443 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-richardson-6lo-ra-in-ie-00" category="info">
<front>
<title abbrev="IE for ICMPv6">802.15.4 Informational Element encapsulation of ICMPv6 Router Advertisements</title>
<author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization>Sandelman Software Works</organization>
<address>
<email>mcr+ietf@sandelman.ca</email>
</address>
</author>
<date year="2016" month="October" day="18"/>
<area>Internet</area>
<workgroup>6lo Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>In TSCH mode of 802.15.4, as described by <xref target="I-D.ietf-6tisch-minimal"/>,
opportunities for broadcasts are limited to specific times and specific
channels. An enhanced beacon must be broadcast periodically by every router
to keep all nodes in sync. This document provides a mechanism by which other
small ICMPv6 packets, such as Router Advertisements may be carried within the
Enhanced Beacon, providing standard IPv6 router/host protocol.</t>
</abstract>
</front>
<middle>
<section anchor="problems" title="Introduction">
<t><xref target="I-D.ietf-6tisch-architecture"/> describes the use of the time-slotted channel
hopping (TSCH) mode of <xref target="ieee802154"/>. As further details in
<xref target="I-D.ietf-6tisch-minimal"/>, an Extended Beacon is transmitted during a slot
designated a broadcast slot.</t>
<t>EDNOTE: Explain why broadcasts are rare, and why we need them. What the Enhanced Beacon is, and what Information Elements are, and how the IETF has a subtype for that area. Explain what kind of things could be placed in Information Elements, how big they could be, and how they could be compressed.</t>
<section anchor="Terminology" title="Terminology">
<t>In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
<xref target="RFC2119"/> and indicate requirement levels for compliant STuPiD
implementations.</t>
</section>
<section anchor="layer-2-synchronization" title="Layer-2 Synchronization">
<t>As explained in section 6 of <xref target="I-D.ietf-6tisch-minimal"/>, the Extended Beacon
has a number of purposes: synchronization of ASN and Join Metric, timeslot
template identifier, the channel hopping sequence identifier, TSCH SlotFrame and
Link IE.</t>
<t>The Extended Beacon is used by operating nodes to correct drift to their clock,
by nodes on medium length sleeps to resynchronize their ASN,
by nodes that have slept through a network rekey to rediscover the network,
and by new Joining Nodes (pledges) to learn about the existance of the network.</t>
<t>There are a limited number of timeslots designated as a broadcast slot by each
router. These slots are rare, and with 10ms slots, with a slot-frame length of
100, there may be only 1 slot/s for the beacon.</t>
</section>
<section anchor="layer-3-synchronization-ipv6-router-solicitations-and-advertisements" title="Layer-3 synchronization IPv6 Router solicitations and advertisements">
<t>At layer 3, <xref target="RFC2461"/> defines a mechanism by which nodes learn about
routers by listening for multicasted Router Advertisements (RA). If 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.</t>
<t>Although <xref target="RFC6775"/> reduces the amount of multicast necessary to do address
resolution via Neighbor Solicitation messages, it still requires multicast
of either RAs or RS. This is an expensive operation for two reasons: there
are few multicast timeslots for unsolicited RAs; if a pledge node does not
hear an RA, and decides to send a RS (consuming a broadcast aloha slot with
unencrypted traffic), many unicast RS may be sent in response.</t>
<t>This is a particularly acute issue for the join process for the following
reasons:</t>
<t><list style="numbers">
<t>use of a multicast slot by even a non-malicious unauthenticated node for
a Router Solicitation may overwhelm that time slot.</t>
<t>it may require many seconds of on-time before a new pledge hears a Router
Soliciation that it can use.</t>
<t>a new pledge may listen to many Enhanced Beacons before it can pick an
appropriate network and/or closest Join Assistant to attach to. If it must
listen for a RS as well as find the Enhanced Beacon, then the process may
take a very long time.</t>
</list></t>
</section>
</section>
<section anchor="protocol-definition" title="Protocol Definition">
<t><xref target="I-D.kivinen-802-15-ie"/> creates a registry for new IETF IE subtypes.
This document allocates a new subtype TBD-XXX.</t>
<t>The base IE subtype structure is as follows. As explained in
<xref target="I-D.kivinen-802-15-ie"/> the length of the Sub-Type Content can be calculated.</t>
<figure><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD-XXX | 6LoRH encoded structure |
+-+-+-+-+-+-+-+-+ |
~ Sub-Type Content ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>Inside the Sub-Type content should be placed compressed packets
according to <xref target="RFC6282"/> (as updated by <xref target="I-D.ietf-6lo-dispatch-iana-registry"/>.</t>
<section anchor="protocol-example" title="Protocol Example">
<t>Typically a Router Advertisement will be placed inside the Sub-Type.
The entire structure typically looks like:</t>
<figure><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver 6 | TC = 0 | Flow Label = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NH = 58 | Hop Lmt = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| fe80::LL |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| fe02::1 |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 134 | Code = 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HL = 0 |0|0| Reserved | Router lifetime = 9000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time = 0 XXX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer = 0 XXX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Len = 10 | EUI-64 of router |
+-+-+-+-+-+-+-+-+-+-+-+---------+ +
| EUI-64 of router |
+ +---------------+---------------+
| EUI-64 of router | Type = TBD-YYY| Len = 18 |
+-------------------------------+-------------------------------+
| DODAGID |
+ |
| |
+ |
| |
+ |
| |
+---------------------------------------------------------------+
]]></artwork></figure>
<t>When compressed by <xref target="RFC6282"/>, this becomes:</t>
<figure><artwork><![CDATA[
+---------------------------------------------------------------+
| 0 | 1 | 1 |TF= 11 |NH |HLIM=01|CID|SAC| SAM | M |DAC| DAM | 0
+ | | | | 0 | | 0 | 0 | 0 1 + 1 + 0 + 1 1 +
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| NH = 0x58 | dstXX = 0x01 | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 134 | Code = 0 | Checksum | 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HL = 0 |0|0| Reserved | Router lifetime = 9000 | 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time = 0 XXX | 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer = 0 XXX | 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Len = 10 | EUI-64 of router | 24
+-+-+-+-+-+-+-+-+-+-+-+---------+ +
| EUI-64 of router | 28
+ +---------------+---------------+
| EUI-64 of router | Type = TBD-YYY| Len = 18 | 32
+-------------------------------+-------------------------------+
| DODAGID | 36
+ |
| | 40
+ |
| | 44
+ |
| | 48
+---------------------------------------------------------------+
]]></artwork></figure>
<t>The total number of bytes needed is 56 bytes.</t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TBD.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>Allocate a new number TBD-XXX from Registry IETF IE Sub-type ID.
This entry should be called 6LoRH-in-IE.</t>
<t>Allocate a new number TBD-YYY from Neighbor Discovery Option Types (RFC2461)
with the name "Constrained Network Identification".</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2119;
&RFC7228;
&I-D.ietf-6tisch-minimal;
&I-D.kivinen-802-15-ie;
&RFC6775;
&RFC6282;
&RFC2461;
&I-D.ietf-6lo-dispatch-iana-registry;
&I-D.ietf-6tisch-architecture;
<reference anchor="ieee802154" target="http://standards.ieee.org/findstds/standard/802.15.4-2015.html">
<front>
<title>802.15.4-2015 - IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs)</title>
<author initials="." surname="IEEE Standard">
<organization></organization>
</author>
<date year="2015"/>
</front>
</reference>
</references>
<references title='Informative References'>
&RFC4655;
&RFC7554;
&RFC4191;
&RFC2460;
&RFC4861;
&RFC4443;
</references>
<section anchor="appendix" title="appendix">
<t>insert appendix here</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 01:13:31 |