RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

Christian Huitema wrote:

>if an application tries to resolve
>"host.local" through, say, gethostbyname, then the query will
>indeed be forwarded to the local DNS service. The responsibility
>for the ".local" traffic lies mostly into whoever is promoting use
>of this top level domain and coding that use in applications.

That would be Microsoft:



>The Domain Name System name recommendations for
>Small Business Server 2000 and Windows Small Business Server 2003

>July 16, 2004

>Make the name a private domain name that is used for name resolution
>on the internal Small Business Server network. This name is usually
>configured with the first-level domain of .local. At the present
>time, the .local domain name is not registered on the Internet.

>The natural separation of internal and external networks
>occurs because of the use of a separate internal namespace.
>A client query generated from the Internet for www.contoso.local
>does not return any valid domain information because .local, at
>the present time, is not a registered domain name.

>Name resolution problems that are created by using a publicly
>registered domain name can be avoided by planning the private
>namespace around a .local first-level domain so that, in this example,
>Contoso.com and Contoso.local are both available to internal clients,
>but Contoso.com is only available to external internet clients.

A suspicious person might think that the reason Microsoft is trying
to encourage its customers to use ".local" is a deliberate attempt
to foster interoperability problems with machines running mDNS.
I do not think that. I'm sure there must be a perfectly reasonable
non-Machiavelian explanation for why Microsoft is advocating use of
the ".local" DNS domain. I just don't know what it is right now.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Andrew Sullivan]

On Tue, Aug 30, 2005 at 12:29:37PM -0400, Margaret Wasserman wrote:
> Other than a few minor issues that are being dealt with in a -43 
> update, I don't think that anyone has raised a blocking technical 
> issue with the LLMNR specification during this IETF LC.  If you (or 

I did not follow the development of the LLMNR drafts; but the
discussion on this list inspired me to review the latest (-43)
Internet Draft.  Having reviewed it, I do not think it should be
published as a Proposed Standard.

My greatest concern is that the document as it stands is likely to
cause a large number of bogus DNS queries.  If the protocol is widely
adopted, it seems probable that many clients will have LLMNR enabled
on an interface in a situation where a DNS server has been configured
(as described in section 2).  In that case, every LLMNR query will
entail (possibly more than) one DNS query, because of the provision,
"All attempts to resolve the name via DNS on all interfaces have
failed after exhausting the searchlist."  Such DNS queries will become
commonplace if the protocol is widely adopted and widely used.  This
feature of the design appears to increase the burden on the entire
Internet infrastructure in order to support unshared infrastructure.

My second worry is that, because the behaviour changes depending on
the results from the DNS query, this protocol will sometimes, if not
often, violate the principle of least surprise.  It also opens a
whole new model for "phishing" attacks, particularly in the context
of ubiquitous wireless access points.  

Because of the foregoing, I do not believe LLMNR, in its current
form, should be adopted as a Proposed Standard.

Regards,
Andrew Sullivan

-- 

Andrew Sullivan 204-4141 Yonge Street
Afilias CanadaToronto, Ontario Canada
<[EMAIL PROTECTED]>  M2P 2A8
+1 416 646 3304 x4110


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Daniel Karrenberg]

On 31.08 14:47, Brian E Carpenter wrote:
> 
> That is about 1/3 of the total. It doesn't surprise me at all that
> so many bogus queries arrive - everybody who mistypes a TLD or
> misconfigures a default domain generates bogus queries, and this isn't
> going to change. The question is whether .local is a *significant*
> part of this load. The limited data I have suggest not, but I'd like
> to see publicly available data: what fraction of those NXDOMAINs are
> due to .local?

I believe CAIDA has published something but I cannot find it.
I have had a quick look myself:

Cursory observation of a random sampple from 2004 which I have used for 
other purporses shows that about 15% of the NXDOMAIN answers excluiding 
'.arpa.' are for questions ending in .local. A further 3% are for 
'localhost' and about 20% are for an IP address in dotted-quad format.

The .local queries have a high incidence of labels beginning with 
an underscore and often conain the string "Default-First-Site" in 
various languages such as illustrated by the following examples:

SOA? _kerberos._tcp.Default-First-Site-Name._sites.capital.local
SRV? _ldap._tcp.dc._msdcs.bsztorgau.local
SOA? _kpasswd._tcp.AppliedEngineeringServices.local
SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.semaia.local
SRV? 
_ldap._tcp.a9c93f95-51af-4f5d-8280-1171e79176c4.domains._msdcs.Netcare.local
SOA? 
_ldap._tcp.Standardname-des-ersten-Standorts._sites.gc._msdcs.VESTERBERG.local
SOA? _kerberos._tcp.Nombre-predeterminado-primer-sitio._sites.d1asib03.local
SRV? _ldap._tcp.Premier-Site-par-defaut._sites.dc._msdcs.production.local
SOA? _kerberos._udp.Christ.local
SRV? _ldap._tcp.dc._msdcs.production.local
SRV? 
_ldap._tcp.3b6c4c19-2d29-4ed0-9915-b7b43f3488e3.domains._msdcs.datalog.local
SOA? _kpasswd._udp.tae.local
SOA? _ldap._tcp.Default-First-Site._sites.gc._msdcs.ufficio-tecnico.local

Preventing an increase of this nonsense from getting worse or even reducing
it is a worthy cause because root servers can use all the headroom they can
get. 

Note that this is only an random sample and as such is just an indication
of what is happening. It should be considered not more than anecdotal evidence.

Note also that I do not read the ietf list.

Daniel


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[JFC (Jefsey) Morfin]

At 13:34 01/09/2005, Keith Moore wrote:
You appear to be confusing "a protocol for resolving names locally" 
with "a protocol for resolving local names".  They don't have to be 
the same thing.


I fail to see what these propositions bring that local name servers 
with small addition in db.local and caching strategy could not be 
used to provide? Or am I misreading  them?

jfc


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Ian Jackson]

Keith Moore writes:
> LLMNR isn't a competitor to mDNS.  They attempt to address different 
> problems.

We see to be living in some kind of Alice Through the Looking Glass
world here.  The llmnr drafts are even called `-mdns-' !

> I favor adoption of LLMNR because in a world of disconnected and 
> intermittently connected networks there's a need for applications to 
> still be able to work - and being able to "work" includes being able to 
> lookup the same DNS names that the applications would normally use in a 
> connected network.

This is not what people are trying to deploy it for, and it is
distinctly unclear that LLMNR is at all the right answer for this
problem.

Ian.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Paul Vixie]

# But what about the other direction? When IETF reserves a name, is it
# always null-routed to AS112? It does not seem so, ".example" (RFC
# 2606), for instance, is not "delegated".

if as112 is asked, my bet is, as112 will cooperate.

for .example, as112 wasn't asked.  (yet?)

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stephane Bortzmeyer]

On Thu, Sep 01, 2005 at 02:58:17PM +,
 Paul Vixie <[EMAIL PROTECTED]> wrote 
 a message of 19 lines which said:

> yes, but only when some rfc reserves .local the way rfc1918 reserves
> the 10.in-addr.arpa and other names handled by AS112.  (IANA will,
> properly, refuse to add a .LOCAL NS RR pointing at AS112 or anywhere
> else until IETF reserves this name.)

In that direction (IANA waiting for IETF), I understand.

But what about the other direction? When IETF reserves a name, is it
always null-routed to AS112? It does not seem so, ".example" (RFC
2606), for instance, is not "delegated".

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Paul Vixie]

# That said, if people want to limit the effect of these 'bogus' queries
# onto the root servers I suggest that ISP's join into the AS112 project.
# Also it would maybe be an idea for AS112 to add .local there?

yes, but only when some rfc reserves .local the way rfc1918 reserves the
10.in-addr.arpa and other names handled by AS112.  (IANA will, properly,
refuse to add a .LOCAL NS RR pointing at AS112 or anywhere else until IETF
reserves this name.)

# PS: Who ever named the LLMNR draft 'mdns' isn't that completely
# confusing for people looking up the mDNS draft, that is the protocol
# that Stuart made? :)

yes.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Tony Finch]

On Thu, 1 Sep 2005, Iljitsch van Beijnum wrote:
>
> I don't understand how you can be in favor of LLMNR while at the same time
> being opposed to confusion between local and global ("DNS") names. In theory,
> I suppose it's possible that the information available over LLMNR and the
> information available from the DNS are 100% consistent.

Is LLMNR supposed to work with RFC 3927 IPv4 link-local address
autoconfiguration? In which case it's also theoretically impossible for
LLMNR to be consistent with the DNS. (Consistency would require dynamic
DNS updates, and if they work your DHCP server should also be working, in
which case you won't have an RFC 3927 address.)

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Alan Barrett]

On Thu, 01 Sep 2005, Keith Moore wrote:
> LLMNR doesn't provide lookups for "local names" - it provides a local
> service that can be used to query for attributes of DNS names.

In other words, if I understand correctly, LLMNR is intended for
use in the situation where your printer is named something like
"myprinter.myrealdomain.tld", where "myrealdomain.tld" is a domain name
that you have the right to use in the DNS, but the DNS is not working
for you right now.  LLMNR is *not* intended for use in the situation
where your printer is named "MYPRINTER" or "myprinter.local", or
"myprinter.randomstuff".

--apb (Alan Barrett)

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Iljitsch van Beijnum]

On 1-sep-2005, at 13:34, Keith Moore wrote:

No.  Or at least, the point of having something like a link-local  
name resolution protocol is that you can use the same interfaces  
to look up the local names when using the link-local protocol, as  
you do
 when looking up real DNS names when using the real DNS protocol.  
That way all the existing applications work and don't need to be  
changed.



False.  That way, you break various kinds of applications because you
violate assumptions that those applications quite reasonably made  
about

the APIs and services they were using, and you flood the DNS with
useless queries.  This is the same kind of problem that resulted from
introduction of NAT.


I find this a very curious position. Basically you're saying that the  
namespace for local lookups and global lookups must be so separate,  
that they can't even use the same code paths. I really don't see that  
having a clear separation between the two that is PART of the  
combined namespace (i.e., one or more global TLDs, one (or more?)  
local TLDs) would be insufficient here.


Otherwise you would be suggesting building an entirely new  
protocol and application stack, with changes to every application  
to support the link-local scheme, which is obviously out of the  
question.


Actually, it's the only approach that makes any sense.  The idea  
that you can substitute a name service that works differently from  
what applications expect, without breaking some of those  
applications, is extremely naive.


Which reasonable expectation are you talking about?


I'm opposed to the concept of confusing resolution of local names
with resolution of DNS names.


[...]

I favor adoption of LLMNR because in a world of disconnected and  
intermittently connected networks there's a need for applications  
to still be able to work - and being able to "work" includes being  
able to lookup the same DNS names that the applications would  
normally use in a connected network.


I don't understand how you can be in favor of LLMNR while at the same  
time being opposed to confusion between local and global ("DNS")  
names. In theory, I suppose it's possible that the information  
available over LLMNR and the information available from the DNS are  
100% consistent. In practice, this is of course completely  
impossible, and unless my memory is going faster than I thought, the  
draft doesn't even address this issue. So effectively, there will be  
a local namespace available over LLMNR and a global one available  
from the DNS, with an overlap somewhere betwee 0 and 1. An  
application then has no way to know which namespace provided a  
certain result.



I favor discouraging use of mDNS


Let's be clear that this is a completely separate issue from whether  
the LLMNR protocol is the right answer to the right question.


because I believe it harms interoperability of Internet  
applications and operation of the DNS.


How, exactly?

I would like to see a solution for the lookup of local names that  
did not have these characteristics.  If that solution can be  
derived from the mDNS protocol, that's fine with me, but it  
shouldn't overload the DNS lookup APIs nor should it borrow the DNS  
name syntax.


That seems unnecessarily conservative. Even if you find the "separate  
TLD" solution unacceptable, local names can still be put in a DNS  
class of their own. Classes were invented for exactly this reason, if  
memory serves.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Henning Schulzrinne]

Maybe something like a Service Location Protocol, so that one could 
query by a combination of properties, not just name?


Keith Moore wrote:

Dave Singer wrote:

The whole idea that 'real DNS' can arbitrarily pre-empt local name 
resolution seems, well, wrong, and needs serious study for security 
implications for the services using those names, no?



The whole idea that local names should look like DNS names and be 
queried through the same APIs and user interfaces seems, well, wrong (or 
dubious at best), and needs serious study for the implications of 
applications using those APIs and the impact of such names on DNS, no?


IMO, local names and a lookup service for local names would be extremely 
useful, but neither the names nor the query interface should look much 
like DNS - the names should look different because otherwise there's too 
much potential for confusion with DNS names, and the query service 
should look different because local name lookup service probably can't 
make the same kinds of consistency or stability assurances that DNS does.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Keith Moore]

The whole idea that local names should look like DNS names and be 
queried through the same APIs and user interfaces seems, well, 
wrong (or dubious at best), and needs serious study for the 
implications of applications using those APIs and the impact of 
such names on DNS, no?



No.  Or at least, the point of having something like a link-local 
name resolution protocol is that you can use the same interfaces to 
look up the local names when using the link-local protocol, as you do
 when looking up real DNS names when using the real DNS protocol. 
That way all the existing applications work and don't need to be 
changed.


False.  That way, you break various kinds of applications because you
violate assumptions that those applications quite reasonably made about
the APIs and services they were using, and you flood the DNS with
useless queries.  This is the same kind of problem that resulted from
introduction of NAT.

Otherwise you would be suggesting building an entirely new protocol 
and application stack, with changes to every application to support 
the link-local scheme, which is obviously out of the question.


Actually, it's the only approach that makes any sense.  The idea that 
you can substitute a name service that works differently from what 
applications expect, without breaking some of those applications, is 
extremely naive.


So what you're saying is that you're opposed to whole concept of 
link-local name resolution.


No, I'm opposed to the concept of confusing resolution of local names
with resolution of DNS names.


And that therefore you favour LLMNR because it doesn't (in your view)
 provide it !


LLMNR isn't a competitor to mDNS.  They attempt to address different 
problems.


I favor adoption of LLMNR because in a world of disconnected and 
intermittently connected networks there's a need for applications to 
still be able to work - and being able to "work" includes being able to 
lookup the same DNS names that the applications would normally use in a 
connected network.


I favor discouraging use of mDNS because I believe it harms 
interoperability of Internet applications and operation of the DNS.  I 
would like to see a solution for the lookup of local names that did not 
have these characteristics.  If that solution can be derived from the 
mDNS protocol, that's fine with me, but it shouldn't overload the DNS 
lookup APIs nor should it borrow the DNS name syntax.



Of course you are wrong on this last point - LLMNR will be deployed
behind the same APIs currently used to do real DNS lookups.


LLMNR doesn't provide lookups for "local names" - it provides a local
service that can be used to query for attributes of DNS names.


IMO, local names and a lookup service for local names would be 
extremely useful, but neither the names nor the query interface 
should look much like DNS - the names should look different because

 otherwise there's too much potential for confusion with DNS names,
 and the query service should look different because local name 
lookup service probably can't make the same kinds of consistency or

 stability assurances that DNS does.



To say that, is to say that work on LLMNR should never have been 
started.  There is no demand for a local name resolution protocol 
which doesn't present a DNS API to applications.


You appear to be confusing "a protocol for resolving names locally" with 
"a protocol for resolving local names".  They don't have to be the same 
thing.



You may well say that the whole concept of local name resolution, if
 it must be presented to applications behind a DNS API, is a bad idea
 and I have some sympathy with that view - but that's no argument for
 LLMNR against mDNS !

Stuart seems to be claiming that the people who first told him to 
take is mDNS away from the IETF, and LLMNR's authors, have that view 
- and that LLMNR is the result of those people producing a protocol 
which is intended to look enough like mDNS to fool people but is 
deliberately _not_ intended to do any of the things that mDNS is good

 for !


LLMNR _looks like_ mDNS because both were intended for looking up names 
on a disconnected network, and because both were based on DNS.  That 
doesn't mean LLMNR _is trying to solve the same problem_ as mDNS.


Keith


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Dave Singer wrote:
I'm a by-stander on this discussion, maybe off-base or out of it -- but 
something other than the undesirable traffic struck me.


Isn't it also true that I might *deliberately break* all sorts of things 
by introducing 'blocking' names into DNS responses, so that an LLMNR 
request is never issued.  So an ISP could 'grab' traffic that the users 
thought was local, by replying to a DNS request in a proxy (or 
converting a negative reply into an answer).


Yes,

we have done that accidently. We were told we have broken things on
windows by publishing ".local" in the Public-Root.

We stopped publishing that domain immediately. But yes, all you have
to do is send some random packets, resolving '.local' to the windows
box. The thing will happily cache them and next time ...



Also, ISPs might be tempted to start turning around DNS requests in 
their proxies for names that they *think* should be answered by LLMNR, 
returning resolution failure, so as not to send too much traffic 
outbound.  This pre-empts the real DNS from ever actually replying.


The whole idea that 'real DNS' can arbitrarily pre-empt local name 
resolution seems, well, wrong, and needs serious study for security 
implications for the services using those names, no?





--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

A friend just called to teach me how to spell LLMNR.
Sorry I can not do that without looking it up.

And he told me not to be so harsh with it. Yes they
need it. Their bot controler needs it.

No, you dont need a windows for the controler, MAC
or Linux does nicely. But the total cost of ownership
of a hijacked windows - you know ...

And he asked my not to tell you the details, like
windows caching used horseshoes or Netbios packets
remotely looking like DNS, or he would shot me or
ask the Apple Music Company (no, not the MAC people)
to do it :)




Kind regards,
Peter and Karin Dambier

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Ian Jackson]

Keith Moore writes ("Re: Last Call: 'Linklocal Multicast Name Resolution    
(LLMNR)'    to   Proposed Standard"):
> The whole idea that local names should look like DNS names and be 
> queried through the same APIs and user interfaces seems, well, wrong (or 
> dubious at best), and needs serious study for the implications of 
> applications using those APIs and the impact of such names on DNS, no?

No.  Or at least, the point of having something like a link-local name
resolution protocol is that you can use the same interfaces to look up
the local names when using the link-local protocol, as you do when
looking up real DNS names when using the real DNS protocol.  That way
all the existing applications work and don't need to be changed.
Otherwise you would be suggesting building an entirely new protocol
and application stack, with changes to every application to support
the link-local scheme, which is obviously out of the question.

So what you're saying is that you're opposed to whole concept of
link-local name resolution.  And that therefore you favour LLMNR
because it doesn't (in your view) provide it !  Of course you are
wrong on this last point - LLMNR will be deployed behind the same APIs
currently used to do real DNS lookups.

I think that what you've done with your posting, really, is
demonstrate Stuart Cheshire's claim that LLMNR is for blocking effort !

> IMO, local names and a lookup service for local names would be extremely 
> useful, but neither the names nor the query interface should look much 
> like DNS - the names should look different because otherwise there's too 
> much potential for confusion with DNS names, and the query service 
> should look different because local name lookup service probably can't 
> make the same kinds of consistency or stability assurances that DNS does.

To say that, is to say that work on LLMNR should never have been
started.  There is no demand for a local name resolution protocol
which doesn't present a DNS API to applications.

You may well say that the whole concept of local name resolution, if
it must be presented to applications behind a DNS API, is a bad idea
and I have some sympathy with that view - but that's no argument for
LLMNR against mDNS !

Stuart seems to be claiming that the people who first told him to take
is mDNS away from the IETF, and LLMNR's authors, have that view - and
that LLMNR is the result of those people producing a protocol which is
intended to look enough like mDNS to fool people but is deliberately
_not_ intended to do any of the things that mDNS is good for !

Ian.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Jeroen Massar]

On Thu, 2005-09-01 at 09:38 +0200, Frank Ellermann wrote:
> Jeroen Massar wrote:
>  
> > [for as112 project: maybe add .local into the list of domains??]
> 
> (?)  Better add ".local" to a hypothetical 2606bis.  Bye, Frank

Full ack.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Frank Ellermann]

Jeroen Massar wrote:
 
> [for as112 project: maybe add .local into the list of domains??]

(?)  Better add ".local" to a hypothetical 2606bis.  Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Jeroen Massar]

[for as112 project: maybe add .local into the list of domains??]

On Wed, 2005-08-31 at 14:24 -0700, Christian Huitema wrote:
> > >Windows 98, Windows 2000 and Windows XP do not enable LLMNR by
> default.
> > 
> > Christian, could you please tell us, for each OS mentioned, how to
> enable
> > LLMNR? That would enable everyone participating in this discussion to
> > witness for themselves exactly how it works and what it does.
> 
> You would have to get an experimental implementation of LLMNR from some
> developer site.

This is not 'simply enabling it' :) And then I also wonder if there
actually is an implementation for Win98/Win2k those two being pretty old
and quite unsupported by now I guess... but this besides the point.

> To the best of my knowledge, Microsoft is not shipping
> this code. In these systems, ad hoc names are resolved through NETBIOS.
> The ".local" queries observed in Peter's root servers is most certainly
> not caused by an LLMNR implementation. 

They are most likely done by these nice DSL "router" (NAT :) setups.
Most of these devices have a .local zone configured too. I would not be
surprised if these leaked their queries to the root servers.

That said, if people want to limit the effect of these 'bogus' queries
onto the root servers I suggest that ISP's join into the AS112 project.
Also it would maybe be an idea for AS112 to add .local there?

Greets,
 Jeroen

PS: Who ever named the LLMNR draft 'mdns' isn't that completely
confusing for people looking up the mDNS draft, that is the protocol
that Stuart made? :)



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Keith Moore]

Dave Singer wrote:
The whole idea that 'real DNS' can arbitrarily pre-empt local name 
resolution seems, well, wrong, and needs serious study for security 
implications for the services using those names, no?


The whole idea that local names should look like DNS names and be 
queried through the same APIs and user interfaces seems, well, wrong (or 
dubious at best), and needs serious study for the implications of 
applications using those APIs and the impact of such names on DNS, no?


IMO, local names and a lookup service for local names would be extremely 
useful, but neither the names nor the query interface should look much 
like DNS - the names should look different because otherwise there's too 
much potential for confusion with DNS names, and the query service 
should look different because local name lookup service probably can't 
make the same kinds of consistency or stability assurances that DNS does.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Dave Singer]

I'm a by-stander on this discussion, maybe off-base or out of it -- 
but something other than the undesirable traffic struck me.


Isn't it also true that I might *deliberately break* all sorts of 
things by introducing 'blocking' names into DNS responses, so that an 
LLMNR request is never issued.  So an ISP could 'grab' traffic that 
the users thought was local, by replying to a DNS request in a proxy 
(or converting a negative reply into an answer).


Also, ISPs might be tempted to start turning around DNS requests in 
their proxies for names that they *think* should be answered by 
LLMNR, returning resolution failure, so as not to send too much 
traffic outbound.  This pre-empts the real DNS from ever actually 
replying.


The whole idea that 'real DNS' can arbitrarily pre-empt local name 
resolution seems, well, wrong, and needs serious study for security 
implications for the services using those names, no?


--
David Singer
Apple Computer/QuickTime

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Christian Huitema]

> >Windows 98, Windows 2000 and Windows XP do not enable LLMNR by
default.
> 
> Christian, could you please tell us, for each OS mentioned, how to
enable
> LLMNR? That would enable everyone participating in this discussion to
> witness for themselves exactly how it works and what it does.

You would have to get an experimental implementation of LLMNR from some
developer site. To the best of my knowledge, Microsoft is not shipping
this code. In these systems, ad hoc names are resolved through NETBIOS.
The ".local" queries observed in Peter's root servers is most certainly
not caused by an LLMNR implementation. 

In the absence of LLMNR, if an application tries to resolve "host.local"
through, say, gethostbyname, then the query will indeed be forwarded to
the local DNS service. The responsibility for the ".local" traffic lies
mostly into whoever is promoting use of this top level domain and coding
that use in applications.

-- Christian Huitema

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

Christian Huitema wrote:

>Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default.

Christian, could you please tell us, for each OS mentioned, how to enable 
LLMNR? That would enable everyone participating in this discussion to 
witness for themselves exactly how it works and what it does.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Tony Finch]

On Tue, 30 Aug 2005, Margaret Wasserman wrote:
>
> The LLMNR document already includes an informative reference to
> draft-cheshire-dnsext-multicastdns-05.txt, but it does so rather obscurely
> (citing a need to use a TTL of 255 for "compatibility with Apple Bonjour").

That doesn't make sense. Why does LLNMR need to be compatible with a
separate protocol?

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Ian Jackson]

Christian Huitema writes ("RE: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)'     to  Proposed Standard"):
> A key technical difference between LLMNR and the initial MDNS proposal
> is precisely that LLMNR has no concept of a ".local" top level domain.

While that is true, the next statement:

> Usage of LLMNR does not promote queries to this zone. 

is not.  LLMNR _requires_ the use of names which do not resolve in the
global DNS, and does a global DNS query for each lookup.  Although
LLMNR doesn't suggest the use of `.local', given that many people
don't have a suitable domain to use, they'll use `.local' or something
else.

> This is indeed a key difference between LLMNR and MDNS. MDNS assumes
> that there is a special zone for local names, which would be linked to
> the topology. LLMNR assumes that names are independent of the topology,
> that a host called "foo.example.net" retains the same name as it move to
> different locations. There were ample debates of this point in the
> working group, and the decisions to "not creating special names" and
> "not linking names to topology" do reflect WG consensus.

Even if that is so, this posistion doesn't seem to reflect IETF
consensus.

It is nonsense to say that a `link-local multicast name resolution
protocol' provides DNS data which is not linked to the topology !
To say that the _names_ are not linked to the topology is to miss the
point and thus to mislead.

