Internet Engineering Task Force P. Thubert Internet-Draft Cisco Intended status: Standards Track C. Bernardos, Ed. Expires: March 16, 2009 UC3M September 12, 2008 Network In Node Advertisement draft-thubert-nina-03.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 March 16, 2009. 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. We refer to this cloud as a Fringe Stub (FS). It is expected that networking in the FS 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 FS and the Tree-Discovery mechanism could be used to avoid the formation of loops in this highly unmanaged structure. Thubert & Bernardos Expires March 16, 2009 [Page 1] Internet-Draft NINA September 2008 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 FS. This form of local routing is useful for Route Optimization (RO) between Mobile Routers that are communicating directly in a portion of the FS. 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, and by using this NA based approach it abstracts the embedded network of a Mobile Router as a host to 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 & Bernardos Expires March 16, 2009 [Page 2] Internet-Draft NINA September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Rationale for the proposed solution . . . . . . . . . . . . . 5 4.1. Why ND based . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Why NA based . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Relationship with TD . . . . . . . . . . . . . . . . . . . 6 4.4. Relationship with RRH . . . . . . . . . . . . . . . . . . 7 5. NINA Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. NINA message . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. NINO IPv4 option . . . . . . . . . . . . . . . . . . . . . 12 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 13 7.1. Multicast TD RA messages from parent . . . . . . . . . . . 15 7.2. Unicast NINA messages from child to parent . . . . . . . . 15 7.3. Other events . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. Aggregation of prefixes on a same MR . . . . . . . . . . . 17 7.5. Aggregation of prefixes by a parent acting as mobile Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.6. Default value . . . . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Thubert & Bernardos Expires March 16, 2009 [Page 3] Internet-Draft NINA September 2008 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], [14] 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 supported 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 4861 [2] and RFC 4191 [7] to add the capability to include a prefix option - called NINO (Network In Node Option) - in the NAs of the MR. 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. 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 [10], the NEMO Terminology draft [19] and the MANEMO Problem Statement draft [18]. Thubert & Bernardos Expires March 16, 2009 [Page 4] Internet-Draft NINA September 2008 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). 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. We refer to this cloud as a Fringe Stub (FS). Examples of wireless technologies used within a FS 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 FS 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 FS. 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 FS 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 FS. 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 Fringe Stub. This type of solution can be considered to be a MANET for NEMO (MANEMO) approach that aims to optimise the local routing in a Nested NEMO topology. When a Fringe Stub is supported in this manner we refer to it as a MANEMO Fringe Stub. 4. Rationale for the proposed solution 4.1. Why ND based NINA extends the Neighbor Discovery protocol to address the MANEMO requirements listed in [18], although MANET protocols [12], [15], [16] provides similar features such as local routing and Internet access over multihop. Thubert & Bernardos Expires March 16, 2009 [Page 5] Internet-Draft NINA September 2008 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. As opposed to most MANET scenarios, MANEMO scenarios do not typically require to establish direct communication with other nodes in the MFS. Instead their typical form of communication is with nodes located in the Internet. Therefore the default route they are interested in establishing is the one between themselves and their respective Gateway. It should be noted however that communication may consequently take place between two nodes in an MFS, in this case the MANEMO protocol should optimise the delivery of packets to ensure that they at least are not transmitted beyond the Gateway. 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. 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 Thubert & Bernardos Expires March 16, 2009 [Page 6] Internet-Draft NINA September 2008 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 RRH The Reverse Routing Header (RRH) described in [17] 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 [17] 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. 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 [17], 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 & Bernardos Expires March 16, 2009 [Page 7] Internet-Draft NINA September 2008 5. NINA Overview This section provides an overview of the operation of NINA to set-up MNP route state in a nested-NEMO scenario. 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 time a movement occurs, TD restores the loop-less structure before NINA can operate again and repaint the graph with prefixes. Thubert & Bernardos Expires March 16, 2009 [Page 8] Internet-Draft NINA September 2008 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. 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 Thubert & Bernardos Expires March 16, 2009 [Page 9] Internet-Draft NINA September 2008 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 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 |L| Reserved1 |4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NINO Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NINO Depth | Reserved3 | NINO Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix (Variable Length) + | | + + | | Thubert & Bernardos Expires March 16, 2009 [Page 10] Internet-Draft NINA September 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. '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: Thubert & Bernardos Expires March 16, 2009 [Page 11] Internet-Draft NINA September 2008 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. 6.2. NINO IPv4 option NINA is defined for both IPv4 and IPv6 address families. For IPv4, a new NINO IPv4 option is introduced to be included in RA and NA messages, for a node to advertise its IPv4 address on the interface where the ND message is issued. The NINO IPv4 option can be included in an RA by the sending router to expose its IPv4 address to the attached visitors, so they can install a default route via that address and use the sending router as default gateway. The option can also be included in a NA by a visiting node to expose its IPv4 address to the Attachment Router; this address is used as next hop by the AR as it installs routes via the visiting node towards the IPv4 prefixes contained in the NINOs and passed as mapped addresses in the NA message. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address on sending interface | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: NINO IPv4 (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. Reserved: Thubert & Bernardos Expires March 16, 2009 [Page 12] Internet-Draft NINA September 2008 8-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. IPv4 address on sending interface: 32-bit field containing the IPv4 address of the sending interface. 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. When the Reverse Routing Header (RRH) is used for NEMO flows, it 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. Thubert & Bernardos Expires March 16, 2009 [Page 13] Internet-Draft NINA September 2008 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. NINA maintains abstract lists of known prefixes. A prefix entry contains the following abstract information: NINA maintains abstract lists of known prefixes. NINA stores the prefix entries in either one of 3 abstract lists; the Connected, the Reachable and the Unreachable lists. A prefix entry contains the following abstract information: 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. 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, Thubert & Bernardos Expires March 16, 2009 [Page 14] Internet-Draft NINA September 2008 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. 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 Thubert & Bernardos Expires March 16, 2009 [Page 15] Internet-Draft NINA September 2008 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: 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. Thubert & Bernardos Expires March 16, 2009 [Page 16] Internet-Draft NINA September 2008 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 [20] 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. Thubert & Bernardos Expires March 16, 2009 [Page 17] Internet-Draft NINA September 2008 Section 2.7 of RFC 4888 [21] 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 ([17]) 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 8. Privacy Considerations It is already possible for a visiting Mobile Node (Mobile Router) to autoconfigure an address that will not identify the visitor [22], [13]. 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 [8]) 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 [23]. Another possibility is to use strict RRH routing [17]; 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 [24], [25] or DHCPv6 prefix delegation [9] can be used as well. 9. IANA Considerations This document requires IANA to assign a number for a new ND option type (NINO NA). Thubert & Bernardos Expires March 16, 2009 [Page 18] Internet-Draft NINA September 2008 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 authorized 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 [26] or [27]) -- may be used to provide the required authorization, before starting to use the RO shortcut within the MFS. 11. Acknowledgments We would like to thank all the people who have provided comments on this draft. 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., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [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. Thubert & Bernardos Expires March 16, 2009 [Page 19] Internet-Draft NINA September 2008 [6] Thubert, P., Bontoux, C., Montavont, N., and B. McCarthy, "Nested Nemo Tree Discovery", draft-thubert-tree-discovery-07 (work in progress), August 2008. [7] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, November 2005. [8] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [9] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 12.2. Informative References [10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [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 Neighbor Discovery (SEND)", RFC 3971, March 2005. [14] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-07 (work in progress), November 2007. [15] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsrv2-07 (work in progress), July 2008. [16] Clausen, T., Dearlove, C., and J. Dean, "MANET Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-07 (work in progress), July 2008. [17] 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. [18] Wakikawa, R., "Problem Statement and Requirements for MANEMO", Thubert & Bernardos Expires March 16, 2009 [Page 20] Internet-Draft NINA September 2008 draft-wakikawa-manemo-problem-statement-01 (work in progress), July 2007. [19] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [20] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC 4887, July 2007. [21] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007. [22] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. [24] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address Autoconfiguration for MANET: Terminology and Problem Statement", draft-ietf-autoconf-statement-04 (work in progress), February 2008. [25] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP address autoconfiguration mechanisms for MANETs", draft-bernardos-manet-autoconf-survey-03 (work in progress), April 2008. [26] Ng, C., "Extending Return Routability Procedure for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress), October 2004. [27] 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. Contributors Ryuji Wakikawa Toyota ITC 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Thubert & Bernardos Expires March 16, 2009 [Page 21] Internet-Draft NINA September 2008 Fax: +81-3-5561-8292 Email: ryuji@jp.toyota-itc.com Roberto Baldessari NEC Europe Network Laboratories Kurfuersten-anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342167 Email: roberto.baldessari@netlab.nec.de Jean Lorchat Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN Email: lorchat@sfc.wide.ad.jp Ben McCarthy Lancaster University Computing Department Infolab21, South Drive Lancaster University Lancaster LA1 4WA UK Phone: +44 1524 510 383 Email: b.mccarthy@lancaster.ac.uk Appendix B. Change Log Changes from -01 to -02: o NINA IPv4 support: added IPv4 NINO ND option. o References updated. o Updated the location of the 'L' bit in the NINO NA option, to match format of RFC 4861. 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 & Bernardos Expires March 16, 2009 [Page 22] Internet-Draft NINA September 2008 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 Carlos J. Bernardos (editor) Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es Thubert & Bernardos Expires March 16, 2009 [Page 23] Internet-Draft NINA September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Thubert & Bernardos Expires March 16, 2009 [Page 24]