WDIFF

draft-aboba-dnsext-mdns-00.txt --> draft-aboba-dnsext-mdns-01.txt

DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
INTERNET-DRAFT Dave Thaler
Category: Standards Track Levon Esibov
<draft-aboba-dnsext-mdns-00.txt> Dave Thaler
<draft-aboba-dnsext-mdns-01.txt> Microsoft
March 9,
14 July 2000

Multicast DNS

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

1. Copyright Notice

2. Abstract

Today, with the rise of home networking, there are an increasing number
of small networks operating without a DNS server. In order to allow DNS
name resolution in such environments, the use of a multicast DNS is
proposed.

With wide deployment of the hosts registered with IPv6 addresses by
routers, in the absence of the DHCP server multicast DNS is proposed to
be used to discover available DNS servers, that will be used for unicast
DNS.

3. Introduction

Multicast DNS enables DNS name resolution in the scenarios when
conventional DNS name resolution is not possible. Namely, when there are
no DNS servers available on the network or available DNS servers do not
provide the name resolution for the names of the hosts on the local

Aboba, Esibov & Thaler Standards Track [Page 1]

INTERNET-DRAFT Multicast DNS 9 March 2000
network. The latter case, for example, corresponds to a scenario when a
home network that doesn't have a DNS server is connected to the Internet
through an ISP and the home network hosts are configured with the ISPÆs ISP's
DNS server for the name resolution. The ISPÆs ISP's DNS server provides the

Esibov, Aboba & Thaler Standards Track [Page 1]

INTERNET-DRAFT Multicast DNS 14 July 2000

name resolution for the names registered on the Internet, but doesn't
provide name resolution for the names of the hosts on the home network.

With wide deployment of the hosts autoconfigured with IPv6 addresses by
routers, in the absence of the DHCP servers, multicast DNS is proposed
to be used to discover available DNS server, that will be used for the
conventional unicast DNS name resolution.

This document discusses multicast DNS, an extension to the DNS protocol
which consists of a single change to the method of use, and no change to
the format of DNS packets.

4. Terminology

In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1].

5. Name resolution using Multicast DNS

This extension to the DNS protocol consists of a single change to the
method of use, and no change whatsoever to the current format of DNS
packets. Namely, this extension allows multicast DNS queries to be sent
to and received on port 53 using IP multicast addresses. These addresses
include four addresses (two Local scope addresses for Ipv4 and IPv6 and
two the LINKLOCAL addresses for IPv4 and IPv6) in this document referred as
Local Scope and LINKLOCAL [2] mDNS addresses.

The IPv4 Local Scope address is 239.255.255.253. The other three
addresses
IPv6, which are yet to be assigned by IANA. LINKLOCAL addresses are used
since the expectation is that if a network has a router, then this
router can function as a mini-DHCP server, as described in [3], and a
DNS proxy, possibly implementing dynamic DNS. Thus there is not expected
to be a need for use of multicast DNS in networks with multiple
segments.

Hosts actively using mDNS behave as DNS servers, and inherit all the
obligations of DNS servers, as described in [8], including the need to
increment the serial number in SOA records. It is suggested that the
serial number be taken from a monotonically increasing clock which
implies that the serial number will be monotonic across reboots.
However, this is not crucial if the DNS TTL is set to a low value.

In order to prevent a DNS server from recursive resolution of the
multicast DNS queries, the RD (Recursion Desired) bit in the Header
section of the query MUST be set to 0.

In order If the RD bit is set to improve scalability, a resolver 1, then
it is ignored.

DNS resolvers configured to use multicast DNS for name resolution always attempts to resolve a multicast query by
sending it to the listen
on port 53 on the LINKLOCAL mDNS addresses prior to sending it address. Responses SHOULD contain a AA
(Authoritative Answer) bit set to 0.

Issue: Handling of the
Local Scope mDNS addresses. AA bit was flagged as a subject for more
discussion.