Given that the _answers_ depend on the topology, wouldn't it be a good
idea to be able to indicate that this topology-dependent behaviour is
- or is not - desired ?

LLMNR only provides that switch - turning on and off topology-
dependent behaviour - on a per-host basis.  mDNS provides it on a
per-lookup basis in a nice easy-to-configure way: specify names in
.local and get topology-dependent answers; specify other names and get
consistent answers.

Ian.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Ned Freed]

> On 8/31/2005 12:36 PM, Ned Freed wrote:

> > Section 2 states:

> that's unfortunate

> LLMNR clients need to make a distinction between the different kinds of
> networks and then process the names accordingly.

Agreed. And there are various ways to accomplish this.

> The whole argument behind the original distinction between LLMNR and DNS
> is that ad-hoc names aren't self-authoritative, the namespaces are
> therefore different, and so forth. Having clients try both namespaces is
> really missing the point.

Agreed as well.

> > Another way of fixing the overlapping namespace problem would be to  require
> > LLMNR to be truly disjoint from the DNS: Remove all this stuff about using 
> > the
> > DNS as the primary service when available. However, my guess is that such a
> > service would not be terribly interesting, and that much of the supposed 
> > value
> > opf LLMNR comes from its lashup to the DNS.

> I was under the impression that LLMNR value was from ad-hoc networks and
> naming. Surely that's the right place to flag the distinction too.

You'd think that, wouldn't you? But the draft really only mentions this stuff
in passing.

Indeed, as I commented before, the whole tone of the document seems off kilter
to me. It really feels like a document meant to block rather than facilitate.

> NB: I consider ".local" to be a crutch that's needed to make a hack work,
> and the right place to deal with these problems is at the interface map,
> not inside the namespace. Nevermind the fact that .local is overloaded
> with massive historical and experimental context already too.

I can argue this point either way. I haven't looked at mDNS closely enough to
have an opinion about it. OTOH, I'm pretty sure LLMNR has missed the mark
rather badly, irrespective of whether the right solution is separation by
interface or separation by naming convention.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Ian Jackson]

Margaret Wasserman writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)' to  Proposed Standard"):
> Other than a few minor issues that are being dealt with in a -43 
> update, I don't think that anyone has raised a blocking technical 
> issue with the LLMNR specification during this IETF LC.  If you (or 
> anyone else) has intended to raise a blocking technical issue, either 
> with LLMNR itself or with its ability to coexist with mDNS, please 
> make that clearer to me.

Just to be clear, I am intending my contributions to this argument as
descriptions of what I see as blocking technical issues with LLMNR.

It seems to me from my reading of the specifications that:

 * LLMNR is a ghastly protocol which should not be on the IETF
   Standards Track.

 * mDNS is a superior protocol to LLMNR in nearly all relevant
   respects.

 * The IETF should abandon LLMNR and put mDNS on the Standards Track.

I'd like to reiterate that I entered this discussion with a strong
presupposition towards IETF processes as opposed to third-party
activities.  As I have read the specifications, and the arguments of
those we see reported here, I have become steadily more convinced that
Stuart is right about the politics and that LLMNR critics - such as I
now am - are right about the technical issues.

> I am somewhat concerned, for example, that someone could implement 
> LLMNR thinking that it is the same thing as mDNS and only later find 
> that the two do not interoperate.  Or that some vendors will ship 
> LLMNR while others ship mDNS, so that products from different vendors 
> will not interoperate.  Do others have any thoughts on whether the 
> publication of LLMNR is likely to cause confusion along these lines?

It seems to me that these kinds of confusion are almost what the LLMNR
proponents are _aiming_ for !

> On the other hand, the DNSEXT WG has worked for several years to 
> produce the LLMNR specification, and I don't see anything 
> fundamentally wrong with the mechanism that we have produced (people 
> should respond to the IETF LC if they see blocking technical issues). 

The LLMNR specification is _terrible_.

The issue with namespace ownership, that I've been hammering on about,
should in my opinion *of itself* be sufficient to block progress of
LLMNR on the Standards Track.

> The authors of that specification gave change control to the IETF 
> community, and they have gone through 40+ document iterations, 
> working towards a document that would achieve DNSEXT consensus.  That 
> process was not followed for mDNS (because it was not the chosen 
> solution), and we currently only have one document (LLMNR) that has 
> reached IETF WG consensus and has been submitted for standards 
> publication.

If we believe Stuart Cheshire's description of events, it is not the
case that the IETF has chosen LLMNR over mDNS.  Rather a subset of the
IETF (mainly associated with the DNSEXT WG) were so upset with mDNS as
a concept that they have sabotaged it.

Furthermore, the point of this exercise is not to measure how much
hard work the LLMNR authors have put into their draft.  The fact that
it has been through 40 document iterations should be a cause for
worry, not a cause for applause !

The point of this exercise is for the IETF, as a whole, to standardise
on the best protocols.

> It is possible, in an IETF LC, that we could learn that we do not 
> have IETF consensus to publish something that was produced by an IETF 
> WG.  That would be an exceptional and unpleasant situation, [...]

If this situation is considered exceptional then I can only think that
the mechanisms for detecting it are broken !

Surely it is obvious that it will often be the case that an IETF Last
Call will bring the attention of many more people to a situation - and
most of those people will not share a community background with the WG
members.  It is not surprising that in some subset of those cases, it
turns out that the WG have gone off in some undesirable direction
(either out of technical error or political machination).

The WG is a part of the whole IETF and should be subject to its
opinions.

Ian.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Paul Hoffman wrote:

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote:


That is about 1/3 of the total. It doesn't surprise me at all that
so many bogus queries arrive - everybody who mistypes a TLD or
misconfigures a default domain generates bogus queries, and this isn't
going to change. The question is whether .local is a *significant*
part of this load. The limited data I have suggest not, but I'd like
to see publicly available data: what fraction of those NXDOMAINs are
due to .local?



The question maybe should be whether .local will become, not is, a 
significant part of this load. If you prevent mDNS, the main proponent 
of the .local namespace, from becoming a standard, the number of those 
names will remain low. If it becomes a standard and implementers use 
that namespace more, the load will of course increase.




Sorry it was not mDSN that provoced these lookups. It was some prerelease
of LLMNR.

There is no LLMNR on apples. The machines that complained were windows
only.


Regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Ian Jackson]

Margaret Wasserman writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)'  to  Proposed Standard"):
> The .local doesn't come from either mDNS or LLMNR...  The user types 
> it and/or an application includes it in the domain name look-up.  So, 
> if the user tries to look up "twiki.local", what happens?  As I 
> understand it, one of three things will happen:
> 
> (1) If the system implements mDNS, the .local domain is treated 
> specially, so this just goes out as a link-local request.

This is fine and as intended, of course.

> (2) If the system implements LLMNR, there will first be a global DNS 
> lookup for "twiki.local", which will fail.  Then, a link-local name 
> request will be tried.

This is not fine, as Peter Dambier's experience shows.  Firstly, it
generates unwanted queries up towards the DNS root (apparently in
large numbers, too!).  Secondly, if measures are taken to get rid of
that unwanted root server traffic, by having (for example) an ISP's
caching DNS proxies return 127.0.0.1 or some other answer that the
querier will accept, the querier breaks.

Why does the querier break ?  Well precisely because of the namespace
confusion I was just talking about.  The querier assumes - without any
kind of justification - that queries for .local (or whatever other
domain the LLMNR administrator has chosen) will always be happily
answered with NXDOMAIN by the `real' DNS as seen from the end system.

> But, given that choices (2) and (3) involve the same interaction with 
> the DNS, I'm not sure how one can argue that LLMNR makes things any 
> worse than things would be without it.  Perhaps you could argue that 
> mDNS makes things better, but that is only true for this one 
> non-existent TLD -- all three systems would generate a bogus global 
> DNS query if I did a DNS lookup for "isoc.frog".

LLMNR _insists_ on you picking _some_ part of the DNS space and then
abusing it this way.

Think broader than just the exact effect of the resolution protocol.
With any kind of resolution protocol - even with normal DNS - there
are decisions to be made about which names to configure in hosts.
Those names will then be used for DNS (or DNS-like) lookups.

It is true that all of these systems - full DNS, mDNS and LLMNR - will
generate bogus DNS queries if systems are configured with bogus names.

Part of the mDNS protocol is the expectation that you will configure
your hosts to expect certain services to be provided at names in
`.local'.  If mDNS were an IETF protocol then the RFC would come with
an IANA action to allocate mDNS the `.local' TLD - and, de facto, the
deployment of mDNS has meant that any other use of `.local' is now
difficult or impossible.  You may argue that this was wrong, but the
mDNS authors did try to get their very sensible protocol put through
the IETF process and were told where to go.  That's a failure of the
whole IETF, not just of the mDNS authors.

But only LLMNR _encourages_ (maybe even requires) you to configure
your systems with bogus names !  LLMNR hosts will _always_ generate
bogus DNS queries for these nonexistent names, and they will always
break if and when the real DNS suddenly provides data for those names
(either because the relevant nameserver operators are fed up of the
query traffic, or because in their wisdom - the namespace belongs to
them after all - they've decided to publish some data they themselves
want to use).

The bogosity of the names in LLMNR is quite different from the problem
(if there is a problem) with mDNS.  With mDNS the functionality - or
the brokenness, if you prefer to look at it like that - is confined to
.local.  It neither affects mDNS hosts' view of `normal' internet DNS
names, nor generates queries to normal internet DNS servers.

Ian.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Eric A. Hall]

On 8/31/2005 12:36 PM, Ned Freed wrote:

> Section 2 states:

that's unfortunate

LLMNR clients need to make a distinction between the different kinds of
networks and then process the names accordingly.

The whole argument behind the original distinction between LLMNR and DNS
is that ad-hoc names aren't self-authoritative, the namespaces are
therefore different, and so forth. Having clients try both namespaces is
really missing the point.

> Another way of fixing the overlapping namespace problem would be to  require
> LLMNR to be truly disjoint from the DNS: Remove all this stuff about using the
> DNS as the primary service when available. However, my guess is that such a
> service would not be terribly interesting, and that much of the supposed value
> opf LLMNR comes from its lashup to the DNS.

