LSIIT - ULP C. Jelger Internet-Draft T. Noel Expires: October 22, 2004 A. Frey LSIIT April 23, 2004 Gateway and address autoconfiguration for IPv6 adhoc networks draft-jelger-manet-gateway-autoconf-v6-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 October 22, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Adhoc networks are formed by the spontaneous collaboration of wireless nodes when no networking infrastructure is available. When communication to the Internet is desired, one or more nodes must act as gateways for the adhoc network. In this case, global addressing of adhoc nodes is required. This document specifies a protocol (node behaviour, information propagation, message format) which allows nodes in an adhoc network to discover a gateway/prefix pair which is used in order to build an IPv6 global address and, when necessary, to maintain a default route towards the Internet. Jelger, et al. Expires October 22, 2004 [Page 1] Internet-Draft Adhoc gateway/prefix autoconf April 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Summary of the protocol operation . . . . . . . . . . . . . . 4 3. Format of the GW_INFO message . . . . . . . . . . . . . . . . 6 4. Processing GW_INFO messages . . . . . . . . . . . . . . . . . 7 4.1 GW_INFO messages sent by gateways . . . . . . . . . . . . . . 7 4.2 Forwarding an updated GW_INFO message . . . . . . . . . . . . 7 4.3 Prefix continuity validation . . . . . . . . . . . . . . . . . 7 4.4 Using GW_INFO information . . . . . . . . . . . . . . . . . . 8 5. Detailed mode of operation . . . . . . . . . . . . . . . . . . 10 5.1 BOOTSTRAP alogorithms for initial upstream neighbor selection . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 REFRESH algorithms for upstream neighbor selection . . . . . . 11 5.3 Validating bi-directional links . . . . . . . . . . . . . . . 12 6. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 15 7. Protocol parameters values . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 20 Jelger, et al. Expires October 22, 2004 [Page 2] Internet-Draft Adhoc gateway/prefix autoconf April 2004 1. Introduction In contrast with current wireless networks, adhoc networks require no pre- existing infrastructure to exist. Because of the inherent limited propagation range of radio transmissions, adhoc nodes collaborate to forward (and route) packets within this spontaneous multi-hop network. Two families of protocols have been proposed by the IETF MANET working group to achieve routing in adhoc networks. Reactive protocols like [1] and [2] build routes "on-demand", i.e. only when a route to a certain destination is needed. In contrast, proactive protocols like [3] and [4] maintain an up-to- date view of the network topology and routing tables entries are updated accordingly. One of the challenge of adhoc networking is the autoconfiguration of global addresses, allowing nodes to be reachable from outside the adhoc network. To achieve this functionality, one (or possibly more) node of the adhoc network must provide connectivity to the rest of the Internet, thus acting as a gateway for the other adhoc nodes. There has been a few proposals (mainly for IP version 4) for automatic address allocation in adhoc networks, and there has also been proposals [5] which present ways of discovering a gateway. This work differs from previous work as follows. First, we combine both problems (global address configuration and gateway discovery) as done in classic wired IPv6 networks : the gateway is therefore responsible for prefix announcement. Second and in contract with some previous work, our method supports multiple gateways which may announce different global prefixes. And third, this work aims to propose a method that is independent (in terms of message semantics) of the underlying routing protocol, as our proposed method can be used with both proactive and reactive routing protocols. When multiple (different) prefixes are available, the prefix selection policy and the information propagation technique that are used both naturally leads to the concept of "prefix continuity". With prefix continuity, any node A that selected a given prefix P has at least one neighbor with prefix P on its path to the selected gateway G. The prefix continuity feature ensures that there exists, between the node A and its gateway G, a path of nodes such that each node on this path uses the same prefix P than the node A and its gateway G. Jelger, et al. Expires October 22, 2004 [Page 3] Internet-Draft Adhoc gateway/prefix autoconf April 2004 2. Summary of the protocol operation Each gateway is responsible for sending periodical information in order to notify nodes in the ad hoc network about its existence and the prefix it uses. Such information is periodically sent by each gateway in a type of message which will further be noted GW_INFO message. Each GW_INFO message contains a number of fields which allow nodes to exchange gateway information and which also allow a node to select which gateway is most appropriate if more than one gateway is available. Without going into details (they are given in sections 3 and 4), the GW_INFO message contains the global address of the gateway, the length of the prefix part of the address, a sequence number used to avoid the forwarding of obsolete information, and the distance to the gateway as perceived by the node sending the GW_INFO message. A GW_INFO message MUST be sent with a hop limit of 1. Therefore the initial GW_INFO message sent by the gateway is only received by its directly connected neighbors. If such a neighbor decides to use the information contained in the GW_INFO message, it must immediately forward an updated version of the message (as detailed in Section 4.2). The updated message MUST also be sent with a hop limit of 1. If a node receives multiple GW_INFO messages it must only forward an updated version of the message whose content has been used by this node to create (or refresh) its global address. When a given node A decides to use the GW_INFO message sent by its neighbor B, B becomes what we define as the upstream neighbor of A. The term is used throughout this document to refer to node B when node A is considered. Upon reception of a GW_INFO sent by its upstream neighbor, a node immediately forwards (to its 1-hop neighborhood) an updated version of the GW_INFO message. The prefix information contained in an initial GW_INFO message (sent by a gateway) is therefore propagated in a hop-by-hop manner among a subset of nodes of the ad hoc network which have decided to use this prefix and gateway. This method of propagation naturally leads to prefix continuity. The main advantage of prefix continuity is that routing via the gateway can be achieved without the need of an IPv6 routing header. This is detailed later in this document. The mechanisms proposed in this document (i.e. message format, prefix selection algorithms, forwarding method) can be integrated in the routing daemon itself or can run as a parallel stand-alone daemon. As described later, our proposal requires the use of a bi-directional link between a node and its upstream neighbor. If our proposal is integrated as part of the operation of a proactive routing protocol, it can benefit from the mechanisms used by such a routing protocol to maintain bi-directionnal links with its neighbors (i.e. exchange of HELLO messages). This information is mainly used by a node to ensure Jelger, et al. Expires October 22, 2004 [Page 4] Internet-Draft Adhoc gateway/prefix autoconf April 2004 that it has a bi-directional link with its upstream neighbor. In contrast, if our proposal is not integrated as part of the routing protocol operation (either proactive or reactive), or even if it is integrated into a reactive routing protocol, a specific light mechanism must be used by each node to ensure it has a bi-directional link with its upstream neighbor. This is detailed in Section 5.3. It is also here worth mentioning that, in contrast to the work proposed in [5] for AODV and in the particular case of reactive protocols, the GW_INFO information is not used to add a default route towards the gateway. We indeed believe that the reactive nature of such protocols avoids the need of keeping a default route which, by nature, prevents such a protocol from being reactive. Details about this concern are given in Section 4.4. The rest of this document is organized as such. The next section details the format of the GW_INFO message. Section 4 details the methods that should be used to send (and forward) GW_INFO messages. It also describes the method that is used by nodes in order to check prefix continuity, i.e. to detect that a node becomes isolated from other nodes using the same prefix. Section 5 defines a light mechanism that can be used to check if a link is bi- directional between two neighboring nodes. This section also details the algorithms used by a node to select and update its upstream neighbor. Jelger, et al. Expires October 22, 2004 [Page 5] Internet-Draft Adhoc gateway/prefix autoconf April 2004 3. Format of the GW_INFO message The format of the GW_INFO message used to dissemate the gateway and prefix information is shown in Figure 1. This message can be sent via control packets of a routing protocol if it is integrated as part of its operation, or via UDP packets sent to a not yet assigned port number. In both cases, The GW_INFO MUST be sent in an IPv6 packet with a hop limit of 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Length | Reserved | Neighborhood connectivity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Distance | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Gateway Global Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. GW_INFO message format Option Length : 8-bit unsigned integer. Gives the length, in bytes, of the GW_INFO message. Reserved : unused (for future use). Must be set to 0. Neighborhood connectivity : these 16 bits are used by a node to check if it has bi-directional links with its neighbors. This is detailed in Section 5.3. Prefix Length : 8-bit unsigned integer. Gives the length, in bits, of the prefix part of the gateway address given in the Gateway Global Address field. The maximum allowed value is 64 (for a /64 prefix). Distance : 8-bit unsigned integer. Gives the distance to the gateway, in hops, as perceived by the node sending the GW_INFO message. A gateway itself MUST set this field to zero. Sequence number : 16-bit unsigned integer. An integer value used to avoid the forwarding of duplicate information. Details about the use of this field are given in Section 5. Gateway Global Address : 128-bit global address of the gateway. Jelger, et al. Expires October 22, 2004 [Page 6] Internet-Draft Adhoc gateway/prefix autoconf April 2004 4. Processing GW_INFO messages Our proposed protocol strongly relies on the way by which GW_INFO messages are exchanged and processed. These messages are used by each node to select their gateway and the prefix associated to it. They are also used by each node to ensure that it is not isolated from other nodes sharing the same prefix that it decided to use, or in other words, to ensure that the prefix continuity condition is satisfied. A GW_INFO message MUST always be sent in a packet with a hop limit of 1, and the destination address of the IPv6 header of the packet containing the GW_INFO message MUST be ff02::2 (all routers). The source address of such a packet must be the link local address of the sender. 4.1 GW_INFO messages sent by gateways As described earlier, each gateway is responsible for the initial sending of periodical GW_INFO messages. Each gateway MUST send every GW_INFO_REFRESH_PERIOD a GW_INFO message. The "Distance" field of this message MUST be set to 0. Initially (e.g. after a reboot, upon restart of the daemon) the "Sequence number" field must be set to 0 by the gateway. This number must be increased by one upon each sending of a GW_INFO message. When the maximum possible value of this field is reached, the subsequent value MUST be 0. Both the "Prefix Length" field and the "Gateway Global Address" field are used to indicate the prefix that should be used by an ad hoc node to build its IPv6 global address. It is preferable if a gateway announces a / 64 prefix. 4.2 Forwarding an updated GW_INFO message Depending on the topology of the ad hoc network and on the selection algorithms used by each node to choose its upstream neighbor (the algorithms are described in sections 5.1 and 5.2), each node may receive multiple GW_INFO messages. It then selects one of its neighbor as its upstream neighbor. Each node subsequently forwards an updated version of the GW_INFO sent by its upstream neighbor. The "Distance" field of the updated GW_INFO message (say N) must be equal to the "Distance" field of the GW_INFO message (say O) sent by the upstream neighbor plus one, i.e. N.Distance = O.Distance + 1. The field "Neighborhood connectivity" must be updated according to what is described in Section 5.3. A node MUST forward an updated GW_INFO message immediately after the reception of the GW_INFO sent by its upstream neighbor. A node MUST NOT forward a GW_INFO message sent by a node that is not its upstream neighbor. 4.3 Prefix continuity validation Jelger, et al. Expires October 22, 2004 [Page 7] Internet-Draft Adhoc gateway/prefix autoconf April 2004 Each node uses all the GW_INFO messages it receives to maintain a list of its neighbors (the NEIGHBORS table) along with the prefix(es) they use. This table allows a node to check the prefix continuity condition. It is also used by the bootstrap algorithm (described in Section 5.1) which is used when a new prefix (or an initial prefix) must be chosen by a node. Upon reception of a GW_INFO message, a node must add the address of the sender of the message to its list of neighbors. The prefix information contained in the GW_INFO message must also be stored. A lifetime timer equal to NEIGH_LIFE must be associated with each new entry. If a neighbor was already in the NEIGHBORS table, the lifetime timer must be reset to NEIGH_LIFE, and the prefix information must be updated according to the information contained in the newly received GW_INFO message. For a given node, if the timer associated to its current upstream neighbor expires, the node MUST use its REFRESH algorithm to find a new upstream neighbor (see Section 5.2 on REFRESH algorithms). 4.4 Using GW_INFO information The GW_INFO received by a node from its upstream neighbor must be used by this node to create a global IPv6 address. This global address is created by adding the EUI of the interface from which the GW_INFO message has been received to the prefix P contained in the GW_INFO message. If the prefix length is smaller than 64 bits, it must be padded with zeros to reach a length equal to 64 bits. The lifetime of the address MUST be set to ADDRESS_LIFE. The lifetime of the address MUST be reset to ADDRESS_LIFE each time that the upstream neighbor of the node sends a GW_INFO message that contains the prefix P. The IPv6 duplicate address detection (DAD) procedure MUST NOT be performed, mainly because it has been designed to work on a broadcast medium, and also because there is a very low probability of address duplication when EUIs are used. With proactive routing protocols, each node MUST also add in its routing table a default entry with its upstream neighbor as next hop. The prefix continuity condition ensures that all nodes on the path to the gateway use the same prefix and have coherent default routes to reach the gateway. This feature permits to avoid the use of an IPv6 routing header. default/0 upstream_neighbor The link between a node and its upstream neighbor MUST therefore be bi- directional. If our proposed protocol is not integrated in the operation of the proactive routing protocol (in this case the state of this link can be known), a simple procedure as described in Section 5.3 MUST be used to validate the bi-directional nature of the link. This MUST be done before a node is selected as upstream Jelger, et al. Expires October 22, 2004 [Page 8] Internet-Draft Adhoc gateway/prefix autoconf April 2004 neighbor, as defined in Section 5. Note that the default route entry does not prevent direct routing between ad hoc nodes, as there should be a /128 host entry in the routing table for each ad hoc node, even for nodes that use a different prefix. With reactive routing protocols, the GW_INFO information is not used to add a default route towards the gateway. We indeed believe that the reactive nature of such protocols avoids the need of keeping a default route which, by nature, prevents such a protocol from being reactive. However, the link between a node and its upstream neighbor MUST be validated as bi-directional, by using the method described in Section 5.3. This condition ensures that there is at least one path for "route requests" sent by this node to reach the gateway it has selected to build its global address. This is crucial if the requests are for a correspondent which is outside the ad hoc network and if ingress filtering is used by other gateways. Moreover, to ensure that direct routing through the ad hoc network is always achieved between nodes with different prefixes, the route discovery procedure of the reactive routing protocol SHOULD follow a path accumulation paradigm such as the one used in [6]. Jelger, et al. Expires October 22, 2004 [Page 9] Internet-Draft Adhoc gateway/prefix autoconf April 2004 5. Detailed mode of operation This section gives a detailed description of the mode of operation of our proposed protocol. We first detail the mechanism that is used by a node to check if it has a bi-directional link with a potential upstream neighbor, i.e. a neighbor it is about to select as upstream neighbor. We then explain the bootstrap algorithm used by a node to select its initial upstream neighbor and which is also used to select a new upstream neighbor when the prefix continuity condition is broken. Third, we detail the different algorithms that can be used by a node to choose its upstream neighbor. 5.1 BOOTSTRAP alogorithms for initial upstream neighbor selection As presented in the next section, we propose a number of algorithms which are used by each node to select its upstream neighbor. These algorithms, which we call REFRESH algorithms, are used when a node already has a global address (and an upstream neighbor) and their objective is to maintain or update the selection of the upstream neighbor. Each REFRESH algorithm gives preference to a certain number of criteria. In parallel, we propose two different BOOTSTRAP algorithms, and each one is linked with the REFRESH algorithms proposed in the next section. The BOOTSTRAP algorithms are used when a node cannot find an upstream neighbor with its REFRESH algorithm. In all cases, a neighbor MUST be validated as bi-directional neighbor before being selected as an upstream neighbor (see Section 5.3). The first BOOTSTRAP algorithm which we call B_DISTANCE is very simple. It MUST be used with the REFRESH algorithms F_DISTANCE. With B_DISTANCE, a node which does not have an upstream neighbor selects, as its upstream neighbor, the first node from which it receives a GW_INFO message. The second BOOTSTRAP algorithm which we call B_NOWAIT must be used with the REFRESH algorithm F_STABILITY. With B_NOWAIT, a node A which does not have an upstream neighbor waits until it receives a GW_INFO message. Upon reception of a GW_INFO message, this node immediately chooses the sender of the GW_INFO message as its new upstream neighbor. The third BOOTSTRAP algorithm which we call B_SLOWSTART must be used with the REFRESH algorithm F_STABILITY. With B_SLOWSTART, a node A which does not have an upstream neighbor waits until it receives a GW_INFO message. Upon reception of a GW_INFO message, this node MUST wait B_STAB_WAIT_TIME and gather all the GW_INFO it receives during that period of time. If a GW_INFO message is sent by a neighbor for which node A already has a stored GW_INFO message, the old GW_INFO message MUST be replaced by the new one. When the period Jelger, et al. Expires October 22, 2004 [Page 10] Internet-Draft Adhoc gateway/prefix autoconf April 2004 B_STAB_WAIT_TIME expires, node A MUST select its upstream neighbor among the nodes from which it has received a GW_INFO message. To do so, node A proceeds as such. First, it must group the GW_INFO messages with respect to the prefix they contain. It will then selects its upstream neighbor (UN) by using the following algorithm : Group neighbors according to their prefix (a selection is always done within the remaining groups of a previous selection) For each group and among all entries within a group compute : - MIN_DIST : the smallest distance value - NB_NODES : the number of nodes in the group - AVR_DIST : the average value for all advertised distances Select group(s) with smallest MIN_DIST If more than 1 group is selected Select group(s) with highest NB_NODES If more than 1 group is selected Select group(s) with smallest AVR_DIST If more than 1 group is selected * Start a timer (2 seconds) * Choose 1st group from which a node sends a GW_INFO msg. * selects this node as UN * STOP ALGORITHM If timer expires, choose 1st sender of a GW_INFO msg. as UN Endif Endif Endif (within "winning group") * Start a timer (2 seconds) * Selects as UN the 1st node that sends a GW_INFO message If timer expires, choose 1st sender of a GW_INFO message as UN 5.2 REFRESH algorithms for upstream neighbor selection The REFRESH algorithms are used when a node already has an upstream neighbor. If a node cannot cannot find an upstream neighbor when using its REFRESH algorithm (i.e. the lifetime timer of its current upstream neighbor has expired and a new upstream neighbor cannot be selected with the REFRESH algorithm), it MUST follows the associated BOOTSTRAP algorithm until a new upstream neighbor can be found. When an upstream neighbor is found with the BOOTSTRAP algorithm, the node Jelger, et al. Expires October 22, 2004 [Page 11] Internet-Draft Adhoc gateway/prefix autoconf April 2004 MUST follow the behavior its REFRESH algorithm. Note that a lifetime timer is associated to the upstream neighbor as for any other neighbors (see Section 4.3). If this timer expires, a new upstream neighbor must be found. The most simple REFRESH algorithm is F_DISTANCE. Its associated BOOTSTRAP algorithm is B_DISTANCE. With F_DISTANCE, a node MUST try to replace its current upstream neighbor if it receives a GW_INFO message that contains a smaller "Distance" value than the one sent by its current upstream neighbor. The sender of this GW_INFO becomes a potential (new) upstream neighbor. If the link with this node is validated as bi-directional, this node becomes the upstream neighbor. With this algorithm, a node selects the prefix of one of its closest gateways. The second REFRESH algorithm is F_DISTANCE_STABILITY. Its associated BOOTSTRAP algorithms are B_SLOWSTART and B_NOWAIT. This REFRESH algorithm is similar to F_DISTANCE, with the following additional restriction : for a given node, a potential upstream neighbor MUST have the same prefix than the one in use by this node. With this algorithm, the prefix of a node remains the same as long as this node can find an upstream neighbor which uses the same prefix. The third REFRESH algorithm is F_DELAY. Its associated BOOTSTRAP algorithms are B_SLOWSTART and B_NOWAIT. F_DELAY has the same restriction than F_DISTANCE_STABILITY : for a given node, a potential upstream neighbor MUST have the same prefix than the current upstream neighbor of this node. The difference is that a potential upstream neighbor is selected as follows. If node A has an upstream neighbor that sent a GW_INFO message with "Sequence number" N and "prefix" P, it selects as a potential upstream neighbor, the first node than sends a GW_INFO message with "prefix" P, and "Sequence number" equal to (N+1) (or equal to 0 if N was equal to the maximum possible value of the "Sequence number" field). If the link to the potential upstream neighbor is validated as bi-directional, the potential upstream neighbor becomes the new upstream neighbor. 5.3 Validating bi-directional links The method described in this paragraph must be used if no other mechanism is available for a node to check if it has a bi-directional link with one of its neighbor. For example, if our proposal is integrated in the operation of a proactive routing protocol which maintains a view of its bi-directional neighbors, the following method is not required. In all other cases, the proposed method MUST be used. When a node is about to select one of its neighbor as upstream Jelger, et al. Expires October 22, 2004 [Page 12] Internet-Draft Adhoc gateway/prefix autoconf April 2004 neighbor, it must ensure it has a bi-directional link with this neighbor. This condition must be checked at regular intervals. If a node A has selected node B as a potential candidate to become its new upstream neighbor, it must assign one of the bit of the "Neighborhood connectivity" field to node B. We say that Node A assigns a "Neighbor ID" to Node B by sending a Neighbor ID message to Node B. The format of this message is shown in Figure 2. The 8-bit unsigned integer "Neighbor ID" field must be set to a value not already assigned. The maximum allowed value for this field is 15. The 8-bit unsigned integer "ACK" field must be set to 0. A specific table is used by each node to store the association Neighbor ID <--> Neighbor Address when it has been validated. This table is called the CONNECT table. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | ACK | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Neighbor ID message Node B replies to this message by also assigning a Neighbor ID to Node A. It must also acknowledge the reception of the previous message by setting the ACK field to 1. This message must also be acknowledged by Node A by sending a Neighbor ID message with the ACK field set to 1 and the "Neighbor ID" field set to the value assigned to B. Upon reception of the message sent by Node B, Node A creates an entry in its CONNECT table for Node B with its assigned Neighbor ID. This entry has a lifetime timer associated to it : it must be set to CONNECT_LIFE. Upon expiration of the timer, the entry is removed. Upon reception of the second message sent by Node A to Node B, Node B creates an entry for Node A in its CONNECT table. If Node A assigned a Neighbor ID equal to N to Node B, it will indicate in its subsequent GW_INFO messages that Node B is in its CONNECT table. To do so, Node A sets the Nth bit of the "Neighborhood connectivity" field of its GW_INFO message to 1. Because Node B knows it has been assigned the Nth bit, it can check if it is still in the CONNECT table of Node A. Upon reception of this message, Node B also reset to CONNECT_LIFE the timer associated to Node A in its CONNECT table. A similar method is used by Node B to notify Node A that it is still in its CONNECT table. If an entry with ID Y in the CONNECT table of a node expires, the Yth bit of the "Neighborhood connectivity" field of the subsequent GW_INFO messages sent by this node must be set to 0. Furthermore, if Jelger, et al. Expires October 22, 2004 [Page 13] Internet-Draft Adhoc gateway/prefix autoconf April 2004 a node C which has been assigned ID Z by Node D receives a GW_INFO message sent by node D with the Zth bit of the "Neighborhood connectivity" field set to 0, it must remove the entry associated to Node D from its CONNECT table because the link has become uni-directional. When a node performs the B_SLOWSTART algorithm, it must carry on sending GW_INFO messages otherwise its neighbors may think they have lost their link with that node. However, the node must not be chosen as upstream neighbor because it performs the B_SLOWSTART algorithm. Therefore it must send specific GW_INFO messages with a NULL gateway address (i.e. ::), a NULL prefix length and a distance value set to 255. The node must continue to use the Neighborhood Connectivity field as usual. Jelger, et al. Expires October 22, 2004 [Page 14] Internet-Draft Adhoc gateway/prefix autoconf April 2004 6. DNS considerations As an extension to the proposed protocol, DNS information could also be sent in GW_INFO messages. This would allow a node to select a gateway that also permits to reach a DNS server. The GW_INFO extension could be easily extended to include a field which contains the IPv6 global address of a DNS server, as shown in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Length | Reserved | Neighborhood connectivity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Distance | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Gateway Global Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS server Global Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Extended GW_INFO message format Jelger, et al. Expires October 22, 2004 [Page 15] Internet-Draft Adhoc gateway/prefix autoconf April 2004 7. Protocol parameters values GW_INFO_REFRESH_PERIOD 2 seconds NEIGH_LIFE LINK_LOST * GW_INFO_REFRESH_PERIOD seconds LINK_LOST 3 ADDRESS_LIFE ADDR_LOST * GW_INFO_REFRESH_PERIOD seconds ADDR_LOST 5 CONNECT_LOST 2.5 CONNECT_LIFE CONNECT_LOST * GW_INFO_REFRESH_PERIOD seconds B_STAB_WAIT_TIME 1.5 * GW_INFO_REFRESH PERIOD seconds Jelger, et al. Expires October 22, 2004 [Page 16] Internet-Draft Adhoc gateway/prefix autoconf April 2004 8. Acknowledgements The authors wish to thank Prof. Jean-Jacques Pansiot for his helpful comments and suggestions. Jelger, et al. Expires October 22, 2004 [Page 17] Internet-Draft Adhoc gateway/prefix autoconf April 2004 References [1] Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [2] Johnson, D., Maltz, D. and Y. Hu, "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", I-D draft-ietf-manet-dsr-09.txt, April 2003. [3] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [4] Ogier, R., Templin, F. and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004. [5] Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A. and A. Tuominen, "Internet Connectivity for Mobile Ad hoc networks", I-D draft-wakikawa-manet-globalv6-02.txt, November 2002. [6] Perkins, C., Belding-Royer, E. and I. Chakeres, "Internet Connectivity for Mobile Ad hoc networks", I-D draft-perkins-manet-aodvbis-00.txt, October 2003. Authors' Addresses Christophe Jelger LSIIT - Université Louis Pasteur Pôle API, bureau C429 Boulevard Sébastien Brant Illkirch 67400 FRANCE Phone: +33 390 24 45 90 EMail: jelger@dpt-info.u-strasbg.fr Thomas Noel LSIIT - Université Louis Pasteur Pôle API, bureau C428 Boulevard Sébastien Brant Illkirch 67400 FRANCE Phone: +33 390 24 45 92 EMail: noel@dpt-info.u-strasbg.fr Jelger, et al. Expires October 22, 2004 [Page 18] Internet-Draft Adhoc gateway/prefix autoconf April 2004 Arnaud Frey LSIIT - Université Louis Pasteur Pôle API, bureau C429 Boulevard Sébastien Brant Illkirch 67400 FRANCE Phone: +33 390 24 45 90 EMail: frey@clarinet.u-strasbg.fr Jelger, et al. Expires October 22, 2004 [Page 19] Internet-Draft Adhoc gateway/prefix autoconf April 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Jelger, et al. Expires October 22, 2004 [Page 20] Internet-Draft Adhoc gateway/prefix autoconf April 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jelger, et al. Expires October 22, 2004 [Page 21]