Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mellon@fugue.com> Tue, 15 August 2017 20:28 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58C41323C8 for <homenet@ietfa.amsl.com>; Tue, 15 Aug 2017 13:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWb8UcqMFAyk for <homenet@ietfa.amsl.com>; Tue, 15 Aug 2017 13:28:55 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56AE51323C7 for <homenet@ietf.org>; Tue, 15 Aug 2017 13:28:55 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id a18so10669078qta.0 for <homenet@ietf.org>; Tue, 15 Aug 2017 13:28:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zlAbnbUEXp3wL3ZD4JehXAcGdK6kWuh3dXugSvlgoFc=; b=XiptRZ87f4Rj708MqJ81Tmw4wWDKN/SSzwFujldXHvoDLqhXeZOhjDzfuA3Dq4P9wP fWq++2mcNTdbtg2yquDbEBvlId/rcHgjJhweKe62i+Eti2ZsqiohvhV/6bYAfUswjSls LLTolcGkJkqI6BLNm/xykynyvcWrfQ7T7U7g89U0jsVTyxGmaMOnG8RZWpoX2B/OucQt /8+TdFm0xxBKYrtnbrKsS4SSHKfnadCryexk+pdOgWafRhKeOjUtdeBR78TctWB3QCoO 8O5dskyqIUoimB5XPJjQjlSmVVl0WmMZAIJSWq4NQb2jTJdmIO+qfIEnATE4GawH14NJ 2cOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zlAbnbUEXp3wL3ZD4JehXAcGdK6kWuh3dXugSvlgoFc=; b=ktCd+mtiqZmD+3XoCgZ60qLejqaMp/Mo/hVSeWAmtdTm11+qS/PLSCMTAQKNJA0D/g 7bES0j6xIEXf5b5/oTm9LDBR6AO6pEvDyuSMZ2b94TpM+ZBnbSWh5Ct56u2kmGVFnUra KmSVBbjwZMOQcbZHLo7NREVC2Jf6oHRk/jdv9H5w1Ko8fP/dP8eeeLOPylc+C1CHCoqw 55zK/Nz0G9OnQ0KFG8EB8A7bIMJuAZvBMeWJssW+Q2AX4d/2gkhg4XowVDMVHdwdyiGd jGc3lUBMRCxpfZEFRpB1BE1zDiyWG6O3aCI4vtfYlvkrqd8eyPXanTvON47xDeMzPpT9 pHJw==
X-Gm-Message-State: AHYfb5jNgTWn7zupEPahAFbgsQDYZ1i7g2cCY2BYPQKEwm8V4btuaiN7 AEqtEFSGQXqRiaWD
X-Received: by 10.200.0.9 with SMTP id a9mr38177035qtg.107.1502828934401; Tue, 15 Aug 2017 13:28:54 -0700 (PDT)
Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id z199sm7026404qka.94.2017.08.15.13.28.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 13:28:53 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <6DF8489E-D780-4E4C-A132-31EEF8285BB7@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6201853B-136F-4EA2-86AD-E56F4F89CA3C"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 15 Aug 2017 16:28:52 -0400
In-Reply-To: <877ey4y62g.fsf@toke.dk>
Cc: Juliusz Chroboczek <jch@irif.fr>, HOMENET <homenet@ietf.org>
To: Toke Høiland-Jørgensen <toke@toke.dk>
References: <2D09D61DDFA73D4C884805CC7865E6114DBF5904@GAALPA1MSGUSRBF.ITServices.sbc.com> <87poc3yt3d.fsf@toke.dk> <22E4B7B8-317F-4CBB-8536-D0AB345B0837@fugue.com> <87h8xez9ys.fsf@toke.dk> <CAPt1N1m+218+FX_G+2W-msDWmxP8XXMKF9S0faTeCBnEEzk1uw@mail.gmail.com> <877eyaz2jm.fsf@toke.dk> <CAPt1N1m5nVGD-y2VrbkoTEPTs4qF98oRxGuvd-Has1yzuS0fmg@mail.gmail.com> <874ltez1wg.fsf@toke.dk> <7E8390B5-9048-4783-B17F-6C9EA5610887@fugue.com> <7ivalujdfu.wl-jch@irif.fr> <15F1CE39-82EE-4B0D-A31B-2C1805991541@fugue.com> <871sofzqma.fsf@toke.dk> <CAPt1N1=oiU+DbjD6izOBNJOnC25d=-S3ARqFxydRfWLEet5mEQ@mail.gmail.com> <87valry4o7.fsf@toke.dk> <FCAD81FA-BBA0-45B0-8F1F-D1D5FD010484@fugue.com> <87shgvxybl.fsf@toke.dk> <4AF8CF8A-F781-449F-9C53-A9603889746E@fugue.com> <87lgmnxr3u.fsf@toke.dk> <E3E75086-BF36-4F59-86BD-7FFDAFE772AB@fugue.com> <87fuctxdrc.fsf@toke.dk> <FB44A942-9DE3-4CE6-88C5-402B20756462@fugue.com> <877ey4y62g.fsf@toke.dk>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/ZWSlkMg04Q93Q-45nagt29n_lZ8>
Subject: Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Aug 2017 20:28:58 -0000

El 15 ag 2017, a les 15:38, Toke Høiland-Jørgensen <toke@toke.dk> va escriure:
>> I think we are wandering off into nonsense territory here.   Have you
>> observed this sort of problem in the field?   If so, can you describe
>> what happened?   If not, why would we optimize for it?
> 
> If you consider flaky ISP DNS servers to be "nonsense" you are clearly
> more fortunate with your ISPs than me. And that's before even going into
> the DNS censorship issue; in my part of the world ISP DNS servers are
> broken *by design*.

In both of these cases, you are better off doing what we discussed earlier and setting up your own DNS cache, possibly with a whitelist for domains you want to send to the ISP forwarder.

>>> Right, so if this is the case, how about we specify that routers MAY (or
>>> maybe even SHOULD) support MPvD-specific resolver addresses, and
>>> advertise the fact over HNCP. And that if a router receives such an
>>> announcement from another router it MUST announce the MPvD-specific
>>> resolver addresses over DHCP/RA. This way we ensure that *if* a router
>>> on the network implements MPvD it is going to work for the whole
>>> network; but routers can still opt to not implement the functionality
>>> itself if the implementer doesn't want to pay the implementation cost.
>> 
>> Can you describe for us what this implementation cost is that you want
>> to avoid?
> 
> Can you describe for us how multiplying the number of resolvers by N (or
> MxN if we follow your suggestion of running a full set of resolvers on
> every router) is *not* going to incur a significant implementation and
> debugability cost?

It's just a bunch of ports/address pairs, with one thing listening on all of them, and using the port/address pair as a behavioral selector.   I'm not going to say that it's zero effort, but it's not hard.   Honestly, every home router right now has some kind of DNS proxy or DNS resolver in it; this is not a big change.   Compared to, say, implementing HNCP or DNSSD, it's utterly trivial.