Internet DRAFT - draft-sood-6man-nd-signalling-n-dad-test
draft-sood-6man-nd-signalling-n-dad-test
6man WG A. Sood
Internet-Draft North Carolina State University
Intended status: Informational March 9, 2015
Expires: September 10, 2015
Test result analysis of IPv6 Neighbor Discovery in a simple Wireless
network
draft-sood-6man-nd-signalling-n-dad-test-00
Abstract
IPv6 WG is looking into various Neighbor Discovery (ND) optimization
techniques. This document describes several test cases and test
results on IPv6 ND number of messages, power usages using simple WiFi
configuration and wireless phones as hosts.
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 September 10, 2015.
Copyright Notice
Copyright (c) 2015 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.
Sood Expires September 10, 2015 [Page 1]
Internet-Draft IPV6-ND March 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv6 Stateless Address Auto-configuration . . . . . . . . . . 3
3. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Current Mechanisms in Sleep and Wakeup . . . . . . . . . . 5
3.2. Issues with the current mechanism . . . . . . . . . . . . 5
4. Experimental Setup . . . . . . . . . . . . . . . . . . . . . . 5
5. Test Case Scenarios . . . . . . . . . . . . . . . . . . . . . 7
6. Test Case Results . . . . . . . . . . . . . . . . . . . . . . 8
6.1. IPv6 ND Implementation Behavior . . . . . . . . . . . . . 8
6.2. Number of multicast messages . . . . . . . . . . . . . . . 9
7. Results Analysis . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Sood Expires September 10, 2015 [Page 2]
Internet-Draft IPV6-ND March 2015
1. Introduction
This document presents the test result analysis of several IPv6 ND
test cases in a simple wireless network. Multiple test cases are
performed on two different IPv6 ND implementations to show anomalies
due to different power saving technique implementations on wireless
devices.
IPv6 ND involves link-local discovery and address auto-configuration
using multicast solicitation and advertisement messages. It provides
a number of functionalities using link-local operations and, eases
the configuration task for the administrator [SLAAC]. However, to
increase the efficiency of the battery system, the power consumption
due to the number of multicast messages exchanged in IPv6 ND process
should be kept at minimum as per
[I-D.vyncke-6man-mcast-not-efficient].
Several power saving techniques based on the sleep and wakeup
interval of a device have been proposed. These techniques optimize
the power by scheduling the node between cycles of sleep and wakeup
[SOW]. It is the lack of any standardized technique that the devices
from various manufacturers function differently and, pose challenges
to automated management protocols like IPv6 ND [ND] and Stateless
Address Auto-configuration (SLAAC) [SLAAC].
In this document, we present the test result analysis of different ND
test cases using a simple wireless network.The difference in behavior
comes from the implementation of the power saving techniques. We
further show by analysis the difference in the number of ND messages
exchanged between the devices due to different power saving
techniques.
Section 2 describes the IPv6 SLAAC mechanism. Section 3 describes
the current mechanism in sleep and wake up and the issues associated
with it. Section 4 describes the experimental setup used. Section 5
describes the various test case scenarios and their expected
behavior. Sections 6 presents the test case results regarding IPv6
ND implementation behavior and the number of multicast messages
exchanged in different scenarios.
2. IPv6 Stateless Address Auto-configuration
In IPv6 SLAAC, the host generates a link-local address on system
startup, and global addresses using the IPv6 prefix advertised by the
routers on the same link. The host either listens to multicast
router advertisement (RA) or sends multicast router solicitation (RS)
messages. The link-local address and global IPv6 addresses remain
Sood Expires September 10, 2015 [Page 3]
Internet-Draft IPV6-ND March 2015
tentative unless they are verified to be unique by Duplicate Address
Detection (DAD) algorithm. In DAD, a node checks the uniqueness of
the IPv6 address by sending a neighbor solicitation (NS) message to
the tentative IPv6 address as the destination address. The address
gets assigned to an interface only if no other node responds to the
NS message.
A general sequence of messages exchanged between the IPv6 host and
the router is as shown below.
IPv6 Host IPv6 Router
+ +
| |
| Router Advertisement |
All Nodes |<---------------------------+ Router Link
MC Address | | Local Address
| Router Solicitation |
Node Link +--------------------------->| All Routers
Local Address| | MC Address
| Router Advertisement |
All Nodes |<---------------------------+ Router Link
MC Address | | Local Address
| Multicast Listener Report |
Node Link +--------------------------->| All MLDv2-capable
Local Address| | Routers
| DAD |
+--------------------------->|
Unspecified | | Solicited Node
Address | DAD | MC Address
+--------------------------->|
| |
| |
+ +
Figure 1: Sequence of messages exchanged between IPv6 host and router
3. Sleep and Wakeup
The current increase in mobile services require efficient use of the
battery power. The battery power usually lasts from few hours to few
days. A number of power saving techniques are proposed to make the
protocols energy efficient and thus increase the battery life [CO-PS]
[CO-NODE]. These power saving techniques improve the energy
consumption by optimizing the sleep and wake up pattern of the mobile
host.
Sood Expires September 10, 2015 [Page 4]
Internet-Draft IPV6-ND March 2015
In this section, we present the current mechanisms in IPv6 for
handling sleep and wake up and the issues related to it.
3.1. Current Mechanisms in Sleep and Wakeup
IPv6 ND [ND] does not provide any recommendations for handling sleep
and wake up in mobile hosts. The general mechanism of the neighbor
discovery and address auto-configuration require the destination host
in the listening state. This idea of an "always on" host contrasts
with the techniques used for power saving where the host has cycles
of sleep and wake up time. During the sleep time, few power saving
techniques keep the host listening to the incoming multicast messages
while others completely shuts off all communication and goes to
complete sleep.
[6LOWPAN-ND]suggest optimizations to ND by avoiding multicast
messages except during system bootup or when the routers become
unreachable.
3.2. Issues with the current mechanism
The non-standardization of the power saving techniques pose
challenges to the current mechanisms in sleep and wake up for
automatic IPv6 ND and SLAAC. These protocols function differently
with power saving techniques which lead to serious security issues.
Therefore [EFF-ND] suggest modifications to the legacy IPv6 ND for
handling energy efficiency in a multicast network domain.
Issues in legacy IPv6 ND due to the power saving techniques depend on
the below scenarios:
o Sleep and wake up interval
o Sleep and wake up pattern
o Reachability to the routers on the same link
o Address binding while in sleep mode and after wake up
o Connectivity to other hosts while in sleep mode and after wake up
In the subsequent section, we present various experimental results to
show the deficiencies of the current mechanism for handling sleep and
wake up.
4. Experimental Setup
The experimental setup used is as shown in Figure 2. A Linux machine
running Ubuntu 14.04 LTS is configured as an IPv6 router. IPv6 ND
functionality is provided by the router advertisement daemon (radvd)
in Linux router. Following are the minimal router configuration
related to radvd and interfaces.
Sood Expires September 10, 2015 [Page 5]
Internet-Draft IPV6-ND March 2015
o radvd configuration
interface eth0
{
AdvSendAdvert on;
prefix 2001:db8:5::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
o Interface configuration
The eth0 interface on the IPv6 router is configured as below.
auto eth0
iface eth0 inet6 static
address 2001:db8:5::1
netmask 64
IPv6 forwarding is enabled in the sysctl.conf by setting
net.ipv6.conf.all.forwarding to 1.
The router connects via its eth0 interface to the WAN port of the
access point (AP). The configuration of the AP is manufacturer
specific and should be done to allow IPv6 traffic to pass through it.
The two IPv6 enabled wireless mobile stations (MS) namely MS A and MS
B, connects to the AP via 802.11 wireless links; and the IPv6 Linux
host connects to the AP via its Ethernet interface.
+------------+
| Router |
+------+-----+
|
+-------+------+
| Access Point |
+-------+------+
|
+------------------------+
| | |
+---+--+ +--+---+ +-----+-----+
| MS A | | MS B | | Linux Host|
+------+ +------+ +-----------+
Figure 2: Experimental Setup
Sood Expires September 10, 2015 [Page 6]
Internet-Draft IPV6-ND March 2015
5. Test Case Scenarios
The various test scenarios along with their expected behavior are
discussed below:
Messages exchanged between the router and the MS on boot up:
When a MS boots up, it either solicits the router using multicast
RS or listens to its multicast RA. The number of IPv6 addresses
configured on the interface depends on the specific IPv6
implementations. The addresses are either global IPv6 privacy
addresses, EUI-64 format addresses or both. The router also sends
Multicast Listener Report messages to discover the presence of
multicast listeners on the attached links [MLDv2].
Address binding when the MS is in sleep state:
The behavior of the MS in this scenario depends on the specific
implementation of the power saving technique. MS either listens
to the incoming messages in partial sleep state or shuts off all
communication and goes to complete sleep.
Address binding when the MS wakes up:
When the MS wakes up, it checks for the uniqueness of the IPv6
address configured on its interfaces. The specific behavior in
this scenario depends on the power saving technique used. If the
MS continuously listens to the incoming multicast messages in
partial sleep state, it still holds the interface IPv6 address.
On the other hand, if the MS goes to complete sleep, it may or may
not hold its configured IPv6 address.
Communication when the MS wakes up:
In this case, two scenarios are possible.
(1) Unique IPv6 address - An IPv6 host has unique IPv6 address in
the network. Therefore, the host receives its intended
communication.
(2) Duplicate IPv6 address - Two or more IPv6 hosts have same IP
address in the network. Communication to these hosts depends
upon the latest neighbor cache entries at the router. The
host corresponding to the latest neighbor cache entry at
router continues to receive the communication.
Number of multicast messages sent in the network
According to [ND], MinRtrAdvInterval is the minimum time allowed
between sending unsolicited multicast RA from the interface, in
seconds, and, MaxRtrAdvInterval is the maximum time allowed
between sending unsolicited multicast RA from the interface, in
seconds.
Sood Expires September 10, 2015 [Page 7]
Internet-Draft IPV6-ND March 2015
In this scenario, we have three different types of observation
based on different values of MinRtrInterval, MaxRtrInterval,
and AdvDefaultLifetime.
6. Test Case Results
In this section, we present the experimental results of
different IPv6 ND implementation behavior. Next we present the
detailed analysis of the number of multicast messages exchanged in
different scenarios.
6.1. IPv6 ND Implementation Behavior
Based on the above test scenarios, below are the observations on the
two IPv6 ND implementations.
Messages exchanged between the router and the MS on boot up:
(1) The number of messages exchanged between the router and the
MS are tabulated below:
+------------------------------+------+------+
| Type Of Message | MS A | MS B |
+------------------------------+------+------+
| Router Solicitation | 1 | 1 |
| Router Advertisement | 1 | 1 |
| Neighbor Solicitation | 3 | 2 |
| Neighbor Advertisement | 0 | 0 |
| Multicast Listener Report | 4 | 2 |
| ---------------------------- | ---- | ---- |
| Total Number of messages | 9 | 6 |
+------------------------------+------+------+
Table 1: Number of multicast messages exchanged during boot
up
(2) MS A on boot up generates two global IPv6 privacy addresses
using the prefix advertised by the router. It also generates
a link-local IPv6 address. MS A performs DAD for all the
three IPv6 addresses.
Sood Expires September 10, 2015 [Page 8]
Internet-Draft IPV6-ND March 2015
(3) MS B on boot up generates two global addresses: an EUI-64
format address and the other as IPv6 privacy address using
the prefix advertised by the router. It also generates a
link-local address. It performs DAD only for the two global
IPv6 addresses.
(4) The difference in the total number of messages is attributed
to the difference in MLDv2 and NS messages. The number of
MLDv2 messages exchanged depends upon the implementation.
Also, MS B does not send NS message to check the uniqueness
of the link local address.
Address binding when the MS is in sleep state:
(1) When MS A goes to sleep, any attempt to assign its global
IPv6 address to the Linux host fails. This is because MS A
keeps listening to the NS message from the Linux host during
the DAD procedure and responds with NA message.
(2) When MS B goes to sleep, any attempt to assign its global
IPv6 address to the Linux host succeeds. While asleep, MS B
shuts off all communication. Any communication to MS B goes
to the Linux host configured with MS B's global IPv6 address.
Address binding when the MS wakes up:
Both MS A and MS B does not perform DAD on wake up.
(1) MS A continuously listens to incoming messages while asleep,
and thus do not need to perform DAD.
(2) MS B too does not check for the uniqueness of its IPv6
address via DAD in spite of coming out of complete sleep
state.
Communication when the MS wakes up:
(1) MS A always keeps listening to incoming messages, so it's
IPv6 address cannot be assigned to any other IPv6 host.
(2) In this scenario, the Linux host is assigned the IPv6 address
of MS B which is in sleep state. All messages destined for
MS B now goes to the Linux host. The Linux host continues to
receive the messages until its entry lasts in the router
neighbor cache. Once the router cache is flushed, either by
manual intervention or by router boot up, the router solicits
the solicited-node multicast address for link-layer address
resolution. Linux host replies before MS B to this RA
message. Since MS B entry is latest in the router cache, it
again becomes the destination for all the messages.
6.2. Number of multicast messages
Below are the observations based on the number of multicast messages
sent in the network.
Sood Expires September 10, 2015 [Page 9]
Internet-Draft IPV6-ND March 2015
Number of multicast RA messages sent in the network
The number of RA messages exchanged between the MS and the router
for a duration of 5, 10, and 15 minutes are tabulated below:
+-------------+------------+------------+-------------+-------------+
| Time | Min/Max | Min/Max | Min/Max | Min/Max |
| Duration | 30/70 | 30/150 | 30/300 | 30/600 |
+-------------+------------+------------+-------------+-------------+
| 5 minutes | 8 | 4 | 4 | 3 |
| 10 minutes | 15 | 6 | 5 | 3 |
| 15 minutes | 18 | 13 | 8 | 4 |
+-------------+------------+------------+-------------+-------------+
Table 2: Number of RA messages exchanged
From the above table, we observe, as the difference between
MinRtrAdvInterval and MaxRtrAdvInterval increases, the number of
RA messages sent in the network reduces.
Total number of multicast messages sent in the network
The number of multicast messages exchanged between the MS and the
router for a duration of 5, 10, and 15 minutes are tabulated below:
+-------------+------------+------------+-------------+-------------+
| Time | Min/Max | Min/Max | Min/Max | Min/Max |
| Duration | 30/70 | 30/150 | 30/300 | 30/600 |
+-------------+------------+------------+-------------+-------------+
| 5 minutes | 14 | 11 | 10 | 8 |
| 10 minutes | 21 | 11 | 12 | 10 |
| 15 minutes | 24 | 20 | 15 | 9 |
+-------------+------------+------------+-------------+-------------+
Table 3: Total number of multicast Messages exchanged
From the above table, we observe, as the difference between
MinRtrAdvInterval and MaxRtrAdvInterval increases, the total
number of messages sent in the network reduces.
Number of RA messages vs AdvDefaultLifetime
In this case, the number of RA messages exchanged between the
MS and the router are observed with respect to AdvDefaultLifetime.
AdvDefaultLifetime defines the lifetime of the router as a default
router, and is measured in seconds.
The number of RA messages is measured with different values of
AdvDefaultLifetime, MinRtrInterval and MaxRtrInterval for a
duration of 5, 10, and 15 minutes and are tabulated below:
Sood Expires September 10, 2015 [Page 10]
Internet-Draft IPV6-ND March 2015
+--------------------+---------+--------------+
| AdvDefaultLifetime | Min/Max | Number of RA |
+--------------------+---------+--------------+
| 150 | 30/50 | 13 |
| 450 | 30/150 | 9 |
| 900 | 30/300 | 11 |
| 1800 | 30/600 | 9 |
| 2700 | 30/900 | 9 |
| 3600 | 30/1200 | 10 |
| 4500 | 30/1500 | 10 |
| 5400 | 30/1800 | 9 |
+--------------------+---------+--------------+
Table 4: Number of RA Messages vs AdvDefaultLifetime (5 minutes)
+--------------------+---------+--------------+
| AdvDefaultLifetime | Min/Max | Number of RA |
+--------------------+---------+--------------+
| 150 | 30/50 | 28 |
| 450 | 30/150 | 20 |
| 900 | 30/300 | 23 |
| 1800 | 30/600 | 21 |
| 2700 | 30/900 | 19 |
| 3600 | 30/1200 | 21 |
| 4500 | 30/1500 | 21 |
| 5400 | 30/1800 | 24 |
+--------------------+---------+--------------+
Table 5: Number of RA Messages vs AdvDefaultLifetime (10 minutes)
+--------------------+---------+--------------+
| AdvDefaultLifetime | Min/Max | Number of RA |
+--------------------+---------+--------------+
| 150 | 30/50 | 41 |
| 450 | 30/150 | 33 |
| 900 | 30/300 | 35 |
| 1800 | 30/600 | 29 |
| 2700 | 30/900 | 34 |
| 3600 | 30/1200 | 33 |
| 4500 | 30/1500 | 32 |
| 5400 | 30/1800 | 34 |
+--------------------+---------+--------------+
Table 6: Number of RA Messages vs AdvDefaultLifetime (15 minutes)
Sood Expires September 10, 2015 [Page 11]
Internet-Draft IPV6-ND March 2015
The frequency of messages depends upon the difference between
MaxRtrAdvInterval and MinRtrAdvInterval. From the above tables,
we observe, almost the same number of RA messages are sent by the
router as for both high and low frequency cases. Only when the
frequency is very high (for example MinRtrAdvInterval = 30 seconds
and MaxRtrAdvInterval = 50 seconds), there is a surge in the
number of RA messages.
7. Results Analysis
From the above test case analysis, we observe that considerable
number of unsolicited RA messages are generated and those can be
minimized. Also, in order to cope with battery power and IPv6 ND
SLAAC behavior, implementations are coming up with independent
solutions which can create serious security and reliability issues
when the traffic of a sleeping host goes to another host configured
with same IPv6 address. We also observe that the number of multicast
messages are different in the two IPv6 ND implementations. These
anomalies depends on vendors IPv6 implementation and the power saving
techniques. In the next step, we target to test [EFF-ND] enhanced
mode approach to observe the realiability and multicast message
exchanges among multiple implementations.
8. Security Considerations
9. IANA Considerations
This memo includes no request to IANA.
10. Changelog
11. Acknowledgements
The author would like to thank Samita Chakrabarti for her valuable
suggestions and insight on this work.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Sood Expires September 10, 2015 [Page 12]
Internet-Draft IPV6-ND March 2015
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[EFF-ND] Chakrabarti, S., Nordmark, E., Thubert, P., and M.
Wasserman, "IPv6 Neighbor Discovery Optimizations for
Wired and Wireless Networks",
draft-chakrabarti-nordmark-6man-efficient-nd-06 (work in
progress), February 2014.
[6LOWPAN-ND]
Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"ND Optimizations for 6LoWPAN", RFC 6775, November 2012.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6", RFC 4861,
September 2007.
[SLAAC] Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[SOW] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574 , April 2012.
12.2. Informative References
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6), Specification", RFC 2460, December 1998.
[I-D.vyncke-6man-mcast-not-efficient]
Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer",
draft-vyncke-6man-mcast-not-efficient-01 (work in
progress), February 2014.
[CO-PS] Cao, Z., Gomez, C., Kovatsch, M., Tian, H., and X. He,
"Energy Efficient Implementation of IETF Constrained
Protocol Suite", draft-ietf-lwig-energy-efficient-01 (work
in progress), October 2014.
[CO-NODE] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
[MLDv2] Vida, R. and L. Costa Eds, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Sood Expires September 10, 2015 [Page 13]
Internet-Draft IPV6-ND March 2015
Author's Address
Ankur Sood
North Carolina State University
Raleigh, NC
USA
Email: asood2@ncsu.edu
Sood Expires September 10, 2015 [Page 14]
