One document matched: draft-thubert-6lowpan-backbone-router-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!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 RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.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 I-D.van-beijnum-multi-mtu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.van-beijnum-multi-mtu.xml">
<!ENTITY I-D.ietf-6lowpan-nd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6lowpan-nd.xml">
<!ENTITY I-D.roll-rpl SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-rpl.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc category="std" ipr="trust200902" docName="draft-thubert-6lowpan-backbone-router-02">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>6LoWPAN Backbone Router</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization abbrev="Cisco">
Cisco Systems
</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>6LoWPAN</workgroup>
<abstract>
<t>
Some LLN subnets are expected to scale up to the thousands of nodes and hundreds of routers.
This paper proposes an IPv6 version of the Backbone Router concept that enables such a degree of scalability
using a high speed network as a backbone to the subnet.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t>
The ISA100.11a standard has introduced the concept of a Backbone Router
that would interconnect small LLNs over a high speed transit network and scale
a single ISA100.11a network up to the thousands of nodes. In that model
the LLNs and the backbone form a single subnet in which nodes can move freely
without the
need of renumbering, and the Backbone Router is a special kind of Border Router
designed to manage the interaction between the LLNs and the backbone at layer 3.
<!--How to implement the Backbone Router
will not be part of the initial release of the ISA100.11a standard.-->
Similar scalability requirements exist in the metering and monitoring industries.
In a network that large, it is impossible for a node to register to all Border Routers
as suggested for smaller topologies in <xref target="I-D.ietf-6lowpan-nd">
Neighbor Discovery Optimization for Low-power and Lossy Networks</xref>.
</t>
<t>
This paper specifies IP layer functionalities that are required to implement
the concept of a Backbone Router with IPv6, in particular the application of the
<xref target="RFC4291">"IP Version 6 Addressing Architecture"</xref>,
<xref target="RFC4861">" the Neighbor Discovery Protocol"</xref> and
<xref target="RFC4862">"IPv6 Stateless Address Autoconfiguration"</xref>.
</t><t>
The use of EUI-64 based link local addresses,
<xref target="RFC4389"> Neighbor Discovery Proxying </xref>,
<xref target="I-D.ietf-6lowpan-nd">Neighbor Discovery Optimization
for Low-power and Lossy Networks</xref>,
<xref target="I-D.ietf-roll-rpl">the IPv6 Routing Protocol for Low
power and Lossy Networks</xref> and
<xref target="RFC4429"> Optimistic Duplicate Address Detection </xref> are
discussed. Also, the concept of Transit Link is introduced to implement
the backbone network that was envisioned by ISA100.11a.
</t>
<t>This operation of the Backbone Router requires that some protocol operates
over the LLNs from which node registrations can be obtained, and that can disseminate the location
of the backbone Router over the LLN. Further expectations will be detailed.</t>
<t>
The way the PAN IDs and 16-bit short addresses are allocated and distributed
in the case of an 802.15.4 network is not covered by this specification.
Similarly, the aspects of joining and securing the network are out of scope.
The way the nodes in the LLN learn about their Backbone Router depends on the protocol
used in the LLN. In the case of RPL, a Border Router is the root of the DODAG
that it serves and represents all nodes attached to that DODAG.
</t>
<!-- t>
ISA100.11a is a Working Group at the ISA SP100 standard committee that covers
Wireless Systems for Industrial Automation and Process Control. The ISA100.11a is mandated to design a
scalable, industrial grade wireless network and application layer suite of
protocols for low power devices such as sensors and actuators, with
a response time on the order of 100ms.
</t -->
<!--
In order to meet industrial requirements for non-critical monitoring, alerting,
supervisory control, open loop control and some closed loop control
applications, the Working Group is leveraging advanced technology at every layer,
including a mix of DSSS and FHSS at the MAC/PHY layer,
path diversity at Data Link Layer, and endorsed the 6LoWPAN format for the
network header, making it possible to utilize IP based protocols such
as BACnet IP, Profibus IP and Modbus TCP without significant changes
to those protocols.
</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="I-D.ietf-6lowpan-nd">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>Readers would benefit from reading <xref target="RFC3775">
"Mobility Support in IPv6" </xref>, <xref target="RFC4389">
"Neighbor Discovery Proxies (ND Proxy)" </xref> and
<xref target="RFC4429">"Optimistic Duplicate Address Detection"
</xref> prior to this specification for a clear
understanding of the art in ND-proxying and binding.</t>
<t>Additionally, this document uses terminology from <xref
target="I-D.ietf-roll-terminology"></xref>, and introduces the following
terminology:
<list hangIndent="6" style="hanging">
<!--t hangText="LLN"></t>
<t>
Low-power wireless Personal Area Network. See <xref target="RFC4919"/>.
The same concept applies for small Wireless Sensor Networks.
</t-->
<t hangText="Backbone"></t>
<t>This is an IPv6 transit link that interconnects 2 or more Backbone Routers.
It is expected to be deployed as a high speed backbone in order to
federate a potentially large set of LLNS. Also referred to as a
LLN backbone or transit network.
</t>
<t hangText="Backbone Router"></t>
<t>An IPv6 router that federates the LLN using a transit link as a backbone.
</t>
<t hangText="Extended LLN"></t>
<t>This is the aggregation of multiple LLNs as defined in
<xref target="RFC4919"/> interconnected
by a Transit Link via Backbone Routers and forming a single IPv6 link.
</t>
<t hangText="Binding"></t>
<t>
The association of the LLN node IPv6 address and Interface ID
with associated proxying states including the remaining lifetime
of that association.
</t>
<t hangText="Registration"></t>
<t>
The process during which a LLN node injects its address in a protocol
through which the Border Router can learn the address and proxy ND for it.
</t>
<t hangText="Primary BR"></t>
<t>
The BR that will defend a registered address for the purpose of DAD over the backbone
</t>
<t hangText="Secondary BR"></t>
<t>
A BR to which the address is registered. A Secondary Router MAY advertise the address
over the backbone and proxy for it.
</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='overview' title="Overview">
<t>
A Transit Link that we'll refer to a the LLN Backbone federates multiple LLNs as a single IP subnet.
Each LLN in the subnet is anchored at a Backbone Router. The Backbone
Routers interconnect the LLNs over that Backbone Link. A node can move
freely from a LLN anchored at a Backbone Router to a LLN anchored at another Backbone Router
on the same backbone and conserve its link local and any other IPv6 address it has formed.
</t>
<figure anchor='figtransit'
title="Backbone Link and Backbone Routers">
<artwork><![CDATA[
---+------------------------
| Plant Network
|
+-----+
| | Gateway
| |
+-----+
|
| Transit Link
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
| | router | | router | | 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 o o o o o o o o o o o
o o o o o o o o o o
o o o o o o o
LLN LLN LLN
]]></artwork>
</figure>
<t>
The Backbone Link is used as reference for
Neighbor Discovery operations, by extending the concept of a Home Link
as defined in <xref target="RFC3775"/> for Mobile IPv6.
In particular, Backbone Routers perform ND proxying for the LLN nodes
in the LLNs they own through a node registration.
</t>
<t>
The Backbone Router operation is compatible with that of a Home Agent.
This enables mobility support for LLN devices that would move
outside of the network delimited by the transit link. This also enables
collocation of Home Agent functionality within Backbone Router
functionality on the same interface of a router.
</t>
<t>
A LLN node registers and claims ownership of its addresse(s) using
proactive acknowledged registration exchanges with a neighboring router.
In case of a complex LLN topology, the router might be an intermediate LLN
Router that relays the registration to the LBR as described for instance in
<xref target="I-D.ietf-6lowpan-nd"/> and <xref target="I-D.ietf-roll-rpl"/>.
In turn, the Backbone Routers operate as a distributed database of all the LLN
nodes and use the Neighbor Discovery Protocol to share that information across the
transit link in a reactive fashion.
</t>
<t>
For the purpose of Neighbor Discovery proxying, this specification documents
the LLN Master Neighbor Registry, a conceptual data structure that is similar to the
MIP6 binding cache. The Master Neighbor Registry is fed by redistributing addresses learnt
from the registration protocol used over the LLN.
</t>
<t>
Another function of the Backbone Router is to perform 6LoWPAN compression and
expansion between the LLN and the Transit Link and ensure MTU compatibility.
Packets flow uncompressed over the Transit Link and are routed normally towards
a Gateway or an Application sitting on the transit link or on a different
link that is reachable over the IP network.
</t>
</section>
<section anchor='mess' title="New types and formats">
<t>The specification expects that the protocol running on the LLN can provide
a sequence number called Transaction ID (TID) that is associated to the registration.
When a node registers to multiple BRs, it is expected that the same TID is used,
to enable the BR to correlate the registrations as being a single one, and
differentiate that situation from a movement. Otherwise, the resolution makes
it so that only the most recent registration was perceived from the highest TID
is kept.</t>
<t>The specification expects that the protocol running on the LLN can provide
a unique ID for the owner of the address that is being registered.
The Owner Unique ID enables to differentiate
a duplicate registration from a double registration. In case of a duplicate, the last
registration looses. The Owner Unique ID can be as simple as a EUI-64 burnin address, if
the device manufacturor is convinced that there can not be a manuf error that would
cause duplicate EUI64 addresses. Alternatively, the unique ID can be a hash of supposedly
unique information from multiple orthogonal sources, for instance:
<list style="symbols">
<t> Burn in address.
</t>
<t> configured address, id, security keys...
</t>
<t> (pseudo) Random number, radio link metrics ...
</t>
</list>
In any fashion, it is recommended that the device stores the unique Id in persistent memory.
Otherwise, it will be prevented to reregister after a reboot that would cause a loss of memory
until the Backbone Router times out the registration.
</t>
<t>The unique ID and the sequence number are placed in a new ND option that is used by the
Backbone Routers over the transit link to detect duplicates and movements. The option format
is as follows:
</t>
<section anchor='trackingmess' title="Binding Tracking Option">
<t> This option is designed to be used with standard NS and NA messages between backbone Routers
over a backbone link and may be used between LRs and LBRs over the LLN.
By using this option, the binding in question can be uniquely identified and matched with
the Master Neighbor Registry entries of each Backbone Router.</t>
<figure anchor='bto'
title="Binding Tracking Option">
<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 | TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Unique Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> Option Fields
<list style='hanging'>
<t hangText="Type:">
</t>
<t hangText="Length:">2
</t>
<t hangText="TID:">A unique Transaction ID assigned by the host in the associated
NR and used to match NC replies. The TID is set to zero when the node boots and then follows a
lollipop lifetime, wrapping direcly from 0xFFFF to 0x10.
</t>
<t hangText="Reserved:">This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
</t>
<t hangText="Owner Unique Identifier:">A globally unique identifier for the
host's interface associated with the binding for the NS/NA message
in question. This can be the EUI-64 derived IID of an interface, which can be hashed
with other supposedly unique information from multiple orthogonal sources.
</t>
</list>
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- section anchor='sdoperationfa' title="Forming addresses">
<t>
All nodes are required to autoconfigure at least one address, a link-local
address that is derived from the IEEE 64-bit extended media access control
address that is globally unique to the device.
Link-local address are described in section 2.5.6 of <xref target="RFC4291"/>.
Appendix A of that specification explains how the node builds an interface-ID
based on the IEEE 64-bit extended MAC address by inverting the "u"
(universal/local) bit.
</t>
<t>
As a result, knowledge of the 64-bit address of another node on the same
extended LLN is enough to derive its link-local address and reach it
over IP. Another consequence is that the link local address is presumably
unique on the Extended LLN, which enables the use of Optimistic Duplicate
Address Detection (oDAD) <xref target="RFC4429"/> over the Transit Link and
the LLN. The address MAY be created as optimistic to enable its use
in the binding process with the Backbone Router.
</t>
<t> Nodes should also autoconfigure the well known anycast address 6LoWPAN_NODE.
If they do not, they have to use their link local address in optimistic mode and
indicate so in the binding flows so that the Backbone Router uses that address in
its replies.
</t>
<t> Nodes MAY learn the address of the Backbone Routers using traditional means such as
configuration or the Neighbor Discovery Protocol Router Advertisement messages.
But those messages are multicast and might not be sent at a short interval or at all
over the LLN. This specification introduces a new anycast address 6LoWPAN_BBR that
the node can use to reach the nearest Backbone Router without previous knowledge
of that router address. This specification tolerates movement within the LLN
so the node does not have to stick with a given Backbone Router and MAY keep using the
6LoWPAN_BBR address for all its registrations.
</t>
<t>The Link Layer Address associated to the 6LoWPAN_BBR address is that of the PAN
coordinator unless the node has a specific reason to select an alternate next hop.
It is expected that the selected next hop has a route to the nearest Backbone Router
but the routing protocol involved is outside the scope of this specification. It
results that the next hop might have to forward the registration message and decrement
the Hop Limit. This is why the Backbone Router MUST accept Binding Solicitations
with a Hop Limit that is lower than 255 (min value TBD).</t>
<t>
The node might also form Unique Local and Global Unicast addresses, for
instance if it needs to be reachable from the outside of the Extended LLN,
or if it can manage its own mobility as prescribed by Mobile IPv6
<xref target="RFC3775"/>.
In that case, the node needs to bind each individual address individually.
</t>
</section -->
<!-- section anchor='sdoperationbind' title="Binding process">
<t>
The binding process is very similar to that of a MIP6 mobile node, though
the messages used are new Neighbor Discovery ICMP messages . A LLN node
address is tentative or optimistic as long as the binding is not confirmed by the
Backbone Router.
</t>
< !--
this specification, the source address of the packet MUST be the link-local
address of the device derived from the IEEE 64-bit extended MAC address.
This is how the Backbone Router learns about the nodes that it needs to proxy for
as well as the interface on which they are located.
-- >
<t>
The LLN node uses unicast Binding Solicitations to perform the binding.
The destination Address is that of the Backbone Router or a well know anycast address
6LoWPAN_BBR that indicates the function of the Backbone Routers. The source address is
the unspecified address as long as the address is still optimistic or tentative,
and it is the link local address of the node after it is successfully bound.
</t>
<t> The acknowledgment to a Binding Solicitation is a unicast Binding Confirmation
message that contains the status of the binding.
The source of the packet is the link-local address of the Backbone Router.
The destination address is a well-know anycast address 6LoWPAN_NODE unless the
optimistic bit is set in the Binding Solicitation or the address was already bound,
in which case the link local address of the node is used.
</t>
<t>
Upon successful completion in the Binding Confirmation message, the LLN node sets
the address from optimistic or tentative to preferred.
</t>
<t>
The 'X' flag in the Binding Confirmation message indicates that the Backbone
Router has completed DAD and now owns the Binding Address over the Transit Link.
</t>
<t>
This specification also introduces the concept of secondary binding.
For redundancy, a node might place a secondary binding with one or more
other Backbone Routers over a same or different LLNs. The 'P' flag in the Binding
Solicitation message indicates whether the binding is primary (set) or secondary
(reset).
</t>
</section -->
<!-- section anchor='sdoperationqa' title="Looking up neighbor addresses">
<t>
A LLN node does not use multicast for its Neighbor
Solicitation as prescribed by the ND protocol <xref target="RFC4861"/> and
oDAD <xref target="RFC4429"/>. For lookup purposes, all
NS messages are sent in unicast to the Backbone Router, that answers
in unicast as well. The message is a standard Neighbor Solicitation
but for the destination that set to the Backbone Router address or
the well known 6LoWPAN_BBR address as opposed to the
solicited-node multicast address for the destination address.
</t>
<t>
The Target link-layer address in the response is
either that of the destination if a short cut is possible over the
LLN, or that of the Backbone Router if the destination is reachable
over the Transit Link, in which case the Backbone Router will terminate 6LoWPAN
and relay the packet.
</t>
</section>
<section anchor='sdoperationaqa' title="Answering address look up">
<t>
A LLN node does not need to join the solicited-node multicast address
for its own addresses and should not have to answer a multicast
Neighbor Solicitation. It may be programmed to answer a unicast NS
but that is not required by this specification.
</t>
</section>
</section -->
<section anchor='opers' title="Backbone Router Operations">
<section anchor='concepts' title="Backbone Link and Router">
<t>The Backbone Router is a specific kind of Border Router that performs
proxy Neighbor Discovery on its backbone interface on behalf of the nodes that
it has discovered on its Low Power Lossy Network interfaces. On the LLN side,
the Backbone Router acquires its states about the nodes by terminating protocols
such as <xref target="I-D.ietf-roll-rpl">RPL</xref> or <xref target="I-D.ietf-6lowpan-nd">
6LoWPAN ND</xref> as a LLN Border Router. It is expected that the backbone
is the medium used to connect the subnet to the rest of the infrastructure, and
that all the LBRs are connected to that backbone and support the Backbone Router
feature as specified in this document.
</t>
<t>The backbone is expected to be a high speed, reliable transit link, with affordable multicast capabilities,
such as an Ethernet Network or a fully meshed NBMA network with multicast emulation, which allows a full support
of classical ND as specified in <xref target="RFC4861"/> and subsequent RFCs. In other words, the
backbone is not a LLN. Still, some restrictions of the attached LLNs will apply to the backbone. In
particular, it is expected that the MTU is set to the same value on the backbone and all attached
LLNs.
</t>
</section>
<section anchor='proxy' title="ND Proxy Operations">
<t>This specification enables a Backbone Router to proxy Neighbor Discovery
operations over the backbone on behalf
of the nodes that are registered to it, allowing any device on the backbone
to reach a LLN node as if it was on-link. </t>
<t>In the context of this specification, proxy ND means:
<list style="symbols">
<t> defending a registered address over the backbone using NA messages with the
Override bit set</t>
<t> advertising a registered address over the backbone using NA messages,
asynchronously or as a response to a Neighbor Solicitation messages.</t>
<t> Looking up a destination over the backbone in order to deliver packets
arriving from the LLN using Neighbor Sollicitation messages.</t>
<t>Forwarding packets from the LLN over the backkbone, and hte other way around.</t>
<t>Eventually triggering a look up for a destination over the LLN that would not be
registered at a given point of time, or as a verification of a registration.</t>
</list>
</t>
<t>
The draft introduces the concept of primary and secondary BRs. The concept is
defined with the granularity of an address, that is a given
BR can be primary for a given address and secondary or another one,
regardess on whether the addresses belong to the same node or not.
The primary Backbone Router is in charge of protecting the address for DAD over the
Backbone. Any of the Primary and Secondary BR may claim the address over the
backbone, since they are all capable to route from the backbone to the LLN device.</t>
<t>When the protocol used to register the nodes over the LLN is
<xref target="I-D.ietf-roll-rpl">RPL</xref>,
it is expected that one BR acts as virtual root coordinating LLN
BRs (with the same DODAGID) over the non-LLN backbone.
In that case, the virtual root may act as primary BR for
all addresses that it cares to support, whereas the physical
roots to which the node is attached are secondary BRs.
It is also possible in a given deployment that
the DODAGs are not coordinated. In that case,
there is no virtual root and no secondary BR; the DODAG
root is primary all the nodes registered to it over the backbone.</t>
<t>When the protocol used to register the nodes over the LLN is
<xref target="I-D.ietf-6lowpan-nd"> 6LoWPAN ND</xref>,
the Backbone Routers act as a distributed DAD table, using
classical ND over the backbone to detect duplication. This specification
requires that:
<list style="numbers">
<t>Registrations for all addresses that can be required to reach the device over the backbone,
including registrations for IPv6 addresses based on burn-in EUI64 addresses
are passed to the DAD table. </t>
<t> Nodes include the Binding Tracking Option in their NS used for registering those addresses
and the LRs propagate that option to the LBRs.
</t>
</list>
</t>
<t>
A false positive duplicate detection may arise over the backbone,
for instance if the node registers to more than one LBR,
or if the node has moved. Both situations are handled gracefully
unbeknownst to the node. In the former case,
one LBR becomes primary to defend the address over the
backbone while the others become secondary and may
still forward packets back and forth. In the latter case the LBR that receives
the newest registration wins and becomes primary.</t>
<!-- t>A Backbone Router advertises itself using a new option in the ND Router Advertisement
Message. A new anycast address 6LoWPAN_BBR is also introduced for the purpose of reaching the nearest
Backbone Router in the absence of any information. This enables to reduce the use of multicast
RAs for the router discovery operation. The routing to the nearest router that owns that anycast
address is out of scope for this specifiation.
</t -->
<!-- t> Another anycast address 6LoWPAN-NODE is introduced
to enable any LLN node to receive a response to its registration whether it completes
successfully or not.
</t -->
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='broperation' title="Claiming and defending">
<t>Upon a new or an updated registration, the BR performs a DAD operation.
If either a TID or a OUI is available, the BR places them in a
Binding Tracking Option in all its ND messages over the backbone.
If content is not available for a given field, it is set to 0.</t>
<t> If a primary already exists over the backbone, it will answer
the DAD with an RA.
<list style="symbols">
<t>If a RA is received with the O bit set, the primary rejects
the DAD and the DAD fails. the BR needs to inform the LLN protocol
that the address is a duplicate.</t>
<t>If a RA is received with the O bit reset, the primary accepts
the BR as secondary and DAD succeeds. The BR may install or maintain
its proxy states for that address. This router MAY advertise the address
using a NA. during a registration flow, it MAY set the O bit.</t>
<t>If no RA is received, this router assumes the role of primary
and DAD succeeds. The BR may install or maintain its proxy states
for that address. This router advertises the address using a NA
with the O bit reset.
</t>
</list>
</t>
<t>When the BR installs or maintains its proxy states for an address,
it sends an NA with a SLLA option for that address. The Primary
BR MAY set the O bit if it wished to attract the traffic for that
address.
</t>
</section>
<section anchor='broperationconflict' title="Conflict Resolution">
<t>A conflict arise when multiple BRs get a registration from a same address.
This situation might arise when a node moves from a BR to another,
when a node registers to multiple BRs, or in the RPL case when the
BRs belong to a single coordinated DODAG.</t>
<t> The primary looks up the Binding Tracking Option in ND messages
with a SLLA option.
<list style="symbols">
<t>If there is no option, normal ND operation takes place and
the primary defends the address with a NA with the O bit set,
adding the Binding Tracking Option with its own information.
</t>
<t>If there is a Binding Tracking Option and the OUIs are different,
then the conflict apparently happens between different nodes, and the
the primary defends the address with a NA with the O bit set,
adding the Binding Tracking Option with its own information.
If the TID in the Binding Tracking Option is in the
straight part of the lollipop, it is possible that the request
comes from the same node that has rebooted and formed a new OUI
The primary BR may assess its registered entry prior to answering.
</t>
<t>If there is a Binding Tracking Option and the OUIs are the same:
<list style="symbols">
<t> If the TID in the ND message is newer than the most recent one known by the
primary router, this is interpreted as a node moving. The primary cleans up
its states and stops defending the address.
</t>
<t> If the TID in the ND message is the same as the most recent one known by the
primary router, this is interpreted as a double registration. In case of a DAD,
the promary responds with a NA with the O bit reset, to confirm its position
as primary, including the Binding Tracking Option.
</t>
<t> If the TID in the ND message is older than the most recent one known by the
primary router, this is interpreted as a stale information. The primary defends
the address with a NA with the O bit set, adding the Binding Tracking Option
with its own information.
</t>
<t> If the TIDs are very different (more than 16 apart, discounting the straight part of
the lollipop), it is impossible to resolve for sure. The primary BR should assess its
registered entry prior to answering.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor='broperationasses' title="Assessing an entry">
<t>In a number of cases, it might happen that the information at the primary BR is stale
and obsolete. In particular, a node with no permanent storage might reboot and form a different OUI,
in which case the information at the BR is inaccurate and should be removed. In another case,
the Br and the node have been out of reach for too long and the TID that the BR maintains is so far out
that it is impossible to compare it with that stored at the BR.</t>
<t>In such situation, the primary Backbone Router has the possibility to assess the registration.
this is performed by the protocol in use to register the node over the LLN.
</t>
<t>When the protocol used to register the nodes over the LLN is
<xref target="I-D.ietf-roll-rpl">RPL</xref>, the BR sends a targetted DIS to
the registered address over the registered path. A DAO back indicates that the
current registration is still valid and provides the adequate data to resolve the
conflict.</t>
<t>When the protocol used to register the nodes over the LLN is
<xref target="I-D.ietf-6lowpan-nd"> 6LoWPAN ND</xref>,
TBD.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
This specification expects that the link layer is sufficiently protected, either
by means of physical or IP security for the Transit 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
tempering with or replaying the RA messages.
</t>
<t>
The use of EUI-64 for forming the Interface ID in the link local address prevents the usage
of Secure ND (<xref target="RFC3971"/> and <xref target="RFC3972"/>) and address privacy
techniques. Considering the envisioned deployments and the MAC layer security applied,
this is not considered an issue at this time.
</t>
</section>
<section title="IANA Considerations">
<t>A new type is requested for an ND option.</t>
</section>
<section title="Acknowledgments">
<t>The author wishes to thank Zach Shelby for their help and in-depth review.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2119;
&RFC2460;
&RFC3775;
&RFC4291;
&RFC4429;
&RFC4443;
&RFC4861;
&RFC4862;
&RFC4944;
</references>
<references title='Informative References'>
&RFC3963;
&RFC3971;
&RFC3972;
&RFC4389;
&RFC4919;
<?rfc include='reference.I-D.ietf-6lowpan-nd.xml'?>
<?rfc include='reference.I-D.ietf-roll-rpl.xml'?>
<?rfc include='reference.I-D.van-beijnum-multi-mtu.xml'?>
<?rfc include='reference.I-D.ietf-roll-terminology.xml'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:24:37 |