One document matched: draft-thubert-6lo-rfc6775-update-reqs-06.xml
<?xml version="1.0" encoding="ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC3610 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3610.xml">
<!ENTITY RFC3810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810.xml">
<!ENTITY RFC3963 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4389.xml">
<!ENTITY RFC4429 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4429.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4919 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC6275 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY RFC6550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6550.xml">
<!ENTITY RFC6655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6655.xml">
<!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC6830 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6830.xml">
<!ENTITY RFC7102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7102.xml">
<!ENTITY RFC7217 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7217.xml">
<!ENTITY I-D.van-beijnum-multi-mtu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijnands-bier-architecture.xml">
<!ENTITY I-D.richardson-6tisch--security-6top SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.richardson-6tisch--security-6top.xml">
]>
<rfc category="std" ipr="trust200902" docName="draft-thubert-6lo-rfc6775-update-reqs-06">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="6775bis reqs">Requirements for an update to 6LoWPAN ND</title>
<author fullname="Pascal Thubert" initials="P" role="editor" surname="Thubert">
<organization abbrev="cisco">Cisco Systems, Inc</organization>
<address>
<postal>
<street>Building D</street>
<street>45 Allee des Ormes - BP1200 </street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>FRANCE</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author initials="P." surname="van der Stok" fullname="Peter van der Stok">
<organization abbrev="consultant">consultant</organization>
<address>
<phone>+31-492474673 (Netherlands), +33-966015248 (France)</phone>
<email>consultancy@vanderstok.org</email>
<uri>www.vanderstok.org</uri>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>6Lo</workgroup>
<abstract>
<t>
Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups suggest
that enhancements to the 6LoWPAN ND mechanism are now needed.
This document elaborates on those requirements and suggests approaches
to serve them.
</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>
A number of use cases, including the Industrial Internet, require a
large scale deployment of sensors that can not be realized with wires
and is only feasible over wireless
Low power and Lossy Network (LLN) technologies.
When simpler hub-and-spoke topologies are not sufficient for the
expected throughput and density, mesh networks are deployed, which
implies the routing of packets over the mesh, operated at either Layer-2
or Layer-3.
</t>
<t>
For routing over a mesh at layer-3, the IETF has designed the IPv6 Routing Protocol over LLN (RPL) <xref target="RFC6550"/>.
</t>
<t> To assign routable addresses, DHCPv6 is still a viable option in LLNs. However, the IETF standard
that supports address assignment specifically for LLNs is 6LoWPAN ND, the
<xref target="RFC6775">Neighbor Discovery Optimization for Low-power and
Lossy Networks</xref>. 6LoWPAN ND was designed as a stand-alone mechanism
separately from its IETF routing counterpart, the <xref target="RFC6550">
IPv6 Routing Protocol for Low power and Lossy Networks</xref> (RPL), and
the interaction between the 2 protocols was not defined.
</t>
<t>The 6TiSCH WG is now considering an
<xref target="I-D.ietf-6tisch-architecture">architecture</xref> whereby a
6LowPAN ND host could connect to the Internet via a RPL
Network, but this requires additions to the 6LOWPAN ND protocol to support mobility
and reachability in a secured and manageable environment.
</t>
<t>
At the same time, new work at 6MAN on
<xref target="I-D.chakrabarti-nordmark-6man-efficient-nd">
Efficiency aware IPv6 Neighbor Discovery Optimizations</xref> suggests
that 6LoWPAN ND can be extended to other types of networks on top of the
Low power and Lossy Networks (LLNs) for which it was already defined.
The value of such extension is especially apparent in the case of mobile
wireless devices, to reduce the multicast operations that are related
to classical ND (<xref target="RFC4861"/>, <xref target="RFC4862"/>) and
plague the wireless medium. In this context also, there is a need for
additions to 6LOWPAN ND.
</t>
<t>The <xref target="RFC4429">Optimistic Duplicate Address Detection</xref>
(ODAD) specification details how an address can be used before a
Duplicate Address Detection (DAD) is complete, and insists that an
address that is TENTATIVE should not be associated to a Source Link-Layer
Address Option in a Neighbor Solicitation message. Applying this rule to 6LOWPAN ND implies another change to its specification.
</t>
<t> In <xref target="I-D.richardson-6tisch--security-6top"/>, the 6tisch working group considers the use of layer-2 security. It develops a network bootstrap protocol that provides secure link connections at the same rate that nodes are discovered. This approach needs the presence of a routing protocol to route packets from a joining node to a security providing node (e.g. a PCE or commissioning tool).
</t>
<t>
This document suggests a limited evolution to <xref target="RFC6775"/> so
as to allow operation of a 6LoWPAN ND node while a routing protocol (in first instance RPL) is present and operational.
It also suggests a more generalized use of the information in the ARO
option of the ND messages outside the strict LLN domain, for instance over a converged
backbone.
</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
<t>Readers are expected to be familiar with all the terms and concepts
that are discussed in <xref target="RFC4861">"Neighbor Discovery for
IP version 6"</xref>, <xref target="RFC4862">"IPv6 Stateless Address
Autoconfiguration"</xref>, <xref target="RFC4919">"IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals"</xref>,
<xref target="RFC6775">Neighbor Discovery Optimization
for Low-power and Lossy Networks</xref> and <xref target="RFC4944">
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>.
</t>
<t>Additionally, this document uses terminology from <xref
target="I-D.ietf-6tisch-terminology">6TiSCH</xref> and <xref
target="RFC7102">ROLL</xref>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='overview' title="Overview">
<t> This document is mostly motivated by the work ongoing in the 6TiSCH working group.
The <xref target="I-D.ietf-6tisch-architecture">6TiSCH architecture
</xref> draft explains the network architecture of a 6TiSCH network. This architecture is used for the remainder of this document.
</t>
<t> The scope of the 6TiSCH Architecture is a Backbone Link that
federates multiple LLNs (mesh) as a single IPv6 Multi-Link Subnet.
Each LLN in the subnet is anchored at a Backbone Router (6BBR).
The Backbone Routers interconnect the LLNs over the Backbone Link and
emulate that the LLN nodes are present on the Backbone thus creating a so-called: Multi-Link Subnet. An LLN node can move freely from an LLN anchored at a Backbone Router to another LLN anchored at the same or a
different Backbone Router inside the Multi-Link Subnet and conserve its
addresses.
<figure anchor='figNetwork'
title="6TiSCH architecture">
<artwork><![CDATA[
---+------------------------
| Plant Network
|
+-----+
| | Gateway
| |
+-----+
|
| Backbone Link (with VLANs)
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
| | router | | router | | router
+-----+ +-----+ +-----+
| | | | | |
0 0 0 0 0 (6LBR == LLN border router)
o o o o o o o o o o o o o o
o o o o o o o o o o (6LR == LLN router)
o o o o o o o z
o o o o o z
RPL Instances (6LoWPAN Host == LLN host)
]]></artwork>
</figure>
</t>
<t>
The 6LBR is the border router that is placed between the LLN and nodes outside the LLN. The 6LBR is logically separated from the 6BBR that
is used to connect the LLN to the backbone. The 6LBR
can use Efficient ND as the interface to register an LLN node in
its topology to the 6BBR for whatever operation the 6BBR performs, such
as ND proxy operations, or injection in a routing protocol. It results
that, as illustrated in <xref target='figReg'/>, the periodic signaling
could start at the leaf node with 6LoWPAN ND, then would be routed to the 6LBR, and then with Efficient-ND to the 6BBR.
Efficient ND being an adaptation of 6LoWPAN ND, it makes sense to keep
those two homogeneous in the way they use the source and the target
addresses in the Neighbor Solicitation (NS) messages for registration,
as well as in the options that they use for that process.
<figure anchor='figReg' suppress-title='false'
title="(Re-)Registration Flow over Multi-Link Subnet">
<artwork><![CDATA[
6LoWPAN host 6LR 6LBR 6BBR
| | | |
| 6LoWPAN ND | 6LoWPAN ND | Efficient ND | IPv6 ND
| LLN link | IPv6 route | IPv6 link | Backbone
| | | |
| NS(ARO) | | |
|-------------->| | |
| 6LoWPAN ND | DAR (then DAO)| |
| |-------------->| |
| | | NS(ARO) |
| | |-------------->|
| | | | DAD
| | | |------>
| | | |
| | | NA(ARO) |
| | |<--------------|
| | DAC | |
| |<--------------| |
| NA(ARO) | | |
|<--------------| | |
]]></artwork>
</figure>
</t><t>As the network builds up, a LoWPAN host starts as a
leaf to join the LLN, and may later turn into a 6LR, so as to accept other nodes to recursively join the LLN.
</t><t>Section 5 of the
<xref target="I-D.ietf-6tisch-architecture">6TiSCH architecture </xref>
provides more information on the need to update the protocols that sustain
the requirements in the next section.
</t>
</section>
<section anchor='Reqes' title="Requirements">
<section anchor='Req1' title="Requirements Related to Mobility">
<t>
Due to the unstable nature of LLN links, even in a LLN of immobile nodes a 6LoWPAN Node may change its
point of attachment to a 6LR, say 6LR-a, and may not be able to notify 6LR-a. Consequently, 6LR-a may still attract traffic
that it cannot deliver any more. When links to a 6LR change state, there is thus a need
to identify stale states in a 6LR and restore reachability in a timely fashion.
</t><t>
Req1.1: Upon a change of point of attachment, connectivity via a new 6LR MUST be
restored timely without the need to de-register from the previous 6LR.
</t><t>
Req1.2: For that purpose, the protocol MUST enable to differentiate between multiple
registrations from one 6LoWPAN Node and registrations from different 6LoWPAN Nodes
claiming the same address.
</t><t>
Req1.3: Stale states MUST be cleaned up in 6LRs.
</t><t>
Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address to multiple
6LRs, and this, concurrently.
</t>
</section>
<section anchor='Req2' title="Requirements Related to Routing Protocols">
<t> The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN mesh.
IPv6 routing in a LLN can be based on RPL, which is the routing
protocol that was defined at the IETF for this particular purpose.
Other routing protocols than RPL are also considered by Standard Defining
Organizations (SDO) on the basis of the expected network characteristics.
It is required that
a 6LoWPAN Node attached via ND to a 6LR would need to participate in the
selected routing protocol to obtain reachability via the 6LR.
</t><t>
Next to the 6LBR unicast address registered by ND, other addresses including multicast addresses are needed as well.
For example a routing protocol often uses a multicast address to register changes to established paths.
ND needs to register such a multicast address to enable routing concurrently with discovery.
</t><t>
Multicast is needed for groups. Groups MAY be
formed by device type (e.g. routers, street lamps), location (Geography,
RPL sub-tree), or both.
</t>
<t>The Bit Index Explicit Replication (BIER)
<xref target="I-D.wijnands-bier-architecture">Architecture</xref>
proposes an optimized technique to enable multicast in a LLN with a very
limited requirement for routing state in the nodes.
</t>
<t>
Related requirements are:
</t><t>
Req2.1: The ND registration method SHOULD be extended in such a fashion that
the 6LR MAY advertise the Address of a 6LoWPAN Node over the selected routing protocol and obtain
reachability to that Address using the selected routing protocol.
</t><t>
Req2.2: Considering RPL, the Address Registration Option that is used in
the ND registration
SHOULD be extended to carry enough information to generate a DAO
message as specified in <xref target="RFC6550"/> section 6.4, in particular
the capability to compute a DAOSequence and, as an option, a RPLInstanceID.
</t><t>
Req2.3: Multicast operations SHOULD be supported and optimized, for instance
using BIER or MPL. Whether ND is appropriate for the registration to the 6BBR is to
be defined, considering the additional burden of supporting the
<xref target="RFC3810"> Multicast Listener Discovery Version 2 </xref>
(MLDv2) for IPv6.
</t>
</section>
<section anchor='Req3' title="Requirements Related to the Variety of Low-Power Link types">
<t>
<xref target="RFC6775">6LoWPAN ND</xref> was defined with a focus on
IEEE802.15.4 and in particular the capability to derive a unique Identifier
from a globally unique MAC-64 address. At this point, the 6lo Working
Group is extending the <xref target="RFC6282">6LoWPAN Header Compression (HC)
</xref> technique to other link types
<xref target="I-D.brandt-6man-lowpanz">ITU-T G.9959</xref>,
<xref target="I-D.ietf-6lo-6lobac">Master-Slave/Token-Passing</xref>,
<xref target="I-D.ietf-6lo-dect-ule">DECT Ultra Low Energy</xref>,
<xref target="I-D.hong-6lo-ipv6-over-nfc">Near Field Communication</xref>,
as well as <xref target="I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks">
IEEE1901.2 Narrowband Powerline Communication Networks</xref> and
<xref target="I-D.ietf-6lo-btle">BLUETOOTH(R) Low Energy</xref>.
</t><t>
Related requirements are:
</t><t>
Req3.1: The support of the registration mechanism SHOULD be extended to more LLN
links than IEEE 802.15.4, matching at least the LLN links for which an "IPv6
over foo" specification exists, as well as Low-Power Wi-Fi.
</t><t>
Req3.2: As part of this extension, a mechanism to compute a unique Identifier should
be provided, with the capability to form a Link-Local Address that SHOULD be unique at least within the LLN connected to a 6LBR discovered by ND in each node within the LLN.
</t><t>
Req3.3: The Address Registration Option used in the ND registration SHOULD be
extended to carry the relevant forms of unique Identifier.
</t><t>
Req3.4: The Neighbour Discovery should specify the formation of a site-local address that follows the security recommendations from <xref target="RFC7217"/>.
</t>
</section>
<section anchor='Req4' title="Requirements Related to Proxy Operations">
<t>
Duty-cycled devices may not be able to answer themselves to a lookup from a node
that uses classical ND on a backbone and may need a proxy. Additionally, the duty-cycled device may need to rely on the 6LBR to perform
registration to the 6BBR.
</t><t>
The ND registration method SHOULD defend the addresses of duty-cycled devices that are sleeping most of the
time and not capable to defend their own Addresses.
</t><t>
Related requirements are:
</t><t>
Req4.1: The registration mechanism SHOULD enable a third party to proxy register
an Address on behalf of a 6LoWPAN node that may be sleeping or located
deeper in an LLN mesh.
</t><t>
Req4.2: The registration mechanism SHOULD be applicable to a duty-cycled device
regardless of the link type, and enable a 6BBR to operate as a proxy to
defend the registered Addresses on its behalf.
</t><t>
Req4.3: The registration mechanism SHOULD enable long sleep durations, in the
order of multiple days to a month.
</t>
</section>
<section anchor='Req5' title="Requirements Related to Security">
<t> In order to guarantee the operations of the 6LoWPAN ND flows, the
spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a node
successfully registers an address, 6LoWPAN ND should provide energy-efficient
means for the 6LBR to protect that ownership even when the node that registered the address is sleeping.
</t>
<t>
In particular,
the 6LR and the 6LBR then should be able to verify whether a subsequent
registration for a given Address comes from the original node.
</t><t>
In a LLN it makes sense to base security on layer-2 security. During bootstrap of the LLN, nodes join the network after authorization by a Joining Assistant (JA) or a Commissioning Tool (CT). After joining nodes communicate with each other via secured links. The keys for the layer-2 security are distributed by the JA/CT. The JA/CT can be part of the LLN or be outside the LLN. In both cases it is needed that packets are routed between JA/CT and the joining node.
</t><t>
Related requirements are:
</t><t>
Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the
6LR, 6LBR and 6BBR to authenticate and authorize one another for their
respective roles, as well as with the 6LoWPAN Node for the role of 6LR.
</t><t>
Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR
and the 6LBR to validate new registration of authorized nodes. Joining of unauthorized nodes MUST be impossible.
</t><t>
Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet sizes. In
particular, the NS, NA, DAR and DAC messages for a re-registration flow
SHOULD NOT exceed 80 octets so as to fit in a secured IEEE802.15.4 frame.
</t><t>
Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be computationally
intensive on the LoWPAN Node CPU. When a Key hash calculation is employed, a
mechanism lighter than SHA-1 SHOULD be preferred.
</t><t>
Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate SHOULD
be minimized.
</t><t>
Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use at both
Layer 2 and Layer 3, and SHOULD enable the reuse of security code that has to
be present on the device for upper layer security such as TLS.
</t><t>
Req5.7: Public key and signature sizes SHOULD be minimized while maintaining
adequate confidentiality and data origin authentication for multiple types
of applications with various degrees of criticality.
</t><t>
Req5.8: Routing of packets should continue when links pass from the unsecured
to the secured state.
</t><t>
Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR
and the 6LBR to validate whether a new registration for a given address
corresponds to the same 6LoWPAN Node that registered it initially, and,
if not, determine the rightful owner, and deny or clean-up
the registration that is duplicate.
</t>
</section>
<section anchor='Req6' title="Requirements Related to Scalability">
<t>
Use cases from Automatic Meter Reading (AMR, collection tree operations) and
Advanced Metering Infrastructure (AMI, bi-directional communication to the
meters) indicate the needs for a large number of LLN nodes pertaining to a
single RPL DODAG (e.g. 5000) and connected to the 6LBR over a large number of
LLN hops (e.g. 15).
</t><t>
Related requirements are:
</t><t>
Req6.1: The registration mechanism SHOULD enable a single 6LBR to register
multiple thousands of devices.
</t><t>
Req6.2: The timing of the registration operation should allow for a large
latency such as found in LLNs with ten and more hops.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
This specification expects that the link layer is sufficiently protected,
either by means of IP security for the Backbone Link or MAC
sublayer cryptography.
In particular, it is expected that the LLN MAC provides secure unicast
to/from the Backbone Router and secure broadcast from the Backbone Router
in a way that prevents tampering with or replaying the RA messages.
Still, <xref target='Req5'/> has a requirement for a mutual authentication
and authorization for a role for 6LRs, 6LBRs and 6BBRs.
</t><t>
This documents also suggests in <xref target='trackingmess'/> that a
6LoWPAN Node could form a single Unique Interface ID (CUID)
based on cryptographic techniques similar to CGA.
The CUID would be used as Unique Interface Identifier in the ARO option
and new Secure ND procedures would be proposed to use it as opposed to the
source IPv6 address to secure the binding between an Address and its
owning Node, and enforce First/Come-First/Serve at the 6LBR.
</t>
</section>
<section title="IANA Considerations">
<t>This draft does not require an IANA action.</t>
</section>
<section title="Acknowledgments">
<t>The author wishes acknowledge the contributions by Samita Chakrabarti, Erik Normark,
JP Vasseur, Eric Levy-Abegnoli, Patrick Wetterwald, Thomas Watteyne, and Behcet Sarikaya.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2119;
&RFC2460;
&RFC3810;
&RFC4291;
&RFC4429;
&RFC4443;
&RFC4861;
&RFC4862;
&RFC4944;
&RFC6282;
&RFC6275;
&RFC6550;
&RFC6655;
&RFC6775;
</references>
<references title='Informative References'>
&RFC3610;
&RFC3963;
&RFC3971;
&RFC3972;
&RFC4389;
&RFC4919;
&RFC6830;
&RFC7102;
&RFC7217;
<?rfc include='reference.I-D.ietf-6tisch-terminology.xml'?>
<?rfc include='reference.I-D.ietf-6tisch-architecture.xml'?>
<?rfc include='reference.I-D.ietf-6lo-6lobac.xml'?>
<?rfc include='reference.I-D.ietf-6lo-dect-ule.xml'?>
<?rfc include='reference.I-D.hong-6lo-ipv6-over-nfc.xml'?>
<?rfc include='reference.I-D.ietf-6lo-btle.xml'?>
<?rfc include='reference.I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks.xml'?>
<?rfc include='reference.I-D.brandt-6man-lowpanz.xml'?>
<?rfc include='reference.I-D.chakrabarti-nordmark-6man-efficient-nd.xml'?>
<?rfc include='reference.I-D.richardson-6tisch--security-6top.xml'?>
<?rfc include='reference.I-D.wijnands-bier-architecture.xml'?>
</references>
<section anchor='changes' title="Suggested Changes to Protocol Elements">
<section anchor='NS' title="ND Neighbor Solicitation (NS)">
<t>The NS message used for registration should use a source address that
respects the rules in <xref target="RFC6775"/>, <xref target="RFC4861"/>,
and <xref target="RFC4429"/> for DAD. The SLLA Option may be present but
only if the address passed DAD, and it is used to allow the 6LR to respond
as opposed to as a registration mechanism.
</t><t>
The address that is being registered is the target address in the NS message
and the TLLA Option must be present.
</t>
</section>
<section anchor='RA' title="ND Router Advertisement (RA)">
<t>
<xref target="I-D.chakrabarti-nordmark-6man-efficient-nd"/> adds an 'E'
bit in the Router Advertisement flag, as well as a new Registrar Address
Option (RAO). These fields are probably pertinent to LLNs inclusion into a
revised 6LoWPAN ND should be studied. If the new 6LoWPAN flows require
a change of behaviour (e.g. registering the Target of the NS message) then
the RA must indicate that the router supports the new capability, and the NS
must indicate that the Target is registered as opposed to the Source in an
unequivocal fashion.
</t><t>
There is some amount of duplication between the options in the RPL DIO
<xref target="RFC6550"/> and the options in the ND RA messages.
At the same time, there are a number of
options, including the 6LoWPAN Context Option (6CO) <xref target="RFC6775"/>,
the MTU and the SLLA Options <xref target="RFC4861"/> that can only
be found in the RA messages. Considering that these options are useful for
a joining node, the recommendation would be to associate the RA messages to
the join beacon, and make them rare when the network is stable. On the other
hand, the DIO message is to be used as the propagated heartbeat of the RPL
network and provide the sense of time and liveliness.
</t><t>
RAs should also be issued and the information therein propagated when a
change occurs in the information therein, such as a router or a prefix
lifetime.
</t>
</section>
<section anchor='DIO' title="RPL DODAG Information Object (DIO)">
<t>If the RPL root serves as 6LBR, it makes sense to add at least a bit of
information in the DIO to signal so. A Registrar Address Option (RAO) may
also be considered for addition.
</t>
</section>
<section anchor='trackingmess' title="ND Enhanced Address Registration Option (EARO)">
<t> The ARO option contains a Unique ID that is supposed to identify the
device across multiple registrations. It is envisioned that the
device could form a single CGA-based Unique Interface ID (CUID) to securely
bind all of its addresses.
The CUID would be used as Unique Interface Identifier in the ARO option and
to form a Link-Local address that would be deemed unique regardless of the
Link type.
Provided that the relevant cryptographic material is passed to the 6LBR upon
the first registration or on-demand at a later time, the 6LBR can validate
that a Node is effectively the owner of a CUID, and ensure that the
ownership of an Address stays with the CUID that registered it first.
</t><t> This option is designed to be used with standard NS and NA messages
between backbone Routers as well as between nodes and 6LRs over the LLN and
between the 6LBR and the 6BBR over whatever IP link they use to communicate.
<figure anchor='EARO' title="EARO">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|P|N| IDS |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Unique Interface Identifier (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<!--
TID: 1-byte integer; a transaction id that is maintained by the device
and incremented with each transaction.
it is recommended that the device maintains the TID in a persistent storage.
T flag: Set if the next octet is a TID.
N flag: Set if the device moved. If not set, the router will refrain from sending NA(O) after DAD in mixed mode.
The TID is really a sequence counter, and it is managed as described in section 7.2. Sequence Counter Operation of [RFC 6550]
-->
<t> The representation above is based on
<xref target="I-D.chakrabarti-nordmark-6man-efficient-nd"/>. Only the
proposed changes from that specification are discussed below but the
expectation is that 6LoWPAN ND and Efficient ND converge on the ARO
format.
<list style='hanging'>
<t hangText="Status:">8-bit integer. A new value of 3 is suggested to
indicate a rejection due to an obsolete TID, typically an indication of
a movement.
</t>
<t hangText="RPLInstanceID:">8-bit integer. This field is set to 0 when
unused. Otherwise it contains the RPLInstanceID for which this address
is registered, as specified in RPL <xref target="RFC6550"/>, and
discussed in particular in section 3.1.2.
</t>
<t hangText="P:">One bit flag.
When the bit is set, the address being registered is Target of the NS as
opposed to the Source, for instance to enable ND proxy operation.
</t>
<t hangText="N:">One bit flag. Set if the device moved.
If not set, the 6BBR will refrain from sending gratuitous NA(O) or other
form of distributed ND cache clean-up over the backbone.
For instance, the flag should be reset after the DAD operation upon
address formation.
</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 08:51:27 |