Internet Engineering Task Force P. Thubert Internet-Draft Cisco Intended status: Standards Track R. Wakikawa Expires: January 5, 2008 Keio University C. Bernardos UC3M R. Baldessari NEC Europe J. Lorchat Keio University July 4, 2007 Network In Node Advertisement draft-thubert-nina-01.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 January 5, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Thubert, et al. Expires January 5, 2008 [Page 1] Internet-Draft NINA July 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. Network In Node Advertisement (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 January 5, 2008 [Page 2] Internet-Draft NINA July 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. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 10 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. NINA message . . . . . . . . . . . . . . . . . . . . . . . 12 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 15 7.1. Multicast TD RA messages from parent . . . . . . . . . . . 17 7.2. Unicast NINA messages from child to parent . . . . . . . . 18 7.3. Other events . . . . . . . . . . . . . . . . . . . . . . . 18 7.4. Aggregation of prefixes on a same MR . . . . . . . . . . . 19 7.5. Aggregation of prefixes by a parent acting as mobile Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.6. Default value . . . . . . . . . . . . . . . . . . . . . . 20 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Thubert, et al. Expires January 5, 2008 [Page 3] Internet-Draft NINA July 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 [12], [15] 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 2461 [2] and RFC 4191 [7] 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 January 5, 2008 [Page 4] Internet-Draft NINA July 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 [11], the NEMO Terminology draft [20] and the MANEMO Problem Statement draft [19]. NINO (Network In Node Option): a new Neighbor Discovery (ND) option that adds the capability to include a prefix option in Neighbor Advertisements (NAs). 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 January 5, 2008 [Page 5] Internet-Draft NINA July 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 [19]. 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 January 5, 2008 [Page 6] Internet-Draft NINA July 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 [19], although MANET protocols [13], [16], [17] 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 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 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 Local Fixed 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 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 January 5, 2008 [Page 7] Internet-Draft NINA July 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 [18] 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 [18] 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 January 5, 2008 [Page 8] Internet-Draft NINA July 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 [18], 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 January 5, 2008 [Page 9] Internet-Draft NINA July 2007 5. Overview This section provides an overview of the operation of NINA to set-up MNP route state in a nested-NEMO scenario. 5.1. 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 1: 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 graph, thus providing loop avoidance for the NINA protocol. Each Thubert, et al. Expires January 5, 2008 [Page 10] Internet-Draft NINA July 2007 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 January 5, 2008 [Page 11] Internet-Draft NINA July 2007 6. Message Formats 6.1. NINA message NINA extends Neighbor Discovery [2] and RFC 4191 [7] to allow an MR 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 this new ND 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 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 o accepts unicast NINAs from any node BUT its AR 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 Thubert, et al. Expires January 5, 2008 [Page 12] Internet-Draft NINA July 2007 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 NINO Lifetime of 0. 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 | Reserved1 |L|4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NINO Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NINO Depth | Reserved3 | NINO Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix (Variable Length) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: NINO (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. Prefix Length: Number of valid leading bits in the IPv6 Prefix. Reserved1: 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Thubert, et al. Expires January 5, 2008 [Page 13] Internet-Draft NINA July 2007 '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 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. Reserved2: 32-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. NINO Depth: Set to 0 by the MR that owns the MNP and issues the NINO. Incremented by all MRs that propagate the NINO. Reserved3: 8-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 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. Prefix: Variable-length field containing an IPv6 address or a prefix of an IPv6 address. The Prefix Length 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 January 5, 2008 [Page 14] Internet-Draft NINA July 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 January 5, 2008 [Page 15] Internet-Draft NINA July 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 DestroyTimer. 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 January 5, 2008 [Page 16] Internet-Draft NINA July 2007 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 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. 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. 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. Thubert, et al. Expires January 5, 2008 [Page 17] Internet-Draft NINA July 2007 7.2. 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. 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 sends 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. 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.3. Other events Finally, NINA listens to a series of events, such as: Thubert, et al. Expires January 5, 2008 [Page 18] Internet-Draft NINA July 2007 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.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 Thubert, et al. Expires January 5, 2008 [Page 19] Internet-Draft NINA July 2007 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 MAX_DESTROY_INTERVAL = 200ms Thubert, et al. Expires January 5, 2008 [Page 20] Internet-Draft NINA July 2007 8. Privacy Considerations It is already possible for a visiting Mobile Node (Mobile Router) to autoconfigure an address that will not identify the visitor [8], [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. Thubert, et al. Expires January 5, 2008 [Page 21] Internet-Draft NINA July 2007 9. IANA Considerations This document requires IANA to assign a number for a new ND option type (NINO NA). Thubert, et al. Expires January 5, 2008 [Page 22] Internet-Draft NINA July 2007 10. Security Considerations Exposing the MRs' MNPs within the MFS introduces several security threats that should be carefully tackled, mainly derived from the fact that MRs are distributing prefixes (i.e., their MNPs) that are not topologically correct within the MFS. To avoid these security issues -- that might enable malicious nodes to steal traffic addressed to other nodes (by spoofing their 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. 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. Thubert, et al. Expires January 5, 2008 [Page 23] Internet-Draft NINA July 2007 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. Thubert, et al. Expires January 5, 2008 [Page 24] Internet-Draft NINA July 2007 12. References 12.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-05 (work in progress), April 2007. [7] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, November 2005. [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [10] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 12.2. Informative References [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 Considerations", RFC 2501, January 1999. [13] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, February 2007. Thubert, et al. Expires January 5, 2008 [Page 25] Internet-Draft NINA July 2007 [14] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [15] Chakeres, I., "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-03 (work in progress), June 2007. [16] Clausen, T., "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007. [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", draft-thubert-nemo-reverse-routing-header-07 (work in progress), February 2007. [19] Wakikawa, R., "MANEMO Problem Statement", draft-wakikawa-manemo-problem-statement-00 (work in progress), 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. Thubert, et al. Expires January 5, 2008 [Page 26] Internet-Draft NINA July 2007 [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. Thubert, et al. Expires January 5, 2008 [Page 27] Internet-Draft NINA July 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. Thubert, et al. Expires January 5, 2008 [Page 28] Internet-Draft NINA July 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 January 5, 2008 [Page 29] Internet-Draft NINA July 2007 Jean Lorchat Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN Email: lorchat@sfc.wide.ad.jp Thubert, et al. Expires January 5, 2008 [Page 30] Internet-Draft NINA July 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 January 5, 2008 [Page 31]