I was under the impression that LLMNR value was from ad-hoc networks and
naming. Surely that's the right place to flag the distinction too.

NB: I consider ".local" to be a crutch that's needed to make a hack work,
and the right place to deal with these problems is at the interface map,
not inside the namespace. Nevermind the fact that .local is overloaded
with massive historical and experimental context already too.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Ned Freed]

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote:
>That is about 1/3 of the total. It doesn't surprise me at all that
>so many bogus queries arrive - everybody who mistypes a TLD or
>misconfigures a default domain generates bogus queries, and this isn't
>going to change. The question is whether .local is a *significant*
>part of this load. The limited data I have suggest not, but I'd like
>to see publicly available data: what fraction of those NXDOMAINs are
>due to .local?



The question maybe should be whether .local will become, not is, a
significant part of this load. If you prevent mDNS, the main
proponent of the .local namespace, from becoming a standard, the
number of those names will remain low. If it becomes a standard and
implementers use that namespace more, the load will of course
increase.


I have only skimmed the mDNS proposal, but I don't think this is correct. mDNS
defines .local as a local namespace and requires that queries in this namespace
not done in the DNS. An implementation that forwarded .local queries to the DNS
would not be compliant IMO.

LLMNR, on the other hand, effectively requires this behavior if you set up
something like .local (it could just as easily be .foo), because it says
that when you have both DNS and LLMNR access you try DNS first and if
that fails fall back to LLMNR.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Ned Freed]

> On 8/30/2005 2:18 PM, Stuart Cheshire wrote:

> > Well, in case 1 (mDNS), no, because it won't return a useful result, so
> > why keep doing it?
> >
> > In case 3 (conventional DNS), no, because it won't return a useful
> > result, so why keep doing it?
> >
> > In case 2 (LLMNR) the answer is yes, all the time, if you chose to call
> > your printer "isoc.frog", which LLMNR allows and encourages.

> What part of the specification requires LLMNR names to be processed
> through Internet DNS?

Section 2 states:

  An LLMNR sender may send a request for any name.  However, by
  default, LLMNR requests SHOULD be sent only when one of the following
  conditions are met:

  [1] No manual or automatic DNS configuration has been performed.
  If DNS server address(es) have been configured, then LLMNR
  SHOULD NOT be used as the primary name resolution mechanism,
  although it MAY be used as a secondary name resolution
  mechanism.  For dual stack hosts configured with DNS server
  address(es) for one protocol but not another, this implies
  that DNS queries SHOULD be sent over the protocol configured
  with a DNS server, prior to sending LLMNR queries.

  [2] All attempts to resolve the name via DNS on all interfaces
  have failed after exhausting the searchlist.  This can occur
  because DNS servers did not respond, or because they
  responded to DNS queries with RCODE=3 (Authoritative Name
  Error) or RCODE=0, and an empty answer section.  A dual
  stack host SHOULD attempt to reach DNS servers over all
  protocols on which DNS server address(es) are configured,
  prior to use of LLMNR.

In other words, if I have a name to resolve and I have both LLMNR and DNS
access, I'm supposed to try DNS first, and if that fails, then LLMNR.

> There are lots of similar-looking naming services out there (DNS, NIS,
> NetBIOS, AppleTalk, ...), and there is a significant amount of experience
> in keeping the names and resolution paths separate.

My experience has been that people generally do a lousy job of keeping
these things separate.

> Just because an LLMNR
> name "looks like" a DNS name doesn't make it one (just as an AppleTalk
> name that "looks like" a DNS name doesn't make it one).

THat would be true if LLMNR was indeed designed to offer a disjoint service.
But it isn't. Rather, it appears to be designed to be able to offer both a
disjoint service as well as a sort of backup service to DNS. And that's the
source of the trouble.

Another way of fixing the overlapping namespace problem would be to  require
LLMNR to be truly disjoint from the DNS: Remove all this stuff about using the
DNS as the primary service when available. However, my guess is that such a
service would not be terribly interesting, and that much of the supposed value
opf LLMNR comes from its lashup to the DNS.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Eric A. Hall]

On 8/30/2005 2:18 PM, Stuart Cheshire wrote:

> Well, in case 1 (mDNS), no, because it won't return a useful result, so 
> why keep doing it?
> 
> In case 3 (conventional DNS), no, because it won't return a useful 
> result, so why keep doing it?
> 
> In case 2 (LLMNR) the answer is yes, all the time, if you chose to call 
> your printer "isoc.frog", which LLMNR allows and encourages.

What part of the specification requires LLMNR names to be processed
through Internet DNS?

There are lots of similar-looking naming services out there (DNS, NIS,
NetBIOS, AppleTalk, ...), and there is a significant amount of experience
in keeping the names and resolution paths separate. Just because an LLMNR
name "looks like" a DNS name doesn't make it one (just as an AppleTalk
name that "looks like" a DNS name doesn't make it one).

People who mix the resolution paths (and/or the caches) deserve what they
get. Unless you can point out where this is mandatory, I'd say the correct
response is "don't do that"

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Christian de Larrinaga]

On Wed, 2005-08-31 at 15:24 +0200, Peter Dambier wrote:
>> Steve Bellovin wrote. 
> > At the risk of starting down a tangent, the IETF does not, as a 
> > technical matter, accept the validity of so-called alternate roots.  
> > See RFC 2826.
> > 
> > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
> > 
> 
> Dear Steven,
> 
> the Public-Root is not an alternative root but a solution.
> 
> Kind regards,
> Peter and Karin
> 

not for everyone it isn't!
unless you think the solution is to sow confusion.


Christian de Larrinaga
Network Brokers Ltd



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Paul Hoffman]

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote:

That is about 1/3 of the total. It doesn't surprise me at all that
so many bogus queries arrive - everybody who mistypes a TLD or
misconfigures a default domain generates bogus queries, and this isn't
going to change. The question is whether .local is a *significant*
part of this load. The limited data I have suggest not, but I'd like
to see publicly available data: what fraction of those NXDOMAINs are
due to .local?


The question maybe should be whether .local will become, not is, a 
significant part of this load. If you prevent mDNS, the main 
proponent of the .local namespace, from becoming a standard, the 
number of those names will remain low. If it becomes a standard and 
implementers use that namespace more, the load will of course 
increase.


--Paul Hoffman, Director
--VPN Consortium

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Alternative roots (was: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard)

[Paul Hoffman]

At 3:24 PM +0200 8/31/05, Peter Dambier wrote:

the Public-Root is not an alternative root but a solution.


 makes it very clear that this set 
of root-like servers intends to answer affirmatively and 
authoritatively for TLDs that the real/generally-accepted root 
servers would say do not exist. From the material on that page, it is 
also likely that, in the future, the NS records returned by these 
root-like servers for some TLDs will be different than those returned 
by the real/generally-accepted root servers.


In other words, the statement "the Public-Root is not an alternative 
root but a solution" seems dishonest  when one reads the material at 
the site describing the service.


--Paul Hoffman, Director
--VPN Consortium

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Christian Huitema]

>  From the data gathered by our root-server operators at that moment we
> estimate that the traffic for ".local" must have been some 25%

A key technical difference between LLMNR and the initial MDNS proposal
is precisely that LLMNR has no concept of a ".local" top level domain.
Usage of LLMNR does not promote queries to this zone. 

This is indeed a key difference between LLMNR and MDNS. MDNS assumes
that there is a special zone for local names, which would be linked to
the topology. LLMNR assumes that names are independent of the topology,
that a host called "foo.example.net" retains the same name as it move to
different locations. There were ample debates of this point in the
working group, and the decisions to "not creating special names" and
"not linking names to topology" do reflect WG consensus.

-- Christian Huitema

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Single DNS root (Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard)

[Harald Tveit Alvestrand]

--On 31. august 2005 13:08 +0200 Marc Manthey <[EMAIL PROTECTED]> wrote:


i want to correct  bills concern  that  , " peters public root server
system" is
an alternative for  the existing ones  and there are several others .


Just being pedantic.

of course anyone can run any service he wants and call it anything he wants 
(modulo use of existing trademarks different rathole...)
But: Anyone who wishes to avail themselves of this service would be well 
advised to read RFC 2826 - "IAB Technical Comment on the Unique DNS Root".


When IETF documents refer to the DNS, I think it's a safe bet that they are 
intending to refer to the system under the single root that most people 
regard as "the root".


I don't think any of the fundamentals have changed in the last 5 years.

Harald

pgpZSQZleZ3Nm.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Steven M. Bellovin wrote:

In message <[EMAIL PROTECTED]>, Marc Manthey writes:


   i'm going to have to raise the point that Peters "root-server" 
system
   is his private "walled-garden" and not representative of the 
Internet's

   authoritative root servers.   Just for clarification.

--bill



i want to correct  bills concern  that  , " peters public root server
system" is
an alternative for  the existing ones  and there are several others .




At the risk of starting down a tangent, the IETF does not, as a 
technical matter, accept the validity of so-called alternate roots.  
See RFC 2826.


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



Dear Steven,

the Public-Root is not an alternative root but a solution.

Kind regards,
Peter and Karin


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Brian E Carpenter wrote:

Peter,

Peter Dambier wrote:


Russ Allbery wrote:


Margaret Wasserman <[EMAIL PROTECTED]> writes:


Other than a few minor issues that are being dealt with in a -43 
update,
I don't think that anyone has raised a blocking technical issue with 
the

LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR itself
or with its ability to coexist with mDNS, please make that clearer to
me.






Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.



Can you point to publicly available data about the rate of .local
queries to *all* the root servers (including the anycast servers)?

 Brian



Hi Brian,

I would really like to do.

We have been alarmed by ISPs that we did kill some customers applications
and we stopped publishing the ".local" immediately.

From the data gathered by our root-server operators at that moment we
estimate that the traffic for ".local" must have been some 25%

At this moment we have to sort out a couple of things but I promise
we will make our data publicly available soon.

Kind regards,
Peter and Karin Dambier

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Hi Bill,

I am speaking of this root-server system:

a.public-root.net.  900 IN  A   205.189.71.2
b.public-root.net.  900 IN  A   61.9.136.52
c.public-root.net.  900 IN  A   68.255.182.111
d.public-root.net.  900 IN  A   205.189.71.34
e.public-root.net.  900 IN  A   216.138.219.83
f.public-root.net.  900 IN  A   66.15.237.185
g.public-root.net.  900 IN  A   199.5.157.131
h.public-root.net.  900 IN  A   64.198.89.245
i.public-root.net.  900 IN  A   203.187.202.205
j.public-root.net.  900 IN  A   57.73.7.89
k.public-root.net.  900 IN  A   81.19.74.67
l.public-root.net.  900 IN  A   195.214.191.125
m.public-root.net.  900 IN  A   205.189.71.26

and I am beeing told by experts that there is no difference to
what other root-server operators have found on their servers.

ICANNed root-server operators look with interest into what
Public-Root has experienced because in the near future they will
have to support more domains than they do today. We do share
information.



I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!



i'm going to have to raise the point that Peters "root-server" system
is his private "walled-garden" and not representative of the Internet's
authoritative root servers.   Just for clarification.

--bill




--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Brian E Carpenter]

Jeroen Massar wrote:

On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote:

...

Check for only "K": http://k.root-servers.org/index.html#stats
Interresting one here is NXDOMAIN responses:
http://k.root-servers.org/stats/linx/xstats_SNXD-all.html
(note, that is only the LINX node)
It is a large part of the traffic and annoying, 0.763 k out of 2116 k
queries/sec. 


That is about 1/3 of the total. It doesn't surprise me at all that
so many bogus queries arrive - everybody who mistypes a TLD or
misconfigures a default domain generates bogus queries, and this isn't
going to change. The question is whether .local is a *significant*
part of this load. The limited data I have suggest not, but I'd like
to see publicly available data: what fraction of those NXDOMAINs are
due to .local?

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Jeroen Massar]

On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote:
> Peter,
> 
> Peter Dambier wrote:
> > Russ Allbery wrote:
> > 
> >> Margaret Wasserman <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>> Other than a few minor issues that are being dealt with in a -43 update,
> >>> I don't think that anyone has raised a blocking technical issue with the
> >>> LLMNR specification during this IETF LC.  If you (or anyone else) has
> >>> intended to raise a blocking technical issue, either with LLMNR itself
> >>> or with its ability to coexist with mDNS, please make that clearer to
> >>> me.
> >>
> >>
> > 
> > Sorry I overlooked this:
> > 
> > I dont count 25% of the root server traffic a minor issue.
> 
> Can you point to publicly available data about the rate of .local
> queries to *all* the root servers (including the anycast servers)?

Check for only "K": http://k.root-servers.org/index.html#stats
Interresting one here is NXDOMAIN responses:
http://k.root-servers.org/stats/linx/xstats_SNXD-all.html
(note, that is only the LINX node)
It is a large part of the traffic and annoying, 0.763 k out of 2116 k
queries/sec. Interrestingly that since about June it started to decline
which could be because these real root-servers
(http://www.root-servers.org/) also have a project called AS112
(http://www.as112.net), which takes care of at least the reverse trees
for RFC1918 space.

For instance, the Italian node (http://frejus.itgate.net/as112/), run by
ITGate is seeing about 100 queries per second for their point of view.
The RIPE one (http://www.ripe.net/as112/) in Amsterdam does about 300
queries/s so it really depends on ones point of view.

For real details I suggest one to ask either Olaf Kolkman or Daniel
Karrenberg (both cc'd so they will not skip this message ;) or other
root-server operators who can shed way more light on this subject.

In short: having something query for known bogus domains is bad and
hurts the root-servers. It can be limited a bit, but not much.

Additional note: Making zones 'up' and making an 'alternate root' causes
that sometimes these zones leak into the real root, where they don't
exist. Eg this happens in misconfiguration cases or people publishing
the alternate root DNS names, which don't exist for the rest of the
world. That said having an alterante root is more disruptive than having
LLMNR.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Marc Manthey writes:
>

>>
>> i'm going to have to raise the point that Peters "root-server" 
>> system
>> is his private "walled-garden" and not representative of the 
>> Internet's
>> authoritative root servers.   Just for clarification.
>>
>> --bill
>
>
>i want to correct  bills concern  that  , " peters public root server
>system" is
>an alternative for  the existing ones  and there are several others .
>
>
At the risk of starting down a tangent, the IETF does not, as a 
technical matter, accept the validity of so-called alternate roots.  
See RFC 2826.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Brian E Carpenter]

Peter,

Peter Dambier wrote:

Russ Allbery wrote:


Margaret Wasserman <[EMAIL PROTECTED]> writes:



Other than a few minor issues that are being dealt with in a -43 update,
I don't think that anyone has raised a blocking technical issue with the
LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR itself
or with its ability to coexist with mDNS, please make that clearer to
me.





Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.


Can you point to publicly available data about the rate of .local
queries to *all* the root servers (including the anycast servers)?

 Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Marc Manthey]

On Aug 31, 2005, at 12:50 PM, Bill Manning wrote:


On Aug 31, 2005, at 2:25, Peter Dambier wrote:

Russ Allbery wrote:


Margaret Wasserman <[EMAIL PROTECTED]> writes:

Other than a few minor issues that are being dealt with in a -43  
update,
I don't think that anyone has raised a blocking technical issue  
with the
LLMNR specification during this IETF LC.  If you (or anyone  
else) has
intended to raise a blocking technical issue, either with LLMNR  
itself
or with its ability to coexist with mDNS, please make that  
clearer to

me.



Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!




i'm going to have to raise the point that Peters "root-server"  
system
is his private "walled-garden" and not representative of the  
Internet's

authoritative root servers.   Just for clarification.

--bill



i want to correct  bills concern  that  , " peters public root server  
system" is

an alternative for  the existing ones  and there are several others .


-marc

http://www.public-root.com/


--
"Wer also allgemeine Aufklärung verbreitet, verschafft zugleich eben  
dadurch allgemeine wechselseitige Sicherheit, und allgemeine  
Aufklärung und Sicherheit machen Fürsten und Staaten entbehrlich.  
Oder wozu braucht man sie sodann?"


Les Enfants Terribles
www.let.de




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Bill Manning]

On Aug 31, 2005, at 2:25, Peter Dambier wrote:


Russ Allbery wrote:

Margaret Wasserman <[EMAIL PROTECTED]> writes:
Other than a few minor issues that are being dealt with in a -43 
update,
I don't think that anyone has raised a blocking technical issue with 
the

LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR 
itself

or with its ability to coexist with mDNS, please make that clearer to
me.


Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!



i'm going to have to raise the point that Peters "root-server" system
is his private "walled-garden" and not representative of the Internet's
authoritative root servers.   Just for clarification.

--bill


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Russ Allbery wrote:

Margaret Wasserman <[EMAIL PROTECTED]> writes:



Other than a few minor issues that are being dealt with in a -43 update,
I don't think that anyone has raised a blocking technical issue with the
LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR itself
or with its ability to coexist with mDNS, please make that clearer to
me.




Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!



I'm getting the impression from the IETF list discussion that several
people do consider the behavior of querying regular DNS first for names
that will be handled by LLMNR to be a blocking technical issue.  I'm not
sure that I've reached the point where I would say that personally, but
the descriptions here have at least been concerning.

I think it is very useful to have a clear distinction between DNS
namespaces, with one namespace clearly identified as being link-local so
that people are not under the impression that they can use arbitrary DNS
domains for link-local resolution and so that software knows not to try to
resolve link-local names against regular DNS servers.  It sounds like mDNS
does this as part of the protocol specification.



On the other hand, the DNSEXT WG has worked for several years to produce
the LLMNR specification, and I don't see anything fundamentally wrong
with the mechanism that we have produced (people should respond to the
IETF LC if they see blocking technical issues). The authors of that
specification gave change control to the IETF community, and they have
gone through 40+ document iterations, working towards a document that
would achieve DNSEXT consensus.  That process was not followed for mDNS
(because it was not the chosen solution), and we currently only have one
document (LLMNR) that has reached IETF WG consensus and has been
submitted for standards publication.



As near as I can tell, the authors of the mDNS specification also gave
change control to the IETF community, so I wouldn't raise that as a
distinction.  The only distinction appears to be working group consensus;
the protocols otherwise look to be in the same place legally and
process-wise.



It is possible, in an IETF LC, that we could learn that we do not have
IETF consensus to publish something that was produced by an IETF WG.



At the moment, based on the discussion in the IETF list, I don't believe
that LLMNR should be published on the standards track unless mDNS is also
being published on the standards track and we agree we really want to have
two standards for this (which I think everyone is agreed would be bad).
Publishing them both as experimental and then seeing which gains more
general acceptance and works better in practice sounds reasonable to me.



I agree.

Regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Henrik Levkowetz]

on 2005-08-31 05:40 Jeffrey Hutzelman said the following:
> 
> On Tuesday, August 30, 2005 15:55:56 -0700 Ned Freed 
> <[EMAIL PROTECTED]> wrote:
> 
>> IMO this needs major work even before being approved as experimental. The
>> overlapped namespace approach in particular seems hugely problematic and
>> IMO needs to be replaced.
> 
> I've only read this document briefly, but based on what I've seen and on 
> the descriptions and explanations in the current discussion, I have to 
> agree.  The overlapped namespace approach has significant problems, which 
> have been mentioned here.  It generates load in the form of additional 
> queries on caching servers and on the global DNS roots for names those 
> servers are never expected to be able to resolve, and in the form of 
> multicast traffic on the local link for potentially every failed query 
> against the global DNS.
> 
> 
> It also creates massive ambiguities in the namespace, by allowing any host 
> on the local link to claim any global DNS name which happens not to resolve 
> at the moment (even if due to a temporary failure).  This means that names 
> which are intended to be part of the global DNS namespace may resolve 
> differently depending on one's location, or what hosts might be responding 
> to LLMNR requests on the local network.
> 
> This is a problem so egregious that the IAB wrote a document about it 
> (RFC2826).  While the majority of that document pertains specifically to 
> recurring "alternate root" proposals, much of it applies equally well here 
> -- "alternate roots" are a bad idea because they split what needs to be a 
> single global namespace into several alternate namespaces.  The use of the 
> overlapped-namespace approach with LLMNR does the same thing, only instead 
> of creating a few alternate roots, it creates millions.

Good summaries, good points.

I do not believe the LLMNR specification should be published in
its current form; the namespace confluence is extremely bothersome,
and should not be accepted even for publication as an experimental
RFC.

Even if the namespace confluence problem is corrected, it seems
more appropriate - given the deployment of mDNS - to publish both
mDNS and LLMNR as experimental RFCs.

Henrik.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Jeffrey Hutzelman]

