Internet DRAFT - draft-engelstad-manet-name-resolution
draft-engelstad-manet-name-resolution
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]
