One document matched: draft-chakrabarti-nordmark-energy-aware-nd-00.txt
INTAREA WG S. Chakrabarti
Internet-Draft Ericsson
Updates: 4861 (if approved) E. Nordmark
Intended status: Standards Track Cisco Systems
Expires: January 3, 2012 July 2, 2011
Energy Aware IPv6 Neighbor Discovery Optimizations
draft-chakrabarti-nordmark-energy-aware-nd-00
Abstract
IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for
neighbor's address resolution, unreachability detection, address
autoconfiguration, router advertisement and solicitation. With the
progress of Internet adoption on various industries including home,
wireless and machine-to-machine communications, there is a desire for
extension or optimization of RFC 4861 protocol for more energy-
efficient networks and nodes. Research indicates that often
networked- nodes require more energy than stand-alone nodes because a
node's energy usage depends on network messages it has to receive and
or respond. While reducing energy consumption is essential for
battery operated nodes in some machines, saving energy actually a
cost factor in business in general as the explosion of more device
usage is leading to usage of more servers and network infrastructure
in all sectors of the society and business. This document describes
methods of optimizations by reducing periodic multicast messages,
frequent Neighbor Solicitation messages and provides a mechanism of
built-in prefix-dissemination in simple scenarios.
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 January 3, 2012.
Copyright Notice
Chakrabarti & Nordmark Expires January 3, 2012 [Page 1]
Internet-Draft Energy-aware-nd July 2011
Copyright (c) 2011 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The New Set Of Requirements . . . . . . . . . . . . . . . . . 5
5. New Neighbor Discovery Options and Messages . . . . . . . . . 5
5.1. Address Registration Option . . . . . . . . . . . . . . . 6
5.2. Authoritative Border Router Option . . . . . . . . . . . . 7
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
7. Energy-aware Neighbor Discovery Messages . . . . . . . . . . . 10
8. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 11
9. The Border Router(BR) Behavior . . . . . . . . . . . . . . . . 11
10. Intermediate-router Behavior . . . . . . . . . . . . . . . . . 12
11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Local Mobility . . . . . . . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
16.1. Normative References . . . . . . . . . . . . . . . . . . . 13
16.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Chakrabarti & Nordmark Expires January 3, 2012 [Page 2]
Internet-Draft Energy-aware-nd July 2011
1. Introduction
IPv6 ND [ND] is based on multicast signaling messages on the local
link in order to avoid broadcast messages. Following power-on and
initialization of the network in IPv6 Ethernet networks, a node joins
the solicited-node multicast address on the interface and then
performs duplicate address detection (DAD) for the acquired link-
local address by sending a solicited-node multicast message to the
link. After that it sends multicast router solicitation (RS)
messages to the all-router address to solicit router advertisements.
Once the host receives a valid router advertisement (RA) with the "A"
flag, it autoconfigures the IPv6 address with the advertised prefix
in the router advertisement (RA). Besides this, the IPv6 routers
usually send router advertisements periodically on the network. RAs
are sent to the all-node multicast address. Nodes send Neighbor
Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve
the IPv6 address of the destination on the link. These NS/NA
messages are also often multicast messages and it is assumed that the
node is on the same link and relies on the fact that the destination
node is always powered and generally available.
The periodic RA messages in IPv6 ND [ND], and NS/NA messages require
all IPv6 nodes in the link to be in listening mode even when they are
in idle mode. It requires energy for the sleepy nodes which may be
otherwise sleeping during idle mode. Non-sleepy nodes also may save
energy if instead of continuous listening mode, they actually pro-
actively synchronize their state with one or two entity in the
network. With the explosion of Internet-of-things and machine to
machine communication, more and more devices would be using IPv6
addresses in the near future. Today, most electricity usage in
United States and in developing countries are in the home buildings
and commercial buildings; the electronic Internet appliances/tablets
etc. are gaining popularities in the modern home networks. These
network of nodes must be conscious about saving energy as their
number increases as otherwise it will cost more and increase stress
on electrical grids, and increases carbon foot-print.
IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND]
addresses many of the concerns described above by optimizing the
Router advertisement, minimizing periodic multicast packets in the
network and introducing two new options - one for node registration
and another for prefix dissemination in a network where all nodes in
the network are uniquely identified by their 64-bit Interface
Identifier. EUI-64 identifiers are recommended as unique Interface
Identifiers, however if the network is isolated from the Internet,
uniqueness of the identifiers may be obtained by other mechanisms
such as a random number generator with lowest collision rate.
Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN
Chakrabarti & Nordmark Expires January 3, 2012 [Page 3]
Internet-Draft Energy-aware-nd July 2011
[LOWPAN] network, the concept is mostly applicable to IPv6 network
that wants to optimize power.
Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize
total number of related signaling messages without loosing generality
of Neighbor Discovery and autoconfiguration and making host and
router communication reliable, is desirable in any IPv6 energy-aware
networks such as Home or Enterprise building networks and as well as
Data Centers.
[ This document is under construction and will have an update soon to
solidify the content of the draft]
2. Definition Of Terms
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].
6LoWPAN-link:
It is a wireless link determined by single hop reachability of
neighboring nodes.
Intermediate-routers:
These are the intermediate routers in the home network who can
communicate with other intermediate routers in the same home
network. These are also the immediate first-hop router for the
physically attached hosts or wirelessly reachable hosts.
Root-node or Border Rotuer(BR):
It is a border router typically located at the junction Internet
and Home Network.
Host:
A host in a IPv6 network is considered a IPv6 node without routing
and forwarding capability.
EUI-64:
It is the IEEE defined 64-bit extended unique identifier formed by
concatenation of 24-bit or 36-bit company id value by IEEE
Registration Authority and the extension identifier within that
company-id assignment. The extension identifiers are 40-bit (for
24-bit company-id) or 28-bit (for the 36-bit company-id)
respectively.
3. Assumptions
o All nodes in the network carry unique interface ID in order to
form the auto-configured IPv6 address uniquely.
Chakrabarti & Nordmark Expires January 3, 2012 [Page 4]
Internet-Draft Energy-aware-nd July 2011
o All nodes use the same IPv6 prefix if multi-level prefix
distribution technique (described in this document) is used
o The special scenario for multi-level prefix dissemination requires
a topology where all packets of that network must go through a
access-gateway of that network. The access gateway may support
multi-level intermediate-rotuers with packet forwarding capability
and prefix-distribution capability as discussed in this document.
The hosts in this network must send and receive packets through a
default router. The default router could be the access-gateway or
the Border Router or the intermediate-router depending on the
location of the host.
4. The New Set Of Requirements
In future homes and new machine-to-machine networks, it will be very
often a hierarchical networks of sub-networks which are all directly
or indirectly served by a root-node router or gateway with an access
to the Internet.
In the cloud computing environment, it is possible that part of the
network or sub-network are geographically separated. Thus the
concept of IPv6-subnet of link-local nodes may be extended.
o Node initiated Registration and address allocation in order to
avoid periodic multicast messages.
o Address allocation through multicast IPv6 Neighbor Discovery [ND]
and IPv6 Autoconfiguration [AUTOCONF] with tuned parameters for
different sub-networks under one gateway or root home router. For
example, one sub-network consists of television and game station
networks and another network is a IEE 802.15.4 ZigBee IP network
running 6LoWPAN [LOWPAN].
o A Requirement of distribution of configuration securely cascading
through the network of sub-networks.
o The node registration may replace the requirement of doing
Duplicate Address Detection.
5. New Neighbor Discovery Options and Messages
This document points to the section of 6LoWPAN-ND [6LOWPAN-ND] as
appropriate. 6LoWPAN-ND [6LOWPAN-ND] assumes a concept of 6Lowpan-
link which is equivalent to a subnet in classical IPv6-subnet sharing
the same IPv6-prefix but it is a collection of sub-networks connected
by special routers called 6LR [6LOWPAN-ND].
Chakrabarti & Nordmark Expires January 3, 2012 [Page 5]
Internet-Draft Energy-aware-nd July 2011
5.1. Address Registration Option
The Address Registration Option(ARO) is useful for avoiding Duplicate
Address Detection messages since it requires a unique ID for
registration. The address registration is used for maintaining
reachability of the node or host by the router.
The routers keep track of host IP addresses that are directly
reachable and their corresponding link-layer addresses. This is
useful for lossy and lowpower networks and as well as wired networks.
An Address Registration Option (ARO) can be included in unicast
Neighbor Solicitation (NS) messages sent by hosts. Thus it can be
included in the unicast NS messages that a host sends as part of
Neighbor Unreachability Detection to determine that it can still
reach a default router. The ARO is used by the receiving router to
reliably maintain its Neighbor Cache. The same option is included in
corresponding Neighbor Advertisement (NA) messages with a Status
field indicating the success or failure of the registration. This
option is always host initiated.
The ARO is required for reliability and power saving. The lifetime
field provides flexibility to the host to register an address which
should be usable (the reachability information may be propagated to
the routing protocols) during its intended sleep schedule of nodes
that switches to frequent sleep mode.
The sender of the NS also includes the EUI-64 of the interface it is
registering an address from. This is used as a unique ID for the
detection of duplicate addresses. It is used to tell the difference
between the same node re-registering its address and a different node
(with a different EUI-64) registering an address that is already in
use by someone else. The EUI-64 is also used to deliver an NA
carrying an error Status code to the EUI-64 based link-local IPv6
address of the host.
When the ARO is used by hosts an SLLA option MUST be included and the
address that is to be registered MUST be the IPv6 source address of
the Neighbor Solicitation message.
Chakrabarti & Nordmark Expires January 3, 2012 [Page 6]
Internet-Draft Energy-aware-nd July 2011
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 = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: TBD1
Length: 8-bit unsigned integer. The length of the option in
units of 8 bytes. Always 2.
Status: 8-bit unsigned integer. Indicates the status of a
registration in the NA response. MUST be set to 0 in
NS messages. See below.
Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Registration Lifetime: 16-bit unsigned integer. The amount of time
in a unit of 10 seconds that the router should retain
the Neighbor Cache entry for the sender of the NS that
includes this option.
EUI-64: 64 bits. This field is used to uniquely identify the
interface of the registered address by including the
EUI-64 identifier assigned to it unmodified.
The Status values used in Neighbor Advertisements are:
+--------+--------------------------------------------+
| Status | Description |
+--------+--------------------------------------------+
| 0 | Success |
| 1 | Duplicate Address |
| 2 | Neighbor Cache Full |
| 3-255 | Allocated using Standards Action [RFC2434] |
+--------+--------------------------------------------+
Table 1
5.2. Authoritative Border Router Option
This is a special optional operation introducing prefix dissemination
for a simple scenario where a network of nodes under the same Border
Router (example: Home gateway) share the same prefix. The routers
Chakrabarti & Nordmark Expires January 3, 2012 [Page 7]
Internet-Draft Energy-aware-nd July 2011
below the Border Router have limited forwarding/routing capabilities
and the packets sent/received by them from the Internet MUST go via
the Border Router. This can assume that /64 bit prefix is delegated
from the authoritative Border Router node then propagated down
through the intermediate nodes to the hosts without change. The
intermediate routers should keep a copy of this prefix for local
distribution and are responsible for periodic synchronization.
|----|
| BR |
------
|
H7--------------H6
| |
iR1 iR2--H1
/ \ \
H2 H3 iR3
/ \
H4 H5
A typical Topology where ABRO is useful
In the above example, we can can think of BR as a Home gateway while
iR routers represent intermediate routers which can be considered as
in-home smaller routers connecting hosts for different applications
or usages such as appliance network or home-entertainment network.
The Authoritative Border Router option MUST be included in all Router
Advertisement messages when Router Advertisements are used to
propagate information between routers in the topology described
above.
Chakrabarti & Nordmark Expires January 3, 2012 [Page 8]
Internet-Draft Energy-aware-nd July 2011
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 = 3 | Version Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ BR Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: TBD3
Length: 8-bit unsigned integer. The length of the option in
units of 8 bytes. Always 3.
Version Number: 16-bit unsigned integer. The version number
corresponding to this set of information contained in
the RA message. The authoritative Border router
originating the prefix increases this version number
each time its set of prefix or context information
changes. This version number uses sequence number
arithmetic as it may wrap around.
Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
BR Address: IPv6 address of the Border Router that is the origin
of the included version number.
This document assumes that an implementation will have configuration
knobs to determine whether it is running in classical IPv6 ND [ND] or
Optimized Energy Aware ND (this document) mode
6. Applicability Statement
This document aims to guide the implementors to choose an appropriate
IPv6 neighbor discovery and Address configuration procedures suitable
for any IPv6 energy-aware network. These optimization is useful for
the classical IPv6 subnet and as well as future home network where
the network is composed of several sub-networks served by a root-node
or home-gateway and the hosts always send packets through a default-
router.
Chakrabarti & Nordmark Expires January 3, 2012 [Page 9]
Internet-Draft Energy-aware-nd July 2011
7. Energy-aware Neighbor Discovery Messages
1. Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only
solicited RAs are recommended. An RA MUST contain the Source
Link-layer Address option containing Router's link-layer address
(this is optional in [ND]. An RA MUST carry Prefix information
option with L bit being unset, so that hosts do not multicast
any NS messages as part of address resolution. In addition to
the Prefix option the RA may carry Authoritative Router option
option generated by the root-node.
2. Router Solicitation(RS): Upon system startup, the node sends a
multicast or link broadcast (when multicast is not supported at
the link-layer) RS to find out the available routers in the
link. An RS may be sent at other times as described in section
6.3.7 of RFC 4861. A Router Solicitation MUST carry Source
Link-layer Address option. Since no periodic RAs are allowed in
a 6LoWPAN network, the host may send periodic unicast messages
RS to the routers. The time-periods for the RS varies on the
deployment scenarios and the Default Router Lifetime advertised
in the RAs.
3. Default Router Selection: Same as in section 6.3.6 of RFC
4861[ND].
4. Neighbor Solicitation (NS): Neighbor solicitation is used
between the hosts and the default-router as part of NUD and
registering the host's address(es). An NS message MUST use the
Address Registration option in order to accomplish the
registration.
5. Neighbor Advertisement (NA): As defined in [ND]
6. Redirect Messages: A router may send a Redirect message to a
host. When to send the redirect message is implementation
specific; a router may be overloaded or by some means it can
determine the proximity of source and destination and decide
that they should directly talk to each other. The host behavior
is same as described in section 8.3 of RFC 4861[ND], i,e. a host
MUST NOT send redirect messages.
7. Message Validation: Same as in RFC 4861[ND]
8. MTU option: As per the RFC 4861.
9. Address Resolution: No NS/NA are sent as the prefixes are
treated as off-link. Thus no address resolution is performed at
the hosts. The routers keep track of Neighbor Solicitations
with Address Registration options(ARO) and create an extended
neighbor cache of reachable addresses. The router also knows
the nexthop link-local address and corresponding link-layer
address when it wants to route a packet.
10. Neighbor Unreachability Detection(NUD): NUD is performed in
"forward-progress" fashion as described in section 7.3.1 of RFC
4861[ND]. However, if Address Registration Option is used, the
NUD SHOULD be combined with the Re-registration of the node.
Chakrabarti & Nordmark Expires January 3, 2012 [Page 10]
Internet-Draft Energy-aware-nd July 2011
This way no extra message for NUD is required.
8. Host Behavior
A host sends Router Solicitation at the system startup and also when
it suspects that one of its default routers have become unreachable
(after NUD fails).
A host SHOULD be able to autoconfigure its IPv6 addresses using the
IPv6 prefix obtained from Router Advertisement. The host SHOULD form
its link-local address from the EUI-64 as specified by IEEE
Registration Authority and RFC 2373. If this draft feature is
implemented and configured, the host MUST NOT re-direct Neighbor
Discovery messages. The host does not require to join solicited-node
multicast address but it MUST join the all-node multicast address.
A host always sends packets to (one of) its default router(s) unless
it receives Router redirect messages from a neighboring router. This
is accomplished by the routers never setting the 'L' flag in the
Prefix options.
The host is unable to forward routes or participate in a routing
protocol.
9. The Border Router(BR) Behavior
A Border Router normally may have multiple interfaces and connects
the nodes in a link like a regular IPv6 subnet(s) or acts as a
gateway between separate networks such as Internet and home networks
. The Border Router is responsible for distributing one or more /64
prefixes to the nodes to identify a packet belonging to the
particular network.
The routers SHOULD NOT garbage collect Registered Neighbor Cache
entries since they need to retain them until the Registration
Lifetime expires. Similarly, if Neighbor Unreachability Detection on
the router determines that the host is UNREACHABLE (based on the
logic in [ND]), the Neighbor Cache entry SHOULD NOT be deleted but be
retained until the Registration Lifetime expires. A renewed ARO
should mark the cache entry as STALE.
When the BR sends a Router Advertisement it SHOULD include a
Authoritative Router option that includes its own address.
A BR keeps a cache for all the nodes' IP addresses, created from the
Address Registration processing. It may send the Router
Chakrabarti & Nordmark Expires January 3, 2012 [Page 11]
Internet-Draft Energy-aware-nd July 2011
advertisement with Prefix option and Authoritative Border Router
option.
10. Intermediate-router Behavior
The intermediate routers may exist in some special scenarios of home
networks or other networks where the Border Router sits at the root
of the network and all packets go in and out of the gateway.
The behavior of this node is still under discussion. But it aids in
prefix dissemination or distribution if the Border Router sends the
ABRO option with Router Advertisements. The intermediate-router role
is somewhat similar to 6LR as defined in [6LOWPAN-ND]. If the
intermediate-router acts as a default router to its neighboring
hosts, then it should be able to process the Address Registration
option and register the neighboring nodes.
11. Bootstrapping
If the network is a classic IPv6 subnet, and the energy-aware
Neighbor Discovery mechansim is used, then the node uses its link-
local address to send Router Solicitation and then it sends the Node
Registration message as described in this document in order to form
the address. The Duplicate address detection process should be
skipped if the network is guaranteed to have unique interface
identifiers.
The intermerdiate-routers may also first bootstrap as a host and then
turn themselves into router-mode. The detail messages will be
discussed in the next version of the document.
12. Local Mobility
If energy-aware Neighbor Discovery model is used and same IPv6 prefix
is shared by all the nodes in the network that is accessed by the
Border Router, then it assures transparent mobility of the nodes
inside the network bordered by Border Router.
The local mobility transparency is quite useful in a home network
environment where multiple networks may exist and be served by a
Border Router or a Home Gateway. Thus one can wirelessly move a node
from one home sub-network to another without disrupting data
connection.
Chakrabarti & Nordmark Expires January 3, 2012 [Page 12]
Internet-Draft Energy-aware-nd July 2011
13. Security Considerations
These optimizations are not known to introduce any new threats
against Neighbor Discovery beyond what is already documented for IPv6
[RFC 3756]. However, careful security considerations will be handled
in a follow-up IETF publication of this draft.
14. IANA Considerations
TBD
15. Acknowledgements
The primary idea of this document are from 6LoWPAN Neighbor Discovery
document [6LOWPAN-ND] and the discussions from the 6lowpan working
group members, chairs Carsten Bormann and Geoff Mulligan and through
our discussions with Zach Shelby.
The inspiration of such a IPv6 generic document came from Margaret
Wasserman who saw a need for such a document at the IOT workshop at
Prague IETF.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[6LOWPAN-ND]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "ND
Optimizations for 6LoWPAN", draft-ietf-6lowpan-nd-17.txt
(work in progress), June 2011.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6", RFC 4861,
September 2007.
[LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6
Packets over IEEE 802.15.4 networks", RFC 4944,
September 2007.
Chakrabarti & Nordmark Expires January 3, 2012 [Page 13]
Internet-Draft Energy-aware-nd July 2011
[LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
Assumptions, Problem Statement and Goals", RFC 4919,
August 2007.
16.2. Informative References
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6), Specification", RFC 2460, December 1998.
[AUTOCONF]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Autoconfiguration", RFC 4862, September 2007.
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure
Neighbor Discovery", RFC 3971, March 2005.
[AUTOADHOC]
Baccelli, E. and M. Townsley, "IP Addressing Model in
Adhoc Networks",
draft-ietf-autoconf-adhoc-addr-model-02.txt (work in
progress), December 2009.
[IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", ,
October 2003.
[PD] Miwakawya, S., "Requirements for Prefix Delegation",
RFC 3769, June 2004.
[ULA] "Unique Local IPv6 Addresses", RFC 4193.
Authors' Addresses
Samita Chakrabarti
Ericsson
San Jose, CA
USA
Email: samita.chakrabarti@ericsson.com
Erik Nordmark
Cisco Systems
San Jose, CA
USA
Email: nordmark@cisco.com
Chakrabarti & Nordmark Expires January 3, 2012 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 01:38:55 |