< draft-thubert-tree-discovery-02.txt   draft-thubert-tree-discovery-03.txt >
NEMO Working Group P. Thubert NEMO Working Group P. Thubert
Internet-Draft Cisco Internet-Draft Cisco
Expires: January 16, 2006 C. Bontoux Expires: October 22, 2006 C. Bontoux
Fortinet Fortinet
N. Montavont N. Montavont
LSIIT - ULP LSIIT - ULP
July 15, 2005 April 20, 2006
Nested Nemo Tree Discovery Nested Nemo Tree Discovery
draft-thubert-tree-discovery-02.txt draft-thubert-tree-discovery-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2006. This Internet-Draft will expire on October 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The purpose of this paper is to describe a minimum set of features The purpose of this paper is to describe a minimum set of features
that extends the Nemo basic support [4] in order to avoid loops in that extends the Nemo basic support [4] in order to avoid loops in
the nested Nemo case. As a result, Mobile Routers assemble into a the nested Nemo case. As a result, Mobile Routers assemble into a
tree that can be optimized based on various metrics. tree that can be optimized based on various metrics.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Multi-Homed nested mobile network . . . . . . . . . . . . 4 3.1 Multi-Homed nested mobile network . . . . . . . . . . . . 5
3.2 Loops in nested Nemo . . . . . . . . . . . . . . . . . . . 5 3.2 Loops in nested Nemo . . . . . . . . . . . . . . . . . . . 6
4. Router Advertisement extensions . . . . . . . . . . . . . . . 6 4. Router Advertisement extensions . . . . . . . . . . . . . . . 8
4.1 Router Advertisement message . . . . . . . . . . . . . . . 6 4.1 Router Advertisement message . . . . . . . . . . . . . . . 8
4.2 Tree Information Option . . . . . . . . . . . . . . . . . 7 4.2 Tree Information Option . . . . . . . . . . . . . . . . . 8
4.3 TIO suboption . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2 Pad1 . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.3 PadN . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.4 Bandwidth Suboption . . . . . . . . . . . . . . . . . 12
4.3.5 Stable time Suboption . . . . . . . . . . . . . . . . 13
4.3.6 Tree Group ID Suboption . . . . . . . . . . . . . . . 13
5. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 tree selection . . . . . . . . . . . . . . . . . . . . . . 11 5.1 tree selection . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Sub-tree mobility . . . . . . . . . . . . . . . . . . . . 11 5.2 Sub-tree mobility . . . . . . . . . . . . . . . . . . . . 16
5.3 DRL entries states and stability . . . . . . . . . . . . . 11 5.3 Administrative depth . . . . . . . . . . . . . . . . . . . 17
5.3.1 Held-Up . . . . . . . . . . . . . . . . . . . . . . . 12 5.4 DRL entries states and stability . . . . . . . . . . . . . 17
5.3.2 Held-Down . . . . . . . . . . . . . . . . . . . . . . 13 5.4.1 Held-Up . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.3 Collision . . . . . . . . . . . . . . . . . . . . . . 13 5.4.2 Held-Down . . . . . . . . . . . . . . . . . . . . . . 19
5.3.4 Instability . . . . . . . . . . . . . . . . . . . . . 14 5.4.3 Collision . . . . . . . . . . . . . . . . . . . . . . 19
5.4 Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 14 5.4.4 Instability . . . . . . . . . . . . . . . . . . . . . 20
5.5 Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Directed Acyclic Graph Discovery . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 16
8.2 Changes from version 01 to 02 . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 21
9.2 Changes from version 01 to 02 . . . . . . . . . . . . . . 21
9.3 Changes from version 02 to 03 . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 17
10.2 Informative Reference . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1 Normative Reference . . . . . . . . . . . . . . . . . . . 23
11.2 Informative Reference . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
As per Nemo Basic support [4], a Mobile Router autoconfigures a As per Nemo Basic support [4], a Mobile Router autoconfigures a
single Care of Address (CoA) to register to its Home Agent and single Care of Address (CoA) to register to its Home Agent and
terminate its Mobile Router-Home Agent tunnel. That Care of Address terminate its Mobile Router-Home Agent tunnel. That Care of Address
is the Mobile Router point of attachment to the nested Nemo. is the Mobile Router point of attachment to the nested Nemo.
Consequently, if loops are avoided, the nested Nemo assumes the shape Consequently, if loops are avoided, the nested Nemo assumes the shape
of a tree. The nodes of the tree are Mobile Routers, the root is of a tree. The nodes of the tree are Mobile Routers, the root is
skipping to change at page 3, line 34 skipping to change at page 4, line 34
decisions, loops between Mobile Routers will be avoided. decisions, loops between Mobile Routers will be avoided.
The method is based on an autonomous decision by each Mobile Router The method is based on an autonomous decision by each Mobile Router
with no global state convergence such as a MANET proactive routing with no global state convergence such as a MANET proactive routing
protocol. In fact, Mobile Routers may make different decisions from protocol. In fact, Mobile Routers may make different decisions from
a same input, based on their own configuration and their own a same input, based on their own configuration and their own
algorithms. algorithms.
In order to build trees of Mobile Routers, we propose an extension to In order to build trees of Mobile Routers, we propose an extension to
the ICMP Router Advertisement (RA) message, the Tree Information the ICMP Router Advertisement (RA) message, the Tree Information
Option (TIO). The RA-TIO allows Mobile Routers to advertise the tree Option (TIO). The TIO allows Mobile Routers to advertise the tree
they belong to, and to select and move to the best location within they belong to, and to select and move to the best location within
the available trees. Mobile Routers propagate the TIO down the tree, the available trees. Mobile Routers propagate the TIO in RA down the
updating some metrics such as the tree depth, leaving alone root tree, updating some metrics such as the tree depth, leaving alone
information such as the tree identifier, and sending the result in root information such as the tree identifier, and sending the result
RAs over the ingress interfaces. in RAs over the ingress interfaces.
2. Terms and Abbreviations 2. Terms and Abbreviations
This document assumes that the reader is familiar with Mobile IPv6 as This document assumes that the reader is familiar with Mobile IPv6 as
defined in [3] and with the concept of Mobile Router defined in the defined in [3] and with the concept of Mobile Router defined in the
Nemo terminology document [6]. Nemo terminology document [6].
For the needs of this paper, the following new definitions are For the needs of this paper, the following new definitions are
introduced: introduced:
skipping to change at page 4, line 31 skipping to change at page 5, line 31
router that does not support Router Advertisement - Tree router that does not support Router Advertisement - Tree
Information Option. Information Option.
Mobile Access Router: A Mobile Router that provides Access Router Mobile Access Router: A Mobile Router that provides Access Router
services to other Mobile Routers. services to other Mobile Routers.
Attachment Router: The Router that is selected as Access Router by a Attachment Router: The Router that is selected as Access Router by a
Mobile Router, making it its parent in the nested NEMO tree. Mobile Router, making it its parent in the nested NEMO tree.
Propagation: The action by a Mobile Router that consists in receiving Propagation: The action by a Mobile Router that consists in receiving
a Router Advertisement - Tree Information Option from its a Router Advertisement Tree Information Option from its Attachment
Attachment Router, recomputing a few specific fields, removing Router, recomputing a few specific fields, removing unknown
unknown suboption, and appending the resulting TIO to RAs sent suboptions, and appending the resulting TIO to RAs sent over the
over the ingress interfaces. ingress interfaces.
3. Motivations 3. Motivations
3.1 Multi-Homed nested mobile network 3.1 Multi-Homed nested mobile network
A nested mobile network that is made of multiple Mobile Routers A nested mobile network that is made of multiple Mobile Routers
having a direct connection to the Internet is said to be multi-homed. having a direct connection to the Internet is said to be multi-homed.
Multihoming in Nemo offers useful properties to Mobile Network Nodes. Multihoming in Nemo offers useful properties to Mobile Network Nodes.
The NEMO multihoming issues [9] draft lists potential multi-homed The NEMO multihoming issues [9] draft lists potential multi-homed
configurations for Nemo and explains the different problems and configurations for Nemo and explains the different problems and
skipping to change at page 5, line 40 skipping to change at page 6, line 40
distribute information on the hierarchy of Mobile Routers. This distribute information on the hierarchy of Mobile Routers. This
information can be distributed to Attachment Routers, Mobile Routers information can be distributed to Attachment Routers, Mobile Routers
and Mobile Network Nodes as well in order to allow better route and Mobile Network Nodes as well in order to allow better route
selection and to increase the knowledge of the Nemo topology on each selection and to increase the knowledge of the Nemo topology on each
node. node.
3.2 Loops in nested Nemo 3.2 Loops in nested Nemo
When several Mobile Routers attach to each other to form a nested When several Mobile Routers attach to each other to form a nested
Nemo, loops can be created if they are not explicitly avoided. In Nemo, loops can be created if they are not explicitly avoided. In
the simplest case, when egress and ingress interfaces of an Mobile the simplest case, when egress and ingress interfaces of A Mobile
Router are all wireless, a mobile router may be listening to Router Router are all wireless, a mobile router may be listening to Router
Advertisement from its own ingress interface, creating a confliction Advertisement from its own ingress interface, creating a confliction
problem. In the general case, arbitrary attachment of Mobile Routers problem. In the general case, arbitrary attachment of Mobile Routers
will form graphs that are not exempt of loops. For instance: Assume will form graphs that are not exempt of loops. For instance: Assume
a nested Nemo where Mobile Router1 is connected to the a nested Nemo where Mobile Router1 is connected to the
infrastructure, and Mobile Router3 is attached to Mobile Router2. infrastructure, and Mobile Router3 is attached to Mobile Router2.
Say that Mobile Router2 can hear both Mobile Router3 and Mobile Say that Mobile Router2 can hear both Mobile Router3 and Mobile
Router1 over its wireless egress interface. If Mobile Router2 select Router1 over its wireless egress interface. If Mobile Router2 select
Mobile Router1, the connectivity to the infrastructure is provided Mobile Router1, the connectivity to the infrastructure is provided
for all. But if Mobile Router2 selects Mobile Router3, Mobile for all. But if Mobile Router2 selects Mobile Router3, Mobile
skipping to change at page 7, line 28 skipping to change at page 8, line 43
Figure 1: Router Advertisement Figure 1: Router Advertisement
Nemo enabled router (N) Nemo enabled router (N)
The Nemo enabled router (N) bit is set when the sending router is a The Nemo enabled router (N) bit is set when the sending router is a
Mobile Router. Mobile Router.
4.2 Tree Information Option 4.2 Tree Information Option
The following option regroups the minimum information that allows a The Tree Information Option carries a number of metrics and other
Mobile Router to discover a tree and select its point of attachment information that allows a Mobile Router to discover a tree and select
while avoiding loop generation. It can also be used by Mobile its point of attachment while avoiding loop generation.
Network Nodes to select their best default router. If the default
router of a non-Mobile Router sends Router Advertisements with a tree
discovery option, the non-Mobile Router MUST set the N flag of its
own Router Advertisement to 0 and copy the Tree Discovery Option in
its own Router Advertisement.
0 1 2 3 The option is a container option, which might contain a number of
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 suboptions. The base option regroups the minimum information set
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ that is mandatory in all cases.
| Type | Length |G|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TreePref. | Preference | BootTimeRandom |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TreeDepth | Reserved | TreeDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDigest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| TreeID |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Tree Information Option A TIO can also be used by Mobile Network Nodes to select their best
default router. If the default router of a non-Mobile Router sends
Router Advertisements with a Tree Information Option, the non-Mobile
Router MUST set the N flag of its own Router Advertisement to 0 and
copy the Tree Discovery Option in its own Router Advertisement.
Type 8-bit unsigned integer set to 10 by the clusterhead. Value is 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 |G|H|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TreePref. | BootTimeRandom |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MR Preference | TreeDepth | TreeDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDigest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| TreeID |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RA Tree Information Option
Type: 8-bit unsigned integer set to 10 by the clusterhead. Value is
"TBD". "TBD".
Length 8-bit unsigned integer set to 4. The length of the option Length: 8-bit unsigned integer set to 4 when there is no suboption.
(including the type and length fields) in units of 8 octets. The length of the option (including the type and length fields and
the suboptions) in units of 8 octets.
Grounded (G) The Grounded (G) flag is set when the clusterhead is Grounded (G): The Grounded (G) flag is set when the clusterhead is
attached to a fixed network infrastructure (such as the Internet). attached to a fixed network infrastructure (such as the Internet).
Home (H) The Home (H) flag is set when the clusterhead is attached to Home (H): The Home (H) flag is set when the clusterhead is attached
its home network. to its home network.
Reserved 16-bit unsigned integer set to 0 by the clusterhead. Battery (B): The Battery (B) flag is indicates that a parent in the
tree operates on batteries, an indication of a costly operation.
It is set by a mobile router which operates on battery and when
set, it is left set as it is propagated down the tree.
TreePreference 8-bit unsigned integer set by the clusterhead to its Reserved: 13-bit unsigned integer set to 0 by the clusterhead.
TreePreference: 8-bit unsigned integer set by the clusterhead to its
preference and unchanged at propagation. Default is 0 (lowest preference and unchanged at propagation. Default is 0 (lowest
preference). preference).
Preference The administrative preference of that (mobile) Access BootTimeRandom: A random value computed at boot time and recomputed
Router. Default is 0. 255 is the highest possible preference. in case of a duplication with another Attachment Router. The
Set by each Mobile Router at propagation time.
BootTimeRandom A random value computed at boot time and recomputed in
case of a duplication with another Attachment Router. The
concatenation of the Preference and the BootTimeRandom is a 32-bit concatenation of the Preference and the BootTimeRandom is a 32-bit
extended preference that is used to resolve collisions. It is set extended preference that is used to resolve collisions. It is set
by each Mobile Router at propagation time. by each Mobile Router at propagation time.
TreeDepth 8-bit unsigned integer. The tree depth of the clusterhead Preference: The administrative preference of that (mobile) Access
Router. Default is 0. 255 is the highest possible preference.
Set by each Mobile Router at propagation time.
TreeDepth: 8-bit unsigned integer. The tree depth of the clusterhead
is 0 if it is a fixed router and 1 if it is a Mobile Router. The is 0 if it is a fixed router and 1 if it is a Mobile Router. The
tree Depth of a tree Node is the depth of its attachment router as tree Depth of a tree Node is the depth of its attachment router as
received in a TIO, incremented by one. All nodes in the tree received in a TIO, incremented by at least one. All nodes in the
advertise their tree depth in the Tree Information Options that tree advertise their tree depth in the Tree Information Options
they append to the RA messages over their ingress interfaces as that they append to the RA messages over their ingress interfaces
part of the propagation process. as part of the propagation process.
TreeDelay 16-bit unsigned integer set by the clusterhead indicating TreeDelay: 16-bit unsigned integer set by the clusterhead indicating
the delay before changing the tree configuration, in milliseconds. the delay before changing the tree configuration, in milliseconds.
A default value is 128ms. It is expected to be an order of A default value is 128ms. It is expected to be an order of
magnitude smaller than the RA-interval so if the clusterhead has a magnitude smaller than the RA-interval so if the clusterhead has a
sub-second RA-interval, the Tree delay may be shorter than 100ms. sub-second RA-interval, the Tree delay may be shorter than 100ms.
It is also expected to be an order of magnitude longer than the It is also expected to be an order of magnitude longer than the
typical propagation delay inside the nested Nemo. typical propagation delay inside the nested Nemo.
PathDigest 32-bit unsigned integer CRC, updated by each Mobile PathDigest: 32-bit unsigned integer CRC, updated by each Mobile
Router. This is the result of a CRC-32c computation on a bit Router. This is the result of a CRC-32c computation on a bit
string obtained by appending the received value and the Mobile string obtained by appending the received value and the Mobile
Router Care of Address. clusterheads use a 'previous value' of Router Care of Address. clusterheads use a 'previous value' of
zeroes to initially set the PathDigest. zeroes to initially set the PathDigest.
TreeID 128-bit unsigned integer which uniquely identify a tree. This TreeID: 128-bit unsigned integer which uniquely identify a tree.
value is set by the clusterhead. The global IPv6 home address of This value is set by the clusterhead. The global IPv6 home
the clusterhead can be used. address of the clusterhead can be used.
The following values MUST not change during the propagation of the The following values MUST not change during the propagation of the
TIO down the tree: Type, Length, G, H, TreePreference, TreeDelay and TIO down the tree: Type, Length, G, H, TreePreference, TreeDelay and
TreeID. All other fields of the TIO are updated at each hop of the TreeID. All other fields of the TIO are updated at each hop of the
propagation. propagation.
4.3 TIO suboption
In addition to the minimum options presented in the base option, a
number of suboptions are defined for the TIO:
4.3.1 Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subopt. Type | Subopt Length | Suboption Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: TIO suboption generic format
Suboption Type: 8-bit identifier of the type of mobility option.
When processing a TIO containing a suboption for which the
suboption Type value is not recognized by the receiver, the
receiver MUST silently ignore and skip over the suboption,
correctly handling any remaining options in the message.
Suboption Length: 8-bit unsigned integer, representing the length in
octets of the suboption, not including the suboption Type and
Length fields.
Suboption Data: A variable length field that contains data specific
to the option.
The following subsections specify the TIO suboptions which are
currently defined for use in the Mobility Header.
Implementations MUST silently ignore any TIO suboptions options that
they do not understand.
TIO suboptions may have alignment requirements. Following the
convention in IPv6, these options are aligned in a packet so that
multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed at
an integer multiple of n octets from the start of the header, for n =
1, 2, 4, or 8).
4.3.2 Pad1
The Pad1 suboption does not have any alignment requirements. Its
format is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
Figure 4: Pad 1
NOTE! the format of the Pad1 option is a special case - it has
neither Option Length nor Option Data fields.
The Pad1 option is used to insert one octet of padding in the TIO to
enable suboptions alignment. If more than one octet of padding is
required, the PadN option, described next, should be used rather than
multiple Pad1 options.
4.3.3 PadN
The PadN option does not have any alignment requirements. Its format
is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Type = 1 | Subopt Length | Subopt Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Figure 5: Pad N
The PadN option is used to insert two or more octets of padding in
the TIO to enable suboptions alignment. For N (N > 1) octets of
padding, the Option Length field contains the value N-2, and the
Option Data consists of N-2 zero-valued octets. PadN Option data
MUST be ignored by the receiver.
4.3.4 Bandwidth Suboption
This suboption carries the bandwidth available up the tree via a
specific parent. The value is expressed in the log base 2 of the
speed, expressed in bps. The Bandwidth suboption does not have any
alignment requirements. Its format is as follows:
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+
| Type = 2 | Length = 1 | Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+
Figure 6: Bandwidth Suboption
Type: Set to 2 for the Bandwidth suboption.
Length: Set to 1 for the Bandwidth suboption.
Bandwidth: 8-bit unsigned integer. The Log2 of the speed of the path
expressed in bps. The clusterhead initializes that field using
the speed of the link to the Access Router to which it is attached
or 0xFF if it is floating. An attached MR propagates it as the
minimum of the Bandwidth as received in the TIO from the parent
and the access speed between the MR and the parent. As a result,
the value received from a candidate AR is that of the bottleneck
between that AR and the wire access.
4.3.5 Stable time Suboption
This suboption carries an indicator of the stability of a network.
This indicator is the time since the branch to which the MR is
attached has remained unchanged. The value is expressed in the log
base 2 of that duration, expressed in milliseconds. The Stable time
suboption does not have any alignment requirements. Its format is as
follows:
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+
| Type = 3 | Length = 1 | Stable time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+
Figure 7: Stable time
Type: Set to 3 for the Stable time suboption.
Length: Set to 1 for the Stable time suboption.
Stable time: 8-bit unsigned integer. The Log2 of the time since the
last change in the attachment branch, expressed in milliseconds.
This is set by the MR as it propagates the TIO down the tree,
indicating for how long the PathDigest in the TIO from its parent
has remained unchanged.
4.3.6 Tree Group ID Suboption
This suboption carries the Group ID for the tree. It is set by the
clusterhead and is left unchanged by the MR that propagates the TIO
down the tree. The Tree Group ID Suboption has an alignment
requirement of 8n+6. Its format is as follows:
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 = 4 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Tree |
+ Group ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Tree Group ID Suboption
Type: 8-bit unsigned integer. Its value is 4 for the Tree Group ID
suboption.
Length: 8-bit unsigned integer. Its value is 16 for the Tree Group
ID suboption.
Tree Group ID: 128-bit unsigned integer which identify a group for a
tree. This value is set by the clusterhead. It can be set
administratively, for instance to an IPv6 multicast group.
5. Tree Discovery 5. Tree Discovery
Here follows a set of rules and definitions that MUST be followed by Here follows a set of rules and definitions that MUST be followed by
all Mobile Routers: all Mobile Routers:
1. An Mobile Router that is not attached to an Attachment Router is 1. A Mobile Router that is not attached to an Attachment Router is
the Nemo clusterhead of its own floating tree. It's depth is 1. the Nemo clusterhead of its own floating tree. It's depth is 1.
2. An Mobile Router that is attached to an Attachment Router that 2. A Mobile Router that is attached to an Attachment Router that
does not support TIO, is the clusterhead of its own grounded does not support TIO, is the clusterhead of its own grounded
tree. It's depth is 1. tree. It's depth is 1.
3. A router sending a RA without TIO is considered a grounded 3. A router sending a RA without TIO is considered a grounded
Attachment Router at depth 0. Attachment Router at depth 0.
4. The Nemo clusterhead of a tree exposes the tree in the Router 4. The Nemo clusterhead of a tree exposes the tree in the Router
Advertisement - Tree Information Option and Mobile Routers Advertisement Tree Information Option and Mobile Routers
propagate the TIO down the tree with the RAs that they forward propagate the TIO down the tree with the RAs that they forward
over their ingress links. over their ingress links.
5. An Mobile Router that is already part of a tree MAY move at any 5. A Mobile Router that is already part of a tree MAY move at any
time and with no delay in order to get closer to the clusterhead time and with no delay in order to get closer to the clusterhead
of its current tree - i.e. in order to reduce its own tree depth. of its current tree - i.e. in order to reduce its own tree depth.
But an Mobile Router MUST NOT move down the tree that it is But A Mobile Router MUST NOT move down the tree that it is
attached to. Mobile Routers MUST ignore RAs that are received attached to. Mobile Routers MUST ignore RAs that are received
from other routers located deeper or at the same depth within the from other routers located deeper or at the same depth within the
same tree. same tree.
6. An Mobile Router may move from its current tree into any 6. A Mobile Router may move from its current tree into any different
different tree at any time and whatever the depth its reaches in tree at any time and whatever the depth it reaches in the new
the new tree, but it may have to wait for a Tree Hop timer to tree, but it may have to wait for a Tree Hop timer to elapse in
elapse in order to do so. The Mobile Router will join that other order to do so. The Mobile Router will join that other tree if
tree if it is more preferable for reasons of connectivity, it is more preferable for reasons of connectivity, configured
configured preference, size, security, bandwidth, tree depth, or preference, size, security, bandwidth, tree depth, or whatever
whatever metrics the Mobile Router cares to use. metrics the Mobile Router cares to use.
7. If a Mobile Router has selected a new attachment router but has 7. If a Mobile Router has selected a new attachment router but has
not moved yet (because it is waiting for Tree Hop timer to not moved yet (because it is waiting for Tree Hop timer to
elapse), the Mobile Router is unstable and refrains from sending elapse), the Mobile Router is unstable and refrains from sending
Router Advertisement - Tree Information Options. Router Advertisement - Tree Information Options.
8. When an Mobile Router joins a tree, moves within its tree, or 8. When A Mobile Router joins a tree, moves within its tree, or when
when it receives a modified TIO from its current attachment it receives a modified TIO from its current attachment router,
router, the Mobile Router sends an unsolicited Router the Mobile Router sends an unsolicited Router Advertisement
Advertisement message on all its mobile networks (i.e. all its message on all its mobile networks (i.e. all its ingress
ingress interfaces). The RA contains a TIO that propagates the interfaces). The RA contains a TIO that propagates the new tree
new tree information. At the same time, the Mobile Router MAY information. At the same time, the Mobile Router MAY send a
send a Binding Update to its home agent or a local proxy of some Binding Update to its home agent or a local proxy of some sort,
sort, because the tree it is attached to has changed. If the because the tree it is attached to has changed. If the Mobile
Mobile Router fails to reach its Home Agent, it MAY attempt to Router fails to reach its Home Agent, it MAY attempt to roll back
roll back the movement or to retry the Home Agent discovery the movement or to retry the Home Agent discovery procedure.
procedure.
9. This allows the new higher parts of the tree to take place first 9. This allows the new higher parts of the tree to take place first
eventually dragging their sub-tree with them, and allowing eventually dragging their sub-tree with them, and allowing
stepped sub-tree reconfigurations, limiting relative movements. stepped sub-tree reconfigurations, limiting relative movements.
5.1 tree selection 5.1 tree selection
The tree selection is implementation and algorithm dependent. In The tree selection is implementation and algorithm dependent. In
order to limit erratic movements, and all metrics being equal, Mobile order to limit erratic movements, and all metrics being equal, Mobile
Routers SHOULD stick to their previous selection. Also, Mobile Routers SHOULD stick to their previous selection. Also, Mobile
skipping to change at page 11, line 29 skipping to change at page 16, line 36
List. DRL entries are extended to store the information received List. DRL entries are extended to store the information received
from the last TIO. These entries are managed by states and timers from the last TIO. These entries are managed by states and timers
described in the next section. described in the next section.
When connection to a fixed network is not possible or preferable for When connection to a fixed network is not possible or preferable for
security or other reasons, scattered trees should aggregate as much security or other reasons, scattered trees should aggregate as much
as possible into larger trees in order to allow inner connectivity. as possible into larger trees in order to allow inner connectivity.
How to balance these trees is implementation dependent, and MAY use a How to balance these trees is implementation dependent, and MAY use a
specific visitor-counter suboption in the TIO. specific visitor-counter suboption in the TIO.
A Mobile Router SHOULD verify that bidirectional connectivity is
available with a candidate Attachment Router before it attaches to
that candidate. Some layer 2 such as 802.11 infrastructure mode will
provide for this, while others such as 802.11 adhoc mode will not.
If the layer 2 does not guarantee the bidirectional connectivity,
then the MR needs to make sure that it can reach the AR. This can be
achieved using Neighbor Sollicitation and refraining from attaching
to an AR for which no neighbor cache exists, or the state is still
INCOMPLETE.
5.2 Sub-tree mobility 5.2 Sub-tree mobility
It might be perceived as beneficial for a sub-tree to move as a It might be perceived as beneficial for a sub-tree to move as a
whole. The way it would work is for a Mobile Router to stay root- whole. The way it would work is for a Mobile Router to stay
Mobile Router even if itself is attached into a parent tree. But the clusterhead even if itself is attached into a parent tree. But the
loop avoidance is based on the knowledge of the tree that the Mobile loop avoidance is based on the knowledge of the tree that the Mobile
Router visit, preventing a Mobile Router to move down a same tree. Router visit, preventing a Mobile Router to move down a same tree.
So without additional support, tree-level loops could form. So without additional support, tree-level loops could form.
To avoid this, it is possible to add a path vector suboption to the To avoid this, it is possible to add a path vector suboption to the
TIO that reflects the nesting of trees. If a root-Mobile Router TIO that reflects the nesting of trees. If a root-Mobile Router
joins a parent tree, then it needs to add its treeID to the path joins a parent tree, then it needs to add its treeID to the path
vector, but it can not join if the treeID is already listed. vector, but it can not join if the treeID is already listed.
A specific case is the root-Mobile Router of a tree that attaches to A specific case is the root-Mobile Router of a tree that attaches to
a fixed Access Router. That root-Mobile Router might omit to a fixed Access Router. That root-Mobile Router might omit to
consider a TIO that comes from the new Attachment Router and decide consider a TIO that comes from the new Attachment Router and decide
to stay root, in order to keep the tree consistency from the nested to stay root, in order to keep the tree consistency from the nested
Mobile Routers standpoint. This does not create loops, even if the Mobile Routers standpoint. This does not create loops, even if the
path vector is not present path vector is not present
5.3 DRL entries states and stability 5.3 Administrative depth
When the tree is formed under a common administration, or when a
Mobile Router performs a certain role within a community, it might be
beneficial to associate a range of acceptable depth with that MR.
For instance, a MR that has limited battery should be a leaf unless
there is no other choice, and thus expose an exagerated depth. On
the other hane, a MR that is designed for backhaul should operate in
a low range of depth.
With Tree Discovery, a MR has to expose a depth that is incremented
from its parent's depth as receive in the TIO. In particular, a MR
might expose a depth which is incremented by more than one from its
parent's depth, in order to fit in its own administrative range. So
a depth of N does not mean that there is precisely N Mobile Routers
on the way, but at most N.
5.4 DRL entries states and stability
Attachment routers in the DRL may or may not be usable for roaming Attachment routers in the DRL may or may not be usable for roaming
depending on runtime conditions. The following states are defined: depending on runtime conditions. The following states are defined:
Current This Attachment Router is used for roaming Current This Attachment Router is used for roaming
Candidate This Attachment Router can be used for roaming. Candidate This Attachment Router can be used for roaming.
Held-Up This Attachment Router can not be used till tree hop timer Held-Up This Attachment Router can not be used till tree hop timer
elapses. This does not occur for a fixed Attachment Router that elapses. This does not occur for a fixed Attachment Router that
does not send a TIO since the tree delay is null in that case. does not send a TIO since the tree delay is null in that case.
Held-Down This Attachment Router can not be used till hold down timer Held-Down This Attachment Router can not be used till hold down timer
elapses. At the end of the hold-down period, the router is elapses. At the end of the hold-down period, the router is
removed from the DRL, and will be reinserted if it appears again removed from the DRL, and will be reinserted if it appears again
with a RA. with a RA.
Collision This Attachment Router can not be used till its next RA. Collision This Attachment Router can not be used till its next RA.
5.3.1 Held-Up 5.4.1 Held-Up
This state is managed by the tree Hop timer, it serves 2 purposes: This state is managed by the tree Hop timer, it serves 2 purposes:
Delay the reattachment of a sub-tree that has been forced to Delay the reattachment of a sub-tree that has been forced to
detach. This allows to make sure that when a sub-tree has detach. This allows to make sure that when a sub-tree has
detached, the Router Advertisement - Tree Information Option that detached, the Router Advertisement - Tree Information Option that
is initiated by the new clusterhead has spread down the sub-tree is initiated by the new clusterhead has spread down the sub-tree
so that two different trees have formed. so that two different trees have formed.
Limit Router Advertisement - Tree Information Option storms when Limit Router Advertisement - Tree Information Option storms when
skipping to change at page 13, line 15 skipping to change at page 19, line 5
that elapses for a given new tree clears them all for that tree, that elapses for a given new tree clears them all for that tree,
allowing the Mobile Router to jump to the highest position available allowing the Mobile Router to jump to the highest position available
in the new tree. in the new tree.
The duration of the Tree Hop timer depends on the tree delay of the The duration of the Tree Hop timer depends on the tree delay of the
new tree and on the depth of Attachment Router that triggers it: new tree and on the depth of Attachment Router that triggers it:
(AR's depth + random) * AR's tree_delay (where 0 <= random < 1). It (AR's depth + random) * AR's tree_delay (where 0 <= random < 1). It
is randomized in order to limit collisions and synchronizations. is randomized in order to limit collisions and synchronizations.
5.3.2 Held-Down 5.4.2 Held-Down
When a router is 'removed' from the Default Router List, it is When a router is 'removed' from the Default Router List, it is
actually held down for a hold down timer period, in order to prevent actually held down for a hold down timer period, in order to prevent
flapping. This happens when an Attachment Router disappears (upon flapping. This happens when an Attachment Router disappears (upon
expiration timer), and when an Attachment Router is tried but can not expiration timer), and when an Attachment Router is tried but can not
reach the Home Agent (upon expiration of another Attachment Router, reach the Home Agent (upon expiration of another Attachment Router,
or upon tree hop for that Attachment Router). or upon tree hop for that Attachment Router).
An Attachment Router that is held down is not considered for the An Attachment Router that is held down is not considered for the
purpose of roaming. When the hold down timer elapses, the Attachment purpose of roaming. When the hold down timer elapses, the Attachment
Router is removed from the DRL. Router is removed from the DRL.
5.3.3 Collision 5.4.3 Collision
A race condition occurs if 2 Mobile Routers send Router Advertisement A race condition occurs if 2 Mobile Routers send Router Advertisement
- Tree Information Option at the same time and wish to join each - Tree Information Option at the same time and wish to join each
other. In order to detect the situation, Mobile Routers time stamp other. In order to detect the situation, Mobile Routers time stamp
the sending of Router Advertisement - Tree Information Option. Any the sending of Router Advertisement - Tree Information Option. Any
Router Advertisement - Tree Information Option received within a Router Advertisement - Tree Information Option received within a
short media-dependant period introduces a risk. To divide the risk, short media-dependant period introduces a risk. To divide the risk,
A 32bits extended preference is added in the TIO. The first byte is A 32bits extended preference is added in the TIO. The first byte is
the clusterhead preference, then the router own preference (default the clusterhead preference, then the router own preference (default
is 0 for both), the remaining 16 bits is a boot time computed is 0 for both), the remaining 16 bits is a boot time computed
skipping to change at page 14, line 17 skipping to change at page 20, line 6
There is risk of a collision when a Mobile Router receives an RA, for There is risk of a collision when a Mobile Router receives an RA, for
an other mobile router that is more preferable than the current an other mobile router that is more preferable than the current
Attachment Router, within the risk window. In the face of a Attachment Router, within the risk window. In the face of a
potential collision, the Mobile Router with the lowest extended potential collision, the Mobile Router with the lowest extended
preference processes the Router Advertisement - Tree Information preference processes the Router Advertisement - Tree Information
Option normally, while the router with the highest preference places Option normally, while the router with the highest preference places
the other in collision state, does not start the tree hop timer, and the other in collision state, does not start the tree hop timer, and
does not become instable. It is expected that next RAs between the does not become instable. It is expected that next RAs between the
two will not cross anyway. two will not cross anyway.
5.3.4 Instability 5.4.4 Instability
A Mobile Router is instable when it is prepared to move shortly to A Mobile Router is instable when it is prepared to move shortly to
another Attachment Router. This happens typically when the Mobile another Attachment Router. This happens typically when the Mobile
Router has selected a more preferred candidate Attachment Router and Router has selected a more preferred candidate Attachment Router and
has to wait for the tree hop timer to elapse before roaming. has to wait for the tree hop timer to elapse before roaming.
Instability may also occur when the current Attachment Router is lost Instability may also occur when the current Attachment Router is lost
and the next best is still held up. Instability is resolved when the and the next best is still held up. Instability is resolved when the
tree hop timer of all the Attachment Router (s) causing instability tree hop timer of all the Attachment Router (s) causing instability
elapse. Such Attachment Router is changes state to Current or Held- elapse. Such Attachment Router is changes state to Current or Held-
Down. Down.
Instability is transient (in the order of tree hop timers). When a Instability is transient (in the order of tree hop timers). When a
Mobile Router is unstable, it MUST NOT send RAs with TIO. This Mobile Router is unstable, it MUST NOT send RAs with TIO. This
avoids loops when Mobile Router A wishes to attach to Mobile Router B avoids loops when Mobile Router A wishes to attach to Mobile Router B
and Mobile Router B wishes to attach to Mobile Router A. Unless RA and Mobile Router B wishes to attach to Mobile Router A. Unless RA
cross (see Collision section), a Mobile Router receives TIO from cross (see Collision section), a Mobile Router receives TIO from
stable Attachment Routers, which do not plan to attach to itself, so stable Attachment Routers, which do not plan to attach to itself, so
the Mobile Router can safely attach to them. the Mobile Router can safely attach to them.
5.4 Legacy Routers 5.5 Legacy Routers
A legacy router sends its Router Advertisements without a TIO. A legacy router sends its Router Advertisements without a TIO.
Consequently, a legacy router can be mistaken for a fixed Access Consequently, a legacy router can be mistaken for a fixed Access
Router when it is placed within a nested NEMO structure, and defeat Router when it is placed within a nested NEMO structure, and defeat
the loop avoidance mechanism. Consequently, it is important for the the loop avoidance mechanism. Consequently, it is important for the
administrator to prevent address autoconfiguration by visiting Mobile administrator to prevent address autoconfiguration by visiting Mobile
Routers from such a legacy router. Routers from such a legacy router.
6. IANA Considerations 6. Directed Acyclic Graph Discovery
Tree Discovery builds trees, which are a specific form of a Directed
Acyclic Graph (DAG). In a more general Fashion, TD can be adapted to
form DAGs, oriented towards the clusterhead. This is DAG Discovery.
In Section 5.3, TD enables a given MR to expose a depth that is
incremented by more than one with regards to its parent. When it
does so, a MR can elect a number of alternate parents as feasible
successors. A feasible successor belongs to the same tree as the MR
parent, and has a depth that is less than that of the MR.
The links MR to feasible successors complete the tree as built by TD
into a DAG towards the clusterhead. The DAG enables alternate exit
paths for a multihomed Mobile Router.
7. IANA Considerations
Section 4.2. requires the definition of a new option to Neighbor Section 4.2. requires the definition of a new option to Neighbor
discovery [1] messages, the Router Advertisement - Tree Information discovery [1] messages, the Router Advertisement - Tree Information
Option (RA-TIO). The Router Advertisement - Tree Information Option Option (RA-TIO). The Router Advertisement - Tree Information Option
has been assigned the value TBD within the numbering space for IPv6 has been assigned the value TBD within the numbering space for IPv6
Neighbor Discovery Option Formats. Neighbor Discovery Option Formats.
7. Security Considerations 8. Security Considerations
At the current level of this draft, the TIO bears the security level At the current level of this draft, the TIO bears the security level
of the RA and the link. Nothing is added to it. A deeper threat of the RA and the link. Nothing is added to it. A deeper threat
analysis would be required to eventually propose additional security. analysis would be required to eventually propose additional security.
8. Changes 9. Changes
8.1 Changes from version 00 to 01 9.1 Changes from version 00 to 01
Added text on sub-tree mobility from the discussion with Marcelo. Added text on sub-tree mobility from the discussion with Marcelo.
Added text on nested legacy routers from the discussion with Added text on nested legacy routers from the discussion with
Marcelo. Marcelo.
8.2 Changes from version 01 to 02 9.2 Changes from version 01 to 02
Improved text on instability Improved text on instability
Changed the formula for the 4 bytes number used in collision Changed the formula for the 4 bytes number used in collision
avoidance avoidance
9. Acknowledgments 9.3 Changes from version 02 to 03
Added suboptions for tree group, stable time and bandwidth.
Added administrative depth and increment by more than 1.
Added words on bidirectional check using ND.
Added DAG discovery.
10. Acknowledgments
The authors wish to thank Marco Molteni and Patrick Wetterwald The authors wish to thank Marco Molteni and Patrick Wetterwald
(cisco) for their participation to this design and the review of the (cisco) for their participation to this design and the review of the
document, and Massimo Villari (university of Messina), for his early document, and Massimo Villari (university of Messina), for his early
work on simulation and research on the subject. This work is also work on simulation and research on the subject. This work is also
based on prior publications, in particular HMRA [8] by Hosik Cho and based on prior publications, in particular HMRA [8] by Hosik Cho and
Eun-Kyoung Paik from Seoul National University and other non IETF Eun-Kyoung Paik from Seoul National University and other non IETF
publications coauthored with Thierry Ernst and Thomas Noel. Finally, publications coauthored with Thierry Ernst and Thomas Noel. Finally,
thanks to Marcelo Bagnulo Braun for his constructive review. thanks to Marcelo Bagnulo Braun for his constructive review.
10. References 11. References
10.1 Normative Reference 11.1 Normative Reference
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address [2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[5] Ernst, T., "Network Mobility Support Goals and Requirements", [5] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-04 (work in progress), draft-ietf-nemo-requirements-05 (work in progress),
February 2005. October 2005.
[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-03 (work in progress), draft-ietf-nemo-terminology-05 (work in progress), March 2006.
February 2005.
[7] Draves, R. and D. Thaler, "Default Router Preferences and More- [7] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", draft-ietf-ipv6-router-selection-07 (work in Specific Routes", draft-ietf-ipv6-router-selection-07 (work in
progress), January 2005. progress), January 2005.
10.2 Informative Reference 11.2 Informative Reference
[8] Cho, H., "Hierarchical Mobile Router Advertisement for nested [8] Cho, H., "Hierarchical Mobile Router Advertisement for nested
mobile networks", draft-cho-nemo-hmra-00 (work in progress), mobile networks", draft-cho-nemo-hmra-00 (work in progress),
January 2004. January 2004.
[9] Ernst, T., "Analysis of Multihoming in Network Mobility [9] Ng, C., "Analysis of Multihoming in Network Mobility Support",
Support", draft-ietf-nemo-multihoming-issues-02 (work in draft-ietf-nemo-multihoming-issues-05 (work in progress),
progress), February 2005. February 2006.
Authors' Addresses Authors' Addresses
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue de Roumanille 400, Avenue de Roumanille
Batiment T3 Batiment T3
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
FRANCE FRANCE
skipping to change at page 19, line 41 skipping to change at page 25, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 65 change blocks. 
145 lines changed or deleted 385 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/