Ad-Hoc Network Autoconfiguration T. Boot (Autoconf) Infinity Networks Internet-Draft November 2, 2007 Expires: May 5, 2008 NEMO for Mobile Ad-hoc Networks draft-boot-autoconf-nemo4manet-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 May 5, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Mobile Ad-hoc Networks could be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization. It provides facilities for choosing the best Border Router, configuring IP addresses needed for using the selected Border Router and providing a path to the selected Border Router. Seamless transition to alternate Border Routers is provided. When mobile nodes in the MANET make use of Mobile IP or NEMO (NEtwork MObility), session continuity is provided. NEMO for Boot Expires May 5, 2008 [Page 1] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 MANET is based on NEMO, which utilizes IPv6 mobility support. The NEMO basic support protocol can easily be enhanced to support IPv4, which provides IPv4 support by NEMO for MANET. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol overview and functioning . . . . . . . . . . . . . . 6 3.1. Border Router Discovery Protocol (BRDP) . . . . . . . . . 6 3.2. BRDP-based Autoconf . . . . . . . . . . . . . . . . . . . 6 3.3. NEMO for MANET . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Session continuity . . . . . . . . . . . . . . . . . . . . 7 3.5. Leech tunneling . . . . . . . . . . . . . . . . . . . . . 7 3.6. Anonymity and traffic flow confidentiality . . . . . . . . 7 4. Border Router Discovery Protocol . . . . . . . . . . . . . . . 8 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Border Router Information Option (BRIO) . . . . . . . . . 8 4.2.1. BRIO Base option . . . . . . . . . . . . . . . . . . . 8 4.2.2. BRIO suboptions . . . . . . . . . . . . . . . . . . . 11 4.3. BRDP processing . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. BRDP message reception and BRIO cache maintenance . . 13 4.3.2. Generating and sending BRDP messages . . . . . . . . . 14 4.3.3. BRDP loop prevention . . . . . . . . . . . . . . . . . 16 5. BRDP-based Autoconf . . . . . . . . . . . . . . . . . . . . . 18 5.1. Border Router selection . . . . . . . . . . . . . . . . . 18 5.2. MANET Address generation . . . . . . . . . . . . . . . . . 19 6. NEMO for MANET . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Need for enforcing usage of selected Border Router . . . . 21 6.2. Using NEMO as tunneling method . . . . . . . . . . . . . . 21 6.3. Header compression . . . . . . . . . . . . . . . . . . . . 22 7. Session continuity . . . . . . . . . . . . . . . . . . . . . . 23 8. Support for IPv4 . . . . . . . . . . . . . . . . . . . . . . . 24 9. Leech tunneling . . . . . . . . . . . . . . . . . . . . . . . 25 10. BRDP-based routing . . . . . . . . . . . . . . . . . . . . . . 26 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 Boot Expires May 5, 2008 [Page 2] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12.1. Anonymity and traffic flow confidentiality . . . . . . . . 28 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14.1. Normative reference . . . . . . . . . . . . . . . . . . . 29 14.2. Informative Reference . . . . . . . . . . . . . . . . . . 30 Appendix A. Change Log From Previous Version . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Boot Expires May 5, 2008 [Page 3] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 1. Introduction The Autoconf workgroup is chartered for standardizing mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. Issues and requirements related to prefix and/or address providing entities shall be addressed. The reader should be familiar with "Mobile Ad hoc Network Architecture" [1] and "Address Autoconfiguration for MANET: Terminology and Problem Statement" [2]. This document describes a complete solution for Autoconf. The solution makes use of as many existing protocols as is feasible. One new protocol is defined for Border Router discovery. All other mechanisms used are existing IETF protocols. The Autoconf solution uses three phases: o Discovery of a Border Router o Autoconfiguration of a globally routable IPv6 addresses to be used for that Border Router o Assurement that traffic sent with the configured globally routable IPv6 address actually uses that Border Router Address uniqueness is assured by IPv6 address generation mechanisms used. NOTE from the author: This version of the document includes information on what functionality NEMO for MANET provides and why. There is also a section on routing, which is somewhat related to Autoconf. However, the Autoconf workgroup should not work on this. During peer reviewing, it was suggested to split this document for better fitting IETF workgroups. This is processed after IETF-70. End of note. Boot Expires May 5, 2008 [Page 4] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [10]. Readers are expected to be familiar with all the terms defined in RFC3753: Mobility Related Terminology [11], RFC4885: Network Mobility Support Terminology [13], Mobile Ad hoc Network Architecture [1] and "Address Autoconfiguration for MANET: Terminology and Problem Statement" [2]. Autoconf Ad-Hoc Network Autoconfiguration BRDP Border Router Discovery Protocol BRIO Border Router Information Option MNR-BR tunnel NEMO based MANET Router to Border Router tunnel MR-HA tunnel Mobile Router to Home Agent tunnel UPM Uniform Path Metric MANET Generated Address Globally unique IPv6 and topologically correct address generated for connectivity between nodes in the MANET and Corresponding Nodes in the fixed infrastructure via a Border Router MANET A routing domain containing MANET routers [1]. Boot Expires May 5, 2008 [Page 5] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 3. Protocol overview and functioning In the following subsections, the NEMO for MANET subcomponents are briefly introduced. 3.1. Border Router Discovery Protocol (BRDP) BRDP extends IPv6 neighbor discovery to provide information on MANET Border Routers. Information is distributed in the MANET, where each MANET Router selects one or more Border Routers and forwards the Border Router information in the MANET. BRDP is implemented as extension on IPv6 Neighbor Discovery [3]. Flood reduction mechanisms MAY be used. First of all, a MANET Router MAY filter Border Routers, based on a path metric. The path metric is the advertized bidirectional distance to the fixed infrastructure, via that Border Router. Secondly, a MANET flooding reduction mechanism MAY be used, if a MANET protocol running in the MANET provides this service. BRDP can carry detailed information for the Border Router, such as a provider name and AAA options. AAA enables providers to control access to the Border Routers. MANET Routers MAY select a Border Router based on preferences for a provider. BRDP can also be used to select an Access Router for Mobile IPv6, as the Border Router option provides information for paths to the fixed infrastructure. The provided information can be used among the Default Router Preferences defined in RFC4191 [15]. 3.2. BRDP-based Autoconf BRDP provides prefix information to configure MANET Generated Addresses. An MANET Generated Address is a globally unique IPv6 and topologically correct address generated for connectivity between nodes in the MANET and Corresponding Nodes in the fixed infrastructure via a Border Router. The nodes using BRDP-based Autoconf MUST implement a mechanism to generate a unique 64-bit Interface Identifier. Uniqueness is extremely likely when Modified EUI-64 format-based Interface Identifiers are used [5], generated randomly [6], or by a well- distributed hash function [7]. The generated Interface Identifier is combined with a BRDP provided 64-bit prefix, resulting in topologically correct address. In this document, it is assumed the fixed infrastructure is the Boot Expires May 5, 2008 [Page 6] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 Internet and globally unique addresses are used. The mechanisms described in this document are compatible with unique local addresses [16]. An implementation MAY provide configuration options for Border Router selection based on offered global prefixes or unique local prefixes, in cases where both types are used in the same MANET. 3.3. NEMO for MANET When a Border Router has been selected and an accompanying address has been configured, there is still a need for a mechanism enforcing this Border Router to be used as an exit router to the fixed infrastructure. NEMO basic support [14] is used as a dynamic tunneling mechanism. Tunneling overhead is reduced by implementing header compression, e.g. RoHC [9]. 3.4. Session continuity When mobile nodes in the MANET move, it is likely that the selected Border Router becomes less optimal. Switching to an alternate Border Router and updating addresses would break sessions to Corresponding Nodes. By using "Mobility Support in IPv6" (RFC3775, [12]), session continuity between the MANET Router and Corresponding Nodes is provided. For hiding mobility for local fixed nodes (LFNs), the MANET Router would act as Mobile Router implementing "Network Mobility (NEMO) Basic Support Protocol" (RFC3963, [14]). The nested NEMO approach introduces one additional tunneling header. Once again, header compression is used to reduce the overhead. Seamless handover is provided by a controlled switch between NEMO MNR-BR tunnels. The MANET Router is responsible for setting up and tearing down the tunnels, and switching traffic over these tunnels. The NEMO MR-HA tunnel is also updated to reflect the new configured address. Coherent switching does not result in any packet loss. 3.5. Leech tunneling When a cluster of MANET Routers moves as a whole, a central node MAY provide Border Router services for other nodes. This mechanism reduces signaling overhead for tunnel maintenance. 3.6. Anonymity and traffic flow confidentiality The mobile nodes in the MANET could require security services. By using IPsec in the NEMO tunnels, traffic flow confidentiality and LFN anonymity is provided. IPsec increases the overhead, but this is kept at a minimum by using header compression. Boot Expires May 5, 2008 [Page 7] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 4. Border Router Discovery Protocol 4.1. Introduction BRDP is a simple distance vector protocol that distributes Border Router information. It extends the Neighbor Discovery Protocol [3] in order to carry information and metrics which help a MANET Router to select a Border Router and help to configure addresses for communication with the fixed infrastructure. BRDP is a derivative of Tree Discovery [18], one of the candidate protocols for Routing for Sensor Networks (RSN) and MANET for NEMO (MANEMO). This document describes a protocol that best suits the Autoconf requirements. It has to be determined if merging with functionally equivalent RSN or MANEMO protocols is useful. BRDP is a minimum extension to IPv6 Neighbor Discovery Router Advertisements in order to distribute information on Border Routers. It does not rely on any MANET protocol. Information is distributed hop by hop from a Border Router downwards in the MANET using a tree structure. Multiple Border Routers result in multiple, potentially overlapping logical trees, i.e. a Directed Acyclic Graph (DAG). ICMP Router Advertisement (RA) messages are used for distributing Border Router information using the Border Router Information Option (BRIO). BRIO allows MANET Routers to advertise Border Router reachability, including information to select a preferred Border Router. A MANET Router also destils a set of BRIOs for advertizing, with a minimum of one. A mechanism is used to prevent looped information, based on distance (Uniform Path Metric (UPM) and Hopcount), sequence numbers and timing. 4.2. Border Router Information Option (BRIO) The Border Router Information Option carries information that allows a MANET Router to select and utilize a Border Router. 4.2.1. BRIO Base option The BRIO is a container option, which might contain a number of suboptions. The BRIO base option groups the minimum information set that is mandatory in all cases. Boot Expires May 5, 2008 [Page 8] Internet-Draft NEMO for Mobile Ad-hoc Networks November 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 |A|F|E|L|S|rsvd | Hopcount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Border Router Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Uniform Path Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: BRIO base option Fields: Type: 8-bit identifier of the Router Advertisement option type. The option identifier is to be determined. Length: 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The minimum BRIO option length is 4. AAA(A): Flag indicating using the Border Router needs authentication and authorization. When set, a Service Selection suboption immediately follows the BRIO base option. This document does only describe BRIO forwarding rules considering the A-flag and Service Selection suboption. Details on performing AAA is out-of-scope of this document. Boot Expires May 5, 2008 [Page 9] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 Floating(F): When the F-flag is set, the Border Router has lost contact with the fixed infrastructure. MANET Routers SHOULD stop using Border Routers indicating that they are floating. Emergency Response Services(E): When the E-flag is set, the Border Router provides support for emergency response services. Details on applications for emergency response services are out-of-scope of this document. The E-flag helps selecting BRIOs to be distributed in the MANET, BRIO distribution SHOULD enable access to emergency response services for all MANET nodes. Loop-possible(L): When the L-flag is set, an upstream MANET Router cannot guarantee a loop-free path to the Border Router advertized in this BRIO. Loop-possible status is cleared when a Border Router generated BRIO with a new Sequence Number is forwarded in the MANET. Solicitation Response(S): When the S-flag is set, the Border Router requests forwarding the BRIO downstream the BRIO forwarding tree as a response to a special Router Solicitation. This provides a mechanism to speed up convergence, requested by a downstream MANET Router. See Section 4.3.3 for details. rsvd, reserved: Reserved bits. Set to 0. Hopcount: 8-bit field registering the number of hops from the advertizing MANET Router to the Border Router. Border Routers send BRIO with a Hopcount zero. MANET Routers increment Hopcount by one when forwarding a BRIO. Hopcount is used for to provide loop-free BRIO forwarding. Border Router Address: 128-bit address of the Border Router. The Border Router is expected to add its own address as /128 prefix in the MANET routing system. Boot Expires May 5, 2008 [Page 10] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 Uniform Path Metric (UPM): Uniform Path Metric is set to an initial value by the Border Router and incremented by each MANET Router forwarding the BRIO. The increment value MUST be between 1 and 16777215, allowing 255 hops with a maximum link metric. Border Router selection is based on UPM and optionally other information. UPM is used to provide loop-free BRIO forwarding. Sequence Number: 16-bit unsigned integer set by the Border Router and incremented with each new BRIO it sends on a link and propagated with no change down the tree. 4.2.2. BRIO suboptions In addition to the BRIO Base option, a number of suboptions are defined. Suboptions MAY have alignment requirements. 4.2.2.1. Pad suboption The Pad suboption format is as follows: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type = 0 | +-+-+-+-+-+-+-+-+ Figure 2: Pad suboption Fields: Type = 0 8-bit identifier of the Pad suboption type. The option identifier is determined as 0. The format of the Pad suboption has neither an suboption length nor suboption data fields. The Pad suboption is used to insert one octet of padding in the BRIO to enable alignment, either between suboptions or for the whole suboption container. Boot Expires May 5, 2008 [Page 11] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 4.2.2.2. Service Selection suboption Each BRIO MAY have only one Service Selection suboption, identifying the Service Provider and/or the provided service offered by the Border Router. The Service Selection suboption MUST be the first BRIO suboption. The Service Selection suboption is equivalent to the Service Selection Mobility Option defined in "Service Selection for Mobile IPv6" [20]. 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 = 1 | Length | Identifier... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Service Selection suboption Fields: Type = 1 8-bit identifier of the Service Selection suboption type. The option identifier is determined as 1. Length: 8-bit unsigned integer. The length represents the length of the Service Selection Identifier in octets, excluding the suboption type and length fields. Usage of the Length field is equivalent to [20]. Identifier: A variable length UTF-8 encoded Service Selection Identifier string used to identify the Border Router service provider and optionally the type of service. Valid examples are 'ims', 'voip' and 'voip.companyxyz.example.com'. A Border Router MAY offer multiple services using multiple BRIOs. However, each BRIO MUST use a unique Border Router address. Boot Expires May 5, 2008 [Page 12] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 4.3. BRDP processing BRDP messages are initiated by Border Routers. MANET Routers forward this information using ICMP ND Router Advertisements. The main BRDP processing functions of a MANET Router are BRDP message reception, maintaining a BRIO cache and forwarding BRDP messages. 4.3.1. BRDP message reception and BRIO cache maintenance Border Router information included in received BRDP messages is stored in a BRIO cache table. Along with the BRIO itself, context information is maintained, such as the BRIO sender, history / statistics and status information. History and statistics include a timestamp indicating when the most recent message was received and a measured or signaled RA interval. Status information includes Border Router selection outcome for BRIO forwarding explained in Section 4.3.2 and Border Router selection for its own usage explained in Section 5.1 . Cache entries are unique on Border Router Address and the neighbor router address that forwarded the BRIO. Status information is also maintained at Border Router Address and Service Selection Identifier aggregation level. Also information on neighbor MANET Router is maintained. When a BRDP message is received, the Sequence Number field of received BRIOs is checked; the Sequence of a received BRIO MUST be equal to or higher than Sequence Number in the cache for an existing entry in the cache, with wrap-around checking. BRIO messages do not need to be forwarded at fixed time intervals, so large gaps in sequence numbers may occur. Increment values between 0 and 65000 are accepted. Increment values between 65001 and 65535 are rejected. This specification does not mandate any new restriction on unsolicited multicast Router Advertisements interval. Unsolicited multicast Router Advertisements are sent with an interval between 30 milliseconds, specified in RFC3775 [12] and 1800 seconds, specified in RFC2461 [3]. BRDP assumes unsolicited multicast Router Advertisements have a somewhat stable interval. The RA Advertisement Interval Option MAY provide the maximum interval being used [12] or alternatively the interval can be measured during BRIO reception. A cache cleanup routine SHOULD run at regular intervals to get rid of stale entries. Stale entries are removed when the entry is not updated for 5400 seconds or all following conditions are met: o The stale entry is not used by the MANET Router itself. Boot Expires May 5, 2008 [Page 13] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 o The stale entry was not selected for forwarding in the last Router Advertisement. o The stale entry was not recently updated by a received BRIO. In this context, recently is defined as a) within its own unsolicited multicast Router Advertisements interval and b) shorter than 3 times the measured senders unsolicited multicast Router Advertisements interval. Cache entries MAY also be removed, under condition that the BRIO cache has reached a configured maximum number of entries and a new, to be stored BRIO is received. A removal candidate is selected based on: o The candidate entry is not used by the MANET Router itself. o The candidate entry is not selected for forwarding in the last Router Advertisement. o The candidate entry is redundant; other information for the same Border Router is stored in the cache with a better UPM and / or was received more recently. o The candidate entry is redundant; other information for the same Service Selection Identifier is stored in the cache with a better UPM and / or was received more recently. o The candidate entry is less attractive; other Border Routers are stored in the cache with better UPM and / or were received more recently. 4.3.2. Generating and sending BRDP messages When a MANET Router sends an Router Advertisement it SHOULD include a set of BRIOs. The maximum number of BRIOs to be sent in a BRDP message is a MANET Router configuration parameter. BRIOs are selected from the BRIO Cache. Router Advertisements are sent in response to Router Solicitation messages or unsolicited with a uniformly-distributed random interval that falls between MinRtrAdvInterval and MaxRtrAdvInterval [3]. In addition, the MANET Router MAY send a Router Advertisement when an important change in a to be sent BRIO would occur. The Border Router MAY request that the sent BRIO SHOULD be forwarded downstream in the MANET, indicated by the S-flag, see Section 4.3.3. These additional Router Advertisements are processed similar to responses on Router Solicitations. Boot Expires May 5, 2008 [Page 14] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 Before composing a set of BRIOs, the UPM increment is calculated for each MANET Router from which a BRIO has been received. UPM increments have a minimum value of 1 and SHOULD incorporate bidirectional MANET link metrics for that neighbor. UPM is a composed metric for both the inbound and the outbound path. Note that MANET metrics are defined for one direction only. Using bidirectional UPM optimizes Border Router selection for both inbound and outbound traffic. In some cases it is far more important to select the best path from the Border Router to the MANET Router than the reverse path. In case the link to the MANET Router from which a BRIO has been received is broken, the UPM is set to the maximum value, i.e. 4294967295. Border Router selection SHOULD be based on UPM, preferring the shortest path for the bi-directional MNR-BR tunnel. Note that the BRIO UPM includes the initial metric set by the Border Router, UPM is not a metric between the MANET Router and the Border Router. Initial metric set by Border Routers can be used for Border Router preference and for load balancing. Border Router selection does not select a routing path to the Border Router. The MANET Protocol is used for routing functionality. Section 10 discusses a future extension for NEMO for MANET, providing BRDP-based routing. The BRIO selection algorithm MUST implement a loop avoidance mechanism, described in Section 4.3.3. BRIOs with the L-flag set SHOULD NOT be selected. The BRIO selection algorithm MAY incorporate a hysteresis and dampening mechanism. It MAY also take into account other information, such as history / statistics and status information tracked in the BRIO cache. At a minimum, one BRIO with the E-flag set MUST be selected, when such an entry exists in the BRIO Cache. BRIO selection SHOULD select a number of BRIOs with distinct Service Selection Identifiers, where the selection mechanism MAY use a preference scheme selecting and filtering Service Selection Identifiers. A MANET Router SHOULD inform downstream MANET Routers if the path to a previous advertized Border Router is lost, by at least 3 times retransmitting previous sent BRIO with a UPM value 4294967295 or by selecting a BRIO that failed the loop prevention check, indicated Boot Expires May 5, 2008 [Page 15] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 with the L-flag set. The MANET Router SHOULD include an alternative BRIO for the same Service Selection Identifier in the to be sent BRDP message, if such a BRIO is available in the cache. The UPM and Hopcount fields of the to be sent BRIO are updated. The calculated UPM increment is added to the UPM and the Hopcount is incremented by 1. Incrementing UPM MAY incorporate a hysteresis and dampening mechanism. Also forcasting information MAY be used. For each Border Router listed in the cache, the UPM-loop-prevention- threshold and the Hopcount-loop-prevention-threshold variables are maintained. These variables are used for the loop prevention mechanism described in Section 4.3.3. The variables are set or updated when sending BRDP messages. For a to be sent BRIO with a higher Sequence Number than the previous sent BRIO for that Border Router, the variables are set on values in the to be sent BRIO. For to be sent BRIO with the same Sequence Number, the variables are updated when the UPM or Hopcount of the to be sent BRIO is lower than the threshold. The BRIOs are appended to the Router Advertisement message. The BRIO cache information is updated. A BRDP flooding reduction mechanism MAY be used, where the mechanism reduces redundant BRIO distributing. Some MANET protocols can provide information for the flooding reduction mechanism. No additional protocol is required. 4.3.3. BRDP loop prevention Each BRIO sent out by a Border Router has an increased Sequence Number. This BRIO is forwarded in the MANET and it updates old BRIO status with an outdated Sequence Number. Between these BRIO Sequence updates, MANET Routers MAY repeatedly send BRIOs with a constant Sequence Number and an updated UPM or Hopcount. A MANET Router MUST check candidate BRIOs for providing loop-free operation. Loop-free operation is guaranteed as long as at least one of the following conditions is true: o The BRIO has a higher Sequence Number than a BRIO for this Border Router sent before. Using wrap-around logic, increments up to 32768 are acceptable. (wrap-around logic needs checking) o The BRIO has the same Sequence Number than a BRIO for this Border Router sent before and the UPM value is equal or lower than the UPM-loop-prevention-threshold for this Border Router. Boot Expires May 5, 2008 [Page 16] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 o The BRIO has the same Sequence Number than a BRIO for this Border Router sent before and the Hopcount is equal or lower than the Hopcount-loop-prevention-threshold for this Border Router. When no candidate BRIO for a Border Router is available, the MANET Router SHOULD select the previous sent BRIO. In such a case, the downstream branch for that BRIO is getting frozen. Downstream MANET Routers MAY jump to other branches of the BRIO forwarding tree, as long as their path to the Border Router is shortened by lower UPM or by lower Hopcount. A new BRIO sent by the Border Router thaws a "loop-possible BRIO forwarding tree". A MANET Router that detects an attractive candidate BRIO but is prohibited for using it, because the Sequence Number is lower or equal than the BRIO sent before, MAY send a special Router Solicitation message to the Border Router. The Border Router responds on such a Router Solicitation message with a BRIO with the S-flag set. Sending Router Solicitations MUST be rate limited to at most twice the reception rate of the attractive candidate BRIO. A next version of this document will include a specification for the special Router Solicitation message. In some circumstances, a MANET Router MAY select a BRIO for forwarding that fails the loop prevention check. For example, the link to the upstream neighbor is lost and an alternative path is available, with a higher UPM and a higher Hopcount or with a lower Sequence Number. The MANET Router cannot assure selecting this candidate BRIO provides a loop-free topology, but it could be better than sending nothing or repeatedly sending unreachable. When a MANET Router forwards a BRIO that failed the loop prevention check, the L-flag MUST be set. When a MANET Router selected a BRIO that failed the loop prevention check, a duplicate packet detection mechanism MUST be implemented. MANET Routers that select a BRIO with the L-flag set SHOULD have a duplicate packet detection mechanism implemented. Details on duplicate packet detection is out-of-scope of this document. Boot Expires May 5, 2008 [Page 17] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 5. BRDP-based Autoconf 5.1. Border Router selection When a MANET Router needs to communicate to the fixed infrastructure, it MUST select a set of Border Routers. Information concerning available Border Routers is kept in the BRIO cache. Before selecting, the UPM increment is calculated as described in Section 4.3.2. The Border Router selection algorithm SHOULD be based on Service Selection Identifiers (if available) and UPM. UPM indicates the best Border Router, however such a Border Router MAY require authorization. The A-flag and the Service Selection Identifier provides the prime information for selecting a preferred provider or preferred service. The Border Router selection algorithm MAY be extended with any other information. Future defined BRIO suboptions could provide additional information. Border Router selection MAY be based on the type of the Border Router Address, e.g. a globally unique address or a unique local address. The BRIO flags MAY assist in Border Router selection. o A Border Router could indicate that it is not connected to the fixed infrastructure, signaled with the F-flag. Usage of this Border Router SHOULD be avoided. o For emergency response applications, a Border Router providing such services SHOULD be selected, indicated by the E-flag. o The guarantee for a loop-free path to a Border Router can temporary be withdrawn, indicated by the L-flag set. Usage of this Border Router SHOULD be avoided. The Border Router selection mechanism MAY be triggered by received BRDP messages, changes in metrics to neighbors advertising BRDP messages, changes in MANET metrics to Border Routers used or with a regular interval. Details on authentication and authorization to the Border Router are out-of-scope for this document. A MANET Router MAY select multiple Border Routers for smooth handover implementing make-before-break. It MAY also use multiple Border Routers concurrently. A description how Border Routers can be used concurrently or how traffic is distributed over MNR-BR tunnels is out-of-scope for this document. Boot Expires May 5, 2008 [Page 18] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 5.2. MANET Address generation The MANET Router MUST use a topologically correct address when communicating to corresponding nodes via the fixed infrastructure. Topologically correct addresses SHOULD be generated for each Border Router used. Only when it is known that for all Border Routers for a Service Selection Identifier or a set of Service Selection Identifiers a commonly used address is accepted, a previously generated acceptable address can be reused. A MANET Generated Address is used as a /128 prefix. It is built up with an 64-bits Interface Identifier and a 64-bits prefix from the Border Router Address. This generated /128 address SHOULD be added in the MANET routing system and SHOULD be used as CoA for the NEMO tunnel to the Border Router as discussed in Section 6. The MANET Generated Address MAY also be used for other traffic, either inside the MANET or towards the fixed infrastructure. For communication towards the fixed infrastructure, this address SHOULD only be used if the MANET Router is sure that the traffic is sent via the Border Router that was used for address generation. For the Interface Identifier used, the BRDP-based MANET Address Generation MUST implement a mechanism for generating a unique Interface Identifier. Known mechanisms are: o Modified EUI-64 format-based Interface Identifier, RFC4291 [5], based on IEEE 802 48-bit MAC address or IEEE EUI-64 identifier. However, this method does not guarantee identifiers are unique as duplicate MAC addresses can occur. o Generated randomly, RFC3041 [6]. o Well-distributed hash function, RFC3972 [7]. After MANET Address Generation, RFC4429 Optimistic Duplicate Address Detection [8] SHOULD be used. Still, uniqueness is not fully guaranteed. Main reasons are merging of MANET segments, node movement, node misbehavior or address spoofing attacks. Details on handling this condition are out-of-scope of this document. Address generation for globally unique addresses and RFC4193 unique local addresses [16] is identical. Nodes MUST NOT use unique local addresses to communicate with a Border Router with a globally unique address. Nodes MUST NOT use globally unique addresses to communicate with a Border Router with a unique local address. In case a MANET Generated Addresses is needed but no BRIO information is available, a MANET Router MAY generate an address using a unique Boot Expires May 5, 2008 [Page 19] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 local addresses [16] /64 prefix. A MANET Generated Addresses cleanup routine SHOULD run at regular intervals to get rid of stale addresses. Boot Expires May 5, 2008 [Page 20] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 6. NEMO for MANET 6.1. Need for enforcing usage of selected Border Router Border Router selection and BRDP-based Autoconf is a MANET Router local mechanism. Without an additional mechanism, other MANET Routers are not notified of Border Router selections. As a consequence, it is not enforced that the Border Router chosen is actually used for packets sent to a Corresponding Node via the fixed infrastructure using for example a default gateway. The packets sent to the Corresponding Node need an attribute which can be used to ensure that the packets are forwarded towards the selected Border Router. This Border Router shall remove the attribute and forward the packets. For the return path, there is no such problem, as the MANET Generated Address is associated with the Border Router using its prefix. Packets from the Corresponding Node are forwarded to the Border Router and from there, to the MANET Router that selected this Border Router. Usage of a Border Router could be limited to subscribers. This scenario needs a method for controlled usage of a Border Router. By using a protected tunnel between the node using the Border Router and the Border Router itself, controlled access can be provided. 6.2. Using NEMO as tunneling method By using tunneling, the destination address is used as attribute ensuring the packets are forwarded to the selected Border Router. NEMO basic support [14] is used as a dynamic tunneling mechanism. It provides a mechanism for tunnel maintenance, based on Mobile IP. This mechanism is used for dynamic tunnel setup and tunnel maintenance. Updating tunnel CoA using a Bind Update is rarely needed. However, it can be used to support some security features or for MANET Generated Address changes. Address changes can be used as a remedy against detected duplicate addresses. After a Border Router is selected and a MANET address is generated, the NEMO tunnel binding procedure is performed. Binding is protected by the use of IPsec extension headers or by the use of the Binding Authorization Data option [12]. The security mechanism MUST support open access for binding when the A-flag is cleared. Details on a protected binding to open access Border Routers are to be described in a next version of this document. Boot Expires May 5, 2008 [Page 21] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 When the A-flag is set, the binding mechanism is not defined in this document. When the binding procedure is completed, the MANET Router has access to the fixed infrastructure and can start communicating to corresponding nodes. It can use the MANET Generated Address for short lived connections using the MANET Generated Address, e.g. DNS requests. The MANET Router MUST NOT use the MANET Generated Address for traffic sent via other Border Routers. For providing session continuity while switching between Border Routers, a MIP6 or NEMO MN-HA tunnel is used. The MANET Generated Address is used as CoA for Mobile IPv6 or NEMO in a nested tunnel, as described in Section 7. The MNR-BR (or MR-HA) tunnel MAY be used for DHCPv6 (or DHCP for IPv4 if IPv4 over the NEMO tunnel is supported) to facilitate a need for prefixes / addresses in the MANET, other than provided by NEMO for MANET address generation described in Section 5.2. In this version of this document, it is assumed that DHCP functionality on the Border Router is not needed. "Prefix delegation for NEMO" [19] is to be used to provide addresses managed by a Home Agent. Such addresses are independent from a Border Router. However, the Border Router itself MAY also act as Home Agent. In this scenario, nested tunneling for overlapping MNR-BR and MN-HA SHOULD be circumvented. The HA functionality provided by the Border Router SHOULD be accessible via the fixed infrastructure. When multiple prefixes for a Mobile Network are being used, the Mobile Router MUST forward packets accordingly. Packets with a source address associated with a MR-HA tunnel SHOULD be forwarded over this tunnel. For successful binding, a two-way communication path between the MANET Router and the Border Router is required. The new MANET Generated Address is added in the MANET domain just before the binding procedure. The MANET protocol could need some time to converge and the delivery of the Binding Acknowledgement Message to the MANET Router could fail. Section 10 provides a mechanism to provide immediate bidirectional reachability between the MANET Router and the Border Router. As an alternative, binding update retransmits help complete the binding procedure. 6.3. Header compression Tunneling overhead is reduced by implementing header compression, e.g. RoHC [9]. However, header compression for MIPv6 or NEMO is not defined yet. Individual proposals are work in progress, e.g. "IP Tunneling Optimization in a Mobile Environment" [21]. Boot Expires May 5, 2008 [Page 22] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 7. Session continuity In case the MANET Router prefers another Border Router, it MUST generate a new MANET Generated Address and set up a new MNR-BR tunnel before switching. However, changing addresses would break sessions to Corresponding Nodes. By using Mobile IP, session continuity is provided. To hide mobility for local fixed nodes (LFNs), the MANET Router SHOULD act as Mobile Router implementing NEMO Basic Support [14]. The nested NEMO approach introduces one additional tunneling header. Once again, header compression is used to reduce the overhead. The MNR-BR overhead reduction is also to be used for the MR-HA tunnel. Seamless handover is provided by a controlled switch between NEMO MNR-BR tunnels. The MANET Router is responsible for setting up and tearing down the MNR-BR tunnels. Seamless switching traffic over these tunnels requires "Multiple Care-of Addresses Registration" [22], for the NEMO MR-HA tunnel. Also a mechanism is needed for signaling the preferred CoA, such as "Flow Bindings in Mobile IPv6 and Nemo Basic Support" [23]. Coherent switching does not result in any packet loss. The steps for a seamless handover are: o Complete procedure for selecting a Border Router and generating an Autoconf Address. o Set-up a MNR-BR tunnel o Register new CoA address for MR-HA tunnel on HA o Switch traffic from other tunnels to this new tunnel o Optionally, check connectivity through this updated tunnel; switch back if check fails o Clean up unused MR-HA CoA registrations o Clean up unused MNR-BR tunnels o Clean up unused MANET Generated Addresses A MANET Router MAY keep any number of MNR-BR tunnels, but it SHOULD restrict the number of tunnels to an acceptable value. Boot Expires May 5, 2008 [Page 23] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 8. Support for IPv4 NEMO for MANET is designed for IP version 6. The used mechanism for address generation extends the functionality specified in "IPv6 Stateless Address Autoconfiguration" (RFC2462, [4]). IPv4 lacks a protocol for Stateless Address Autoconfiguration. Dynamic link-Local addresses (RFC3927, [17]) could be used, but these addresses are not globally routable. A future enhancement for NEMO for MANET is supporting IPv4 by using the MR-HA tunnel. After NEMO tunnel setup towards the Home Agent, any NEMO support for IPv4 is provided for usage in the MANET. NEMO for MANET IPv4 support depends on: o NEMO support for IPv4 transport between Mobile Router and Home Agent o Deployment of IPv6 in the MANET o IPv6 connectivity between Border Routers and Home Agents Boot Expires May 5, 2008 [Page 24] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 9. Leech tunneling NOTE from the author: I used the term LEECH, because I could not find any other term for this functionality. In the past, leeching was being used to reduce blood pressure, so it could be some kind of a remedy. Too much leeching weakens a person or can be cause of death. Same applies for what is meant here, leech tunneling reduces binding update storms, but it can overload an offering MANET Router. End of note. In a MANET, a group of MANET Routers could move as a whole. Switching Border Routers would generate a storm of NEMO tunnel maintenance overhead. In such a case, a single tunnel update procedure for all MANET Routers in a cluster could be more efficient. This mechanism can be supported by another NEMO nesting. MANET Routers MAY select another MANET Router in the moving cluster as (proxy) Border Router. Leech tunneling is supported without any modification in BRDP, MANET Generated Address generation or NEMO tunneling protocol. However, leech tunneling depends on a MANET Router offering leeching as a service. A MANET Router MAY advertise itself as Border Router, with an UPM as calculated during the BRIO generation step described in Section 4.3.2. The UPM MAY additionally be incremented, as the additional nesting introduces additional overhead. Next versions of this document might refine the Leech Tunneling mechanism. BRIO suboptions could be added for improving performance, e.g. clusterhead election. Boot Expires May 5, 2008 [Page 25] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 10. BRDP-based routing NOTE from the author: BRDP-based routing is to be discussed in IETF, the expected outcome would be to remove this idea out of this document and optionally to describe this mechanism in more detail in a seperate Internet Draft. End of note. NEMO for MANET's primary goal is to provide a mechanism to distribute Border Router information, address generation and Border Router utilization. Providing a path between the MNR and the BR is a responsibility of the MANET Routing protocol. However, the mechanism can easily be extended to provide lightweight routing, providing only the needed paths and nothing else. The proposed mechanism described below could be somewhat optimized for improved performance, e.g. better loop avoidance or speeding up convergence time. The paths provided by BRDP-based routing can span multiple MANET protocols or MANET regions segmented by parameters (e.g. area ID) or security mechanisms (e.g. shared key). BRDP-based routing is not a replacement for MANET routing protocols. MANET routing protocols are optimized for inner MANET routing, where BRDP-based routing is optimized for Border Router reachability. Using two mechanisms fulfilling these two objectives is practical and efficient. BRDP provides loop-free BRIO distribution, but can also provide a backwards path from MANET Routers to learned Border Routers. For each Border Router Address, the neighbor advertizing the best path (lowest UPM) incremented with a link metric to the neighbor is selected as next-hop. To provide a path from the Border Router to the MANET Routers, a new mechanism is needed. Choices are: o Implement some form of source routing, where the Border Router caches this routing header and uses this information for sending packets to the MANET Router. Such a mechanism is described in "IPv6 Reverse Routing Header and its application to Mobile Networks" [24]. o Implement some form of ND extension, signaling reachability information towards the Border Router. Such a mechanism is described in "Network In Node Advertisement" [25]. Boot Expires May 5, 2008 [Page 26] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 o Implement some kind of Routing header or Hop-by-Hop Options header, signaling the MANET Router address used for forwarding the packet to the Border Router. All MANET Routers in the path, used for the MNR-BR tunnel, process this header. The routing table is checked and updated if needed, storing the reverse path back to the MANET Router. This provides a return path, from Border Router to MANET Router as soon as the first packet with the MANET Generated Address is received by the Border Router. This mechanism is similar to an 802.1D self-learning bridge. Note that this header information can also be used for loop detection, a packet MUST NOT be forwarded back to the previous hop. Routing table entries generated by BRDP-based routing SHOULD have an expiration time. The maximum time suggested is two times the maximum unsolicited multicast Router Advertisements interval, which is 1 hour. Boot Expires May 5, 2008 [Page 27] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 11. IANA considerations The IANA is requested to define a new IPv6 Neighbor Discovery option for the Border Router Information Option, defined in this document. +------+----------------------------------+-----------+ | Type | Description | Reference | +------+----------------------------------+-----------+ | TBA | Border Router Information Option | [RFCXXXX] | +------+----------------------------------+-----------+ Figure 4: IANA BRIO assignment The registry for these options can be found at: http://www.iana.org/assignments/icmpv6-parameters The IANA is requested to create a new registration for BRIO suboptions. 12. Security Considerations NEMO for MANET inherits security considerations from MANET and NEMO technology. BRDP is a new mechanism, based on ND. BRDP inherits security considerations from ND. A more detailed description on this subject is to be included in a next version of this document. 12.1. Anonymity and traffic flow confidentiality In a wireless environment, a major vulnerability is traffic interception. Encrypting data traffic is used as a remedy. By using IPsec in the NEMO tunnels, traffic flow confidentiality and LFN anonymity can be provided. IPsec increases the overhead. Once again, header compression is used to reduce overhead. The following services are provided: o Traffic between LFN and CN can be encrypted. This is an end-node responsibility. o The MR-HA tunnel can be encrypted. This protects the tunnel and hides LFN and CN addresses. Boot Expires May 5, 2008 [Page 28] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 o The MNR-BR tunnel can be encrypted. This protects the tunnel and hides LFN and CN addresses. The CN address would be the MR-HA tunnel HA address. o The MNR-BR Bind Update MAY use random CoA addresses. Information leakage is limited to the Border Router address and Border Router prefix. Details on anonymous Bind Update for the MNR-BR tunnel are to be included in one of the next versions of this document. Anonymity is also related to information on other layers, e.g. 802 MAC addresses or mobile equipment identities (IMEI) / mobile subscriber identities (IMSI). 13. Acknowledgments The author wants to thank anyone involved in IETF on MANET and NEMO technology for their efforts on mobile network infrastructures. Special thanks to Pascal Thubert, Thomas Clausen and Ryuji Wakikawa for their efforts on defining MANEMO technology, which inspired the author to compose this document. Also special thanks to Benny Tops and Ronald in 't Velt for reviewing. 14. References 14.1. Normative reference [1] Chakeres, I., "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-06 (work in progress), October 2007. [2] Baccelli, E., "Address Autoconfiguration for MANET: Terminology and Problem Statement", draft-ietf-autoconf-statement-01 (work in progress), September 2007. [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [4] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [5] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. Boot Expires May 5, 2008 [Page 29] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 [7] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [8] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006. [9] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [11] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [12] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [13] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [14] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. 14.2. Informative Reference [15] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, November 2005. [16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [17] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [18] Thubert, P., "Nested Nemo Tree Discovery", draft-thubert-tree-discovery-06 (work in progress), July 2007. [19] Kniveton, T. and P. Thubert, "Mobile Network Prefix Delegation", draft-ietf-nemo-prefix-delegation-02 (work in progress), August 2007. [20] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Boot Expires May 5, 2008 [Page 30] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 Selection for Mobile IPv6", draft-korhonen-mip6-service-04 (work in progress), October 2007. [21] Haddad, W., "IP Tunneling Optimization in a Mobile Environment", draft-haddad-mip6-tunneling-optimization-01 (work in progress), July 2007. [22] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-03 (work in progress), July 2007. [23] Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-soliman-monami6-flow-binding-04 (work in progress), March 2007. [24] 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. [25] Thubert, P., "Network In Node Advertisement", draft-thubert-nina-01 (work in progress), July 2007. Boot Expires May 5, 2008 [Page 31] Internet-Draft NEMO for Mobile Ad-hoc Networks November 2007 Appendix A. Change Log From Previous Version o 00: Initial Document. Author's Address Teco Boot Infinity Networks B.V. Elperstraat 4 Schoonloo 9443TL Netherlands Email: teco@inf-net.nl Boot Expires May 5, 2008 [Page 32] Internet-Draft NEMO for Mobile Ad-hoc Networks November 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). Boot Expires May 5, 2008 [Page 33]