Re: [mdnsext] Discussion of BoF during Berlin IETF

David Farmer <> Mon, 10 June 2013 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D39B21F9619 for <>; Mon, 10 Jun 2013 16:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z2Bvvg51NnH1 for <>; Mon, 10 Jun 2013 16:24:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2791421F91BF for <>; Mon, 10 Jun 2013 16:24:33 -0700 (PDT)
Received: from ( []) by (UMN smtpd) with ESMTP for <>; Mon, 10 Jun 2013 18:24:33 -0500 (CDT)
X-Umn-Remote-Mta: [N] [] #+LO+TR
X-Umn-Classification: local
Received: by with SMTP id dn14so10909222obc.2 for <>; Mon, 10 Jun 2013 16:24:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=0rKqp9PgxAOZFjdvvnzOwhE1CQHCQVnSCdZ8FsA7IJg=; b=f7JUax06frzLKKUL5bG7t8h111gopAui8kvgqSzmrpzvNnzzLCM+V/4SFbOyoZjYF5 +qo2gAOifIE56TElOQAFq5bbQT40hX7L61/LUPwjjt01o9PZ9n81s1VHmLkLivVSWVaL gbz/YyPcNz4DGoys7BwrOz0Xtz9qCqaUtMvOqLX1gSpbZqKE16GnttMdX9BmJXStdyil uvtJv9SoQHAA2KUqehecJ4k4joAONLFW2d6UMb6NfNwQmweAszxHrndI5ce60i4DMAVY HInQ0+SnJbSkXhPhjdk7JS8I6naymViP0l2eR6AjDSBtGd1+KA+rZfet+Vk1FXfdKOpa 7SWQ==
X-Received: by with SMTP id cp6mr10113309oeb.91.1370906672792; Mon, 10 Jun 2013 16:24:32 -0700 (PDT)
X-Received: by with SMTP id cp6mr10113298oeb.91.1370906672709; Mon, 10 Jun 2013 16:24:32 -0700 (PDT)
Received: from ( []) by with ESMTPSA id h4sm25591644oel.2.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 16:24:32 -0700 (PDT)
Message-ID: <>
Date: Mon, 10 Jun 2013 18:24:30 -0500
From: David Farmer <>
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Kerry Lynn <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQk8N0qDSdZgSMyg6BUEPdR/4j0Q1UjMi5MZOA4de2aItp+iu8emsO2AmIsNcEOzTgUX4R3WBcDFgi1Hyp/m9lb979xhKjSESHkX4Qofm/EQPFaWYbPetIHdEb0Q+N5+zLS/0MJj
Cc: David Farmer <>, "" <>, "Albrecht, Harald" <>, Michael Richardson <>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: David Farmer <>
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Jun 2013 23:24:40 -0000

On 6/10/13 17:28 , Kerry Lynn wrote:
> On Mon, Jun 10, 2013 at 4:45 PM, David Farmer <
> <>> wrote:
>     On 6/5/13 08:42 , Michael Richardson wrote:
>         But, that doesn't prevent or clearly signal, that mDNS may be
>         *unwelcome* on a particular network.   Enterprise folks might
>         want to do
>         that. I'm not claiming that they will, or should, succeed, btw.  I'm
>         pointing out that we don't know what they want, because they
>         don't tend
>         to participate.
>     While I wouldn't recommend general use of such a mode of operation I
>     do see some special situations where I think it could be necessary,
>     even on my own network, especially in networks or subnets with high
>     security requirements.
>     More fundamentally, I would prefer to see a graceful mechanism to
>     achieve this policy, rather than requiring traffic filtering or
>     another blunt force mechanism to achieve such a policy.  If someone
>     feels they need such a policy they will find a way.  I believe it is
>     far better for the protocol to give them a way to achieve their
>     policy goals then to force them to use other possibly more drastic
>     mechanisms to achieve their policy goal.
> The policy goal being "black hole all FF02::FB traffic"?

I would put it slightly differently, "not allowing multicast service 
discovery."  One option could be to "black hole all FF02::FB" and traffic.  However, a mechanism designed into the protocol 
could be more graceful, allowing an appropriate error message to be 
returned to an application or user.  Whereas, black holing all FF02::FB 
and traffic wouldn't generally provide a useful error 
message, other than maybe a ICMP administratively not allowed. And, only 
if the filtering device is so kind as to actually return an ICMP 
message, which is kind of rare these days unfortunately.  Most things 
that filter just black hole things these days, because "that is more 
secure", BAH!!

Also, a mechanism designed into the protocol could allow more subtle 
policies like "allowing service discovery without allowing service 
registration" with something like the hybrid draft Stuart proposed, or 
"only allowing registration of certain type of services".

David Farmer               Email:
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952