On Tuesday, August 30, 2005 15:55:56 -0700 Ned Freed 
<[EMAIL PROTECTED]> wrote:



IMO this needs major work even before being approved as experimental. The
overlapped namespace approach in particular seems hugely problematic and
IMO needs to be replaced.


I've only read this document briefly, but based on what I've seen and on 
the descriptions and explanations in the current discussion, I have to 
agree.  The overlapped namespace approach has significant problems, which 
have been mentioned here.  It generates load in the form of additional 
queries on caching servers and on the global DNS roots for names those 
servers are never expected to be able to resolve, and in the form of 
multicast traffic on the local link for potentially every failed query 
against the global DNS.



It also creates massive ambiguities in the namespace, by allowing any host 
on the local link to claim any global DNS name which happens not to resolve 
at the moment (even if due to a temporary failure).  This means that names 
which are intended to be part of the global DNS namespace may resolve 
differently depending on one's location, or what hosts might be responding 
to LLMNR requests on the local network.


This is a problem so egregious that the IAB wrote a document about it 
(RFC2826).  While the majority of that document pertains specifically to 
recurring "alternate root" proposals, much of it applies equally well here 
-- "alternate roots" are a bad idea because they split what needs to be a 
single global namespace into several alternate namespaces.  The use of the 
overlapped-namespace approach with LLMNR does the same thing, only instead 
of creating a few alternate roots, it creates millions.




P.S. Please note that I have taken no position on the LLMNR vs mDNS
debate.  I haaven't even looked at the mDNS specifications.


Me either.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Iljitsch van Beijnum]

One more thing:

On 31-aug-2005, at 0:55, Ned Freed wrote:

Section 2.4 discusses use of TCP for LLMNR queries and  
responses.  In
composing an LLMNR query using TCP, the sender MUST set the  
Hop Limit
field in the IPv6 header and the TTL field in the IPv4 header  
of the
response to one (1).  The responder SHOULD set the TTL or Hop  
Limit
settings on the TCP listen socket to one (1) so that SYN-ACK  
packets

will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
prevents an incoming connection from off-link since the sender  
will

not receive a SYN-ACK from the responder.


I've heard reports in the past that attackers were able to spoof  
their end of a TCP session without being able to see return traffic.  
Obviously this is very hard to do if the TCP implementation uses  
enough randomness in its initial sequence numbers, but nonetheless it  
seems prudent to make it possible for the RECEIVER to check whether  
an incoming packet was forged (with the TTL=255 trick) rather than  
depend on the quality of the initial sequence number generation  
algorithm.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Russ Allbery]

Margaret Wasserman <[EMAIL PROTECTED]> writes:

> Other than a few minor issues that are being dealt with in a -43 update,
> I don't think that anyone has raised a blocking technical issue with the
> LLMNR specification during this IETF LC.  If you (or anyone else) has
> intended to raise a blocking technical issue, either with LLMNR itself
> or with its ability to coexist with mDNS, please make that clearer to
> me.

I'm getting the impression from the IETF list discussion that several
people do consider the behavior of querying regular DNS first for names
that will be handled by LLMNR to be a blocking technical issue.  I'm not
sure that I've reached the point where I would say that personally, but
the descriptions here have at least been concerning.

I think it is very useful to have a clear distinction between DNS
namespaces, with one namespace clearly identified as being link-local so
that people are not under the impression that they can use arbitrary DNS
domains for link-local resolution and so that software knows not to try to
resolve link-local names against regular DNS servers.  It sounds like mDNS
does this as part of the protocol specification.

> On the other hand, the DNSEXT WG has worked for several years to produce
> the LLMNR specification, and I don't see anything fundamentally wrong
> with the mechanism that we have produced (people should respond to the
> IETF LC if they see blocking technical issues). The authors of that
> specification gave change control to the IETF community, and they have
> gone through 40+ document iterations, working towards a document that
> would achieve DNSEXT consensus.  That process was not followed for mDNS
> (because it was not the chosen solution), and we currently only have one
> document (LLMNR) that has reached IETF WG consensus and has been
> submitted for standards publication.

As near as I can tell, the authors of the mDNS specification also gave
change control to the IETF community, so I wouldn't raise that as a
distinction.  The only distinction appears to be working group consensus;
the protocols otherwise look to be in the same place legally and
process-wise.

> It is possible, in an IETF LC, that we could learn that we do not have
> IETF consensus to publish something that was produced by an IETF WG.

At the moment, based on the discussion in the IETF list, I don't believe
that LLMNR should be published on the standards track unless mDNS is also
being published on the standards track and we agree we really want to have
two standards for this (which I think everyone is agreed would be bad).
Publishing them both as experimental and then seeing which gains more
general acceptance and works better in practice sounds reasonable to me.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Russ Allbery]

Stuart Cheshire <[EMAIL PROTECTED]> writes:

> What happened here was *not* that the DNSEXT working group disagreed
> with me on the technical details of my solution. What happened was that
> the DNSEXT working group disagreed with me on the problem statement. I
> said, "Here's a proposed way to do simple effective service discovery
> using existing DNS record types." The DNSEXT working group said, "The
> DNS protocol is not to be used for service discovery. We forbid it, and
> furthermore, to prove the point, we're going to design a protocol of our
> own that superficially looks like yours but can't be used for service
> discovery."

And, of course, this is now a particularly non-sensical position given
that DNS is being widely used for service discovery (RFC 2782, which is
standards track, not to mention AFSDB records which have been part of DNS
since RFC 1183 and are in widespread use in the AFS community despite the
experimental status).

-- 
Russ Allbery ([EMAIL PROTECTED]) 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

[Ned Freed]

On 10-aug-2005, at 20:47, The IESG wrote:



> The IESG has received a request from the DNS Extensions WG to
> consider the
> following document:



> - 'Linklocal Multicast Name Resolution (LLMNR) '
> as a Proposed Standard



> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24.



Sorry for the delay.



After the discussion on the IETF list I thought it prudent to do a
more thorough review of the draft.


Agreed. Although this is not gernally my area, the discussion led me to
review the document.


This statement:



[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
  address(es) defined in Section 2, and on UDP and TCP port 5355 on
  the unicast address(es) that could be set as the source address
(es)
  when the responder responds to the LLMNR query.



Seems to be in conflict with:



Unicast LLMNR queries MUST be done using TCP and the responses MUST
be sent using the same TCP connection as the query.  Senders MUST
support sending TCP queries, and responders MUST support listening
for TCP queries. If the sender of a TCP query receives a response to
that query not using TCP, the response MUST be silently discarded.



Unicast UDP queries MUST be silently discarded.



Why would a responder be required to listen on unicast UDP and then
have to silently discard anything that comes in?


Indeed. It certainly seems unnecessary to me.


Section 2.4 discusses use of TCP for LLMNR queries and
responses.  In
composing an LLMNR query using TCP, the sender MUST set the Hop
Limit
field in the IPv6 header and the TTL field in the IPv4 header of the
response to one (1).  The responder SHOULD set the TTL or Hop Limit
settings on the TCP listen socket to one (1) so that SYN-ACK packets
will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
prevents an incoming connection from off-link since the sender will
not receive a SYN-ACK from the responder.



For UDP queries and responses, the Hop Limit field in the IPv6
header
and the TTL field in the IPV4 header MAY be set to any value.
However, it is RECOMMENDED that the value 255 be used for
compatibility with Apple Bonjour [Bonjour].



Why not REQUIRE that UDP queries/responses have a TTL of 255. Then
the receiver of a packet can determine with almost complete certainty
that the packet didn't traverse any routers by checking if the
received packet has a TTL of 255. (See (amongst others) ICMPv6 for
how this works.)


This seems like a reasonable suggestion.


Since LLMNR queries can be sent when DNS server(s) do not respond, an
attacker can execute a denial of service attack on the DNS server(s)
and then poison the LLMNR cache by responding to an LLMNR query with
incorrect information.



Couldn't have said it better myself.



LLMNR takes the approach of intermingling the locally resolved
namespace with the globally resolved namespace. This will lead to
security problems such as the one mentioned above (the security
considerations section is way too cavalier), but also unduly puts
strain on both the local and the global mechanisms in the expected
common case where a host will first try to resolve a name globally
and failing that, try to resolve the name locally.


Quite correct. In addition, the approach of trying the global DNS then falling
back to LLMNR seems likely to create fertile ground for screwy and hard
to trace errors.

Suppose, for example, the LLMNR resolver is configured (intentionally or
otherwise) to respond to some names that are also defined in the DNS. Perhaps
this was done to provide a fallback service, perhaps it was done in error,
whatever. But since normal DNS provides the information under normal
circumstances this information ends up not being used. Soon it is forgotten,
updates aren't done, and the information goes stale. Then the DNS service
experiences a transient failure. LLNMR now provides the information, but oops,
it's way out of date. And of course by the time someone attempts to track down
the problem the DNS will no doubt be back up and nobody will be able to figure
out what happened.

Debugging name service problems is already difficult enough, thank you very
much, without this added wrinkle.


For instance, when a user configures a name that doesn't exist in the
global namespace on a locally reachable device, and then references
that device by name, this will involve the global DNS unnecessarily.
Since the intended result does materialize, the user doesn't see a
failure condition and the situation persists.


It has been claimed elsewhere that this is not so much of an issue because DNS
servers can be configured to reject such queries. I'm afraid I don't buy this
claim, for two reasons. First and most important, implementing such a setup
requires that sites

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Iljitsch van Beijnum]

On 10-aug-2005, at 20:47, The IESG wrote:

The IESG has received a request from the DNS Extensions WG to  
consider the

following document:



- 'Linklocal Multicast Name Resolution (LLMNR) '
as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24.


Sorry for the delay.

After the discussion on the IETF list I thought it prudent to do a  
more thorough review of the draft.


This statement:

[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
 address(es) defined in Section 2, and on UDP and TCP port 5355 on
 the unicast address(es) that could be set as the source address 
(es)

 when the responder responds to the LLMNR query.

Seems to be in conflict with:

   Unicast LLMNR queries MUST be done using TCP and the responses MUST
   be sent using the same TCP connection as the query.  Senders MUST
   support sending TCP queries, and responders MUST support listening
   for TCP queries. If the sender of a TCP query receives a response to
   that query not using TCP, the response MUST be silently discarded.

   Unicast UDP queries MUST be silently discarded.

Why would a responder be required to listen on unicast UDP and then  
have to silently discard anything that comes in?


   Section 2.4 discusses use of TCP for LLMNR queries and  
responses.  In
   composing an LLMNR query using TCP, the sender MUST set the Hop  
Limit

   field in the IPv6 header and the TTL field in the IPv4 header of the
   response to one (1).  The responder SHOULD set the TTL or Hop Limit
   settings on the TCP listen socket to one (1) so that SYN-ACK packets
   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
   prevents an incoming connection from off-link since the sender will
   not receive a SYN-ACK from the responder.

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

   and the TTL field in the IPV4 header MAY be set to any value.
   However, it is RECOMMENDED that the value 255 be used for
   compatibility with Apple Bonjour [Bonjour].

Why not REQUIRE that UDP queries/responses have a TTL of 255. Then  
the receiver of a packet can determine with almost complete certainty  
that the packet didn't traverse any routers by checking if the  
received packet has a TTL of 255. (See (amongst others) ICMPv6 for  
how this works.)


   Since LLMNR queries can be sent when DNS server(s) do not  
respond, an

   attacker can execute a denial of service attack on the DNS server(s)
   and then poison the LLMNR cache by responding to an LLMNR query with
   incorrect information.

Couldn't have said it better myself.

LLMNR takes the approach of intermingling the locally resolved  
namespace with the globally resolved namespace. This will lead to  
security problems such as the one mentioned above (the security  
considerations section is way too cavalier), but also unduly puts  
strain on both the local and the global mechanisms in the expected  
common case where a host will first try to resolve a name globally  
and failing that, try to resolve the name locally.


For instance, when a user configures a name that doesn't exist in the  
global namespace on a locally reachable device, and then references  
that device by name, this will involve the global DNS unnecessarily.  
Since the intended result does materialize, the user doesn't see a  
failure condition and the situation persists.


Alternatively, whenever there is a failure in the global DNS, for  
instance because of lack of reachability, unavailability of a DNS  
server or the user typing an incorrect name, this will result in a  
local multicast query. On some links this is very undesirable. Low- 
bandwidth links such as cell phone data services are an obvious  
example. Another one is IEEE 802.11x. Due to its one-to-many nature  
broadcasts and multicasts must be sent at an artificial low bitrate  
on these links, using up an inordinate amount of link bandwidth  
relative to the packet size.


I suggest that the IESG either send back the draft to the wg to fix  
these problems or at most approves publication as an experimental RFC  
and NOT a standards track RFC.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Yes, that is exactly what our unvolontary experiment has shown.
And it makes 25% of our root server traffic. It is stealing resources
from us. That is why we consider this protocol harmful to the
internet society.

Kind regards,
Peter and Karin


Stuart Cheshire wrote:

As I understand it, one of three things will happen:

(1) If the system implements mDNS, the .local domain is treated 
specially, so this just goes out as a link-local request.


(2) If the system implements LLMNR, there will first be a global DNS 
lookup for "twiki.local", which will fail.  Then, a link-local name 
request will be tried.


(3) If the system doesn't implement any link-local name resolution, 
there will be a global lookup for "twiki.local" which will fail.


So, if people use .local domains on systems that implement LLMNR 
instead of mDNS, this can result in lookups for .local in the global 
DNS.


But, given that choices (2) and (3) involve the same interaction with 
the DNS, I'm not sure how one can argue that LLMNR makes things any 
worse than things would be without it.  Perhaps you could argue that 
mDNS makes things better, but that is only true for this one 
non-existent TLD -- all three systems would generate a bogus global 
DNS query if I did a DNS lookup for "isoc.frog".


Margaret



There's one other relevant difference to note here: If you do a DNS 
lookup for "isoc.frog" you generate a bogus global DNS query. This is 
true. But... do you habitually do DNS lookups for "isoc.frog"?


Well, in case 1 (mDNS), no, because it won't return a useful result, so 
why keep doing it?


In case 3 (conventional DNS), no, because it won't return a useful 
result, so why keep doing it?


In case 2 (LLMNR) the answer is yes, all the time, if you chose to call 
your printer "isoc.frog", which LLMNR allows and encourages.


Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org



--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

>As I understand it, one of three things will happen:
>
>(1) If the system implements mDNS, the .local domain is treated 
>specially, so this just goes out as a link-local request.
>
>(2) If the system implements LLMNR, there will first be a global DNS 
>lookup for "twiki.local", which will fail.  Then, a link-local name 
>request will be tried.
>
>(3) If the system doesn't implement any link-local name resolution, 
>there will be a global lookup for "twiki.local" which will fail.
>
>So, if people use .local domains on systems that implement LLMNR 
>instead of mDNS, this can result in lookups for .local in the global 
>DNS.
>
>But, given that choices (2) and (3) involve the same interaction with 
>the DNS, I'm not sure how one can argue that LLMNR makes things any 
>worse than things would be without it.  Perhaps you could argue that 
>mDNS makes things better, but that is only true for this one 
>non-existent TLD -- all three systems would generate a bogus global 
>DNS query if I did a DNS lookup for "isoc.frog".
>
>Margaret

There's one other relevant difference to note here: If you do a DNS 
lookup for "isoc.frog" you generate a bogus global DNS query. This is 
true. But... do you habitually do DNS lookups for "isoc.frog"?

Well, in case 1 (mDNS), no, because it won't return a useful result, so 
why keep doing it?

In case 3 (conventional DNS), no, because it won't return a useful 
result, so why keep doing it?

In case 2 (LLMNR) the answer is yes, all the time, if you chose to call 
your printer "isoc.frog", which LLMNR allows and encourages.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Margaret Wasserman]

