wdiff draft-thubert-6lowpan-backbone-router-01.txt draft-thubert-6lowpan-backbone-router-02.txt

6LoWPAN P. Thubert
Internet-Draft Cisco
Intended status: Standards Track July 10, 2008 June 6, 2010
Expires: January 11, 2009 December 8, 2010

6LoWPAN Backbone Router
draft-thubert-6lowpan-backbone-router-01
draft-thubert-6lowpan-backbone-router-02

Abstract

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.

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she

This Internet-Draft is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, submitted in accordance full conformance with Section 6 the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts.
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 11, 2009. December 8, 2010.

Abstract

ISA100.11a is a Working Group at the ISA SP100 standard committee
that covers Wireless Systems for Industrial Automation and Process
Control. The WG the persons identified as the
document authors. All rights reserved.

This document is mandated subject to design a scalable, industrial grade
LowPAN for devices such as sensors, valves, BCP 78 and actuators. The
upcoming standard uses the 6LoWPAN format for the network header. It
also introduces IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the concept date of a Backbone Router to merge small
LoWPANs via a high speed transit
publication of this document. Please review these documents
carefully, as they describe your rights and scale the ISA100.11a network.
This paper proposes an IPv6 version restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Backbone Router concept. Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6
4. Neighbor Binding messages . . . . . . . . . . . New types and formats . . . . . . . 6
4.1. Binding Solicitation message . . . . . . . . . . . . . 8
4.1. Binding Tracking Option . . 7
4.2. Binding Confirmation message . . . . . . . . . . . . . . . 8
5. LowPAN device operations . Backbone Router Operations . . . . . . . . . . . . . . . . . . 10
5.1. Forming addresses . . . Backbone Link and Router . . . . . . . . . . . . . . . . . 10
5.2. Binding process . . ND Proxy Operations . . . . . . . . . . . . . . . . . . . 11 10
5.3. Looking up neighbor addresses . . . . . . . . . . . . Claiming and defending . . 12
5.4. Answering address look up . . . . . . . . . . . . . . . . 12
6. Backbone router operations . . . . . . . . . . . . . . . . . . 13
6.1. Exposing the Backbone Router . . . . . . . . . . . . . . . 13
6.2. Binding process . . . . . . . . . . . . . . . . . . . . . 14
6.3. Looking up neighbor addresses . . . . . . . . . . .
5.4. Conflict Resolution . . . 15
6.4. Answering address look up . . . . . . . . . . . . . . . . 15
6.5. Forwarding packets 12
5.5. Assessing an entry . . . . . . . . . . . . . . . . . . . . 15
7. 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 20

1. Introduction

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.

