< draft-thubert-6lowpan-backbone-router-00.txt   draft-thubert-6lowpan-backbone-router-01.txt >
6LoWPAN P. Thubert 6LoWPAN P. Thubert
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track March 18, 2008 Intended status: Standards Track July 10, 2008
Expires: September 19, 2008 Expires: January 11, 2009
LoWPAN Backbone Router 6LoWPAN Backbone Router
draft-thubert-6lowpan-backbone-router-00 draft-thubert-6lowpan-backbone-router-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 19, 2008. This Internet-Draft will expire on January 11, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
ISA100.11a is a Working Group at the ISA SP100 standard committee ISA100.11a is a Working Group at the ISA SP100 standard committee
that covers Wireless Systems for Industrial Automation and Process that covers Wireless Systems for Industrial Automation and Process
Control. The WG is mandated to design a scalable, industrial grade Control. The WG is mandated to design a scalable, industrial grade
skipping to change at page 2, line 10 skipping to change at page 2, line 10
upcoming standard uses the 6LoWPAN format for the network header. It upcoming standard uses the 6LoWPAN format for the network header. It
also introduces the concept of a Backbone Router to merge small also introduces the concept of a Backbone Router to merge small
LoWPANs via a high speed transit and scale the ISA100.11a network. LoWPANs via a high speed transit and scale the ISA100.11a network.
This paper proposes an IPv6 version of the Backbone Router concept. This paper proposes an IPv6 version of the Backbone Router concept.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. New Neighbor Discovery options . . . . . . . . . . . . . . . . 6 4. Neighbor Binding messages . . . . . . . . . . . . . . . . . . 6
4.1. Binding Update Option . . . . . . . . . . . . . . . . . . 6 4.1. Binding Solicitation message . . . . . . . . . . . . . . . 7
4.2. Binding Acknowledgement Option . . . . . . . . . . . . . . 7 4.2. Binding Confirmation message . . . . . . . . . . . . . . . 8
5. LowPAN device operations . . . . . . . . . . . . . . . . . . . 8 5. LowPAN device operations . . . . . . . . . . . . . . . . . . . 10
5.1. Forming addresses . . . . . . . . . . . . . . . . . . . . 8 5.1. Forming addresses . . . . . . . . . . . . . . . . . . . . 10
5.2. Binding process . . . . . . . . . . . . . . . . . . . . . 9 5.2. Binding process . . . . . . . . . . . . . . . . . . . . . 11
5.3. Looking up neighbor addresses . . . . . . . . . . . . . . 9 5.3. Looking up neighbor addresses . . . . . . . . . . . . . . 12
5.4. Answering address look up . . . . . . . . . . . . . . . . 10 5.4. Answering address look up . . . . . . . . . . . . . . . . 12
6. Backbone router operations . . . . . . . . . . . . . . . . . . 10 6. Backbone router operations . . . . . . . . . . . . . . . . . . 13
6.1. Exposing the Backbone Router . . . . . . . . . . . . . . . 10 6.1. Exposing the Backbone Router . . . . . . . . . . . . . . . 13
6.2. Binding process . . . . . . . . . . . . . . . . . . . . . 11 6.2. Binding process . . . . . . . . . . . . . . . . . . . . . 14
6.3. Looking up neighbor addresses . . . . . . . . . . . . . . 11 6.3. Looking up neighbor addresses . . . . . . . . . . . . . . 15
6.4. Answering address look up . . . . . . . . . . . . . . . . 12 6.4. Answering address look up . . . . . . . . . . . . . . . . 15
6.5. Forwarding packets . . . . . . . . . . . . . . . . . . . . 12 6.5. Forwarding packets . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
ISA100.11a is a Working Group at the ISA SP100 standard committee ISA100.11a is a Working Group at the ISA SP100 standard committee
that covers Wireless Systems for Industrial Automation and Process that covers Wireless Systems for Industrial Automation and Process
Control. The ISA100.11a is mandated to design a scalable, industrial Control. The ISA100.11a is mandated to design a scalable, industrial
grade wireless network and application layer suite of protocols for grade wireless network and application layer suite of protocols for
low power devices such as sensors and actuators, with a response time low power devices such as sensors and actuators, with a response time
on the order of 100ms. on the order of 100ms.
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.
The ISA100.11a WG has also introduced the concept of a Backbone The ISA100.11a WG has also introduced the concept of a Backbone
Router that would interconnect small LoWPANs over a high speed Router that would interconnect small LoWPANs over a high speed
transit network and scale a single ISA100.11a network up to the transit network and scale a single ISA100.11a network up to the
thousands of nodes. thousands of nodes.
This paper specifies IP layer functionalities that are required to This paper specifies IP layer functionalities that are required to
implement a such Backbone Router with IPv6, in particular the implement the concept of a Backbone Router with IPv6, in particular
application of the "IP Version 6 Addressing Architecture" [RFC4291], the application of the "IP Version 6 Addressing Architecture"
"Neighbor Discovery for IP version 6" [RFC4861] and "IPv6 Stateless [RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6
Address Autoconfiguration" [RFC4862]. The use of EUI-64 based link Stateless Address Autoconfiguration" [RFC4862]. The use of EUI-64
local addresses, Neighbor Discovery Proxying and Optimistic Duplicate based link local addresses, Neighbor Discovery Proxying [RFC4389] and
Address Detection are discussed. Also, the concept of Transit Link Optimistic Duplicate Address Detection [RFC4429] are discussed.
is introduced to implement the transit network that is envisioned by Also, the concept of Transit Link is introduced to implement the
ISA100.11a. transit network that is envisioned by ISA100.11a.
This draft solves the problem of finding the other Backbone Router or An extension to the Neighbor Discovery Protocol is introduced to
gateway on the transit link from a 64 bits address that is used as enable LoWPAN nodes to register to one or more Backbone Routers that
interface ID for building a link local address. The Backbone Router acts as white board for address resolution. This feature enables to
acts as proxy for all nodes attached to it through a process of avoid the use of multicast over a Low power Wireless Personal Area
registration. The Backbone Router also acts as a server for all Network for the purpose of address resolution.
Neighbor Discovery flows from and to its nodes, avoiding the burden
of multicast over the LoWPAN. The Backbone Router might also acts as proxy for the Neighbor
Discovery Protocol for all nodes attached to it through a process of
registration 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 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.
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.
The way the PAN IDs and 16-bit short addresses are allocated and 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 distributed in the case of an 802.15.4 network is not covered by this
specification. This specification is compatible with a deployment specification. Similarly, the aspects of joining and securing the
where each Backbone Router is connected to a different PAN-ID that is network are out of scope.
managed locally, as well as a deployment where the whole transit link
and all nodes attached are a single PAN-ID. Similarly, the aspects
of joining and securing the network are out of scope.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Readers are expected to be familiar with all the terms and concepts Readers are expected to be familiar with all the terms and concepts
that are discussed in "Neighbor Discovery for IP version 6" that are discussed in "Neighbor Discovery for IP version 6"
[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
skipping to change at page 5, line 43 skipping to change at page 5, line 49
o o o o o o o o o o o o o o
LoWPAN LoWPAN LoWPAN LoWPAN LoWPAN LoWPAN
Figure 1: Transit Link and Backbone Routers Figure 1: Transit Link and Backbone Routers
In order to achieve this, the Transit link is used as reference for In order to achieve this, the Transit link is used as reference for
Neighbor Discovery operations, by extending the concept of a Home Neighbor Discovery operations, by extending the concept of a Home
Link as defined in [RFC3775] for Mobile IPv6. In particular, Link as defined in [RFC3775] for Mobile IPv6. In particular,
Backbone Routers perform ND proxying for the LoWPAN nodes in the Backbone Routers perform ND proxying for the LoWPAN nodes in the
LoWPANs they own. LoWPANs they own through a Primary registration.
The backbone router operation is compatible with that of a Home The backbone router operation is compatible with that of a Home
Agent. This enables mobility support for sensor devices that would Agent. This enables mobility support for sensor devices that would
move outside of the network delimited by the transit link. This also move outside of the network delimited by the transit link. This also
enables collocation of Home Agent functionality within Backbone enables collocation of Home Agent functionality within Backbone
Router functionality on the same interface of the router. Router functionality on the same interface of a router.
The Backbone Router is centric for ND operation inside the LoWPAN. The Backbone Router is centric for address resolution inside the
Part of the reason is the cost of the support for multicasting over LoWPAN. The raison d'etre of the Backbone Router is to eliminate the
the LoWPAN that this specification avoids for the Neighbor need of the support for multicasting over the LoWPAN for address
Solicitation flows. As a result, a LoWPAN node performs unicast resolution that the Neighbor Discovery flows normally require. This
exchanges to its Backbone Router to claim and lookup addresses, and is based on a white board registration model that uses anycast and
the Backbone Router proxies the ND requests over the Transit Link unicast only.
when necessary.
This specification documents the extensions to IPv6 Neighbor As a result, a LoWPAN node performs unicast exchanges to its Backbone
Discovery that enables a LoWPAN Node to claim and lookup addresses Router to claim and lookup addresses, and the Backbone Router proxies
using a Backbone Router as an intermediate proxy. The draft also the ND requests over the Transit Link when necessary.
documents the use of EUI-64 based link-local addresses and the way
they are claimed by the Backbone Routers over the transit link. In turn, the Backbone Routers operate as a distributed database of
all the LoWPAN 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 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.
For the purpose of Neighbor Discovery proxying, this specification For the purpose of Neighbor Discovery proxying, this specification
documents the LoWPAN binding cache, a conceptual data structure that documents the LoWPAN binding cache, a conceptual data structure that
is similar to the MIP6 binding cache. is similar to the MIP6 binding cache.
Another function of the Backbone Router is to perform 6LowPAN Another function of the Backbone Router is to perform 6LowPAN
compression and uncompression between the LoWPAN and the Transit Link compression and expansion between the LoWPAN and the Transit Link and
and ensure MTU compatibility. Packets flow uncompressed over the ensure MTU compatibility. Packets flow uncompressed over the Transit
Transit Link and are routed normally towards a Gateway or an Link and are routed normally towards a Gateway or an Application
Application sitting on the transit link or on a different link that sitting on the transit link or on a different link that is reachable
is reachable via IP. via IP.
4. New Neighbor Discovery options 4. Neighbor Binding messages
4.1. Binding Update Option This section introduces message formats for all messages used in this
specification. The new messages are all ICMP messages and extend the
capabilities of " the IPv6 Neighbor Discovery Protocol" [RFC4861]
The binding Update Option echoes the BU in [RFC3775] for Mobile IPv6. 4.1. Binding Solicitation message
At this stage of the specification, there is no control bit or
suboption. The BU option is used in Neighbor Solicitation messages
sent by the LoWPAN node to its Backbone Router for registration.
0 1 2 3 The Binding Sollicitation has a function similar to that of the
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 Binding Solicitation message in [RFC3775] for Mobile IPv6 and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [RFC3963] for NEMO. Any option that is not recognized MUST be
| Type | Length | Sequence # | skipped silently. The Binding Solicitation message is sent by the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LoWPAN node to its Backbone Router to register an address.
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NS BU option 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 is assigned to the sending
interface.
Destination Address: The well-known Backbone Router anycast address
6LOWPAN_BBR or 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". Type: 8-bit unsigned integer. Value is "to be assigned by IANA".
Length: 8-bit unsigned integer set to 1 when there is no suboption. Code: 0
The length of the option (including the type and length fields and
the suboptions) in units of 8 octets. Checksum: The ICMP checksum. See [RFC4443]
Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
P: Primary Flag. Set to indicate that the router is primary 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 that the node uses optimistic
addresses and can accept packets on the Binding Address even
before the binding is complete. The Router MUST always use 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 #: A 16-bit unsigned integer used by the receiving node to
sequence Binding Updates and by the sending node to match a sequence Binding Solicitation and by the sending node to match a
returned Binding Acknowledgement option with this Binding Update returned Binding Confirmation.
option.
Lifetime: 16-bit unsigned integer. The number of time units Lifetime: 32-bit unsigned integer. The number of seconds remaining
remaining before the binding MUST be considered expired. A value before the binding MUST be considered expired. A value of zero
of zero indicates that the Binding Cache entry for the mobile node indicates that the Binding Cache entry for the registered node
MUST be deleted. (In this case the specified care-of address MUST MUST be deleted.
also be set equal to the home address.) One time unit is 4
seconds.
4.2. Binding Acknowledgement Option Binding Address: The link-layer address that the sender wishes to
assign or maintain assigned to its interface.
The Binding Ack Option echoes the Binding Ack in [RFC3775] for Mobile Possible options
IPv6. At this stage of the specification, there is no control bit or
suboption. The Binding Ack option is used in Neighbor Advertisement
messages sent by the Backbone Router to a LoWPAN node to acknowledge
its registration. A status indicates the completion.
0 1 2 3 Target link-layer address: The link-layer address for the target,
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 i.e., the sender of the message. See [RFC4861]. The link-layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ address option MUST be included when the binding is created and
| Type | Length | Status | Reserved | MAY be omitted in renewal.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NA Binding Ack option MTU: Specifies the maximum size of a fragmented message that the
node stack can recompose. See [RFC4861] and [RFC4944].
4.2. Binding Confirmation message
The Binding Confirmation has a function similar to that of the
Binding Ack message in [RFC3775] for Mobile IPv6 and [RFC3963] for
NEMO. Any option that is not recognized MUST be skipped silently.
The Binding Confirmation message is sent by the Backbone Router node
to the LoWPAN node to confirm whether an IP address MAY be assigned
to an interface.
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Binding Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Binding Confirmation message format
IP fields
Source Address: An IP address assigned to the sending interface of
the router.
Destination Address: 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 is "to be assigned by IANA". Type: 8-bit unsigned integer. Value is "to be assigned by IANA".
Length: 8-bit unsigned integer set to 1 when there is no suboption. Code: 0
The length of the option (including the type and length fields and
the suboptions) in units of 8 octets.
Status: 8-bit unsigned integer indicating the disposition of the Checksum: The ICMP checksum. See [RFC4443]
Binding Update. Values of the Status field less than 128 indicate
that the Binding Update Option was accepted by the Backbone
Router. Values greater than or equal to 128 indicate that the
Binding Update was rejected by the Backbone Router. The following
Status values are currently defined:
0 Binding Update accepted (primary) Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
2 Binding Update accepted (secondary) P: Primary Flag. MUST echo the P flag in the Binding solicitation.
128 Reason unspecified X: Proxy Flag. Indicates that the route actually proxies for the
node. This can only happen if the P flag is set as well.
129 Administratively prohibited Sequence #: A 16-bit unsigned integer used by the receiving node to
sequence Binding Solicitation and by the sending node to match a
returned Binding Confirmation.
130 Insufficient resources Lifetime: 32-bit unsigned integer. The number of seconds remaining
before the binding MUST be considered expired. A value of zero
indicates that the Binding Cache entry for the registered node
MUST be deleted.
134 Duplicate Address Detection failed Binding Address: The link-layer address that the sender wishes to
assign or maintain assigned to its interface.
135 Duplicate Address Detection failed Possible options
Sequence #: 16-bit unsigned integer. The Sequence Number in the Source link-layer address: The link-layer address of the interface
Binding Acknowledgement is copied from the Sequence Number field from which the Router Advertisement is sent. See [RFC4861].
in the Binding Update. It is used by the LoWPAN node in matching
this Binding Acknowledgement with an outstanding Binding Update.
Lifetime: 16-bit unsigned integer. The granted lifetime, in time MTU: Specifies the maximum size of a fragmented message that the
units of 4 seconds, for which the Backbone Router SHOULD retain router stack can recompose. See [RFC4861] and [RFC4944].
the entry for this LoWPAN node in its Binding Cache. The value of
this field is undefined if the Status field indicates that the Prefix Information: The preferred address for the router. See
Binding Update was rejected. [RFC4861] and [RFC3775]. When this information is present, the
Source link-layer address option MUST be present as well. The
Prefix Information option MUST be included when the binding is
created and MAY be omitted in renewal.
5. LowPAN device operations 5. LowPAN device operations
5.1. Forming addresses 5.1. Forming addresses
All nodes are required to autoconfigure at least one address, a link- All nodes are required to autoconfigure at least one address, a link-
local address that is derived from the IEEE 64-bit extended media local address that is derived from the IEEE 64-bit extended media
access control address that is globally unique to the device. Link- access control address that is globally unique to the device. Link-
local address are described in section 2.5.6 of [RFC4291]. Appendix local address are described in section 2.5.6 of [RFC4291]. Appendix
A of that specification explains how the node builds an interface-ID 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" based on the IEEE 64-bit extended MAC address by inverting the "u"
(universal/local) bit. (universal/local) bit.
As a result, knowledge of the 64-bit address of another node on the As a result, knowledge of the 64-bit address of another node on the
same extended LoWPAN is enough to derive its link-local address and same extended LoWPAN is enough to derive its link-local address and
reach it over IP. Another consequence is that the link local address reach it over IP. Another consequence is that the link local address
is presumably unique on the Extended LoWPAN, which enables the use of is presumably unique on the Extended LoWPAN, which enables the use of
Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the
Transit Link and the LoWPAN. The address is created as optimistic to Transit Link and the LoWPAN. The address MAY be created as
enable its use in the binding process with the Backbone Router. optimistic to enable its use in the binding process with the Backbone
Router.
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 node and indicate so in the binding flows so
that the Backbone Router uses that address in its replies.
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 LoWPAN. 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 LoWPAN 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.
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).
The node might also form Unique Local and Global Unicast addresses, The node might also form Unique Local and Global Unicast addresses,
for instance if it needs to be reachable from the outside of the for instance if it needs to be reachable from the outside of the
Extended LoWPAN, or if it can manage its own mobility as prescribed Extended LoWPAN, or if it can manage its own mobility as prescribed
by Mobile IPv6 [RFC3775]. In that case, the node needs to bind each by Mobile IPv6 [RFC3775]. In that case, the node needs to bind each
individual address individually. individual address individually.
5.2. Binding process 5.2. Binding process
The binding process is very similar to that of a MIP6 mobile node, The binding process is very similar to that of a MIP6 mobile node,
though the messages used are Neighbor Discovery messages with new though the messages used are new Neighbor Discovery ICMP messages .
extensions to specify a binding relationship associated to the A LoWPAN node address is tentative or optimistic as long as the
advertisements. A LoWPAN Address is tentative as long as the binding binding is not confirmed by the Backbone Router.
is not confirmed by the Backbone Router.
The LoWPAN node uses unicast Neighbor Solicitations to perform the The LoWPAN node uses unicast Binding Solicitations to perform the
binding. The destination Address is that of the Backbone Router. binding. The destination Address is that of the Backbone Router or a
The source address the unspecified address as long as the address is well know anycast address 6LOWPAN_BBR that indicates the function of
still optimistic or tentative, and it is the link local address of the Backbone Routers. The source address is the unspecified address
the node after DAD is completed. The target address is the address as long as the address is still optimistic or tentative, and it is
being bound. A new binding-update option specifies parameters such the link local address of the node after it is successfully bound.
as the binding lifetime.
The acknowledgment to an NS is a unicast Neighbor Advertisement with The acknowledgment to a Binding Solicitation is a unicast Binding
a new Binding Acknowledgement option that contains the status of the Confirmation message that contains the status of the binding. The
binding. The source of the packet is the link-local address of the source of the packet is the link-local address of the Backbone
Backbone Router. The destination address is the link-local address Router. The destination address is a well-know anycast address
of the LoWPAN node, and the Target Address field contains the address 6LOWPAN_NODE unless the optimistic bit is set in the Binding
being bound. That unicast NA is not to be confused with the response Solicitation or the address was already bound, in which case the link
to a DAD and does not mean that the address is duplicated. local address of the node is used.
A bit in the Binding Acknowledgement option indicates whether the Upon successful completion in the Binding Confirmation message, the
Backbone Router has completed DAD and now owns the bound address over LoWPAN node sets the address from optimistic or tentative to
the Transit Link. If the bit is set, the LoWPAN node set the address preferred.
from optimistic to preferred.
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.
This specification also introduces the concept of secondary binding. This specification also introduces the concept of secondary binding.
For redundancy, a node might place a secondary binding with one or For redundancy, a node might place a secondary binding with one or
more other Backbone Routers over a same or different LoWPANs. A flag more other Backbone Routers over a same or different LoWPANs. The
in the binding option indicates whether the binding is secondary. 'P' flag in the Binding Solicitation message indicates whether the
binding is primary (set) or secondary (reset).
The Backbone Router might learn the PAN-ID and the 16-bit short
address from the NS message if it was not already known by another
means that is not within the scope of this specification.
5.3. Looking up neighbor addresses 5.3. Looking up neighbor addresses
A LoWPAN node does not use multicast for its Neighbor Solicitation. A LoWPAN node does not use multicast for its Neighbor Solicitation as
Whether for DAD or lookup purposes, all NS messages are sent in prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. For
unicast to the Backbone Router, that answers in unicast as well. 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.
The Target link-layer address in the response is either that of the The Target link-layer address in the response is either that of the
destination if a short cut is possible over the LoWPAN, or that of destination if a short cut is possible over the LoWPAN, or that of
the Backbone Router if the destination is reachable over the Transit the Backbone Router if the destination is reachable over the Transit
Link, in which case the Backbone Router will terminate 6LoWPAN and Link, in which case the Backbone Router will terminate 6LoWPAN and
relay the packet. relay the packet.
5.4. Answering address look up 5.4. Answering address look up
A LoWPAN node does not need to join the solicited-node multicast A LoWPAN node does not need to join the solicited-node multicast
skipping to change at page 10, line 28 skipping to change at page 13, line 14
6. Backbone router operations 6. Backbone router operations
6.1. Exposing the Backbone Router 6.1. Exposing the Backbone Router
The Backbone Router forms a link-local address in exactly the same The Backbone Router forms a link-local address in exactly the same
way as any other node on the LoWPAN. It uses the same link local way as any other node on the LoWPAN. It uses the same link local
address for the Transit Link and for all the associated LoWPAN(s) address for the Transit Link and for all the associated LoWPAN(s)
connected to that Backbone Router. connected to that Backbone Router.
The backbone router also configures the well known 6LOWPAN_BBR
anycast address on the LoWPAN interfaces where it serves as Backbone
Router. Note that The Backbone Router will accept registration
packets with a hop limit that is lower than 255 on that specific
address.
The Backbone Router announces itself using Router Advertisements (RA) The Backbone Router announces itself using Router Advertisements (RA)
messages that are broadcasted periodically over the LOWPAN. (note: messages that are broadcasted periodically over the LOWPAN. (note:
can we merge RA with some other maintenance packet or distribute the can we merge RA with some other maintenance packet or distribute the
info from the manager in some specific cases like ISA100.11a where info from the manager in some specific cases like ISA100.11a where
such a thing exists?). (also, when the node moves to another LoWPAN, such a thing exists?). (also, when the node moves to another LoWPAN,
is there a way to let it know faster which is the Backbone Router so is there a way to let it know faster which is the Backbone Router so
that it can stimulate a RA using RS?). that it can stimulate a RA using RS?).
A new option in the RA indicates the Backbone Router capability. In A new option in the RA indicates the Backbone Router capability. In
this way a node can learn the PAN-ID and the 16-bit short address for this way a node can learn the PAN-ID and the 16-bit short address for
skipping to change at page 11, line 4 skipping to change at page 13, line 43
The Backbone Router MAY also announce any prefix that is configured The Backbone Router MAY also announce any prefix that is configured
on the transit link, and serve as the default gateway for any node on on the transit link, and serve as the default gateway for any node on
the Transit Link or on the attached LoWPANs. the Transit Link or on the attached LoWPANs.
The transit link Maximum Transmission Unit serves as base for Path The transit link Maximum Transmission Unit serves as base for Path
MTU discovery and Transport layer Maximum Segment Size negotiation MTU discovery and Transport layer Maximum Segment Size negotiation
(see section 8.3 of [RFC2460]) for all nodes in the LoWPANs. To (see section 8.3 of [RFC2460]) for all nodes in the LoWPANs. To
achieve this, the Backbone Router announces the MTU of the transit achieve this, the Backbone Router announces the MTU of the transit
link over the LoWPAN using the MTU option in the RA message as link over the LoWPAN using the MTU option in the RA message as
prescribed in section "4.6.4. MTU" of IPv6 Neighbor Discovery prescribed in section "4.6.4. MTU" of IPv6 Neighbor Discovery
[RFC4861]. [RFC4861].
LoWPAN nodes SHOULD form IPv6 packets that are smaller than that MTU. LoWPAN nodes SHOULD form IPv6 packets that are smaller than that MTU.
As a result, those packets should not require any fragmentation over As a result, those packets should not require any fragmentation over
the transit link though they might be intranet-fragmented over the the transit link though they might be intranet-fragmented over the
LoWPAN itself as prescribed by [RFC4944]). LoWPAN itself as prescribed by [RFC4944]).
More information on the MTU issue with regard to ND-proxying can be More information on the MTU issue with regard to ND-proxying can be
found in Neighbor Discovery Proxies [RFC4389] and found in Neighbor Discovery Proxies [RFC4389] and
[I-D.van-beijnum-multi-mtu]. [I-D.van-beijnum-multi-mtu].
6.2. Binding process 6.2. Binding process
Upon a new binding for a link-local address based on a IEEE 64-bit Upon a new binding for a link-local address based on a IEEE 64-bit
extended MAC address, the Backbone Router uses Optimistic DAD on the extended MAC address, the Backbone Router MAY use Optimistic DAD on
Transit Link. Any other Backbone Router that would happen to have a the Transit Link. Any other Backbone Router that would happen to
binding for that same address SHOULD yield and deprecate its binding have a binding for that same address SHOULD yield and deprecate its
to secondary if it was primary. A positive acknowledgement can be binding to secondary if it was primary. A positive acknowledgement
sent to the LoWPAN node right away if oDAD is used on the Transit can be sent to the LoWPAN node right away if oDAD is used on the
Link. Transit Link. Note: A new option with a sequence number from the
Binding Solicitation should be used to select the winner
The Backbone Router operation on the transit link is similar to that The Backbone Router operation on the transit link is similar to that
of a Home Agent as specified in Mobility Support for IPv6 [RFC3775]. of a Home Agent as specified in Mobility Support for IPv6 [RFC3775].
In particular, the Neighbor Advertisement message is used as In particular, the Neighbor Advertisement message is used as
specified in section "10.4.1. Intercepting Packets for a Mobile specified in section "10.4.1. Intercepting Packets for a Mobile
Node" with one exception that the override (O) bit is not set, Node" with one exception that the override (O) bit is not set,
indicating that this Backbone Router acts as a proxy for the LoWPAN indicating that this Backbone Router acts as a proxy for the LoWPAN
and will yield should another Backbone Router claim that address on and will yield should another Backbone Router claim that address on
the Transit Link. This enables the LoWPAN node to join a different the Transit Link. This enables the LoWPAN node to join a different
Backbone Router at any time without the complexities of terminating a Backbone Router at any time without the complexities of terminating a
current binding. current binding.
This specification also introduces the concept of secondary binding. This specification also introduces the concept of secondary binding.
Upon a secondary binding, the Backbone Router will not announce or Upon a secondary binding, the Backbone Router will not announce or
defend the address on the transit link, but will be able to forward defend the address on the transit link, but will be able to forward
packets to the node over its LoWPAN interface. For other addresses, packets to the node over its LoWPAN interface. For other addresses,
the rules in [RFC3775] apply for compatibility. the rules in [RFC3775] apply for compatibility.
The Backbone Router responds to a Binding Solicitation with a Binding
Confirmation. The source address is a link local address of the
router and the destination is the well known 6LOWPAN_NODE address
unless a binding flow has already successfully completed in which
case the router MAY use the node's Binding. The router will also use
the Binding Address if the 'O' flag is raised in the Solicitation,
indicating that the node accepts packets on that address prior to a
successful binding but may not accept packets on the 6LOWPAN_NODE
address.
If the Backbone Router is primary for a registration (as indicated by
the 'P' flag) and it is connected to a Backbone, then it SHOULD
perform proxy ND operations on the backbone and indicate so in the
Confirmation message using the 'X' flag. In particular it SHOULD
reject the registration if DAD fails on the backbone. When oDAD is
used over the backbone the Backbone Router MAY issue the Binding
Confirmation right away with a positive code, but if a collision is
finally detected, it cancels the registration with an asynchronous
Binding Confirmation and a negative completion code.
6.3. Looking up neighbor addresses 6.3. Looking up neighbor addresses
A Backbone Router knows and proxies for all the IPv6 addresses that A Backbone Router knows and proxies for all the IPv6 addresses that
are registered to it. When resolving a target address, the Backbone are registered to it. When resolving a target address, the Backbone
Router first considers its binding cache. If this address is in the Router first considers its binding cache. If this address is in the
cache, then the target is reachable over the LoWPAN as indicated in cache, then the target is reachable over the LoWPAN as indicated in
the cache. Else, the Backbone Router locates the target over the the cache. Else, the Backbone Router locates the target over the
transit link using standard "Neighbor Discovery" [RFC4861] over that transit link using standard "Neighbor Discovery" [RFC4861] over that
link. link.
skipping to change at page 12, line 34 skipping to change at page 15, line 44
6LoWPAN and relay the packet. 6LoWPAN and relay the packet.
6.5. Forwarding packets 6.5. Forwarding packets
Upon receiving packets on one of its LoWPAN interfaces, the Backbone Upon receiving packets on one of its LoWPAN interfaces, the Backbone
Router checks whether it has a binding for the source address. If it Router checks whether it has a binding for the source address. If it
does, then the Backbone Router can forward the packet to another does, then the Backbone Router can forward the packet to another
LoWPAN node or over the Transit link. Otherwise, the Backbone Router LoWPAN node or over the Transit link. Otherwise, the Backbone Router
MUST discard the packet. If the packet is to be transmitted over the MUST discard the packet. If the packet is to be transmitted over the
Transit link, then the 6LoWPAN sublayer is terminated and the full Transit link, then the 6LoWPAN sublayer is terminated and the full
IPv6 packet is uncompressed and reassembled. IPv6 packet is reassembled and expanded.
When forwarding a packet from the Transit Link towards a LOwPAN When forwarding a packet from the Transit Link towards a LOwPAN
interface, the Backbone Router performs the 6LoWPAN sublayer interface, the Backbone Router performs the 6LoWPAN sublayer
operations of compression and fragmentation and passes the packet to operations of compression and fragmentation and passes the packet to
the lower layer for transmission. the lower layer for transmission.
7. Security Considerations 7. Security Considerations
This specification expects that the link layer is sufficiently This specification expects that the link layer is sufficiently
protected, either by means of physical or IP security for the Transit protected, either by means of physical or IP security for the Transit
skipping to change at page 13, line 10 skipping to change at page 16, line 22
prevents tempering with or replaying the RA messages. prevents tempering with or replaying the RA messages.
The use of EUI-64 for forming the Interface ID in the link local 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 prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
address privacy techniques. Considering the envisioned deployments address privacy techniques. Considering the envisioned deployments
and the MAC layer security applied, this is not considered an issue and the MAC layer security applied, this is not considered an issue
at this time. at this time.
8. IANA Considerations 8. IANA Considerations
Need new NS/NA option numbers for the binding flow. This specification requires 2 new ICMP types for the binding flow.
The is also a need for 2 new link local anycast addresses,
6LOWPAN_BBR for the routers and 6LOWPAN_NODE the nodes; those
addresses used as functional addresses.
9. Acknowledgments 9. Acknowledgments
The author wishes to thank Geoff Mulligan for his help and in-depth The author wishes to thank Geoff Mulligan for his help and in-depth
review. review.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 13, line 36 skipping to change at page 17, line 5
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006. 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, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
10.2. Informative References 10.2. Informative References
[I-D.van-beijnum-multi-mtu] [I-D.van-beijnum-multi-mtu]
Beijnum, I., "Extensions for Multi-MTU Subnets", Beijnum, I., "Extensions for Multi-MTU Subnets",
draft-van-beijnum-multi-mtu-02 (work in progress), draft-van-beijnum-multi-mtu-02 (work in progress),
February 2008. 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 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006. Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
 End of changes. 52 change blocks. 
186 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/