Hi Brian,


I'm afraid I don't understand. As far as I can understand,
mDNS uses the .local pseudo-domain and LLMNR does not.
So how can LLMNR be blamed for bogus queries for *.local?


The .local doesn't come from either mDNS or LLMNR...  The user types 
it and/or an application includes it in the domain name look-up.  So, 
if the user tries to look up "twiki.local", what happens?  As I 
understand it, one of three things will happen:


(1) If the system implements mDNS, the .local domain is treated 
specially, so this just goes out as a link-local request.


(2) If the system implements LLMNR, there will first be a global DNS 
lookup for "twiki.local", which will fail.  Then, a link-local name 
request will be tried.


(3) If the system doesn't implement any link-local name resolution, 
there will be a global lookup for "twiki.local" which will fail.


So, if people use .local domains on systems that implement LLMNR 
instead of mDNS, this can result in lookups for .local in the global 
DNS.


But, given that choices (2) and (3) involve the same interaction with 
the DNS, I'm not sure how one can argue that LLMNR makes things any 
worse than things would be without it.  Perhaps you could argue that 
mDNS makes things better, but that is only true for this one 
non-existent TLD -- all three systems would generate a bogus global 
DNS query if I did a DNS lookup for "isoc.frog".


Margaret



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Christian Huitema]

> > I'm afraid I don't understand. As far as I can understand,
> > mDNS uses the .local pseudo-domain and LLMNR does not.
> > So how can LLMNR be blamed for bogus queries for *.local?
> 
> I cannot garantie it was LLMNR. I was told these are windows boxes
> using the default enabled LLMNR and it defaults to ".local". I know
> that newer windows boxes do have LLMNR but it is not normally used.
> Nevertheless it comes up.

Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default.
Name resolution in these systems is performed through DNS or
NetBIOS/WINS. Hosts using these systems are not expected to be aware of
a complete list of top-level domains. Queries for "unknown domains" will
indeed be routed by default to the local DNS servers. 

One could argue that special knowledge for some reserved names (.local
or .example) should be "wired" in every host. But it is simpler to
program this knowledge in the local name servers, thus avoiding undue
traffic to the root servers without risking interop issues and name
conficts in local naming plans.

-- Christian Huitema

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Brian E Carpenter wrote:

Peter,

I'm afraid I don't understand. As far as I can understand,
mDNS uses the .local pseudo-domain and LLMNR does not.
So how can LLMNR be blamed for bogus queries for *.local?


I cannot garantie it was LLMNR. I was told these are windows boxes
using the default enabled LLMNR and it defaults to ".local". I know
that newer windows boxes do have LLMNR but it is not normally used.
Nevertheless it comes up.

MAC systems with mDNS may use ".local" too but they never ask for
".local" via DNS. They stay with mDNS on the direct link.

It was only windows boxes who complained when we returned 127.0.0.1
for *.local



I can easily configure my Windows box to default to *.local.
But why would I want to?

   Brian


The problem is that windows users plug their box in and cry if it does
not work. They dont know how to configure or why.

Well, if you do not use ".local" on your box why not try ".com" ?
It might be fun. :)



Peter Dambier wrote:


Ian Jackson wrote:

Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name 
Resolution (LLMNR)' toProposed  Standard"):



Ian Jackson wrote:


Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.




Can you spell that out please? Since it uses a different port number,
where does the confusion occur?




The confusion occurs on the root servers.

I dont really know if it was some LLMNR enabled windows machine, but
they definitely asked DNS first and on port 53. If we supply a dummy
zone like we do for localhost then those boxes do break.


What does the port number have to do with it ?  That's an
implementation detail (from the point of view of this complaint; many
other complaints might well be about these kind of details).

The LLMNR model supposes that when an application asks for data of a
certain type associated with a certain name (ie, when the application
thinks it's asking for a DNS query) answers may come from either the
real DNS system or, even if the real DNS is authoritative for the
relevant name but denies that it exists, from LLMNR.




You name it: The implementation asks DNS for garbadge.local and if we
say 127.0.0.1 then windows breaks.

If we dont supply the krutch then 25% of our root server traffic is
for .local because they repeat their question again and again on all
13 if the root servers.


See draft-ietf-dnsext-mdns-42 s2 bullet point [2].

It is not true that separating LLMNR out on a different port, and
introducing other incompatibilities, prevents confusion between LLMNR
and the real DNS.  Applications will still see a bizarre mix of real
and LLMNR data.

On the other hand, mDNS has a much better scheme: the mDNS
specification defines the tree under `.local' for mDNS use.  Names in
.local are looked up with mDNS and names elsewhere via the real DNS.
This means that applications always either see the data intended for
them, or (transient) failure if the relevant mechanism isn't
available.

Stuart Cheshire makes IMO a very cogent argument in
<[EMAIL PROTECTED]>, where he says:
] What's weird about LLMNR is that it blurs what's global and what's 
local.
] With LLMNR you can call your television "tv.ietf.org" if you want, 
and as

] long as the IETF's name server returns NXDOMAIN (which it does today)
] then a LLMNR-compliant host will fail over to local multicast and 
resolve
] that name to your television's address. This sends a very strange 
message
] to end users -- it suggests they can use any name they want in any 
domain
] they want without having to communicate with any registry. It also 
means
] that every failed DNS query will result in a LLMNR multicast on the 
local
] network, and (worse) every intentional LLMNR query needs to be 
preceded

] by a failed DNS query to some unsuspecting DNS server somewhere.
] ] mDNS says that "local" is a free-for-all playground where anyone 
can use
] any name and no one has any more right to a particular name than 
anyone
] else. LLMNR didn't want to do that, but what they've effectively 
ended up

] doing instead is saying that the root of the DNS namespace (and
] everything below it) is a free-for-all playground where anyone can use
] any name they want.

In addition, mDNS's limitation to `.local' means that deliberate
additional incompatibilities to avoid cache pollution in the real DNS
is not necessary; since mDNS is only used for names in `.local',
normal precuations against unsolicited DNS replies will prevent the
main DNS namespace being polluted with mDNS data.

If we are to so strongly fear pollution, mDNS's wide deployment ought
to provide some evidence for this from operational experience !  Where
is that evidence ?

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Margaret Wasserman]

Hi Stuart,

Somehow our discussion has gone awry, and I'm not quite sure why, 
because I am not sure that we fundamentally disagree with each other. 
At least, I think that we both see some of the same potential 
problems, even if we disagree about what steps would be appropriate 
to resolve them.


[Please note:  In this note, I will use the term "LLMNR" to refer to 
the DNSEXT WG draft named draft-ietf-dnsext-mdns-XX.txt, and I will 
use the term "mDNS" to refer to the de facto standard Apple mDNS 
protocol.]


Other than a few minor issues that are being dealt with in a -43 
update, I don't think that anyone has raised a blocking technical 
issue with the LLMNR specification during this IETF LC.  If you (or 
anyone else) has intended to raise a blocking technical issue, either 
with LLMNR itself or with its ability to coexist with mDNS, please 
make that clearer to me.


I do, of course, see overlapping purpose/applicability for the mDNS 
and LLMNR mechanisms, and that is a significant source of concern.


In general, I don't personally think that the Internet would be 
best-served by having two different widely-deployed mechanisms for 
link local name resolution.  I can infer that the DNSEXT WG agrees 
(or agreed at one time), since they decided that a selection process 
was necessary rather than just publishing both (or all three) 
mechanisms.  So, I'm not quite sure what to do given that mDNS _is_ 
widely deployed, and that we are considering the standardization of 
LLMNR in an Internet where mDNS must considered as part of the 
existing landscape.


I am somewhat concerned, for example, that someone could implement 
LLMNR thinking that it is the same thing as mDNS and only later find 
that the two do not interoperate.  Or that some vendors will ship 
LLMNR while others ship mDNS, so that products from different vendors 
will not interoperate.  Do others have any thoughts on whether the 
publication of LLMNR is likely to cause confusion along these lines?


On the other hand, the DNSEXT WG has worked for several years to 
produce the LLMNR specification, and I don't see anything 
fundamentally wrong with the mechanism that we have produced (people 
should respond to the IETF LC if they see blocking technical issues). 
The authors of that specification gave change control to the IETF 
community, and they have gone through 40+ document iterations, 
working towards a document that would achieve DNSEXT consensus.  That 
process was not followed for mDNS (because it was not the chosen 
solution), and we currently only have one document (LLMNR) that has 
reached IETF WG consensus and has been submitted for standards 
publication.


It is possible, in an IETF LC, that we could learn that we do not 
have IETF consensus to publish something that was produced by an IETF 
WG.  That would be an exceptional and unpleasant situation, but I am 
open to that possibility.  In this particular case, though, I see 
that a few concerns have been raised that were already raised during 
the WG process, and I do not see an IETF consensus against publishing 
the LLMNR document that would override the DNSEXT WG consensus to 
publish it.  If folks disagree with this determination, they should 
speak up, because I am currently of the opinion that we do have 
DNSEXT WG and IETF consensus to publish LLMNR on the IETF standards 
track.


Some folks have already implemented LLMNR, and at least one company 
has shipped it in a commercial product.


So, I think that, no matter what happens, we are stuck in a world 
where there will be at least two link-local name resolution 
mechanisms.  Having come to that conclusion, I don't believe that 
there is any perfect answer here.  I think that our focus needs to be 
on minimizing the potential damage or confusion that will be caused 
by having two mechanisms.


Stuart, have you considered publishing mDNS on the individual 
submission track (as an Informational RFC)? I think that the 
existence of that document might help to avoid confusion about 
whether the LLMNR document describes mDNS.


The LLMNR document already includes an informative reference to 
draft-cheshire-dnsext-multicastdns-05.txt, but it does so rather 
obscurely (citing a need to use a TTL of 255 for "compatibility with 
Apple Bonjour").  It might be better to include a pointer to this 
document earlier in the LLMNR spec and indicate that Apple Bonjour 
includes another mechanisms for link-local name resolution.  Also, I 
am surprised by the reference to compatibility with Apple Bonjour 
(which I didn't notice in my AD review), because I was not under the 
impression that these protocols are compatible (as in interoperable). 
LLMNR authors, could you perhaps elaborate on what was meant by this 
statement?


Would the LLMNR authors and or the DNSEXT WG object to the idea of 
including an informative reference to mDNS (presumably as "Apple 
Bonjour") earlier in the document, stating that it is another 
link-local name reso

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

>Peter,
>
>I'm afraid I don't understand. As far as I can understand,
>mDNS uses the .local pseudo-domain and LLMNR does not.
>So how can LLMNR be blamed for bogus queries for *.local?

Simple: If you call your printer "myprinter.local", and then type
"ping myprinter.local", LLMNR will *always* send a DNS query to the
root first, before rolling over to a local multicast query, whereas
mDNS (except when operating in "Microsoft compatibility mode") will
*never* send a dot-local query anywhere other than the local LAN.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

Looking at the recent discussion and some private emails I've received, 
it's clear that I didn't explain some points well enough.

1. I'm not claiming this is an Apple vs. Microsoft battle. Bernard Aboba 
is not a Microsoft corporate shill, and I'm not a shill for Apple. What's 
happened is more complicated and more puzzling. Somehow the IETF process 
has run out of control, and taken on a life of its own, and taken us in a 
direction that makes little sense.

2. People have commented that my postings were light on technical
argument and heavy on marketing. If so I apologize. But in a sense, this 
debate *is* about marketing.

My complaint is not so much that the IETF community (or at least a vocal 
and influential portion of it) didn't like what I proposed with mDNS & 
DNS-SD, or that the IETF may choose to make LLMNR a Proposed Standard. 
Those are two independent things that should really have no bearing on 
each other. My complaint is that the IETF is engaged (perhaps 
unknowingly) in a marketing campaign of its own, to present LLMNR as the 
"official" version of Apple's "inferior proprietary" solution, as if 
there were an expectation that eventually everyone would migrate over to 
the new "official" protocol.

In almost every posting on the subject there's a tacit assumption by 
almost everyone that these are two roughly equivalent competing 
protocols, and they do the same thing, but do it in slightly different 
ways. If that were true, then it would be a straightforward technical 
analysis to see which does it best, and over time a migration to the 
better one would be possible, sensible, and desirable.

The problem is that they don't do the same thing. LLMNR can't replace 
mDNS because LLMNR doesn't do what mDNS does, and LLMNR doesn't do what 
mDNS does by design, not by oversight:

* mDNS was designed primarily to meet service discovery goals, and
delivers hostname lookup almost as a side effect that you get "for free".

* LLMNR was designed solely to do hostname lookup, and the document
explicitly prohibits any use for service discovery purposes.

What happened here was *not* that the DNSEXT working group disagreed with 
me on the technical details of my solution. What happened was that the 
DNSEXT working group disagreed with me on the problem statement. I said, 
"Here's a proposed way to do simple effective service discovery using 
existing DNS record types." The DNSEXT working group said, "The DNS 
protocol is not to be used for service discovery. We forbid it, and 
furthermore, to prove the point, we're going to design a protocol of our 
own that superficially looks like yours but can't be used for service 
discovery." It was a "poison the well" response. They didn't create LLMNR 
because they thought that a DNS-like multicast-based name lookup protocol 
was a good idea. They created it because they saw it as the lesser of two 
evils. It was a case of, "If we don't create this, then Stuart will 
create something worse."

People who know me can tell you that I haven't done all this work with 
the intent of creating some great monopoly for Apple. I began this work 
before I joined Apple, and I'm sure I'll continue it even if I leave 
Apple. I've done all this work because I'm tired of seeing people 
struggle with computer products that are too hard to use. I'm tired of 
great potential products that can't come to market because the audience 
of people who could actually make them work is too small. That's why I 
fought so hard to get Apple's mDNS & DNS-SD code freely licensed as an 
APSL Open Source project. That's why I fought so hard to get the client 
libraries licensed under the even more liberal three-clause BSD license, 
so they're compatible with GPL client code. That's why I fought so hard 
to have Apple's code live in a publicly-accessible CVS server so that 
everything we do can be seen and shared by others, and so that others can 
contribute. That's why we work so hard to have accurate specifications 
available so others can do independent implementations from the spec, and 
when others do create independent implementations, we don't treat them as 
competitors. We thank them publicly, and encourage them, and help them, 
and make our conformance test software available to them to help them 
find any bugs or potential incompatibilities. If they believe that our 
conformance test software is making some unreasonably strict requirement, 
and we agree, then we've even changed our conformance test to permit 
legitimate variant behaviors by other implementations.

What bothers me is the almost universal assumption that LLMNR is the 
official successor to mDNS, or at least is intended to be. Everywhere I 
read -- the LLMNR FAQ, Wikipedia, news articles, this IETF discussion -- 
I see the same assumption repeated, taken so much for granted that it 
doesn't even need to be stated. To me it's like someone on the evening 
news telling the world, "Why waste money on expensive messy oil for you

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Brian E Carpenter]

Peter,

I'm afraid I don't understand. As far as I can understand,
mDNS uses the .local pseudo-domain and LLMNR does not.
So how can LLMNR be blamed for bogus queries for *.local?

I can easily configure my Windows box to default to *.local.
But why would I want to?

   Brian

Peter Dambier wrote:

Ian Jackson wrote:

Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name 
Resolution (LLMNR)' toProposed  Standard"):



Ian Jackson wrote:


Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.



Can you spell that out please? Since it uses a different port number,
where does the confusion occur?



The confusion occurs on the root servers.

I dont really know if it was some LLMNR enabled windows machine, but
they definitely asked DNS first and on port 53. If we supply a dummy
zone like we do for localhost then those boxes do break.


What does the port number have to do with it ?  That's an
implementation detail (from the point of view of this complaint; many
other complaints might well be about these kind of details).

The LLMNR model supposes that when an application asks for data of a
certain type associated with a certain name (ie, when the application
thinks it's asking for a DNS query) answers may come from either the
real DNS system or, even if the real DNS is authoritative for the
relevant name but denies that it exists, from LLMNR.



You name it: The implementation asks DNS for garbadge.local and if we
say 127.0.0.1 then windows breaks.

If we dont supply the krutch then 25% of our root server traffic is
for .local because they repeat their question again and again on all
13 if the root servers.


See draft-ietf-dnsext-mdns-42 s2 bullet point [2].

It is not true that separating LLMNR out on a different port, and
introducing other incompatibilities, prevents confusion between LLMNR
and the real DNS.  Applications will still see a bizarre mix of real
and LLMNR data.

On the other hand, mDNS has a much better scheme: the mDNS
specification defines the tree under `.local' for mDNS use.  Names in
.local are looked up with mDNS and names elsewhere via the real DNS.
This means that applications always either see the data intended for
them, or (transient) failure if the relevant mechanism isn't
available.

Stuart Cheshire makes IMO a very cogent argument in
<[EMAIL PROTECTED]>, where he says:
] What's weird about LLMNR is that it blurs what's global and what's 
local.
] With LLMNR you can call your television "tv.ietf.org" if you want, 
and as

] long as the IETF's name server returns NXDOMAIN (which it does today)
] then a LLMNR-compliant host will fail over to local multicast and 
resolve
] that name to your television's address. This sends a very strange 
message
] to end users -- it suggests they can use any name they want in any 
domain
] they want without having to communicate with any registry. It also 
means
] that every failed DNS query will result in a LLMNR multicast on the 
local

] network, and (worse) every intentional LLMNR query needs to be preceded
] by a failed DNS query to some unsuspecting DNS server somewhere.
] ] mDNS says that "local" is a free-for-all playground where anyone 
can use

] any name and no one has any more right to a particular name than anyone
] else. LLMNR didn't want to do that, but what they've effectively 
ended up

] doing instead is saying that the root of the DNS namespace (and
] everything below it) is a free-for-all playground where anyone can use
] any name they want.