If a query sent to the LINKLOCAL mDNS addresses is not positively
resolved (ôpositively resolvedö ("positively resolved" refers in this document to the response
with the RCODE set to 0) during a limited amount of time, then the

Esibov, Aboba & Thaler Standards Track [Page 2]

INTERNET-DRAFT Multicast DNS 14 July 2000

resolver SHOULD resend query to a Local Scope mDNS
addresses. Resolvers MAY repeat the transmission of a query in order to assure
themselves that the query has been received by any hosts capable of
answering the query.

Aboba, Esibov & Thaler Standards Track [Page 2]

INTERNET-DRAFT Multicast DNS 9 March 2000

DNS resolvers configured to use multicast DNS for name resolution listen
on port 53 on the LINKLOCAL and Local Scope mDNS addresseses. Resolvers
MUST respond to those queries for which they have a positive
authoritative answer. The resolver responds to such queries after a
random delay in the interval [0,MAX_DELAY). MAX_DELAY MUST never be
longer than the requester's retransmission interval. If a duplicate
response is heard by a resolver during the random delay, the resolver
MUST suppress its own response. The authoritative response MUST contain
AA (Authoritative Answer) bit set to 1. As an example, computer
host.example.com. that receives a multicast DNS query for an A record
for the name host.example.com., will respond with an A record that
contains its IP address in the RDATA of the record.
In addition to this, the resolvers SHOULD respond to the queries if
cached data can be used. Such response contains a AA (Authoritative
Answer) bit set to 0.

Resolvers MUST anticipate receiving no replies to some multicasted
queries, in the event that no multicast-enabled clients are available
within the multicast scope, or in the event that no positive non-null
responses exist to the transmitted query.

If no positive response is received, a resolver treats it as a response
that no records of the specified type and class for the specified name
exist (NXRRSET), which should be cached according to RFC 2308 [15].

Resolvers MUST anticipate receiving multiple replies to the same
multicasted query, in the event that several multicast

6. Usage model

Multicast DNS enabled hosts
receive the query and respond with valid answers. When this occurs, usage is determined by the
responses MAY first be concatenated, and then treated in domain search configuration as
well as by special treatment of the same manner
that multiple RRs received from ".lcl.arpa" namespace. The resolver
treat queries for ".lcl.arpa" as a special case, thus avoiding the same DNS server would, ordinarily.

Auto-configured hosts:

Reference [3] describes how hosts that are configured need
to use DHCP,
but cannot find formally allocate a DHCP server, may auto-configure their IPv4 address
within the 169.254/16 prefix. Such hosts may use multicast DNS as
their name resolution mechanism.

However, since new top level domain. The domain search list can
be configured manually or automatically via a DHCP option. There is
therefore no need for another mDNS queries from an auto-configured host configuration mechanism.

The resolver will
originate from always do a linklocal scope unicast addresses, it may not be
possible multicast query for a host located on another subnet names in the
".lcl.arpa" namespace if there is no NS record corresponding to answer them, since the source address
name. mDNS is only used to resolve unqualified names. This means, for
example, that queries for "www.microsoft.com" will never be resolved via
mDNS.

If ".lcl.arpa" is not routable. Thus, in the result would domain search list, then mDNS MUST NOT be
propagation of useless traffic. As a result, an
used by that host. An auto-configured
IPv4 address host MAY send will typically have
".lcl.arpa" first in its search list so that it will be enabled to use
mDNS. Typically an enterprise host will not have ".lcl.arpa" in its
searchlist at all so that it will not use mDNS.

6.1. Sequence of events

The sequence of events for usage of multicast DNS queries is as follows:

1. A host multicasts a query for ANY record for a name within
the ".lcl.arpa" domain. The query is sent to IPv4 the LINKLOCAL
multicast address. The response is multicast to the LINKLOCAL
mDNS
address, and MUST NOT send multicast uses DNS queries to TTL=0, with the IPv4
Local Scope mDNS address. Similarly, exception of NS, which
uses a host default TTL, with an auto-configured
address MUST a value TBD.

2. Hosts only listen for multicast DNS respond to queries on if they are the IPv4
LINKLOCAL mDNS address.

An auto-configured host that subsequently locates a DHCP name server will
transition to behaving as though it was configured via DHCP, as
described above.

Aboba, Esibov for
the domain (e.g. they are foo.lcl.arpa). Hosts never
respond based on cached information. The responding host
responds with SOA and NS records.

Esibov, Aboba & Thaler Standards Track [Page 3]

INTERNET-DRAFT Multicast DNS 9 March 14 July 2000

6. Name conflicts

It is required to verify the uniqueness of

3. Now that the querying host DNS has discovered the name when it is
configured server for the
domain, subsequent queries are sent unicast to use the discovered
name server.

Note that this implies that multicast DNS cannot be used for discovering
services (e.g. trying to query for all printers on the name resolution. When segument via a host
configured
"*._lpr._udp" SRV [4] query). While this is not an objective of the
current specification, this functionality may be added in a subsequent
extension.

Since mDNS queries are sent on to use a LINKLOCAL multicast address, mDNS
cannot even be used to discover the location of DNS servers off the
local segment. As a result, mDNS is not useful for IPv6 or IPv4 DNS
server discovery.

7. Name conflicts

It is joined required to verify the uniqueness of the host DNS name when a network and/or host
boots, when its name changes is changed, or when a host becomes it is configured to use
multicast DNS (such as when the domain search option is changed to
include ".lcl.arpa").

A gratuitious name resolution query SHOULD be done to check for a name resolution,
conflict. This is done by having the resolver sends send a multicast A ANY type
query with for its own name to discover whether there is any host (within the multicast
scope) with the same name. All the responses with AA (Authoritative
Answer) bit set to 0 MUST be ignored. If the query is not positively resolved then
host starts using its name. If the query is positively resolved, (and AA (Authoritative Answer) bit is set to 1 in the
response) then
the host should verify that the IP addresses specified in the response
are its own IP addresses, possibly from another adapter. If the host
verifies it, then it starts using its name. If the host
canÆt cannot match the
returned A records to its IP addresses, then a conflict has been
detected. In order to resolve ownership conflicts, if the host has a
lower IP address it will keep the name, else if the device has a higher
IP address it will change names.

A host that has detected a name conflict and has loses the name election
MUST not NOT use the name. This means that the host will not MUST NOT respond
authoritatively to the
multicast queries to for that name as well as will
not and MUST NOT respond to other multicast
queries with the records that contain in RDATA name in conflict (for
example, PTR record).

Although the name conflict is detected when a host joins a network (as
described above), such

Note that this name conflict detection mechanism doesnÆt doesn't prevent name
conflicts when ômulticast scopeö changes. As an example of
such change, a router, connecting two previously separate networks may be reconfigured to
allow packages sent to local scope addresses to pass through. Similar
examples may consider two separate networks being are connected by a router
or bridge.
Name conflict in such situation is detected when a host
receives an authoritative multicast response to an A query for its name
or when a client receives more than one authoritative response to a
multicast A type query that it sent. In this situation such client will
send using unicast the first response (preserving the AA (Authoritative
Answer) bit) that it received to the host(s) that authoritatively
responded to the query after the first response was received. A host
that receives a response for a query for itÆs own name, even if it
didnÆt send such query, behaves as if it sent this query, meaning that
the host will stop using the name as it is specified above if the AA bit
is set to 1 and the IP address specified in the response is not its own
IP address.

7. DNS resolver configuration

In general, a DNS resolver may be configured to use for name resolution
only unicast DNS, or only multicast DNS, or both. Following the
notations introduced in the RFC 1001 [16], every DNS resolver may be
configured as one of the following four types of nodes:

p-node û DNS resolver sends only unicast queries. Resolver doesnÆt
listen on multicast addresses.

Aboba, Esibov & Thaler Standards Track [Page 4]

INTERNET-DRAFT Multicast DNS 9 March 2000

h-node û DNS resolver sends unicast query. If the query is not
positively resolved, then it submits the multicast query. Resolver
listens on multicast addresses.

m-node û DNS resolver sends multicast query. If the query is not
positively resolved, then it submits the unicast query. Resolver
listens on multicast addresses.

b-node û DNS resolver sends only multicast queries. Clients listen
on multicast addresses.

Depending on the environments where host is used, different
configurations could be more or less appropriate. While multicast DNS
was designed for use within small networks, it is essential that its
deployment not adversely affect enterprise networks.

A Multicast DNS Node Type DHCP Option [4] enables network
administrators to appropriately configure resolvers to prevent flooding
caused by multicast DNS queries in the administered large networks.

A host that is configured via DHCP, but does not receive a Multicast DNS
Node Type DHCP Option MUST NOT use multicast DNS for name resolution
unless otherwise configured. Thus, it behaves as though it had been
configured as a P-node.

If a DNS server is running on a host, the DNS resolver on such a host
MUST be configured as a p-node, to prevent a DNS resolver from listening
on port 53 and intercepting DNS queries directed to the DNS server.

8. DNS server discovery in IPv6

Multicast DNS MAY be used for the DNS server discovery. This behavior is
expected when IPv6 gets widely deployed in the scenarios where DHCPv6 is
not available. In the presence of a DHCPv6 server it is expected that
administrators will configure the hosts with the DNS servers using the
DNS server configuration option.
A host that is not configured with a DNS server regardless of the
configuration of its Multicast DNS node type MAY attempt to discover a
preferred DNS server by sending a multicast SRV [17] query as described
below. If no response is received, then the host MUST behave according
to its multicast DNS node type configuration, but MAY repeat a multicast
SRV query to discover DNS server on a periodic basis. If a response is
received the host starts using discovered DNS servers for the name
resolution, but it continues to behave according to its multicast DNS
node type configuration.

Aboba, Esibov & Thaler Standards Track [Page 5]

INTERNET-DRAFT Multicast DNS 9 March 2000

To minimize the network load and load on the resolvers that listen to
the multicast DNS queries, the following algorithm will be used if a
resolver attempts a discovery of a DNS server:
1. send a query to the IPv6 LINKLOCAL mDNS address
2. if a query sent to the IPv6 LINKLOCAL mDNS address is not positively
resolved during a limited amount of time, then resolver SHOULD resend
query to the Local Scope All_DNS_servers mDNS address. Resolvers MAY
repeat the transmission of a query in order to assure themselves that
the query has been received by a DNS servers capable of answering the
query.

DNS servers that are configured to be discovered through multicast DNS
queries, MUST listen on the IPv6 LINKLOCAL and IPv6 Local Scope
All_DNS_servers mDNS addresses. They respond to the same multicast
address the query was sent.

DNS server discovery using SRV multicast query

DNS server location information is to be stored using DNS Service
Location Record (SRV)[17]. The data in a SRV record contains the DNS
name of the DNS server, corresponding Port number, and Priority and
Weight fields that enable the resolver to choose an appropriate
server from multiple servers according to the algorithm described in
the SRV protocol[17]. The name of this record is always:

_dns._udp.lcl

where ôdnsö indicates the service provided by the server, and "udp"
is a protocol that should be used to contact a DNS server. This
document doesnÆt imply to change the current standards specifying
when udp and tcp protocols should/should not be used by DNS resolvers
and servers.

Every DNS server that is configured to be discovered through the
multicast DNS query must be authoritative for the zone ôlclö.

Presence of the SRV records for ô_dns._udp.lclö enables resolvers to
find the DNS servers using multicast DNS query. As receives an example,
multicast response to a
resolver that searches query for its name or when a DNS server will submit client receives
more than one response to a multicast DNS query that it sent. A host that
receives a response for a set of SRV records with owner name:

_dns._udp.lcl

The resolver will receive the list of SRV records published in DNS
that satisfy the requested criteria. The following is an example of query for it's own name, even if it didn't
send such record:

_dns._udp.lcl IN SRV 0 0 53 dnsserver.example.net.

The set of returned records may contain multiple records in the case
where multiple DNS servers serve the same network.

Aboba, Esibov query, behaves as if it sent this query.

Esibov, Aboba & Thaler Standards Track [Page 6] 4]

