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

Henrik Levkowetz <henrik@levkowetz.com> Wed, 31 August 2005 07:55 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EANRC-0000Wu-Nw; Wed, 31 Aug 2005 03:55:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EANRA-0000Wp-0v for ietf@megatron.ietf.org; Wed, 31 Aug 2005 03:55:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06343 for <ietf@ietf.org>; Wed, 31 Aug 2005 03:55:09 -0400 (EDT)
Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EANSr-0005E2-P7 for ietf@ietf.org; Wed, 31 Aug 2005 03:56:58 -0400
Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id C240A380F1; Wed, 31 Aug 2005 09:54:51 +0200 (CEST)
Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id B1A6B380D6; Wed, 31 Aug 2005 09:54:51 +0200 (CEST)
Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 9AEF137E4F; Wed, 31 Aug 2005 09:54:50 +0200 (CEST)
Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EANQo-0003fx-9A; Wed, 31 Aug 2005 09:54:50 +0200
Message-ID: <43156249.7010508@levkowetz.com>
Date: Wed, 31 Aug 2005 09:54:49 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeffrey Hutzelman <jhutz@cmu.edu>
References: <E1E2vc4-0005tK-3G@newodin.ietf.org> <FF02984E-5095-412D-B3C3-3DF1C4B8E5A6@muada.com> <01LSG29TZ2JE000092@mauve.mrochek.com> <DF4FE04E74E1B1AA21FDB45C@bistromath.pc.cs.cmu.edu>
In-Reply-To: <DF4FE04E74E1B1AA21FDB45C@bistromath.pc.cs.cmu.edu>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org, IETF General Discussion Mailing List <ietf@ietf.org>
Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

on 2005-08-31 05:40 Jeffrey Hutzelman said the following:
> 
> On Tuesday, August 30, 2005 15:55:56 -0700 Ned Freed 
> <ned.freed@mrochek.com> 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