In addition, mDNS's limitation to `.local' means that deliberate
additional incompatibilities to avoid cache pollution in the real DNS
is not necessary; since mDNS is only used for names in `.local',
normal precuations against unsolicited DNS replies will prevent the
main DNS namespace being polluted with mDNS data.

If we are to so strongly fear pollution, mDNS's wide deployment ought
to provide some evidence for this from operational experience !  Where
is that evidence ?



mDNS is mostly free of bugs. The dont ask DNS for garbage.local . That is
why we dont see them.


Regards,
Peter Dambier




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Ian Jackson wrote:

Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)' to Proposed  Standard"):


Ian Jackson wrote:


Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.


Can you spell that out please? Since it uses a different port number,
where does the confusion occur?


The confusion occurs on the root servers.

I dont really know if it was some LLMNR enabled windows machine, but
they definitely asked DNS first and on port 53. If we supply a dummy
zone like we do for localhost then those boxes do break.


What does the port number have to do with it ?  That's an
implementation detail (from the point of view of this complaint; many
other complaints might well be about these kind of details).

The LLMNR model supposes that when an application asks for data of a
certain type associated with a certain name (ie, when the application
thinks it's asking for a DNS query) answers may come from either the
real DNS system or, even if the real DNS is authoritative for the
relevant name but denies that it exists, from LLMNR.


You name it: The implementation asks DNS for garbadge.local and if we
say 127.0.0.1 then windows breaks.

If we dont supply the krutch then 25% of our root server traffic is
for .local because they repeat their question again and again on all
13 if the root servers.


See draft-ietf-dnsext-mdns-42 s2 bullet point [2].

It is not true that separating LLMNR out on a different port, and
introducing other incompatibilities, prevents confusion between LLMNR
and the real DNS.  Applications will still see a bizarre mix of real
and LLMNR data.

On the other hand, mDNS has a much better scheme: the mDNS
specification defines the tree under `.local' for mDNS use.  Names in
.local are looked up with mDNS and names elsewhere via the real DNS.
This means that applications always either see the data intended for
them, or (transient) failure if the relevant mechanism isn't
available.

Stuart Cheshire makes IMO a very cogent argument in
<[EMAIL PROTECTED]>, where he says:
] What's weird about LLMNR is that it blurs what's global and what's local.
] With LLMNR you can call your television "tv.ietf.org" if you want, and as
] long as the IETF's name server returns NXDOMAIN (which it does today)
] then a LLMNR-compliant host will fail over to local multicast and resolve
] that name to your television's address. This sends a very strange message
] to end users -- it suggests they can use any name they want in any domain
] they want without having to communicate with any registry. It also means
] that every failed DNS query will result in a LLMNR multicast on the local
] network, and (worse) every intentional LLMNR query needs to be preceded
] by a failed DNS query to some unsuspecting DNS server somewhere.
] 
] mDNS says that "local" is a free-for-all playground where anyone can use

] any name and no one has any more right to a particular name than anyone
] else. LLMNR didn't want to do that, but what they've effectively ended up
] doing instead is saying that the root of the DNS namespace (and
] everything below it) is a free-for-all playground where anyone can use
] any name they want.

In addition, mDNS's limitation to `.local' means that deliberate
additional incompatibilities to avoid cache pollution in the real DNS
is not necessary; since mDNS is only used for names in `.local',
normal precuations against unsolicited DNS replies will prevent the
main DNS namespace being polluted with mDNS data.

If we are to so strongly fear pollution, mDNS's wide deployment ought
to provide some evidence for this from operational experience !  Where
is that evidence ?


mDNS is mostly free of bugs. The dont ask DNS for garbage.local . That is
why we dont see them.


Regards,
Peter Dambier

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Ian Jackson]

Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)' to  Proposed  Standard"):
> Ian Jackson wrote:
> > Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
> > senior IETF/IESG people seriously contemplating the kind of namespace
> > confusion which is fundamental in the LLMNR protocol design.
> 
> Can you spell that out please? Since it uses a different port number,
> where does the confusion occur?

What does the port number have to do with it ?  That's an
implementation detail (from the point of view of this complaint; many
other complaints might well be about these kind of details).

The LLMNR model supposes that when an application asks for data of a
certain type associated with a certain name (ie, when the application
thinks it's asking for a DNS query) answers may come from either the
real DNS system or, even if the real DNS is authoritative for the
relevant name but denies that it exists, from LLMNR.

See draft-ietf-dnsext-mdns-42 s2 bullet point [2].

It is not true that separating LLMNR out on a different port, and
introducing other incompatibilities, prevents confusion between LLMNR
and the real DNS.  Applications will still see a bizarre mix of real
and LLMNR data.

On the other hand, mDNS has a much better scheme: the mDNS
specification defines the tree under `.local' for mDNS use.  Names in
.local are looked up with mDNS and names elsewhere via the real DNS.
This means that applications always either see the data intended for
them, or (transient) failure if the relevant mechanism isn't
available.

Stuart Cheshire makes IMO a very cogent argument in
<[EMAIL PROTECTED]>, where he says:
] What's weird about LLMNR is that it blurs what's global and what's local.
] With LLMNR you can call your television "tv.ietf.org" if you want, and as
] long as the IETF's name server returns NXDOMAIN (which it does today)
] then a LLMNR-compliant host will fail over to local multicast and resolve
] that name to your television's address. This sends a very strange message
] to end users -- it suggests they can use any name they want in any domain
] they want without having to communicate with any registry. It also means
] that every failed DNS query will result in a LLMNR multicast on the local
] network, and (worse) every intentional LLMNR query needs to be preceded
] by a failed DNS query to some unsuspecting DNS server somewhere.
] 
] mDNS says that "local" is a free-for-all playground where anyone can use
] any name and no one has any more right to a particular name than anyone
] else. LLMNR didn't want to do that, but what they've effectively ended up
] doing instead is saying that the root of the DNS namespace (and
] everything below it) is a free-for-all playground where anyone can use
] any name they want.

In addition, mDNS's limitation to `.local' means that deliberate
additional incompatibilities to avoid cache pollution in the real DNS
is not necessary; since mDNS is only used for names in `.local',
normal precuations against unsolicited DNS replies will prevent the
main DNS namespace being polluted with mDNS data.

If we are to so strongly fear pollution, mDNS's wide deployment ought
to provide some evidence for this from operational experience !  Where
is that evidence ?

Ian.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Russ Allbery]

bmanning <[EMAIL PROTECTED]> writes:

>   we shouldn't.  LLMNR has waded through the lengthy IETF
>   standardization process to get to where it is.  That Microsoft has
>   been patient and spent the money needed to keep people on this
>   task long enough to get it here should be rewarded with the IETF
>   imprinture.

I completely disagree with this.  The purpose of the IETF approval process
is to ensure that the result is a good standard, not to reward people for
being patient.  People can and have been very patient about *bad ideas*;
they still shouldn't be published.

If LLMNR is a good protocol with solid reasons for not going with the
existing de facto standard, then by all means it should be published.
However, it absolutely should not be published simply because Microsoft
(or any other company or organization) has been patient and spent money.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

[EMAIL PROTECTED] wrote:


LLMNR has waded through the lengthy IETF standardization
process to get to where it is.  That Microsoft has been patient and 
spent
the money needed to keep people on this task long enough to get it here
should be rewarded with the IETF imprinture.  Of course even Microsoft 
has
hedged its bets (even they are aware of the need to ship products) wrt
LLMNR.  But that is no reason for the IETF to not sanction this work.

--bill



How about a protocol to remotely control the explosion of bombs. It could
even be built on top of LLMNR. It is not necessaryly more harmful than
LLMNR. Nobody intends to build bombs anyhow not to mention remotely explode
them. So would you consider publishing this protocol harmful?

Terrorists - I am sorry, weapons researches have spent a lot ...

We should really reward them by publishing this parodicol :)

Is that what you meant?

Regards
Peter

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Brian E Carpenter]

Ian Jackson wrote:

Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)'  to    Proposed Standard"):


Russ Allbery wrote:
...


I think your criteria doesn't survive logical scrutiny.  If other people
have access to the standard, can implement the standard, and can build on
the standard to create a newer revision of it, I can't imagine what
definition of "proprietary" you're using that would apply.


But mDNS is not on the standards track and LLMNR is proposed to be
on the standards track. That, I think, is why Stuart has raised the issue.



I'm finding this discussion quite disturbing.  It seems that the
proposal is that the IETF should bless LLMNR because LLMNR is on the
Blessing Track.


It's been duly submitted by a WG and Last Called, so we *must*
consider it for the standards track. I can't tell you what the result
of that consideration will be; my crystal ball is down.



Surely the reasons for the IETF to bless LLMNR as opposed to mDNS
should be based on technical details


Yes, except that we don't "bless", we approve publication (or not).

and deployment experience ? 


Strictly speaking, no - not for Proposed Standard status. But
implementation and deployment experience is always valuable input.


In
which case it seems clear that mDNS is far superior.  It's more widely
deployed, more widely implemented, and not COMPLETELY INSANE !

Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.


Can you spell that out please? Since it uses a different port number,
where does the confusion occur?

Brian



The mDNS approach at least isolates the damage (if you consider it
damage) to a specific subregion of the DNS, which you can choose to
have on your search path or in your configuration - or not.

It's a shame they chose `.local' (which was previously thought to be
reserved for local system administrators) but that's too late to
change now.  This mistake has happened in part because the relevant
IETF WG failed to properly engage with the mDNS authors !

I'm in general not a big fan of zeroconf, multicast, or anything else
you might think of as weirdo DNS extensions.  I'm something of a
luddite.  But if we're going to have an IETF-standardised protocol to
address this problem area, surely we should choose the protocol that's
(a) widely deployed, (b) technically superior and (c) less weird ?

I haven't read the drafts in detail, but I have read the LLMNR FAQ,
expecting to find a biased account of the differences which would lead
me to want to read the other side of the story.  But in nearly all of
the cases, I found myself disagreeing with the LLMNR way of doing
things, despite the best efforts of the text I was reading !



As long as they are Internet-Drafts they all have the same status, work
in progress, except that LLMNR has gained WG consensus.




From what I can see it might be more accurate to say that the DNSEXT

WG has been captured by people who have a bee in their bonnet about
killing mDNS, or who are at the very least badly misguided.

Ian.
(not usually a fan of people making wild-sounding statements about
 IETF WG conspiracies, either!)

[1] GNU adns, http://www.chiark.greenend.org.uk/~ian/adns/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[bmanning]

On Fri, Aug 26, 2005 at 11:21:06AM -0400, Keith Moore wrote:
> >I am perhaps just being slow and dim-witted after minor surgery, but why
> >should a protocol that no-one will use be standards track ?
> 
> Why should we accept a few (mostly axe-grinding) peoples' assertions 
> that no-one will use it?
> 
> Keith

we shouldn't.  LLMNR has waded through the lengthy IETF standardization
process to get to where it is.  That Microsoft has been patient and 
spent
the money needed to keep people on this task long enough to get it here
should be rewarded with the IETF imprinture.  Of course even Microsoft 
has
hedged its bets (even they are aware of the need to ship products) wrt
LLMNR.  But that is no reason for the IETF to not sanction this work.

--bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Pete Resnick]

On 8/26/05 at 5:59 PM -0400, Steven M. Bellovin wrote:

What I find amusing is so many people asking the IESG to overrule a 
WG's judgment, given how many people have complained about the 
IESG's power to do exactly that.  I haven't checked for overlap 
between the two groups...


I have never heard anyone complain about the IESG overruling a WG's 
judgement *based on IETF Last Call comments*. That's the IESG 
determining that there is lack of consensus in the IETF as a whole 
for the document to go forward. Now, that probably indicates a 
different sort of failure (not enough early outside review during the 
WG process), but I don't think there's any complaining about the IESG 
making that sort of determination.


pr
--
Pete Resnick 
QUALCOMM Incorporated

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Ian Jackson writes
:

>
>Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
>senior IETF/IESG people seriously contemplating the kind of namespace
>confusion which is fundamental in the LLMNR protocol design.
>

What I find amusing is so many people asking the IESG to overrule a 
WG's judgment, given how many people have complained about the IESG's 
power to do exactly that.  I haven't checked for overlap between the 
two groups...

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Marc Manthey]

hopefully convalesce Marshall Eubanks wrote following  important lines


why should a protocol that no-one will use be standards track ?
This discussion is beginning to remind me of the scientific  
standards processes involving the Soviet
bloc that I was involved with during the Cold War. That is not a  
good sign...


and a very disrespectful person named  Keith Moore wrote:

Why should we accept a few (mostly axe-grinding) peoples'  
assertions that no-one will use it?


 Iljitsch van Beijnum wrote:
I think the fact that mDNS has been successful in the market place  
should be given a lot of consideration. At this point, something  
new has to be a A LOT better to be worth the extra implementation  
effort, and, more importantly: all the operational issues it will  
cause (if there is any uptake) for years to come.
I'm afraid we're looking at a new ip6.int / ip6.arpa debacle. This  
stuff wastes SO MUCH time and effort that it's almost criminal to  
make these changes if there is no clear technical advantage.


Russ Allbery wrote:
Presumably the DNS working group has some incredibly strong  
arguments that
trump running code or they wouldn't have made the choices that they  
have.
Let's see them, and furthermore, let's see them *in the document*  
or at

least in a supporting informational document, since those of us on the
IETF mailing list are certainly not the only people who are going  
to have

that question.


Rob Austein wrote a lot of importand stuff and ...


 "How about tossing a coin?"


ladys and gentleman ,

i count over 170 application that are under deployment  or  allready  
successfully  implemented
why can t we have a constructional discussion how things could be  
progressed ?




pace Marc

--  
"Pulvis et umbra sumus" -  Staub und Schatten sind wir.


Les Enfants Terribles
www.let.de




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Rob Austein]

At Fri, 26 Aug 2005 11:28:44 -0700, Bill Manning wrote:
> 
>   then there was the debate over if this was DNS or something else...
>   Stewart & I took the stance, yes it was/is.

Yep, this was the original sticking point.  In particular, there were
folks (myself among them) who felt strongly that:

1) Whatever this thing was, it should not run on the same port as
   normal DNS; and

2) Whatever this thing was, cached answers from it should not be
   mingled with cached answers from normal DNS.

The usage model for this multicast thing is very different from normal
DNS (every node for itself vs hierarchical, totally different models
for what constitutes authoritative data, totally different security
models, etc).  To me, this is enough to make it a different protocol
that happens to reuse some DNS data formats.

Unfortunately, even getting agreement on that much (that it was a
different protocol) was hard, in part because some participants
believed this whole thing should be as simple as putting a multicast
address into their /etc/resolv.conf files.  Sigh.  By the time we
achieved rough consensus that DNS and this other thing were different
protocols to be run on different ports with separate caches,
discussion had already become fairly polarized.

I happen to think that both mDNS and LLMNR crippled themselves by
attempting to wedge a totally different protocol into a DNS-like
framework (a lot of the DNS semantics make no sense in this different
usage model, so the developers of these protocols had to figure out
what to do for all the cases where the packet format expressed
something that had no analogue in the new protocol), but that's what
the proponants chose to do.  Their call, and hey, I could be wrong.

What I did care about was preventing leaks between normal DNS and this
other stuff.  Unless something changed since the last time I checked,
both mDNS and LLMNR use different ports and different caches from
normal DNS, so I have no problem with either one on this score.

Subsequent parallel development of LLMNR and mDNS was just weird, and
I mostly stayed out of it because my main concerns had already been
addressed.  There have been several attempts to reconcile the two
protocols, but in the end neither camp seems willing to budge.  The
differences between the two protocols have been discussed, several
times, in mind-numbing detail, all of which is available in the
namedroppers archives and the LLMNR issue tracker for anybody with the
intestinal fortitude to wade through it.

So, like Stuart, I find this mess sad and disturbing, but, unlike
Stuart, I don't see major harm (either way) with LLMNR.  It would have
been nice to have one protocol, but the people involved couldn't
settle their differences.  That happens sometimes.  Vendors who think
LLMNR is a better idea than mDNS are going to implement it anyway,
whether the IETF blesses it or not.  If the network effect (economic
sense) is going to make mDNS win no matter what happens with LLMNR, it
won't matter whether the IETF has blessed LLMNR or not.

So the only thing I see left for the IETF to decide is whether we're
going to continue arguing about this for another N years.

Let's not.

--Rob

["Little-Endians are Little-Endians and Big-Endians are Big-Endians
  and never the twain shall meet.

 "We would like to see some Gulliver standing up between the two
  islands, forcing a unified communication regime on all of us.  I do
  hope that my way will be chosen, but I believe that, after all,
  which way is chosen does not make too much difference.  It is more
  important to agree upon an order than which order is agreed upon.

 "How about tossing a coin?"

  --Danny Cohen, IEN 137, "On Holy Wars and a Plea for Peace"]

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Bill Manning]

On Aug 26, 2005, at 10:36, Russ Allbery wrote:


Presumably the DNS working group has some incredibly strong arguments 
that
trump running code or they wouldn't have made the choices that they 
have.

Let's see them, and furthermore, let's see them *in the document* or at
least in a supporting informational document, since those of us on the
IETF mailing list are certainly not the only people who are going to 
have
that question.  Implementors are going to have to choose which 
protocols
to use, and right now they're being given very little useful guidance 
and

justification by the DNS working group as near as I can tell.

--
Russ Allbery ([EMAIL PROTECTED]) 






to be fair, the mdns work was work looking for a home in the
IETF.  DNSEXT at the time had a couple dozen work items at
the time and was not prepared to take on something this radical.
There were a couple of BOFs to see if we could spin up a new WG
for this  which in my feeble memory turned into zeroconf WG.

