Internet Engineering Task Force P. Thubert Internet-Draft Cisco Intended status: Standards Track R. Wakikawa Expires: August 30, 2007 Keio University C. Bernardos UC3M R. Baldessari NEC Europe J. Lorchat Keio University February 26, 2007 Network In Node Advertisement draft-thubert-nina-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Thubert, et al. Expires August 30, 2007 [Page 1] Internet-Draft NINA February 2007 Abstract The Internet is evolving to become a more ubiquitous network, driven by the low prices of wireless routers and access points and by the users' requirements of connectivity anytime and anywhere. For that reason, a cloud of nodes connected by wireless technology is being created at the edge of the Internet. This cloud is called a MANEMO Fringe Stub (MFS). It is expected that networking in the MFS will be highly unmanaged and ad-hoc, but at the same time will need to offer excellent service availability. The NEMO Basic Support protocol could be used to provide global reachability for a mobile access network within the MFS and the Tree-Discovery mechanism could be used to avoid the formation of loops in this highly unmanaged structure. Since Internet connectivity in mobile scenarios can be costly, limited or unavailable, there is a need to enable local routing between the Mobile Routers within a portion of the MFS. This form of local routing is useful for Route Optimization (RO) between Mobile 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 Discovery, builds a loop-less structure -a tree-, and the second pass, NINA, exposes the Mobile Network Prefixes (MNPs) up the tree. The protocol operates as a multi-hop extension of Neighbor Discovery (ND), to populate TD-based trees with prefixes, and establish routes towards the MNPs down the tree, from the root-MR towards the MR that owns the prefix, whereas the default route is oriented towards the root-MR. The NINA protocol introduces a new option in the ND Neighbor Advertisement (NA), the Network In Node Option (NINO). An NA with NINO(s) is called a NINA (Network In Node Advertisement). NINA is designed for a hierarchical model where an embedded network is 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 embedded network and hides the inner topology and movements. Thubert, et al. Expires August 30, 2007 [Page 2] Internet-Draft NINA February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Rationale for the proposed solution . . . . . . . . . . . . . 7 4.1. Why ND based . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Why NA based . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Relationship with TD . . . . . . . . . . . . . . . . . . . 8 4.4. Relationship with NEMO . . . . . . . . . . . . . . . . . . 8 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Basic kiss (MR to MR over egress) . . . . . . . . . . . . 10 5.2. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 11 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. All MANEMO Mobile Routers multicast address . . . . . . . 13 6.2. NINO NA option . . . . . . . . . . . . . . . . . . . . . . 13 6.3. NINO NS option . . . . . . . . . . . . . . . . . . . . . . 17 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 19 7.1. NINA messages between siblings . . . . . . . . . . . . . . 21 7.2. Multicast TD RA messages from parent . . . . . . . . . . . 21 7.3. Unicast NINA messages from child to parent . . . . . . . . 22 7.4. Other events . . . . . . . . . . . . . . . . . . . . . . . 23 7.5. Default value . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Thubert, et al. Expires August 30, 2007 [Page 3] Internet-Draft NINA February 2007 1. Introduction Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility for IPv6, and NEMO [5] enables it for mobile prefixes. In any case, a mobile node is always identified by its Home Address (HoA), regardless of its current point of attachment to the Internet. In turn, MANET [11] allows a set of unrelated nodes and routers to discover their peers and establish communication. 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 are really MARs, Mobile Access Routers, because they can accept connections from other MRs on their ingress interfaces. When Mobile 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 described in Tree Discovery (TD) [6]. This draft provides a minimum extension to IPv6 Neighbor Discovery (ND) Neighbors Advertisements (NA) - called NINA (Network In Node Advertisement) - extending RFC 4191 [9] to add the capability to include a prefix option - called NINO (Network In Node Option) - in the NAs. This enables an MR to learn the prefixes of all other MRs down its sub-tree. Note that NINO is pronounced NEE-GNO and NINA is pronounced NEE-GNA. A NEMO Mobile Router has a double behavior. On its egress 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 (MN), performing the IPv6 and MIPv6 host-required features such as neighbor and router discovery [2]. On the (ingress) interfaces to the Mobile Networks, the Mobile Router behaves as an IPv6 router with support of the MIPv6 requirements on routers. This is why TD [6] extends ND RA over the ingress interface of a Mobile Router whereas NINA extends ND NAs to advertise over the egress interface the prefixes that are reachable via the MR. Thubert, et al. Expires August 30, 2007 [Page 4] Internet-Draft NINA February 2007 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 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 Statement draft [17]. NINO (Network In Node Option): a new Neighbor Discovery (ND) option that adds the capability to include a prefix option in Neighbor Advertisements (NAs) and Solicitations (NSs). NINA (Network In Node Advertisement): a Neighbor Discovery (ND) Neighbor Advertisement (NA) carrying a NINO. NINA is also used to refer to the protocol itself (defined in this document). Thubert, et al. Expires August 30, 2007 [Page 5] Internet-Draft NINA February 2007 3. Motivations The Internet is evolving to become a more ubiquitous network, driven by the low prices of wireless routers and access points and by the users' requirements of connectivity anytime and anywhere. For that reason, a cloud of nodes connected by wireless technology is being created at the edge of the Internet. This cloud is called a MANEMO Fringe Stub (MFS) in [17]. Examples of wireless technologies used within a MFS are wireless metropolitan and local area network protocols (WiMAX, WLAN, 802.20, etc), short distance wireless technology (bluetooth, IrDA, UWB), and radio mesh networks (e.g., 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 excellent service availability. The NEMO Basic Support protocol [5] could be used to provide global reachability for a mobile access network within the MFS. Analogously, the Tree-Discovery mechanism [6] could be used to avoid the formation of loops in this highly unmanaged structure. However, even with these two technologies in place, packet delivery within the MFS can still be highly inefficient. Since Internet connectivity in mobile scenarios can be costly, limited or unavailable, there is 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 is an example of Route Optimization (RO) between Mobile Routers that are communicating directly in a portion of the MFS. Thubert, et al. Expires August 30, 2007 [Page 6] Internet-Draft NINA February 2007 4. Rationale for the proposed solution 4.1. Why ND based NINA extends the Neighbor Discovery protocol to address the MANEMO requirements listed in [17], although MANET protocols [12], [14], [15] provides similar features such as local routing and Internet access over multihop. One of the drawbacks of MANET protocols is the question of which protocol should be used. AODV, DSR, DYMO, OLSR, etc. are standardized in IETF and each has distinct features, like proactive and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and fixed access routers are involved, and therefore, it is highly 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 IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if desired. 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 tree fashion. Flooding the entire network with route information is a redundant process and its overhead is not negligible. ND simply carries prefix information to setup the path from the tree root to each mobile router/node. 4.2. Why NA based Since MR appears as a host on the egress interface side, it is legitimate to use NA in the visited network. There are two reasons for that: 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 to the visited network and cause trouble. 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 (and moves as a single host). 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 single host footprint, and retain NEMO compatibility by avoiding spurious RAs. Thus, a whole subtree can move within the fringe as a single host. Thubert, et al. Expires August 30, 2007 [Page 7] Internet-Draft NINA February 2007 4.3. Relationship with TD NINA exploits the loop-less cluster established by Tree Discovery, so it does not need to provide loop avoidance. With TD, MRs setup a default route up the tree via the parent Access Router, and all the packets are directed by default towards the clusterhead (Top Level Mobile Router or root-MR in NEMO terms). To provide complete reachability, it is enough for NINA to expose the prefixes down the tree from any given MR, while propagating prefixes information up the tree. This allows an extreme conciseness of the routing information, with no topological knowledge past the first hop. That conciseness enables a high degree of movement within the nested structure; in particular, a movement within a subtree is not seen outside of that subtree, so most of the connectivity is maintained at all times while there might never be such a thing as a convergence. 4.4. Relationship with NEMO The Reverse Routing Header (RRH) described in [16] operates in the nested NEMO as a layer 3 Source Route Bridging (SRB) technique for nested NEMO Route Optimization. It allows a quick reaction to inner movements with the resolution of the packet; but the cost, an IPv6 address per packet per hop, might be deemed excessive. Also, the Home Agent needs to cache the RRH in its binding cache, and again, the overhead might be significant for a large deployment. On the other hand, NINA establishes states in the intermediate nodes, in a fashion similar to Transparent Bridging (TB), but at layer 3. The integration of these 2 approaches allows switching between SRB to TB models dynamically as the NINA states are populated or become obsolete. To obtain this capability, the operation of an intermediate MR described in [16] is altered in the following manner: 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 with its own Care-of Address, but does not save the previous source as a new entry in the RRH. 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, the first MR's Home Address, and its Care-of Address, regardless of the depth of the first MR in the nested NEMO. Thubert, et al. Expires August 30, 2007 [Page 8] Internet-Draft NINA February 2007 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 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 to ensure a correct routing on the way back. When NINA catches up, the entry will be saved again. The integration of NINA and RRH can offer the best of 2 worlds: a quick (per packet) resolution to the network changes, and the transparent (stateful) operation when the NINA routing protocol establishes the states in the nested NEMO. Thubert, et al. Expires August 30, 2007 [Page 9] Internet-Draft NINA February 2007 5. Overview 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 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 Thubert, et al. Expires August 30, 2007 [Page 10] Internet-Draft NINA February 2007 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 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 sub-tree of the topology, and that change triggers a flow of route updates for that sub-tree in the topology. +---------------------+ | Internet |---CN +---------------|-----+ / Access Router MR3_HA | ======?====== MR1 | ====?=============?==============?=== MR5 MR2 MR6 | | | =========== ===?========= ============= MR3 | ==|=========?== LFN1 MR4 | ========= Figure 2: Nested NEMO scenario Each tree that TD self-forms is considered a separate routing topology. If a Mobile Router belongs to multiple of such topologies, then it is expected that both the NINA signaling and the data packets are flagged to follow the topology for which the packet was introduced in the 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 that there is a single source for the advertisement of a given prefix within a topology. If multiple MRs share a given MNP, some protocol must take place between those MRs to make sure that one and only one MR advertises a given prefix in a given tree. Tree Discovery formats the nested NEMO into a loop-less logical Thubert, et al. Expires August 30, 2007 [Page 11] Internet-Draft NINA February 2007 graph, thus providing loop avoidance for the NINA protocol. Each time a movement occurs, TD restores the loop-less structure before NINA can operate again and repaint the graph with prefixes. The root-MR of a nested NEMO is selected for a number of properties, the primary one being an access to the wired infrastructure. It is the default sink for every node in the tree. More generally, the default gateway for a Mobile Router is its parent up in the tree; the more specific routes, towards the Mobile Network Prefixes, are always oriented down the tree, and NINA advertisements flow up the tree towards the root-MR. Each NINO contains a prefix and a sequence counter. The Mobile Router that owns the prefix generates the NINO for that prefix, including the sequence counter associated to that prefix and that is incremented each time it generates a new NINO. Due to a movement, a sub-tree can be temporarily out of sequence and a NINO can be received from a sub-tree where the MR was but is no more, until the parents realize it is gone. But by construction of the tree, there can be a single route to a given prefix, so older information is always invalid. 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 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 with the parent's own prefixes. Thubert, et al. Expires August 30, 2007 [Page 12] Internet-Draft NINA February 2007 6. Message Formats 6.1. All MANEMO Mobile Routers multicast address 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 specification extends RFC 4191 [9] and adds the capability to include a prefix option in the Neighbor Advertisements (NAs). The NA is a necessary exchange that allows the AR to map the IPv6 address of a node with its L2 address. The prefix option is normally present in 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 NINO (Network In Node Option) and we name the resulting message NINA (Network In Node Advertisement). 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 is always the best for unicast routes. In order to track that, the NINO includes a sequence counter to the prefix advertisement. 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, 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 is propagated up the tree. On an egress interface, if NINA is configured, the MR: o selects an Access Router (AR) as its point of attachment to the network Thubert, et al. Expires August 30, 2007 [Page 13] Internet-Draft NINA February 2007 o auto-configures a Care-of Address (CoA) o acts as a host as opposed to a router. In particular, it refrains from sending RAs o sends NINAs, as unicast, to its AR only, with the propagate ('P') 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 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: o acts as a router, may accept visitors o sends RAs with the Tree Information Option (RA-TIO) o accepts NINAs from any node 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 back, with the collection of all known prefixes (that is the prefixes 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 when the list of advertised prefixes has changed. NINA may advertise positive (prefix is present) or negative (removed) 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) or by receiving a no-NINO. A no-NINO is a NINO with a Route lifetime of 0. Thubert, et al. Expires August 30, 2007 [Page 14] Internet-Draft NINA February 2007 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 | IPv6 PL | IPv4 PL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NINO Depth |6|4|P|L| | NINO Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: NINO NA (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. IPv6 PL: Number of valid leading bits in the IPv6 Prefix. IPv4 PL: Number of valid leading bits in the IPv4 Prefix. Route Lifetime: 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 determination. A value of all one bits (0xFFFFFFFF) represents infinity. A value of all zero bits (0x00000000) indicates a loss of reachability. NINO Depth: Thubert, et al. Expires August 30, 2007 [Page 15] Internet-Draft NINA February 2007 Set to 0 by the MR that owns the MNP and issues the NINO. Incremented by all MRs that propagate the NINO. '6' bit: 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 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. NINO Sequence: 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 lollipop mechanism is used to wrap from 0xFFFF directly to 10. IPv4 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 IPv6 address. The IPv6 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. Thubert, et al. Expires August 30, 2007 [Page 16] Internet-Draft NINA February 2007 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: Thubert, et al. Expires August 30, 2007 [Page 17] Internet-Draft NINA February 2007 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). Thubert, et al. Expires August 30, 2007 [Page 18] Internet-Draft NINA February 2007 7. Mobile Router Operation The Mobile Router operation is autonomous, based on the information 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 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 global graph. So the adaptation to local movements must be rapid and localized. For NEMO flows, the Reverse Routing Header allows the update to the path on a per packet basis. Hopefully, the root of the tree (the clusterhead) is connected to the infrastructure where Home can be reached, and can be used as a gateway to discover Home. When the NEMO tunnel is established, it becomes the default route for the MR. If the tree is not connected to the infrastructure or in any case if Home can not be reached, MRs need an ad-hoc protocol to establish local connectivity. This specification takes advantage of the TD cluster and allows an MR to discover the prefixes below itself. NINA information can be redistributed in a routing protocol, MANET or IGP. But the MANET or the IGP SHOULD NOT be redistributed into NINA. This creates a hierarchy of routing protocols where NINA routes stand somewhere between connected and IGP routes. NINA also allows a compression of the Reverse Routing header when the routes match the topology as traced by RRH on a per packet basis. In particular, if a NINA route exists to the first entry in the RRH via the source of the packet, then the MR can override the source of the packet with its own CoA without adding the original source to the RRH. At that point, the RRH operation becomes loose, in other words an hybrid between transparent (stateful) and source routing. As a result: o Tree Discovery establishes a tree using extended Neighbor Discovery RS/RA flows. o The NEMO Basic Support protocol exploits the tree to get optimally out of a nested set of MRs and register Home. o RRH extends the NEMO Basic Support to provide Route Optimization and faster path reestablishment. o NINA also extends Neighbor Discovery in order to establish quickly the routes down the cluster. Thubert, et al. Expires August 30, 2007 [Page 19] Internet-Draft NINA February 2007 NINA maintains abstract lists of known prefixes. A prefix entry contains the following abstract information: o The state of the entry: ELAPSED, PENDING, or CONFIRMED. o A reference to the adjacency that was created for that prefix. o A reference to the ND entry that was created for the advertiser Neighbor. o The IPv6 address of the advertiser Neighbor. o The logical equivalent of the full NINA information. o A reference to the interface of the advertiser Neighbor. o A 'reported' Boolean to keep track whether this prefix was reported already to the parent AR. o A counter of retries to count how many RA-TIOs were sent on the interface to the neighbor without reachability confirmation for the prefix. NINA stores the prefix entries in either one of 3 abstract lists; the Connected, the Reachable and the Unreachable lists. The Connected list corresponds to the MNP of the Mobile Router. As long as an MR keeps receiving NINOs for a prefix timely, its prefix entry is listed in the Reachable list. 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, 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 is sent to the parent indicating the loss of the prefix. NINA requires 2 timers; the DelayNA timer and the Destroy Timer. 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 the Reachable list as well as all entries for Connected list are set to not reported yet. o The DelayNA timer has a duration that is DEF_NA_LATENCY divided by 2 with the tree depth. Thubert, et al. Expires August 30, 2007 [Page 20] Internet-Draft NINA February 2007 o The Destroy timer is armed when at least one entry has exhausted 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 NINO. When the destroy timer elapses, for all exhausted entries, the associated route is removed, and the entry is scheduled to be destroyed. o The Destroy timer has a duration of min (MAX_DESTROY_INTERVAL, RA_INTERVAL). 7.1. NINA messages between siblings 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 options for: o All the prefixes that are not 'DELETED' for all the ingress interfaces. o All the prefixes in the removed list as no-NINO. o All the prefixes in the advertised list that are not reported yet. The entries are set to reported. When ND receives a NA from a visitor over an ingress interface, NINOs are processed in a loop. For known prefixes, the sequence counter in the NINO is checked against the last received and the update is used only if the sequence is newer. This filters out obsolete advertisements when a prefix has moved between 2 subtrees attached to a same node. If a prefix is advertised as a no-NINO, the associated route is removed, and the entry is transferred to the removed list. Otherwise, the route table is looked up: o If a preferred route to that prefix from another protocol already exists, the prefix is ignored. Thubert, et al. Expires August 30, 2007 [Page 21] Internet-Draft NINA February 2007 o If a new route can be created, a new prefix entry is allocated to track it, as CONFIRMED, but not reported. o If a NINA route existed already via the same Neighbor, it is CONFIRMED. 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 NINO for the new entry. So the old entry is scheduled to be destroyed, whereas the new one is installed. 7.3. Unicast NINA messages from child to parent When sending NINA to its parent, an MR includes the NINOs about not already reported prefix entries in the Reachable and Connected lists, as well as no-NINOs for all the entries in the Unreachable list. The 'P' bit in the NINOs is set, indicating that the parent can propagate the NINOs up the tree. Depending on its policy, the receiving MR SHOULD install a route to the prefix in the NINO via the link local address of the source MR and it SHOULD propagate the information, 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. Its period is expected to range from 500ms to hours, depending on the stability of the configuration and the bandwidth available. 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 described in [6] the MR also issues a propagated RA-TIO over all its ingress interfaces, after a small jitter that aims at minimizing collisions of RA-TIO messages over the radio as it is propagated down the tree. The design choice behind this is NOT TO synchronize the parent and children databases, but instead to update them regularly to cover from the loss of packets. The rationale for that choice is movement. If the topology can be expected to change frequently, synchronization might be an excessive goal in terms of exchanges and protocol 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 on that interface: o If the entry is CONFIRMED, it goes PENDING with the retry count set to 0. Thubert, et al. Expires August 30, 2007 [Page 22] Internet-Draft NINA February 2007 o If the entry is PENDING, the retry count is incremented. If it reaches a maximum threshold, the entry goes ELAPSED If at least one entry is ELAPSED at the end of the process: if the Destroy timer is not running then it is armed with a jitter. Since the DelayNA has a duration that decreases with the depth, it is expected to receive all NINOs from all children before the timer elapses and the full update is sent to the parent. 7.4. Other events Finally, NINA listens to a series of events, such as: o MR stopped or unable to run: NINA routes are cleaned up. NINA is inactive. o NINA operation stopped: All entries in the abstract lists are freed. All the NINA routes are destroyed. o Interface going down: for all entries in the Reachable list on that interface, the associated route is removed, and the entry is scheduled to be destroyed. 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 scheduled to be destroyed. o Roaming: All entries in the Reachable list are set to not 'reported' and DelayNA is armed. 7.5. Default value DEF_NA_LATENCY = 150 ms MAX_DESTROY_INTERVAL = 200ms Thubert, et al. Expires August 30, 2007 [Page 23] Internet-Draft NINA February 2007 8. 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. Thubert, et al. Expires August 30, 2007 [Page 24] Internet-Draft NINA February 2007 9. IANA Considerations This document requires IANA to define a permanently-assigned multicast address: the MANEMO Mobile Routers Group (Section 6.1). Additionally, 2 new ND option types should be defined for NINO NA and NINO NS messages. Thubert, et al. Expires August 30, 2007 [Page 25] Internet-Draft NINA February 2007 10. Security Considerations The MANEMO Basic kiss (MR to MR over egress) scenario can be secured by SeND [13]. An MR can prove ownership of its prefix by the same certificate on egress as it could already on ingress. The nested NEMO scenario has the same security concerns that ND/RFC 4191 without SeND. In order to secure this scenario, L2 trusts and policies are required. Thubert, et al. Expires August 30, 2007 [Page 26] Internet-Draft NINA February 2007 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [6] Thubert, P., "Nested Nemo Tree Discovery", draft-thubert-tree-discovery-04 (work in progress), November 2006. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06 (work in progress), November 2006. [9] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, November 2005. [10] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 11.2. Informative References [11] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [12] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, February 2007. [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Thubert, et al. Expires August 30, 2007 [Page 27] Internet-Draft NINA February 2007 Neighbor Discovery (SEND)", RFC 3971, March 2005. [14] Clausen, T., "The Optimized Link-State Routing Protocol version 2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006. [15] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-01 (work in progress), February 2007. [16] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-07 (work in progress), February 2007. [17] Wakikawa, R., "MANEMO Problem Statement", draft-wakikawa-manemo-problem-statement-00 (work in progress), February 2007. Thubert, et al. Expires August 30, 2007 [Page 28] Internet-Draft NINA February 2007 Authors' Addresses Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN Email: ryuji@sfc.wide.ad.jp Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es Roberto Baldessari NEC Europe Network Laboratories Kurfuersten-anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342167 Email: roberto.baldessari@netlab.nec.de Thubert, et al. Expires August 30, 2007 [Page 29] Internet-Draft NINA February 2007 Jean Lorchat Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN Email: lorchat@sfc.wide.ad.jp Thubert, et al. Expires August 30, 2007 [Page 30] Internet-Draft NINA February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thubert, et al. Expires August 30, 2007 [Page 31]