LSIIT - ULP C. Jelger Internet-Draft T. Noel Expires: February 25, 2004 LSIIT August 27, 2003 Gateway and address autoconfiguration for IPv6 adhoc networks draft-jelger-manet-gateway-autoconf-v6-00.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 February 25, 2004. Copyright Notice Copyright (C) The Internet Society (2003). 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 & Noel Expires February 25, 2004 [Page 1] Internet-Draft Adhoc gateway/prefix autoconf August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Summary of the protocol operation . . . . . . . . . . . . . 4 3. Format of the GW_INFO message . . . . . . . . . . . . . . . 6 4. Sending GW_INFO messages . . . . . . . . . . . . . . . . . . 8 4.1 Proactive protocols . . . . . . . . . . . . . . . . . . . . 8 4.2 Reactive protocols . . . . . . . . . . . . . . . . . . . . . 8 5. Detailed mode of operation . . . . . . . . . . . . . . . . . 10 5.1 Hop-by-hop propagation of GW_INFO messages . . . . . . . . . 10 5.2 Avoiding confusion after nodes movements . . . . . . . . . . 10 5.3 GW_INFO information freshness notification . . . . . . . . . 11 5.4 Algorithms and node behaviour . . . . . . . . . . . . . . . 11 5.4.1 Initial selection algorithm . . . . . . . . . . . . . . . . 12 5.4.2 Maintaining prefix and route information . . . . . . . . . . 13 6. DNS considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Protocol parameters values . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . 20 Jelger & Noel Expires February 25, 2004 [Page 2] Internet-Draft Adhoc gateway/prefix autoconf August 2003 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 previous work, our method supports multiple gateways which may announce different global prefixes. Third, our method includes some mechanisms whose aim is to avoid the propagation of false information during nodes movements. And fourth, this work aims to propose a method that is independent (in terms of message semantics) of the underlying routing protocol. Our proposed method is particularly suited to proactive protocols which maintain an up-to-date knowledge of their 1-hop neighborhood by sending periodical HELLO-like messages. While our proposed method could also be used with reactive protocols with no modifications to their operation, both its effectiveness and correctness are greatly increased if periodical HELLO-like messages are exchanged between a node and its neighbors. This can be implemented with very little overhead because nodes using a reactive routing protocol do not need to maintain a knowledge of their neighborhood. A node indeed only needs to know what prefix has been selected by each of its neighbor in order to ensure that it is not isolated from other nodes sharing the prefix it selected. This feature can either be added to the reactive protocol as part of its operation or can be implemented in a parallel stand-alone process (i.e. a daemon in networking terms). Jelger & Noel Expires February 25, 2004 [Page 3] Internet-Draft Adhoc gateway/prefix autoconf August 2003 2. Summary of the protocol operation Nodes periodically exchange gateway and prefix information with their 1-hop neighbors via packets whose content will further be noted GW_INFO messages. For proactive protocols, this message can be carried by HELLO packets which are periodically sent by a node to maintain its 1-hop neighborhood. This technique is very attractive as it allows nodes to quickly react to topological changes, for example when a node loses connectivity to its next hop neighbor towards the gateway. On the other hand, reactive protocols do not strictly use such a mechanism to maintain a view of their 1-hop neighborhood. We therefore propose that, with reactive protocols, a light mechanism MUST be added to the reactive protocol itself, or that a stand-alone process (a daemon in networking terms) MUST be run in parallel with the proactive protocol. The objective is to exchange GW_INFO messages (as detailed in sections 4 and 5) in order for a node to check the prefix used by its neighbors when multiple gateways are available : the aim is to ensure that nodes which share a common prefix always form a continuous neighborhood. The 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 Section 3), 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 refrain nodes to accept wrong information (e.g. after node movements), a 3-bit field used by a node to notify its neighbors about its perceived "freshness" of the information contained in its GW_INFO messages, and the distance to the gateway as perceived by the node sending the GW_INFO message. GW_INFO messages are sent locally with a hop limit of 1, the propagation of gateway and prefix information is therefore done in a hop-by-hop manner. Upon reception of GW_INFO messages, each node follows an algorithm to select and update both the prefix used to create a global address and the gateway used to send data to nodes outside the adhoc network. A node receives GW_INFO messages from all of its neighbors, and must therefore choose to use the information sent by one of them. The algorithm used to select the most appropriate information is detailed in another section. When a given node A decides to use the GW_INFO messages 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. The information received by a node from its upstream neighbor is used by this node to build its own GW_INFO messages. It is also here worth mentioning that, in contrast to the work Jelger & Noel Expires February 25, 2004 [Page 4] Internet-Draft Adhoc gateway/prefix autoconf August 2003 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. 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 GW_INFO messages. It also describes the method that is used by nodes using a reactive routing protocol in order to check prefix continuity, i.e. to prevent a node from being isolated from other nodes using the same prefix. Section 5 gives a detailed view of the use of GW_INFO messages and details the algorithms used by a node to select and update both its prefix and gateway. Jelger & Noel Expires February 25, 2004 [Page 5] Internet-Draft Adhoc gateway/prefix autoconf August 2003 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 is sent via an IPv6 hop-by-hop header extension. The GW_INFO MUST be sent in an IPv6 packet with a hop limit of 1. The hop-by-hop header extension is prefered because it can be used with any routing protocol. However, if the GW_INFO message is integrated within the control packets of a routing protocol (e.g. in the HELLO messages of a proactive protocol), the GW_INFO message can be added to the payload of the control packets. In that case, the two first fields (Next header and Hdr Ext Len) MUST be removed. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next header | Hdr Ext Len | Option type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Distance |G|L N K| Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Gateway Global Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. GW_INFO message format Next Header : 8-bit selector. Identifies the header following the hop-by-hop extension. This field is part of the hop-by-hop extension header format. Hdr Ext Len : 8-bit unsigned integer. Gives the length of the extension. MUST be set to 2. This field is part of the hop-by-hop extension header format. Option type : 8-bit unsigned integer. To be attributed. Specifies that the message is a GW_INFO message. Opt Data Len : 8-bit unsigned integer. MUST be set to 20. 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, Jelger & Noel Expires February 25, 2004 [Page 6] Internet-Draft Adhoc gateway/prefix autoconf August 2003 in hops, as perceived by the node sending the GW_INFO message. The gateway itself MUST set this field to zero. G bit : a gateway sending GW_INFO messages MUST set this bit to 1. This SHOULD be manually configured by the administrator of the gateway. L N K (link) 3-bit field : these 3 bits are used by a node to indicate the quality of its link towards its upstream neighbor. The detailed use of this field is given in the sections 4 and 5. Sequence number : 16-bit unsigned integer. An integer value used to avoid the wrong dissemination of GW_INFO information due to nodes movements. Details about the use of this field are given in section 5. Gateway Global Address : 128-bit global address of the gateway. Jelger & Noel Expires February 25, 2004 [Page 7] Internet-Draft Adhoc gateway/prefix autoconf August 2003 4. Sending GW_INFO messages Our proposed protocol strongly relies on the way by which GW_INFO messages are exchanged. A node indeed needs to quickly react to topological changes for two main reasons. First, a node must ensure that it is not isolated from other nodes sharing the same prefix that it decided to use. This property is known in this document as prefix continuity. Second, a node must be able to detect that it has lost connectivity with its upstream neighbor. 4.1 Proactive protocols Proactive protocols already provide a way to detect close topological changes via the periodical sending of HELLO messages. We therefore propose to use HELLO messages to send the GW_INFO information (as part of the proactive protocol operation - if this is not possible, the same method described for reactive protocols SHOULD be used). In particular and with this method, it is possible for a node to detect a loss of connectivity with one of its neighbor and to know what prefix is used by each of its neighbors. The GW_INFO message MAY be sent in each HELLO packet sent by a given node. However, to reduce the induced overhead, a node MAY only add the GW_INFO message to its HELLO packets when a new neighbor appears or when there is a change in the GW_INFO information it maintains. When the overhead reduction mechanism is used, a node SHOULD still include a GW_INFO message once every GW_INFO_MIN_REFRESH HELLO packets transmitted. In all cases with overhead reduction, a node which decides to include GW_INFO information in its upcoming HELLO packet MUST also include the (possibly updated) GW_INFO information in its next HELLO packet to prevent information loss if a packet collision/loss occurs. 4.2 Reactive protocols Reactive protocols do not (strictly) use a HELLO-like mechanism to maintain a knowledge of their neighborhood. However, our proposed method needs a periodical exchange of GW_INFO messages. A node using a reactive routing protocol MUST therefore send every GW_INFO_REFRESH_PERIOD a packet containing a GW_INFO message. The IPv6 destination address of this packet MUST be ff02::1 and the hop limit field in the IPv6 header MUST be set to 1. The IPv6 source address of such a packet SHOULD be the IPv6 link local address of the sender. This packet can be sent by the reactive protocol itself (as part of its normal operation) or it can be sent by a parallel stand-alone process (i.e. a daemon in networking terms). The same assumption applies for the reception of such packets. In the rest of this document, such a packet containing a GW_INFO message will be called a GW_INFO packet. Jelger & Noel Expires February 25, 2004 [Page 8] Internet-Draft Adhoc gateway/prefix autoconf August 2003 Each node should maintain and update a list of pairs of the form (SRC_ADDR ; PREFIX) for each GW_INFO packet received. SRC_ADDR is the source address of the IPv6 header of the GW_INFO packet and PREFIX is the IPv6 prefix contained in the GW_INFO message. This list allows a node to check if it does not become isolated from nodes which share the same prefix that it uses. Also, the periodicity introduced in the sending of GW_INFO packets allows a node to update the 3-bit "Link" field of the GW_INFO messages it sends. This is detailed in Section 5. We also believe that there is no need for a node to keep a default entry in its routing table when a reactive routing protocol is used. This is in contrast to what is proposed in [5]. Keeping a default route is somehow contradictory with the reactive nature of such protocols, i.e. a route request is started when a node cannot find a route to a destination with which it wishes to communicate. The default route prevents the route discovery procedure to happen. Moreover, the presence of a gateway is not contradictory with the reactive nature of such protocols. A node wishing to communicate with a node outside the adhoc network generates a route request and, according to these protocols, the first node with a fresh enough route can reply. In the worst case, the gateway can therefore send the route reply indicating that it has a route to the destination. Jelger & Noel Expires February 25, 2004 [Page 9] Internet-Draft Adhoc gateway/prefix autoconf August 2003 5. Detailed mode of operation This section gives a detailed description of the mode of operation of our proposed protocol. We first detail the hop-by-hop propagation of the GW_INFO information and how this information is used by a node to create a global address and (with proactive protocols) to add a default route. We then explain the use of sequence numbers to avoid the propagation of false information after nodes movements. Third, we describe the use of the "Link" field of the GW_INFO message. It is used by a node to notify its neighbors about the "freshness" of the information contained in its GW_INFO message. Finally in a fourth sub-section, we detail the algorithms used by a node to select and update its prefix and gateway information. 5.1 Hop-by-hop propagation of GW_INFO messages GW_INFO messages propagate in a hop-by-hop manner, starting from a gateway and propagating away from it. A node can receive multiple GW_INFO messages depending on the network topology and on the number of gateways in the network. A node MUST follow the algorithms described in Section 5.4 to select and update the prefix and gateway information. It MUST also use the selected information to build and send its own GW_INFO messages. In short, a node selects, among all the GW_INFO messages received within an arbitrary started GW_INFO_REFRESH_PERIOD period, the most appropriate GW_INFO message according to the algorithms described in Section 5.4. The node B which sent the GW_INFO message that has been selected by a node A becomes the upstream neighbor of A. The node A uses the information contained in the GW_INFO messages sent by node B to create and send its own GW_INFO messages. In particular, the "distance" field (d) contained in its own GW_INFO messages MUST be equal to the "distance" field (s) of the selected GW_INFO message plus one (d=s+1). This field MUST be set to zero by a gateway. Also, a node MUST use in its GW_INFO messages the same "Gateway Global Address" field as the one present in the GW_INFO message it has selected. The same rule applies for the "Prefix Length" and the "Sequence Number" fields, i.e. they are left unchanged. 5.2 Avoiding confusion after nodes movements The changing nature of the topology of an adhoc network requires that a mechanism must be used to prevent a node from accepting wrong or outdated information after nodes movements. We borrow the concept from the DSDV routing protocol [6], a distance vector protocol which uses sequence numbers to avoid the dissemination of wrong routing information. In our proposal, a gateway adds a sequence number in each of its Jelger & Noel Expires February 25, 2004 [Page 10] Internet-Draft Adhoc gateway/prefix autoconf August 2003 GW_INFO messages. This sequence number MUST be increased by one each time a GW_INFO message is sent by the gateway. When started, a gateway SHOULD use a sequence number initial value equal to zero. A node which decides to use the GW_INFO information of a given node (in order to build its own GW_INFO messages) MUST use the same sequence number (in its GW_INFO messages) as the one contained in the GW_INFO message it has selected. Each node stores the GW_INFO information in current use and, for a given gateway, can therefore compare the sequence number it has against the sequence number in received GW_INFO messages. For a given gateway, a node MUST NOT use the information contained in a GW_INFO message if the sequence number it contains is smaller or equal to the one stored by the node. The only exception to this rule is if the sequence number is equal to zero : in this case, it MUST not be compared with the stored information (if available). 5.3 GW_INFO information freshness notification In order to ease the selection procedure used by a node to choose the neighbor from which it takes the GW_INFO information, we propose to add information about the freshness of such information. GW_INFO messages are indeed sent at periodical intervals, and a node can therefore expect to receive GW_INFO messages from its upstream neighbor at fixed and known intervals. It can thus detect if it has not received an expected GW_INFO message. We propose that each node indicates in its GW_INFO messages if it has not received one or more GW_INFO messages from its upstream neighbor. The "Link" field of the GW_INFO message is used for this purpose. The 3 bits of this field have the following meaning. The K bit, when set to one, indicates that a node has not received the last expected GW_INFO from its upstream neighbor. In the following GW_INFO message sent by the node, the value of the K bit of the previous GW_INFO message sent MUST be copied to the N bit, and the value of the N bit of the previous GW_INFO message sent MUST be copied to the L bit. The K bit must be updated according to the method described above. The K bit therefore gives an "instantaneous" image of the link quality towards the upstream node, and in other terms, an idea of the freshness of the information contained in the GW_INFO message. The other two bits (N and L) reflect the evolution of the link quality. The three bits are used in the selection algorithm (detailed in Section 5.4) used by a node to choose its upstream neighbor. 5.4 Algorithms and node behaviour This section describes the selection algorithms that are to be used by a node receiving multiple GW_INFO messages in order to select the upstream neighbor. The behaviour of a node is different whether it already has a global address or not. Because no assumption can be Jelger & Noel Expires February 25, 2004 [Page 11] Internet-Draft Adhoc gateway/prefix autoconf August 2003 made on the frequency of topological changes in an adhoc network, preference is given to address stability rather than route optimization. That is, a node must not change its global address unless it has lost connectivity with other nodes sharing the same prefix. 5.4.1 Initial selection algorithm When a node does not have a global address, it should wait until it receives a GW_INFO message. Upon reception of a GW_INFO message, it SHOULD wait GW_INFO_REFRESH_PERIOD to ensure that there are no other neighbors sending GW_INFO messages. If only one GW_INFO message is received, the sender of this message is chosen as the upstream node. The information contained in the GW_INFO message is used as defined in the next paragraph. If multiple GW_INFO messages are received, the selection is done as follows. All GW_INFO messages received are grouped (in sets) according to the prefix they contain. Let d be an integer value initially set to zero. The prefix of the set that contains the most GW_INFO messages with the "distance" field equal to d is selected. If more than one set have an equal number of entries with a "distance" field equal to d, d is increased by one and the test is re-applied, but only on the sets that were in the tie. This procedure is repeated until a set can be selected. If this test does not permit to select a set, a new test must be applied to the sets that remained in the last tie. The value d is again set to zero, but this time the "Link" value is checked. The value is computed as v = K^3+N^2+L (where x^y means x to the power of y) for each GW_INFO message. For a given set and a given value of d, a value g is computed as the sum of all v values of the entries that have a "distance" equal to d. The set with the smallest value of g is selected. If a set cannot be selected, d is increased by one and the same test is re-applied to the sets that remainded in the last tie. If, after the last check, no set is selected, one must be randomly chosen among the sets remaining in the last tie. Finally and within the selected set, the entry with the smallest "Link" value among those with the smallest "distance" value is chosen. If a tie remains it is broken via a random choice. The prefix contained in the selected GW_INFO message is used to create a global address by adding the node's EUI to the prefix, as done for the link local address with the fe80::/64 prefix. Note that it is preferable if gateways announce a /64 prefix. If this not the case, the prefix must be padded with zeros until a length of /64 is reached. The normal DAD (Duplicate Address Detection) of the IPv6 protocol MUST NOT be performed, because the probability of an address collision is very low when EUI are used, and DAD is also complex to setup in an adhoc network. The information contained in the GW_INFO message (noted o) of its upstream node is also used by a node to Jelger & Noel Expires February 25, 2004 [Page 12] Internet-Draft Adhoc gateway/prefix autoconf August 2003 create its own GW_INFO message (noted n). The value of the "distance" field of n is equal to the value of the "distance" field of o plus one. The G bit of n MUST be set to zero. All other fields are left unchanged. With proactive protocols, a default route entry is also added to the node's routing table. The upstream node becomes the next hop for the default entry. default/0 upstream_node This is in contrast to the method proposed in [5] to add a default entry such as : default/0 gateway gateway/128 upstream_node The problem with the work from [5] is that it requires the possibility for the operating system to perform a double (or recursive) routing table lookup, something that is currently not implemented in modern operating systems. If this feature becomes available, this method SHOULD be prefered. 5.4.2 Maintaining prefix and route information When a node already has a global address set, it should continue to listen to updated GW_INFO messages from its neighbors. In particular, it should update its stored information (i.e. prefix, gateway address and distance), and is allowed to decide to choose a new upstream neighbor but ONLY, and only if the prefix remains identical. With proactive protocols, a change in the upstream neighbor also triggers an update in the routing table. A node decides to choose a new upstream neighbor if it receives GW_INFO messages with a smaller "distance" field than what is sent by the current upstream node, at the condition that the "Link" field is equal or better than the one in use. A node MUST choose a new upstream neighbor if it has not received LINK_LOST consecutive GW_INFO messages from its upstream neighbor. The only situation in which a node is allowed to change its prefix (and consequently its global address) is if this node loses connectivity with all its neighbors which shared the same prefix. By losing connectivity, we mean that either these nodes are not reachable (LINK_LOST consecutive GW_INFO messages are not received), or that the "Link" field of their GW_INFO messages is equal to 111 (in binary representation), which means that the node sending the GW_INFO message has lost connectivity with its upstream node. If these conditions are satisfied, a node is allowed to choose a new Jelger & Noel Expires February 25, 2004 [Page 13] Internet-Draft Adhoc gateway/prefix autoconf August 2003 upstream neighbor with a new prefix. In that case, the global address of the node MUST be changed accordingly. With proactive protocols, this also triggers an update in the routing table. The old global address MUST be removed. It is also possible to use a protocol such as Mobile IPv6 to maintain connectivity at the transport layer but this is out of the scope of thios ducument. Because of the frequent update imposed by the use of GW_INFO messages, there is no prefix lifetime value within a GW_INFO message. When a node configures a global address it SHOULD set a lifetime value at least greater than GW_INFO_REFRESH_PERIOD*LINK_LOST. However, a node which has lost connectivity with all its neighbors SHOULD remove its current global address and all GW_INFO information associated to it. Jelger & Noel Expires February 25, 2004 [Page 14] Internet-Draft Adhoc gateway/prefix autoconf August 2003 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 2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next header | Hdr Ext Len | Option type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Distance |G|L N K| Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Gateway Global Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS server Global Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Extended GW_INFO message format With this new message format, the "Hdr Ext Len" field MUST be set to 4, and the "Opt Data Len" must be set to 36. Jelger & Noel Expires February 25, 2004 [Page 15] Internet-Draft Adhoc gateway/prefix autoconf August 2003 7. Protocol parameters values GW_INFO_MIN_REFRESH 10 GW_INFO_REFRESH_PERIOD 2 seconds LINK_LOST 3 8. Acknowledgements The authors wish to thank Prof. Jean-Jacques Pansiot for his helpful comments and suggestions concerning the use of the "Link" field. Jelger & Noel Expires February 25, 2004 [Page 16] Internet-Draft Adhoc gateway/prefix autoconf August 2003 References [1] Perkins, C., Eli, 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", I-D draft-ietf-manet-olsr-11.txt, June 2003. [4] Ogier, R., Templin, F. and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", I-D draft-ietf-manet-tbrpf-10.txt, July 2003. [5] Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A. and A. Tuominen, "MIPv6 for Multiple Interfaces", I-D draft-wakikawa-manet-globalv6-02.txt, November 2002. [6] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-Sequenced Distance-Vector Routing ({DSDV}) for Mobile Computers", November 1994. 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 URI: http://www-r2.u-strasbg.fr/~jelger/ Jelger & Noel Expires February 25, 2004 [Page 17] Internet-Draft Adhoc gateway/prefix autoconf August 2003 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 URI: http://www-r2.u-strasbg.fr/~noel/ Jelger & Noel Expires February 25, 2004 [Page 18] Internet-Draft Adhoc gateway/prefix autoconf August 2003 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 (2003). 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 & Noel Expires February 25, 2004 [Page 19] Internet-Draft Adhoc gateway/prefix autoconf August 2003 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 & Noel Expires February 25, 2004 [Page 20]