then there was the debate over if this was DNS or something else...
Stewart & I took the stance, yes it was/is.  Bernard/LLMNR bowed
to the pressure to not call it DNS - (hence the goofy name) 
My grant over and Stewart ready to ship, we kind of let this IETF
thing slide

only after all this did the LLMNR work get "grafted back" into the
DNSEXT wg...  even tho it was not really DNS by then.

So i don't think it is fair to dump on the DNSEXT wg members.  This
stuff was pretty much gell'ed before it got to them.

--bill


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Russ Allbery]

Ian Jackson <[EMAIL PROTECTED]> writes:

> I'm finding this discussion quite disturbing.

You're not the only one, and I'm not even directly affected by this
decision.

> It seems that the proposal is that the IETF should bless LLMNR because
> LLMNR is on the Blessing Track.

> Surely the reasons for the IETF to bless LLMNR as opposed to mDNS
> should be based on technical details and deployment experience ?

Amen.

I recognize that apparently a lot of DNS working group members are
apparently not fond of mDNS for some reason.  That's an important opinion
and should be respected.  However, widespread, existing *successful*
deployment is also a very strong argument and should also be respected.  I
personally tend to give it somewhat more weight than theoretical
arguments, unless the theoretical arguments are *very* strong.

At the very least, I would find it extremely disappointing and contrary to
the needs of the consumers of IETF standards if LLMNR were approved
without attention to interoperability with the existing mDNS deployed base
(which doesn't mean necessarily having interoperability, but it does mean
explaining how existing mDNS installations should deal with LLMNR) and
without a very clear explanation of why the already widely deployed
solution was not standardized instead of standardizing a different
protocol.

Presumably the DNS working group has some incredibly strong arguments that
trump running code or they wouldn't have made the choices that they have.
Let's see them, and furthermore, let's see them *in the document* or at
least in a supporting informational document, since those of us on the
IETF mailing list are certainly not the only people who are going to have
that question.  Implementors are going to have to choose which protocols
to use, and right now they're being given very little useful guidance and
justification by the DNS working group as near as I can tell.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Iljitsch van Beijnum]

On 26-aug-2005, at 0:29, Margaret Wasserman wrote:

I wasn't involved at the time, but I understand that the WG did not  
choose to purse the Apple mDNS proposal and intentionally selected  
the LLMNR proposal, with the understanding that the standard they  
produced would not be compatible with the existing Apple mDNS  
technology.  I wish that I had enough insight into the decision- 
making process to know why that was decided, but I do not.


Would it be too much to ask that someone who knows explain this?

At this point, it seems too late to revisit this decision which was  
made several years ago.


I disagree. If you can't do the right thing on time, at least do the  
right thing late. Doing the wrong thing late doesn't help anyone.


I think the fact that mDNS has been successful in the market place  
should be given a lot of consideration. At this point, something new  
has to be a A LOT better to be worth the extra implementation effort,  
and, more importantly: all the operational issues it will cause (if  
there is any uptake) for years to come.


I'm afraid we're looking at a new ip6.int / ip6.arpa debacle. This  
stuff wastes SO MUCH time and effort that it's almost criminal to  
make these changes if there is no clear technical advantage.


The posts from others lead me to believe that LLMNR is actually  
inferior to mDNS, and the fact that the draft is version 42 also  
speaks volumes.


At the very least the IESG should move this protocol off the  
standards track and let it stew in "experimental" for a while.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Ian Jackson]

Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)'  to Proposed Standard"):
> Russ Allbery wrote:
> ...
> > I think your criteria doesn't survive logical scrutiny.  If other people
> > have access to the standard, can implement the standard, and can build on
> > the standard to create a newer revision of it, I can't imagine what
> > definition of "proprietary" you're using that would apply.
> 
> But mDNS is not on the standards track and LLMNR is proposed to be
> on the standards track. That, I think, is why Stuart has raised the issue.

I'm finding this discussion quite disturbing.  It seems that the
proposal is that the IETF should bless LLMNR because LLMNR is on the
Blessing Track.

Surely the reasons for the IETF to bless LLMNR as opposed to mDNS
should be based on technical details and deployment experience ?  In
which case it seems clear that mDNS is far superior.  It's more widely
deployed, more widely implemented, and not COMPLETELY INSANE !

Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.

The mDNS approach at least isolates the damage (if you consider it
damage) to a specific subregion of the DNS, which you can choose to
have on your search path or in your configuration - or not.

It's a shame they chose `.local' (which was previously thought to be
reserved for local system administrators) but that's too late to
change now.  This mistake has happened in part because the relevant
IETF WG failed to properly engage with the mDNS authors !

I'm in general not a big fan of zeroconf, multicast, or anything else
you might think of as weirdo DNS extensions.  I'm something of a
luddite.  But if we're going to have an IETF-standardised protocol to
address this problem area, surely we should choose the protocol that's
(a) widely deployed, (b) technically superior and (c) less weird ?

I haven't read the drafts in detail, but I have read the LLMNR FAQ,
expecting to find a biased account of the differences which would lead
me to want to read the other side of the story.  But in nearly all of
the cases, I found myself disagreeing with the LLMNR way of doing
things, despite the best efforts of the text I was reading !

> As long as they are Internet-Drafts they all have the same status, work
> in progress, except that LLMNR has gained WG consensus.

>From what I can see it might be more accurate to say that the DNSEXT
WG has been captured by people who have a bee in their bonnet about
killing mDNS, or who are at the very least badly misguided.

Ian.
(not usually a fan of people making wild-sounding statements about
 IETF WG conspiracies, either!)

[1] GNU adns, http://www.chiark.greenend.org.uk/~ian/adns/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Keith Moore]

I am perhaps just being slow and dim-witted after minor surgery, but why
should a protocol that no-one will use be standards track ?


Why should we accept a few (mostly axe-grinding) peoples' assertions 
that no-one will use it?


Keith

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Marshall Eubanks]

On Fri, 26 Aug 2005 06:54:57 -0700
 Bill Manning <[EMAIL PROTECTED]> wrote:
> there is a fairly extensive history of multicast DNS...
> in 1998/1999, along w/ this draft:
> 

> ... so multicast DNS has been around, with various implementations over 
> the years.
> the Apple mDNS spec is not an IETF work product, in part because the 
> IETF rejected
> it.  Same w/ the DARPA mDNS work I did six years ago.  I believe that 
> Bernard and
> his team are where they are because they had the patience and money to 
> wait out a
> multi year IETF standardization effort.   I ran out of money, Apple 
> wanted to ship solutions.
> (i think)...   the Apple specs are available as are the mDNS specs.  
> neither is proprietary.
> 
> that said, i think it is reasonable for the IETF to provide its 
> imprinture on LLMNR as an IETF
> standards track activitiy for naming on a link-local environment.  The 
> work has not violated the
> processes, has met all the IETF criteria and should proceed. Pretty 
> much a clear case of a protocol
> designed by committee.  And its not like anyone will use it of course.
> Even Microsoft appears to have abandon it.
> 
> --bill
> 
> 

I am perhaps just being slow and dim-witted after minor surgery, but why
should a protocol that no-one will use be standards track ?

This discussion is beginning to remind me of the scientific standards processes 
involving the Soviet
bloc that I was involved with during the Cold War. That is not a good sign...

Regards
Marshall Eubanks

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Bill Manning]

there is a fairly extensive history of multicast DNS...
in 1998/1999, along w/ this draft:

Woodcock, B., Manning, B., "Multicast Domain Name Service",
	draft-manning-dnsext-mdns-02.txt,  August 2000.  Revied twice now 
Expired.


was this one:

Vixie, P., Manning, B., "Supporting unicast replies to multicast 
queries in the DNS",
	draft-manning-opcode-discover-01.txt,  First submitted as an ID July 
2000 - Active


With this abstract.

0. Abstract:

   The QUERY opcode in the DNS is designed for unicast. With the
   development of multicast capabilities in the DNS, it is desireable
   to have a more robust opcode for server interactions since a single
   request may result in replies from multiple responders. So DISCOVER
   is defined to deal with replies from multiple responders.

   As such, this document extend the core DNS specifications to allow
   clients to have a method for coping with replies from multiple
   responders. Use of this new opcode may facilitate DNS operations in
   modern networking topologies. A prototype of the DISCOVER opcode
   was developed as part of the TBDS project, funded under DARPA grant
   F30602-99-1-0523.

... so multicast DNS has been around, with various implementations over 
the years.
the Apple mDNS spec is not an IETF work product, in part because the 
IETF rejected
it.  Same w/ the DARPA mDNS work I did six years ago.  I believe that 
Bernard and
his team are where they are because they had the patience and money to 
wait out a
multi year IETF standardization effort.   I ran out of money, Apple 
wanted to ship solutions.
(i think)...   the Apple specs are available as are the mDNS specs.  
neither is proprietary.


that said, i think it is reasonable for the IETF to provide its 
imprinture on LLMNR as an IETF
standards track activitiy for naming on a link-local environment.  The 
work has not violated the
processes, has met all the IETF criteria and should proceed. Pretty 
much a clear case of a protocol

designed by committee.  And its not like anyone will use it of course.
Even Microsoft appears to have abandon it.

--bill


On Aug 25, 2005, at 18:53, Stuart Cheshire wrote:


It is not typical for us to make statements in our standards
regarding what proprietary mechanisms our standards are or are not
intended to compete with, nor do we typically include statements that
compare the features of our standards to proprietary protocols.


Please stop calling it "proprietary". The mDNS specificiation is 
publicly

available, and is the result of many years of open public discussion.
There are multiple independent open source implementations. Just 
because

a certain IETF inner circle decided to turn their backs on it doesn't
make it proprietary.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Brian E Carpenter]

Russ Allbery wrote:
...

I think your criteria doesn't survive logical scrutiny.  If other people
have access to the standard, can implement the standard, and can build on
the standard to create a newer revision of it, I can't imagine what
definition of "proprietary" you're using that would apply.


But mDNS is not on the standards track and LLMNR is proposed to be
on the standards track. That, I think, is why Stuart has raised the issue.

As long as they are Internet-Drafts they all have the same status, work
in progress, except that LLMNR has gained WG consensus.

   Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Russ Allbery]

Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:

> It is not sufficient to make it an open standard (by your criteria, Java
> or PDF would be non-proprietary). The most important criteria is the
> fact that the specification is NOT controlled by any given private
> entity.

If you go look at the documents that Stuart posted references to, you will
find:

| 21. Copyright Notice
| 
|Copyright (C) The Internet Society (2005).
| 
|This document is subject to the rights, licenses and restrictions
|contained in BCP 78, and except as set forth therein, the authors
|retain all their rights. For the purposes of this document,
|the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights
|in Contributions", published March 2005.

In other words, they're exactly as controlled by a given private entity as
any other IETF work.  Is the IETF a private entity?  Is SMTP controlled by
the IETF?

I think your criteria doesn't survive logical scrutiny.  If other people
have access to the standard, can implement the standard, and can build on
the standard to create a newer revision of it, I can't imagine what
definition of "proprietary" you're using that would apply.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stephane Bortzmeyer]

On Fri, Aug 26, 2005 at 10:00:39AM +0200,
 Marc Manthey <[EMAIL PROTECTED]> wrote 
 a message of 120 lines which said:

> is that enought  to show thats not "proprietary" ?

It has nothing to do with the criterium I expressed. You just said
that Bonjour / Rendez-vous has several free (as in free speech, not as
in free beer) implementations, something that Stuart Cheshire already
said several times.

> http://sourceforge.net/projects/swig/

Why this one?

> P.S. can you show me some free LLMNR implementations?

I do not think there is one yet.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Marc Manthey]

On Aug 26, 2005, at 9:20 AM, Stephane Bortzmeyer wrote:

 The most important criteria is
the fact that the specification is NOT controlled by any given private
entity.


is that enought  to show thats not "proprietary" ?

http://www.macdevcenter.com/pub/a/mac/2004/08/31/osx_java.html
http://www-unix.mcs.anl.gov/fl/research/accessgrid/bonjour-py/bonjour- 
py.html

http://sourceforge.net/projects/swig/
http://rubyforge.org/projects/dnssd/

cheers

have a great day

P.S. can you show me some free LLMNR implementations?

--
"Wer also allgemeine Aufklärung verbreitet, verschafft zugleich eben  
dadurch allgemeine wechselseitige Sicherheit, und allgemeine  
Aufklärung und Sicherheit machen Fürsten und Staaten entbehrlich.  
Oder wozu braucht man sie sodann?"


Les Enfants Terribles
www.let.de




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stephane Bortzmeyer]

On Thu, Aug 25, 2005 at 06:53:12PM -0700,
 Stuart Cheshire <[EMAIL PROTECTED]> wrote 
 a message of 20 lines which said:

> Please stop calling it "proprietary". 

"A proprietary solution by any other name would still be proprietary"
:-)

> The mDNS specificiation is publicly available, and is the result of
> many years of open public discussion.  There are multiple
> independent open source implementations.

It is not sufficient to make it an open standard (by your criteria,
Java or PDF would be non-proprietary). The most important criteria is
the fact that the specification is NOT controlled by any given private
entity.




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Margaret Wasserman]

Hi Stuart,

I'm sorry.  I didn't mean to be insulting...

We don't typically include statements about how we compete or don't 
compete with any non-IETF protocols, including de-facto standards 
and/or standards from other standards groups, as that is more of a 
marketing discussion than a technical discussion.


If there is a technical concern regarding interoperability or 
compatibility with an existing de-facto/industry standard, that might 
be included.  But I don't think that is what you are asking for, is 
it?  If it is, could you let us know what the technical issues are 
that should be documented?


Margaret

At 6:53 PM -0700 8/25/05, Stuart Cheshire wrote:

It is not typical for us to make statements in our standards
regarding what proprietary mechanisms our standards are or are not
intended to compete with, nor do we typically include statements that
compare the features of our standards to proprietary protocols.


Please stop calling it "proprietary". The mDNS specificiation is publicly
available, and is the result of many years of open public discussion.
There are multiple independent open source implementations. Just because
a certain IETF inner circle decided to turn their backs on it doesn't
make it proprietary.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Margaret Wasserman]

Hi Stuart,

Although implementaitons are not strictly required for Proposed 
Standard publication, I do think that it is interesting to know 
whether people have implemented, or intend to implement our standards.


I have received a couple of private confirmations that LLMNR is 
implemented in WinCE 5.0.  I have also been told that it has been 
implemented by ETRI, as documented in the following paper:


http://www-users.cs.umn.edu/~jjeong/publications/international-conference/icact2004-jaehoon.pdf

Margaret

At 6:52 PM -0700 8/25/05, Stuart Cheshire wrote:

I don't see anything in RFC 2026 criteria that hinges on whether
Microsoft intends to implement a protocol.


Is doesn't have to be Microsoft.

Is there *anyone* out there who has implemented this, or plans to?

Or am I just being old-fashioned in thinking that the idea behind a
protocol specified in an RFC is that someone somewhere might implement it?

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

>It is not typical for us to make statements in our standards 
>regarding what proprietary mechanisms our standards are or are not 
>intended to compete with, nor do we typically include statements that 
>compare the features of our standards to proprietary protocols.

Please stop calling it "proprietary". The mDNS specificiation is publicly 
available, and is the result of many years of open public discussion. 
There are multiple independent open source implementations. Just because 
a certain IETF inner circle decided to turn their backs on it doesn't 
make it proprietary.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

>In The Public-Root there used to exist a domain ".local". I know at least
>of one ISP who complained we did break a lot of windowed PCs.
>
>I dont know why queries for ".local" would leave their private LANs and
>reach even our root servers. They did!
>
>That is why we set up a dummy and returned localhost, to get rid of those
>bogus queries. That is what finally broke their windows and dropped our
>root server traffic some 25%. :)

I don't think this has anything to do with mDNS or LLMNR.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

>I don't see anything in RFC 2026 criteria that hinges on whether
>Microsoft intends to implement a protocol.

Is doesn't have to be Microsoft.

Is there *anyone* out there who has implemented this, or plans to?

Or am I just being old-fashioned in thinking that the idea behind a 
protocol specified in an RFC is that someone somewhere might implement it?

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Margaret Wasserman]

Hi Stuart,

--On 25. august 2005 10:18 -0700 Stuart Cheshire <[EMAIL PROTECTED]> wrote:

 It would go a long way to ease my concerns if the LLMNR specification
 stated clearly in its introduction that it's NOT intended to compete with
 mDNS, because LLMNR doesn't have any of the functionality that mDNS
 provides to enable network browsing and service discovery.


It is not typical for us to make statements in our standards 
regarding what proprietary mechanisms our standards are or are not 
intended to compete with, nor do we typically include statements that 
compare the features of our standards to proprietary protocols.


We do sometimes include statements about the applicability of our 
standards to specific environments, but I don't think that is quite 
what you are suggesting here.


I understand that you and some others would have preferred it if we 
had standardized the Apple protocol.  I wasn't involved at the time, 
but I understand that the WG did not choose to purse the Apple mDNS 
proposal and intentionally selected the LLMNR proposal, with the 
understanding that the standard they produced would not be compatible 
with the existing Apple mDNS technology.  I wish that I had enough 
insight into the decision-making process to know why that was 
decided, but I do not.  At this point, it seems too late to revisit 
this decision which was made several years ago.


Margaret

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Keith Moore wrote:
What is this document for? No one has implemented this LLMNR protocol. No 
one has any plans to implement this protocol. No company plans to ship 
products using this protocol. Even Microsoft has not even hinted at plans 
to use LLMNR in Longhorn/Vista. 



I don't see anything in RFC 2026 criteria that hinges on whether
Microsoft intends to implement a protocol.



I have seen windows boxes use it. They left traces on our root servers
and they cried when we hit them treating ".local" like "localhost"

It was windows users who complained not Macintoshes.


