Skip to main content

Link-local Multicast Name Resolution (LLMNR)
draft-ietf-dnsext-mdns-47

Revision differences

Document history

Date Rev. By Action
2012-08-22
47 (System) post-migration administrative database adjustment to the Abstain position for Magnus Westerlund
2012-08-22
47 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2006-12-05
47 (System) IANA Action state changed to Waiting on RFC Editor from RFC-Ed-Ack
2006-12-04
47 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on Authors
2006-11-13
47 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-11-08
47 (System) Request for Early review by SECDIR is assigned to Joseph Salowey
2006-11-08
47 (System) Request for Early review by SECDIR is assigned to Joseph Salowey
2006-11-03
47 (System) IANA Action state changed to In Progress
2006-11-01
47 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-10-31
47 Amy Vezza IESG state changed to Approved-announcement sent
2006-10-31
47 Amy Vezza IESG has approved the document
2006-10-31
47 Amy Vezza Closed "Approve" ballot
2006-10-30
47 Mark Townsley Note field has been cleared by Mark Townsley
2006-08-21
47 (System) New version available: draft-ietf-dnsext-mdns-47.txt
2006-08-21
47 Mark Townsley State Changes to Approved-announcement to be sent::External Party from Approved-announcement to be sent::Point Raised - writeup needed by Mark Townsley
2006-08-21
47 Mark Townsley [Note]: 'Waiting until Sept 4 based on IESG Note email' added by Mark Townsley
2006-08-21
47 Mark Townsley
Heads up about IESG Note

-------- Original Message --------
Subject: draft-ietf-dnsext-mdns-46.txt
Date: Mon, 21 Aug 2006 11:34:02 +0200
From: Mark Townsley
To: dnsext-chairs@tools.ietf.org, Bernard …
Heads up about IESG Note

-------- Original Message --------
Subject: draft-ietf-dnsext-mdns-46.txt
Date: Mon, 21 Aug 2006 11:34:02 +0200
From: Mark Townsley
To: dnsext-chairs@tools.ietf.org, Bernard Aboba , Dave Thaler , levone@microsoft.com
CC: iesg@cisco.com


The IESG is ready to approve publication of this document, with the
following IESG note attached:

"This document is published as a record of discussion and in order to
provide a specification of a deployed protocol.  The IETF did not reach
consensus on this approach."

I'm sending this to the authors and chairs to give each of you a chance
to object to this before moving forward. If I hear no objection by two
weeks from today (understanding that folks may be on holiday right now),
Monday Sept 4, I will add this IESG Note and approve the document for
publication.

Thanks,

- Mark
2006-07-20
47 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2006-07-20
47 Mark Townsley [Note]: 'Need to followup on additional edits from Bernard and IANA options.' added by Mark Townsley
2006-07-20
47 Mark Townsley
IANA issue from: yoshiko.chong@jabber.icann.org

IANA notes that the port 5355 for both TCP and UDP have already been
regestered to LLMNR in the registry located …
IANA issue from: yoshiko.chong@jabber.icann.org

IANA notes that the port 5355 for both TCP and UDP have already been
regestered to LLMNR in the registry located at
http://www.iana.org/assignments/port-numbers.

IANA notes that the link-scope multicast IPv4 address 224.0.0.252 has
already been allocated to LLMNR in the registry located at
http://www.iana.org/assignments/multicast-addresses.

The IANA also notes that the link-scope multicast IPv6 address
FF02:0:0:0:0:0:1:3 has already been allocated in the registry located at
http://www.iana.org/assignments/ipv6-multicast-addresses.

Upon approval of this document two new name spaces are created: the
LLMNR namespace and the reserved bits for the LLMNR Header.

IANA understands that no action is required for the LLMNR namespace.  As
a result of using single-label names in this namespace - in accordance
with RFC 1001 - no registration process is required.

