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

From: Margaret Wasserman <[email-masked]>
Date: Tue, 30 Aug 2005 12:29:37 -0400

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 resolution protocol and making it clear to what 
extent LLMNR is (or is not) compatible with mDNS?

Thoughts?
Margaret

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Aug 2005 16:44:03 -0700

Margaret Wasserman <[email-masked]> 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-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 30 Aug 2005 22:56:46 -0500

From: "Russ Allbery" <[email-masked]>

> Margaret Wasserman <[email-masked]> writes:
<deleted down to>
> the protocols otherwise look to be in the same place legally and

One other minor point here, that should probably migrate to Newtrk pretty 
quickly if anyone wants to chat about it...

I'm getting an uneasy feeling here about a comparison between a working 
group internet-draft and a non-working group internet-draft, as if that was 
interesting.

If our process had anything to say about what it means for a draft to be 
adopted by a working group, in terms of the quality standard it's being held 
to, or the reviews that have been conducted, or anything similar, this would 
be a very reasonable distinction, but our process says very little about any 
of this stuff - so saying "my draft is a working group draft" (or, even 
worse, "a working group draft on the standards track") isn't helpful at all.

Often our processes are fuzzy for a reason, so I'm not saying we should 
"require three out-of-working-group independent reviews before an 
internet-draft can be adopted by a working group", or anything like that. 
I'm just saying that we shouldn't say things that sound like we DO have 
specific criteria that some internet-drafts meet and become working group 
drafts.

Spencer

---

From: Peter Dambier <[email-masked]>
Date: Wed, 31 Aug 2005 11:25:55 +0200

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

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!

> 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-masked]
http://iason.site.voila.fr
http://www.kokoom.com/iason

---

From: Bill Manning <[email-masked]>
Date: Wed, 31 Aug 2005 03:50:13 -0700

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

>>> update,

	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

---

From: Marc Manthey <[email-masked]>
Date: Wed, 31 Aug 2005 13:08:45 +0200

>     authoritative root servers.   Just for clarification.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Aug 2005 13:14:12 +0200

Peter,

> 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

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 31 Aug 2005 07:36:36 -0400

In message <[email-masked]>, Marc Manthey writes:

>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

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 31 Aug 2005 13:54:17 +0200

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Aug 2005 14:47:58 +0200

> On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote:
...
> 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

---

From: Peter Dambier <[email-masked]>
Date: Wed, 31 Aug 2005 14:55:02 +0200

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.

---

From: Peter Dambier <[email-masked]>
Date: Wed, 31 Aug 2005 15:15:02 +0200

> queries to *all* the root servers (including the anycast servers)?

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

---

From: Peter Dambier <[email-masked]>
Date: Wed, 31 Aug 2005 15:24:51 +0200

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 31 Aug 2005 13:44:50 +0200

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 31 Aug 2005 08:25:08 -0700

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

<http://public-root.com/tlds.htm> 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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 31 Aug 2005 08:27:42 -0700

>to see publicly available data: what fraction of those NXDOMAINs are

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

---

From: Christian de Larrinaga <[email-masked]>
Date: Wed, 31 Aug 2005 16:42:25 +0100

On Wed, 2005-08-31 at 15:24 +0200, Peter Dambier wrote:
>> Steve Bellovin wrote. 

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

Christian de Larrinaga
Network Brokers Ltd

---

From: Ned Freed <[email-masked]>
Date: Wed, 31 Aug 2005 09:48:42 -0700 (PDT)

> implementers use that namespace more, the load will of course

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

---

From: Peter Dambier <[email-masked]>
Date: Wed, 31 Aug 2005 20:00:14 +0200

Paul Hoffman wrote:
> 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

---

From: Ian Jackson <[email-masked]>
Date: Wed, 31 Aug 2005 19:05:14 +0100

> with LLMNR itself or with its ability to coexist with mDNS, please 

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.

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

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

> reached IETF WG consensus and has been submitted for standards 

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.

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 31 Aug 2005 19:22:02 +0100

On Tue, 30 Aug 2005, Margaret Wasserman wrote:
> 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-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 01 Sep 2005 02:49:52 +0200

Dear Harald and Paul,
May be time to stop 3683ing this issue. Major moves in the naming 
area are probable in the year to come (PADs - shared root under UN - 
National TLDs, CENTR move.); while an ICANN request of update of RFC 
2826 stays unanswered or opposed for four years.

On 17:25 31/08/2005, Paul Hoffman said:
><http://public-root.com/tlds.htm>

It also confuses Registries and Registrars (cf. presentation of ccTLDs)

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

There is an USG/ICANN contract over IANA functions confirmed by RFC 
2860. Not to make any politics let call it "legacy" root as results 
from the 1984 agreement (RFC 920, claimed source of the ICANN 
legitimacy). The resulting "legacy top zone" - through server 
declarations - is already larger than documented by its root file.

>the site describing the service.

Correct. The "Public-Root" is technically a decentralised root file. 
It is not a "solution".

At 13:44 31/08/2005, Harald Tveit Alvestrand wrote:
>Anyone who wishes to avail themselves of this service would be well 

Harald, RFC 2826 has been used and partly out-dated by the 2001 
response ICANN (http://www.icann.org/icp/icp-3.htm ) you ignored for 
practical reasons I accept, but none one commented. It calls for an 
experimentation to document the evolution we face today unprepared. 
When there is more than an unique authoritative root file.

I lead such an experimentation for two years, along with the ICANN 
criteria. Most of my positions you oppose have been tested and 
validated there. I am sure would you run a similar test-bed, our 
strategies could still oppose, but our understandings of the network 
architectural evolution would be similar.

>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".

May be, but this is wrong. We are to face the balkanisation vs. 
compartmentalisation reality. Chinese law and US Statements of 
Principles have enforced a new situation leading to sovereign 
alt-roots. We can say "obey RFC ....", be disregarded and get 
balkanisation. Or we can work on solutions adapted to the current 
evolution, imagine a distributed root system (no big deal) and 
possibly obtain a unique authoritative root matrix. A few months from 
now it will practically be too late.

Harald, we are in direct competition over the language root. "my" 
solution there can survive a balkanisation of the IANA, not yours. So 
it is a common interest to quickly review and document the evolution 
of the name root before it is too late for you and a pain for others.

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

This _IS_  the problem. You have not seen and acknowledged the change 
(first act: Tokyo 2000, call for the first change in RFC 920 status 
quo), leading to (2001) considering the obsolescence of these 
"fundamentals". In that area nothing has changed since 1984 on the 
internet root side, while the Internet _has_changed_ into the 
international network it only interfaced in 1984.

This change is not trivial, it must be matched by a serious "how to".

jfc