INTERNET DRAFT Paal E. Engelstad Mobile Ad Hoc Networking Working Group Geir Egeland Telenor R&D Rajeev Koodli Charles E. Perkins Nokia Research Center Expires July 2004 January 2004 Name Resolution in on-demand MANETS and over external IP Networks draft-engelstad-manet-name-resolution-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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 document is an individual submission for the MANET Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mailing list manet@ietf.org. Abstract The most common user applications for data communication (including web browsing and e-mail) lack a method for name resolution in multi- hop wireless ad-hoc networks of mobile nodes (MANETs). While the Domain Name System (DNS) works well on the fixed Internet, it represents a centralized approach to name resolution, which is not suitable for MANETs. This document specifies a straightforward solution for name resolution lookup in on-demand MANETs, i.e. MANETs that are routed with a reactive routing protocol, such as DSR [DSR] or AODV [AODV]. Names are resolved locally within the MANET with a mechanism similar to multicast DNS or LLMNR on a link. Although names resolved locally normally will have preference, MANET nodes P. Engelstad Expires July 2004 [Page 1] Ad-hoc Name Resolution January 2004 that have access to external networks may complement the local name resolution by injecting into the MANET lookup results resolved by a conventional DNS server. The proposed solution applies equally well to IPv4 or IPv6. Table of Contents 1 Introduction.....................................................2 2 Terminology......................................................3 3 Assumptions......................................................5 4 Protocol Overview................................................5 4.1 On-Demand Routing Protocols..................................5 4.2 Name Resolution Requests and Replies.........................5 4.3 Interaction with External Networks...........................6 4.4 Response Selection...........................................7 5 Mandatory Message Formats........................................7 5.1 Name-to-Address Queries......................................8 5.2 Address-to-Name Queries (Reverse Lookups)....................9 6 Optional Message Formats for High Capability Networks...........10 6.1 DNS Queries.................................................10 7 Protocol Parameters.............................................11 8 Security Considerations.........................................11 1 Introduction When a user wants to communicate with an external resource, it normally prefers to identify the resource with a name (e.g. 'www.ietf.org') rather than with an IP address. Names are easier to remember, while 32-bits or 128-bits IP-addresses are normally unknown to the user. Hence, the user will not be able to communicate with the resource unless an application helps resolving the name to a corresponding IP-address. Without a name resolution method for Mobile ad-hoc networks (MANETs) in place, MANET users cannot easily use applications that are developed for fixed networks for local communication. Normally a DNS Resolver looks up a requested name and retrieves an IP-address on behalf of the user ([RFC1034], [RFC1035]). The application would then subsequently contact the counterpart directly, using the obtained IP-address. DNS takes a centralized hierarchical approach to name resolution, and is designed with the fixed Internet in mind. A centralized approach is not very suitable for name resolution on MANETs. Since MANETs lack infrastructure, some means (e.g. an election algorithm) would be required to ensure that there is always at least one name server present on the network, storing name-to- address mappings of the other MANET nodes. Furthermore, MANETs are dynamic and often exhibit non-deterministic ad-hoc behavior. With a centralized approach, MANET nodes would have no means to resolve names if the centralized name server moves out of reach of the P. Engelstad Expires July 2004 [Page 2] Ad-hoc Name Resolution January 2004 MANET. Instead, MANETs call for a distributed approach to local name resolution. The presented scheme for name resolution in on-demand MANETs applies equally well to IPv4 or IPv6. It is mainly targeted at users that can supply their MANET node with a Fully Qualified Domain Name (FQDN) from the globally unique DNS name space. The user may have control over some part of the DNS name space or may have received the FQDN from an organization that they belong to or subscribe to. A MANET node might as well use a non-unique name from the '.local.' domain [M-DNS] (for example in combination with an auto-configured link-local IPv4 address ([v4LL], [MANETv4LL]) or with a MANET-local IPv6 address. However, that might require a method to resolve potential naming conflicts, which is beyond the scope of this draft. The proposed name resolution scheme share similarities to the Link- Local Multicast Name Resolution (LLMNR) protocol for name resolution on a link [M-DNS]. The presented mechanism, however, specifies compressed message formats that allows for normal (A-record) lookup, and reverse (PTR-record) lookup, which are sufficient for most purposes [ADHOC-NR]. On a network of nodes with sufficient capabilities and of links with sufficient bandwidth, however, every node may run a minimal DNS server, and lookup can be communicated in the form of regular DNS messages [ADHOC-mDNS]. Message formats to wrap regular DNS / LLMNR messages, are also provided as an option for those networks that can afford this rather bandwidth-expensive scheme. This also allows for other types of lookups ([DNS-SRV], [ADHOC-SD]). MANETs might be connected to external networks through Internet Gateways (IGWs). An IGW is a MANET router, which also is a host or a router on an external network (with Internet connectivity). The IGW may have access to a conventional DNS server over the external network and it MAY also provide other MANET nodes with access to the external network. This draft does not assume any particular mechanism for the latter, since this is an issue still under development (e.g. [GW-DISC-1], [GW-DISC-2], [Globalv4] and [Globalv6]). Since IGWs may have access to a conventional DNS servers over the external network, the name resolution protocol for MANETs should interoperate with DNS so that it can resolve both local names and names from the conventional DNS system simultaneously. 2 Terminology This document borrows terminology from [AODV] and [DSR]. In addition: Route Request (RREQ) P. Engelstad Expires July 2004 [Page 3] Ad-hoc Name Resolution January 2004 A RREQ is a routing message that an originator broadcasts to discover a route to a destination node. RREQ allows the destination to discover a reverse path to the originator. Route Reply (RREP) A RREP is a routing message that a destination node or an intermediate node unicasts back to the source node in reply to a RREQ. RREP allows the source to discover a forward path to the destination. Name Resolution Request (NREQ) A NREQ is a name resolution request that is always carried as an extension to a RREQ. For AODV this extension will be in a Type- Length-Value format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREQ | +---------------------------------------------------------------+ | Type | Length | NREQ Payload . . . . +---------------------------------------------------------------+ By using a RREQ header a reverse unicast route back to the originator is already in place for nodes that can respond to the NREQ. (Total bandwidth overhead is reduced since a route has already been established. Name Resolution Reply (NREP) A NREP is a name resolution reply that is always carried as an extension to a RREP. For AODV this extension will be in a Type- Length-Value format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREP | +---------------------------------------------------------------+ | Type | Length | NREP Payload . . . +---------------------------------------------------------------+ By using a RREP header a forward unicast route from the originator to the node that resolved the IP address is already in place for subsequent communication. Originator P. Engelstad Expires July 2004 [Page 4] Ad-hoc Name Resolution January 2004 In a discovery process the originator is the MANET node that broadcasts the RREQ (with or without an NREQ). Internet Gateway (IGW) This is a (possibly mobile) MANET router, which also is a host or a router on an external network with Internet connectivity. The IGW may have access to a conventional DNS server over the external network and it may provide other MANET nodes with access to the external network. This draft does not assume any particular mechanism for the latter, since this is an issue still under development (e.g. [GW-DISC-1], [GW-DISC-2], [Globalv4] and [Globalv6]). 3 Assumptions This document assumes that RREQ and RREP messages of the reactive routing protocol can carry additional extension encoded in a Type- Length-Value (TLV) format. This is the case for AODV [AODV]. For DSR [DSR], on the other hand, some changes might be required to be able to add extensions (or options) to these messages. 4 Protocol Overview 4.1 On-Demand Routing Protocols The proposed scheme for name resolution is designed for on-demand MANETs (i.e. MANETs routed by a reactive routing protocol, such as AODV [AODV] or DSR [DSR]) where route detection is performed as follows: A source node broadcasts/floods a RREQ containing the IP address of the requested destination node. If the RREQ reaches the node that is identified by the destination IP address (or an intermediate node with a valid route to the destination), that node responds with a RREP. Since the RREQ formed a reverse route, the RREP can be unicasted back to the originator. The RREP will form a forward route that allows the originator to unicast subsequent IP packets to the destination. 4.2 Name Resolution Requests and Replies On a dynamic MANET, name resolution cannot rely on only one centralized name server. Instead a NREQ should be broadcasted throughout the MANET. Each MANET node with a discoverable name MUST process the request, as it is flooded throughout the network. To reduce the number of broadcasts required for name resolution, the NREQ is carried as an extension to an RREQ. Hence, a return unicast route to the originator of the request is already in place for a node that wants to respond to the NREQ. If the NREQ were not carried by a RREQ message, the responding node would have to issue an P. Engelstad Expires July 2004 [Page 5] Ad-hoc Name Resolution January 2004 additional broadcast to discover the route back to the originating node. The destination IP address contained in the RREQ, which indicates the address to which a route is searched for, MUST be set to a pre- defined value, NAME-RESOLUTION-ADDRESS. This can be a zero-address, a broadcast address or a pre-assigned multicast-address to which no node can cache a route. Hence, intermediate nodes without a valid address mapping for the requested name MUST NOT respond to the RREQ. For AODV the Unknown Destination Sequence Number flag MUST be set to 1, and the destination sequence number MUST be set to zero. The NREP is carried as an extension to an RREP message. The sender of the NREP will normally include its own IP address as destination IP address in the RREP message to ensure that a forward route is formed. In many instances the node that responds to the NREQ is the node identified with the name that is searched for. If this is the case and AODV is the routing protocol, the responding node MUST include its current non-zero destination sequence number in the RREP it sends. By carrying the response in an RREP message, a responder that is identified by the name that is searched for can supply the originator with both the resolved IP address and a unicast route to that IP-address. Hence, the originator does not have to issue an additional broadcast to discover a route to the resolved address when it subsequently tries to contact that address. Each MANET node with a discoverable name SHOULD respond to an NREQ message with the discoverable name in the Name field. Furthermore, other MANET nodes, except for IGWs, which is not identified with the name requested for in the Name field, MUST NOT respond to the NREQ. 4.3 Interaction with External Networks When an Internet Gateway (IGW) receives an NREQ it SHOULD try to resolve the requested name by a conventional DNS server through the external network to which it is connected. After having successfully resolved the name, it returns to the originator an NREP containing the resolved IP address(es), thus acting as a DNS proxy. The gateway MUST resolve names to IPv4 addresses if the MANET runs IPv4, or to IPv6 if the MANET runs IPv6. If the name is resolved to multiple addresses, the gateway MAY return only a subset of these addresses in the NREP. If DNS resolves a name into a number of different IP-addresses, the IGW MUST prioritize IP-addresses that are assumed to be present on the MANET (e.g. if the IGW has cached a valid route to that address). The presented mechanism for name resolution on MANETs does not hinder a node to also acquire an IP-address of a conventional DNS server on an external network (by some means that are beyond the scope of the current version of this draft). This node MAY try to P. Engelstad Expires July 2004 [Page 6] Ad-hoc Name Resolution January 2004 resolve a name on this server if name resolution locally on the MANET fails. However, many nodes might not have straightforward access to an external network, and may therefore not be able to utilize this option. It is thus assumed that using an IGW as a DNS- proxy will be sufficient in most scenarios. The details of how to ensure global connectivity are beyond the scope of this document, and the reader is referred to [GW-DISC-1], [GW-DISC-2], [Globalv4] and [Globalv6] for proposed solutions. 4.4 Response Selection The proposed scheme resembles Link-Local Multicast Name Resolution [LLMNR] in that an originator of a NREQ might receive a number of NREPs from different responders. Hence, the originator should wait for NREP-COLLECTION-INTERVAL milliseconds to collect responses that might arrive. With AODV, a MANET node will include a non-zero sequence number in the RREP carrying a mapping for its own name to its own address. Hence, the routing system will always give preference to an NREP returned from a MANET node present locally on the MANET over an NREP returned from a gateway (since the latter will contain a zero destination sequence number). If the originator receives an NREP where the resolved IP address is equal to the destination IP address of the RREP header, it MUST assume that the address was resolved locally. On the contrary, if the originator receives an NREP where the resolved IP address is not equal to the destination IP address of the RREP header, it SHOULD assume that the address was resolved by an IGW over an external network. The detailed procedures for handling multiple responses and selecting a resolved IP address is implementation-specific and outside the scope of this document. However, if the originator receives responses from both the external DNS system and locally, it SHOULD prioritize responses arriving from the local MANET. Hence, a direct route through the MANET will have preference compared to a route that goes through external networks. Furthermore, a local response might be more reliable and up-to-date. If the name is resolved to multiple addresses that are all present on the MANET, the originator SHOULD select an IP-address to which it has a route that is preferred by the routing protocol. That is, it will normally select from the IP-addresses to which it has valid routes and select the IP-address that is fewest hops away from the originator. 5 Mandatory Message Formats P. Engelstad Expires July 2004 [Page 7] Ad-hoc Name Resolution January 2004 5.1 Name-to-Address Queries 5.1.1 Name-to-Address Request Extension The format of the Name-to-Address Request Extension is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Length of extension in terms of bytes (octets), excluding the length of the Type and Length fields. Name A Fully Qualified Domain Name encoded with the UTF-8 format [UTF-8]. This extension must only be used in RREQ messages. A node that has a discoverable name MUST process this extension. The extension is skippable, i.e. nodes that do not implement the presented name resolution mechanism MUST NOT process this extension. 5.1.2 Name-to-Address Reply Extension The format of the Name-to-Address Reply Extension is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | #Addrs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP Address 1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP Address N : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... +-+-+-+-+-+-+-+-+-+-+-+-... Type TBD Length Length of extension in terms of bytes (octets), excluding the length of the Type and Length fields Reserved Reserved field for future use. All bits MUST be set to zero. P. Engelstad Expires July 2004 [Page 8] Ad-hoc Name Resolution January 2004 #Addrs The number of resolved IP addresses returned in this extension. IP Address An IP address that corresponds to the name found in the Name field. The Protocol Version field of the IP header of the RREP determines whether this extension contains only IPv4 addresses (of 4 bytes each) or only IPv6 addresses (of 16 bytes each). Name A Fully Qualified Domain Name encoded with the UTF-8 format [UTF-8]. This extension must only be used in RREP messages sent as a reply to a Name-to-Address Request extension received in a RREQ message. The extension is skippable, i.e. nodes that do not implement the presented name resolution mechanism MUST NOT process this extension. 5.2 Address-to-Name Queries (Reverse Lookups) 5.2.1 Address-to-Name Request Extension The format of the Address-to-Name Request Extension is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Length of extension in terms of bytes (octets), excluding the length of the Type and Length fields. Reserved Reserved field for future use. All bits MUST be set to zero. IP Address An IP address that the originator wants to resolve to a name. The Protocol Version field of the IP header of the RREP determines whether this extension contains only IPv4 addresses (of 4 bytes each) or only IPv6 addresses (of 16 bytes each). The extension is skippable, i.e. nodes that do not implement the presented name resolution mechanism MUST NOT process this extension. P. Engelstad Expires July 2004 [Page 9] Ad-hoc Name Resolution January 2004 5.2.2 Address-to-Name Reply Extension The format of the Address-to-Name Reply Extension is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... +-+-+-+-+-+-+-+-+-+-+-+-... Type TBD Length Length of extension in terms of bytes (octets), excluding the length of the Type and Length fields Reserved Reserved field for future use. All bits MUST be set to zero. IP Address An IP address that corresponds to the name found in the Name field. The Protocol Version field of the IP header of the RREP determines whether this extension contains only IPv4 addresses (of 4 bytes each) or only IPv6 addresses (of 16 bytes each). Name A Fully Qualified Domain Name encoded with the UTF-8 format [UTF-8]. This extension must only be used in RREP messages sent as a reply to a Address-to-Name Request extension received in a RREQ message. The extension is skippable, i.e. nodes that do not implement the presented name resolution mechanism MUST NOT process this extension. 6 Optional Message Formats for High Capability Networks 6.1 DNS Queries 6.1.1 DNS Request Extension The format of the DNS Request Extension is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | DNS message ... P. Engelstad Expires July 2004 [Page 10] Ad-hoc Name Resolution January 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Length of extension in terms of bytes (octets), excluding the length of the Type and Length fields. DNS message A query in the form of a DNS Query. This extension must only be used in RREQ messages. A node that runs a DNS-server MUST process this extension. The extension is skippable, i.e. nodes that do not implement the presented name resolution mechanism MUST NOT process this extension. 6.1.2 DNS Reply Extension The format of the DNS Reply Extension is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | DNS message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Length of extension in terms of bytes (octets), excluding the length of the Type and Length fields. DNS message A response to a query in the form of a DNS Response. This extension must only be used in RREP messages sent as a reply to a DNS Request extension received in a RREQ message. The extension is skippable, i.e. nodes that do not implement the presented name resolution mechanism MUST NOT process this extension. 7 Protocol Parameters NAME-RESOLUTION-ADDRESS IPv4 or IPv6 Zero-address NREP-COLLECTION-INTERVAL TBD 8 Security Considerations This document does not provide a mechanism to secure the integrity of name resolution messages. The reactive routing protocol should have means to ensure integrity of the routing path between source and destination. The integrity of the proposed name resolution scheme should probably be protected by the same mechanism, since P. Engelstad Expires July 2004 [Page 11] Ad-hoc Name Resolution January 2004 name resolution is communicated entirely by means of extensions to routing protocol messages. References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, Internet Engineering Task Force, November 1987. [RFC1035] Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, Internet Engineering Task Force, November 1987. [LLMNR] Esibov, L., Aboba, B. and Thaler, D., "Linklocal Multicast Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-21.txt, June 2003, Work in Progress. [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", draft-ietf-zeroconf-ipv4-linklocal-07.txt, August 2002, Work in Progress. [MANETv4LL] Perkins et al., "IPv4 Address Autoconfiguration for Ad Hoc Networks", draft-ietf-manet-autoconf-01.txt, November 2001, Work in Progress. [ADHOC-NR] Engelstad,P.E., Thanh,D.V., Egeland, G., "Name Resolution in On-Demand MANETs and over External IP Networks", Proceedings of IEEE Int. conf. on Comm. 2003 (ICC 2003). http://www.unik.no/~paalee/publications/NR-paper-for- ICC2003.pdf [ADHOC-mDNS] Engelstad,P.E., Thanh,D.V., J°nvik,T.E., "Name Resolution in Mobile Ad-hoc Networks", Proceedings of 10th Int. Conf. on Telecom. 2003 (ICT 2003). http://www.unik.no/~paalee/ publications/NR-paper-for-ICT2003.pdf [DNS-SRV] Gulbrandsen, A., Vixie, P., Esibov, L., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, Internet Engineering Task Force, February 2000. [ADHOC-SD] Engelstad et al., "Service Discovery and Name Resolution Architectures in On-Demand MANETs", Proceedings of 2003 Workshop on Mobile Wireless Networks (MWN 2003). http://www.unik.no/~paalee/publications/NR-paper-for- MWN2003.pdf [GW-DISC-1] Engelstad, P.E. and Egeland, G., "Analysis of Explicit Gateway Discovery for IPv4 On-Demand Ad Hoc Networks", Proceedings of WONS 2004, LNCS2928, Springer, January 2004, pp. 342-356. http://www.unik.no/~paalee/publications/XA-paper-for- WONS2004.pdf P. Engelstad Expires July 2004 [Page 12] Ad-hoc Name Resolution January 2004 [GW-DISC-2] Engelstad, P.E., Egeland, G., Thanh, V.D., "Explicit Gateway Discovery for IPv4 On-Demand Ad Hoc Networks", Proceedings of CNDS 2004, January 2004. http://www.unik.no/~paalee/publications/XA-paper-for- CNDS2004.pdf [GLOBALv4] Royer et al., "Global connectivity for IPv4 Mobile Ad Hoc Networks", draft-royer-manet-globalv4-00.txt, November 2001, Work in Progress. [GLOBALv6] Wakikawa et al., "Global connectivity for IPv6 Mobile Ad Hoc Networks", draft-wakikawa-manet-globalv6-02.txt, November 2002, Work in Progress. [AODV] Perkins, C.E., Belding-Royer, E.M., Das, S.R., "Ad hoc On- Demand Distance Vector (AODV) Routing", draft-ietf-manet- aodv-12.txt, November 2002, Work in Progress. [DSR] Johnson, D.B., Maltz, D.A., Hu, J.-C., Jetcheva, J.G., "The Dynamic Source Routing Protocol", draft-ietf-manet- dsr-07.txt, February 2002, Work in Progress. [DNS-UPDATE] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, Internet Engineering Task Force, November 2000. [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2044, Internet Engineering Task Force, January 1998. Authors' Addresses {Paal E. Engelstad, Geir Egeland} Telenor R&D Snar°yvn. 30 1331 Fornebu, Norway EMail: {Paal.Engelstad, Geir.Egeland}@telenor.com Phone: +47- {41633776, 90640507} Fax: +47-67891812 {Rajeev Koodli, Charles E. Perkins} Communications Systems Lab, Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043, USA EMail: {rajeev.koodli@nokia.com, charliep@iprg.nokia.com} Phone: +1-650 625- {2359, 2986} Fax: +1-650 625-2502 P. Engelstad Expires July 2004 [Page 13]