INTERNET-DRAFT Multicast DNS 9 March 14 July 2000

In order to prevent denial of service attacks, it is recommended that
"lcl.arpa" be placed last in the domain searchlist. As long as this is
the case, there should be no way for a server with a FQDN to encounter
name conflict problems which would cause it to become unreachable.

8. IANA Considerations

Authors will contact IANA to reserve:
1. reserve LINKLOCAL IPv4 and IPv6 addresses
2. Local Scope IPv6 address
3. Local Scope All_DNS_servers IPv6 address.

Authors of the draft will contact IANA to reserve a top level domain
ôlclö. addresses.

9. Security Considerations

This draft does not prescribe a means of securing the multicast DNS
mechanism. It is possible that hosts will allocate conflicting names for
a period of time, or that non-conforming hosts will attempt to deny
service to other hosts by allocating the same name.

These threats are most serious in wireless networks such as 802.11,
since attackers on a wired network will require physical access to the
home network, while wireless attackers may reside outside the home. In
order to provide for privacy equivalent to a wired network, the 802.11
specification provides for RC4-based encryption. This is known as the
"Wired Equivalency Privacy" (WEP) specification. Where WEP is
implemented, an attacker will need to obtain the WEP key prior to
gaining access to the home network.

The multicast DNS server discovery mechanism introduces another type of
denial of service attack on the DNS servers by sending multicast queries
to the DNS server, but this type is not worse than any other and does
not add additional complication.