Local name lookup is useful, but trying to overload DNS names to serve
two different purposes, without breaking apps and/or making DNS appear
to be inconsistent, is fairly difficult.  There's an inherent conflict
between wanting local name lookup to be transparent to apps
(perhaps even by changing the semantics of existing and well-established
APIs to do local lookup in addition to DNS lookup), and having the two
lookup services produce inconsistent results (thus confusing apps that
quite reasonably expect that they should be consistent).  If you try
to make the two kinds of names look different you risk breaking apps
that expect everything to look like a DNS name.  And if you overload
DNS syntax then you subject DNS servers to bogus queries.  



Bogus queries do sabotage our root servers. They make 90% of our traffic.
That is what "root-servers.net" say. I have seen traffic reduced on
"a.public-root.net" by some 25% when we showed them a dummy for ".local".


The primary reason IETF exists is to try to sort out those kinds of
conflict in an open, neutral setting. 


For whatever reason, you chose to ship code without waiting for IETF to
finish its deliberations on how to resolve those conflicts. Maybe you
were right to do so.  I wish I could say that IETF always produces
superior results, but we all know that it desn't always succeed.  And
yet, by doing so you were essentially disregarding others' legitimate
concerns about the problems associated with your approach, and/or
unilaterally deciding, on behalf of not only your customers but
everyone who might be affected by deployment of your protocol, that you
are in a better position to know what is good for them than everyone
else who participated in IETF.


They are restricted to their local LANs. I have never seen them in the
wide, wild internet.



Now you are arguing  that people who attempted to consider a wide range
of input, and to do a responsible job of engineering a DNS-compatible
name lookup solution should abandon the results of their efforts in
favor of your ad hoc solution, merely because you were irresponsible
enough to ship it in product before the issues were widely understood
and the conflicts resolved in an open forum.

Well, maybe you're right, and maybe mDNS is better than LLMNR.  Or
maybe mDNS is only slightly worse, and not enough worse to make it
worth the confusion that standardizing LLMNR will create.  But you're
not going to convince anybody of that with your current line of
argument.

IMHO, if you can't provide a thorough analysis indicating that mDNS
works better than LLMNR,  that mDNS resolves those conflicts in a
superior way to LLMNR, and that your solution will do less harm to
applications and DNS consistency than LLMNR, and that mDNS conforms to
2026 criteria, you don't have much of a gripe, and you certainly don't
have justification for saying that LLMNR should be abandoned.

You ask about running code.  Running code is useful.  A single
impelmentation serves as a proof of concept.  Multiple implementations
derived from a single spec and tested against each other serve as a
clarity check on the specification.  But mere existence of running code
is not a reliable indicator of sound design.  In the ARPAnet days, when
there were only a few dozen hosts, a few interoperability tests were
generally enough to give a reliable indication of full-scale behavior.
In an Internet with a billion hosts, producing an implementation is
just a baby step.  These days, there's no substitute for thorough
analysis of the effect of a protocol based on a large number of use
cases.  So mDNS's running code and deployment do not trump LLMNR, and a
comparison of mDNS and LLMNR implementations would not yield much
useful data unless one were grossly more inefficient than the other.



I'd say 25% of traffic on root servers is grossly inefficient and it does
violate a couple of RFCs.



As for this Last Call - I think there are two questions that should be
asked:

1. does LLMNR meet 2026 criteria?  no known technical omissions,
conflicts resolved, etc. 


2. is LLMNR enough better than mDNS to make it worth approving it as a
standard even though mDNS exists and has some limited deployment?   If
the answer to #1 is yes, then I suspect the answer to #2 is also yes,
but an explanation is needed.

Furthermore, if there is rough consensus, supported by analysis, that
mDNS is harmful, 

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Keith Moore]

> What is this document for? No one has implemented this LLMNR protocol. No 
> one has any plans to implement this protocol. No company plans to ship 
> products using this protocol. Even Microsoft has not even hinted at plans 
> to use LLMNR in Longhorn/Vista. 

I don't see anything in RFC 2026 criteria that hinges on whether
Microsoft intends to implement a protocol.

Local name lookup is useful, but trying to overload DNS names to serve
two different purposes, without breaking apps and/or making DNS appear
to be inconsistent, is fairly difficult.  There's an inherent conflict
between wanting local name lookup to be transparent to apps
(perhaps even by changing the semantics of existing and well-established
APIs to do local lookup in addition to DNS lookup), and having the two
lookup services produce inconsistent results (thus confusing apps that
quite reasonably expect that they should be consistent).  If you try
to make the two kinds of names look different you risk breaking apps
that expect everything to look like a DNS name.  And if you overload
DNS syntax then you subject DNS servers to bogus queries.  

The primary reason IETF exists is to try to sort out those kinds of
conflict in an open, neutral setting. 

For whatever reason, you chose to ship code without waiting for IETF to
finish its deliberations on how to resolve those conflicts. Maybe you
were right to do so.  I wish I could say that IETF always produces
superior results, but we all know that it desn't always succeed.  And
yet, by doing so you were essentially disregarding others' legitimate
concerns about the problems associated with your approach, and/or
unilaterally deciding, on behalf of not only your customers but
everyone who might be affected by deployment of your protocol, that you
are in a better position to know what is good for them than everyone
else who participated in IETF.

Now you are arguing  that people who attempted to consider a wide range
of input, and to do a responsible job of engineering a DNS-compatible
name lookup solution should abandon the results of their efforts in
favor of your ad hoc solution, merely because you were irresponsible
enough to ship it in product before the issues were widely understood
and the conflicts resolved in an open forum.

Well, maybe you're right, and maybe mDNS is better than LLMNR.  Or
maybe mDNS is only slightly worse, and not enough worse to make it
worth the confusion that standardizing LLMNR will create.  But you're
not going to convince anybody of that with your current line of
argument.

IMHO, if you can't provide a thorough analysis indicating that mDNS
works better than LLMNR,  that mDNS resolves those conflicts in a
superior way to LLMNR, and that your solution will do less harm to
applications and DNS consistency than LLMNR, and that mDNS conforms to
2026 criteria, you don't have much of a gripe, and you certainly don't
have justification for saying that LLMNR should be abandoned.

You ask about running code.  Running code is useful.  A single
impelmentation serves as a proof of concept.  Multiple implementations
derived from a single spec and tested against each other serve as a
clarity check on the specification.  But mere existence of running code
is not a reliable indicator of sound design.  In the ARPAnet days, when
there were only a few dozen hosts, a few interoperability tests were
generally enough to give a reliable indication of full-scale behavior.
In an Internet with a billion hosts, producing an implementation is
just a baby step.  These days, there's no substitute for thorough
analysis of the effect of a protocol based on a large number of use
cases.  So mDNS's running code and deployment do not trump LLMNR, and a
comparison of mDNS and LLMNR implementations would not yield much
useful data unless one were grossly more inefficient than the other.


As for this Last Call - I think there are two questions that should be
asked:

1. does LLMNR meet 2026 criteria?  no known technical omissions,
conflicts resolved, etc. 

2. is LLMNR enough better than mDNS to make it worth approving it as a
standard even though mDNS exists and has some limited deployment?   If
the answer to #1 is yes, then I suspect the answer to #2 is also yes,
but an explanation is needed.

Furthermore, if there is rough consensus, supported by analysis, that
mDNS is harmful, then we ought to consider saying that.  But we
shouldn't make this statement critical path for getting LLMNR out the
door.

Keith


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Stuart Cheshire wrote:


Putting service discovery requirements aside for a moment, the other big 
difference between mDNS and LLMNR is that mDNS facilitates local-scoped 
names, analogous to RFC 1918 addresses. LLMNR lets you look up a host 
name without a DNS server, but it pre-supposes that you HAVE a globally 
unique fully-qualified host name in the first place. In contrast, mDNS 
says you can call your television "tv.local" if you want, and you don't 
need to pay anyone for that name, or ask permission, or know how to 
register it in some global database, but at the same time the name has 
only local significance so don't expect it to be usable worldwide.


What's weird about LLMNR is that it blurs what's global and what's local. 
With LLMNR you can call your television "tv.ietf.org" if you want, and as 
long as the IETF's name server returns NXDOMAIN (which it does today) 
then a LLMNR-compliant host will fail over to local multicast and resolve 
that name to your television's address. This sends a very strange message 
to end users -- it suggests they can use any name they want in any domain 
they want without having to communicate with any registry. It also means 
that every failed DNS query will result in a LLMNR multicast on the local 
network, and (worse) every intentional LLMNR query needs to be preceded 
by a failed DNS query to some unsuspecting DNS server somewhere.




Here we did have a problem:

In The Public-Root there used to exist a domain ".local". I know at least
of one ISP who complained we did break a lot of windowed PCs.

I dont know why queries for ".local" would leave their private LANs and
reach even our root servers. They did!

That is why we set up a dummy and returned localhost, to get rid of those
bogus queries. That is what finally broke their windows and dropped our
root server traffic some 25%. :)

mDNS says that "local" is a free-for-all playground where anyone can use 
any name and no one has any more right to a particular name than anyone 
else. LLMNR didn't want to do that, but what they've effectively ended up 
doing instead is saying that the root of the DNS namespace (and 
everything below it) is a free-for-all playground where anyone can use 
any name they want.


Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org



--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

>Stuart,
>
>do you have a published specification of Apple's mDNS that you can point 
>people at, so that people can understand what functionality mDNS has that 
>LLMNR does not?

Certainly.

The framework document, describing what we need and why we need it, is:

 Requirements for a Protocol to Replace AppleTalk NBP
 
 (32 pages)


The two specification documents that, when used together, meet those 
requirements are:

 Multicast DNS
 

 (45 pages)

 DNS-Based Service Discovery
 
 (32 pages)


Although the documents are complementary, we made an effort to keep a 
clean separation between the encoding of service discovery using DNS 
records (DNS-SD), and the transport of those records using multicast 
(mDNS). This makes it possible and fruitful to use one without the other, 
for example, wide-area DNS-SD service discovery performed via standard 
unicast DNS queries:

 
 

Although the documents are separate, much of what's in mDNS is there to 
make DNS-SD work better. Some examples:

* Because a given device may advertise many services, or be looking for 
many services, we allow several questions to be packed into a single 
query packet for efficiency. Semantically, a single query packet 
containing multiple questions is treated by receivers as exactly the same 
as multiple packets containing one question each. The only difference is 
that it's more efficient on the wire. (In addition to saving header 
overhead, where the queries are similar, DNS name compression can come 
into play.)

* Because of packet loss, a question may need to be retransmitted more 
than once. Because of the nature of service discovery, a single question 
may elicit a hundred responses, not just one. How do we reconcile these 
two aspects? Every time we retransmit a query, we don't want to get 
bombed with the same hundred responses. In fact, if the flood of packets 
caused some slow device's response to get lost the first time, it's 
likely to get lost in each subsequent flood of packets too. The solution 
we worked out for this is to use the answer section of the query to list 
the already-known answers. This suppresses redundant responses from the 
hundred devices we've already heard from, and gives the slow one a chance 
to be heard.

One property that a lot of these extensions have in common is that they 
can be safely omitted if all you want to do is look up host names. A 
client doesn't have to put anything in the answer section of a query, if 
the implementer chooses not to. A responder doesn't have to consult the 
answer section of a query, if the implementer chooses not to. This might 
mean lost opportunities to suppress unnecessary responses, but you could 
argue that for simple host name lookup you can live without that. It's 
very easy to make a simplified compatible subset of mDNS.

Putting service discovery requirements aside for a moment, the other big 
difference between mDNS and LLMNR is that mDNS facilitates local-scoped 
names, analogous to RFC 1918 addresses. LLMNR lets you look up a host 
name without a DNS server, but it pre-supposes that you HAVE a globally 
unique fully-qualified host name in the first place. In contrast, mDNS 
says you can call your television "tv.local" if you want, and you don't 
need to pay anyone for that name, or ask permission, or know how to 
register it in some global database, but at the same time the name has 
only local significance so don't expect it to be usable worldwide.

What's weird about LLMNR is that it blurs what's global and what's local. 
With LLMNR you can call your television "tv.ietf.org" if you want, and as 
long as the IETF's name server returns NXDOMAIN (which it does today) 
then a LLMNR-compliant host will fail over to local multicast and resolve 
that name to your television's address. This sends a very strange message 
to end users -- it suggests they can use any name they want in any domain 
they want without having to communicate with any registry. It also means 
that every failed DNS query will result in a LLMNR multicast on the local 
network, and (worse) every intentional LLMNR query needs to be preceded 
by a failed DNS query to some unsuspecting DNS server somewhere.

mDNS says that "local" is a free-for-all playground where anyone can use 
any name and no one has any more right to a particular name than anyone 
else. LLMNR didn't want to do that, but what they've effectively ended up 
doing instead is saying that the root of the DNS namespace (and 
everything below it) is a free-for-all playground where anyone can use 
any name they want.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


__

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Marc Manthey]

On Aug 25, 2005, at 7:39 PM, Harald Tveit Alvestrand wrote:


 claims that browsing and service discovery is  
described in this draft:


  [DNS-SD]   Cheshire, S. "DNS-Based Service Discovery", Internet- 
Draft

 (work in progress), draft-cheshire-dnsext-dns-sd-01.txt,
 June 2003.


hello all,

this is  more detailed i think. http://www.dns-sd.org/

regards

marcM.

--
"Fernsehen ist Kaugummi für die Augen. "(Orson Welles)

Les Enfants Terribles
www.let.de




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Harald Tveit Alvestrand]

--On 25. august 2005 10:18 -0700 Stuart Cheshire <[EMAIL PROTECTED]> wrote:


It would go a long way to ease my concerns if the LLMNR specification
stated clearly in its introduction that it's NOT intended to compete with
mDNS, because LLMNR doesn't have any of the functionality that mDNS
provides to enable network browsing and service discovery.


Stuart,

do you have a published specification of Apple's mDNS that you can point 
people at, so that people can understand what functionality mDNS has that 
LLMNR does not?


 
claims that browsing and service discovery is described in this draft:


  [DNS-SD]   Cheshire, S. "DNS-Based Service Discovery", Internet-Draft
 (work in progress), draft-cheshire-dnsext-dns-sd-01.txt,
 June 2003.

Is it the combination of those 2 drafts that you mean when saying "mDNS", 
or is it some other document grouping?


  Harald



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Stuart Cheshire]

>I do not understand how defining a new, different service on a new 
>port will kill anything.

Are you saying that you *REALLY* do not understand how the IETF defining 
a new protocol, and stating publicly that it's intended to compete with 
some established protocol, gives all the appearance of an attempt to kill 
off that existing protocol? An attempt to split implementers into two 
non-interoperating camps? An attempt to cause customers and other 
implementers to put off making a decision on either protocol while they 
wait to see which camp wins?

Of course LLMNR won't actually kill off mDNS, but there's a real risk of 
it causing confusion and delay. And, in the process, the failed effort to 
kill off mDNS squanders the IETF's credibility.

Before you claim that LLMNR was not intended to compete with mDNS, this 
is from Bernard Aboba's LLMNR FAQ:



> Rendezvous [Bonjour] is an individual submission that is not a work
> item of any IETF working group, and is currently not an IETF standard.
> While it is possible for an individual submission to become an
> IETF standard, this is unlikely in this case because an existing
> WG (DNSEXT) is already working on a competing protocol (LLMNR)

Before you claim that it's not causing confusion in the broader 
community, this is from the Wikipedia entry for "Zeroconf":



> Name resolution
> There are two very similar ways of figuring out which
> networked item has a certain name. Apple Computer's Multicast
> DNS (mDNS) is in use, but is not an IETF standard. Microsoft's
> Link-local Multicast Name Resolution (LLMNR) is not yet being
> used, but is being officially standardized by the IETF.

There's a clear message being promulgated that the two protocols are 
more-or-less equivalent in functionality, the only significant difference 
being that one has the endorsement of the IETF and the other doesn't.

It would go a long way to ease my concerns if the LLMNR specification 
stated clearly in its introduction that it's NOT intended to compete with 
mDNS, because LLMNR doesn't have any of the functionality that mDNS 
provides to enable network browsing and service discovery.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Margaret Wasserman]

Hi Peter,

At 12:41 PM +0200 8/25/05, Peter Dambier wrote:

Stuart Cheshire wrote:
The IESG has received a request from the DNS Extensions WG to 
consider the following document:


- 'Linklocal Multicast Name Resolution (LLMNR) '
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24.


I really would appreciate do think IESG should postpone or reject.

This protocoll is untested!

Its implementation could result in a loss of lives!

There is no reference implementation.


The IETF does not define reference implementations.  This document 
has been submitted for Proposed Standard (PS) publication, and there 
are no specific implementation requirements for publication at the PS 
level, which is the first level of the IETF standards track.  Two 
interoperable implementations are required for advancement to Draft 
Standard.


However, I have been told (although I cannot personally verify this) 
that the LLMNR protocol has been implemented in Microsoft WinCE 5.0, 
and that statement is supported by the release notes that can be 
found at:


http://download.microsoft.com/download/0/8/0/08000f6b-974b-4384-90d0-26440d9ecbcf/relnotes.rtf


Apple's mDNS protocol differs from LLMNR (and DNS) in more than
half a dozen ways.


1. It is emplemented.

2. Mostly everybody does use it.

3. mDNS did not result in the loss of lives.


Apple mDNS and LLMNR use different ports, as well as different
multicast addresses, and because of the many protocol
differences, do not interoperate.


The DNSEXT WG understands that LLMNR is not identical to the Apple 
mDNS protocol and that it will not interoperate with it.  In fact, 
the reason that LLMNR runs on a different port is that it is known to 
be different.



Forget about bats and bees now. Think of existing programmes and appliances.
Do you want to kill them?


I do not understand how defining a new, different service on a new 
port will kill anything.  There is nothing about the existence LLMNR 
that would prevent hosts from running Apple's proprietary mDNS 
protocol on the existing Apple mDNS port.


I don't think that you have raised any issues here that have not 
already been discussed in the DNSEXT WG.  If you do have specific 
technical objections to the LLMNR protocol, could you re-state them a 
bit more clearly so that I can understand what they are?


Thank you,
Margaret

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf