< draft-thubert-nina-00.txt   draft-thubert-nina-01.txt >
Internet Engineering Task Force P. Thubert Internet Engineering Task Force P. Thubert
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track R. Wakikawa Intended status: Standards Track R. Wakikawa
Expires: August 30, 2007 Keio University Expires: January 5, 2008 Keio University
C. Bernardos C. Bernardos
UC3M UC3M
R. Baldessari R. Baldessari
NEC Europe NEC Europe
J. Lorchat J. Lorchat
Keio University Keio University
February 26, 2007 July 4, 2007
Network In Node Advertisement Network In Node Advertisement
draft-thubert-nina-00.txt draft-thubert-nina-01.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 41 skipping to change at page 1, line 41
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 August 30, 2007. This Internet-Draft will expire on January 5, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Internet is evolving to become a more ubiquitous network, driven The Internet is evolving to become a more ubiquitous network, driven
by the low prices of wireless routers and access points and by the by the low prices of wireless routers and access points and by the
users' requirements of connectivity anytime and anywhere. For that users' requirements of connectivity anytime and anywhere. For that
skipping to change at page 2, line 24 skipping to change at page 2, line 24
excellent service availability. The NEMO Basic Support protocol excellent service availability. The NEMO Basic Support protocol
could be used to provide global reachability for a mobile access could be used to provide global reachability for a mobile access
network within the MFS and the Tree-Discovery mechanism could be used network within the MFS and the Tree-Discovery mechanism could be used
to avoid the formation of loops in this highly unmanaged structure. to avoid the formation of loops in this highly unmanaged structure.
Since Internet connectivity in mobile scenarios can be costly, Since Internet connectivity in mobile scenarios can be costly,
limited or unavailable, there is a need to enable local routing limited or unavailable, there is a need to enable local routing
between the Mobile Routers within a portion of the MFS. This form of between the Mobile Routers within a portion of the MFS. This form of
local routing is useful for Route Optimization (RO) between Mobile local routing is useful for Route Optimization (RO) between Mobile
Routers that are communicating directly in a portion of the MFS. Routers that are communicating directly in a portion of the MFS.
NINA is the second of a 2-passes routing protocol; a first pass, Tree Network In Node Advertisement (NINA) is the second of a 2-passes
Discovery, builds a loop-less structure -a tree-, and the second routing protocol; a first pass, Tree Discovery, builds a loop-less
pass, NINA, exposes the Mobile Network Prefixes (MNPs) up the tree. structure -- a tree --, and the second pass, NINA, exposes the Mobile
The protocol operates as a multi-hop extension of Neighbor Discovery Network Prefixes (MNPs) up the tree. The protocol operates as a
(ND), to populate TD-based trees with prefixes, and establish routes multi-hop extension of Neighbor Discovery (ND), to populate TD-based
towards the MNPs down the tree, from the root-MR towards the MR that trees with prefixes, and establish routes towards the MNPs down the
owns the prefix, whereas the default route is oriented towards the tree, from the root-MR towards the MR that owns the prefix, whereas
root-MR. the default route is oriented towards the root-MR.
The NINA protocol introduces a new option in the ND Neighbor The NINA protocol introduces a new option in the ND Neighbor
Advertisement (NA), the Network In Node Option (NINO). An NA with Advertisement (NA), the Network In Node Option (NINO). An NA with
NINO(s) is called a NINA (Network In Node Advertisement). NINA is NINO(s) is called a NINA (Network In Node Advertisement). NINA is
designed for a hierarchical model where an embedded network is designed for a hierarchical model where an embedded network is
abstracted as a Host for the upper level of network abstraction. abstracted as a Host for the upper level of network abstraction.
With NINA, a Mobile Router presents its sub-tree to its parent as an With NINA, a Mobile Router presents its sub-tree to its parent as an
embedded network and hides the inner topology and movements. embedded network and hides the inner topology and movements.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Rationale for the proposed solution . . . . . . . . . . . . . 7 4. Rationale for the proposed solution . . . . . . . . . . . . . 7
4.1. Why ND based . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Why ND based . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Why NA based . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Why NA based . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Relationship with TD . . . . . . . . . . . . . . . . . . . 8 4.3. Relationship with TD . . . . . . . . . . . . . . . . . . . 8
4.4. Relationship with NEMO . . . . . . . . . . . . . . . . . . 8 4.4. Relationship with NEMO . . . . . . . . . . . . . . . . . . 8
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Basic kiss (MR to MR over egress) . . . . . . . . . . . . 10 5.1. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 11 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. NINA message . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. All MANEMO Mobile Routers multicast address . . . . . . . 13 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 15
6.2. NINO NA option . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Multicast TD RA messages from parent . . . . . . . . . . . 17
6.3. NINO NS option . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Unicast NINA messages from child to parent . . . . . . . . 18
7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 19 7.3. Other events . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. NINA messages between siblings . . . . . . . . . . . . . . 21 7.4. Aggregation of prefixes on a same MR . . . . . . . . . . . 19
7.2. Multicast TD RA messages from parent . . . . . . . . . . . 21 7.5. Aggregation of prefixes by a parent acting as mobile
7.3. Unicast NINA messages from child to parent . . . . . . . . 22 Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4. Other events . . . . . . . . . . . . . . . . . . . . . . . 23 7.6. Default value . . . . . . . . . . . . . . . . . . . . . . 20
7.5. Default value . . . . . . . . . . . . . . . . . . . . . . 23 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile
nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility
for IPv6, and NEMO [5] enables it for mobile prefixes. In any case, for IPv6, and NEMO [5] enables it for mobile prefixes. In any case,
a mobile node is always identified by its Home Address (HoA), a mobile node is always identified by its Home Address (HoA),
regardless of its current point of attachment to the Internet. In regardless of its current point of attachment to the Internet. In
turn, MANET [11] allows a set of unrelated nodes and routers to turn, MANET [12], [15] allows a set of unrelated nodes and routers to
discover their peers and establish communication. discover their peers and establish communication.
Mobile Routers (MRs) may attach to other MRs and form a Care-of Mobile Routers (MRs) may attach to other MRs and form a Care-of
Address (CoA) from a Mobile Network Prefix (MNP). As a result, MRs Address (CoA) from a Mobile Network Prefix (MNP). As a result, MRs
are really MARs, Mobile Access Routers, because they can accept are really MARs, Mobile Access Routers, because they can accept
connections from other MRs on their ingress interfaces. When Mobile connections from other MRs on their ingress interfaces. When Mobile
Routers attach to other Mobile Routers with a single Care-of Address Routers attach to other Mobile Routers with a single Care-of Address
in a loop-less manner, they end up building trees. This process is in a loop-less manner, they end up building trees. This process is
described in Tree Discovery (TD) [6]. described in Tree Discovery (TD) [6].
This draft provides a minimum extension to IPv6 Neighbor Discovery This draft provides a minimum extension to IPv6 Neighbor Discovery
(ND) Neighbors Advertisements (NA) - called NINA (Network In Node (ND) Neighbors Advertisements (NA) - called NINA (Network In Node
Advertisement) - extending RFC 4191 [9] to add the capability to Advertisement) - extending RFC 2461 [2] and RFC 4191 [7] to add the
include a prefix option - called NINO (Network In Node Option) - in capability to include a prefix option - called NINO (Network In Node
the NAs. This enables an MR to learn the prefixes of all other MRs Option) - in the NAs. This enables an MR to learn the prefixes of
down its sub-tree. Note that NINO is pronounced NEE-GNO and NINA is all other MRs down its sub-tree. Note that NINO is pronounced NEE-
pronounced NEE-GNA. GNO and NINA is pronounced NEE-GNA.
A NEMO Mobile Router has a double behavior. On its egress A NEMO Mobile Router has a double behavior. On its egress
interfaces, which are used to backhaul the traffic to the Home interfaces, which are used to backhaul the traffic to the Home
Network and the rest of the Internet, it is seen as a Mobile Node Network and the rest of the Internet, it is seen as a Mobile Node
(MN), performing the IPv6 and MIPv6 host-required features such as (MN), performing the IPv6 and MIPv6 host-required features such as
neighbor and router discovery [2]. On the (ingress) interfaces to neighbor and router discovery [2]. On the (ingress) interfaces to
the Mobile Networks, the Mobile Router behaves as an IPv6 router with the Mobile Networks, the Mobile Router behaves as an IPv6 router with
support of the MIPv6 requirements on routers. This is why TD [6] support of the MIPv6 requirements on routers. This is why TD [6]
extends ND RA over the ingress interface of a Mobile Router whereas extends ND RA over the ingress interface of a Mobile Router whereas
NINA extends ND NAs to advertise over the egress interface the NINA extends ND NAs to advertise over the egress interface the
prefixes that are reachable via the MR. prefixes that are reachable via the MR.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
Readers are expected to be familiar with all the terms defined in the Readers are expected to be familiar with all the terms defined in the
RFC 3753 [7], the NEMO Terminology draft [8] and the MANEMO Problem RFC 3753 [11], the NEMO Terminology draft [20] and the MANEMO Problem
Statement draft [17]. Statement draft [19].
NINO (Network In Node Option): a new Neighbor Discovery (ND) NINO (Network In Node Option): a new Neighbor Discovery (ND)
option that adds the capability to include a prefix option in option that adds the capability to include a prefix option in
Neighbor Advertisements (NAs) and Solicitations (NSs). Neighbor Advertisements (NAs).
NINA (Network In Node Advertisement): a Neighbor Discovery (ND) NINA (Network In Node Advertisement): a Neighbor Discovery (ND)
Neighbor Advertisement (NA) carrying a NINO. NINA is also used to Neighbor Advertisement (NA) carrying a NINO. NINA is also used to
refer to the protocol itself (defined in this document). refer to the protocol itself (defined in this document).
3. Motivations 3. Motivations
The Internet is evolving to become a more ubiquitous network, driven The Internet is evolving to become a more ubiquitous network, driven
by the low prices of wireless routers and access points and by the by the low prices of wireless routers and access points and by the
users' requirements of connectivity anytime and anywhere. For that users' requirements of connectivity anytime and anywhere. For that
reason, a cloud of nodes connected by wireless technology is being reason, a cloud of nodes connected by wireless technology is being
created at the edge of the Internet. This cloud is called a MANEMO created at the edge of the Internet. This cloud is called a MANEMO
Fringe Stub (MFS) in [17]. Examples of wireless technologies used Fringe Stub (MFS) in [19]. Examples of wireless technologies used
within a MFS are wireless metropolitan and local area network within a MFS are wireless metropolitan and local area network
protocols (WiMAX, WLAN, 802.20, etc), short distance wireless protocols (WiMAX, WLAN, 802.20, etc), short distance wireless
technology (bluetooth, IrDA, UWB), and radio mesh networks (e.g., technology (bluetooth, IrDA, UWB), and radio mesh networks (e.g.,
802.11s). It is expected that networking in the MFS will be highly 802.11s). It is expected that networking in the MFS will be highly
unmanaged and ad-hoc, but at the same time will need to offer unmanaged and ad-hoc, but at the same time will need to offer
excellent service availability. excellent service availability.
The NEMO Basic Support protocol [5] could be used to provide global The NEMO Basic Support protocol [5] could be used to provide global
reachability for a mobile access network within the MFS. reachability for a mobile access network within the MFS.
Analogously, the Tree-Discovery mechanism [6] could be used to avoid Analogously, the Tree-Discovery mechanism [6] could be used to avoid
skipping to change at page 7, line 10 skipping to change at page 7, line 10
need to enable local routing between the Mobile Routers within a need to enable local routing between the Mobile Routers within a
portion of the MFS. NINA can provide this form of local routing; it portion of the MFS. NINA can provide this form of local routing; it
is an example of Route Optimization (RO) between Mobile Routers that is an example of Route Optimization (RO) between Mobile Routers that
are communicating directly in a portion of the MFS. are communicating directly in a portion of the MFS.
4. Rationale for the proposed solution 4. Rationale for the proposed solution
4.1. Why ND based 4.1. Why ND based
NINA extends the Neighbor Discovery protocol to address the MANEMO NINA extends the Neighbor Discovery protocol to address the MANEMO
requirements listed in [17], although MANET protocols [12], [14], requirements listed in [19], although MANET protocols [13], [16],
[15] provides similar features such as local routing and Internet [17] provides similar features such as local routing and Internet
access over multihop. access over multihop.
One of the drawbacks of MANET protocols is the question of which One of the drawbacks of MANET protocols is the question of which
protocol should be used. AODV, DSR, DYMO, OLSR, etc. are protocol should be used. AODV, DSR, DYMO, OLSR, etc. are
standardized in IETF and each has distinct features, like proactive standardized in IETF and each has distinct features, like proactive
and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and
fixed access routers are involved, and therefore, it is highly fixed access routers are involved, and therefore, it is highly
important to deploy a consistent protocol in the network. On the important to deploy a consistent protocol in the network. On the
other hand, ND is a core component of IPv6 and is supported by all other hand, ND is a core component of IPv6 and is supported by all
IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if
skipping to change at page 7, line 33 skipping to change at page 7, line 33
MANEMO does not require full link states of a network as OLSR does, MANEMO does not require full link states of a network as OLSR does,
it only requires path to and from the exit router (tree root) in the it only requires path to and from the exit router (tree root) in the
tree fashion. Flooding the entire network with route information is tree fashion. Flooding the entire network with route information is
a redundant process and its overhead is not negligible. ND simply a redundant process and its overhead is not negligible. ND simply
carries prefix information to setup the path from the tree root to carries prefix information to setup the path from the tree root to
each mobile router/node. each mobile router/node.
4.2. Why NA based 4.2. Why NA based
Since MR appears as a host on the egress interface side, it is Since an MR appears as a host on the egress interface side, it is
legitimate to use NA in the visited network. There are two reasons legitimate to use NA in the visited network. There are two reasons
for that: for that:
o If an MR advertises itself as a router in the visited network o If an MR advertises itself as a router in the visited network
using RA, it might get used as a default router by LFNs attached using RA, it might get used as a default router by Local Fixed
to the visited network and cause trouble. Nodes (LFNs) attached to the visited network and cause trouble.
o By using NINA, the whole part of the fringe behind the MR has the o By using NINA, the whole part of the fringe behind the MR has the
footprint of a single host from the visited network standpoint footprint of a single host from the visited network standpoint
(and moves as a single host). (and moves as a single host).
By using NINA on top of a TD established tree, MANEMO can be made to By using NINA on top of a TD established tree, MANEMO can be made to
reproduce the NEMO behavior for a whole subtree by reducing to a reproduce the NEMO behavior for a whole subtree by reducing to a
single host footprint, and retain NEMO compatibility by avoiding single host footprint, and retain NEMO compatibility by avoiding
spurious RAs. Thus, a whole subtree can move within the fringe as a spurious RAs. Thus, a whole subtree can move within the fringe as a
single host. single host.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
This allows an extreme conciseness of the routing information, with This allows an extreme conciseness of the routing information, with
no topological knowledge past the first hop. That conciseness no topological knowledge past the first hop. That conciseness
enables a high degree of movement within the nested structure; in enables a high degree of movement within the nested structure; in
particular, a movement within a subtree is not seen outside of that particular, a movement within a subtree is not seen outside of that
subtree, so most of the connectivity is maintained at all times while subtree, so most of the connectivity is maintained at all times while
there might never be such a thing as a convergence. there might never be such a thing as a convergence.
4.4. Relationship with NEMO 4.4. Relationship with NEMO
The Reverse Routing Header (RRH) described in [16] operates in the The Reverse Routing Header (RRH) described in [18] operates in the
nested NEMO as a layer 3 Source Route Bridging (SRB) technique for nested NEMO as a layer 3 Source Route Bridging (SRB) technique for
nested NEMO Route Optimization. It allows a quick reaction to inner nested NEMO Route Optimization. It allows a quick reaction to inner
movements with the resolution of the packet; but the cost, an IPv6 movements with the resolution of the packet; but the cost, an IPv6
address per packet per hop, might be deemed excessive. address per packet per hop, might be deemed excessive.
Also, the Home Agent needs to cache the RRH in its binding cache, and Also, the Home Agent needs to cache the RRH in its binding cache, and
again, the overhead might be significant for a large deployment. again, the overhead might be significant for a large deployment.
On the other hand, NINA establishes states in the intermediate nodes, On the other hand, NINA establishes states in the intermediate nodes,
in a fashion similar to Transparent Bridging (TB), but at layer 3. in a fashion similar to Transparent Bridging (TB), but at layer 3.
The integration of these 2 approaches allows switching between SRB to The integration of these 2 approaches allows switching between SRB to
TB models dynamically as the NINA states are populated or become TB models dynamically as the NINA states are populated or become
obsolete. To obtain this capability, the operation of an obsolete. To obtain this capability, the operation of an
intermediate MR described in [16] is altered in the following manner: intermediate MR described in [18] is altered in the following manner:
o If the MR has a (NINA) route to the upper entry in the RRH via the o If the MR has a (NINA) route to the upper entry in the RRH via the
source of the packet, it still updates the source of the packet source of the packet, it still updates the source of the packet
with its own Care-of Address, but does not save the previous with its own Care-of Address, but does not save the previous
source as a new entry in the RRH. source as a new entry in the RRH.
o At best, if NINA has established states all along in a given o At best, if NINA has established states all along in a given
branch of the tree, the RRH for that branch has always 2 entries, branch of the tree, the RRH for that branch has always 2 entries,
the first MR's Home Address, and its Care-of Address, regardless the first MR's Home Address, and its Care-of Address, regardless
of the depth of the first MR in the nested NEMO. of the depth of the first MR in the nested NEMO.
o When some MRs in the tree support NINA and some do not, the o When some MRs in the tree support NINA and some do not, the
resulting RRH will be only partly compressed. Also, if the NINA resulting RRH will be only partly compressed. Also, if the NINA
route does not match the RRH, then the route is obsolete and the route does not match the RRH, then the route is obsolete and the
source address is added to the RRH as described in [16], in order source address is added to the RRH as described in [18], in order
to ensure a correct routing on the way back. When NINA catches to ensure a correct routing on the way back. When NINA catches
up, the entry will be saved again. up, the entry will be saved again.
The integration of NINA and RRH can offer the best of 2 worlds: a The integration of NINA and RRH can offer the best of 2 worlds: a
quick (per packet) resolution to the network changes, and the quick (per packet) resolution to the network changes, and the
transparent (stateful) operation when the NINA routing protocol transparent (stateful) operation when the NINA routing protocol
establishes the states in the nested NEMO. establishes the states in the nested NEMO.
5. Overview 5. Overview
This section provides an overview of the operation of NINA to set-up This section provides an overview of the operation of NINA to set-up
MNP route state in two different scenarios: a non-nested NEMO-to-NEMO MNP route state in a nested-NEMO scenario.
communication and a nested-NEMO one.
5.1. Basic kiss (MR to MR over egress)
A basic scenario where NINA can be used occurs when two or more MRs
are attached with their egress interfaces on the same link but do not
have connectivity to the infrastructure network (Figure 1). This
scenario includes, for example, the case of MRs equipped with short-
range communication technology (e.g. WLAN 802.11) that find
themselves in their communication range but are isolated from the
Internet. The NEMO Basic Support protocol [5] does not allow LFNs to
communicate, as it requires that the Home Agent is reachable and that
data packets go through it. By exchanging NINA messages, the MRs
expose their Mobile Network Prefixes to each other. Consequently,
MRs can add in their routing table a temporary route for MNPs exposed
by other MRs, which allows data packets to be exchanged between LFNs.
---+-------------------+-------------+------
| | |
+--+--+ +--+--+ +--+--+
| MR1 | | MR2 | | MR3 |
+---+-+ +-+---+ +--+--+
| | |
-+--+--- -+--+-- ---+--+--
| | |
+--+---+ +--+---+ +---+--+
| LFN1 | | LFN2 | | LFN3 |
+------+ +------+ +------+
Figure 1: Basic Kiss scenario
A new multicast group is created (all MANEMO Mobile Routers, see
Section 6.1). An MR that needs to know all MNPs on link will
multicast a NINA NS to that group with a link scope. Reversely, an
MR that wishes to advertise its MNPs to all its siblings on link will
multicast a NINA containing information about all the MNPs it manages
to that group with a link scope. A NINA sent to siblings can contain
information regarding its own MNPs and only its own MNPs (i.e. it
MUST NOT contain information about MNPs managed by others than the MR
sending the NINA). This information MUST NOT be propagated by the
siblings. For that purpose, the flag in the NINO ('P' bit, see
Section 6.2) MUST be set to 0.
MRs that want to advertise their MNPs to all of their siblings, in
addition to answering to NINA NS messages sent to the all MANEMO
Mobile Routers multicast address, SHOULD also send periodically
unsolicited NINAs to this link-scoped multicast group. This enables
information about sibling MNPs to expire (i.e. time out) when MRs
disappear from the network.
5.2. Nested NEMO 5.1. Nested NEMO
NINA requires the Tree Discovery protocol to build and maintain a NINA requires the Tree Discovery protocol to build and maintain a
tree topology. It relies on TD to discover that a change occurs in a tree topology. It relies on TD to discover that a change occurs in a
sub-tree of the topology, and that change triggers a flow of route sub-tree of the topology, and that change triggers a flow of route
updates for that sub-tree in the topology. updates for that sub-tree in the topology.
+---------------------+ +---------------------+
| Internet |---CN | Internet |---CN
+---------------|-----+ +---------------|-----+
/ Access Router / Access Router
skipping to change at page 11, line 36 skipping to change at page 10, line 36
MR5 MR2 MR6 MR5 MR2 MR6
| | | | | |
=========== ===?========= ============= =========== ===?========= =============
MR3 MR3
| |
==|=========?== ==|=========?==
LFN1 MR4 LFN1 MR4
| |
========= =========
Figure 2: Nested NEMO scenario Figure 1: Nested NEMO scenario
Each tree that TD self-forms is considered a separate routing Each tree that TD self-forms is considered a separate routing
topology. If a Mobile Router belongs to multiple of such topologies, topology. If a Mobile Router belongs to multiple of such topologies,
then it is expected that both the NINA signaling and the data packets then it is expected that both the NINA signaling and the data packets
are flagged to follow the topology for which the packet was are flagged to follow the topology for which the packet was
introduced in the network. introduced in the network.
NINA expects a Mobile Router to own one or more Mobile Network NINA expects a Mobile Router to own one or more Mobile Network
Prefix(es) that move with the MR. With that model, it is assumed Prefix(es) that move with the MR. With that model, it is assumed
that there is a single source for the advertisement of a given prefix that there is a single source for the advertisement of a given prefix
skipping to change at page 13, line 7 skipping to change at page 12, line 7
information is always invalid. information is always invalid.
A parent-MR maintains a state for each prefix it learns from NINA. A parent-MR maintains a state for each prefix it learns from NINA.
In particular, the last sequence number is kept. An out-of-sequence In particular, the last sequence number is kept. An out-of-sequence
NINO must be disregarded. If the NINO appears valid, it is forwarded NINO must be disregarded. If the NINO appears valid, it is forwarded
to the parent's parent in the next burst, carried by a NINA, together to the parent's parent in the next burst, carried by a NINA, together
with the parent's own prefixes. with the parent's own prefixes.
6. Message Formats 6. Message Formats
6.1. All MANEMO Mobile Routers multicast address 6.1. NINA message
RFC 4291 [10] defines the IPv6 Addressing Model and in particular
Multicast Addresses.
Multicast addresses have the following format:
| 8 | 4 | 4 | 112 bits |
+------ -+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
MANEMO requires a permanently-assigned multicast address: the MANEMO
Mobile Routers Group (IANA TBD 199?). As a result:
o FF02:0:0:0:0:0:0:(199?) means all MANEMO Mobile Routers on the
same link as the sender.
6.2. NINO NA option
NINO is a new option of ND Neighbors Advertisements. This NINA extends Neighbor Discovery [2] and RFC 4191 [7] to allow an MR
specification extends RFC 4191 [9] and adds the capability to include include a prefix option in the Neighbor Advertisements (NAs). The NA
a prefix option in the Neighbor Advertisements (NAs). The NA is a is a necessary exchange that allows the AR to map the IPv6 address of
necessary exchange that allows the AR to map the IPv6 address of a a node with its L2 address. The prefix option is normally present in
node with its L2 address. The prefix option is normally present in
Router Advertisements (RAs) only. The meaning of such an option in a Router Advertisements (RAs) only. The meaning of such an option in a
NA is the concept of 'network in node', so we refer to the option as NA is the concept of 'network in node', so we refer to this new ND
NINO (Network In Node Option) and we name the resulting message NINA option as NINO (Network In Node Option) and we name the resulting
(Network In Node Advertisement). message NINA (Network In Node Advertisement).
When Tree Discovery is used to build a tree, there can be a single When Tree Discovery is used to build a tree, there can be a single
route to a given prefix along that tree, so the freshest information route to a given prefix along that tree, so the freshest information
is always the best for unicast routes. In order to track that, the is always the best for unicast routes. In order to track that, the
NINO includes a sequence counter to the prefix advertisement. NINO includes a sequence counter to the prefix advertisement.
The sequence counter is incremented by the source of the NINO, that The sequence counter is incremented by the source of the NINO, that
is the Mobile Router that owns the MNP, each time it issues a NINA, is the Mobile Router that owns the MNP, each time it issues a NINA,
and then forwarded as is up the tree. A depth is also added for and then forwarded as is up the tree. A depth is also added for
tracking purposes; the depth is incremented at each hop as the NINO tracking purposes; the depth is incremented at each hop as the NINO
skipping to change at page 14, line 10 skipping to change at page 12, line 39
On an egress interface, if NINA is configured, the MR: On an egress interface, if NINA is configured, the MR:
o selects an Access Router (AR) as its point of attachment to the o selects an Access Router (AR) as its point of attachment to the
network network
o auto-configures a Care-of Address (CoA) o auto-configures a Care-of Address (CoA)
o acts as a host as opposed to a router. In particular, it refrains o acts as a host as opposed to a router. In particular, it refrains
from sending RAs from sending RAs
o sends NINAs, as unicast, to its AR only, with the propagate ('P') o sends NINAs, as unicast, to its AR only
bit set in the NINOs indicating that the NINO can be propagated up
the tree
o sends NINAs as solicited or unsolicited unicast or multicast to
siblings, with the propagate ('P') bit reset in the NINOs
indicating that the NINO cannot be propagated up the tree
o accepts unicast NINAs from any node BUT its AR o accepts unicast NINAs from any node BUT its AR
o optionally solicits multicast NINAs from all MANEMO MRs
o optionally accepts multicast NINAs (note, multicast NINAs
advertise only CONNECTED routes)
On an ingress interface, if NINA is configured, the MR: On an ingress interface, if NINA is configured, the MR:
o acts as a router, may accept visitors o acts as a router, may accept visitors
o sends RAs with the Tree Information Option (RA-TIO) o sends RAs with the Tree Information Option (RA-TIO)
o accepts NINAs from any node o accepts NINAs from any node
Every NA to the AR contains a NINO. In particular, receiving a Tree Every NA to the AR contains a NINO. In particular, receiving a Tree
Discovery RA-TIO from the AR stimulates the sending of a delayed NINA Discovery RA-TIO from the AR stimulates the sending of a delayed NINA
back, with the collection of all known prefixes (that is the prefixes back, with the collection of all known prefixes (that is the prefixes
learned from NINO and the connected prefixes). A NINA is also sent learned from NINO and the connected prefixes). A NINA is also sent
to the AR once it has been selected as new AR after a movement, or to the AR once it has been selected as new AR after a movement, or
when the list of advertised prefixes has changed. when the list of advertised prefixes has changed.
NINA may advertise positive (prefix is present) or negative (removed) NINA may advertise positive (prefix is present) or negative (removed)
NINOs. A no-NINO is stimulated by the disappearance of a prefix NINOs. A no-NINO is stimulated by the disappearance of a prefix
below. This is discovered by timing out after a request (a RA-TIO) below. This is discovered by timing out after a request (a RA-TIO)
or by receiving a no-NINO. A no-NINO is a NINO with a Route lifetime or by receiving a no-NINO. A no-NINO is a NINO with a NINO Lifetime
of 0. of 0.
0 1 2 3 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 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 | IPv6 PL | IPv4 PL | | Type | Length | Prefix Length | Reserved1 |L|4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime | | NINO Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NINO Depth |6|4|P|L| | NINO Sequence | | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix | | NINO Depth | Reserved3 | NINO Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ IPv6 Prefix + + Prefix (Variable Length) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
NINO NA (number to be assigned by IANA) NINO (number to be assigned by IANA).
Length: Length:
8-bit unsigned integer. The length of the option (including the 8-bit unsigned integer. The length of the option (including the
Type and Length fields) in units of 8 octets. Type and Length fields) in units of 8 octets.
IPv6 PL: Prefix Length:
Number of valid leading bits in the IPv6 Prefix. Number of valid leading bits in the IPv6 Prefix.
IPv4 PL: Reserved1:
Number of valid leading bits in the IPv4 Prefix. 6-bit unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
Route Lifetime: 'L' bit:
Indicates that the prefix or address is on-link as opposed to
another interface of the MR. This is useful for a child MR to
expose its IPv4 address on its egress interface. In that case,
the parent can set up forwarding to all the IPv4 prefixes in the
NINA via that address on this link.
'4' bit:
Indicates that the Prefix field carries an IPv4 mapped address.
NINO Lifetime:
32-bit unsigned integer. The length of time in seconds (relative 32-bit unsigned integer. The length of time in seconds (relative
to the time the packet is sent) that the prefix is valid for route to the time the packet is sent) that the prefix is valid for route
determination. A value of all one bits (0xFFFFFFFF) represents determination. A value of all one bits (0xFFFFFFFF) represents
infinity. A value of all zero bits (0x00000000) indicates a loss infinity. A value of all zero bits (0x00000000) indicates a loss
of reachability. of reachability.
Reserved2:
32-bit unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
NINO Depth: NINO Depth:
Set to 0 by the MR that owns the MNP and issues the NINO. Set to 0 by the MR that owns the MNP and issues the NINO.
Incremented by all MRs that propagate the NINO. Incremented by all MRs that propagate the NINO.
'6' bit: Reserved3:
Indicates that the IPv6 prefix is valid.
'4' bit:
Indicates that the IPv4 prefix is valid.
'P' bit:
Set only in a parent-child relationship, this flag indicates that
the NINO can be propagated up the tree.
'L' bit:
Indicates that the prefix or address is on-link as opposed to 8-bit unused field. It MUST be initialized to zero by the sender
another interface of the MR. This is useful for a child MR to and MUST be ignored by the receiver.
expose its IPv4 address on its egress interface. In that case,
the parent can set up forwarding to all the IPv4 prefixes in the
NINA via that address on this link.
NINO Sequence: NINO Sequence:
Incremented by the MR that owns the MNP for each new NINO for that Incremented by the MR that owns the MNP for each new NINO for that
prefix. Left unchanged by all MRs that propagate the NINO. A prefix. Left unchanged by all MRs that propagate the NINO. A
lollipop mechanism is used to wrap from 0xFFFF directly to 10. lollipop mechanism is used to wrap from 0xFFFF directly to 10.
IPv4 Prefix: Prefix:
4-byte field containing an IPv4 address or a prefix of an IP
address. The IPv4 PL field contains the number of valid leading
bits in the prefix. The bits in the prefix after the prefix
length (if any) are reserved and MUST be initialized to zero by
the sender and ignored by the receiver.
IPv6 Prefix:
Variable-length field containing an IPv6 address or a prefix of an Variable-length field containing an IPv6 address or a prefix of an
IPv6 address. The IPv6 PL field contains the number of valid IPv6 address. The Prefix Length field contains the number of
leading bits in the prefix. The bits in the prefix after the valid leading bits in the prefix. The bits in the prefix after
prefix length (if any) are reserved and MUST be initialized to the prefix length (if any) are reserved and MUST be initialized to
zero by the sender and ignored by the receiver. zero by the sender and ignored by the receiver.
6.3. NINO NS option
NINA messages MAY be solicited or unsolicited. In particular, for
privacy reasons, MRs may disable sending of unsolicited NINAs and
send only NINA to other nodes or MRs that requested it. This allows
the solicited MRs to decide whether or not to reveal its MNP.
Definition of policies for revealing MNP is out of scope of this
document.
As opposed to standard Neighbor Discovery [2], NINO Neighbor
Solicitations aim at resolving an MNP into an IPv6 address (MR link
local address) and not a known IPv6 address into a link-layer
address. Therefore, a NINA NS is sent to the All MANEMO MRs
multicast address and optionally contains the target MNP in a NINO NS
option.
An MR receiving a NINA NS compares its MNP with the one specified in
the NINO NS option. If the MNP matches the requested one and privacy
policies allow that, the MR sends a unicast NINA message to the
sender.
When there is no NINA NS option in the NS, the MR adds NINOs to its
NAs based on its policy. The NINA NS message MAY contain also a NINO
to inform other MRs about its MNP.
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 | Prefix Length | |4| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Requested IPv6 Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
NINO NS (number to be assigned by IANA).
Length:
8-bit unsigned integer. The length of the option (including the
Type and Length fields) in units of 8 octets. This is set to 1
for an IPv4 query and to 3 for an IPv6 query.
Prefix Length:
Number of valid leading bits in the IPv4/IPv6 Requested Prefix.
'4' bit:
If set to 1, it indicates that the target (requested) prefix is an
IPv4 prefix. If set to 0, it indicates that the target
(requested) prefix is an IPv6 prefix.
Requested IPv4 Prefix:
The IPv4 MNP that the sender wants to resolve into an IPv4
address.
Requested IPv6 Prefix:
The IPv6 MNP that the sender wants to resolve into an IPv6 address
(MR link local address).
7. Mobile Router Operation 7. Mobile Router Operation
The Mobile Router operation is autonomous, based on the information The Mobile Router operation is autonomous, based on the information
provided by the potential Access Routers in sight. Each MR selects provided by the potential Access Routers in sight. Each MR selects
an AR (a MAR) in a loop-less and case-optimized fashion, and installs an AR (a MAR) in a loop-less and case-optimized fashion, and installs
a default route up the tree via the selected AR. The resulting tree a default route up the tree via the selected AR. The resulting tree
(the cluster) may never be globally stable enough to be mapped in a (the cluster) may never be globally stable enough to be mapped in a
global graph. So the adaptation to local movements must be rapid and global graph. So the adaptation to local movements must be rapid and
localized. localized.
skipping to change at page 20, line 42 skipping to change at page 16, line 42
As long as an MR keeps receiving NINOs for a prefix timely, its As long as an MR keeps receiving NINOs for a prefix timely, its
prefix entry is listed in the Reachable list. prefix entry is listed in the Reachable list.
Once scheduled to be destroyed, a prefix entry is moved to the Once scheduled to be destroyed, a prefix entry is moved to the
Unreachable list if the MR has a parent to which it sends NINOs, Unreachable list if the MR has a parent to which it sends NINOs,
otherwise the entry is cleaned up right away. The entry is removed otherwise the entry is cleaned up right away. The entry is removed
from the Unreachable list when the parent changes or when a no-NINO from the Unreachable list when the parent changes or when a no-NINO
is sent to the parent indicating the loss of the prefix. is sent to the parent indicating the loss of the prefix.
NINA requires 2 timers; the DelayNA timer and the Destroy Timer. NINA requires 2 timers; the DelayNA timer and the DestroyTimer.
o The DelayNA timer is armed upon a stimulation to send a NINA (such o The DelayNA timer is armed upon a stimulation to send a NINA (such
as a TIO from the AR). When the timer is armed, all entries in as a TIO from the AR). When the timer is armed, all entries in
the Reachable list as well as all entries for Connected list are the Reachable list as well as all entries for Connected list are
set to not reported yet. set to not reported yet.
o The DelayNA timer has a duration that is DEF_NA_LATENCY divided by o The DelayNA timer has a duration that is DEF_NA_LATENCY divided by
2 with the tree depth. 2 with the tree depth.
o The Destroy timer is armed when at least one entry has exhausted o The DestroyTimer is armed when at least one entry has exhausted
its retries, which means that a number of RA-TIO were sent over its retries, which means that a number of RA-TIO were sent over
the ingress interface but that the entry was not confirmed with a the ingress interface but that the entry was not confirmed with a
NINO. When the destroy timer elapses, for all exhausted entries, NINO. When the destroy timer elapses, for all exhausted entries,
the associated route is removed, and the entry is scheduled to be the associated route is removed, and the entry is scheduled to be
destroyed. destroyed.
o The Destroy timer has a duration of min (MAX_DESTROY_INTERVAL, o The Destroy timer has a duration of min (MAX_DESTROY_INTERVAL,
RA_INTERVAL). RA_INTERVAL).
7.1. NINA messages between siblings 7.1. Multicast TD RA messages from parent
When sending NINA to siblings, an MR includes the NINOs corresponding
to the prefix entries in the Connected list, with the 'P' bit set to
0.
Depending on its policy, the receiving MR MAY install a route to the
prefix in the NINO via the link local address of the source MR but it
SHOULD NOT propagate the information, either as a NINO or by means of
redistribution into a routing protocol, since the 'P' bit is not set.
7.2. Multicast TD RA messages from parent
When ND sends a NA to the AR, NINA extends the message with prefix When ND sends a NA to the AR, NINA extends the message with prefix
options for: options for:
o All the prefixes that are not 'DELETED' for all the ingress o All the prefixes that are not 'DELETED' for all the ingress
interfaces. interfaces.
o All the prefixes in the removed list as no-NINO. o All the prefixes in the removed list as no-NINO.
o All the prefixes in the advertised list that are not reported yet. o All the prefixes in the advertised list that are not reported yet.
skipping to change at page 22, line 16 skipping to change at page 18, line 5
track it, as CONFIRMED, but not reported. track it, as CONFIRMED, but not reported.
o If a NINA route existed already via the same Neighbor, it is o If a NINA route existed already via the same Neighbor, it is
CONFIRMED. CONFIRMED.
o If a NINA route existed via a different Neighbor, this is o If a NINA route existed via a different Neighbor, this is
equivalent to a no-NINO for the previous entry followed by a new equivalent to a no-NINO for the previous entry followed by a new
NINO for the new entry. So the old entry is scheduled to be NINO for the new entry. So the old entry is scheduled to be
destroyed, whereas the new one is installed. destroyed, whereas the new one is installed.
7.3. Unicast NINA messages from child to parent 7.2. Unicast NINA messages from child to parent
When sending NINA to its parent, an MR includes the NINOs about not When sending NINA to its parent, an MR includes the NINOs about not
already reported prefix entries in the Reachable and Connected lists, already reported prefix entries in the Reachable and Connected lists,
as well as no-NINOs for all the entries in the Unreachable list. The as well as no-NINOs for all the entries in the Unreachable list.
'P' bit in the NINOs is set, indicating that the parent can propagate Depending on its policy, the receiving MR SHOULD install a route to
the NINOs up the tree. Depending on its policy, the receiving MR the prefix in the NINO via the link local address of the source MR
SHOULD install a route to the prefix in the NINO via the link local and it SHOULD propagate the information, either as a NINO or by means
address of the source MR and it SHOULD propagate the information, of redistribution into a routing protocol.
either as a NINO or by means of redistribution into a routing
protocol.
The RA-TIO from the root-MR is used to synchronize the whole tree. The RA-TIO from the root-MR is used to synchronize the whole tree.
Its period is expected to range from 500ms to hours, depending on the Its period is expected to range from 500ms to hours, depending on the
stability of the configuration and the bandwidth available. stability of the configuration and the bandwidth available.
When an MR receives a RA-TIO over an egress interface from the When an MR receives a RA-TIO over an egress interface from the
current parent AR, the DelayNA is armed to force a full update. As current parent AR, the DelayNA is armed to force a full update. As
described in [6] the MR also issues a propagated RA-TIO over all its described in [6] the MR also issues a propagated RA-TIO over all its
ingress interfaces, after a small jitter that aims at minimizing ingress interfaces, after a small jitter that aims at minimizing
collisions of RA-TIO messages over the radio as it is propagated down collisions of RA-TIO messages over the radio as it is propagated down
the tree. the tree.
The design choice behind this is NOT TO synchronize the parent and The design choice behind this is NOT TO synchronize the parent and
children databases, but instead to update them regularly to cover children databases, but instead to update them regularly to cover
from the loss of packets. The rationale for that choice is movement. from the loss of packets. The rationale for that choice is movement.
If the topology can be expected to change frequently, synchronization If the topology can be expected to change frequently, synchronization
might be an excessive goal in terms of exchanges and protocol might be an excessive goal in terms of exchanges and protocol
complexity. This results in a simple protocol with no real peering. complexity. This results in a simple protocol with no real peering.
When the MR send a RA-TIO over an ingress interface, for all entries When the MR sends a RA-TIO over an ingress interface, for all entries
on that interface: on that interface:
o If the entry is CONFIRMED, it goes PENDING with the retry count o If the entry is CONFIRMED, it goes PENDING with the retry count
set to 0. set to 0.
o If the entry is PENDING, the retry count is incremented. If it o If the entry is PENDING, the retry count is incremented. If it
reaches a maximum threshold, the entry goes ELAPSED If at least reaches a maximum threshold, the entry goes ELAPSED If at least
one entry is ELAPSED at the end of the process: if the Destroy one entry is ELAPSED at the end of the process: if the Destroy
timer is not running then it is armed with a jitter. timer is not running then it is armed with a jitter.
Since the DelayNA has a duration that decreases with the depth, it is Since the DelayNA has a duration that decreases with the depth, it is
expected to receive all NINOs from all children before the timer expected to receive all NINOs from all children before the timer
elapses and the full update is sent to the parent. elapses and the full update is sent to the parent.
7.4. Other events 7.3. Other events
Finally, NINA listens to a series of events, such as: Finally, NINA listens to a series of events, such as:
o MR stopped or unable to run: NINA routes are cleaned up. NINA is o MR stopped or unable to run: NINA routes are cleaned up. NINA is
inactive. inactive.
o NINA operation stopped: All entries in the abstract lists are o NINA operation stopped: All entries in the abstract lists are
freed. All the NINA routes are destroyed. freed. All the NINA routes are destroyed.
o Interface going down: for all entries in the Reachable list on o Interface going down: for all entries in the Reachable list on
that interface, the associated route is removed, and the entry is that interface, the associated route is removed, and the entry is
scheduled to be destroyed. scheduled to be destroyed.
o Neighbor being removed from the ND list: if the entry is in the o Neighbor being removed from the ND list: if the entry is in the
Reachable list the associated route is removed, and the entry is Reachable list the associated route is removed, and the entry is
scheduled to be destroyed. scheduled to be destroyed.
o Roaming: All entries in the Reachable list are set to not o Roaming: All entries in the Reachable list are set to not
'reported' and DelayNA is armed. 'reported' and DelayNA is armed.
7.5. Default value 7.4. Aggregation of prefixes on a same MR
When deploying an MR with multiple ingress interfaces, it makes sense
to affect an aggregation prefix (shorter than /64) to the MR and
partition it as /64 prefixes over the MR interfaces. An MR that owns
a contiguous set of prefixes should only report the aggregation of
these prefixes through NINA.
7.5. Aggregation of prefixes by a parent acting as mobile Home
There are also a number of cases where a mobile aggregation is shared
within a toon of Mobile Routers. For instance, a toon formed by
firefighters and their commander. In that case, it is still possible
to use aggregation techniques with NINA and improve its scalability.
In that case, the commander is configured as the NINA aggregator for
the group prefix. In run time, it absorbs the individual NINO
information it receives from the toon members down its subtree and
only reports the aggregation up the TD tree. This works fine when
the whole toon is attached within the commander's subtree.
But other cases might occur for which additional support is required:
1. the commander is attached within the subtree of one of its toon
members.
2. A toon member is somewhere else within the TD tree.
3. A toon member is somewhere else in the Internet.
In all those cases, a node situated above the commander in the TD
tree but not above the toon member will see the advertisements for
the aggregation owned by the commander but not that of the individual
toon member prefix. So it will route all the packets for the toon
member towards the commander, but the commander will have no route to
the toon and will fail to forward.
Section 8 'Mobile Home' of RFC 4887 [21] proposes a deployment model
where a Mobile Router would also act as Home Agent for a mobile
aggregation. This method can be used in the general case 3 to ensure
routability to the toon member. With that method, the Home Link for
a toon member should be one of the commander links. The Tree
Discovery plug-in should favor that link so that many toon members
actually attach at Home.
If a toon member is not at Home, then it will register to its Home
Agent using NEMO basic support (RFC 3963 [5]). Depending of the
location of a source, a packet to the toon member will either go
directly to it, or go to its commander. If the toon member as a
Mobile Router is registered to its commander as its Home Agent, the
commander can always encapsulate the packet to the CoA of the toon
member using NEMO, and ensure reachability to the MR.
Section 2.7 of RFC 4888 [22] explains that in the specific case of
case 1), the commander will not be able to reach Home using plain
NEMO basic support, and an additional mechanism such as RRH ([18]) is
required to fix that issue.
Also specifically in case 1), the toon member will refrain from
adding the NINO options for its own prefixes that are aggregated in
the NINO option of its commander that it propagates up the TD tree.
7.6. Default value
DEF_NA_LATENCY = 150 ms DEF_NA_LATENCY = 150 ms
MAX_DESTROY_INTERVAL = 200ms MAX_DESTROY_INTERVAL = 200ms
8. Acknowledgments 8. Privacy Considerations
We would like to thank all the people who have provided comments on It is already possible for a visiting Mobile Node (Mobile Router) to
this draft, specially to Ben McCarthy for his very helpful review of autoconfigure an address that will not identify the visitor [8],
this document. [23], [14]. It is also possible for a visitor to roll its CoA
periodically even when it stays attached to a same point, and
register the new addresses as it forms them.
CIA (Capability, Innocuousness and Anonymity) properties demand also
that the visited party might not be identified by the visitor. To
achieve that, a Mobile Router should not advertise its MNPs on its
links open to untrusted visitors.
This draft recommends that the interface that is open for untrusted
visitors uses unique local addresses (RFC 4193 [9]) and rolls the
advertised prefixes with a short lifetime. This can be achieved for
instance by obtaining short lived leases from the Home Agent using
DHCP-PD [24].
Another possibility is to use strict RRH routing [18]; in that case,
the prefix that is presented on the link can be taken from anywhere
in the ULA range since it is not used for routing outside the link.
Alternatively, a global unique prefix obtained from an autoconf
solution [25], [26] or DHCPv6 prefix delegation [10] can be used as
well.
9. IANA Considerations 9. IANA Considerations
This document requires IANA to define a permanently-assigned This document requires IANA to assign a number for a new ND option
multicast address: the MANEMO Mobile Routers Group (Section 6.1). type (NINO NA).
Additionally, 2 new ND option types should be defined for NINO NA and
NINO NS messages.
10. Security Considerations 10. Security Considerations
The MANEMO Basic kiss (MR to MR over egress) scenario can be secured Exposing the MRs' MNPs within the MFS introduces several security
by SeND [13]. An MR can prove ownership of its prefix by the same threats that should be carefully tackled, mainly derived from the
certificate on egress as it could already on ingress. fact that MRs are distributing prefixes (i.e., their MNPs) that are
not topologically correct within the MFS.
The nested NEMO scenario has the same security concerns that ND/RFC To avoid these security issues -- that might enable malicious nodes
4191 without SeND. In order to secure this scenario, L2 trusts and to steal traffic addressed to other nodes (by spoofing their
policies are required. prefixes) -- Mobile Routers should be provided with some security
mechanisms, ensuring that an MR that is advertising a certain MNP is
actually authorised to do that.
11. References The use of L2 trusts and policies, SeND or preconfigured security
relationships might help in securing the mechanism described in this
draft. Additionally, if MRs have connectivity with their Home
Agents, a modified Return Routability mechanism -- extended to
support prefix checks (such as [27] or [28]) -- may be used to
provide the required authorisation, before starting to use the RO
shortcut within the MFS.
11.1. Normative References 11. Acknowledgments
We would like to thank all the people who have provided comments on
this draft, specially to Ben McCarthy for his very helpful review of
this document.
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [2] 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.
[3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [5] 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.
[6] Thubert, P., "Nested Nemo Tree Discovery", [6] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-04 (work in progress), draft-thubert-tree-discovery-05 (work in progress), April 2007.
November 2006.
[7] Manner, J. and M. Kojo, "Mobility Related Terminology", [7] Draves, R. and D. Thaler, "Default Router Preferences and More-
RFC 3753, June 2004. Specific Routes", RFC 4191, November 2005.
[8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless
draft-ietf-nemo-terminology-06 (work in progress), Address Autoconfiguration in IPv6", RFC 3041, January 2001.
November 2006.
[9] Draves, R. and D. Thaler, "Default Router Preferences and More- [9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Specific Routes", RFC 4191, November 2005. Addresses", RFC 4193, October 2005.
[10] Hinden, R. and S. Deering, "IP Version 6 Addressing [10] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Architecture", RFC 4291, February 2006. Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
11.2. Informative References 12.2. Informative References
[11] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): [11] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[12] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET):
Routing Protocol Performance Issues and Evaluation Routing Protocol Performance Issues and Evaluation
Considerations", RFC 2501, January 1999. Considerations", RFC 2501, January 1999.
[12] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing [13] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing
Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728,
February 2007. February 2007.
[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [14] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[14] Clausen, T., "The Optimized Link-State Routing Protocol version [15] Chakeres, I., "Mobile Ad hoc Network Architecture",
2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006. draft-ietf-autoconf-manetarch-03 (work in progress), June 2007.
[15] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", [16] Clausen, T., "The Optimized Link State Routing Protocol version
draft-ietf-manet-nhdp-01 (work in progress), February 2007. 2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007.
[16] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and [17] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-04 (work in progress), June 2007.
[18] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks", its application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-07 (work in draft-thubert-nemo-reverse-routing-header-07 (work in
progress), February 2007. progress), February 2007.
[17] Wakikawa, R., "MANEMO Problem Statement", [19] Wakikawa, R., "MANEMO Problem Statement",
draft-wakikawa-manemo-problem-statement-00 (work in progress), draft-wakikawa-manemo-problem-statement-00 (work in progress),
February 2007. February 2007.
[20] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-06 (work in progress),
November 2006.
[21] Thubert, P., "NEMO Home Network models",
draft-ietf-nemo-home-network-models-06 (work in progress),
February 2006.
[22] Ng, C., "Network Mobility Route Optimization Problem
Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
progress), September 2006.
[23] Narten, T., "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", draft-ietf-ipv6-privacy-addrs-v2-05
(work in progress), October 2006.
[24] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.
[25] Baccelli, E., "Address Autoconfiguration for MANET: Terminology
and Problem Statement", draft-ietf-autoconf-statement-00 (work
in progress), June 2007.
[26] Bernardos, C. and M. Calderon, "Survey of IP address
autoconfiguration mechanisms for MANETs",
draft-bernardos-manet-autoconf-survey-00 (work in progress),
July 2005.
[27] Ng, C., "Extending Return Routability Procedure for Network
Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress),
October 2004.
[28] Bernardos, C., Soto, I., Maria, M., Fernando, F., and A.
Arturo, "VARON: Vehicular Ad hoc Route Optimisation for NEMO",
Computer Communications, vol. 30, pp. 1765-1784 , 2007.
Appendix A. Change Log
Changes from -00 to -01:
o Basic kiss (MR to MR over egress) sections removed.
o Added sections about aggregation of prefixes.
o Added Privacy consideration section.
o NINO NA message format changed.
o Some text cleanups.
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
 End of changes. 71 change blocks. 
314 lines changed or deleted 298 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/