[Arcing] ARCING BoF and mailing list

Douglas Otis <doug.mtview@gmail.com> Sat, 30 January 2016 02:25 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: arcing@ietfa.amsl.com
Delivered-To: arcing@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0C31B2E2E; Fri, 29 Jan 2016 18:25:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 bdGp3CCp0KUM; Fri, 29 Jan 2016 18:25:05 -0800 (PST)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 F1ABA1B2E30; Fri, 29 Jan 2016 18:25:04 -0800 (PST)
Received: by mail-pa0-x233.google.com with SMTP id yy13so50272907pab.3; Fri, 29 Jan 2016 18:25:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=cvhSWLuP83s7vpDq+nYXyjNQDsjAOvuDOf4RKscKk4A=; b=jkCfmcrpv7NIX6P5YTaX+5eGKszm/A+D2ZFQtOmlmK4BLsLeT82I3T5E2UbZfEu49/ UOybCEZK6T6pdieF18UpacCvEYUfMzZ3SQO04J2p/kniaaERJ1jnmEtz/OUgRvTbDXiF nMxt4tOMtlhnV7k38jKiXCiB8wHoj8UzVMPnzarsx0Ce/5m0PkMEJiaLBYn5rS5Kq6Ne itjgElsCwwCKo7e6/QL5LLmmG54q7rwbAGcY9rylhUcv25mjGpgEK/Kr2Hx/4Et1x6vQ 7R1WufoyZ/oUNgLfdr9lvttJvwjVO/0UJugjdrWcdkRqokPJBUbdc6iaF9bAynYRnWA/ cGIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:cc:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=cvhSWLuP83s7vpDq+nYXyjNQDsjAOvuDOf4RKscKk4A=; b=AG0fFVUK4Rt2GfR3v4Lil40IQ6Utu9waMQcGkeEh+EXUATN1dsp7K13wtxbW3YEPDs A9C0q8sOLxH7wzSinfA9wz+Ayua+WbHzzFrkZnr1O2eiURqCMacwnoABQjf/duOchHhS kzt4PEY+brxQSxkXruLw+ccHdqDC4cBhvZUGrw+651wIQY/NeMcF/6hk7u13axPeRPA4 tZbc4iXJsNzXLnogL24wbDM2cagWc3fL43F2ySAulmi4Zaq9jMe+Y6U9ygiQx2KxcvWB b/15entl47lXTdJDZR9HArScrSRDjsq3ufOIoaIoF9CyCuiM7sKCpZHtIXP91i7+Lka5 kFBQ==
X-Gm-Message-State: AG10YOQ6ijxdMrCBX0EdjdXWTnLhW4VfcccDbz7gH6Fxr+jYA/emXfZC4qd/oaw81+mvWQ==
X-Received: by 10.67.6.67 with SMTP id cs3mr18591125pad.143.1454120704663; Fri, 29 Jan 2016 18:25:04 -0800 (PST)
Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id 76sm14145121pft.44.2016.01.29.18.25.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 18:25:04 -0800 (PST)
From: Douglas Otis <doug.mtview@gmail.com>
X-Enigmail-Draft-Status: N1110
To: "arcing@ietf.org" <arcing@ietf.org>
Message-ID: <56AC1F60.6060803@gmail.com>
Date: Fri, 29 Jan 2016 18:26:40 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/arcing/p0T5sOb7k66-_j1szBJ5xP5sFGc>
X-Mailman-Approved-At: Sat, 30 Jan 2016 00:31:49 -0800
Cc: Ray Bellis <ray@bellis.me.uk>, Andrew Sullivan <ajs@shinkuro.com>, ietf dnssd <dnssd@ietf.org>, mark@townsley.net, suzworldwide@gmail.com, Warren Kumari <warren@kumari.net>
Subject: [Arcing] ARCING BoF and mailing list
X-BeenThere: arcing@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names <arcing.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/arcing>, <mailto:arcing-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/arcing/>
List-Post: <mailto:arcing@ietf.org>
List-Help: <mailto:arcing-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arcing>, <mailto:arcing-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jan 2016 02:25:07 -0000

Dear Ted,

https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02

https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf
,--
Lacking clear RFC 1918-like guidance directing operators to
DNS namespaces safe for internal use, several such
namespaces have been “appropriated” for this purpose over
the years. While the etiology is subtly different, the .corp
and .home TLDs are clear outliers in this respect; the use
of .corp and .home for internal namespaces/networks is so
overwhelming that the inertia created by such a large
“installed base” and prevalent use is not likely reversible.
We also note that RFC 6762 suggests that .corp and .home are
safe for use on internal networks.
'--

Reservation of Special-Use Domain Names will not circumvent
normal domain name registration processes. Reservation as
a Special-Use Name can however ensure it is NOT part of
the DNS global namespace and returns NXDOMAIN. In the case
of .corp or .home, a responsible agency is irrelevant due to
conventions established by those meeting obvious necessities.

Registering a domain should not be considered a necessary
expense for resolving hosts contained in homenet realms. A
home network may consist of multiple links interconnected
using IP-layer routing rather than link-layer bridging
where multicast might be impractical or poorly supported.

Homenet routers should not forward link-local IPv6 packets
to exclude traffic forwarded from the global Internet and
may not forward some multicast traffic (especially that of
non-diffused mDNS). A Special-Use Domain Name can anchor
DNS-SD resources without being mistaken for an
organizational domain. Otherwise devices made by many
vendors are likely to make use of non-registered names
nevertheless. Adopting a Special-Use Domain Name better
ensures against future name collisions and resulting
confusion that might otherwise occur.

The URI domain is normally assessed from a security
standpoint and used to illicit user feedback of potential
threats where changing the URI form would be counter
productive since this would require needless widespread change.

Special-Use Domain Names of Peer-to-Peer Name Systems

GNU Name System (GNS), for example, defines a decentralized
and censorship-resistant overlay able to operate within mesh
network topology as a bootstrap replacement. Special
zone relative names based on a distributed hash offer
DNS-free access for Friend-to-Friend networks. Relative
names end in '.+' which indicates names resolved relative to
the current local authoritative zone. Replacing the '.+'
with the delegation chain to the authoritative zone produces
a valid GNS name. Swapping .home for .gnu reduces the
burden seen at root servers, and offers interesting
techniques for handling local name space that can be
differentiated by GNS specific Resource Records. Perhaps an
I-D should be written to further extend the potential use of
a DNS overlay and how to make its use locally safe.

Perhaps use of GNS Resource records as an extension could
eliminate a need for the resources and administration
otherwise necessary to support Internet accessed DNS just to
establish local names not published below the .local TLD.
Currently there is no site-local scope naming conventions
available and this should be changed without impacting URI
conventions where examination of the entire name is most
often used to assess any need for caution.

Regards,
Douglas Otis