Reinventing Site-Locals (Re: easy to remember addresses and /etc/hosts and DNS)

Mark Smith <markzzzsmith@gmail.com> Sat, 27 April 2019 02:20 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD43120086 for <ipv6@ietfa.amsl.com>; Fri, 26 Apr 2019 19:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dbDCsOFHMdMQ for <ipv6@ietfa.amsl.com>; Fri, 26 Apr 2019 19:20:19 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 C536C120098 for <ipv6@ietf.org>; Fri, 26 Apr 2019 19:20:19 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id j10so4315629otq.0 for <ipv6@ietf.org>; Fri, 26 Apr 2019 19:20:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3AB9cRn2ir/d6aaKr1hPEM2Gz9ed+s+JVu5zem3jsmY=; b=ui8AoQm9tElfeWt2sNSs1SvY+9KPufl+5bn0GfNp/ENOx7lnE+radMSDM9fttwVLol uVOBAn2LeWt/ni3iiZoMEDei3yVAXwu3TMDUvLlVXMrPsIixsqbxMFKZiGHLmovEN4Fl ea0llt9QVucpohx5IzEufOFltuMNNYb53SBVgxd9zboCM5PPphVRdrqEvxQ5Wh4ljKF9 cf54Mv3AH0Bz5tDBMbBHLOhWG0dRBwe6Vvzu6Ql/7wkfWiywYopuFskb4F02pPj3o7qr ZcTsaQecDMUtFqKfjVaNwi7Vt1FmVdq5OTVK1V81qPcrtjRts+Nlbn9JSlYpFXme6Ikn t8Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3AB9cRn2ir/d6aaKr1hPEM2Gz9ed+s+JVu5zem3jsmY=; b=jhxY+8GXxODQmC7boZO0zYaHUEBCAWfvgwWVceTQXdJDJpPJCHO+toYiOypX0SPnHD /3VxzYXiqK7W+tKKOBgxTw4Oe4bO3pyPioxcRRdzPBq/661g1sd2ymUBXr5RQ2Ctmn23 vT0AsDjvIAOSH3WnY4HuQgFoZsQoKkEDY6A2jbWbvNANX2jzED/de/Gkid7h8JJDVqIP 1pYxGV5v4SzpwEuazhZ+eMv7T8qWTbvOtopoZJZxcVQGYJ5jNf8HjuMpvk1Un8rStWh0 eF8gatvJ9r3zGgermzbIc8xkv+s5zRCMDp61FWkOJNiYtAcTLnKdXFNESGLdru9OAfhT /wmQ==
X-Gm-Message-State: APjAAAWgeGHW5XUpJKcN7WJjZrPkrz6M65eq/jXP6ceI4/+DdNqrlk/C khTt+wmbI7h0qHO5hRJBoTWL72erwrLslYB3kng=
X-Google-Smtp-Source: APXvYqxvei59qFo9yGM2NOEDrh4DuMSr68ApPWT6SOm1n2cjoFE9xjAEv04VN4+OkNVPjAkpmuPTLJElNN0DF4UFakM=
X-Received: by 2002:a9d:4e15:: with SMTP id p21mr13365126otf.285.1556331619034; Fri, 26 Apr 2019 19:20:19 -0700 (PDT)
MIME-Version: 1.0
References: <bb7f7606-2adf-e669-8bcd-e41f17800782@gmail.com> <CAJE_bqd9frqX5-yeVPj8MYXpZ4737HqK1gmfD9cQV3A-Ea5HrQ@mail.gmail.com> <6bd5db47-408a-727e-5c13-f34a3465f986@si6networks.com> <CAJE_bqfTLqRbLp4fLu2ASZuZ+4G5c2G+RXkO92kXfLgPTqBnng@mail.gmail.com> <EEF00EA7-2AAF-403F-99AD-1D53ED18E8B3@cisco.com> <CAJE_bqe8OXPWRDvXEY66gZHiBgv37OV67YB27WoEtq_VmBqieQ@mail.gmail.com> <3F852B26-FD19-445D-A8E9-94BCBB9BE7C1@gmail.com> <455C3D20-E71B-4DF4-837E-081964E3328A@gmail.com> <19275484-3fa5-7c4e-3624-b861ddea6e2f@gmail.com> <2B1FBA08-3DDB-4287-B2B4-11324334B7FC@employees.org> <5b3f148a-3f61-66ea-716a-9f29cb4de346@gmail.com> <m1hJazF-0000ILC@stereo.hq.phicoh.net> <b6cb92ac-859e-cf8a-d4cf-1115ff7a8241@gmail.com> <b810937b-8989-1c61-89b8-2b8ee176587a@gmail.com> <CAO42Z2z+SYZnf2TztPVW3h6mZFj6B8BKqDsa=vcsLJ1gmz6gpQ@mail.gmail.com> <7131ea21-1a0c-ebe7-d08b-50747f8c4229@gmail.com> <CAO42Z2yuh3jtU6YJMoyCOruZozyyEgTxeeBpot2jqMW5S=zWfw@mail.gmail.com> <6c84b452-ff6b-373d-2efb-9f4e337f0a5d@gmail.com>
In-Reply-To: <6c84b452-ff6b-373d-2efb-9f4e337f0a5d@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 27 Apr 2019 12:19:52 +1000
Message-ID: <CAO42Z2w_gk4yyrBhXydeB4P+9FV4XzqyKcib1_JspZ+xxYxeew@mail.gmail.com>
Subject: Reinventing Site-Locals (Re: easy to remember addresses and /etc/hosts and DNS)
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZK0xXBPMBDRBUifqGccBiF9tvv4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Apr 2019 02:20:22 -0000