The ISA100.11a WG standard has also introduced the concept of a Backbone
Router that would interconnect small LoWPANs 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.
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
Neighbor Discovery Optimization for Low-power and Lossy Networks
[I-D.ietf-6lowpan-nd].

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 "IP Version 6 Addressing Architecture"
[RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6
Stateless Address Autoconfiguration" [RFC4862].

The use of EUI-64 based link local addresses, Neighbor Discovery
Proxying [RFC4389] [RFC4389], Neighbor Discovery Optimization for Low-power
and Lossy Networks [I-D.ietf-6lowpan-nd], the IPv6 Routing Protocol
for Low power and Lossy Networks [I-D.ietf-roll-rpl] and Optimistic
Duplicate Address Detection [RFC4429] are discussed. Also, the
concept of Transit Link is introduced to implement the
transit backbone
network that is was envisioned by ISA100.11a.

An extension to the Neighbor Discovery Protocol is introduced to
enable LoWPAN nodes to register to one or more Backbone Routers that
acts as white board for address resolution.

This feature enables to
avoid the use operation of multicast over a Low power Wireless Personal Area
Network for the purpose of address resolution.

The Backbone Router might also acts as proxy for requires that some protocol
operates over the Neighbor
Discovery Protocol for all nodes attached to it through a process of
registration LLNs from which node registrations can be obtained,
and enables to merge multiple LoWPANs via a transit link
into a larger link.

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 that can disseminate the purpose location of reaching the nearest Backbone 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 over the nearest router that owns that anycast address is out of scope
for this specifiation.

Another anycast address 6LOWPAN-NODE is introduced to enable any
LowPAN node to receive a response to its registration whether it
completes successfully or not.
LLN. Further expectations will be detailed.

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.

2. Terminology

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 [RFC2119].

Readers are expected to be familiar with all the terms and concepts
that are discussed in "Neighbor Discovery for IP version 6"
[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919] [RFC4919],
Neighbor Discovery Optimization for Low-power and Lossy Networks
[I-D.ietf-6lowpan-nd] and "Transmission of IPv6 Packets over IEEE
802.15.4 Networks" [RFC4944].

Readers would benefit from reading "Mobility Support in IPv6"
[RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and
"Optimistic Duplicate Address Detection" [RFC4429] prior to this
specification for a clear understanding of the art in ND-proxying and
binding. This

Additionally, this document defines additional terms:

Transit Link uses terminology from
[I-D.ietf-roll-terminology], and introduces the following
terminology:

Backbone

This is an IPv6 transit link that interconnects 2 or more backbone
routers.
Backbone Routers. It is expected to be deployed as a high
speed backbone in order to federate a potentially large set of LoWPANS.
LLNS. Also referred to as a LoWPAN LLN backbone or transit network.

Backbone Router

An IPv6 router that interconnects federates the LoWPAN with LLN using a Transit Link. transit link as a
backbone.

Extended LoWPAN LLN

This is the aggregation of multiple LoWPANs LLNs as defined in
[RFC4919] interconnected by a Transit Link via Backbone Routers
and forming a single IPv6 link.

Binding
The association of the LoWPAN LLN node IPv6 address and Interface ID
with associated proxying states including the remaining
lifetime of that association.

Registration

The process during which a LoWPAN LLN node sends a Binding ND message
to injects its address in a Backbone
protocol through which the Border Router causing can learn the address
and proxy ND for it.

Primary BR

The BR that will defend a binding registered address for the LoWPAN node purpose of
DAD over the backbone

Secondary BR

A BR to be which the address is registered. A Secondary Router
MAY advertise the address over the backbone and proxy for it.

3. Overview

A Transit Link that we'll refer to a the LLN Backbone federates
multiple LoWPANs LLNs as a single IP link, the
extended LoWPAN. subnet. Each LoWPAN LLN in the subnet is
anchored at a Backbone Router. The Backbone Routers interconnect the LoWPANs
LLNs over the Transit that Backbone Link. A node can move freely from a LoWPAN LLN
anchored at a Backbone Router to a
LoWPAN LLN anchored at another Backbone
Router on the same Transit Link backbone and conserve its link local and any other
IPv6 address it has formed.

LoWPAN LoWPAN LoWPAN

LLN LLN LLN

Figure 1: Transit Backbone Link and Backbone Routers

In order to achieve this, the Transit link

The Backbone Link is used as reference for Neighbor Discovery
operations, by extending the concept of a Home Link as defined in
[RFC3775] for Mobile IPv6. In particular, Backbone Routers perform
ND proxying for the LoWPAN LLN nodes in the
LoWPANs LLNs they own through a Primary node
registration.

The backbone router Backbone Router operation is compatible with that of a Home
Agent. This enables mobility support for sensor 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.

The Backbone Router is centric for address resolution inside the
LoWPAN. The raison d'etre of the Backbone Router is to eliminate the
need

A LLN node registers and claims ownership of the support for multicasting over the LoWPAN for address
resolution that the Neighbor Discovery flows normally require. This
is based on a white board its addresse(s) using
proactive acknowledged registration model that uses anycast and
unicast only.

As exchanges with a result, neighboring
router. In case of a LoWPAN node performs unicast exchanges to its Backbone
Router to claim and lookup addresses, and complex LLN topology, the Backbone router might be an
intermediate LLN Router proxies that relays the ND requests over registration to the Transit Link when necessary. LBR as
described for instance in [I-D.ietf-6lowpan-nd] and
[I-D.ietf-roll-rpl]. In turn, the Backbone Routers operate as a
distributed database of all the LoWPAN LLN nodes and use the Neighbor
Discovery Protocol to share that information across the transit link.

This specification documents a Neighbor Binding protocol that enables
a LoWPAN Node to claim and lookup addresses using a Backbone Router
as link
in a white board.

This specification also documents the use of EUI-64 based link-local
addresses and the way they are claimed by the Backbone Routers over
the transit link. reactive fashion.

For the purpose of Neighbor Discovery proxying, this specification
documents the LoWPAN binding cache, 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.

Another function of the Backbone Router is to perform 6LowPAN 6LoWPAN
compression and expansion between the LoWPAN 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
via IP.
over the IP network.

4. Neighbor Binding messages

This section introduces message New types and formats for all messages used in this
specification.

The new messages are all ICMP messages and extend specification expects that the
capabilities of " protocol running on the IPv6 Neighbor Discovery Protocol" [RFC4861]

4.1. Binding Solicitation message

The Binding Sollicitation has LLN can
provide a function similar to that of the
Binding Solicitation message in [RFC3775] for Mobile IPv6 and
[RFC3963] for NEMO. Any option sequence number called Transaction ID (TID) that is not recognized MUST be
skipped silently. The Binding Solicitation message is sent by
associated to the
LoWPAN registration. When a node registers to its Backbone Router to register an address.

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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |O|P| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Binding Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Binding Solicitation message format

IP fields

Source Address: An IP address assigned to the sending interface, or
the unspecified address if no address multiple
BRs, it is assigned to the sending
interface.

Destination Address: The well-known Backbone Router anycast address
6LOWPAN_BBR or expected that the specific address of a given Backbone Router if
available.

Hop Limit: 255

ICMP fields
Type: 8-bit unsigned integer. Value is "to be assigned by IANA".

Code: 0

Checksum: The ICMP checksum. See [RFC4443]

Reserved: This field same TID is unused. It MUST be initialized used, to zero by
the sender and MUST be ignored by enable the receiver.

P: Primary Flag. Set BR to indicate that
correlate the router is primary registrations as being a single one, and MAY
proxy for the node if Proxy ND is used on the transit link. If
the flag is not set then the router MUST not proxy for the node.

O: Optimistic Flag. Set to indicate differentiate
that situation from a movement. Otherwise, the node uses optimistic
addresses and can accept packets on resolution makes it
so that only the Binding Address even
before most recent registration was perceived from the binding
highest TID is complete. kept.

The Router MUST always use specification expects that
Binding Address as destination for the response as opposed to the
well-known anywast address.

Sequence #: A 16-bit unsigned integer used by the receiving node to
sequence Binding Solicitation and by protocol running on the sending node to match LLN can
provide a
returned Binding Confirmation.

Lifetime: 32-bit unsigned integer. The number of seconds remaining
before unique ID for the binding MUST be considered expired. A value owner of zero
indicates that the Binding Cache entry for the registered node
MUST be deleted.

Binding Address: The link-layer address that the sender wishes to
assign or maintain assigned to its interface.

Possible options

Target link-layer address: is being
registered. The link-layer address for the target,
i.e., the sender Owner Unique ID enables to differentiate a duplicate
registration from a double registration. In case of a duplicate, the message. See [RFC4861].
last registration looses. The link-layer
address option MUST Owner Unique ID can be included when as simple as a
EUI-64 burnin address, if the binding device manufacturor is created and
MAY convinced that
there can not be omitted in renewal.

MTU: Specifies the maximum size of a fragmented message manuf error that would cause duplicate EUI64
addresses. Alternatively, the
node stack unique ID can recompose. See [RFC4861] and [RFC4944].

4.2. Binding Confirmation message

The Binding Confirmation has be a function similar hash of supposedly
unique information from multiple orthogonal sources, for instance:

o Burn in address.

o configured address, id, security keys...

o (pseudo) Random number, radio link metrics ...

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
Binding Ack message in [RFC3775] for Mobile IPv6
Backbone Router times out the registration.

The unique ID and [RFC3963] for
NEMO. Any the sequence number are placed in a new ND option
that is not recognized MUST be skipped silently.
The Binding Confirmation message is sent used by the Backbone Router node
to Routers over the LoWPAN node transit link to confirm whether an IP address MAY be assigned detect
duplicates and movements. The option format is as follows:

4.1. Binding Tracking Option

This option is designed to an interface. 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.

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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |X|P| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length | Lifetime TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Binding Address +
| |
+ Owner Unique Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: 2: Binding Confirmation message format

IP fields

Source Address: An IP address Tracking Option

Option Fields

Type:

Length: 2

TID: A unique Transaction ID assigned to by the sending interface of host in the router.

Destination Address: associated
NR and used to match NC replies. The well-known LoWPAN node anycast address
6LOWPAN_NODE or the Binding Address for the LoWPAN node.

Hop Limit: 255

ICMP fields

Type: 8-bit unsigned integer. Value TID is "to be assigned by IANA".

Code: 0

Checksum: The ICMP checksum. See [RFC4443] set to zero when the
node boots and then follows a lollipop lifetime, wrapping direcly
from 0xFFFF to 0x10.

Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.

P: Primary Flag. MUST echo the P flag in

Owner Unique Identifier: A globally unique identifier for the Binding solicitation.

X: Proxy Flag. Indicates that host's
interface associated with the route actually proxies binding for the
node. NS/NA message in
question. This can only happen if the P flag is set as well.

Sequence #: A 16-bit unsigned integer used by the receiving node to
sequence Binding Solicitation and by be the sending node to match a
returned Binding Confirmation.

Lifetime: 32-bit unsigned integer. The number EUI-64 derived IID of seconds remaining
before the binding MUST an interface,
which can be considered expired. A value hashed with other supposedly unique information from
multiple orthogonal sources.

5. Backbone Router Operations

5.1. Backbone Link and Router

The Backbone Router is a specific kind of zero
indicates Border Router that performs
proxy Neighbor Discovery on its backbone interface on behalf of the Binding Cache entry for the registered node
MUST be deleted.

Binding Address: The link-layer address
nodes that the sender wishes to
assign or maintain assigned to it has discovered on its interface.

Possible options

Source link-layer address: The link-layer address of Low Power Lossy Network
interfaces. On the interface
from which LLN side, the Backbone Router Advertisement is sent. See [RFC4861].

MTU: Specifies acquires its states
about the maximum size of nodes by terminating protocols such as RPL
[I-D.ietf-roll-rpl] or 6LoWPAN ND [I-D.ietf-6lowpan-nd] as a fragmented message LLN
Border Router. It is expected that the
router stack can recompose. See [RFC4861] and [RFC4944].

Prefix Information: The preferred address for the router. See
[RFC4861] and [RFC3775]. When this information backbone is present, the
Source link-layer address option MUST be present as well. The
Prefix Information option MUST be included when medium used
to connect the binding is
created and MAY be omitted in renewal.

5. LowPAN device operations

5.1. Forming addresses

All nodes are required subnet to autoconfigure at least one address, a link-
local address that is derived from the IEEE 64-bit extended media
access control address rest of the infrastructure, and that is globally unique to all
the device. Link-
local address LBRs are described in section 2.5.6 of [RFC4291]. Appendix
A of connected to that specification explains how backbone and support the node builds Backbone
Router feature as specified in this document.

The backbone is expected to be a high speed, reliable transit link,
with affordable multicast capabilities, such as an interface-ID
based on the IEEE 64-bit extended MAC address by inverting the "u"
(universal/local) bit.

As Ethernet Network
or a fully meshed NBMA network with multicast emulation, which allows
a result, knowledge full support of classical ND as specified in [RFC4861] and
subsequent RFCs. In other words, the 64-bit address backbone is not a LLN. Still,
some restrictions of another node on the
same extended LoWPAN is enough attached LLNs will apply to derive its link-local address and
reach the backbone.
In particular, it over IP. Another consequence is expected that the link local address MTU is presumably unique set to the same value
on the Extended LoWPAN, which backbone and all attached LLNs.

5.2. ND Proxy Operations

This specification enables the use of
Optimistic Duplicate Address Detection (oDAD) [RFC4429] a Backbone Router to proxy Neighbor
Discovery operations over the
Transit Link and backbone on behalf of the LoWPAN. The address MAY be created as
optimistic nodes that
are registered to enable its use in the binding process with the Backbone
Router.

Nodes should also autoconfigure it, allowing any device on the well known anycast address
6LOWPAN_NODE. If they do not, they have backbone to use their link local
address in optimistic reach a
LLN node and indicate so in the binding flows so
that as if it was on-link.

In the Backbone Router uses that context of this specification, proxy ND means:

o defending a registered address in its replies.

Nodes MAY learn over the backbone using NA messages
with the Override bit set

o advertising a registered address of over the Backbone Routers backbone using traditional
means such as configuration NA
messages, asynchronously or the as a response to a Neighbor Discovery Protocol Router
Advertisement
Solicitation messages. But those messages are multicast and might
not be sent at

o Looking up a short interval or at all destination over the LoWPAN. This
specification introduces a new anycast address 6LOWPAN_BBR that the
node can use backbone in order to reach deliver
packets arriving from the nearest Backbone Router without previous
knowledge of that router address. This specification tolerates
movement within LLN using Neighbor Sollicitation
messages.

o Forwarding packets from the LoWPAN so LLN over the node does not have to stick with a
given backbone router backkbone, and MAY keep using the 6LOWPAN_BBR address hte other
way around.

o Eventually triggering a look up for
all its registrations.

The Link Layer Address associated to a destination over the 6LOWPAN_BBR address is LLN
that would not be registered at a given point of the PAN coordinator unless the node has time, or as a specific reason to
select an alternate next hop. It is expected that the selected next
hop has
verification of a route to the nearest Backbone Router but the routing
protocol involved is outside registration.

The draft introduces the scope concept of this specification. It
results that the next hop might have to forward the registration
message primary and decrement the Hop Limit. This secondary BRs. The
concept is why the Backbone Router
MUST accept Binding Solicitations defined with a Hop Limit that is lower than
255 (min value TBD).

The node might also form Unique Local and Global Unicast addresses,
for instance if it needs to be reachable from the outside granularity of the
Extended LoWPAN, or if it can manage its own mobility as prescribed
by Mobile IPv6 [RFC3775]. In an address, that case, the node needs to bind each
individual address individually.

5.2. Binding process

The binding process is very similar to that of a MIP6 mobile node,
though the messages used are new Neighbor Discovery ICMP messages .
A LoWPAN node
given BR can be primary for a given address is tentative and secondary or optimistic as long as the
binding is not confirmed by another
one, regardess on whether the Backbone Router.

The LoWPAN node uses unicast Binding Solicitations addresses belong to perform the
binding. same node or
not. The destination Address is that of the primary Backbone Router or a
well know anycast address 6LOWPAN_BBR that indicates the function is in charge of protecting the Backbone Routers. The source
address is for DAD over the unspecified address
as long as Backbone. Any of the address is still optimistic or tentative, Primary and it is Secondary
BR may claim the link local address of over the node after it is successfully bound.

The acknowledgment backbone, since they are all
capable to a Binding Solicitation is a unicast Binding
Confirmation message that contains route from the status of backbone to the binding. The
source of LLN device.

When the packet is protocol used to register the link-local address of nodes over the Backbone
Router. The destination address LLN is a well-know anycast address
6LOWPAN_NODE unless the optimistic bit RPL
[I-D.ietf-roll-rpl], it is set in the Binding
Solicitation or expected that one BR acts as virtual root
coordinating LLN BRs (with the address was already bound, in which case same DODAGID) over the link
local address of non-LLN
backbone. In that case, the node is used.

Upon successful completion in virtual root may act as primary BR for
all addresses that it cares to support, whereas the Binding Confirmation message, physical roots to
which the
LoWPAN node sets the address from optimistic or tentative to
preferred.

The 'X' flag is attached are secondary BRs. It is also possible in the Binding Confirmation message indicates
a given deployment that the
Backbone Router has completed DAD DODAGs are not coordinated. In that
case, there is no virtual root and now owns no secondary BR; the Binding Address DODAG root is
primary all the nodes registered to it over the Transit Link.

This specification also introduces backbone.

When 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 LoWPANs. The
'P' flag in protocol used to register the Binding Solicitation message indicates whether nodes over the
binding LLN is primary (set) or secondary (reset).

5.3. Looking up neighbor addresses

A LoWPAN node does not use multicast for its Neighbor Solicitation as
prescribed by the 6LoWPAN
ND protocol [RFC4861] and oDAD [RFC4429]. For
lookup purposes, all NS messages are sent in unicast to [I-D.ietf-6lowpan-nd], the Backbone
Router, that answers in unicast Routers act as well. The message is a standard
Neighbor Solicitation but for distributed
DAD table, using classical ND over the destination backbone to detect
duplication. This specification requires that:

1. Registrations for all addresses that set can be required to reach the
Backbone Router address or
device over the well known 6LOWPAN_BBR address as
opposed backbone, including registrations for IPv6
addresses based on burn-in EUI64 addresses are passed to the solicited-node multicast address for DAD
table.

2. Nodes include the destination
address.

The Target link-layer address Binding Tracking Option in their NS used for
registering those addresses and the response is either LRs propagate that of option to
the
destination if a short cut is possible LBRs.

A false positive duplicate detection may arise over the LoWPAN, or that of
the Backbone Router backbone, for
instance if the destination is reachable over the Transit
Link, in which case the Backbone Router will terminate 6LoWPAN and
relay the packet.

5.4. Answering address look up

A LoWPAN node does not need registers to join more than one LBR, or if the solicited-node multicast
address for its own addresses and should not have to answer a
multicast Neighbor Solicitation. It may be programmed node
has moved. Both situations are handled gracefully unbeknownst to answer a
unicast NS but that is not required by this specification.

6. Backbone router operations

6.1. Exposing the Backbone Router

The Backbone Router forms a link-local address in exactly the same
way as any other node on
node. In the LoWPAN. It uses former case, one LBR becomes primary to defend the same link local
address for the Transit Link and for all over the associated LoWPAN(s)
connected to that Backbone Router.

The backbone router also configures while the well known 6LOWPAN_BBR
anycast address on others become secondary and may
still forward packets back and forth. In the LoWPAN interfaces where it serves as Backbone
Router. Note latter case the LBR
that The Backbone Router will accept receives the newest registration
packets with wins and becomes primary.

5.3. Claiming and defending

Upon a hop limit that is lower than 255 on that specific
address.

The Backbone Router announces itself using Router Advertisements (RA)
messages that are broadcasted periodically over the LOWPAN. (note:
can we merge RA with some other maintenance packet new or distribute an updated registration, the
info from BR performs a DAD
operation. If either a TID or a OUI is available, the manager BR places them
in some specific cases like ISA100.11a where
such a thing exists?). (also, when Binding Tracking Option in all its ND messages over the node moves to another LoWPAN,
backbone. If content is there not available for a way to let given field, it know faster which is set
to 0.

If a primary already exists over the Backbone Router so
that backbone, it can stimulate will answer the DAD
with an RA.

o If a RA using RS?).

A new option in is received with the RA indicates O bit set, the Backbone Router capability. In
this way a node can learn primary rejects the PAN-ID
DAD and the 16-bit short address for DAD fails. the Backbone Router if it was not already acquired from another
process BR needs to inform the LLN protocol
that the address is not covered by this specification.

The Backbone Router MAY also announce any prefix that a duplicate.

o If a RA is configured
on the transit link, and serve as received with the default gateway for any node on O bit reset, the Transit Link or on primary accepts the attached LoWPANs.

The transit link Maximum Transmission Unit serves
BR as base for Path
MTU discovery secondary and Transport layer Maximum Segment Size negotiation
(see section 8.3 of [RFC2460]) DAD succeeds. The BR may install or maintain
its proxy states for all nodes in the LoWPANs. To
achieve this, the Backbone Router announces the MTU of the transit
link over that address. This router MAY advertise the LoWPAN
address using the MTU option in the RA message as
prescribed in section "4.6.4. MTU" of IPv6 Neighbor Discovery
[RFC4861].

LoWPAN nodes SHOULD form IPv6 packets that are smaller than that MTU.
As a result, those packets should not require any fragmentation over
the transit link though they might be intranet-fragmented over NA. during a registration flow, it MAY set the
LoWPAN itself as prescribed by [RFC4944]).

More information on O
bit.

o If no RA is received, this router assumes the MTU issue with regard to ND-proxying can be
found in Neighbor Discovery Proxies [RFC4389] role of primary and
[I-D.van-beijnum-multi-mtu].

6.2. Binding process

Upon a new binding
DAD succeeds. The BR may install or maintain its proxy states for a link-local
that address. This router advertises the address based on using a IEEE 64-bit
extended MAC address, NA with
the Backbone Router MAY use Optimistic DAD on O bit reset.

When the Transit Link. Any other Backbone Router that would happen to
have BR installs or maintains its proxy states for an address, it
sends an NA with a binding SLLA option for that same address SHOULD yield and deprecate its
binding to secondary address. The Primary BR MAY
set the O bit if it was primary. A positive acknowledgement
can be sent wished to attract the LoWPAN node right away if oDAD is used on the
Transit Link. Note: traffic for that address.

5.4. Conflict Resolution

A new option with conflict arise when multiple BRs get a sequence number registration from the
Binding Solicitation should be used a same
address. This situation might arise when a node moves from a BR to
another, when a node registers to select multiple BRs, or in the winner

The Backbone Router operation on RPL case
when the transit link is similar BRs belong to that
of a Home Agent as specified in Mobility Support for IPv6 [RFC3775].
In particular, single coordinated DODAG.

The primary looks up the Neighbor Advertisement message is used as
specified Binding Tracking Option in section "10.4.1. Intercepting Packets for a Mobile
Node" ND messages with one exception that the override (O) bit is not set,
indicating that this Backbone Router acts as
a proxy for the LoWPAN SLLA option.

o If there is no option, normal ND operation takes place and will yield should another Backbone Router claim that address on
the Transit Link. This enables the LoWPAN node to join a different
Backbone Router at any time without the complexities of terminating a
current binding.

This specification also introduces the concept of secondary binding.
Upon a secondary binding, the Backbone Router will not announce or
defend
primary defends the address on the transit link, but will be able to forward
packets to with a NA with the node over its LoWPAN interface. For other addresses, O bit set, adding
the rules in [RFC3775] apply for compatibility.

The Backbone Router responds to a Binding Solicitation Tracking Option with a Binding
Confirmation. The source address its own information.

o If there is a link local address of Binding Tracking Option and the
router OUIs are different,
then the conflict apparently happens between different nodes, and
the destination is the well known 6LOWPAN_NODE primary defends the address
unless with a binding flow has already successfully completed in which
case the router MAY use NA with the node's Binding. The router will also use O bit set,
adding the Binding Address if Tracking Option with its own information. If
the TID in the 'O' flag Binding Tracking Option is raised in the Solicitation,
indicating straight part of
the lollipop, it is possible that the request comes from the same
node accepts packets on that address has rebooted and formed a new OUI The primary BR may
assess its registered entry prior to answering.

o If there is a
successful binding but may not accept packets on Binding Tracking Option and the 6LOWPAN_NODE
address. OUIs are the same:

* If the Backbone Router TID in the ND message is primary for a registration (as indicated newer than the most recent one
known by the 'P' flag) and it primary router, this is connected to interpreted as a Backbone, then it SHOULD
perform proxy ND operations on the backbone node
moving. The primary cleans up its states and indicate so in the
Confirmation message using stops defending
the 'X' flag. In particular it SHOULD
reject address.

* If the registration if DAD fails on TID in the backbone. When oDAD ND message is
used over the backbone same as the Backbone Router MAY issue most recent one
known by the Binding
Confirmation right away with primary router, this is interpreted as a positive code, but if double
registration. In case of a collision is
finally detected, it cancels DAD, the registration promary responds with an asynchronous
Binding Confirmation and a negative completion code.

6.3. Looking up neighbor addresses

A Backbone Router knows and proxies for all NA
with the IPv6 addresses that
are registered O bit reset, to it. When resolving a target address, the Backbone
Router first considers confirm its binding cache. If this address is in the
cache, then the target is reachable over the LoWPAN position as indicated in
the cache. Else, the Backbone Router locates the target over primary,
including the
transit link using standard "Neighbor Discovery" [RFC4861] over that
link. Binding Tracking Option.

* If the target is located over a LoWPAN owned by another Backbone
Router, then that other Backbone Router is TID in charge of answering the
Neighbor Solicitation on behalf of ND message is older than the target node.

6.4. Answering address look up

To enable proxying over most recent one
known by the Transit Link, primary router, this is interpreted as a Backbone Router must join stale
information. The primary defends the solicited-node multicast address on that link for all the
registered addresses of with a NA with
the nodes in its LoWPANs. The Backbone
Router answers O bit set, adding the Neighbor Solicitation Binding Tracking Option with a Neighbor
Advertisement that indicates its own link-layer address in the Target
link-layer address option.

A Backbone Router expects and answers unicast Neighbor Solicitations
for all nodes in its LoWPANs. It answers as a proxy for
information.

* If the real
target. The target link-layer address in TIDs are very different (more than 16 apart, discounting
the response is either that straight part of the destination if a short cut lollipop), it is possible over the LoWPAN, or
that impossible to resolve
for sure. The primary BR should assess its registered entry
prior to answering.

5.5. Assessing an entry

In a number of cases, it might happen that the Backbone Router if information at the destination
primary BR is reachable over the
Transit Link, stale and obsolete. In particular, a node with no
permanent storage might reboot and form a different OUI, in which
case the Backbone Router will terminate
6LoWPAN information at the BR is inaccurate and relay should be removed.
In another case, the packet.

6.5. Forwarding packets

Upon receiving packets on one of its LoWPAN interfaces, Br and the Backbone
Router checks whether it has a binding node have been out of reach for too
long and the source address. If TID that the BR maintains is so far out that it
does, then is
impossible to compare it with that stored at the BR.

In such situation, the primary Backbone Router can forward has the packet possibility to another
LoWPAN
assess the registration. this is performed by the protocol in use to
register the node or over the Transit link. Otherwise, LLN.

When the Backbone Router
MUST discard protocol used to register the packet. If nodes over the packet LLN is RPL
[I-D.ietf-roll-rpl], the BR sends a targetted DIS to be transmitted the registered
address over the
Transit link, then registered path. A DAO back indicates that the 6LoWPAN sublayer
current registration is terminated still valid and provides the full
IPv6 packet is reassembled and expanded. adequate data to
resolve the conflict.

When forwarding a packet from the Transit Link towards a LOwPAN
interface, protocol used to register the Backbone Router performs nodes over the LLN is 6LoWPAN sublayer
operations of compression and fragmentation and passes the packet to
the lower layer for transmission.

7.
ND [I-D.ietf-6lowpan-nd], TBD.

6. Security Considerations

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 LoWPAN 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.

The use of EUI-64 for forming the Interface ID in the link local
address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
address privacy techniques. Considering the envisioned deployments
and the MAC layer security applied, this is not considered an issue
at this time.

7. IANA Considerations

This specification requires 2

A new ICMP types for the binding flow.
The type is also a need requested for 2 new link local anycast addresses,
6LOWPAN_BBR for the routers and 6LOWPAN_NODE the nodes; those
addresses used as functional addresses.

9. an ND option.

8. Acknowledgments

The author wishes to thank Geoff Mulligan Zach Shelby for his their help and in-depth
review.

10.

9. References

10.1.

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.

[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.

[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.

[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.

10.2.

9.2. Informative References

[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low-power and Lossy Networks",
draft-ietf-6lowpan-nd-09 (work in progress), April 2010.

[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
Protocol for Low power and Lossy Networks",
draft-ietf-roll-rpl-08 (work in progress), May 2010.

[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-03 (work in
progress), March 2010.

[I-D.van-beijnum-multi-mtu]
Beijnum, I., "Extensions for Multi-MTU Subnets",
draft-van-beijnum-multi-mtu-02 (work in progress),
February 2008.

[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.

[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.

[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.

[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.

Author's Address

Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE

Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).