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 … |
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 |