autoconf S. Ruffino Internet-Draft P. Stupar Expires: June 8, 2006 TILAB December 9, 2005 Automatic configuration of IPv6 addresses for nodes in a MANET with multiple gateways draft-ruffino-manet-autoconf-multigw-01 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 June 8, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This Internet Draft relates to Mobile Ad-hoc Networks (MANETs) connected to an external network by means of one or more gateways. A solution that enables MANET nodes to automatically discover a global address is proposed, based on the OLSR protocol. The proposed solution aims at reducing the latency introduced by a global address change and presents two algorithms a node may use to discover if the used address has to be changed. Ruffino & Stupar Expires June 8, 2006 [Page 1] Internet-Draft Multi-GW MANET Autconfiguration December 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Scenario . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 5. Autoconfiguration Method Overview . . . . . . . . . . . . . . 9 5.1 Advantages of the proposed method . . . . . . . . . . . . 10 5.2 Examples of operations . . . . . . . . . . . . . . . . . . 11 5.2.1 Bootstrapping of a node . . . . . . . . . . . . . . . 11 5.2.2 Gateway change . . . . . . . . . . . . . . . . . . . . 12 6. Data structures . . . . . . . . . . . . . . . . . . . . . . . 15 6.1 Prefix Information base . . . . . . . . . . . . . . . . . 15 6.2 Delegated Prefixes Information Base . . . . . . . . . . . 15 6.3 Secondary Addresses Information Base . . . . . . . . . . . 16 6.4 Multiple Interface Association Information Base . . . . . 16 7. Detailed operations . . . . . . . . . . . . . . . . . . . . . 18 7.1 IPv6 Addresses generation . . . . . . . . . . . . . . . . 18 7.2 Primary Address configuration . . . . . . . . . . . . . . 18 7.3 Prefix Advertisement . . . . . . . . . . . . . . . . . . . 18 7.3.1 Prefix Advertisement (PA) messages format . . . . . . 18 7.3.2 PA message generation . . . . . . . . . . . . . . . . 20 7.3.3 PA message forwarding . . . . . . . . . . . . . . . . 20 7.3.4 PA message processing . . . . . . . . . . . . . . . . 21 7.3.5 Secondary Addresses Information Base Management . . . 21 7.4 MID messages . . . . . . . . . . . . . . . . . . . . . . . 22 7.4.1 MID message generation . . . . . . . . . . . . . . . . 22 7.4.2 MID message forwarding . . . . . . . . . . . . . . . . 22 7.4.3 MID message processing . . . . . . . . . . . . . . . . 22 7.5 Global IPv6 Address configuration for MANET nodes . . . . 23 7.5.1 Best Prefix Selection Algorithm . . . . . . . . . . . 24 7.5.2 Address change . . . . . . . . . . . . . . . . . . . . 25 7.6 Gateway operations . . . . . . . . . . . . . . . . . . . . 25 8. Mobile IPv6 Considerations . . . . . . . . . . . . . . . . . . 27 9. Proposed Values for Constants . . . . . . . . . . . . . . . . 28 9.1 Emission Intervals . . . . . . . . . . . . . . . . . . . . 28 9.2 Holding Time . . . . . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.1 Normative references . . . . . . . . . . . . . . . . . . . 31 12.2 Informative References . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . 36 Ruffino & Stupar Expires June 8, 2006 [Page 2] Internet-Draft Multi-GW MANET Autconfiguration December 2005 1. Introduction MANETs are wireless networks characterized by the absence of any infrastructure: nodes of a MANET function both as hosts (i.e. they are end-points of a communication) and as routers. In fact packets which can not be directly delivered between two nodes are routed through other intermediate nodes following a multi-hop path to reach their destination. Routing within a MANET is guaranteed by a routing protocol, which enables nodes calculate the optimal path that data packets must follow within the MANET itself. If the MANET is connected to an external network (e.g. the global Internet), nodes can communicate towards hosts located in such network: in this case, global connectivity has to be guaranteed, i.e. MANET nodes have to be identified by a valid IP address through which packets transmitted by hosts located outside the MANET can be received. This document presents a mechanism for automatic configuration of a topologically correct, globally valid IPv6 address on nodes in a MANET connected to the Internet through one or more gateways. The routing protocol considered in this document is Optimized Link State Routing (OLSR) [RFC3626]. With the solution presented in this document, nodes can effectively exploit all the active gateways in the MANET: a new OLSR message type is introduced, to enable gateways to announce IP prefixes within MANET. When nodes receive such prefixes, they build a set of global addresses and, in turn, advertise them to other MANET nodes. Global addresses announcement enables node to dynamically choose another valid address, among those announced, and to continue to communicate with external IP hosts, without experiencing significant delay. The node can decide to change the global address in use basically for two reasons: 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 downlink data traffic path. This document is organized as follows: Section 3 describes the reference scenario and its main features; Section 4 exposes the problem statement regarding global address configuration in the reference scenario; Section 5 outlines the proposed solution, which is detailed in Section 6 and Section 7. Ruffino & Stupar Expires June 8, 2006 [Page 3] Internet-Draft Multi-GW MANET Autconfiguration December 2005 2. Terminology Valid IPv6 Global Address An IPv6 address which is globally routable, i.e. it is topologically correct and it is reachable from all hosts and routers located in external networks (e.g. the Internet). Main Address In OLSR [RFC3626], an IPv6 address used as identifier of the node, inserted in the 'Originator Address' field in OLSR control messages. Primary Address (PADD) The identifier used by MANET nodes to partecipate to routing protocol, i.e. it is used as OLSR main address. One MANET node owns exactly one primary address, which must be configured at bootstrapping. In this proposal, such address is MANET-scoped, i.e. it is routable within the MANET only. Secondary Address (SADD) A valid IPv6 global address that can be used as IPv6 source address in datagrams transmitted from a MANET node to internal nodes or external hosts. More than one secondary address can be bound to one node's primary address. Designated Secondary Address (DSADD) A SADD used by the node to communicate with a generic host, namely an address used as IPv6 source address of transmitted packets. This address may change during the lifetime of a node. Ruffino & Stupar Expires June 8, 2006 [Page 4] Internet-Draft Multi-GW MANET Autconfiguration December 2005 3. Applicability Scenario The reference scenario to which the mechanism described in this specification applies is shown in Figure 1. In this scenario, MANETs are connected to other external networks by means of one or more gateways that provide Internet connectivity. Nodes that are not directly linked to the external network can use a multihop wireless connection to reach the gateways and forward outbound traffic. An in-depth description of such scenario can be found in [I-D.ruffino- conn-scenarios]. H1 | +---------------+ | Internet |** +---------------+ * * * * * * * GW1** * GW3 | +--GW2-------+ | | | ---N1--------+ | / \ | N4 \ N2 N3-----/ Figure 1: MANET interconnected to an external network An example of the applicability scenario can be a mobile operator cellular network extended by means of ad-hoc "clouds". In this case, mobile nodes are equipped with two interfaces, for example an UMTS interface and an IEEE 802.11g interface. The first one enables nodes to directly set-up a radio link towards the external network and receive a valid global IPv6 address, while the second one is used to participate to a MANET. This is typically achieved by running a MANET routing protocol, s.a. AODV [RFC3561], OLSR [RFC3626], TBRPF [RFC3684] and DSR [DSR]. A node located in the coverage area of the cellular network can act as gateway for the MANET: in this way, nodes that are not in the coverage area of the mobile network can use other MANET nodes to reach the gateways and forward outbound traffic. It is also assumed that gateways own one or more IPv6 prefixes which can be advertised within the MANET. The mechanism by which gateways retrieve this information is out of scope of this specification: it can be manually configured by administrators or dynamically set up, during link establishment towards the Internet, e.g. using DHCP with Prefix Delegation Option ([RFC3633]). It is also assumed that Ruffino & Stupar Expires June 8, 2006 [Page 5] Internet-Draft Multi-GW MANET Autconfiguration December 2005 different gateways advertise different prefixes, in order not to require special configuration both on gateways themselves and on Internet routers. As a consequence, traffic directed to an IPv6 address derived by one of the prefixes advertised within the MANET is univocally routed towards the gateway owning such prefix. Ruffino & Stupar Expires June 8, 2006 [Page 6] Internet-Draft Multi-GW MANET Autconfiguration December 2005 4. Problem Statement Standard configuration methods for IPv6, i.e. stateful ([RFC3315]) and stateless ([RFC2462]) IPv6 autoconfiguration, cannot be applied to MANETs, as outlined by previous work ([PERKINS], [WAKI-GLOBAL6], [I-D.singh-autoconf-adp], [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 are on the same Layer 2 link) and don't address MANET intrinsic characteristics, such as multi-hop connections, partitions and mergers. In the past, a number of solutions has been proposed, to solve automatic configuration of IPv6 addresses in a MANET and the global IPv6 connectivity problem: e.g. [WAKI-GLOBAL6], [CHA], [JELGER], [JEONG], [PAAKKONEN]. Technical issues addressed by these proposals can be summarized as follows: Bootstrapping of a node Actually, there is no standardized method enabling a node to automatically configure a unique address by means of which it can participate to the routing protocol. MANET routing protocols have been defined implicitly assuming that nodes already own a unique address configured on their MANET interface. Moreover, there is not any standard DAD mechanism for MANET, through which a node can verify the uniqueness of its address. Global Connectivity In a MANET endowed with gateways global connectivity problem arises: nodes need a valid global IPv6 address enabling them receive data traffic coming from hosts located outside the MANET. It is worth noting that in the applicability scenario, a number of technical issues arise, besides those described by previous work. In fact, gateways can freely move and they may also leave the MANET: in this case, global prefixes associated to such gateways are no more valid, as the traffic would be routed by external network routers towards a link which is no more active. As a consequence, MANET nodes using global addresses derived from such (no more valid) prefixes are no more reachable from the external network. Nodes must therefore acquire a new valid IPv6 address, derived from a valid prefix which is advertised by an available gateway. The technical issues specific to the applicability scenario described in Section 3 are the following: Ruffino & Stupar Expires June 8, 2006 [Page 7] Internet-Draft Multi-GW MANET Autconfiguration December 2005 IPv6 address change Routing protocols (e.g. OLSR) assume that each node configures on its MANET interface one address, which identifies the node itself and all its related topological information collected by routing protocol. When the node changes such address (named main address in OLSR), all topological information diffused by the node to the MANET is no more valid as it is associated to an address which is not used by any node. From the point of view of the MANET, an address change is similar to the failure of the node. Therefore, after the change of its configured address, a node will experience a period of absence of connectivity as the other MANET nodes don't own a route towards it. Such period will last until the node has transmitted enough topological information bound to its new configured address. Sub-optimal path The choice of the global address defines the path that downlink traffic coming from the Internet will follow to reach a MANET node. Indeed, external hosts will send packets to the global address used by the node: such packets will be delivered to the gateway owning the global prefix from which the global (configured) address was derived and will then follow a path connecting such gateway to the node. If a node doesn't change the global address in use as long as this is valid, the downlink path followed by (return) traffic within the MANET will always start from the same gateway. This doesn't assure that such used path is the best one, according to a predefined metric. Indeed, after a change of MANET topology, there may be a better gateway whose use optimizes download traffic reception: the node doesn't exploit such gateway as long as the global address in use is derived from another gateway's global prefix. It is a non-goal of this specification to solve application session survivability, after a node changes its global address. It is authors' belief that IETF standard method for IPv6 mobility, namely Mobile IPv6 [RFC3775], can be applied to this environment. Section 8 elaborates on this. Similarly, this specification does not propose any new Duplicate Address Detection method. A generic DAD procedure (e.g. [PERKINS]) for MANET can be used, in order to verify uniqueness of MANET-local and global addresses. Ruffino & Stupar Expires June 8, 2006 [Page 8] Internet-Draft Multi-GW MANET Autconfiguration December 2005 5. Autoconfiguration Method Overview This section gives an overview of the proposed IPv6 address autoconfiguration solution, which is specified for nodes running OLSR protocol in Section 6 and Section 7. Each node is characterized by two types of addresses: o its Primary Address (PADD), which does not change during node's life in the MANET and is independent from the prefixes announced by gateways; PADD can be, for example, an IPv6 ULA [I-D.ULA]; o one or more Secondary Addresses (SADD), built using the global prefixes announced by gateways; each node can use one of such addresses as source address of the outgoing traffic, i.e. the Designated Secondary Address (DSADD). A new OSLR message type, named Prefix Advertisements (PA), is defined, to advertise global prefixes. Gateways periodically disseminate PA messages, which contain their delegated prefixes. More details on PA messages format and processing are described in section Section 7.3. PA messages can be considered complementary to OLSR HNA (Host and Network Association) messages, whose content is used by OLSR nodes to perform gateway discovery and default route set-up. Basic operations for a generic node can be summarized as follows: o At bootstrap, node builds and configures a PADD and uses it as main address in OLSR messages. o Node participates to OLSR, sending and receiving topology information. After a transitory period, the node receives Prefix Advertisement (PA) messages from the gateways in the MANET. o It uses the prefixes, received from gateways, to build a set of global IPv6 addresses: at least, it derives an address from each received prefix (i.e. a SADD). Among them, node chooses the "best" address, corresponding to the "best" prefix, according to some method (e.g. Default Gateway method, described in Section 7.5.1), and starts using it as DSADD. Ruffino & Stupar Expires June 8, 2006 [Page 9] Internet-Draft Multi-GW MANET Autconfiguration December 2005 o Node inserts all (or a subset) of the addresses (including DSADD) built in the previous step into OLSR MID messages and starts broadcasting them. After a transitory period, all nodes own a route towards the DSADD and all the other SADDs of the node, proactively announced using MID messages. o Topological information regarding gateways announcing global prefixes is constantly monitored by node to know at any time which is the best prefix and therefore the current best global address. Such address is chosen as DSADD. As a consequence, the node changes its DSADD after one of the following events: * The gateway which advertises the prefix used by the node to derive its DSADD is no more reachable. * Node experiences a significant topological change (e.g. it moves) after which the prefix used to derive the DSADD is no more the best one. Since a node inserts into MID messages multiple SADDs, besides those which it is actually using as DSADDs, a node can transparently use a new Secondary Address without bootstrapping the routing protocol every time this happens. Indeed, the traffic destined to any of the Secondary Addresses is immediately routable within the MANET and, in particular, from the gateways to the nodes. In case the considered gateway has several associated prefixes, the node will choose one of these prefixes according to a predetermined rule, for example it may choose the first one it has received, but may also decide to configure many DSADDs (one for each prefix). Section 5.1 exposes the benefits of the solution proposed in this document and Section 5.2 gives two examples of the sequence of operations executed by a node when the proposed solution is adopted. 5.1 Advantages of the proposed method The main advantages of the proposed solution are the following: o The downlink path followed by traffic coming from external network can be optimized, with respect to the hop-count metric. This can be achieved when using a best prefix selection method that enables MANET nodes always to use as DSADD an address derived from a prefix announced by the gateway indicated as the best one by Ruffino & Stupar Expires June 8, 2006 [Page 10] Internet-Draft Multi-GW MANET Autconfiguration December 2005 routing protocol. o After changing its DSADD, a node can immedately exchange data traffic with hosts located both within and outside the MANET: no significant delay is experienced. This because the local topological information is bound to a PADD and therefore independent from the DSADD currently used. This address has been already announced with MID messages: all other MANET nodes already know the correct path to reach the node by this address. 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. 5.2 Examples of operations 5.2.1 Bootstrapping of a node This section gives an overview of the operations executed by a node N that joins a MANET for the first time (i.e. it is bootstrapping). As shown in Figure 2, the node configures its Primary Address and participates to the routing protocol, sending Hellos and TCs. The participation to the routing protocol lets the node to be informed of the network topology (Hello and TC messages), of the gateways addresses (HNA messages) and of the correspondent delegated prefixes (PA messages). HNA messages reception enables the node to choose its default gateway, which will be used to send uplink traffic, while PA messages reception enables the node to receive all the available global prefixes. Among those, it chooses the best prefix and uses it to build the DSADD, which is then configured on the interface. It builds also a set of SADDs, one for each received prefix. At this point the node is not reachable from the external network yet, as no routes towards any of its SADDs have been set up by the MANET nodes. The node starts sending MID messages containing the whole list of the SADDs. Only after MID messages diffusion, the node can receive traffic incoming from the external network (as all MANET nodes own a route to its global address) and can therefore start transmitting data to external hosts. Ruffino & Stupar Expires June 8, 2006 [Page 11] Internet-Draft Multi-GW MANET Autconfiguration December 2005 +------+ +-------+ +----+ +----------+ | N | | MANET | | GW | | Internet | +------+ +-------+ +----+ +----------+ | | | | +----------+| | | | |Configures|| | | | | PADD || | | | +----------+| | | | | Hello | | | |<----------->| | | | TC | | | |<----------->| | | | | | | | | | | +----------+| HNA | | | Receives ||<--------------------------| | |PA and HNA|| | | | | messages || PA | | +----------+|<--------------------------| | | | | | +----------+| | | | | Builds || | | | | SADD || MID | | |Configures||-------------------------->| | | DSADD || | | | +----------+| | | | | | | | |<--------------------------O--------------| +----------+ | | | Traffic | |---------------------------O------------->| | with | | external | | hosts | +----------+ Figure 2: Bootstrapping of a node 5.2.2 Gateway change In Figure 3 it is represented the message flow triggered by a node N, connected to a MANET endowed with two gateways GW1 and GW2. The Secondary Addresses built by node N are two: SADD1 (derived by gateway GW1 delegated prefix) and SADD2 (derived by gateway GW2 delegated prefix). It is assumed that the node is using SADD1 (according to a best prefix selection method not specified). It is worth noting that as soon as node N receives PA messages, it can start using SADD1 and sending MID messages at the same time. Ruffino & Stupar Expires June 8, 2006 [Page 12] Internet-Draft Multi-GW MANET Autconfiguration December 2005 After the failure of GW1, the Secondary Address SADD1 used by node N is no more valid: node N then stops using SADD1 and starts using the other globally valid Secondary Address, i.e. SADD2: all the other MANET nodes already own a route towards such address as it was inserted into MID messages generated by N, which can start a new communication towards the internet without experiencing significant delay due to the address change. Ruffino & Stupar Expires June 8, 2006 [Page 13] Internet-Draft Multi-GW MANET Autconfiguration December 2005 +-----+ +-------+ +-----+ +-----+ +----------+ | N | | MANET | | GW1 | | GW2 | | Internet | +-----+ +-------+ +-----+ +-----+ +----------+ +----------+| | | | | |Configures|| | | | | | PADD || | | | | +----------+| | | | | | Hello | | | | |<----------->| | | | | TC | | | | |<----------->| | | | | | | | | +----------+| HNA/PA | | | | Receives ||<-------------------------| | | |PA and HNA|| | | | | | messages || HNA/PA | | | +----------+|<-----------------------------------| | | | | | | +----------+| | | | | | Builds || | | | | |SADD1 and || | | | | | SADD2 || MID(SADD1,SADD2) | | | +----------+|------------------------->| | | | MID(SADD1,SADD2) | | | |----------------------------------->| | +----------+| | | | | |Configures|| | | | | | SADD1 || | | | | |as DSADD || | | | | +----------+| | | | | |<-------------------------O----------------------| |--------------------------O--------------------->| | | | | | | | +-----------+ | | | | | GW1 fails | | | | | +-----------+ | | +----------+| | | | |Configures|| | | | | SADD2 || | | | |as DSADD || | | | +----------+| | | | |<-----------------------------------O------------| |------------------------------------O----------->| | MID(SADD2) | |----------------------------------->| Figure 3: Gateway change Ruffino & Stupar Expires June 8, 2006 [Page 14] Internet-Draft Multi-GW MANET Autconfiguration December 2005 6. Data structures In this section the OLSR data structures used by the proposed solution are detailed. One of these structures, namely the Multiple Interface Association Information Base, is defined in [RFC3626]: the present specification modifies the semantics of one of its fields. 6.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. Entries of the PIB have the following structure: +--------------+----------------------------------------------------+ | Field | Data | +--------------+----------------------------------------------------+ | P_address | Primary Address of the gateway which sent the PA | | | | | P_network | A prefix owned by the gateway whose PADD is | | | specified in P_address | | | | | P_prefix_len | Length of the prefix contained in P_network field | | gth | | | | | | P_time | Validity time | +--------------+----------------------------------------------------+ Table 1: Prefix Information Base (PIB) 6.2 Delegated Prefixes Information Base Each gateway owns one or more global prefixes to be announced within the MANET. Delegated Prefix Information Base, maintained only by gateways, contains such prefixes. How the table is filled is out of scope of this specification. Prefixes contained in this table are inserted in Prefix Advertisements, sent out by gateways. Ruffino & Stupar Expires June 8, 2006 [Page 15] Internet-Draft Multi-GW MANET Autconfiguration December 2005 Entries of the Delegated Prefixes Information Base have the following structure: +--------------+----------------------------------------------------+ | Field | Data | +--------------+----------------------------------------------------+ | P_network | A prefix delegated to the gateway | | | | | P_prefix_len | Length of the prefix contained in P_network field | | gth | | +--------------+----------------------------------------------------+ Table 2: Delegated Prefixes Information Base 6.3 Secondary Addresses Information Base The Secondary Addresses Information Base (SAIB) is the set of the Secondary Addresses built by a node. It is maintained on each node and gateway. The Secondary Addresses stored by a node are those built processing Prefix Advertisements carrying global prefixes, i.e. using global prefixes contained into PIB. The refresh of its entries tightly depends on the state of the entries of PIB, as the validity of a Secondary Address is bound to the validity of the global prefix from which the Secondary Address has been derived. Entries of the Secondary Addresses Information Base have the following structure: +--------------+----------------------------------------------------+ | Field | Data | +--------------+----------------------------------------------------+ | S_Address | A valid global IPv6 address, owned by a node | +--------------+----------------------------------------------------+ Table 3: Secondary Addresses Information Base DSADD is chosen among the addresses contained into this Base, using one of the algorithms detailed in Section 7.5. 6.4 Multiple Interface Association Information Base 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 Ruffino & Stupar Expires June 8, 2006 [Page 16] Internet-Draft Multi-GW MANET Autconfiguration December 2005 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 Section 7.4, MID messages generated by a node contain the list of the Secondary 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 Secondary Addresses and Primary 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 Secondary 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]. Hence, Multiple Interface Association Information Base entries have the following semantics (same as specified in [RFC3626]): +--------------+----------------------------------------------------+ | Field | Data | +--------------+----------------------------------------------------+ | I_iface_addr | a Secondary Address built (and possibly | | | configured) by a node | | | | | I_main_addr | the Primary Address of the node which has built | | | the Secondary Address contained into I_iface_addr | | | field | | | | | I_time | Validity time | +--------------+----------------------------------------------------+ Table 4: Multiple Interface Association Information Base Ruffino & Stupar Expires June 8, 2006 [Page 17] Internet-Draft Multi-GW MANET Autconfiguration December 2005 7. Detailed operations This section gives the complete description of the operations MANET devices must execute in order to build a SADD. Procedures are detailed for nodes running OLSR ([RFC3626]), but mechanism can though be generalized for other routing protocols. 7.1 IPv6 Addresses generation An IPv6 address is obtained by a node by attaching a prefix (both local-scoped and global) to the unique 64-bit interface identifier. According to [RFC3513], this identifier can be an End-System Unique Identifier, EUI-64 identifier, e.g. derived from the MAC address of the node. In [I-D.dupont-ipv6-imei] the International Mobile Subscriber Identity of a SIM-card is used for this purpose. 7.2 Primary Address configuration At bootstrap, each node builds an IPv6 address and uses it as Primary Address (PADD), i.e. PADD is the OLSR Main Address and will be inserted into the Originator Address field of all sent OLSR messages. The PADD can be generated as described in Section 7.1 using mechanism detailed in [I-D.ULA] to obtain the prefix. It is worth noting that uniqueness of ULAs is not guaranteed, especially if they are locally generated. Therefore, PADD uniqueness MUST be verified by the configuring node, by means of one DAD method, not specified in this document. 7.3 Prefix Advertisement Prefix Advertisement messages are transmitted by gateways and contain their delegated prefixes. Such messages are received by nodes partecipating to routing protocol. 7.3.1 Prefix Advertisement (PA) messages format The new message type defined to announce the delegated prefixes associated to the MANET is shown in Figure 4 together with OLSR message header Ruffino & Stupar Expires June 8, 2006 [Page 18] Internet-Draft Multi-GW MANET Autconfiguration December 2005 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time To Live | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Reserved | +---------------------------------------------------------------+ | | | Network Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Reserved | +---------------------------------------------------------------+ | | | Network Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Format of Prefix Advertisement messages Ruffino & Stupar Expires June 8, 2006 [Page 19] Internet-Draft Multi-GW MANET Autconfiguration December 2005 Where each field of the message has the following meaning: +---------------------+---------------------------------------------+ | Field | Data | +---------------------+---------------------------------------------+ | Message Type | [TBD] | | | | | Vtime | PA_HOLD_TIME | | | | | Message Size | see [RFC3626] | | | | | Originator Address | the Primary Address of the node (gateway) | | | which generated the message | | | | | Time To Live | see [RFC3626] | | | | | Hop Count | see [RFC3626] | | | | | Message Sequence | see [RFC3626] | | Number | | | | | | 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 5: Prefix Advertisement Fields 7.3.2 PA message generation A PA message is sent by a gateway in the network to announce its delegated prefixes. I.e., the PA message contains the list of global prefixes which are associated to it. The list of prefixes can be partial in each PA message (e.g., due to message size limitations, imposed by the network), 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 Secondary Addresses. 7.3.3 PA message forwarding Upon receiving a PA message, following the rules of Section 3 of [RFC3626], the message MUST be forwarded according to Section 3.4 of [RFC3626]. Ruffino & Stupar Expires June 8, 2006 [Page 20] Internet-Draft Multi-GW MANET Autconfiguration December 2005 7.3.4 PA message processing 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: 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. Otherwise, for each (Network Address, Prefix Length) pair 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 7.3.5 Secondary Addresses Information Base Management For each (valid) prefix contained into Prefix Information Base, the node builds a Secondary Address as described in Section 7.1 and inserts it into the Secondary Address Information Base. If a t-uple contained into Prefix Information Base is removed, e.g. after P_time expiration, the Secondary Address derived from the prefix contained into the removed t-uple MUST be removed from the Secondary Address Information Base. Ruffino & Stupar Expires June 8, 2006 [Page 21] Internet-Draft Multi-GW MANET Autconfiguration December 2005 7.4 MID messages By means of standard MID messages processing, when OLSR eventually converges, the node is reachable at any of its Secondary 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. 7.4.1 MID message generation A MID message is sent by a node in the network to announce its Secondary Addresses. I.e., the MID message contains the list of the Secondary 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 Secondary 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 Secondary Addresses, chosen by a node to communicate with hosts located outside the MANET. 7.4.2 MID message forwarding Upon receiving a MID message, following the rules of section 3 of [RFC3626], the message MUST be forwarded according to section 3.4 of [RFC3626]. 7.4.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 Secondary Address listed in the MID message: Ruffino & Stupar Expires June 8, 2006 [Page 22] Internet-Draft Multi-GW MANET Autconfiguration December 2005 1. If there exist some tuple in the interface association set where: I_iface_addr == Secondary 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 = Secondary Address, I_main_addr = Originator Address, I_time = current time + validity time. 7.5 Global IPv6 Address configuration for MANET nodes A node uses one of the SADDs as its DSADD, i.e. the global IPv6 address used to exchange data traffic with other MANET nodes, as well as with external hosts. The choice of the global address must 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 topological change in the MANET. Such events have been cited in Section 5 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; Ruffino & Stupar Expires June 8, 2006 [Page 23] Internet-Draft Multi-GW MANET Autconfiguration December 2005 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. the global prefix, which the used SADD is derived from, is no more listed into PA messages and therefore is removed from Prefix Information Base: the node MUST change its global address, choosing one of the prefixes announced by active gateways. In case of 4. and 5., the node determines that its DSADD is derived from a prefix which is no more the best one, according to the the topological information it owns: in this cases, the node MAY change its DSADD, although it is still valid. A number of methods can be applied, to enable a node to choose its best prefix, among those announced by active gateways. Next section details two of such algorithms. 7.5.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. In this section two alternative algorithms are proposed. 1. Default Gateway Method: a node always selects the prefix announced by the current Default Gateway. As in this document the solution is OLSR-based, the default gateway is the closest gateway in terms of number of hops. This algorithm solves the downlink path optimization problem described in Section 4. 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 disadvantage, if MANET topology frequently changes, a node using this algorithm may experience frequent address changes, which can cause disruption of data sessions. 2. Threshold Method: a node compares the metric value of the gateway announcing the prefix currently used with that of the best gateway (normally, the default gateway); if the absolute value of the difference of the two metrics is higher than a predefined threshold, an address change is triggered; the new address is derived from the prefix announced by the best gateway. Ruffino & Stupar Expires June 8, 2006 [Page 24] Internet-Draft Multi-GW MANET Autconfiguration December 2005 Choosing one 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, how many active data sessions the node will tear down after address change. 7.5.2 Address change If an address change is triggered by one of the events listed in the previous Section, a node executes the following operations: o It stops using the SADD which was previously used as DSADD o Starts using as DSADD the SADD derived from the prefix announced by the new best gateway (this SADD has been already disseminated in the MANET using MIDs). 7.6 Gateway operations As described in Section 3, a gateway is a MANET node, equipped with a MANET interface, and a second interface, connected to the external network. Therefore, 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 addresses of their MANET interface using the mechanism specified in Section 6 and Section 7: a gateway MUST execute the operations described in these sections for MANET nodes. Gateways MUST always select the prefix contained into Delegated Prefixes Information Base to derive global addresses they will use on MANET interface. Finally, gateways MUST process PAs received from other gateways, generate SADDs and disseminate them with MIDs. As described in Section 5.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 secondary interface failure. When a gateway becomes a node, it stops generating PA messages and executes the operations described in Section 7.5.1 and Section 7.5.2. In particular, it chooses the secondary address corresponding to the best active gateway as DSADD. Ruffino & Stupar Expires June 8, 2006 [Page 25] Internet-Draft Multi-GW MANET Autconfiguration December 2005 Since the gateway has already disseminated its new global address as a SADD in MIDs, it can communicate with the hosts located outside the MANET with negligible latency. Ruffino & Stupar Expires June 8, 2006 [Page 26] Internet-Draft Multi-GW MANET Autconfiguration December 2005 8. Mobile IPv6 Considerations According to the proposed solution (Section 7.5.1), a node can change its DSADD for many reasons, e.g. in order to optimize downlink traffic coming from external hosts: generally, such address change implies active sessions interruption. In order to cope with this, Mobile IPv6 [RFC3775] can be used. It is worth noting that the reduction (ideally to zero) of the latency introduced by a DSADD change implies better performances when MANET nodes use MIPv6. In fact, if a node experiments a change from a gateway to a second gateway, then it chooses a secondary address as DSADD, 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 using the MID messages. Therefore handover latency is reduced to the time needed to send a Binding Update message and receive the correspondent Binding Acknowledge message, because routing latency is negligible. Ruffino & Stupar Expires June 8, 2006 [Page 27] Internet-Draft Multi-GW MANET Autconfiguration December 2005 9. Proposed Values for Constants 9.1 Emission Intervals PA_INTERVAL = 5 seconds MID_INTERVAL = 5 seconds 9.2 Holding Time PA_HOLD_TIME = 3 x PA_INTERVAL MID_HOLD_TIME = 3 x MID_INTERVAL Ruffino & Stupar Expires June 8, 2006 [Page 28] Internet-Draft Multi-GW MANET Autconfiguration December 2005 10. Security Considerations TBD. Ruffino & Stupar Expires June 8, 2006 [Page 29] Internet-Draft Multi-GW MANET Autconfiguration December 2005 11. IANA Considerations This document has no actions for IANA. Ruffino & Stupar Expires June 8, 2006 [Page 30] Internet-Draft Multi-GW MANET Autconfiguration December 2005 12. References 12.1 Normative references [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [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. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [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. 12.2 Informative References [4G-INT] Siebert, M., "On Ad Hoc Networks in the 4G Integration Process", Med-Hoc 2004 , June 2004. [AMBNET] "Ambient Networks", http://www.ambient-networks.org . [BELDING] Sun, Y. and E. Belding-Royer, "A study of dynamic addressing techniques in mobile ad hoc networks", I-D Wireless communication and mobile computing, May 2004. [CHA] Cha, H., Park, J., and H. Kim, "Extended Support for Global Connectivity for IPv6 Mobile Ad Hoc Networks", I-D draft-cha-manet-extended-support-globalv6-00.txt, October 2003. [DSR] Johnson, D., Maltz, D., and Y. Hu, "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", I-D draft-ietf-manet-dsr-10.txt, July 2004. [ENGELSTAD] Engelstad, P., T?sen, A., Hafslund, A., and G. Egeland, "Internet Connectivity for Multi-Homed Proactive Ad Hoc Networks", First IEEE International Conference on Sensor Ruffino & Stupar Expires June 8, 2006 [Page 31] Internet-Draft Multi-GW MANET Autconfiguration December 2005 and Ad hoc Communications and Networks , October 2004. [I-D.ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-hinden-ipv6-global-local-addr-09 (work in progress), January 2005. [I-D.dupont-ipv6-imei] Dupont, F. and L. Nuaymi, "IMEI-based universal IPv6 interface IDs", draft-dupont-ipv6-imei-08 (work in progress), October 2004. [I-D.ruffino-conn-scenarios] Ruffino, S., "Connectivity Scenarios for MANET", draft-ruffino-conn-scenarios-00 (work in progress), February 2005. [I-D.singh-autoconf-adp] Singh, S., "Ad hoc network autoconfiguration: definition and problem statement", draft-singh-autoconf-adp-00 (work in progress), February 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. [JELGER] Jelger, C., Noel, T., and A. Frey, "Gateway and address autoconfiguration for IPv6 adhoc networks", I-D draft-jelger-manet-gateway-autoconf-v6-02.txt, April 2004. [JEONG] Jeong, J., Park, J., Kim, H., and D. Kim, "Ad Hoc IP Address Autoconfiguration", I-D draft-jeong-adhoc-ip-addr-autoconf-02.txt, February 2004. [PAAKKONEN] Paakkonen, P., Rantonen, M., and J. Latvakoski, "IPv6 addressing in a heterogeneous MANET-network", I-D draft-paakkonen-addressing-htr-manet-00.txt, December 2003. [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. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. Ruffino & Stupar Expires June 8, 2006 [Page 32] Internet-Draft Multi-GW MANET Autconfiguration December 2005 [RFC2501] Corson, S. and J. Macker, "Mobile ad hoc networking (MANET): Routing protocol performance issues and evaluation considerations", RFC 2501, January 1999. [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. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [SINGH] Singh, S., Kim, JH., Choi, YG., Kang, KL., and YS. Roh, "Mobile multi-gateway support for IPv6 mobile ad hoc networks", I-D draft-singh-manet-mmg-00.txt, 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-03.txt, October 2003. [WWRF] "World Wireless Research Forum", http://www.wireless-world-research.org . [ZEROCONF] Aboba, B., "Dynamic Configuration of Link-Local IPv4 Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in progress), July 2004. Ruffino & Stupar Expires June 8, 2006 [Page 33] Internet-Draft Multi-GW MANET Autconfiguration December 2005 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 June 8, 2006 [Page 34] Internet-Draft Multi-GW MANET Autconfiguration December 2005 Appendix A. Acknowledgments The authors would like to thank Ivano Guardini for his valuable comments. Ruffino & Stupar Expires June 8, 2006 [Page 35] Internet-Draft Multi-GW MANET Autconfiguration December 2005 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 (2005). 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 June 8, 2006 [Page 36]