All security considerations related to DNS SRV records are inherited by
this document. See the security considerations section in [17] for more
details.

10. Acknowledgements

Authors

The authors would like to thank Eric Gutman for productive discussion Stuart Cheshire, Michael Patton, Erik
Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark,
Myrong Hattig and
his contribution to the specification of Bill Manning for comments on this draft, provided at
the multicast DNS.

Aboba, Esibov & Thaler Standards Track [Page 7]

INTERNET-DRAFT Multicast DNS 9 March 2000 mDNS lunch in Adelaide, Australia on 3/29/00.

11. Authors' Addresses

Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: levone@microsoft.com

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 (425) 936-6605
EMail: bernarda@microsoft.com

Esibov, Aboba & Thaler Standards Track [Page 5]

INTERNET-DRAFT Multicast DNS 14 July 2000

Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 (425) 703-8835
EMail: dthaler@microsoft.com

Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: levone@microsoft.com

12. References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.

[3] Troll, R., "Automatically Choosing an IP Address in an Ad-Hoc
IPv4 Network", Aboba, B., "The Mini-DHCP Server", Internet draft (work in
progress), draft-ietf-dhc-
ipv4-autoconfig-04.txt, draft-aboba-dhc-mini-01.txt, April 1999. 2000.

[4] Aboba, B., Gulbrandsen, A., Vixie, P., Esibov, L, Thaler, D., "Multicast L. "A DNS Configuration
Option", Internet draft (work in progress), draft-aboba-dhc-mdns-
conf-00.txt, RR for specifying the
location of services (DNS SRV)", RFC 2782, February 2000.