On Fri, 26 Apr 2019 at 21:36, Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:
>
>
>
> Le 26/04/2019 à 12:05, Mark Smith a écrit :
> > On Fri, 26 Apr 2019 at 19:54, Alexandre Petrescu
> > <alexandre.petrescu@gmail.com> wrote:
> >>
> >>
> >>

<snip>

> >>>>
> >>>> But think about three cars in a covoy; the convoy is disconnected from
> >>>> the IPv6 Internet, yet fully connected on IPv6 between all computers in
> >>>> the convoy.  Which of the cars should host the DNS server?
> >>>>
> >>>
> >>> All of them.
> >>
> >> Mark,
> >>
> >> Thank you very much for the suggestion.  I will consider it.
> >>
> >> I would like to ask you: is multicast DNS (mDNS) working on a single
> >> subnet only?  Or does it work across subnets?
> >>
> >
> > I'm not an expert in mDNS or related, have just read enough to know
> > what problem they're solving and (very) roughly how it works.
> >
> > DNS Service Discovery is intended to convey that information across subnets:
> >
> > http://www.dns-sd.org/
>
> I suppose DNS Service Discovery works ok on IPv6, and over multiple
> subnets, and that it relies on the proper use of IPv6 multicast routing
> protocols.

No, I'm pretty sure it doesn't. It's designed to be able to work over
the Internet, so no multicast required.

> I never tried IPv6 multicast routing protocols on links
> involving OCB (a kind of stripped ad-hoc WiFi at 5.9GHz).
>
> I suppose the use of DNS resolver address in RA is also an option in
> this space.  I have tried this DNS-in-RA and it works ok.
>
> Whether DNS-in-RA, DNS-SD and mDNS should be used in cars, and how, can
> be a subject of debate.  There is a Problem Statement draft in the
> IPWAVE WG that lists in section "DNS Naming Service" some considered
> problems.
>
> Until these things get fixed (how to use DNS in car convoy?) I need the
> manual configuration of easy to remember link-local addresses
>

It will be much easier to adapt existing name and resource discovery
methods and protocols to your problem space than to get RFC4291
updated to include a unique subnet ID in Link-Local addresses.

> When DNS works in car convoys, I expect other inconvenients using
> name-to-address mappings compared to IP address literals.
>

You need to read "The Design of Everyday Things" if you think typing
in IP address literals is more user friendly than device names.

https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things


The importance if giving names to devices instead of expecting users
to remember numbers has been recognised for at least as long as the
last 47 years, when the ARPA Network only had 20 hosts on it, and
single octet addresses -

RFC 226, "STANDARDIZATION OF HOST MNEUMONICS", 20 SEPT 71.


Discovery of services and resources with names on the network is as
least as old as 1982 -

(Xerox) "Grapevine: An exercise in distributed computing"
http://birrell.org/andrew/papers/Grapevine.pdf


> I might need to update the DNS servers' files with new IPv6 Link-Local
> address to name mappings, whenever a faulty interface is replaced, or
> when USB interface keys are moved, or when 1Gb Ethernet cards are
> migrated to 10Gb Ethernet.
>
> If I am to update files, why not updating rather the computer startup
> scripts (not DNS)?  These computer startup scripts are present in all
> computers, including embedded, as unencumbered and open source.
>
> Second,
>
> If I use DNS names I must remember a name like:
> front-Lead-First (means the IP address on the front bumper of the
>                    Follower, in the subnet between Lead and First
>                    Follower)
> rear-Lead-First
> front-First-Second
> rear-First-Second
> etc.
> These names are too long to type.  So I would abbreviate them to:
> flf
> rlf
> ffs
> rfs
> etc.
>
> These flf, rlf, etc are no less cryptic than a literal like fe80:1::1 is.
>
> The short IP address literals are loved and understood by more people.
>

A test for you. Which would you find easier to remember?

This series of numbers?

821
826
791
1035



or this series of acronyms and what they stand for?

SMTP
ARP
IP
DNS


> >> (because the numerous computers in these three cars are not all on a
> >> single subnet; they are all interconnected with IP, but there are
> >> multiple subnets with routers in between).
> >>
> >

Right. This confirms my suspicion. If you got us to add Subnet IDs to
Link-Local addresses, I'm confident you'd next be lobbying them to be
routeable across different links attached to routers.

In other words, you'd want these Link-Local addresses to have a scope
that is greater than a link.

We used to have an address space for that, called the Site-Local address space.

Read why they were deprecated and then replaced by ULAs in RFC 3879.

You won't like that they're easy to type, however that is the cost of
solving all of the issues described in RFC 3879.

(If you wanted a problem description of the problems that duplication
IPv4 address spaces cause i.e. RFC1918 addresses, RFC 3879 would serve
that purpose too - as does RFC1627 - "Network 10 Considered Harmful
(Some Practices Shouldn't be Codified)".)

> > There may be other options that better suit or can be better made to
> > suit what you're trying to do, such as the work done in the Homenet or
> > the ANIMA Working Groups.
> >
> > Autonomic networking (the focus of ANIMA WG), sounds like it might be
> > working on solutions to your problem domain.
> >
> > "Autonomic networking refers to the self-managing characteristics
> > (configuration, protection, healing, and optimization) of distributed
> > network elements, adapting to unpredictable changes while hiding
> > intrinsic complexity from operators and users."
>
> Yes, they should be considered.
>
> I will make this suggestion in the IPWAVE WG for the Problem Statement
> draft.
>

Good.

We really shouldn't have cars that can literally drive themselves,
while at the same time expecting end users (or anybody) to be spending
a lot of time typing in literal IP addresses.

Typing in literal IP addresses is the car equivalent of starting the
engine with a hand crank at the front bumper. Most cars stopped being
started that way in the 1920s.

Regards,
Mark.