One document matched: draft-jeong-manet-dns-service-00.txt
Internet Draft
Jaehoon Paul Jeong
Jungsoo Park
Hyoungjun Kim
ETRI
<draft-jeong-manet-dns-service-00.txt>
Expires: July 2004 9 February 2004
DNS Service for Mobile Ad Hoc Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted [1].
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.
Abstract
This document specifies an architecture of DNS service system for
mobile ad hoc network which might be connected to the Internet. The
resolution of DNS names of mobile nodes within mobile ad hoc network
is performed by multicast DNS and that of DNS names of nodes in the
Internet is performed through DNS autoconfiguration of recursive DNS
server. In the former, each mobile node plays a role of DNS name
server for the DNS resource records associated with DNS name of which
authority it has. The latter allows mobile node to receive the
global Internet service, such as web service, by providing global DNS
resolution in mobile ad hoc network connected to the Internet. These
two kinds of DNS name resolution are processed automatically without
the intervention of users in mobile ad hoc network. Also, this
Jeong, et al. Expires - July 2004 [Page 1]
Internet-Draft MANET DNS Service February 2004
document specifies how to authenticate DNS message as well as how to
provide ad hoc users with service discovery based on multicast DNS.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
Table of Contents
1. Terminology...................................................2
2. Introduction..................................................2
3. Overview......................................................3
4. DNS Operations in ANS System..................................5
4.1 ANS Responder.............................................5
4.2 ANS Resolver..............................................5
4.3 ANS API...................................................7
5. Generation of DNS Zone File...................................7
6. Service Discovery.............................................8
7. Global DNS Service in MANET connected to the Internet.........8
8. IPv6 Considerations...........................................8
9. Configuration Parameters......................................9
10. Security Considerations......................................9
10.1 Message Authentication through TSIG......................9
11. Copyright....................................................9
12. Normative References........................................10
13. Informative References......................................10
14. Authors' Addresses..........................................11
1. Terminology
This document uses the terminology described in [3]. In addition,
two new terms are defined below:
Mobile Ad Hoc Network (MANET)
The network where mobile nodes can communicate with one another
without preexisting communication infrastructure, such as base
station or access point.
Ad Hoc Name Service System (ANS)
The name service system that provides DNS name resolution and
service discovery in MANET connected to the Internet.
2. Introduction
Jeong, et al. Expires - July 2004 [Page 2]
Internet-Draft MANET DNS Service February 2004
When mobile nodes want to communicate with one another in MANET
environments such as battle field and public vehicle (e.g., airplane,
bus and boat), they need to construct a temporary and
infrastructureless network. Recently, according as the necessity of
MANET increases, Ad Hoc routing protocols for multi-hop MANET have
been being developed actively. Also, Ad Hoc multicast routing
protocols as well as ad hoc unicast routing protocols have been being
developed and implemented to provide mobile users in MANET with
multicast service such as video conference and computer-supported
collaborative work (CSCW). For the deployment of MANET technology,
the global connectivity for MANET has been being researched, of which
object is to support the communication between the mobile ad hoc node
and Internet node [3].
DNS is one of the most popular applications in the Internet. It
provides the name-to-address resolution among nodes in the Internet.
DNS must also be a necessity of MANET but the current DNS is
inappropriate to MANET that has dynamic topology because the current
DNS works on the basis of dedicated and fixed DNS name servers.
Therefore, a new DNS architecture appropriate to this MANET, where
there is no dedicated DNS server and the network is multi-hop, became
necessary [4].
This document specifies an architecture of name service system which
can provide mobile nodes in MANET with the name-to-address resolution
and autoconfiguration technology for easy configuration related to IP
address autoconfiguration [5] and name service, such as the
generation of zone file for name service. It also describes service
discovery performed through the name service system of this document
and DNS service resource record (SRV) [6]. This service discovery
mechanism provides ad hoc user with the information of a service with
the specified transport protocol (TCP or UDP) that is needed for the
connection to the service in MANET, such as IP address and port
number. The name service system allows mobile node within MANET
connected to the Internet via Internet gateway to resolve DNS name of
Internet node into global IP address and the mobile node to
communicate with the Internet node via Internet gateway. For the
authentication of DNS messages, this document specifies a mechanism
of DNS authentication based on TSIG resource record [7].
3. Overview
ANS is the name service system that provides the name resolution and
service discovery in MANET which is multi-hop. The IP address for
the network device of each mobile node is configured by Ad Hoc IP
address autoconfiguration or by manual configuration [5]. ANS System
consists of ANS Responder that works as DNS name server in MANET and
ANS Resolver that performs the role of DNS resolver for name-to-
Jeong, et al. Expires - July 2004 [Page 3]
Internet-Draft MANET DNS Service February 2004
address translation. Figure 1 shows DNS name resolution through ANS
System in MANET, consisting of three mobile nodes; that is, Node A,
Node B and Node C. Each mobile node runs ANS Responder and Resolver.
An application on mobile node that needs the name resolution can
receive the name service through ANS Resolver because ANS provides
the applications with the library functions for name resolution, ANS
API, through which they can communicate with ANS Resolver.
+-------+ +-------+
|Node A | |Node B |
+-------+ +-------+
| . DNS Query |
| ..........................>|
-------------------.------------------
|.
|V
+-------+
|Node C |
+-------+
Figure 1. Multicasting of DNS Query Message for Name Resolution
+-------+ +-------+
|Node A | |Node B |
+-------+ +-------+
| DNS Response |
| <............. |
-------------------.------------------
|.
|.
+-------+
|Node C |
+-------+
Figure 2. Unicasting of DNS Response Message for Name Resolution
ANS Resolver sends DNS query message for a host DNS name in a
multicast address for ANS name service, ANS_MULTICAST_IPV4_ADDRESS,
which ANS Responder in each mobile node MUST join for DNS name
service [3]. When ANS Responder receives DNS query from ANS Resolver
in other mobile nodes, after checking if it is responsible for the
query, it decides to respond to the query. When it is responsible
for the query, it sends an appropriate response message to ANS
Resolver in unicast. In Figure 1 and 2, Node A sends in multicast a
DNS Query message for resolving a host DNS name into IP address and
Jeong, et al. Expires - July 2004 [Page 4]
Internet-Draft MANET DNS Service February 2004
Node C responds to the query with a DNS Response message, which is
responsible for the DNS name queried by Node A.
4. DNS Operations in ANS System
4.1 ANS Responder
ANS Responder plays the role of DNS name server, operating in eight
steps as follows;
Step (a) : ANS Responder starts.
Step (b) : ANS Responder generates a DNS zone file for name service.
Step (c) : ANS Responder loads resource records of the zone file into
ANS Zone DB.
Step (d) : ANS Responder verifies the uniqueness of the resource
records related to each domain name through dynamic update
request (DUR) [3]. DUR query message is sent in multicast
with destination address set to ANS_MULTICAST_IPV4_ADDRESS.
Step (e) : ANS Responder joins ANS multicast group,
ANS_MULTICAST_IPV4_ADDRESS in order to receive DNS query
messages from other mobile nodes.
Step (f) : ANS Responder waits for DNS message.
Step (g) : When ANS Responder receives a DNS message, it checks if
the message is a DNS query.
Step (h) : If the DNS message is a query, ANS Responder processes the
query and sends the response to ANS Resolver that sent the
query and goes to Step (f). If the DNS message is a
response of which the name belongs to this node, ANS
Responder performs the dynamic update request to verify
the uniqueness of the resource record related to the name
like in [3]. If ANS Responder finds the name conflict
through the dynamic update request, it invalidates the
resource record corresponding to the duplicate name in its
ANS Zone DB. After performing the dynamic update request,
ANS Responder goes to Step (f).
4.2 ANS Resolver
ANS Resolver performs the name resolution request received from user
application via ANS API, operating in twelve steps as follows;
Jeong, et al. Expires - July 2004 [Page 5]
Internet-Draft MANET DNS Service February 2004
Step (a) : ANS Resolver starts.
Step (b) : ANS Resolver waits for the request of name resolution from
an application via ANS API on the same node.
Step (c) : When ANS Resolver receives the resolution request, it
checks first if there is the result of the request in ANS
Cache.
Step (d) : If there is already the result of the request in ANS Cache,
ANS Resolver passes the result to the application and goes
to Step (b). Unless there is the result of the request in
ANS Cache, it goes Step (e).
Step (e) : ANS Resolver generates a DNS query message.
Step (f) : ANS Resolver sends the DNS query message in multicast with
destination address set to ANS_MULTICAST_IPV4_ADDRESS.
Step (g) : ANS Resolver starts a query timer.
Step (h) : ANS Resolver waits for a DNS response message until the
query timer expires.
Step (i) : If the query timer expires or a DNS response message
arrives, ANS Resolver checks what the event is. If the
event is the timer expiration, it goes to Step (j).
Otherwise, it goes to Step (k).
Step (j) : ANS Resolver checks whether the number of retransmission
of query message is less than or equal to the allowed
maximum number of retransmission (MAX_RETRANS) and. If
the number of retransmission of query message
(Num_Retrans) is greater than MAX_RETRANS, ANS Resolver
returns the error message to the application via ANS API
and goes to Step (b). Otherwise, it goes to Step (f).
Step (k) : ANS Resolver checks if the response is valid. If the
response is valid, it goes to Step (l). Otherwise, it
discards the response and checks Num_Retrans. If
Num_Retrans is greater than MAX_RETRANS, ANS Resolver
returns the error message to the application via ANS API
and goes to Step (b). Otherwise, it goes to Step (h).
Step (l) : If ANS Resolver has received multiple valid response
messages from other ANS Responders, it sends the first
response to every ANS Responder that sent a response
except the ANS Responder that has sent the response first.
Jeong, et al. Expires - July 2004 [Page 6]
Internet-Draft MANET DNS Service February 2004
This triggers dynamic update request at each ANS Responder
that receives this response message, allowing each ANS
Responder to check the duplication of a DNS resource
record. After this, ANS Resolver stores the response in
ANS Cache, passes the response to the application via ANS
API and goes to Step (b). If ANS Resolver received only
one valid response, it stores the response in ANS Cache,
passes the response to the application via ANS API and
goes to Step (b).
4.3 ANS API
ANS API allows a user application to use ANS Resolver for resolving
DNS name. A user application calls ANS API function,
ans_getaddrinfo() as follow;
/* ANS API function */
int ans_getaddrinfo(char* node, u_short family, struct
ans_addrinfo** res);
//node: contain DNS name
//family: indicate IP version
//res: store the result of DNS name resolution, i.e., IP address
/* structure for name resolution */
struct ans_addrinfo
{
int ai_flags; //indicate if resolution is from name to address
/* 0 : no resolution, 1 : resolution from name to address */
int ai_family; //IP version
size_t ai_addrlen; //length of socket address, ai_addr, in bytes
struct sockaddr* ai_addr; //IP address
char* ai_canonname; //domain name
};
5. Generation of DNS Zone File
ANS Responder needs a file for storing host DNS name, Host Name File.
Host DNS name consists of user id and MANET_DOMAIN; for example, when
user id is "paul", host DNS name is "paul.manet.".
When ANS Responder starts for DNS service, it generates its DNS zone
file, called ANS Zone File, which contains DNS resource record(s) of
A or AAAA type by combining its DNS name and IP address with its
Host Name File. The autoconfiguration of DNS zone file allows ad hoc
Jeong, et al. Expires - July 2004 [Page 7]
Internet-Draft MANET DNS Service February 2004
user easily to configure DNS resource records for its DNS name. That
is to say, the user only registers its DNS name with ANS Responder's
Host Name File. This autoconfiguration becomes more useful when IP
address autoconfiguration is used together [5].
6. Service Discovery
Service discovery allows ad hoc users to discover the service
information that is necessary to connect to the service when the
service name, transport protocol (e.g., TCP or UDP) and domain where
the service is placed are given. With DNS SRV resource record [6],
ANS can provide service discovery. It is assumed that mobile node
running unicast services should register a DNS SRV resource record
for each service with its ANS Zone File.
7. Global DNS Service in MANET connected to the Internet
When a mobile node in MANET connects to a web server in the Internet,
it needs an Internet gateway that connects the MANET to the Internet
[4]. Also, it needs a recursive DNS server, called global DNS server,
that translates the DNS name of the web server into the global IP
address. Therefore, Internet gateway SHOULD run ANS Responder in
order to inform mobile nodes in MANET of the information of recursive
DNS server connected to the Internet. The IP address of A global DNS
server is resolved with ANS Resolver and SRV resource record. The
service name of global DNS server is defined as "_global-dns-server".
For example, if the address of global DNS server is "A.B.C.D", the
SRV resource record is as follows;
$ORIGIN MANET_DOMAIN
dns-server A ttl A.B.C.D
__global-dns-server._udp SRV ttl priority weight 53 dns-server
In another way, the global DNS address MAY be delivered to mobile
node that tries to connect to the Internet on piggy-back along with
Internet gateway address [8].
The function of the library related to DNS resolver for the DNS
resolution, e.g., "getaddrinfo()", SHOULD be modified for the support
of DNS name service in MANET. The DNS name for the domain belonging
to MANET, of which suffix is MANET_DOMAIN, is resolved through ANS
Resolver of ANS System. The other DNS names are resolved through the
regular DNS resolver which uses DNS resolver's configuration file,
e.g., /etc/resolv.conf in UNIX, including the recursive DNS server(s)
informed by Internet gateway.
8. IPv6 Considerations
Jeong, et al. Expires - July 2004 [Page 8]
Internet-Draft MANET DNS Service February 2004
ANS can provide ad hoc users with DNS name service and service
discovery in IPv6 MANET. ANS_MULTICAST_IPV4_ADDRESS is replaced with
ANS_MULTICAST_IPV6_ADDRESS for IPv6 ANS. AAAA resource record is
used for the purpose of containing IPv6 address associated with host
DNS name in ANS zone file.
9. Configuration Parameters
This section gives default values for some important parameters
associated with MANET DNS operations.
Parameter Name Value
--------------------------- -----
ANS_MULTICAST_IPV4_ADDRESS 224.0.0.251
ANS_MULTICAST_IPV6_ADDRESS FF05::224.0.0.251
MAX_RETRANS 3
MANET_DOMAIN manet.
10. Security Considerations
In order to provide securer name service including service discovery
in ANS, it is necessary to authenticate ANS responses. ANS can use
IPsec ESP with a null-transform or the secret key transaction
authentication for DNS, TSIG [7], which can be easily accomplished
through the configuration of a group pre-shared secret key for the
trusted nodes [3].
10.1 Message Authentication through TSIG
In ANS, the authentication of DNS message is recommended on the basis
of TSIG resource record which provides secret key transaction
authentication for DNS. HMAC-MD5 is used as hashing algorithm for
authentication [9][10]. All ANS Resolvers and Responders in a
trusted group SHOULD share a group secret key for TSIG authentication.
Whenever ANS Responder responds to DNS query, it sends DNS response
message including TSIG resource record, which has the authentication
code generated through hashing the total DNS response message with
the group's secret key.
11. Copyright
The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
document.
Copyright (C) The Internet Society July 12, 2001. All Rights
Reserved.
Jeong, et al. Expires - July 2004 [Page 9]
Internet-Draft MANET DNS Service February 2004
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Levon Esibov, Bernard Aboba and Dave Thaler, "Linklocal Multicast
Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-29.txt, January
2004.
13. Informative References
[4] Ryuji Wakikawa et al., "Global connectivity for IPv6 Mobile Ad
Hoc Networks", draft-wakikawa-manet-globalv6-01.txt, July 2002.
[5] Jaehoon Paul Jeong, Jungsoo Park, Hyoungjun Kim and Dongkyun Kim,
"Ad Hoc IP Address Autoconfiguration", draft-jeong-adhoc-ip-
addr-autoconf-02.txt, February 2004.
[6] A. Gulbrandsen, P. Vixie and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV) ", RFC 2782, February 2000.
Jeong, et al. Expires - July 2004 [Page 10]
Internet-Draft MANET DNS Service February 2004
[7] P. Vixie, O. Gudmundsson, D. Eastlake and B. Wellington, "Secret
Key Transaction Authentication for DNS (TSIG) ", RFC 2845, May
2000.
[8] Jaehoon Paul Jeong, Soohong Daniel Park, Luc Beloeil and Syam
Madanapalli, "IPv6 DNS Discovery based on Router Advertisement",
draft-jeong-dnsop-ipv6-dns-discovery-01.txt, February 2004.
[9] H. Krawczyk, M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997.
[10] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
14. Authors' Addresses
Jaehoon Paul Jeong
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 1664
Fax: +82 42 861 5404
EMail: paul@etri.re.kr
Jungsoo Park
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 6514
Fax: +82 42 861 5404
EMail: pjs@etri.re.kr
Hyoungjun Kim
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 6576
Fax: +82 42 861 5404
EMail: khj@etri.re.kr
Jeong, et al. Expires - July 2004 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 06:14:10 |