[5] Braden, R., "Requirements for Internet Hosts -- Application and
Support", RFC 1123, October 1989.

[6] Hanna, S., Patel, B., and Shah, M., "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

Aboba, Esibov & Thaler Standards Track [Page 8]

INTERNET-DRAFT Multicast DNS 9 March 2000

[7] Woodcock, B., Manning, B., "Multicast Discovery of Gulbrandsen, A., "A DNS Services", RR for encoding DHCP information", Internet
draft (work in progress), draft-manning-multicast-
dns-01.txt, draft-ietf-dnsind-dhcp-rr-00.txt, October 1998.
1999.

[8] Mockapetris, P., "Domain Names - Implementation and Specification",
RFC 1035, November 1987.

[9] IANA, "Single-source IP Multicast Address Range",
http://www.isi.edu/in-notes/iana/assignments/single-source-
multicast, October 1998.

[10] Handley, M., Thaler, D., and Kermode, R., "Multicast-Scope Zone
Announcement Protocol (MZAP)", Work in progress, draft-ietf-mboned-
mzap-06.txt, December, 1999.

[11] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear,
E., "Address Allocation for Private Internets", RFC 1918, February,
1996.

Esibov, Aboba & Thaler Standards Track [Page 6]

INTERNET-DRAFT Multicast DNS 14 July 2000

[12] Stapp, M., Rekhter, Y., "Interaction between DHCP and DNS",
Internet draft (work in progress), draft-ietf-dhc-dhcp-dns-11.txt,
October 1999.

[13] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April, 1997.

[14] Troll, R., "DHCP Option to Disable Stateless Auto-
Configuration in IPv4 Clients", RFC 2563, May 1999.

[15] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
2308, March 1998.

[16] Auerbach, K., "PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
TRANSPORT: CONCEPTS AND METHODS", RFC 1001, March, 1987.

[17] Gulbrandsen , A., . Vixie, P., Esibov, L. ôA DNS RR

13. Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for specifying publication and any assurances of licenses to
be made available, or the location result of services (DNS SRV)ö, RFC 2782, February 2000.

13. an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.

14. Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation 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

Esibov, Aboba & Thaler Standards Track [Page 7]

INTERNET-DRAFT Multicast DNS 14 July 2000

or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in

Aboba, Esibov & Thaler Standards Track [Page 9]

INTERNET-DRAFT Multicast DNS 9 March 2000
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 assigns. 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."

14.

15. Expiration Date

This memo is filed as <draft-aboba-dnsext-mdns-00.txt>, <draft-aboba-dnsext-mdns-01.txt>, and expires
September 9, 2000.

Aboba, Esibov
February 1, 20001.

Esibov, Aboba & Thaler Standards Track [Page 10] 8]

----