draft-ietf-dnsext-mdns-01.txt   draft-ietf-dnsext-mdns-02.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-01.txt> Microsoft <draft-ietf-dnsext-mdns-02.txt> Microsoft
6 July 2001 14 July 2001
Multicast DNS Multicast DNS
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts. may also distribute working documents as Internet- Drafts.
skipping to change at page 2, line 9 skipping to change at page 2, line 9
Today, with the rise of home networking, there are an increasing number Today, with the rise of home networking, there are an increasing number
of ad-hoc networks operating without a DNS server. In order to allow DNS of ad-hoc networks operating without a DNS server. In order to allow DNS
name resolution in such environments, the use of a multicast DNS is name resolution in such environments, the use of a multicast DNS is
proposed. proposed.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
2. Name resolution using multicast DNS ................... 3 2. Name resolution using multicast DNS ................... 3
2.1 Behavior of the sender and responder ............ 3 2.1 Behavior of the sender and responder ............ 4
3. Usage model ........................................... 4 3. Usage model ........................................... 6
4. Sequence of events .................................... 8 4. Sequence of events .................................... 8
5. Conflict resolution ................................... 8 5. Conflict resolution ................................... 8
5.1 Considerations for multiple interfaces .......... 10 5.1 Considerations for multiple interfaces .......... 10
6. IANA considerations ................................... 11 5.2 API issues ...................................... 11
7. ARPA domain considerations ............................ 11 6. IANA considerations ................................... 12
7. ARPA domain considerations ............................ 12
8. References ............................................ 12 8. References ............................................ 12
9. Security considerations ............................... 13 9. Security considerations ............................... 13
ACKNOWLEDGMENTS .............................................. 13 ACKNOWLEDGMENTS .............................................. 14
AUTHORS' ADDRESSES ........................................... 14 AUTHORS' ADDRESSES ........................................... 15
Intellectual Property Statement .............................. 14 Intellectual Property Statement .............................. 15
Full Copyright Statement ..................................... 15 Full Copyright Statement ..................................... 16
1. Introduction 1. Introduction
Multicast DNS enables DNS name resolution in the scenarios when Multicast DNS enables DNS name resolution in the scenarios when
conventional DNS name resolution is not possible. Namely, when there are conventional DNS name resolution is not possible. Namely, when there are
no DNS servers available on the network or available DNS servers do not no DNS servers available on the network or available DNS servers do not
provide name resolution for the names of the hosts on the local network. provide name resolution for the names of the hosts on the local network.
The latter case, for example, corresponds to a scenario when a network The latter case, for example, corresponds to a scenario when a network
that doesn't have a DNS server is connected to the Internet through an that doesn't have a DNS server is connected to the Internet through an
ISP and the network hosts are configured with the ISP's DNS server for ISP and the network hosts are configured with the ISP's DNS server for
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Figure 2. Off-segment name conflict Figure 2. Off-segment name conflict
If host myhost is configured to use mDNS on both interfaces, it will If host myhost is configured to use mDNS on both interfaces, it will
send mDNS queries on both interfaces. When host myhost sends a query send mDNS queries on both interfaces. When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on for the host RR for name "A" it will receive a response from hosts on
both interfaces. Host myhost will then forward a response from the both interfaces. Host myhost will then forward a response from the
first responder to the second responder, who will attempt to verify the first responder to the second responder, who will attempt to verify the
uniqueness of host RR for its name, but will not discover a conflict, uniqueness of host RR for its name, but will not discover a conflict,
since the conflicting host resides on a different subnet. Therefore it since the conflicting host resides on a different subnet. Therefore it
will continue using its name. This illustrates that the proposed name will continue using its name.
conflict resolution mechanism does not support resolution of conflicts
between hosts on different subnets. This problem can also occur with Indeed, host myhost cannot distinguish between the situation shown in
unicast DNS when a multi-homed host is connected to two different Figure 2, and that shown in Figure 3 where no conflict exists:
networks with separated name spaces. It is not the intent of this
document to address the issue of uniqueness of names within DNS. [A]
| |
----- -----
| |
[myhost]
Figure 3. Multiple paths to same host
This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts on
different subnets. This problem can also occur with unicast DNS when a
multi-homed host is connected to two different networks with separated
name spaces. It is not the intent of this document to address the issue
of uniqueness of names within DNS.
5.2. API issues
RFC 2553 [13] provides an API which can partially solve the name
ambiguity problem for applications written to use this API, since the
sockaddr_in6 structure exposes the scope within which each scoped
address exists, and this structure can be used for both IPv4 (using
v4-mapped IPv6 addresses) and IPv6 addresses.
Following the example in Figure 2, an application on 'myhost' issues the
request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. mDNS requests will be sent from both
interfaces and the resolver library will return a list containing
multiple addrinfo structures, each with an associated sockaddr_in6
structure. This list will thus contain the IPv4 and IPv6 addresses of
both hosts responding to the name 'A'. Link-local addresses will have a
sin6_scope_id value that disambiguates which interface is used to reach
the address. Of course, to the application, Figures 2 and 3 are still
indistinguishable, but this API allows the application to communicate
successfully with any address in the list.
6. IANA Considerations 6. IANA Considerations
Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses. Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses.
7. ARPA domain considerations 7. ARPA domain considerations
This document specifies the use of a new sub-domain of the "ARPA" This document specifies the use of a new sub-domain of the "ARPA"
domain. According to Section 2.1 of the ARPA Guidelines [12], this domain. According to Section 2.1 of the ARPA Guidelines [12], this
specification requires description and justification. specification requires description and justification.
skipping to change at page 13, line 5 skipping to change at page 13, line 37
(MAC) and Physical Layer (PHY) Specifications, IEEE Std. (MAC) and Physical Layer (PHY) Specifications, IEEE Std.
802.11-1997, 1997. 802.11-1997, 1997.
[11] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in [11] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in
the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[12] Huston, G., "Management Guidelines & Operational Requirements for [12] Huston, G., "Management Guidelines & Operational Requirements for
the Internet Infrastructure Domain ("ARPA")", Internet draft (work the Internet Infrastructure Domain ("ARPA")", Internet draft (work
in progress), draft-iab-arpa-02.txt, May 2001. in progress), draft-iab-arpa-02.txt, May 2001.
[13] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic Socket
Interface Extensions for IPv6", RFC 2553, March 1999.
9. Security Considerations 9. Security Considerations
This draft does not prescribe a means of securing the multicast DNS This draft does not prescribe a means of securing the multicast DNS
mechanism. It is possible that hosts will allocate conflicting names for mechanism. It is possible that hosts will allocate conflicting names for
a period of time, or that non-conforming hosts will attempt to deny a period of time, or that non-conforming hosts will attempt to deny
service to other hosts by allocating the same name. Such attacks also service to other hosts by allocating the same name. Such attacks also
allow nodes to receive packets destined for other nodes. The protocol allow nodes to receive packets destined for other nodes. The protocol
reduces the exposure to such threats in the absence of authentication by reduces the exposure to such threats in the absence of authentication by
ignoring multicast DNS query response packets received from off-link ignoring multicast DNS query response packets received from off-link
senders. senders.
skipping to change at page 13, line 43 skipping to change at page 14, line 30
not be authenticated. If a network contains a "signed key distribution not be authenticated. If a network contains a "signed key distribution
center" for all (or at least some) of the DNS zones that the responders center" for all (or at least some) of the DNS zones that the responders
are authoritative for, then hosts on such a network are configured with are authoritative for, then hosts on such a network are configured with
the key for the top zone, "local.arpa." (hosted by "signed keys the key for the top zone, "local.arpa." (hosted by "signed keys
distribution center") and may use DNSSEC for authentication of the distribution center") and may use DNSSEC for authentication of the
responders using DNSSEC. responders using DNSSEC.
Acknowledgments Acknowledgments
This work builds upon original work done on multicast DNS by Bill This work builds upon original work done on multicast DNS by Bill
Manning and Bill Woodcock. The authors gratefully acknowledge their Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
grant #F30602-99-1-0523. The authors gratefully acknowledge their
contribution to the current specification. Constructive input has also contribution to the current specification. Constructive input has also
been received from Mark Andrews, Stuart Cheshire, Robert Elz, James been received from Mark Andrews, Stuart Cheshire, Robert Elz, James
Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten, Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten,
Erik Nordmark, Sander Van-Valkenburg and Tomohide Nagashima. Erik Nordmark, Sander Van-Valkenburg and Tomohide Nagashima.
Authors' Addresses Authors' Addresses
Levon Esibov Levon Esibov
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
skipping to change at page 15, line 30 skipping to change at page 16, line 30
perpetual and will not be revoked by the Internet Society or its perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-01.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-02.txt>, and expires
January 15, 2002. January 30, 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/