Subject: I-D ACTION:draft-ietf-dnsext-mdns-11.txt

From: [email-masked]
Date: Thu, 25 Jul 2002 08:06:18 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Linklocal Multicast Name Resolution (LLMNR)
	Author(s)	: L. Esibov, B. Aboba, D. Thaler
	Filename	: draft-ietf-dnsext-mdns-11.txt
	Pages		: 20
	Date		: 24-Jul-02
	
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
name resolution in such environments, Link-Local Multicast Name
Resolution (LLMNR) is proposed. LLMNR supports all current and future
DNS formats, types and classes, while operating on a separate port from
DNS, and with a distinct resolver cache.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-11.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-mdns-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-mdns-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Markku Savela <[email-masked]>
Date: Thu, 25 Jul 2002 16:23:05 +0300

I may have other comments later, but first this: the introduction
contains a paragraph:

   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it
   is possible for a dual stack host to be configured with the address
   of a DNS server for IPv4, while remaining unconfigured with a DNS
   server suitable for use with IPv6. ... 

I think this contains a fundamental misunderstanding how a
nameresolving on the dual stack host works.

If a dual stack host has even one DNS server address (either IPv4 or
IPv6), it can be used for both IPv4 (A) and IPv6 (AAAA) queries.

It makes no difference how this DNS server address was obtained
(/etc/resolv.conf, DHCP, DHCPv6 or whatever).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Markku Savela <[email-masked]>
Date: Fri, 26 Jul 2002 17:57:39 +0300

I've more comments about <draft-ietf-dnsext-mdns-11.txt> 20 July 2002

-----------------
1.2.  Terminology

Responder      A host that listens to (but not necessarily responds to)
               a LLMNR query is called "responder".

Sender         A host that sends an LLMNR query. The same host may be
               configured as a "sender", but not a "responder" and vice
               versa, i.e. as a "responder", but not a "sender".
-----------------

	I thought the idea was that each host knows it's own name and
	address and is an authority on those. Thus each host must be a
	'responder'. But, if it cannot be 'sender' at same time, it
	cannot query any other names.

	And if host is a 'sender', it cannot listen and respond to
	queries that match its name?

	To me it seems that the most common and useful configuration
	would exactly be combined 'sender' + 'responder', which seems
	to be ruled out by above!

------------------
2.  Name resolution using LLMNR

...
network has a home gateway, then the network either has a DNS server or
the home gateway can function as a DNS proxy.  By implementing DHCPv4 as
well as a DNS proxy and dynamic DNS, home gateways can provide name
resolution for the names of IPv4 hosts on the local network.

For small IPv6 networks, equivalent functionality can be provided by a
home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name
resolution for the names of IPv6 hosts on the local network.
....
------------------

	In above I see again some confusion. Any DNS server either
	over IPv6 or over IPv4 can serve BOTH IPv6 and IPv4
	queries. It does not matter whether this server was obtained
	through DHCPv4 or DCHPv6 (or by any other means).

	The corollary to this is that enabling both IPv4 and IPv6
	LLMNR on the same link, means that you just have two
	"nameservers" to choose, and a host (sender) should be able
	send query to either one (regardless of the query type: A,
	AAAA or PTR).

	However, if it is expected that there are IPv4-only or
	IPv6-only hosts on the link, then it should send query to both
	"servers"? Does it send them in parallel or after one
	timeouts?

------------------
2.5.  No/multiple responses

...
Since the responder MUST NOT respond to queries for names it is not
authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR
query with an NXRRSET. However, for other queries, such a response is
possible; for example, if the host has a AAAA RR, but no MX RR, and an
MX RR query is received.
...
-------------------

	Perhaps, better or additional example would be "AAAA" and "A"
	(instead of "AAAA" and "MX"): e.g. "if the host has a AAAA RR,
	but no A RR, and an A RR query is received" (or vice versa).

-------------------
...
The sender MUST anticipate receiving multiple replies to the same LLMNR
query, in the event that several LLMNR enabled computers receive the
query and respond with valid answers. When this occurs, the responses
MAY first be concatenated, and then treated in the same manner that
multiple RRs received from the same DNS server would, ordinarily.
...
-------------------

	Concatenated? Isn't receiving multiple replies an indication
	of a conflict? Two hosts on the link use same name? At least
	for A and AAAA queries?

-------------------
3.1.  LLMNR configuration

