INTERNET DRAFT Paal Engelstad Mobile Ad Hoc Networking Working Group Geir Egeland Telenor R&D/ UniK Expires August 2003 February 7. 2003 Name Resolution in on-demand MANETS and external IP Networks draft-engelstad-manet-name-resolution-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. 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 in on-demand MANETs, i.e. MANETs that are routed with a reactive routing protocol, such as DSR [DSR] or AODV [AODV]. Names that are resolved locally within the MANET will normally have preference. However, MANET nodes that have access to external networks may complement the local name resolution by injecting into the MANET addresses resolved by a conventional DNS server. The proposed solution applies equally well to IPv4 or IPv6. P. Engelstad Expires August 2003 [Page 1] Ad-hoc Name Resolution February 2003 Table of Contents 1 Introduction.....................................................2 2 Terminology......................................................3 3 Assumptions......................................................4 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...........................................6 4.5 Duplicate Response Suppression...............................7 5 Message Formats..................................................7 5.1 Name-to-Address Request (NREQ) Extension.....................7 5.2 Name-to-Address Reply (NREP) Extension.......................8 6 Protocol Parameters..............................................9 7 Further Work.....................................................9 7.1 Caching of Name-to-Address Mappings..........................9 7.2 Address-to-Name Lookups (Reverse DNS Queries)................9 8 Security Considerations..........................................9 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 on 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 MANET. Instead, MANETs call for a distributed approach to local name resolution. P. Engelstad Expires August 2003 [Page 2] Ad-hoc Name Resolution February 2003 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. 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. [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) 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-to-Address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P. Engelstad Expires August 2003 [Page 3] Ad-hoc Name Resolution February 2003 | 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-to-Address 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 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. [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 P. Engelstad Expires August 2003 [Page 4] Ad-hoc Name Resolution February 2003 [DSR], on the other hand, some changes might be required to be able to add extensions (or options) to these messages. The current version of this draft will only address æname-to- addressÆ queries. Other kinds of queries (such as 'address-to-name' queries) might be specified in a later version if deemed necessary. 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 Name-to-Address Request (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 additional broadcast to discover the route back to the originating node. The destination IP address contained in the RREQ, which indicates which address 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. When the NAME-RESOLUTION-ADDRESS is being used, additional unicast- specific properties of the reactive routing protocol might also be turned off (e.g. for AODV the destination sequence number must be set to unknown). The Name-to-Address Reply (NREP) is carried as an extension to a RREP message. The sender of the NREP will normally include its own IP address as destination IP address in the RREP message to ensure P. Engelstad Expires August 2003 [Page 5] Ad-hoc Name Resolution February 2003 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. By carrying the response in an RREP message, it 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. This fully distributed approach may later be enhanced with caching- mechanisms. Since the benefits of intermediate-node caching are unclear, this is left for further research (Section 6). 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. 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 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 [Globalv4] and [Globalv6] for proposed solutions. 4.4 Response Selection The proposed scheme resembles multicast DNS [M-DNS] 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. 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 P. Engelstad Expires August 2003 [Page 6] Ad-hoc Name Resolution February 2003 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 since the MANET node identified with the resolved name might not have had a chance to update its DNS server (e.g. by [DNS-UPDATE]) after having entered the MANET. 4.5 Duplicate Response Suppression A node that has responded to a NREQ, might receive a new NREQ for the same name and from the same originator several times in a row. The reason might be that the first NREP message got lost, and never reached the originator. Hence, the responder will have to respond to the NREQ again to ensure that the originator receives the reply. However, the reason for receiving the same NREQ over and over again might also be that the originator is not satisfied with the response. If the originator for example receives a DNS mapping for an IP address on external networks, but has no means to ensure global connectivity, the response might not be very useful, and the originator might continue the expanded ring search for a local response. In such cases, a responder should not be allowed to respond to each NREQ issued. In conclusion, the responder SHOULD NOT respond to the same Name-to- Address request (originating from the same IP source address) more than MAX-REPEATED-NREPS times within a timeframe of NREP-REPEAT- TIMEFRAME milliseconds. This mechanism allows some RREPs being lost in the network while unnecessary duplicate responses are being suppressed. 5 Message Formats 5.1 Name-to-Address Request (NREQ) 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 (Skippable) P. Engelstad Expires August 2003 [Page 7] Ad-hoc Name Resolution February 2003 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]. The last '.' is redundant and SHOULD be omitted. 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.2 Name-to-Address Reply (NREP) 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 (Skippable) 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. #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]. P. Engelstad Expires August 2003 [Page 8] Ad-hoc Name Resolution February 2003 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. 6 Protocol Parameters NAME-RESOLUTION-ADDRESS TBD NREP-COLLECTION-INTERVAL TBD MAX-REPEATED-NREPS TBD NREP-REPEAT-TIMEFRAME TBD 7 Further Work 7.1 Caching of Name-to-Address Mappings The presented fully distributed scheme may later be complemented with name servers that cache names of surrounding MANET nodes and thereby increase service availability. However, massive pro-active synchronization between name server and surrounding nodes seems to go bad together with MANET scenarios that call for reactive routing. Bad synchronization, on the other hand, may lead to a substantial amount of false positive and false negative name resolution lookups. A milder form of caching is to allow intermediate nodes cache Name- to-Address mappings appearing in NREP messages that are forwarded by the node. If receiving an NREQ message for which it has cached a mapping and a valid route to the resolved IP address, the intermediate node would return a NREP message to the source node containing the resolved IP address. If an IGW has cached a mapping, it should return an NREP based on this mapping, and it should not attempt to resolve the name over the external network. The message formats of the NREP extensions are designed to allow for a caching mechanism to be defined in the future, since they contain not only resolved IP-addresses but also the requested name. The use of such caching, however, is NOT RECOMMENDED by the current version of this draft: The benefits of such caching are unclear, and it is an issue that calls for further research. 7.2 Address-to-Name Lookups (Reverse DNS Queries) If deemed necessary, the current document may later be extended to also allow for 'address-to-name' lookups. 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 P. Engelstad Expires August 2003 [Page 9] Ad-hoc Name Resolution February 2003 scheme should probably be protected by the same mechanism, since name resolution is communicated entirely by means of extensions to routing protocol messages. IANA Considerations ... 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. [M-DNS] Cheshire, S., "Performing DNS queries via IP Multicast", draft-cheshire-dnsext-multicastdns-01.txt, December 2002, 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. [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. P. Engelstad Expires August 2003 [Page 10] Ad-hoc Name Resolution February 2003 [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. [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 Tel.: + 47 {41633776, 90640507} e-mail: {Paal.Engelstad, Geir.Egeland}@telenor.com P. Engelstad Expires August 2003 [Page 11]