Re: [mdnsext] mDNSext features/requirements rollup

David Farmer <farmer@umn.edu> Fri, 15 February 2013 08:47 UTC

Return-Path: <farmer@umn.edu>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B821F88B0 for <mdnsext@ietfa.amsl.com>; Fri, 15 Feb 2013 00:47:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.349
X-Spam-Level:
X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRdzhrMmcF-X for <mdnsext@ietfa.amsl.com>; Fri, 15 Feb 2013 00:47:40 -0800 (PST)
Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id ABF7221F866F for <mdnsext@ietf.org>; Fri, 15 Feb 2013 00:47:40 -0800 (PST)
Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for <mdnsext@ietf.org>; Fri, 15 Feb 2013 02:47:30 -0600 (CST)
X-Umn-Remote-Mta: [N] mail-ob0-f198.google.com [209.85.214.198] #+LO+TR
X-Umn-Classification: local
Received: by mail-ob0-f198.google.com with SMTP id dn14so16990289obc.1 for <mdnsext@ietf.org>; Fri, 15 Feb 2013 00:47:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received: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=DuyIwKR97fdZ4I5MJuIeLmx7lW8Hrodi0tc/cMM1wlI=; b=hDZ8RhAbNBfVS8N0h0XG+q4WEkc/cyCddanU+2BOhKpsxXfxEf8uKf78Ql8+yBkRet 0TWG7A7wW4jr4Z4MKf4LaDWvwDZaoiopGqWpgkWYoZmqatR0b3VMawSNY89mIlhUYAAX XQaynEb+pdW3hmlD6SNwPgSo2P31tARxLCxZYHUdkVtXOZqAFDuPakhM19IniFCBhpDJ PkUv+AXkAu43/K+TUHxulVQLfzCoqU+5eHvC3pR9L0xy4/VmV06oEhAPLDyWbom699Yn um9PyB/uJ9RfS9iWnW6CHF0PZaW8FeCv/ifW90C8vW/uCVKRNl6BKtRNmJfDWR4rQdZV /kdg==
X-Received: by 10.43.124.130 with SMTP id go2mr1110765icc.8.1360918049676; Fri, 15 Feb 2013 00:47:29 -0800 (PST)
X-Received: by 10.43.124.130 with SMTP id go2mr1110763icc.8.1360918049572; Fri, 15 Feb 2013 00:47:29 -0800 (PST)
Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id nh1sm3352309igc.4.2013.02.15.00.47.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 00:47:28 -0800 (PST)
Message-ID: <511DF61E.9010005@umn.edu>
Date: Fri, 15 Feb 2013 02:47:26 -0600
From: David Farmer <farmer@umn.edu>
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: RJ Atkinson <rja.lists@gmail.com>
References: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com>
In-Reply-To: <4D4B5680-EF92-4646-957F-5FF4E588DFEF@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQltN27ra612sBlrTpmJyJxUt01FAHiHWwugzgk31hEHk8SijPvhaPppQjuA/yYwWJAw2iWyA24C21RfwzcMtR2upJT5mnyLo0+ad9bnzmt1tgV8GjRbLGct2fJVRYBFkYUCATrr
Cc: mdnsext@ietf.org, David Farmer <farmer@umn.edu>
Subject: Re: [mdnsext] mDNSext features/requirements rollup
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: David Farmer <farmer@umn.edu>
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2013 08:47:41 -0000

On 2/7/13 07:58 , RJ Atkinson wrote:
> Later on 29th Jan 2013, David Farmer wrote, in part:
>> 5. What about IPv6, mDNS is using link-local IPv6, how do you
>> route between multiple IPv6 link-local, by definition you can't.
>> So multi network mDNS is really IPv4 only right now.
>
> I'm not too sure about the claim in that last sentence.
>
> I have heard of at least one multi-subnet "proxy-oriented"
> implementation of mDNS that exists today, and that approach
> should work equally well for IPv4 and IPv6.  Of course, that
> existing prototype/implementation is necessarily proprietary,
> simply because this WG doesn't have a specification one
> could comply with.

OK, my comments were based on testing I did more than a year ago, and 
I'd swear that I saw only link-local IPv6 addressing for services on a 
dual-stack network with a IPv6 GUA prefix available.  However, I just 
looked at this again and now I'm seeing IPv4 GUA, IPv6 link-local, and 
IPv6 GUA addressing associated with the same mDNS service name.  So, I 
don't know if I just was remembering things wrong, if implementations 
have changed, or I just screwed up in my previous testing.  Whatever the 
case, this isn't the problem I thought it was, sorry.

However, I will say that care needs to be taking to not proxy link-local 
(IPv4 or IPv6) addressing associated with services and only proxy GUA or 
ULA addressing for services off of a network segment with multicast or 
hybrid proxy of mDNS services.  Furthermore, we need to define if a 
proxy should defend the name of a link-local only service on other 
segments to preserve naming coherency for any devices that may see the 
link-local only service and the potentially conflicting GUA addressed 
service of the same name on a different segment?  I think link-local 
only name needs to be defended.  But then, what address should the 
link-local only service be advertized with on the other segments? 
Should the proxy use its own link-local address on the other segment?

Should an mDNS proxy also proxy the data path in the case of a 
link-local only addressed service as well?  In the case of an mDNS proxy 
across a NAT Router then you would have to use the proxies outside 
address and NAT the Data path of the service, there are a whole bunch of 
corner cases here, BLECH!!

There is a similar question between IPv4 and IPv6, the 
ships-in-the-night solution for IPv4 and IPv6 used in mDNS may or may 
not be workable across multicast and hybrid proxies.  Which every way we 
go with it we need to give serious attention to the dual-stack naming 
behavior across proxies, multicast or hybrid.  If this is implemented 
differently between solutions you could see some really weird behavior.




-- 
================================================
David Farmer               Email: farmer@umn.edu
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
================================================