LLMNR usage can be configured manually or automatically.  On interfaces
where no manual or automatic DNS configuration has been performed for a
given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that
protocol.
...
-------------------

	Again the same confusion. DNS is not configured for single
	interface. When a host finds a DNS server address, it will
	apply to ALL interfaces.

	Thus, the logical conclusion is: if host has "real" DNS server
	address, then NONE of the interfaces can have LLNMR. Or, you
	have to accept the fact that in such situation you have both
	GLOBAL DNS and LLNMR applying to the same interface and
	specify sensible rules to deal with situation.

	[NOTE: I do realise there are such beasts as split DNS servers
	or intranet local servers, but handling these require some new
	"namespace" concepts that are not present in "standard
	traditional" DNS semantics and resolver stubs.]

--------------------
...
Note that it is possible for LLMNR to be enabled for use with IPv6 at
the same time it is disabled for IPv4, and vice versa.
...
--------------------
	Yes, but this just means that you have "LLMNR" over IPv4 or
	IPv6. You can still use either to query A or AAAA.

--------------------
5.  Conflict resolution
...
...
   - multiple hosts may respond to a query for a SRV type record
   - multiple hosts may respond to a query for an A type record for a
     cluster name (assigned to multiple hosts in the cluster)
   - only a single host may respond to a query for an A type record for
     a hostname.
--------------------

	When querying a name and getting multiple replies, how does
	host know whether name was "hostname" or "cluster name"?

	Each "...for an A type..." in above should be replaced with
	text "...for an A or AAAA type..."

---------------------
...
Where a host is configured to respond to LLMNR queries on more than one
interface, the host MUST verify resource record uniqueness on each
interface for each UNIQUE resource record that could be used on that
interface.
...
---------------------

	LLMNR is "LINK LOCAL MULTICAST NAME RESOLUTION". I think all
	text concerning about synchronizing the names across links
	should be removed.

	Each link should have it's own independent LLMNR cache.

regards,
-- 
Markku Savela

Esibov, Aboba & Thaler       Standards Track                   [Page 20]

---

From: David Terrell <[email-masked]>
Date: Fri, 26 Jul 2002 14:02:47 -0700

> I've more comments about <draft-ietf-dnsext-mdns-11.txt> 20 July 2002

It's just vague wording.  The problem with the term responder, of course, 
is that it's not always a responder.  What's wrong with the more common
multicast term "listener"?
I would suggest:

1.2 Terminology

Listener - A host that listens to a LLMNR query is called a "listener".
           A listener need not actually send a response to any
           particular query.

Sender   - A host that originates an LLMNR query is called a sender.
           A sender need not be a listener, and vice versa.

But after 11 revisions I don't know if you really want to change
your terminology that drastically. :)  Even if you don't, the new
definition wording seems clearer (to me) as to what defines a
[responder] or sender.

-- 
David Terrell            | "When we said that you needed to cut the
[email-masked]             | wires for ultimate security, we didn't
Nebcorp Prime Minister   | mean that you should go wireless instead."
http://wwn.nebcorp.com/  |   - Casper Dik

---

From: Markku Savela <[email-masked]>
Date: Tue, 30 Jul 2002 14:17:43 +0300

Having read and commented on <draft-ietf-dnsext-mdns-11.txt>, I think
we might need a "Scoped name resolution reference model" or something,
that specifies the framework for handling overlapping situations.

- we have "traditional" global DNS
- we have this new Link Local Name resolution
- we may hava site local name resolution

The <draft-ietf-dnsext-mdns-11.txt> includes some text about not
having global DNS and LLMNR active at same time.

This assumption requires highly special conditions (a closed meeting
room without any outside network connections, permanently isolated
network segments). In normal practise I would claim most useful ad hoc
networks (bluetooth, wlan..) will also have occational access to the
global internet and thus global DNS.

There is a need to accept situation where a node can 

- has neither LLMNR nor global DNS
- has LLMNR (on at least one link)
- has global DNS
- has both LLMNR and global DNS

and node can transition between these states unpredictably. Then add
possible site local DNS into this soup...

It should be noted that LLMNR is somewhat different "taxonomically"
from global DNS. LLMNR is P2P, global DNS is peer-to-server.
One could consider P2P on site-local level (SLMNR?) or
peer-to-server. Howabout global P2P name resolution, based on
global multicast (yeah, does not scale? Unless you have IPSEC
protected multicast group, and only limited membership :-)

The reference model should tell how to behave in enviroment that has
multiple enclosing name resolutions:

- which order are queries sent (global -> site - > local or local ->
  site - > global, or something else?)

- are gueries sent in parallel or one at time

- how are conflicts handled (at least each level must have own cache,
  and each LLMNR must be cached separately per interface) [you can use
  <scopelevel, scope-id> from IPv6 scoped addressing architecture as
  cache id, for example]

- if there are multiple LLMNR interfaces, how are queries handled?
  (send queries in parallel to all?)

- can LLMNR contain only link local addresses in A and AAAA? Should
  name already tell the scope? Eg. only "*.local" names are resolved
  with LLMNR? "*.site"? Or can, any name "foo.bar.com" or address
  appear in any of the levels and you just get what is first found
  based on the search order?

- what happens when some name resolution level becomes reachable or
  unreachable?