The IANA has a question about the LLMNR namespace.  IANA understands
that this is to be a new namespace where reserved bits are allocated by
IETF consensus.  IANA wishes to understand if there are to be any
initial registrations in this namespace?  Would this new registry be
located within another existing registry or would a new location be needed?
2006-07-20
47 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2006-07-20
47 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Abstain from No Objection by Magnus Westerlund
2006-07-20
47 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Abstain by Magnus Westerlund
2006-07-20
47 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Abstain from Yes by Sam Hartman
2006-07-20
47 Sam Hartman
[Ballot comment]
[declaration of potential conflict: the Kerberos group at MIT is
closely associated with Apple.  We do not currently receive direct
funding from Apple …
[Ballot comment]
[declaration of potential conflict: the Kerberos group at MIT is
closely associated with Apple.  We do not currently receive direct
funding from Apple although we have in the past.]


I agree with Cullen and Ted.  There should be an interoperable
standard solution to this need; it should be one that people actually
use.  Publishing this protocol and encouraging its implementation is
not a step in that direction.

Publishing this as a record of discussion may be reasonable.  However
we need to be very clear in the IESG note that we are not publishing
in the hopes of encouraging wider deployment.

I too believe this document represents a huge process failure.
2006-07-20
47 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman by Sam Hartman
2006-07-20
47 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Abstain from Discuss by Magnus Westerlund
2006-07-19
47 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Abstain from Undefined by Cullen Jennings
2006-07-19
47 Cullen Jennings
[Ballot comment]
A solution to this problem is useful. IETF should manage to provide a standards track approach to it. I do not believe that …
[Ballot comment]
A solution to this problem is useful. IETF should manage to provide a standards track approach to it. I do not believe that moving this forward gets us closer to having that or helps the longer term goals of having the IETF produce interoperable standards.
2006-07-19
47 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2006-07-18
47 Lisa Dusseault
[Ballot comment]
I'm concerned but OK with this as informational.  I wish I had a better understanding of the risks to applications that believe they're …
[Ballot comment]
I'm concerned but OK with this as informational.  I wish I had a better understanding of the risks to applications that believe they're doing DNS when they actually get resolution from LLMNR/mDNS.  There were ominous references to that in last call and I don't know if that's FUD or real as there's nothing in the document that really addresses that.

Nit: "  The use of separate caches is most
  effective when LLMNR is used as a name resolution mechanism of last
  resort, since this minimizes the opportunities for poisoning the
  LLMNR cache, and decreases reliance on it."

Shouldn't this be the DNS cache that is protected from poisoning, or perhaps both?
2006-07-18
47 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-07-14
47 Russ Housley
[Ballot comment]
The concerns raised by Ted and Bill are significant.

  The header on the title page inicates that this document is intended
  …
[Ballot comment]
The concerns raised by Ted and Bill are significant.

  The header on the title page inicates that this document is intended
  for Standards Track.  Of course, the ballot indicates that this
  document is intended for Informational.  This clearly needs to be
  corrected if the document is approved for publication.
2006-07-14
47 Russ Housley [Ballot Position Update] New position, Abstain, has been recorded for Russ Housley by Russ Housley
2006-07-07
47 (System) Removed from agenda for telechat - 2006-07-06
2006-07-06
47 Brian Carpenter
[Ballot comment]
Minor/editorial points from Gen-ART review by Francis Dupont:

- 2.1 page 5: the 512 octets default maximum seems a bit too conservative?
- …
[Ballot comment]
Minor/editorial points from Gen-ART review by Francis Dupont:

- 2.1 page 5: the 512 octets default maximum seems a bit too conservative?
- 2.1.1 C page 6: request -> query (IMHO the document should use only
  the pair of terms query/response)
- 2.9 page 14: check if SIG(0) is not now RSIG(0) (PS: as far as I know
  the RFC 2931 was not updated so it is still SIG(0))
- 3.1 pages 17 and 18: linklocal -> link-local (twice)
- 4.1 page 19: I am not happy with "interpreted as an unsigned integer"
  as this involves an ambiguous byte order (I assume it is big endian
  but it is not specified). I strongly prefer the lexicographical order.
- 4.2 page 20: same than the previous point.
- 4.2 page 21: requests -> queries, and replies -> responses
- 5 page 22: 802.11 -> IEEE 802.11
- 5.1 page 23: silently discarding them as rapidly as possible ->
  silently discarding them (I don't know a way to slowly discard them :-)
- 5.2 page 23: link layer security -> link-layer security (the link-xxx
  style seems fine)
- 5.2 page 23: local-link -> local link
- 5.3 [a] page 24: same than 2.9
- 6 page 25: my dictionary has no "coincident", in particular in this
  position... (i.e., there is a possible wording/language problem)

[BC - it's a perfectly fine adjective but an adverb is needed here.]

- 8.2 pages 26/27: many informative references are for 2002 I-Ds,
  perhaps this can become a problem?
- Acks page 28: Van-Valkenburg -> van Valkenburg? (please check with him)
- Open Issues page 30: should be marked as to be removed by the RFC editor.
2006-07-06
47 Brian Carpenter
[Ballot discuss]
From Gen-ART review by Francis Dupont

- 5.3 [b] page 24: IPsec ESP has two NULL algorithms, NULL encryption
  and NULL integrity/authentication …
[Ballot discuss]
From Gen-ART review by Francis Dupont

- 5.3 [b] page 24: IPsec ESP has two NULL algorithms, NULL encryption
  and NULL integrity/authentication (cf RFC 4305, the term transform comes
  from RFC 4306 but "algorithm" is better). I strongly suggest:
  null-transform -> NULL encryption algorithm.
2006-07-06
47 Brian Carpenter
[Ballot discuss]
From Gen-ART review by Francis Dupont

- 5.3 page 24: IPsec ESP has two NULL algorithms, NULL encryption
  and NULL integrity/authentication (cf …
[Ballot discuss]
From Gen-ART review by Francis Dupont

- 5.3 page 24: IPsec ESP has two NULL algorithms, NULL encryption
  and NULL integrity/authentication (cf RFC 4305, the term transform comes
  from RFC 4306 but "algorithm" is better). I strongly suggest:
  null-transform -> NULL encryption algorithm.
2006-07-06
47 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter
2006-07-06
47 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-07-06
47 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from No Objection by Cullen Jennings
2006-07-06
47 Cullen Jennings State Changes to IESG Evaluation - Defer from IESG Evaluation by Cullen Jennings
2006-07-05
47 Ross Callon
[Ballot comment]
I agree with Ted and Bill that this is a result of a sub-optimal process. However, I think that it is better to …
[Ballot comment]
I agree with Ted and Bill that this is a result of a sub-optimal process. However, I think that it is better to publish the document in order to document the protocol. I agree with Ted that some sort of note would be appropriate, perhaps along the lines that "the working group was not able to reach full consensus".
2006-07-05
47 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by Ross Callon
2006-07-05
47 Bill Fenner [Ballot comment]
I'm piggybacking on Ted's abstain.  The development of this document is something for the IETF to be ashamed of.
2006-07-05
47 Bill Fenner [Ballot Position Update] New position, Abstain, has been recorded for Bill Fenner by Bill Fenner
2006-07-05
47 Ted Hardie
[Ballot comment]
I've entered an Abstain on this, rather than a discuss, because I believe the energy to work on this document is pretty severely …
[Ballot comment]
I've entered an Abstain on this, rather than a discuss, because I believe the energy to work on this document is pretty severely limited.  I would be happier with the document with an IESG  note saying, basically, "Published as a record of discussion".

Other than the really basic issue that they didn't resolve the interoperability with deployed rendezvous/bonjour, my concerns are around the continuing MPD around the relationship to the DNS.  The use of "DNS TTL" in 2.8, for example, when the TTL record in the LLMNR record is apparently meant (yes, it reuses the packet format, and I think I get what they mean, but this kind of confusion doesn't help).  The other aspects of the interaction are similarly confusing:

  In order to to avoid creating any new administrative procedures,
  administration of the LLMNR namespace will piggyback on the
  administration of the DNS namespace.

Given the scope of this, one of the issues is that these fundamentally aren't administered like the DNS namespace; saying they are just doesn't make sense and adds to confusion.  I do appreciate the advice not share the LLMNR and DNS local cache.
2006-07-05
47 Ted Hardie [Ballot Position Update] New position, Abstain, has been recorded for Ted Hardie by Ted Hardie
2006-07-05
47 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-07-05
47 Magnus Westerlund
[Ballot discuss]
I am missing some discussion and requirement on rate limiting of the requests and respons to avoid causing or worsening congestion situations on …
[Ballot discuss]
I am missing some discussion and requirement on rate limiting of the requests and respons to avoid causing or worsening congestion situations on the local link. The LLMNR requests with its capability to result in a multi packet (fragments) response can help cause congestion and be a target for an attack.

Please provide some recommendations on how to mitigate this issue.
2006-07-05
47 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-07-04
47 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-06-30
47 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Undefined by Lars Eggert
2006-06-30
47 Lars Eggert [Ballot Position Update] New position, Undefined, has been recorded for Lars Eggert by Lars Eggert
2006-06-19
47 Mark Townsley State Changes to IESG Evaluation from AD Evaluation by Mark Townsley
2006-06-19
47 Mark Townsley Placed on agenda for telechat - 2006-07-06 by Mark Townsley
2006-06-19
47 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2006-06-19
47 Mark Townsley Ballot has been issued by Mark Townsley
2006-06-19
47 Mark Townsley Created "Approve" ballot
2006-05-17
47 Mark Townsley State Changes to AD Evaluation from Publication Requested by Mark Townsley
2006-04-18
47 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2006-04-18
47 Dinara Suleymanova Intended Status has been changed to Informational from Proposed Standard
2006-04-17
46 (System) New version available: draft-ietf-dnsext-mdns-46.txt
2006-04-05
47 Mark Townsley Shepherding AD has been changed to Mark Townsley from Margaret Wasserman
2005-10-06
45 (System) New version available: draft-ietf-dnsext-mdns-45.txt
2005-10-03
44 (System) New version available: draft-ietf-dnsext-mdns-44.txt
2005-09-19
47 Margaret Cullen State Changes to AD is watching from Waiting for AD Go-Ahead::AD Followup by Margaret Wasserman
2005-09-19
47 Margaret Cullen Note field has been cleared by Margaret Wasserman
2005-08-31
47 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-08-31
43 (System) New version available: draft-ietf-dnsext-mdns-43.txt
2005-08-25
47 Margaret Cullen State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Margaret Wasserman
2005-08-25
47 Margaret Cullen [Note]: 'Waiting for resolution of 3 issues raised during LC.  -43 expected.' added by Margaret Wasserman
2005-08-25
47 Margaret Cullen Removed from agenda for telechat - 2005-09-01 by Margaret Wasserman
2005-08-25
47 Margaret Cullen [Note]: 'Waiting for resolution of 3 issues raised during LC.  -43 expected.' added by Margaret Wasserman
2005-08-24
47 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2005-08-10
47 Amy Vezza Last call sent
2005-08-10
47 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-08-10
47 Margaret Cullen Telechat date was changed to 2005-09-01 from  by Margaret Wasserman
2005-08-10
47 Margaret Cullen Telechat date was changed to 2005-09-01 from  by Margaret Wasserman
2005-08-10
47 Margaret Cullen Telechat date was changed to 2005-09-01 from  by Margaret Wasserman
2005-08-10
47 Margaret Cullen Telechat date was changed to 2005-09-01 from  by Margaret Wasserman
2005-08-10
47 Margaret Cullen Placed on agenda for telechat - 2005-09-01 by Margaret Wasserman
2005-08-10
47 Margaret Cullen State Changes to Last Call Requested from AD Evaluation::AD Followup by Margaret Wasserman
2005-08-10
47 Margaret Cullen Last Call was requested by Margaret Wasserman
2005-08-10
47 (System) Ballot writeup text was added
2005-08-10
47 (System) Last call text was added
2005-08-10
47 (System) Ballot approval text was added
2005-08-10
47 Margaret Cullen Note field has been cleared by Margaret Wasserman
2005-08-08
42 (System) New version available: draft-ietf-dnsext-mdns-42.txt
2005-07-18
47 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-07-18
41 (System) New version available: draft-ietf-dnsext-mdns-41.txt
2005-07-18
47 Margaret Cullen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Margaret Wasserman
2005-07-18
47 Margaret Cullen [Note]: '2005-07-18:  One open issue remains from WG LC, waiting for resolution.' added by Margaret Wasserman
2005-05-26
40 (System) New version available: draft-ietf-dnsext-mdns-40.txt
2005-05-10
47 Margaret Cullen
Mail to Thomas and Chairs regarding AD Review Comments

To: Bernard Aboba , narten@us.ibm.com
From: Margaret Wasserman
Subject: Re: Resolving AD review comments on draft-ietf-dnsext-mdns-39.txt …
Mail to Thomas and Chairs regarding AD Review Comments

To: Bernard Aboba , narten@us.ibm.com
From: Margaret Wasserman
Subject: Re: Resolving AD review comments on draft-ietf-dnsext-mdns-39.txt
Cc: townsley@cisco.com, Olafur...snip...Kolkman 

Hi Bernard,

I have a couple of questions on this one, and I have cc:ed the WG chairs because at least one of these questions should be answered by them.

(1) Why did you change the order of the flag bits (C, TC, Z, etc.)?  Was there a technical concern that this addresses?  Is there any concern that this will cause a problem with existing implementations if there are any?

(2) Thomas, are you satisfied that the changes that Bernard has proposed (in -39 and on the list) resolve the concerns that you raised in AD review (message sent 2004-08-27 with subject: Re: Publication Requested: LLMNR document (MDNS-34) )?

(3) Olaf and Olafur, there have been 5 revisions of this document since it was submitted for publication (-34 was submitted and we are now at -39), and a quick look at the diffs shows some fairly substantial changes during that period.  I know  that the changes have been individually run by the WG, but I wasn't on the list until March, and I haven't seen much discussion of the resolutions that have been suggested since then.

Has the WG reached consensus on the resolution of these issues?  Are you satisfied that the current version has been adequately reviewed by the WG?  And that it represents WG consensus?  I wouldn't like to surprise the WG by sending this version to IETF LC.

Thanks,
Margaret
2005-05-10
47 Margaret Cullen
[Note]: '2005-05-10:  Wrote to Bernard, Thomas & WG Chairs to see if AD Review comments are resolved and document is ready for IETF LC (See …
[Note]: '2005-05-10:  Wrote to Bernard, Thomas & WG Chairs to see if AD Review comments are resolved and document is ready for IETF LC (See Comments).' added by Margaret Wasserman
2005-03-28
39 (System) New version available: draft-ietf-dnsext-mdns-39.txt
2005-03-11
47 Mark Townsley Shepherding AD has been changed to Margaret Wasserman from Thomas Narten
2005-02-21
47 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-02-21
38 (System) New version available: draft-ietf-dnsext-mdns-38.txt
2005-02-01
47 Thomas Narten State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Thomas Narten
2005-01-21
47 Thomas Narten
From: Bernard Aboba
To: llmnr-design@internaut.com
cc: narten@us.ibm.com, margaret@thingmagic.com
Date: Mon, 10 Jan 2005 08:14:59 -0800 (PST)
Subject: [llmnr-design] Re: Proposed Resolution of LLMNR Issue …
From: Bernard Aboba
To: llmnr-design@internaut.com
cc: narten@us.ibm.com, margaret@thingmagic.com
Date: Mon, 10 Jan 2005 08:14:59 -0800 (PST)
Subject: [llmnr-design] Re: Proposed Resolution of LLMNR Issue 78
Reply-To: Bernard Aboba

I'll be scheduling a conference call next week to follow up on this issue.
How would Monday, January 17, 2005 at 9 AM Pacific time work?

On Sun, 26 Dec 2004, Bernard Aboba wrote:

> In the AD review of draft-ietf-dnsext-mdns-37.txt, Thomas questioned
> whether the LLMNR name conflict detection mechanism was sufficiently
> robust. While the issue was originally raised with respect to the
> initial uniqueness verification, name conflicts can also occur on an
> ongoing basis, such as after healing of a network partition.
>
> The issue was filed as Issue 78 on the LLMNR Issues List:
> http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
>
> In the AD review, a number of potential solutions were suggested. Since
> only LLMNR queries are sent via multicast, modifications to the query
> packet appear to be required in order to resolve the problem.
>
> One of the original design assumptions of LLMNR was that name conflicts
> were sufficiently infrequent that it did not make sense to check for
> conflicts on an ongoing basis, only during an initial uniqueness
> verification phase.
>
> However, with LLMNR proposed for usage in scenarios where partitioning and
> healing may occur frequently, such as adhoc wireless networks, an argument
> can be made that support for ongoing conflict detection is required.
>
> In order to improve the robustness of the initial uniqueness
> verifiation as well as to support ongoing conflict detection, I've
> put together a proposed Issue resolution, available for inspection
> here:
> http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 78
>
> A version of the LLMNR specification with all the changes applied is
> available here:
> http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-38.txt
>
> Before sending the proposed changes off to the DNSEXT WG mailing list, I'd
> first like to hear your opinion on the whether the Issue is worth
> fixing, and whether the proposed solution makes sense.
>
> The recommended solution is for LLMNR senders to include their UNIQUE
> resource records within the additional section of a query, and for
> responders to check queries for potential name conflicts.  This solution
> applies both to the initial uniqueness verification phase as well as to
> ongoing conflict detection.
>
2005-01-21
47 Thomas Narten [Note]: '2005-01-21: WG is still discussing issues arising from AD review. E.g., see comment log.' added by Thomas Narten
2004-11-11
47 Thomas Narten [Note]: '2004-11-11: WG is still discussing issues arising from AD review.' added by Thomas Narten
2004-10-21
37 (System) New version available: draft-ietf-dnsext-mdns-37.txt
2004-09-10
36 (System) New version available: draft-ietf-dnsext-mdns-36.txt
2004-09-08
35 (System) New version available: draft-ietf-dnsext-mdns-35.txt
2004-08-27
47 Thomas Narten State Changes to AD Evaluation from Publication Requested by Thomas Narten
2004-08-27
47 Thomas Narten [Note]: '2004-08-27: AD review complete (see log), waiting for response from authors.' added by Thomas Narten
2004-08-27
47 Thomas Narten
From: Thomas Narten
To: Bernard Aboba
cc: margaret@thingmagic.com, presnick@qualcomm.com, ogud@ogud.com,
    olaf@ripe.net, erik.guttman@sun.com
Date: Fri, 27 Aug 2004 12:08:41 -0400 …
From: Thomas Narten
To: Bernard Aboba
cc: margaret@thingmagic.com, presnick@qualcomm.com, ogud@ogud.com,
    olaf@ripe.net, erik.guttman@sun.com
Date: Fri, 27 Aug 2004 12:08:41 -0400
Subject: Re: Publication Requested: LLMNR document (MDNS-34)

Here is my AD review. Not sure how serious these are, but I suspect we
might want to iterate once more before doing the LC. Advice solicited.

Should I send these to the WG directly? Or do you want to just break
them up into issues and deal with them that way?

PS, any particular reason why Pete is cc'ed? First I've heard that
he's interested in this document ... not that that is a bad
thing... Just curious.

Thomas

2004-08-26: WG says it is done, review of -34

>    becomes ubiquitous.  For example, expanded support for multicast name
>    resolution might be required for mobile ad-hoc networking scenarios,
>    or where no DNS server is available that is authoritative for the
>    names of local hosts, and can support dynamic DNS, such as in
>    wireless hotspots.

reword? sentence is hard to parse (especially last part).

> Reachable
>      An address is considered reachable over a link if either an ARP or
>      neighbor discovery cache entry exists for the address on the link.

funny definition, since an ARP/ND entry might exists but be very old.

>    [1] No manual or automatic DNS configuration has been
>        performed.  If an interface has been configured with DNS
>        server address(es),  then LLMNR SHOULD NOT be used as the
>        primary name resolution mechanism on that interface, although
>        it MAY be used as a name resolution mechanism of last resort.

DNS server addresses are not what I'd consider "per-interface"
information.

>    packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
>    accept UDP queries and responses as large as permitted by the link
>    MTU.

Some links support ridiculous MTUs (e.g., 65K). Would it be useful to
place an upper bound on the max size to something big, but not
ridiculous? E.g., 5K? 10k?

>      queries. The ID field in a query SHOULD be set to a pseudo-random
>      value.

Does this need to be unpredictable for security? If so, say so, and
perhaps cite the relevant RFC.

>      by an LLMNR responder.  If the TC bit is set an LLMNR response,

s/an/in an/

>      by an LLMNR responder.  If the TC bit is set an LLMNR response,
>      then the sender MAY use the response if it contains all necessary
>      information, or the sender MAY discard the response and resend the
>      LLMNR query over TCP using the unicast address of the responder as
>      the destination address.  See  [RFC2181] and Section 2.4 of this
>      specification for further discussion of the TC bit.

section 9 of 2181 does not allow use of a partial response. the issue
is that one can't know whether all the data that one needs is in the
response. Should this spec be deviating from DNS here? I suspect not,
especially since truncation should be much less of an issue given the
requirement that the link MTU be supported.

>      If an LLMNR responder is authoritative for the name in a multicast
>      query, but an error is encountered, the responder SHOULD send an
>      LLMNR response with an RCODE of zero, no RRs in the answer section,
>      and the TC bit set.  This will cause the query to be resent using
>      TCP, and allow the inclusion of a non-zero RCODE in the response to
>      the TCP query.  Responding with the TC bit set is preferable to not
>      sending a response, since it enables errors to be diagnosed.

Don't follow the above. "but an error" is general (not just for too
much data to fit in response). Why would requerying with TCP get a
better response?

>      LLMNR implementations MUST support EDNS0 [RFC2671] and extended
>      RCODE values.

Is this necessary? Earlier, the spec says non-zero RCODEs must be
ignored. Isn't an EDNS0 extended RCODE by definition non-zero (I
couldn't quite tell from a quick check, but that would seem to be the
case.)

>    (e.g.  A, AAAA, SRV, etc.) to the link-scope multicast address.

s/e.g./e.g.,/

>    Since the responder may order the RRs in the response so as to
>    indicate preference, the sender SHOULD preserve ordering in the
>    response to the querying application.

this is a change from DNS.

>    Upon configuring an IP address responders typically will synthesize

s/address/address,/

>    6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
>    ip6.arpa IN PTR host1.
>    IN PTR host1.example.com.

Text should  somehow indicate that the  above is one line that had to
be split for formatting reasons...

> [b]  Responders MUST direct responses to the port from which the query
>      was sent.  When queries are received via TCP this is an inherent
>      part of the transport protocol.  For queries received by UDP the
>      responder MUST take note of the source port and use that as the
>      destination port in the response.  Responses SHOULD always be sent
>      from the port to which they were directed.

SHOULD is no good here, unless you also specify what sender MUST do.

> [e]  Responders MUST NOT respond using cached data.

add something like "learned from other LLMNR queries" (or DNS queries,
etc....)

> [f]  If a DNS server is running on a host that supports LLMNR, the DNS
>      server MUST respond to LLMNR queries only for the RRSets relating
>      to the host on which the server is running, but MUST NOT respond
>      for other records for which the server is authoritative.  DNS
>      servers also MUST NOT send LLMNR queries in order to resolve DNS
>      queries.

Might be better to say something like "if the same process/application
implements both LLMNR and DNS (e.g., for code sharing purposes),
.... the must keep things logically separate".

> [g]  If a responder is authoritative for a name, it MAY respond with
>      RCODE=0 and an empty answer section, if the type of query does not
>      match a RR that the responder has.

why the MAY? Is this useful? What impact does this have on a
recipient??

>    As an example, a host configured to respond to LLMNR queries for the
>    name "foo.example.com."  is authoritative for the name
>    "foo.example.com.".  On receiving an LLMNR query for an A RR with the
>    name "foo.example.com." the host authoritatively responds with A
>    RR(s) that contain IP address(es) in the RDATA of the resource
>    record.  If the responder has a AAAA RR, but no A RR, and an A RR
>    query is received, the responder would respond with RCODE=0 and an
>    empty answer section.

above won't happen if [g] is only a MAY....

>    For IPv4, an "on link" address is defined as a link-local address
>    [IPv4Link] or an address whose prefix belongs to a subnet on the
>    local link.  For IPv6 [RFC2460] an "on link" address is either a
>    link-local address, defined in [RFC2373], or an address whose prefix
>    belongs to a subnet on the local link.

Actually 2461 has a very specific definition of on-link. It's one
where the RA says the prefix is "on link". This may in some cases be
different than what is stated above. There maybe a subtle limitation
here. 2461 allows routers to say "nothing is on link, send it to me",
even if it then forwards stuff back onto the same link. This feature
is not being used today, but might be used in the future.

>    For UDP queries and responses the Hop Limit field in the IPv6 header,

s/responses/responses,/ and drop the last , ??

>    Routable addresses MUST be included first in the response, if
>    available.  This encourages use of routable address(es) for
>    establishment of new connections.

hmm.

>    If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
>    then a sender MAY repeat the transmission of the query in order to
>    assure that it was received by a host capable of responding to it.

MAY? Come on, this should be a SHOULD/MUST. It's hardly robust to do
this query exactly one time.

>    The responder should use a pre-configured TTL value in the records
>    returned an LLMNR response.  A default value of 30 seconds is

s/an/in an/?

>    The responder should use a pre-configured TTL value in the records
>    returned an LLMNR response.  A default value of 30 seconds is

s/use a/insert a/ ??

>    Responders SHOULD NOT perform DNS additional section processing,
>    except as required for EDNS0 and DNSSEC.

DNSSEC is a part of this?

>    For example, if the configured DNS server responds to AAAA RR queries
>    sent over IPv4 or IPv6 with an authoritative name error (RCODE=3),
>    then it will not be possible to resolve the names of IPv6-only hosts.
>    In this situation, LLMNR over IPv6 can be used for local name
>    resolution.

seems to narrow. Getting RCODE=3 for one query, can't be generalized
to say AAAA is not supported at all by that server.

>    Unless unconfigured hosts periodically retry configuration, an outage
>    in the DNS configuration mechanism will result in hosts continuing to
>    use LLMNR even once the outage is repaired.  Since LLMNR only enables
>    linklocal name resolution, this represents an unnecessary degradation
>    in capabilities.  As a result, it is recommended that hosts without a
>    configured DNS server periodically attempt to obtain DNS
>    configuration.  For example, where DHCP is used for DNS
>    configuration, [RFC2131] recommends a maximum retry interval of 64
>    seconds.  In the absence of other guidance, a default retry interval
>    of one (1) minute is RECOMMENDED.

Again, this seems simplistic. You should not go back to your DHC
server every 64 seconds if has given you parameters other than DNS.

>    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; the
>    sender perceives no inherent conflict in the receipt of multiple
>    responses.

Do you mean concatenate valid answers? it doesn't make sense to
concatenate various errors, ...

>    There are some scenarios when multiple responders MAY respond to the
>    same query.  There are other scenarios when only one responder MAY
>    respond to a query.  Resource records for which the latter queries

MAY seems wrong here. MAY is not about implementation choices (when
you receive them...)

>    Every responder that responds to an LLMNR query AND includes a UNIQUE
>    record in the response:

This is an odd use/defn. of UNIQUE. UNIQUE depends on there being only
one response. The words here seem to say that the responder (if it
cares) needs to ensure this. But the wording is weak. When does a
responder care about a UNIQUE record? If not, it won't bother doing
any steps.

>    [1]  MUST verify that there is no other host within the
>        scope of the LLMNR query propagation that can return
>        a resource record for the same name, type and class.

What resonder cares about this?

If you are trying to say that there are certain RRsets that must be
unique, then better just say that...

>    Where a host is configured to issue LLMNR queries on more than one
>    interface, each interface should have its own independent LLMNR
>    cache. 

what exactly is in such a cache?

>    cache.  For each UNIQUE resource record in a given interface's
>    configuration, the host MUST verify resource record uniqueness on
>    that interface.  To accomplish this, the host MUST send an LLMNR
>    query for each UNIQUE resource record.

again, I sense that a UNIQUE RR is something that needs to be
configured. Are there words to that effect somewhere?

>    record, the host MUST respond.  After the client receives a response,

Who is the client now? Is this not just requester?

>    record, the host MUST respond.  After the client receives a response,
>    it MUST check whether the response arrived on an interface different
>    from the one on which the query was sent.  If the response arrives on
>    a different interface, the client can use the UNIQUE resource record
>    in response to LLMNR queries.  If not, then it MUST NOT use the
>    UNIQUE resource record in response to LLMNR queries.

I'm confused. Is this part of the uniqueness verification algorithm?
It seems like the first sentence and the rest of the paragraph don't
quite go together.
2004-08-27
47 Thomas Narten State Change Notice email list have been change to ogud@ogud.com, okolkman@ripe.net, levone@microsoft.com, aboba@internaut.com, dthaler@microsoft.com from ogud@ogud.com, okolkman@ripe.net
2004-08-12
47 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2004-08-11
34 (System) New version available: draft-ietf-dnsext-mdns-34.txt
2004-07-20
33 (System) New version available: draft-ietf-dnsext-mdns-33.txt
2004-06-29
32 (System) New version available: draft-ietf-dnsext-mdns-32.txt
2004-06-28
31 (System) New version available: draft-ietf-dnsext-mdns-31.txt
2004-03-26
30 (System) New version available: draft-ietf-dnsext-mdns-30.txt
2004-01-20
29 (System) New version available: draft-ietf-dnsext-mdns-29.txt
2004-01-09
28 (System) New version available: draft-ietf-dnsext-mdns-28.txt
2003-12-18
27 (System) New version available: draft-ietf-dnsext-mdns-27.txt
2003-12-15
26 (System) New version available: draft-ietf-dnsext-mdns-26.txt
2003-12-01
25 (System) New version available: draft-ietf-dnsext-mdns-25.txt
2003-09-29
24 (System) New version available: draft-ietf-dnsext-mdns-24.txt
2003-09-12
23 (System) New version available: draft-ietf-dnsext-mdns-23.txt
2003-07-23
22 (System) New version available: draft-ietf-dnsext-mdns-22.txt
2003-06-10
21 (System) New version available: draft-ietf-dnsext-mdns-21.txt
2003-05-21
20 (System) New version available: draft-ietf-dnsext-mdns-20.txt
2003-05-13
19 (System) New version available: draft-ietf-dnsext-mdns-19.txt
2003-05-02
18 (System) New version available: draft-ietf-dnsext-mdns-18.txt
2003-04-17
17 (System) New version available: draft-ietf-dnsext-mdns-17.txt
2003-04-10
16 (System) New version available: draft-ietf-dnsext-mdns-16.txt
2003-04-03
15 (System) New version available: draft-ietf-dnsext-mdns-15.txt
2003-03-24
14 (System) New version available: draft-ietf-dnsext-mdns-14.txt
2002-12-03
13 (System) New version available: draft-ietf-dnsext-mdns-13.txt
2002-08-27
12 (System) New version available: draft-ietf-dnsext-mdns-12.txt
2002-07-24
11 (System) New version available: draft-ietf-dnsext-mdns-11.txt
2002-03-26
10 (System) New version available: draft-ietf-dnsext-mdns-10.txt
2002-02-28
09 (System) New version available: draft-ietf-dnsext-mdns-09.txt
2002-01-07
08 (System) New version available: draft-ietf-dnsext-mdns-08.txt
2001-11-27
07 (System) New version available: draft-ietf-dnsext-mdns-07.txt
2001-10-12
06 (System) New version available: draft-ietf-dnsext-mdns-06.txt
2001-09-20
05 (System) New version available: draft-ietf-dnsext-mdns-05.txt
2001-09-14
04 (System) New version available: draft-ietf-dnsext-mdns-04.txt
2001-07-20
03 (System) New version available: draft-ietf-dnsext-mdns-03.txt
2001-07-19
02 (System) New version available: draft-ietf-dnsext-mdns-02.txt
2001-07-09
01 (System) New version available: draft-ietf-dnsext-mdns-01.txt
2000-11-17
00 (System) New version available: draft-ietf-dnsext-mdns-00.txt