< draft-thubert-6lowpan-backbone-router-01.txt   draft-thubert-6lowpan-backbone-router-02.txt >
6LoWPAN P. Thubert 6LoWPAN P. Thubert
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track July 10, 2008 Intended status: Standards Track June 6, 2010
Expires: January 11, 2009 Expires: December 8, 2010
6LoWPAN Backbone Router 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- 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 Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on December 8, 2010.
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.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract
ISA100.11a is a Working Group at the ISA SP100 standard committee This document is subject to BCP 78 and the IETF Trust's Legal
that covers Wireless Systems for Industrial Automation and Process Provisions Relating to IETF Documents
Control. The WG is mandated to design a scalable, industrial grade (http://trustee.ietf.org/license-info) in effect on the date of
LowPAN for devices such as sensors, valves, and actuators. The publication of this document. Please review these documents
upcoming standard uses the 6LoWPAN format for the network header. It carefully, as they describe your rights and restrictions with respect
also introduces the concept of a Backbone Router to merge small to this document. Code Components extracted from this document must
LoWPANs via a high speed transit and scale the ISA100.11a network. include Simplified BSD License text as described in Section 4.e of
This paper proposes an IPv6 version of the Backbone Router concept. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Neighbor Binding messages . . . . . . . . . . . . . . . . . . 6 4. New types and formats . . . . . . . . . . . . . . . . . . . . 8
4.1. Binding Solicitation message . . . . . . . . . . . . . . . 7 4.1. Binding Tracking Option . . . . . . . . . . . . . . . . . 8
4.2. Binding Confirmation message . . . . . . . . . . . . . . . 8 5. Backbone Router Operations . . . . . . . . . . . . . . . . . . 10
5. LowPAN device operations . . . . . . . . . . . . . . . . . . . 10 5.1. Backbone Link and Router . . . . . . . . . . . . . . . . . 10
5.1. Forming addresses . . . . . . . . . . . . . . . . . . . . 10 5.2. ND Proxy Operations . . . . . . . . . . . . . . . . . . . 10
5.2. Binding process . . . . . . . . . . . . . . . . . . . . . 11 5.3. Claiming and defending . . . . . . . . . . . . . . . . . . 12
5.3. Looking up neighbor addresses . . . . . . . . . . . . . . 12 5.4. Conflict Resolution . . . . . . . . . . . . . . . . . . . 12
5.4. Answering address look up . . . . . . . . . . . . . . . . 12 5.5. Assessing an entry . . . . . . . . . . . . . . . . . . . . 13
6. Backbone router operations . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Exposing the Backbone Router . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.2. Binding process . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Looking up neighbor addresses . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Answering address look up . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.5. Forwarding packets . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
ISA100.11a is a Working Group at the ISA SP100 standard committee The ISA100.11a standard has introduced the concept of a Backbone
that covers Wireless Systems for Industrial Automation and Process Router that would interconnect small LLNs over a high speed transit
Control. The ISA100.11a is mandated to design a scalable, industrial network and scale a single ISA100.11a network up to the thousands of
grade wireless network and application layer suite of protocols for nodes. In that model the LLNs and the backbone form a single subnet
low power devices such as sensors and actuators, with a response time in which nodes can move freely without the need of renumbering, and
on the order of 100ms. the Backbone Router is a special kind of Border Router designed to
manage the interaction between the LLNs and the backbone at layer 3.
The ISA100.11a WG has also introduced the concept of a Backbone Similar scalability requirements exist in the metering and monitoring
Router that would interconnect small LoWPANs over a high speed industries. In a network that large, it is impossible for a node to
transit network and scale a single ISA100.11a network up to the register to all Border Routers as suggested for smaller topologies in
thousands of nodes. Neighbor Discovery Optimization for Low-power and Lossy Networks
[I-D.ietf-6lowpan-nd].
This paper specifies IP layer functionalities that are required to This paper specifies IP layer functionalities that are required to
implement the concept of a Backbone Router with IPv6, in particular implement the concept of a Backbone Router with IPv6, in particular
the application of the "IP Version 6 Addressing Architecture" the application of the "IP Version 6 Addressing Architecture"
[RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6 [RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6
Stateless Address Autoconfiguration" [RFC4862]. The use of EUI-64 Stateless Address Autoconfiguration" [RFC4862].
based link local addresses, Neighbor Discovery Proxying [RFC4389] and
Optimistic Duplicate Address Detection [RFC4429] are discussed.
Also, the concept of Transit Link is introduced to implement the
transit network that is 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 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 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 The use of EUI-64 based link local addresses, Neighbor Discovery
Router Advertisement Message. A new anycast address 6LOWPAN_BBR is Proxying [RFC4389], Neighbor Discovery Optimization for Low-power
also introduced for the purpose of reaching the nearest Backbone and Lossy Networks [I-D.ietf-6lowpan-nd], the IPv6 Routing Protocol
Router in the absence of any information. This enables to reduce the for Low power and Lossy Networks [I-D.ietf-roll-rpl] and Optimistic
use of multicast RAs for the router discovery operation. The routing Duplicate Address Detection [RFC4429] are discussed. Also, the
to the nearest router that owns that anycast address is out of scope concept of Transit Link is introduced to implement the backbone
for this specifiation. network that was envisioned by ISA100.11a.
Another anycast address 6LOWPAN-NODE is introduced to enable any This operation of the Backbone Router requires that some protocol
LowPAN node to receive a response to its registration whether it operates over the LLNs from which node registrations can be obtained,
completes successfully or not. and that can disseminate the location of the backbone Router over the
LLN. Further expectations will be detailed.
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. Similarly, the aspects of joining and securing the specification. Similarly, the aspects of joining and securing the
network are out of scope. 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 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],
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. 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" Readers would benefit from reading "Mobility Support in IPv6"
[RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and [RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and
"Optimistic Duplicate Address Detection" [RFC4429] prior to this "Optimistic Duplicate Address Detection" [RFC4429] prior to this
specification for a clear understanding of the art in ND-proxying and specification for a clear understanding of the art in ND-proxying and
binding. This document defines additional terms: binding.
Transit Link Additionally, this document uses terminology from
[I-D.ietf-roll-terminology], and introduces the following
terminology:
This is an IPv6 link that interconnects 2 or more backbone Backbone
routers. It is expected to be deployed as a high speed backbone
in order to federate a potentially large set of LoWPANS. Also This is an IPv6 transit link that interconnects 2 or more
referred to as a LoWPAN backbone or transit network. Backbone Routers. It is expected to be deployed as a high
speed backbone in order to federate a potentially large set of
LLNS. Also referred to as a LLN backbone or transit network.
Backbone Router Backbone Router
An IPv6 router that interconnects the LoWPAN with a Transit Link. An IPv6 router that federates the LLN using a transit link as a
backbone.
Extended LoWPAN Extended LLN
This is the aggregation of multiple LoWPANs as defined in This is the aggregation of multiple LLNs as defined in
[RFC4919] interconnected by a Transit Link via Backbone Routers [RFC4919] interconnected by a Transit Link via Backbone Routers
and forming a single IPv6 link. and forming a single IPv6 link.
Binding Binding
The association of the LLN node IPv6 address and Interface ID
The association of the LoWPAN node IPv6 address and Interface ID with associated proxying states including the remaining
with associated proxying states including the remaining lifetime lifetime of that association.
of that association.
Registration Registration
The process during which a LoWPAN node sends a Binding ND message The process during which a LLN node injects its address in a
to a Backbone Router causing a binding for the LoWPAN node to be protocol through which the Border Router can learn the address
registered. and proxy ND for it.
Primary BR
The BR that will defend a registered address for the purpose of
DAD over the backbone
Secondary BR
A BR to which the address is registered. A Secondary Router
MAY advertise the address over the backbone and proxy for it.
3. Overview 3. Overview
A Transit Link federates multiple LoWPANs as a single IP link, the A Transit Link that we'll refer to a the LLN Backbone federates
extended LoWPAN. Each LoWPAN is anchored at a Backbone Router. The multiple LLNs as a single IP subnet. Each LLN in the subnet is
Backbone Routers interconnect the LoWPANs over the Transit Link. A anchored at a Backbone Router. The Backbone Routers interconnect the
node can move freely from a LoWPAN anchored at a Backbone Router to a LLNs over that Backbone Link. A node can move freely from a LLN
LoWPAN anchored at another Backbone Router on the same Transit Link anchored at a Backbone Router to a LLN anchored at another Backbone
and conserve its link local and any other IPv6 address it has formed. Router on the same backbone and conserve its link local and any other
IPv6 address it has formed.
---+------------------------ ---+------------------------
| Plant Network | Plant Network
| |
+-----+ +-----+
| | Gateway | | Gateway
| | | |
+-----+ +-----+
| |
| Transit Link | Transit Link
skipping to change at page 5, line 41 skipping to change at page 6, line 36
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone | | Backbone | | Backbone | | Backbone
| | router | | router | | router | | router | | router | | router
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o
LoWPAN LoWPAN LoWPAN LLN LLN LLN
Figure 1: Transit Link and Backbone Routers Figure 1: Backbone Link and Backbone Routers
In order to achieve this, the Transit link is used as reference for The Backbone Link is used as reference for Neighbor Discovery
Neighbor Discovery operations, by extending the concept of a Home operations, by extending the concept of a Home Link as defined in
Link as defined in [RFC3775] for Mobile IPv6. In particular, [RFC3775] for Mobile IPv6. In particular, Backbone Routers perform
Backbone Routers perform ND proxying for the LoWPAN nodes in the ND proxying for the LLN nodes in the LLNs they own through a node
LoWPANs they own through a Primary registration. 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 LLN devices that would move
move outside of the network delimited by the transit link. This also 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 a router. Router functionality on the same interface of a router.
The Backbone Router is centric for address resolution inside the A LLN node registers and claims ownership of its addresse(s) using
LoWPAN. The raison d'etre of the Backbone Router is to eliminate the proactive acknowledged registration exchanges with a neighboring
need of the support for multicasting over the LoWPAN for address router. In case of a complex LLN topology, the router might be an
resolution that the Neighbor Discovery flows normally require. This intermediate LLN Router that relays the registration to the LBR as
is based on a white board registration model that uses anycast and described for instance in [I-D.ietf-6lowpan-nd] and
unicast only. [I-D.ietf-roll-rpl]. In turn, the Backbone Routers operate as a
distributed database of all the LLN nodes and use the Neighbor
As a result, a LoWPAN node performs unicast exchanges to its Backbone Discovery Protocol to share that information across the transit link
Router to claim and lookup addresses, and the Backbone Router proxies in a reactive fashion.
the ND requests over the Transit Link when necessary.
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 LLN Master Neighbor Registry, a conceptual data
is similar to the MIP6 binding cache. 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 Another function of the Backbone Router is to perform 6LoWPAN
compression and expansion between the LoWPAN and the Transit Link and compression and expansion between the LLN and the Transit Link and
ensure MTU compatibility. Packets flow uncompressed over the Transit ensure MTU compatibility. Packets flow uncompressed over the Transit
Link and are routed normally towards a Gateway or an Application Link and are routed normally towards a Gateway or an Application
sitting on the transit link or on a different link that is reachable 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 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]
4.1. Binding Solicitation message
The Binding Sollicitation has a function similar to that of the
Binding Solicitation message in [RFC3775] for Mobile IPv6 and
[RFC3963] for NEMO. Any option that is not recognized MUST be
skipped silently. The Binding Solicitation message is sent by the
LoWPAN node 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 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".
Code: 0
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 Binding Solicitation and by the sending node to match a
returned Binding Confirmation.
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.
Binding Address: The link-layer address that the sender wishes to 4. New types and formats
assign or maintain assigned to its interface.
Possible options The specification expects that the protocol running on the LLN can
provide a sequence number called Transaction ID (TID) that is
associated to the registration. When a node registers to multiple
BRs, it is expected that the same TID is used, to enable the BR to
correlate the registrations as being a single one, and differentiate
that situation from a movement. Otherwise, the resolution makes it
so that only the most recent registration was perceived from the
highest TID is kept.
Target link-layer address: The link-layer address for the target, The specification expects that the protocol running on the LLN can
i.e., the sender of the message. See [RFC4861]. The link-layer provide a unique ID for the owner of the address that is being
address option MUST be included when the binding is created and registered. The Owner Unique ID enables to differentiate a duplicate
MAY be omitted in renewal. registration from a double registration. In case of a duplicate, the
last registration looses. The Owner Unique ID can be as simple as a
EUI-64 burnin address, if the device manufacturor is convinced that
there can not be a manuf error that would cause duplicate EUI64
addresses. Alternatively, the unique ID can be a hash of supposedly
unique information from multiple orthogonal sources, for instance:
MTU: Specifies the maximum size of a fragmented message that the o Burn in address.
node stack can recompose. See [RFC4861] and [RFC4944].
4.2. Binding Confirmation message o configured address, id, security keys...
The Binding Confirmation has a function similar to that of the o (pseudo) Random number, radio link metrics ...
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 In any fashion, it is recommended that the device stores the unique
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 Id in persistent memory. Otherwise, it will be prevented to
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reregister after a reboot that would cause a loss of memory until the
| Type | Code | Checksum | Backbone Router times out the registration.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |X|P| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Binding Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Binding Confirmation message format The unique ID and the sequence number are placed in a new ND option
that is used by the Backbone Routers over the transit link to detect
duplicates and movements. The option format is as follows:
IP fields 4.1. Binding Tracking Option
Source Address: An IP address assigned to the sending interface of This option is designed to be used with standard NS and NA messages
the router. 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.
Destination Address: The well-known LoWPAN node anycast address 0 1 2 3
6LOWPAN_NODE or the Binding Address for the LoWPAN node. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Unique Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop Limit: 255 Figure 2: Binding Tracking Option
ICMP fields Option Fields
Type: 8-bit unsigned integer. Value is "to be assigned by IANA". Type:
Code: 0 Length: 2
Checksum: The ICMP checksum. See [RFC4443] TID: A unique Transaction ID assigned by the host in the associated
NR and used to match NC replies. The TID is set to zero when the
node boots and then follows a lollipop lifetime, wrapping direcly
from 0xFFFF to 0x10.
Reserved: This field is unused. It MUST be initialized to zero by Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver. the sender and MUST be ignored by the receiver.
P: Primary Flag. MUST echo the P flag in the Binding solicitation. Owner Unique Identifier: A globally unique identifier for the host's
interface associated with the binding for the NS/NA message in
X: Proxy Flag. Indicates that the route actually proxies for the question. This can be the EUI-64 derived IID of an interface,
node. This can only happen if the P flag is set as well. which can be hashed with other supposedly unique information from
multiple orthogonal sources.
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.
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.
Binding Address: The link-layer address that the sender wishes to
assign or maintain assigned to its interface.
Possible options
Source link-layer address: The link-layer address of the interface
from which the Router Advertisement is sent. See [RFC4861].
MTU: Specifies the maximum size of a fragmented message 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 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.1. Forming addresses
All nodes are required to autoconfigure at least one address, a link-
local address that is derived from the IEEE 64-bit extended media
access control address that is globally unique to the device. Link-
local address are described in section 2.5.6 of [RFC4291]. Appendix
A of that specification explains how the node builds an interface-ID
based on the IEEE 64-bit extended MAC address by inverting the "u"
(universal/local) bit.
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
reach it over IP. Another consequence is that the link local address
is presumably unique on the Extended LoWPAN, which enables the use of
Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the
Transit Link and the LoWPAN. The address MAY be created as
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 5. Backbone Router Operations
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 5.1. Backbone Link and Router
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 Backbone Router is a specific kind of Border Router that performs
for instance if it needs to be reachable from the outside of the proxy Neighbor Discovery on its backbone interface on behalf of the
Extended LoWPAN, or if it can manage its own mobility as prescribed nodes that it has discovered on its Low Power Lossy Network
by Mobile IPv6 [RFC3775]. In that case, the node needs to bind each interfaces. On the LLN side, the Backbone Router acquires its states
individual address individually. about the nodes by terminating protocols such as RPL
[I-D.ietf-roll-rpl] or 6LoWPAN ND [I-D.ietf-6lowpan-nd] as a LLN
Border Router. It is expected that the backbone is the medium used
to connect the subnet to the rest of the infrastructure, and that all
the LBRs are connected to that backbone and support the Backbone
Router feature as specified in this document.
5.2. Binding process The backbone is expected to be a high speed, reliable transit link,
with affordable multicast capabilities, such as an Ethernet Network
or a fully meshed NBMA network with multicast emulation, which allows
a full support of classical ND as specified in [RFC4861] and
subsequent RFCs. In other words, the backbone is not a LLN. Still,
some restrictions of the attached LLNs will apply to the backbone.
In particular, it is expected that the MTU is set to the same value
on the backbone and all attached LLNs.
The binding process is very similar to that of a MIP6 mobile node, 5.2. ND Proxy Operations
though the messages used are new Neighbor Discovery ICMP messages .
A LoWPAN node address is tentative or optimistic as long as the
binding is not confirmed by the Backbone Router.
The LoWPAN node uses unicast Binding Solicitations to perform the This specification enables a Backbone Router to proxy Neighbor
binding. The destination Address is that of the Backbone Router or a Discovery operations over the backbone on behalf of the nodes that
well know anycast address 6LOWPAN_BBR that indicates the function of are registered to it, allowing any device on the backbone to reach a
the Backbone Routers. The source address is the unspecified address LLN node as if it was on-link.
as long as the address is still optimistic or tentative, and it is
the link local address of the node after it is successfully bound.
The acknowledgment to a Binding Solicitation is a unicast Binding In the context of this specification, proxy ND means:
Confirmation message that contains the status of the binding. The
source of the packet is the link-local address of the Backbone
Router. The destination address is a well-know anycast address
6LOWPAN_NODE unless the optimistic bit is set in the Binding
Solicitation or the address was already bound, in which case the link
local address of the node is used.
Upon successful completion in the Binding Confirmation message, the o defending a registered address over the backbone using NA messages
LoWPAN node sets the address from optimistic or tentative to with the Override bit set
preferred.
The 'X' flag in the Binding Confirmation message indicates that the o advertising a registered address over the backbone using NA
Backbone Router has completed DAD and now owns the Binding Address messages, asynchronously or as a response to a Neighbor
over the Transit Link. Solicitation messages.
This specification also introduces the concept of secondary binding. o Looking up a destination over the backbone in order to deliver
For redundancy, a node might place a secondary binding with one or packets arriving from the LLN using Neighbor Sollicitation
more other Backbone Routers over a same or different LoWPANs. The messages.
'P' flag in the Binding Solicitation message indicates whether the
binding is primary (set) or secondary (reset).
5.3. Looking up neighbor addresses o Forwarding packets from the LLN over the backkbone, and hte other
way around.
A LoWPAN node does not use multicast for its Neighbor Solicitation as o Eventually triggering a look up for a destination over the LLN
prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. For that would not be registered at a given point of time, or as a
lookup purposes, all NS messages are sent in unicast to the Backbone verification of a registration.
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 draft introduces the concept of primary and secondary BRs. The
destination if a short cut is possible over the LoWPAN, or that of concept is defined with the granularity of an address, that is a
the Backbone Router if the destination is reachable over the Transit given BR can be primary for a given address and secondary or another
Link, in which case the Backbone Router will terminate 6LoWPAN and one, regardess on whether the addresses belong to the same node or
relay the packet. not. The primary Backbone Router is in charge of protecting the
address for DAD over the Backbone. Any of the Primary and Secondary
BR may claim the address over the backbone, since they are all
capable to route from the backbone to the LLN device.
5.4. Answering address look up When the protocol used to register the nodes over the LLN is RPL
[I-D.ietf-roll-rpl], it is expected that one BR acts as virtual root
coordinating LLN BRs (with the same DODAGID) over the non-LLN
backbone. In that case, the virtual root may act as primary BR for
all addresses that it cares to support, whereas the physical roots to
which the node is attached are secondary BRs. It is also possible in
a given deployment that the DODAGs are not coordinated. In that
case, there is no virtual root and no secondary BR; the DODAG root is
primary all the nodes registered to it over the backbone.
A LoWPAN node does not need to join the solicited-node multicast When the protocol used to register the nodes over the LLN is 6LoWPAN
address for its own addresses and should not have to answer a ND [I-D.ietf-6lowpan-nd], the Backbone Routers act as a distributed
multicast Neighbor Solicitation. It may be programmed to answer a DAD table, using classical ND over the backbone to detect
unicast NS but that is not required by this specification. duplication. This specification requires that:
6. Backbone router operations 1. Registrations for all addresses that can be required to reach the
device over the backbone, including registrations for IPv6
addresses based on burn-in EUI64 addresses are passed to the DAD
table.
6.1. Exposing the Backbone Router 2. Nodes include the Binding Tracking Option in their NS used for
registering those addresses and the LRs propagate that option to
the LBRs.
The Backbone Router forms a link-local address in exactly the same A false positive duplicate detection may arise over the backbone, for
way as any other node on the LoWPAN. It uses the same link local instance if the node registers to more than one LBR, or if the node
address for the Transit Link and for all the associated LoWPAN(s) has moved. Both situations are handled gracefully unbeknownst to the
connected to that Backbone Router. node. In the former case, one LBR becomes primary to defend the
address over the backbone while the others become secondary and may
still forward packets back and forth. In the latter case the LBR
that receives the newest registration wins and becomes primary.
The backbone router also configures the well known 6LOWPAN_BBR 5.3. Claiming and defending
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) Upon a new or an updated registration, the BR performs a DAD
messages that are broadcasted periodically over the LOWPAN. (note: operation. If either a TID or a OUI is available, the BR places them
can we merge RA with some other maintenance packet or distribute the in a Binding Tracking Option in all its ND messages over the
info from the manager in some specific cases like ISA100.11a where backbone. If content is not available for a given field, it is set
such a thing exists?). (also, when the node moves to another LoWPAN, to 0.
is there a way to let it know faster which is the Backbone Router so
that it can stimulate a RA using RS?).
A new option in the RA indicates the Backbone Router capability. In If a primary already exists over the backbone, it will answer the DAD
this way a node can learn the PAN-ID and the 16-bit short address for with an RA.
the Backbone Router if it was not already acquired from another
process that is not covered by this specification.
The Backbone Router MAY also announce any prefix that is configured o If a RA is received with the O bit set, the primary rejects the
on the transit link, and serve as the default gateway for any node on DAD and the DAD fails. the BR needs to inform the LLN protocol
the Transit Link or on the attached LoWPANs. that the address is a duplicate.
The transit link Maximum Transmission Unit serves as base for Path o If a RA is received with the O bit reset, the primary accepts the
MTU discovery and Transport layer Maximum Segment Size negotiation BR as secondary and DAD succeeds. The BR may install or maintain
(see section 8.3 of [RFC2460]) for all nodes in the LoWPANs. To its proxy states for that address. This router MAY advertise the
achieve this, the Backbone Router announces the MTU of the transit address using a NA. during a registration flow, it MAY set the O
link over the LoWPAN using the MTU option in the RA message as bit.
prescribed in section "4.6.4. MTU" of IPv6 Neighbor Discovery
[RFC4861].
LoWPAN nodes SHOULD form IPv6 packets that are smaller than that MTU. o If no RA is received, this router assumes the role of primary and
As a result, those packets should not require any fragmentation over DAD succeeds. The BR may install or maintain its proxy states for
the transit link though they might be intranet-fragmented over the that address. This router advertises the address using a NA with
LoWPAN itself as prescribed by [RFC4944]). the O bit reset.
More information on the MTU issue with regard to ND-proxying can be When the BR installs or maintains its proxy states for an address, it
found in Neighbor Discovery Proxies [RFC4389] and sends an NA with a SLLA option for that address. The Primary BR MAY
[I-D.van-beijnum-multi-mtu]. set the O bit if it wished to attract the traffic for that address.
6.2. Binding process 5.4. Conflict Resolution
Upon a new binding for a link-local address based on a IEEE 64-bit A conflict arise when multiple BRs get a registration from a same
extended MAC address, the Backbone Router MAY use Optimistic DAD on address. This situation might arise when a node moves from a BR to
the Transit Link. Any other Backbone Router that would happen to another, when a node registers to multiple BRs, or in the RPL case
have a binding for that same address SHOULD yield and deprecate its when the BRs belong to a single coordinated DODAG.
binding to secondary if it was primary. A positive acknowledgement
can be sent to the LoWPAN node right away if oDAD is used on the
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 primary looks up the Binding Tracking Option in ND messages with
of a Home Agent as specified in Mobility Support for IPv6 [RFC3775]. a SLLA option.
In particular, the Neighbor Advertisement message is used as
specified in section "10.4.1. Intercepting Packets for a Mobile
Node" with one exception that the override (O) bit is not set,
indicating that this Backbone Router acts as a proxy for the LoWPAN
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. o If there is no option, normal ND operation takes place and the
Upon a secondary binding, the Backbone Router will not announce or primary defends the address with a NA with the O bit set, adding
defend the address on the transit link, but will be able to forward the Binding Tracking Option with its own information.
packets to the node over its LoWPAN interface. For other addresses,
the rules in [RFC3775] apply for compatibility.
The Backbone Router responds to a Binding Solicitation with a Binding o If there is a Binding Tracking Option and the OUIs are different,
Confirmation. The source address is a link local address of the then the conflict apparently happens between different nodes, and
router and the destination is the well known 6LOWPAN_NODE address the the primary defends the address with a NA with the O bit set,
unless a binding flow has already successfully completed in which adding the Binding Tracking Option with its own information. If
case the router MAY use the node's Binding. The router will also use the TID in the Binding Tracking Option is in the straight part of
the Binding Address if the 'O' flag is raised in the Solicitation, the lollipop, it is possible that the request comes from the same
indicating that the node accepts packets on that address prior to a node that has rebooted and formed a new OUI The primary BR may
successful binding but may not accept packets on the 6LOWPAN_NODE assess its registered entry prior to answering.
address.
If the Backbone Router is primary for a registration (as indicated by o If there is a Binding Tracking Option and the OUIs are the same:
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 * If the TID in the ND message is newer than the most recent one
known by the primary router, this is interpreted as a node
moving. The primary cleans up its states and stops defending
the address.
A Backbone Router knows and proxies for all the IPv6 addresses that * If the TID in the ND message is the same as the most recent one
are registered to it. When resolving a target address, the Backbone known by the primary router, this is interpreted as a double
Router first considers its binding cache. If this address is in the registration. In case of a DAD, the promary responds with a NA
cache, then the target is reachable over the LoWPAN as indicated in with the O bit reset, to confirm its position as primary,
the cache. Else, the Backbone Router locates the target over the including the Binding Tracking Option.
transit link using standard "Neighbor Discovery" [RFC4861] over that
link.
If the target is located over a LoWPAN owned by another Backbone * If the TID in the ND message is older than the most recent one
Router, then that other Backbone Router is in charge of answering the known by the primary router, this is interpreted as a stale
Neighbor Solicitation on behalf of the target node. information. The primary defends the address with a NA with
the O bit set, adding the Binding Tracking Option with its own
information.
6.4. Answering address look up * If the TIDs are very different (more than 16 apart, discounting
the straight part of the lollipop), it is impossible to resolve
for sure. The primary BR should assess its registered entry
prior to answering.
To enable proxying over the Transit Link, a Backbone Router must join 5.5. Assessing an entry
the solicited-node multicast address on that link for all the
registered addresses of the nodes in its LoWPANs. The Backbone
Router answers the Neighbor Solicitation 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 In a number of cases, it might happen that the information at the
for all nodes in its LoWPANs. It answers as a proxy for the real primary BR is stale and obsolete. In particular, a node with no
target. The target link-layer address in the response is either that permanent storage might reboot and form a different OUI, in which
of the destination if a short cut is possible over the LoWPAN, or case the information at the BR is inaccurate and should be removed.
that of the Backbone Router if the destination is reachable over the In another case, the Br and the node have been out of reach for too
Transit Link, in which case the Backbone Router will terminate long and the TID that the BR maintains is so far out that it is
6LoWPAN and relay the packet. impossible to compare it with that stored at the BR.
6.5. Forwarding packets In such situation, the primary Backbone Router has the possibility to
assess the registration. this is performed by the protocol in use to
register the node over the LLN.
Upon receiving packets on one of its LoWPAN interfaces, the Backbone When the protocol used to register the nodes over the LLN is RPL
Router checks whether it has a binding for the source address. If it [I-D.ietf-roll-rpl], the BR sends a targetted DIS to the registered
does, then the Backbone Router can forward the packet to another address over the registered path. A DAO back indicates that the
LoWPAN node or over the Transit link. Otherwise, the Backbone Router current registration is still valid and provides the adequate data to
MUST discard the packet. If the packet is to be transmitted over the resolve the conflict.
Transit link, then the 6LoWPAN sublayer is terminated and the full
IPv6 packet is reassembled and expanded.
When forwarding a packet from the Transit Link towards a LOwPAN When the protocol used to register the nodes over the LLN is 6LoWPAN
interface, the Backbone Router performs the 6LoWPAN sublayer ND [I-D.ietf-6lowpan-nd], TBD.
operations of compression and fragmentation and passes the packet to
the lower layer for transmission.
7. Security Considerations 6. 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
Link or MAC sublayer cryptography. In particular, it is expected Link or MAC sublayer cryptography. In particular, it is expected
that the LoWPAN MAC provides secure unicast to/from the Backbone that the LLN MAC provides secure unicast to/from the Backbone Router
Router and secure broadcast from the Backbone Router in a way that and secure broadcast from the Backbone Router in a way that prevents
prevents tempering with or replaying the RA messages. 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 7. IANA Considerations
This specification requires 2 new ICMP types for the binding flow. A new type is requested for an ND option.
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 8. Acknowledgments
The author wishes to thank Geoff Mulligan for his help and in-depth The author wishes to thank Zach Shelby for their help and in-depth
review. review.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[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.
skipping to change at page 17, line 20 skipping to change at page 18, line 39
"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 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] [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. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 2005.
skipping to change at page 19, line 4 skipping to change at line 626
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
Batiment T3 Batiment T3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
Phone: +33 4 97 23 26 34 Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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).
 End of changes. 98 change blocks. 
539 lines changed or deleted 376 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/