One document matched: draft-thubert-6lowpan-backbone-router-02.txt
Differences from draft-thubert-6lowpan-backbone-router-01.txt
6LoWPAN P. Thubert
Internet-Draft Cisco
Intended status: Standards Track June 6, 2010
Expires: December 8, 2010
6LoWPAN Backbone Router
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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Thubert Expires December 8, 2010 [Page 1]
Internet-Draft 6LoWPAN Backbone Router June 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. New types and formats . . . . . . . . . . . . . . . . . . . . 8
4.1. Binding Tracking Option . . . . . . . . . . . . . . . . . 8
5. Backbone Router Operations . . . . . . . . . . . . . . . . . . 10
5.1. Backbone Link and Router . . . . . . . . . . . . . . . . . 10
5.2. ND Proxy Operations . . . . . . . . . . . . . . . . . . . 10
5.3. Claiming and defending . . . . . . . . . . . . . . . . . . 12
5.4. Conflict Resolution . . . . . . . . . . . . . . . . . . . 12
5.5. Assessing an entry . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Thubert Expires December 8, 2010 [Page 2]
Internet-Draft 6LoWPAN Backbone Router June 2010
1. Introduction
The ISA100.11a standard has introduced the concept of a Backbone
Router that would interconnect small LLNs over a high speed transit
network and scale a single ISA100.11a network up to the thousands of
nodes. In that model the LLNs and the backbone form a single subnet
in which nodes can move freely without the need of renumbering, and
the Backbone Router is a special kind of Border Router designed to
manage the interaction between the LLNs and the backbone at layer 3.
Similar scalability requirements exist in the metering and monitoring
industries. In a network that large, it is impossible for a node to
register to all Border Routers as suggested for smaller topologies in
Neighbor Discovery Optimization for Low-power and Lossy Networks
[I-D.ietf-6lowpan-nd].
This paper specifies IP layer functionalities that are required to
implement the concept of a Backbone Router with IPv6, in particular
the application of the "IP Version 6 Addressing Architecture"
[RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6
Stateless Address Autoconfiguration" [RFC4862].
The use of EUI-64 based link local addresses, Neighbor Discovery
Proxying [RFC4389], Neighbor Discovery Optimization for Low-power
and Lossy Networks [I-D.ietf-6lowpan-nd], the IPv6 Routing Protocol
for Low power and Lossy Networks [I-D.ietf-roll-rpl] and Optimistic
Duplicate Address Detection [RFC4429] are discussed. Also, the
concept of Transit Link is introduced to implement the backbone
network that was envisioned by ISA100.11a.
This operation of the Backbone Router requires that some protocol
operates over the LLNs from which node registrations can be obtained,
and that can disseminate the location of the backbone Router over the
LLN. Further expectations will be detailed.
The way the PAN IDs and 16-bit short addresses are allocated and
distributed in the case of an 802.15.4 network is not covered by this
specification. Similarly, the aspects of joining and securing the
network are out of scope. The way the nodes in the LLN learn about
their Backbone Router depends on the protocol used in the LLN. In
the case of RPL, a Border Router is the root of the DODAG that it
serves and represents all nodes attached to that DODAG.
Thubert Expires December 8, 2010 [Page 3]
Internet-Draft 6LoWPAN Backbone Router June 2010
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],
Neighbor Discovery Optimization for Low-power and Lossy Networks
[I-D.ietf-6lowpan-nd] and "Transmission of IPv6 Packets over IEEE
802.15.4 Networks" [RFC4944].
Readers would benefit from reading "Mobility Support in IPv6"
[RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and
"Optimistic Duplicate Address Detection" [RFC4429] prior to this
specification for a clear understanding of the art in ND-proxying and
binding.
Additionally, this document uses terminology from
[I-D.ietf-roll-terminology], and introduces the following
terminology:
Backbone
This is an IPv6 transit link that interconnects 2 or more
Backbone Routers. 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
An IPv6 router that federates the LLN using a transit link as a
backbone.
Extended LLN
This is the aggregation of multiple LLNs as defined in
[RFC4919] interconnected by a Transit Link via Backbone Routers
and forming a single IPv6 link.
Binding
Thubert Expires December 8, 2010 [Page 4]
Internet-Draft 6LoWPAN Backbone Router June 2010
The association of the LLN node IPv6 address and Interface ID
with associated proxying states including the remaining
lifetime of that association.
Registration
The process during which a LLN node injects its address in a
protocol through which the Border Router can learn the address
and proxy ND for it.
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.
Thubert Expires December 8, 2010 [Page 5]
Internet-Draft 6LoWPAN Backbone Router June 2010
3. Overview
A Transit Link that we'll refer to a the LLN Backbone federates
multiple LLNs as a single IP subnet. Each LLN in the subnet is
anchored at a Backbone Router. The Backbone Routers interconnect the
LLNs over that Backbone Link. A node can move freely from a LLN
anchored at a Backbone Router to a LLN anchored at another Backbone
Router on the same backbone and conserve its link local and any other
IPv6 address it has formed.
---+------------------------
| Plant Network
|
+-----+
| | Gateway
| |
+-----+
|
| Transit Link
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone
| | router | | router | | router
+-----+ +-----+ +-----+
o o o o o o
o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o
o o o o o o o o o o
o o o o o o o
LLN LLN LLN
Figure 1: Backbone Link and Backbone Routers
The Backbone Link is used as reference for Neighbor Discovery
operations, by extending the concept of a Home Link as defined in
[RFC3775] for Mobile IPv6. In particular, Backbone Routers perform
ND proxying for the LLN nodes in the LLNs they own through a node
registration.
The Backbone Router operation is compatible with that of a Home
Agent. This enables mobility support for LLN devices that would move
outside of the network delimited by the transit link. This also
enables collocation of Home Agent functionality within Backbone
Router functionality on the same interface of a router.
Thubert Expires December 8, 2010 [Page 6]
Internet-Draft 6LoWPAN Backbone Router June 2010
A LLN node registers and claims ownership of its addresse(s) using
proactive acknowledged registration exchanges with a neighboring
router. In case of a complex LLN topology, the router might be an
intermediate LLN Router that relays the registration to the LBR as
described for instance in [I-D.ietf-6lowpan-nd] and
[I-D.ietf-roll-rpl]. In turn, the Backbone Routers operate as a
distributed database of all the LLN nodes and use the Neighbor
Discovery Protocol to share that information across the transit link
in a reactive fashion.
For the purpose of Neighbor Discovery proxying, this specification
documents the LLN Master Neighbor Registry, a conceptual data
structure that is similar to the MIP6 binding cache. The Master
Neighbor Registry is fed by redistributing addresses learnt from the
registration protocol used over the LLN.
Another function of the Backbone Router is to perform 6LoWPAN
compression and expansion between the LLN and the Transit Link and
ensure MTU compatibility. Packets flow uncompressed over the Transit
Link and are routed normally towards a Gateway or an Application
sitting on the transit link or on a different link that is reachable
over the IP network.
Thubert Expires December 8, 2010 [Page 7]
Internet-Draft 6LoWPAN Backbone Router June 2010
4. New types and formats
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.
The specification expects that the protocol running on the LLN can
provide a unique ID for the owner of the address that is being
registered. The Owner Unique ID enables to differentiate a duplicate
registration from a double registration. In case of a duplicate, the
last registration looses. The Owner Unique ID can be as simple as a
EUI-64 burnin address, if the device manufacturor is convinced that
there can not be a manuf error that would cause duplicate EUI64
addresses. Alternatively, the unique ID can be a hash of supposedly
unique information from multiple orthogonal sources, for instance:
o Burn in address.
o configured address, id, security keys...
o (pseudo) Random number, radio link metrics ...
In any fashion, it is recommended that the device stores the unique
Id in persistent memory. Otherwise, it will be prevented to
reregister after a reboot that would cause a loss of memory until the
Backbone Router times out the registration.
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:
4.1. Binding Tracking Option
This option is designed to be used with standard NS and NA messages
between backbone Routers over a backbone link and may be used between
LRs and LBRs over the LLN. By using this option, the binding in
question can be uniquely identified and matched with the Master
Neighbor Registry entries of each Backbone Router.
Thubert Expires December 8, 2010 [Page 8]
Internet-Draft 6LoWPAN Backbone Router June 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Unique Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Binding Tracking Option
Option Fields
Type:
Length: 2
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
the sender and MUST be ignored by the receiver.
Owner Unique Identifier: A globally unique identifier for the host's
interface associated with the binding for the NS/NA message in
question. This can be the EUI-64 derived IID of an interface,
which can be hashed with other supposedly unique information from
multiple orthogonal sources.
Thubert Expires December 8, 2010 [Page 9]
Internet-Draft 6LoWPAN Backbone Router June 2010
5. Backbone Router Operations
5.1. Backbone Link and Router
The Backbone Router is a specific kind of Border Router that performs
proxy Neighbor Discovery on its backbone interface on behalf of the
nodes that it has discovered on its Low Power Lossy Network
interfaces. On the LLN side, the Backbone Router acquires its states
about the nodes by terminating protocols such as 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.
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.
5.2. ND Proxy Operations
This specification enables a Backbone Router to proxy Neighbor
Discovery operations over the backbone on behalf of the nodes that
are registered to it, allowing any device on the backbone to reach a
LLN node as if it was on-link.
In the context of this specification, proxy ND means:
o defending a registered address over the backbone using NA messages
with the Override bit set
o advertising a registered address over the backbone using NA
messages, asynchronously or as a response to a Neighbor
Solicitation messages.
o Looking up a destination over the backbone in order to deliver
packets arriving from the LLN using Neighbor Sollicitation
messages.
o Forwarding packets from the LLN over the backkbone, and hte other
way around.
Thubert Expires December 8, 2010 [Page 10]
Internet-Draft 6LoWPAN Backbone Router June 2010
o Eventually triggering a look up for a destination over the LLN
that would not be registered at a given point of time, or as a
verification of a registration.
The draft introduces the concept of primary and secondary BRs. The
concept is defined with the granularity of an address, that is a
given BR can be primary for a given address and secondary or another
one, regardess on whether the addresses belong to the same node or
not. The primary Backbone Router is in charge of protecting the
address for DAD over the Backbone. Any of the Primary and Secondary
BR may claim the address over the backbone, since they are all
capable to route from the backbone to the LLN device.
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.
When the protocol used to register the nodes over the LLN is 6LoWPAN
ND [I-D.ietf-6lowpan-nd], the Backbone Routers act as a distributed
DAD table, using classical ND over the backbone to detect
duplication. This specification requires that:
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.
2. Nodes include the Binding Tracking Option in their NS used for
registering those addresses and the LRs propagate that option to
the LBRs.
A false positive duplicate detection may arise over the backbone, for
instance if the node registers to more than one LBR, or if the node
has moved. Both situations are handled gracefully unbeknownst to the
node. In the former case, one LBR becomes primary to defend the
address over the backbone while the others become secondary and may
still forward packets back and forth. In the latter case the LBR
that receives the newest registration wins and becomes primary.
Thubert Expires December 8, 2010 [Page 11]
Internet-Draft 6LoWPAN Backbone Router June 2010
5.3. Claiming and defending
Upon a new or an updated registration, the BR performs a DAD
operation. If either a TID or a OUI is available, the BR places them
in a Binding Tracking Option in all its ND messages over the
backbone. If content is not available for a given field, it is set
to 0.
If a primary already exists over the backbone, it will answer the DAD
with an RA.
o If a RA is received with the O bit set, the primary rejects the
DAD and the DAD fails. the BR needs to inform the LLN protocol
that the address is a duplicate.
o If a RA is received with the O bit reset, the primary accepts the
BR as secondary and DAD succeeds. The BR may install or maintain
its proxy states for that address. This router MAY advertise the
address using a NA. during a registration flow, it MAY set the O
bit.
o If no RA is received, this router assumes the role of primary and
DAD succeeds. The BR may install or maintain its proxy states for
that address. This router advertises the address using a NA with
the O bit reset.
When the BR installs or maintains its proxy states for an address, it
sends an NA with a SLLA option for that address. The Primary BR MAY
set the O bit if it wished to attract the traffic for that address.
5.4. Conflict Resolution
A conflict arise when multiple BRs get a registration from a same
address. This situation might arise when a node moves from a BR to
another, when a node registers to multiple BRs, or in the RPL case
when the BRs belong to a single coordinated DODAG.
The primary looks up the Binding Tracking Option in ND messages with
a SLLA option.
o If there is no option, normal ND operation takes place and the
primary defends the address with a NA with the O bit set, adding
the Binding Tracking Option with its own information.
o If there is a Binding Tracking Option and the OUIs are different,
then the conflict apparently happens between different nodes, and
the the primary defends the address with a NA with the O bit set,
adding the Binding Tracking Option with its own information. If
Thubert Expires December 8, 2010 [Page 12]
Internet-Draft 6LoWPAN Backbone Router June 2010
the TID in the Binding Tracking Option is in the straight part of
the lollipop, it is possible that the request comes from the same
node that has rebooted and formed a new OUI The primary BR may
assess its registered entry prior to answering.
o If there is a Binding Tracking Option and the OUIs are the same:
* 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.
* If the TID in the ND message is the same as the most recent one
known by the primary router, this is interpreted as a double
registration. In case of a DAD, the promary responds with a NA
with the O bit reset, to confirm its position as primary,
including the Binding Tracking Option.
* If the TID in the ND message is older than the most recent one
known by the primary router, this is interpreted as a stale
information. The primary defends the address with a NA with
the O bit set, adding the Binding Tracking Option with its own
information.
* 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.
5.5. Assessing an entry
In a number of cases, it might happen that the information at the
primary BR is stale and obsolete. In particular, a node with no
permanent storage might reboot and form a different OUI, in which
case the information at the BR is inaccurate and should be removed.
In another case, the Br and the node have been out of reach for too
long and the TID that the BR maintains is so far out that it is
impossible to compare it with that stored at the BR.
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.
When the protocol used to register the nodes over the LLN is RPL
[I-D.ietf-roll-rpl], the BR sends a targetted DIS to the registered
address over the registered path. A DAO back indicates that the
current registration is still valid and provides the adequate data to
resolve the conflict.
Thubert Expires December 8, 2010 [Page 13]
Internet-Draft 6LoWPAN Backbone Router June 2010
When the protocol used to register the nodes over the LLN is 6LoWPAN
ND [I-D.ietf-6lowpan-nd], TBD.
Thubert Expires December 8, 2010 [Page 14]
Internet-Draft 6LoWPAN Backbone Router June 2010
6. Security Considerations
This specification expects that the link layer is sufficiently
protected, either by means of physical or IP security for the Transit
Link or MAC sublayer cryptography. In particular, it is expected
that the LLN MAC provides secure unicast to/from the Backbone Router
and secure broadcast from the Backbone Router in a way that prevents
tempering with or replaying the RA messages.
The use of EUI-64 for forming the Interface ID in the link local
address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
address privacy techniques. Considering the envisioned deployments
and the MAC layer security applied, this is not considered an issue
at this time.
Thubert Expires December 8, 2010 [Page 15]
Internet-Draft 6LoWPAN Backbone Router June 2010
7. IANA Considerations
A new type is requested for an ND option.
Thubert Expires December 8, 2010 [Page 16]
Internet-Draft 6LoWPAN Backbone Router June 2010
8. Acknowledgments
The author wishes to thank Zach Shelby for their help and in-depth
review.
Thubert Expires December 8, 2010 [Page 17]
Internet-Draft 6LoWPAN Backbone Router June 2010
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
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
Thubert Expires December 8, 2010 [Page 18]
Internet-Draft 6LoWPAN Backbone Router June 2010
Networks", draft-ietf-roll-terminology-03 (work in
progress), March 2010.
[I-D.van-beijnum-multi-mtu]
Beijnum, I., "Extensions for Multi-MTU Subnets",
draft-van-beijnum-multi-mtu-02 (work in progress),
February 2008.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
Thubert Expires December 8, 2010 [Page 19]
Internet-Draft 6LoWPAN Backbone Router June 2010
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 December 8, 2010 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-21 18:36:30 |