AUTOCONF S. Ruffino Internet-Draft P. Stupar Expires: August 5, 2006 TILAB February 2006 Automatic configuration of IPv6 addresses for MANET with multiple gateways draft-ruffino-manet-autoconf-multigw-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a mechanism for stateless autoconfiguration of IPv6 addresses for Mobile Ad-hoc Networks (MANETs), connected to the Internet by means of one or more gateways. Network prefixes are disseminated by Internet gateways and are used by nodes to configure a set of global IPv6 addresses. An algorithm is specified, by which nodes can choose the optimal address for data traffic. Configured global addresses are also advertised to other MANET nodes, to Ruffino & Stupar Expires August 5, 2006 [Page 1] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 minimize latencies in case of gateway failures, partitions and mergers. The specified mechanism aims to be independent from any particular MANET routing protocol and to effectively exploit multiple gateways. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability Scenarios . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement and assumptions . . . . . . . . . . . . . . 6 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 4. Autoconfiguration Method Overview . . . . . . . . . . . . . . 9 4.1 Advantages of the proposed method . . . . . . . . . . . . 10 5. Logical data structures . . . . . . . . . . . . . . . . . . . 11 5.1 Prefix Information Base . . . . . . . . . . . . . . . . . 11 5.2 Global Addresses Information Base (GAIB) . . . . . . . . . 11 5.2.1 Global Addresses Information Base Management . . . . . 12 6. Prefix Advertisement . . . . . . . . . . . . . . . . . . . . . 14 6.1 Prefix Advertisement (PA) messages format . . . . . . . . 14 6.2 PA message generation . . . . . . . . . . . . . . . . . . 15 6.3 PA message processing and PIB management . . . . . . . . . 16 7. Address configuration mechanism . . . . . . . . . . . . . . . 17 7.1 MANET-local Address configuration . . . . . . . . . . . . 17 7.2 Global addresses configuration . . . . . . . . . . . . . . 17 7.2.1 Best Prefix Selection Algorithm . . . . . . . . . . . 18 7.3 Global addresses broadcasting . . . . . . . . . . . . . . 19 7.3.1 OLSRv1 operations . . . . . . . . . . . . . . . . . . 19 7.3.2 OLSRv2 operations . . . . . . . . . . . . . . . . . . 19 7.3.3 DYMO operations . . . . . . . . . . . . . . . . . . . 20 7.4 Gateway operations . . . . . . . . . . . . . . . . . . . . 20 8. Considerations on address changes . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1 Normative references . . . . . . . . . . . . . . . . . . . 24 11.2 Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 B. Proposed Values for Constants . . . . . . . . . . . . . . . . 28 B.1 Emission Intervals . . . . . . . . . . . . . . . . . . . . 28 B.2 Holding Time . . . . . . . . . . . . . . . . . . . . . . . 28 C. OLSRv1 operations . . . . . . . . . . . . . . . . . . . . . . 29 C.1 Data structures: MID Information Base . . . . . . . . . . 29 C.2 MID messages . . . . . . . . . . . . . . . . . . . . . . . 30 C.2.1 MID message generation . . . . . . . . . . . . . . . . 30 C.2.2 MID message forwarding . . . . . . . . . . . . . . . . 30 C.2.3 MID message processing . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . 32 Ruffino & Stupar Expires August 5, 2006 [Page 2] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 1. Introduction MANETs are wireless networks characterized by the absence of any fixed infrastructure: nodes of a MANET are mobile devices, that function both as end-points of communications as well as intermediate relays. Packets which can not be delivered via a 1-hop link are routed through other intermediate nodes, following a multi-hop path to reach their destinations: a MANET routing protocol enables nodes to calculate the optimal path, despite movement of nodes. If a MANET is connected to an external network (e.g. the Internet), nodes can communicate with hosts located in such network: in this case, global connectivity has to be guaranteed, i.e. MANET nodes must be configured with a topologically correct IP address. This document specifies a stateless mechanism for automatic configuration of topologically correct, globally valid IPv6 addresses on nodes in a MANET connected to the Internet through one or more Internet gateways. An overview of the method can be given as follows: gateways periodically disseminate their IPv6 prefixes in the MANET; when nodes receive such prefixes, they build a set of global addresses, rank them with a best-prefix selection algorithm, start using one or more of them for data traffic and concurrently advertise them back to other MANET nodes. A first key point is the use of a best-prefix selection algorithm, which enables MANET nodes to continuosly choose the best address to use, according to the MANET topology. In fact, a node can change the global address in use e.g. after the failure of the gateway announcing the prefix from which it derived its used global address or for performance reasons, e.g. to optimize downstream data traffic path. A second important feature is address advertisement: it enables nodes and gateways, to know all the addresses configured on each other nodes and to build routes towards them: in particular, packets arriving at the gateways from the Internet directed to any addresses of MANET nodes, can be routed with no delay, even after partitioning occur and many nodes may be forced to change addresses in use. The specified mechanism aims to be independent from any particular MANET routing protocol; nevertheless we specify detailed operations in case the Optimized Link State Routing (OLSR) [RFC3626] is used. This document is organized as follows: Section 2 describes the multiple gateway scenario; Section 3 exposes the problem of global address configuration in case of multiple gateways; Section 4 outlines the proposed solution. Logical data structures are detailed Ruffino & Stupar Expires August 5, 2006 [Page 3] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 in Section 5 and operations are described in Section 6, Section 7, Section 7, Section 7.4. Finally, Section 8 contains some considerations on using the proposed mechanism with Mobile IPv6. Ruffino & Stupar Expires August 5, 2006 [Page 4] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 2. Applicability Scenarios This specification is particularly suited for the reference scenario shown in Figure 1 (see also [I-D.ruffino-conn-scenarios]). In this scenario, MANETs are connected to the Internet by means of one or more gateways (GW1,GW2,GW3). Nodes (N1...N6), that are not directly linked to the external network, can use multi-hop paths to reach the gateways and forward outbound traffic to Internet hosts (H1). H1 | | +---------------+ | Internet |** +---------------+ * * * * * * * * * * GW1** * GW3 | +--GW2 | | | | | ---N1--------+ | | / \ | N5----N6 N4 \ N2 N3-----/ Figure 1: MANET interconnected to an external network An Internet gateway is a MANET node, equipped with a MANET interface, and a second interface, connected to the external network. Multiple gateways can improve reliability and fault tolerance, as there is no single point of failure in the network, and enable load balancing of traffic directed/coming to/from the Internet. Gateways, as well as nodes, can also be mobile devices, and, as such, can join and depart to/from the MANET at any time: the number of available gateways can therefore vary in time. This specification can also be applied to scenarios where Internet connection is unavailable, i.e. when MANET is isolated or temporary disconnected (see [I-D.ruffino-conn-scenarios] for a description of isolated MANET scenarios and applications). Ruffino & Stupar Expires August 5, 2006 [Page 5] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 3. Problem Statement and assumptions Standard configuration methods for IPv6, i.e. stateful ([RFC3315]) and stateless ([RFC2462]) IPv6 autoconfiguration, cannot be applied to multi-link networks such as MANETs, as outlined by previous work ([I-D.singh-autoconf-adp], [PERKINS], [WAKI-GLOBAL6], [I-D.wakikawa- manet-ipv6-support]). Standard methods have been designed for single-hop link (e.g. a single LAN segment), where all hosts and routers share the same Layer 2 link and don't address MANET intrinsic characteristics, such as multi-hop connections, partitions and mergers. This specification aims at solving some of the problems described in AUTOCONF Problem Statement [I-D.singh-autoconf-adp]. In particular, it is focused on global connectivity, i.e. its goals are to enable MANET nodes to build topologically correct IPv6 addresses and to discover and exploit multiple Internet gateways, if present. It is designed to cope with partitions of the MANET and mergers of two or more MANETs. It is worth noting that in the reference scenario (Section 2), different design choices imply different technical issues and requirements: 1. In case of multiple GWs announcing *one* network prefix, partitioning of the MANET may invalid routes in the Internet towards MANET nodes, compromising end-to-end reachability. E.g., if a MANET cloud breaks into two separate parts, each one containing a gateway, routers in the Internet cannot choose the correct gateway to deliver traffic for a MANET node. Recovery could be possible, e.g. using host routes, or using a signalling path through the Internet (if available), between partitioned gateways, but, currently, there is no consolidated way (i.e. IETF standard) to solve the problem. Moreover, the implications should be carefully studied, because it is quite likely such a mechanism would require additional protocols/mechanism to run on Internet routers, gateways and MANET nodes. This might limit the applicability of single-prefix autoconf to scenarios with no partitioning at all, e.g. small controlled ad-hoc networks, with very limited mobility, or static sensor networks. 2. In case of multiple gateways advertising *multiple* network prefixes, no coordination among gateways is needed, to preserve Internet routing consistency, even after partitions/mergers, since traffic is univocally routed towards the gateway owning one particular prefix. Using all the available prefixes, MANET nodes can build a "pool" of valid global IPv6 addresses. However, other problems may arise within the MANET itself. Ruffino & Stupar Expires August 5, 2006 [Page 6] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 In fact, traffic coming from the Internet is routed through the gateway which owns the prefix, used by nodes to build source address for data packets. Nodes' choice of which global address (and gateway) to use is critical, since it also directly affects the path followed by downstream data within the MANET: a node could choose a prefix announced by a very "far" gateway (in terms of routing metrics), while a "closer" one could exist. In this case, traffic could flow through a non-optimal path within the MANET. Therefore, MANET nodes should be able to choose, both at bootstrap and after major topological changes, the best gateway (e.g. the "closest" one in terms of routing metrics) to configure their address(es), in order to minimize latency and delay variation, maximize throughput and efficiently use radio resources. This can be summarized as the "best prefix selection" problem. Note that this problem is separate from the selection of a default gateway, which defines the default route for traffic directed to the Internet. 3. MANET nodes could reconfigure (frequently) their global address(es), due to partitioning, merging, movement and gateway failure. Following current version of [I-D.rfc2461bis], every unicast IPv6 address should be checked for uniqueness, prior to configuration. In a multiple-gateway/multiple-prefixes MANET, this could bring to a large amount of control signalling, especially if the ad-hoc network is very dynamic. 4. If nodes, involved in communications with Internet hosts, use only global addresses for route calculation (e.g. in OLSR, use of global address as originator address), existing MANET routes must be recomputed when connectivity to the gateway that assigned the prefix is lost. This, because nodes could choose to reestablish communications after the outage is detected, by exploiting another available gateway and therefore configuring a new global address. 3.1 Assumptions It is therefore assumed that each gateway owns one or more topologically correct IPv6 network prefixes, which can be announced within the MANET. The mechanism by which gateways retreive this information is out of scope of this specification: it can be manually configured or dynamically set up, during link establishment towards the Internet, e.g. using DHCP with Prefix Delegation Option ([RFC3633]). It is also assumed that different gateways advertise different prefixes, in order not to require special configuration both on Ruffino & Stupar Expires August 5, 2006 [Page 7] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 gateways themselves and on Internet routers. Moreover, as discussed above, use of MANET-local addresses to build in-MANET routes could be more efficient than use of global addresses, in case of frequent global address reconfiguration, especially if proactive protocols are used. This specification explicitly does not address the problem of verifying uniqueness of a newly configured address. It is authors' beleif that due to the very low probability of an address conflict when IPv6 is used, an active Duplicate Address Detection mechanism may not be needed. A lightweight passive address conflict detection and repair mechanism could be used instead. The specified autoconfiguration mechanism performs gateway discovery, but it is assumed that default route calculation is performed by routing protocol running on MANET nodes. This, because routing protocol is the only process responsible for calculating optimal routes in the MANET. Ruffino & Stupar Expires August 5, 2006 [Page 8] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 4. Autoconfiguration Method Overview The proposed autoconfiguration mechanism operates in 4 phases. 1) MANET-local address configuration At bootstrap, nodes configure a permanent MANET-local address and use it as identifier in routing protocol messages (e.g. as main address in OLSR). This specification recommends the use of IPv6 Unique Local Addresses [RFC4193] to configure MANET-local addresses. As explained in Section 3, such addresses are not verified for uniqueness prior to configuration; instead, an address conflict detection mechanism is started, that monitors routing packets and other events, reacting only when a conflict is detected (out of scope of this specification). 2) Prefix Advertisement Internet gateways periodically advertise global network prefixes by means of a message, named Prefix Advertisement (PA). It is assumed that a multicast forwarding engine is available in the MANET. The current version of this specification assumes the use of SMF ([I-D.SMF]); future versions may define a specialized forwarding procedure for PAs; 3) Best prefix selection and global address configuration MANET nodes receive Prefix Advertisement (PA) messages from the gateways. They use the prefixes stored in PAs to configure a set of global IPv6 addresses, built according to [RFC4291]: at least, they build an address from each received prefix. Nodes apply an algorithm, named Best Prefix Selection (see Section 7.2.1), using routing metrics of Internet gateways, if available, to rank the received prefixes. Nodes can use the ranking to select appropriate source address for Internet traffic. 4) Advertisement of global addresses Nodes start broadcasting the configured global addresses (step 3.) to other MANET nodes: this operation enables all nodes to bind MANET-local addresses, used by routing protocol for path calulations, to global addresses. As a result, they can use existing routes to deliver data traffic coming from the Internet and directed to any global address in the MANET. Routing protocols can be used for address advertisement: OLSRv1 (with HNA or MID messages) and DYMO already have the capability to advertise multiple addresses along with the main address of each node. Nodes periodically reapply Best Prefix Selection algorithm (step 3. above), inspecting the routing table. Nodes can also reactively trigger the selection algorithm, to re-order prefixes after a significant event occurs, for example: Ruffino & Stupar Expires August 5, 2006 [Page 9] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 o one ore more gateways which advertises prefixes used by the node are no more reachable. o node experiences a significant topological change after which the best prefix corresponds to an non-optimal path (see Section 3). 4.1 Advantages of the proposed method The main advantages of the proposed solution are the following: o in case of gateway failure or MANET partitioning, nodes can immediately use another valid global address to start data communications with other nodes and Internet hosts: no significant delay due to routing protocol operations is experienced. This, because the local topological information is bound to a MANET- local address and is independent from the global address currently used. As described above (step 4.), all other MANET nodes already know the correct path to reach the node by this address. o the path followed by downstream traffic coming from the Internet can be optimized, with respect to the routing metric. This can be achieved, using a Best Prefix Selection algorithm (Default Gateway method, described in Section 7.2.1) that assigns the highest rank to the address derived from a prefix announced by the default gateway (i.e., the best one routing protocol chooses). o a gateway which becomes a node, e.g. as the result of losing connectivity towards the external network, can immediately receive downlink traffic by using another active gateway. Ruffino & Stupar Expires August 5, 2006 [Page 10] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 5. Logical data structures In this section, two data structures used by the proposed solution are defined: the Prefix Information Base (PIB), which store the received prefixes, and the Global Addresses Information Base (GAIB), which stores global addresses built by the node. Best prefix Selection algorithm is applied on GAIB entries. 5.1 Prefix Information Base The Prefix Information Base (PIB) contains the delegated prefixes announced by gateways within the MANET and it is filled processing Prefix Advertisements. It is maintained by each node and gateway. If a gateway advertises multiple prefixes, PIB MUST be filled with an entry for each advertised prefix. Entries of the PIB have the following structure (length of each field is expressed in octets): +--------------+----------------------------------------------------+ | Field | Data | +--------------+----------------------------------------------------+ | P_address | MANET-local address of the gateway which sent the | | (16) | PA | | | | | P_network | A prefix owned by the gateway whose MANET-local | | (16) | address is P_address | | | | | P_prefix_len | Length of the prefix contained in P_network field | | gth (1) | | | | | | P_time (1) | Validity time | +--------------+----------------------------------------------------+ Table 1: Prefix Information Base (PIB) 5.2 Global Addresses Information Base (GAIB) The Global Addresses Information Base (GAIB) stores the set of the global addresses built by a node, after processing Prefix Advertisements carrying global prefixes, i.e. using global prefixes contained into PIB. It is maintained on each node and gateway. The refresh of GAIB entries tightly depends on the state of the entries of PIB, as the validity of a global Address is bound to the validity of the global prefix from which the global Address has been derived. Best Prefix Selection algorithm is applied on entries of GAIB, which Ruffino & Stupar Expires August 5, 2006 [Page 11] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 are re-ordered accordingly. Entries of the Global Addresses Information Base have the following structure: +--------------+----------------------------------------------------+ | Field | Data | +--------------+----------------------------------------------------+ | G_address | A valid global IPv6 address, owned by the node | | (16) | | | | | | G_prefix_len | Length of the prefix in G_address | | gth (1) | | | | | | G_metric (1) | Routing metric of the gateway, owner of the prefix | | | used to build G_address. | +--------------+----------------------------------------------------+ Table 2: Global Addresses Information Base Entries in GAIB are used to fill routing protocol messages, responsible for advertising global addresses of each node to other MANET nodes (e.g. HNA and MID in OLSRv1), as explained in Section 7.3. Optimisations, such as advertising only a subset of the GAIB, to decrease overhead in the network, may be specified in future versions of this specification. 5.2.1 Global Addresses Information Base Management For each (valid) prefix contained into Prefix Information Base, a node creates a new entry as follows: 1. it creates a IPv6 global address as described in [RFC4291] and stores it in the G_address field. It stores the prefix length in G_prefix_length. 2. it looks-up the routing table and retreives the metric of the gateway that advertised the network prefix used to build G_address, if available. It stores the metric in G_metric field. It can retreive MANET-local address of the gateway inspecting the PIB: the node performs a search using network prefix as key. If the look-up fails, G_metric is left blank. GAIB maintanance is periodically executed, to update values in G_metric field of all entries: i.e. routing table look-up is periodically looked-up to updates values, if necessary. If an entry stored into Prefix Information Base is removed, e.g. Ruffino & Stupar Expires August 5, 2006 [Page 12] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 after P_time expiration, all the addresses derived from the expired prefix must be removed from GAIB as well. Ruffino & Stupar Expires August 5, 2006 [Page 13] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 6. Prefix Advertisement This section details format and processing of Prefix Advertisement messages 6.1 Prefix Advertisement (PA) messages format The PA message format is shown in Figure 2: PAs can contain one or more prefixes, which format is defined in Figure 3. The format used in this specification may be updated by a future version of this document. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Vtime | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Originator Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One ore more Prefixes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 2: Format of Prefix Advertisement messages Where each field of the message has the following meaning: +---------------------+---------------------------------------------+ | Field | Data | +---------------------+---------------------------------------------+ | Message Type | T.B.D. | | | | | Vtime | Validity time of the information stored in | | | the PA message. It is set to PA_HOLD_TIME. | | | | | Message Size | Total length of PA message, including | | | header | | | | | Originator Address | the MANET-local Address of the gateway | | | which generated the message | +---------------------+---------------------------------------------+ Table 3: Prefix Advertisement Fields Ruffino & Stupar Expires August 5, 2006 [Page 14] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Network Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of Prefix for PA messages Where each field of the message has the following meaning: +---------------------+---------------------------------------------+ | Field | Data | +---------------------+---------------------------------------------+ | Prefix Length | the length of the prefix contained in | | | Network Address field | | | | | Network Address | the delegated prefix of the gateway which | | | generated the message | +---------------------+---------------------------------------------+ Table 4: Prefix Fields 6.2 PA message generation PAs are originated by gateways every PA_INTERVAL seconds. Every PA contains all the prefixes owned by the gateway, along with associated validity time. The list of prefixes can be partial in each PA message (e.g., due to message size limitations, imposed by the network, or other policies), but parsing of all PA messages describing the interface set from a node MUST be complete within a certain refreshing period (PA_INTERVAL). The information contained in the PA messages is used by the nodes to build their Global Addresses. This specification assumes use of SMF [I-D.SMF] to perform broadcasting of PAs within the MANET. Using SMF, "hop-count" field, commonly used in MANET applications, cannot be incremented by nodes, upon forwarding the message. Therefore, to apply the Best Prefix algorithm defined in Section 7.2.1, nodes look-up routing table, Ruffino & Stupar Expires August 5, 2006 [Page 15] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 updated by the routing protocol, to retrieve metrics (which can be generally different from hop-count) associated with gateways. 6.3 PA message processing and PIB management PAs are received by all MANET nodes and gateways, which MUST process every received PA according to this Section. Upon processing a PA message, the P_time MUST be computed from the Vtime field of the message header (see [RFC3626]). The PIB SHOULD then be updated as follows; for each Prefix field (Network Address, Prefix Length) in the message: 1. if an entry in the association set already exists, where: P_addr == Originator Address P_network_addr == Network Address P_prefix_length == Prefix Length then the holding time for that entry MUST be set to: P_time = current time + validity time 2. otherwise, a new entry MUST be recorded with: P_gateway_addr = Originator Address P_network_addr = Network Address P_prefix_length = Prefix Length P_time = current time + validity time Ruffino & Stupar Expires August 5, 2006 [Page 16] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 7. Address configuration mechanism This section describes the configuration operations for MANET nodes and gateways. 7.1 MANET-local Address configuration At bootstrap, each node and gateway builds one address following [RFC4193] and configures it on one of its interface partecipating to MANET routing. ULA addresses can be used for multi-hop transmissions (in this sense, they can be defined as MANET-local). Other interface can be configured with ULA as well, but nodes must choose one of its MANET-local addresses as main address and activate the SMF process. MANET-local address is also used as originator address in routing protocol messages. A passive address conflict detection mechanism, such as [I-D.lao.mase], MAY be started after configuration. As explained in Section 4, due to the very low probability of a conflict in IPv6 address space, uniqueness check should be performed in a reactive way, instead of an try-and-wait approach (e.g. the model used in [RFC2462]), which can bring to signalling overhead and long latencies. 7.2 Global addresses configuration As a configuring node joins the appropriate multicast group and activates SMF, it starts receiving PAs from available Internet gateways. It processes PAs and updates PIB accordingly, as described in Section 6.3. It concurrently starts to fill GAIB, as described in Section 5.2.1, building a set of valid global IPv6 addresses. If the node needs to transmit traffic to the Internet, it can configure one or more of the global addresses on its interfaces and start using them as source addresses. To choose the optimal source address to use, the nodes executes the Best Prefix Selection algorithm on entries of GAIB. There are two situations: o node configures only one global address: in this case, the selection algorithm can help the node to choose the best address to use; o node configures multiple global addresses: in this case, [RFC3484] controls the source address selection. The Best Prefix Selection algorithm could nevertheless be use as an aid to RFC3484, using routing table information to rank the global addresses in GAIB. Next section propose two Best Prefix Selection algorithms. In the current version of this document only algorithm traces are included. Ruffino & Stupar Expires August 5, 2006 [Page 17] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 7.2.1 Best Prefix Selection Algorithm The best prefix selection algorithm must take into account factors related to MANET topology, e.g. the routing metrics of the gateways and external factors, e.g. the number and type of active data sessions. It is assumed that a node, inspecting the routing table, monitors the current metric value of every reachable gateway generating PA messages and always knows which is the current deafult gateway, chosen by routing protocol. In this section two alternative algorithms are proposed. 1. Default Gateway Method: a node always ranks the prefix announced by the current Default Gateway as the highest possible and sort the remaining prefixes by descending value of routing metrics (i.e. worse metric means worse ranking). In case of OLSR and DYMO, the default gateway is the closest gateway in terms of number of hops. This algorithm solves the downlink path optimization problem described in Section 3. In fact, if the node uses a global IPv6 address derived from the prefix announced by the default gateway, traffic to and from the external network flows through the same gateway. As a drawback, if MANET topology frequently changes, nodes which configured only one global address on MANET interface, may experience frequent address changes, which can cause disruption of data sessions. 2. Threshold Method: a node compares the metric of the gateway announcing the prefix currently used with the metrics of all gateways ; for each pair, it computes the absolute value of the difference of the two metrics, dicards results which are below a predefined threshold, and finally re-sorts the prefix ranking accordingly. Threshold method accounts for situations when, although nodes use non-optimal prefixes and traffic flows on non-optimal paths, they prefer to keep current address preferences unaltered, e.g. because they have only one configured address and many active data sessions. Choosing one single value of the threshold for many deployment environments can be difficult: it highly depends on the chosen metric and other factors, which do not strictly depend on routing, e.g. Quality of Service required by applications, number of active data sessions. The seelction algorithm SHOULD be executed at bootstrap time, after a node receives the first global prefixes. Nevertheless, this operation SHOULD also be executed when particular events trigger a Ruffino & Stupar Expires August 5, 2006 [Page 18] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 topological change in the MANET. Such events have been cited in Section 4 and can be further detailed as follows: 1. The failure or the departure of the gateway owning the chosen prefix; 2. A partition, after which the node and the gateway owning the chosen prefix are connected to two different MANETs; 3. The gateway, which announces the chosen prefix, becomes a node, e.g. after shutting down the interface connecting it to the external network and stops announcing prefixes; 4. After a movement of one or more MANET devices, a gateway has a better metric than the gateway announcing the chosen prefix; 5. A merging occurs, after which a gateway previously not connected to the MANET may have the best metric value. In case of events 1., 2. and 3. PIB entries expire, because the global prefix, which the global addresses in use are derived from, is no more listed into PA messages: the node MUST also change its global address, choosing one of the prefixes announced by active gateways. In case of 4. and 5., the node determines that its global addresses in use are derived from a non-optimal prefix, according to the the topological information it owns: in this cases, the node MAY use other valid global addresses, derived from optimal gateways. Section 8 elaborates on address changes on MANET nodes. 7.3 Global addresses broadcasting After nodes have built and configured one or more global addresses, they advertise them within the MANET. Doing this, other MANET nodes bind each other node's MANET-local address with the global addresses owned by each node. Since both DYMO and OLSRv2 can already support multiple addresses on a single node, this specification does not define any new broadcasting procedure. In the following sections, implementation guidelines are given for the two mentioned protocols. 7.3.1 OLSRv1 operations OLSRv1 operations are detailed in Appendix C. Here, MID messages are used to disseminate global addresses. HNAs messages can be used as well. 7.3.2 OLSRv2 operations T.B.D. Ruffino & Stupar Expires August 5, 2006 [Page 19] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 In the current version of OLSRv2, HNA and MID functionalities have been incorporated in TC and MA messages. Procedures defined for OLSRv1 can be changed to work with v2 processing. 7.3.3 DYMO operations T.B.D. Current version of DYMO supports "path accumulation", i.e. the capability of inserting information regarding configured addresses and network prefixes into the Route Request and Reply messages. 7.4 Gateway operations Internet gateways have at least one global IPv6 address, belonging to the external network and used on the external interface. While the mechanism, by which such address is acquired, is out of scope of this specification, the configuration of the global address used on the MANET interface is described in this section. Gateways MUST configure the global IPv6 address of their MANET interface using the mechanism specified in Section 5 and Section 7: a gateway MUST execute the operations described in these sections for MANET nodes. Gateways MUST always select the prefix they own, to configure global address they will use on MANET interface. Finally, gateways MUST process PAs received from other gateways, build global addresses and disseminate them as described in Section 7.3. As described in Section 4.1, a gateway can change its mode of operations, becoming a node, for a number of reasons, e.g. because it has lost connectivity with the external network or because of its Internet interface failure. When a gateway is active, but it has indications that the Internet is unreachable, it stops generating PA messages and executes the operations described in Section 7.2 and Section 7.3. Since the gateway has already disseminated its new global address (after it first received prefixes from other gateways), it can start communicating with the hosts located outside the MANET with negligible latency. Ruffino & Stupar Expires August 5, 2006 [Page 20] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 8. Considerations on address changes As explained in Section 7.2, nodes and gateway can configure multiple addresses on their MANET interfaces, if multiple gateways and/or prefixes are available. [RFC3484]is used to choose among configured global addresses the source addresses for data communications. The output of Best Prefix Selection algorithm, i.e. prefix ranking, can be used as an hint, to enable nodes to choose always the optimal prefix and address. Configuring multiple addresses enable nodes to effectively exploit multiple egress points in the MANET and to smoothly change source addresses for data traffic, following MANET topological changes. If a MANET is very dynamic, the best gateway for a node can change very quickly: if multiple address are available, node can simply choose one of them as source address to set-up new data communications. If only one address is configured on MANET interface (e.g. due to user preferences, configuration or other policies), then, according to the proposed solution (Section 7.2.1), node could experience frequent address changes, e.g. in order to optimize downlink traffic coming from external hosts. Generally, such address changes imply active data sessions interruption. In order to cope with this, Mobile IPv6 [RFC3775] can be used. It is worth noting that the proposed mechanism, in particular Section 7.3 reduces (ideally to zero) the latency introduced by a global address change, granting better performances when MANET nodes use MIPv6. In fact, if a node experiments a change from a first gateway to a second gateway, then it chooses a new global address, associated to the second gateway, and it sends a Binding Update message, registering the new chosen address as the new Care-of Address. When the Binding Acknowledge message from the Home Agent arrives at the gateway, immediately a route to the node will be available, because the new Care-of Address was announced in the MANET (as described in Section 7.3). Therefore handover latency is reduced to the time needed to send a Binding Update message and receive the correspondent Binding Acknowledge message routing latency is negligible. Ruffino & Stupar Expires August 5, 2006 [Page 21] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 9. Security Considerations T.B.D. Ruffino & Stupar Expires August 5, 2006 [Page 22] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 10. IANA Considerations This document has no actions for IANA. Ruffino & Stupar Expires August 5, 2006 [Page 23] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 11. References 11.1 Normative references [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 4291, February 2006. 11.2 Informative References [I-D.DYMO] Chakeres, I., Belding-Royer, E., and C. Perkins, "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-03 (work in progress), October 2005. [I-D.OLSRv2] Clausen, T., "The Optimized Link-State Routing Protocol version 2", draft-clausen-manet-olsrv2-00 (work in progress), July 2005. [I-D.SMF] Macker, J., "Simplified Multicast Forwarding for MANET", draft-ietf-manet-smf-01 (work in progress), June 2005. [I-D.lao.mase] Adjih, C., Laouiti, A., and K. Mase, "Address autoconfiguration in Optimized Link State Routing Protocol", draft-laouiti-manet-olsr-address-autoconf-01 (work in progress), July 2005. [I-D.rfc2461bis] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", Ruffino & Stupar Expires August 5, 2006 [Page 24] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 draft-ietf-ipv6-2461bis-05 (work in progress), October 2005. [I-D.ruffino-conn-scenarios] Ruffino, S., Stupar, P., Clausen, T., and S. Singh, "Connectivity Scenarios for MANET", draft-ruffino-conn-scenarios-00 (work in progress), January 2006. [I-D.singh-autoconf-adp] Singh, S., Clausen, T., Perkins, C., and P. Ruiz, "Ad hoc network autoconfiguration: definition and problem statement", draft-singh-autoconf-adp-02 (work in progress), October 2005. [I-D.wakikawa-manet-ipv6-support] Wakikawa, R., "IPv6 Support on Mobile Ad-hoc Network", draft-wakikawa-manet-ipv6-support-00 (work in progress), February 2005. [PERKINS] Perkins, C., Malinen, J., Wakikawa, R., and E. Belding- Royer, "IP Address Autoconfiguration for Ad Hoc Networks", I-D draft-perkins-manet-autoconf-01.txt, November 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [WAKI-GLOBAL6] Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A., and A. Tuominen, "Global connectivity for IPv6 Mobile Ad Hoc Networks", I-D draft-wakikawa-manet-globalv6-04.txt, October 2003. Ruffino & Stupar Expires August 5, 2006 [Page 25] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 Authors' Addresses Simone Ruffino Telecom Italia LAB Via G.Reiss Romoli 274 Torino 10148 Italy Phone: +39 011 228 7566 Email: simone.ruffino@telecomitalia.it Patrick Stupar Telecom Italia LAB Via G.Reiss Romoli 274 Torino 10148 Italy Phone: +39 011 228 5727 Email: patrick.stupar@telecomitalia.it Ruffino & Stupar Expires August 5, 2006 [Page 26] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 Appendix A. Acknowledgments The authors would like to thank Ivano Guardini for his valuable comments. Ruffino & Stupar Expires August 5, 2006 [Page 27] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 Appendix B. Proposed Values for Constants B.1 Emission Intervals PA_INTERVAL = 5 seconds MID_INTERVAL = 5 seconds B.2 Holding Time PA_HOLD_TIME = 3 x PA_INTERVAL MID_HOLD_TIME = 3 x MID_INTERVAL Ruffino & Stupar Expires August 5, 2006 [Page 28] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 Appendix C. OLSRv1 operations This section details the global address advertising procedure, described in Section 7.3, using OLSRv1 MID messages. C.1 Data structures: MID Information Base The Multiple Interface Association Information Base, is defined in [RFC3626]: the present specification modifies the semantics of one of its fields. Multiple Interface Association Information Base is defined in [RFC3626] and is filled processing MID messages. [RFC3626] mandates that these messages are generated by a MANET node only when it is equipped with multiple physical interfaces, through which it is connected to the MANET and participates to OLSR. MIDs contain the addresses configured on the node's physical interfaces. The node is identified by multiple valid IPv6 addresses, one for each interface connected to the MANET: Multiple Interface Association Information Base contains bindings between such addresses and the main address of the node. Using this table, MANET nodes can set-up routes not only towards main address of other nodes, but also towards multiple interface addresses associated to main address. Following [RFC3626], a node connected to the MANET by means of a single interface MUST NOT generate MIDs. In this specification, as described in Appendix C.2, MID messages generated by a node contain the list of the Global Addresses, i.e. the list of all the global addresses the node may configure on its MANET interface. The Multiple Interface Association Information Base is maintained by each node and gateway and is used to store the bindings between the Global Addresses and MANET-local Addresses of other nodes. It is worth noting that the semantics of the entries in Multiple Interface Association Information Base, as well as of MID messages, is changed by this specification, since multiple Global Addresses can be configured on a single interface. This semantic change has no effect on the processing of MID messages and it is completely backward-compatible: in fact, from a node's perspective, addresses announced in MID messages can be single addresses configured on multiple interfaces, or multiple addresses configured on a single interface. Routing table construction rules are not changed: nodes build necessary routes to both primary and secondary addresses following [RFC3626]. Ruffino & Stupar Expires August 5, 2006 [Page 29] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 Hence, Multiple Interface Association Information Base entries have the following semantics (same as specified in [RFC3626]): +--------------+----------------------------------------------------+ | Field | Data | +--------------+----------------------------------------------------+ | I_iface_addr | a Global Address built (and possibly configured) | | | by a node | | | | | I_main_addr | the MANET-local Address of the node which has | | | built the Global Address contained into | | | I_iface_addr field | | | | | I_time | Validity time | +--------------+----------------------------------------------------+ Table 5: Multiple Interface Association Information Base C.2 MID messages By means of standard MID messages processing, when OLSR eventually converges, the node is reachable at any of its Global Addresses : MANET nodes' routing tables contain a route for each secondary address listed into MID messages. A packet whose destination is one of the secondary addresses of a node (e.g. traffic from external hosts to MANET nodes) can therefore be routed within the MANET. Return traffic will be destined to such secondary address and will be routed within the MANET by means of the topological information inserted into MID messages. C.2.1 MID message generation A MID message is sent by a node in the network to announce its Global Addresses. I.e., the MID message contains the list of the Global Addresses which have been built by it and inserted into SAIB. The list of Addresses can be partial in each MID message (e.g., due to message size limitations, imposed by the network), but parsing of all MID messages describing the Global Information Base of a node MUST be complete within a certain refreshing period (MID_INTERVAL). The information contained in the MID messages is used by the nodes to route packets, which may be destined to one (or more) of the Global Addresses, chosen by a node to communicate with hosts located outside the MANET. C.2.2 MID message forwarding Upon receiving a MID message, following the rules of section 3 of Ruffino & Stupar Expires August 5, 2006 [Page 30] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 [RFC3626], the message MUST be forwarded according to section 3.4 of [RFC3626]. C.2.3 MID message processing MID messages are processed as described in [RFC3626]. The tuples in the multiple interface association set are recorded with the information that is exchanged through MID messages. Upon receiving a MID message, the "validity time" MUST be computed from the Vtime field of the message header (as described in Section 3.3.2 of [RFC3626]). The Multiple Interface Association Information Base SHOULD then be updated as follows: 1. If the sender interface (note: not the originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded. 2. For each Global Address listed in the MID message: 1. If there exist some tuple in the interface association set where: I_iface_addr == Global Address, AND I_main_addr == Originator Address, then the holding time of that tuple is set to: I_time = current time + validity time. 2. Otherwise, a new tuple is recorded in the interface association set where: I_iface_addr = Global Address, I_main_addr = Originator Address, I_time = current time + validity time. Ruffino & Stupar Expires August 5, 2006 [Page 31] Internet-Draft Autoconfiguration for multi-gw MANET February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ruffino & Stupar Expires August 5, 2006 [Page 32]