6LoWPAN P. Thubert
Internet-Draft Cisco
Intended status: Standards Track March 18, 2008
Expires: September 19, 2008
LoWPAN Backbone Router
draft-thubert-6lowpan-backbone-router-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
ISA100.11a is a Working Group at the ISA SP100 standard committee
that covers Wireless Systems for Industrial Automation and Process
Control. The WG is mandated to design a scalable, industrial grade
LowPAN for devices such as sensors, valves, and actuators. The
upcoming standard uses the 6LoWPAN format for the network header. It
also introduces the concept of a Backbone Router to merge small
LoWPANs via a high speed transit and scale the ISA100.11a network.
This paper proposes an IPv6 version of the Backbone Router concept.
Thubert Expires September 19, 2008 [Page 1]
Internet-Draft LoWPAN Backbone Router March 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. New Neighbor Discovery options . . . . . . . . . . . . . . . . 6
4.1. Binding Update Option . . . . . . . . . . . . . . . . . . 6
4.2. Binding Acknowledgement Option . . . . . . . . . . . . . . 7
5. LowPAN device operations . . . . . . . . . . . . . . . . . . . 8
5.1. Forming addresses . . . . . . . . . . . . . . . . . . . . 8
5.2. Binding process . . . . . . . . . . . . . . . . . . . . . 9
5.3. Looking up neighbor addresses . . . . . . . . . . . . . . 9
5.4. Answering address look up . . . . . . . . . . . . . . . . 10
6. Backbone router operations . . . . . . . . . . . . . . . . . . 10
6.1. Exposing the Backbone Router . . . . . . . . . . . . . . . 10
6.2. Binding process . . . . . . . . . . . . . . . . . . . . . 11
6.3. Looking up neighbor addresses . . . . . . . . . . . . . . 11
6.4. Answering address look up . . . . . . . . . . . . . . . . 12
6.5. Forwarding packets . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Thubert Expires September 19, 2008 [Page 2]
Internet-Draft LoWPAN Backbone Router March 2008
1. Introduction
ISA100.11a is a Working Group at the ISA SP100 standard committee
that covers Wireless Systems for Industrial Automation and Process
Control. The ISA100.11a is mandated to design a scalable, industrial
grade wireless network and application layer suite of protocols for
low power devices such as sensors and actuators, with a response time
on the order of 100ms.
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
Router that would interconnect small LoWPANs over a high speed
transit network and scale a single ISA100.11a network up to the
thousands of nodes.
This paper specifies IP layer functionalities that are required to
implement a such Backbone Router with IPv6, in particular the
application of the "IP Version 6 Addressing Architecture" [RFC4291],
"Neighbor Discovery for IP version 6" [RFC4861] and "IPv6 Stateless
Address Autoconfiguration" [RFC4862]. The use of EUI-64 based link
local addresses, Neighbor Discovery Proxying and Optimistic Duplicate
Address Detection are discussed. Also, the concept of Transit Link
is introduced to implement the transit network that is envisioned by
ISA100.11a.
This draft solves the problem of finding the other Backbone Router or
gateway on the transit link from a 64 bits address that is used as
interface ID for building a link local address. The Backbone Router
acts as proxy for all nodes attached to it through a process of
registration. The Backbone Router also acts as a server for all
Neighbor Discovery flows from and to its nodes, avoiding the burden
of multicast over the LoWPAN.
The way the PAN IDs and 16-bit short addresses are allocated and
distributed in the case of an 802.15.4 network is not covered by this
specification. This specification is compatible with a deployment
where each Backbone Router is connected to a different PAN-ID that is
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.
Thubert Expires September 19, 2008 [Page 3]
Internet-Draft LoWPAN Backbone Router March 2008
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Readers are expected to be familiar with all the terms and concepts
that are discussed in "Neighbor Discovery for IP version 6"
[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944].
Readers would benefit from reading "Mobility Support in IPv6"
[RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and
"Optimistic Duplicate Address Detection" [RFC4429] prior to this
specification for a clear understanding of the art in ND-proxying and
binding. This document defines additional terms:
Transit Link
This is an IPv6 link that interconnects 2 or more backbone
routers. It is expected to be deployed as a high speed backbone
in order to federate a potentially large set of LoWPANS. Also
referred to as a LoWPAN backbone or transit network.
Backbone Router
An IPv6 router that interconnects the LoWPAN with a Transit Link.
Extended LoWPAN
This is the aggregation of multiple LoWPANs as defined in
[RFC4919] interconnected by a Transit Link via Backbone Routers
and forming a single IPv6 link.
Binding
The association of the LoWPAN node IPv6 address and Interface ID
with associated proxying states including the remaining lifetime
of that association.
Registration
The process during which a LoWPAN node sends a Binding ND message
to a Backbone Router causing a binding for the LoWPAN node to be
registered.
Thubert Expires September 19, 2008 [Page 4]
Internet-Draft LoWPAN Backbone Router March 2008
3. Overview
A Transit Link federates multiple LoWPANs as a single IP link, the
extended LoWPAN. Each LoWPAN is anchored at a Backbone Router. The
Backbone Routers interconnect the LoWPANs over the Transit Link. A
node can move freely from a LoWPAN anchored at a Backbone Router to a
LoWPAN anchored at another Backbone Router on the same Transit Link
and conserve its link local and any other IPv6 address it has formed.
---+------------------------
| Plant Network
|
+-----+
| | Gateway
| |
+-----+
|
| Transit Link
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
| | router | | router | | router
+-----+ +-----+ +-----+
o o o o o o
o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o
o o o o o o o o o o
o o o o o o o
LoWPAN LoWPAN LoWPAN
Figure 1: Transit Link and Backbone Routers
In order to achieve this, the Transit link is used as reference for
Neighbor Discovery operations, by extending the concept of a Home
Link as defined in [RFC3775] for Mobile IPv6. In particular,
Backbone Routers perform ND proxying for the LoWPAN nodes in the
LoWPANs they own.
The backbone router operation is compatible with that of a Home
Agent. This enables mobility support for sensor devices that would
move outside of the network delimited by the transit link. This also
enables collocation of Home Agent functionality within Backbone
Router functionality on the same interface of the router.
Thubert Expires September 19, 2008 [Page 5]
Internet-Draft LoWPAN Backbone Router March 2008
The Backbone Router is centric for ND operation inside the LoWPAN.
Part of the reason is the cost of the support for multicasting over
the LoWPAN that this specification avoids for the Neighbor
Solicitation flows. As a result, a LoWPAN node performs unicast
exchanges to its Backbone Router to claim and lookup addresses, and
the Backbone Router proxies the ND requests over the Transit Link
when necessary.
This specification documents the extensions to IPv6 Neighbor
Discovery that enables a LoWPAN Node to claim and lookup addresses
using a Backbone Router as an intermediate proxy. The draft 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
documents the LoWPAN binding cache, a conceptual data structure that
is similar to the MIP6 binding cache.
Another function of the Backbone Router is to perform 6LowPAN
compression and uncompression between the LoWPAN and the Transit Link
and ensure MTU compatibility. Packets flow uncompressed over the
Transit Link and are routed normally towards a Gateway or an
Application sitting on the transit link or on a different link that
is reachable via IP.
4. New Neighbor Discovery options
4.1. Binding Update Option
The binding Update Option echoes the BU in [RFC3775] for Mobile IPv6.
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
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 | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NS BU option
Thubert Expires September 19, 2008 [Page 6]
Internet-Draft LoWPAN Backbone Router March 2008
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.
The length of the option (including the type and length fields and
the suboptions) in units of 8 octets.
Sequence #: A 16-bit unsigned integer used by the receiving node to
sequence Binding Updates and by the sending node to match a
returned Binding Acknowledgement option with this Binding Update
option.
Lifetime: 16-bit unsigned integer. The number of time units
remaining before the binding MUST be considered expired. A value
of zero indicates that the Binding Cache entry for the mobile node
MUST be deleted. (In this case the specified care-of address MUST
also be set equal to the home address.) One time unit is 4
seconds.
4.2. Binding Acknowledgement Option
The Binding Ack Option echoes the Binding Ack in [RFC3775] for Mobile
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NA Binding Ack option
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.
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
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
Thubert Expires September 19, 2008 [Page 7]
Internet-Draft LoWPAN Backbone Router March 2008
Binding Update was rejected by the Backbone Router. The following
Status values are currently defined:
0 Binding Update accepted (primary)
2 Binding Update accepted (secondary)
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
134 Duplicate Address Detection failed
135 Duplicate Address Detection failed
Sequence #: 16-bit unsigned integer. The Sequence Number in the
Binding Acknowledgement is copied from the Sequence Number field
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
units of 4 seconds, for which the Backbone Router SHOULD retain
the entry for this LoWPAN node in its Binding Cache. The value of
this field is undefined if the Status field indicates that the
Binding Update was rejected.
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 is created as optimistic to
enable its use in the binding process with the Backbone Router.
Thubert Expires September 19, 2008 [Page 8]
Internet-Draft LoWPAN Backbone Router March 2008
The node might also form Unique Local and Global Unicast addresses,
for instance if it needs to be reachable from the outside of the
Extended LoWPAN, or if it can manage its own mobility as prescribed
by Mobile IPv6 [RFC3775]. In that case, the node needs to bind each
individual address individually.
5.2. Binding process
The binding process is very similar to that of a MIP6 mobile node,
though the messages used are Neighbor Discovery messages with new
extensions to specify a binding relationship associated to the
advertisements. A LoWPAN Address is tentative as long as the binding
is not confirmed by the Backbone Router.
The LoWPAN node uses unicast Neighbor Solicitations to perform the
binding. The destination Address is that of the Backbone Router.
The source address the unspecified address as long as the address is
still optimistic or tentative, and it is the link local address of
the node after DAD is completed. The target address is the address
being bound. A new binding-update option specifies parameters such
as the binding lifetime.
The acknowledgment to an NS is a unicast Neighbor Advertisement with
a new Binding Acknowledgement option 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 the link-local address
of the LoWPAN node, and the Target Address field contains the address
being bound. That unicast NA is not to be confused with the response
to a DAD and does not mean that the address is duplicated.
A bit in the Binding Acknowledgement option indicates whether the
Backbone Router has completed DAD and now owns the bound address over
the Transit Link. If the bit is set, the LoWPAN node set the address
from optimistic to preferred.
This specification also introduces the concept of secondary binding.
For redundancy, a node might place a secondary binding with one or
more other Backbone Routers over a same or different LoWPANs. A flag
in the binding option indicates whether the binding is secondary.
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
A LoWPAN node does not use multicast for its Neighbor Solicitation.
Whether for DAD or lookup purposes, all NS messages are sent in
Thubert Expires September 19, 2008 [Page 9]
Internet-Draft LoWPAN Backbone Router March 2008
unicast to the Backbone Router, that answers in unicast as well.
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
the Backbone Router if the destination is reachable over the Transit
Link, in which case the Backbone Router will terminate 6LoWPAN and
relay the packet.
5.4. Answering address look up
A LoWPAN node does not need to join the solicited-node multicast
address for its own addresses and should not have to answer a
multicast Neighbor Solicitation. It may be programmed to answer a
unicast NS but that is not required by this specification.
6. Backbone router operations
6.1. Exposing the Backbone Router
The Backbone Router forms a link-local address in exactly the same
way as any other node on the LoWPAN. It uses the same link local
address for the Transit Link and for all the associated LoWPAN(s)
connected to that Backbone Router.
The Backbone Router announces itself using Router Advertisements (RA)
messages that are broadcasted periodically over the LOWPAN. (note:
can we merge RA with some other maintenance packet or distribute the
info from the manager in some specific cases like ISA100.11a where
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
that it can stimulate a RA using RS?).
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
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
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 Maximum Transmission Unit serves as base for Path
MTU discovery and Transport layer Maximum Segment Size negotiation
(see section 8.3 of [RFC2460]) for all nodes in the LoWPANs. To
achieve this, the Backbone Router announces the MTU of the transit
link over the LoWPAN using the MTU option in the RA message as
prescribed in section "4.6.4. MTU" of IPv6 Neighbor Discovery
Thubert Expires September 19, 2008 [Page 10]
Internet-Draft LoWPAN Backbone Router March 2008
[RFC4861].
LoWPAN nodes SHOULD form IPv6 packets that are smaller than that MTU.
As a result, those packets should not require any fragmentation over
the transit link though they might be intranet-fragmented over the
LoWPAN itself as prescribed by [RFC4944]).
More information on the MTU issue with regard to ND-proxying can be
found in Neighbor Discovery Proxies [RFC4389] and
[I-D.van-beijnum-multi-mtu].
6.2. Binding process
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
Transit Link. Any other Backbone Router that would happen to have a
binding for that same address SHOULD yield and deprecate its 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.
The Backbone Router operation on the transit link is similar to that
of a Home Agent as specified in Mobility Support for IPv6 [RFC3775].
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.
Upon a secondary binding, the Backbone Router will not announce or
defend the address on the transit link, but will be able to forward
packets to the node over its LoWPAN interface. For other addresses,
the rules in [RFC3775] apply for compatibility.
6.3. Looking up neighbor addresses
A Backbone Router knows and proxies for all the IPv6 addresses that
are registered to it. When resolving a target address, the Backbone
Router first considers its binding cache. If this address is in the
cache, then the target is reachable over the LoWPAN as indicated in
the cache. Else, the Backbone Router locates the target over the
transit link using standard "Neighbor Discovery" [RFC4861] over that
link.
Thubert Expires September 19, 2008 [Page 11]
Internet-Draft LoWPAN Backbone Router March 2008
If the target is located over a LoWPAN owned by another Backbone
Router, then that other Backbone Router is in charge of answering the
Neighbor Solicitation on behalf of the target node.
6.4. Answering address look up
To enable proxying over the Transit Link, a Backbone Router must join
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
for all nodes in its LoWPANs. It answers as a proxy for the real
target. 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 the Backbone Router if the destination is reachable over the
Transit Link, in which case the Backbone Router will terminate
6LoWPAN and relay the packet.
6.5. Forwarding packets
Upon receiving packets on one of its LoWPAN interfaces, the Backbone
Router checks whether it has a binding for the source address. If it
does, then the Backbone Router can forward the packet to another
LoWPAN node or over the Transit link. Otherwise, the Backbone Router
MUST discard the packet. If the packet is to be transmitted over the
Transit link, then the 6LoWPAN sublayer is terminated and the full
IPv6 packet is uncompressed and reassembled.
When forwarding a packet from the Transit Link towards a LOwPAN
interface, the Backbone Router performs the 6LoWPAN sublayer
operations of compression and fragmentation and passes the packet to
the lower layer for transmission.
7. Security Considerations
This specification expects that the link layer is sufficiently
protected, either by means of physical or IP security for the Transit
Link or MAC sublayer cryptography. In particular, it is expected
that the LoWPAN MAC provides secure unicast to/from the Backbone
Router and secure broadcast from the Backbone Router in a way that
prevents tempering with or replaying the RA messages.
The use of EUI-64 for forming the Interface ID in the link local
address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
Thubert Expires September 19, 2008 [Page 12]
Internet-Draft LoWPAN Backbone Router March 2008
address privacy techniques. Considering the envisioned deployments
and the MAC layer security applied, this is not considered an issue
at this time.
8. IANA Considerations
Need new NS/NA option numbers for the binding flow.
9. Acknowledgments
The author wishes to thank Geoff Mulligan for his help and in-depth
review.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
Thubert Expires September 19, 2008 [Page 13]
Internet-Draft LoWPAN Backbone Router March 2008
10.2. Informative References
[I-D.van-beijnum-multi-mtu]
Beijnum, I., "Extensions for Multi-MTU Subnets",
draft-van-beijnum-multi-mtu-02 (work in progress),
February 2008.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
Author's Address
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Thubert Expires September 19, 2008 [Page 14]
Internet-Draft LoWPAN Backbone Router March 2008
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).
Thubert Expires September 19, 2008 [Page 15]