Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Owen DeLong <owen@delong.com> Mon, 16 November 2015 20:41 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D561B314B for <v6ops@ietfa.amsl.com>; Mon, 16 Nov 2015 12:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level:
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, 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 QVQLPFBNnswz for <v6ops@ietfa.amsl.com>; Mon, 16 Nov 2015 12:41:55 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 195131B313C for <v6ops@ietf.org>; Mon, 16 Nov 2015 12:41:54 -0800 (PST)
Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tAGKdno5026028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 12:39:49 -0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <564975CF.7000908@si6networks.com>
Date: Mon, 16 Nov 2015 12:39:48 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C990D67F-C197-48F1-97D3-512734EC027F@delong.com>
References: <D25D5920.C914E%Lee.Howard@twcable.com> <563C7C01.6010703@foobar.org> <CAKD1Yr1rKjkDhhuD9L=R_MJ+ofOAZ2Nt+5mszZKQxCh-kH4vqw@mail.gmail.com> <563FA84C.7030601@si6networks.com> <CAKD1Yr0F888Aw0opSigtC8HV6esUrE1JECKQ4gT737s+43ayfw@mail.gmail.com> <CAG6TeAs8ie=c0F8RMioBpemCw949Bf9c7ZTNvqgaZP=10rmNcQ@mail.gmail.com> <CAKD1Yr1EqbiGJ8EZo8E909zujUt49skcz1SNe8stEWfHnbUsTw@mail.gmail.com> <CAG6TeAsHMTyhbRrOenb1kA9XEDdOC! BBbuN3ZGF3LJ=8ToyGtiQ@mail.gmail.com> <CAKD1Yr3RUc9FEw7VyJ=ENH_sJY85m1BESo77v_maShPvCkj6rA@mail.gmail.com> <CAG6TeAv9DPYUCsNG_vHCTOpwwJ8KdhjWeGE=-s6dEuMgaVHf1g@mail.gmail.com> <CAKD1Yr2VXVFareTk-J_+pcr_UW9Do-zf_uYcyjNW-MTPts6hRQ@mail.gmail.com> <CAG6TeAt2JJJmALy=pJFaojbnZrQRE0e0i-D=XtTce=rmbf08tQ@mail.gmail.com> <CAKD1Yr1H2HgxBNOZBrx-ttoB6z6caLAck3csF=ti6CDUzW57ng@mail.gmail.com> <D267B9E3.5DB8C%evyncke@cisco.com> <A3B1A605-399D-491B-A188-FB6109A55EC7@delong.com> <56453C96.7070509@si6netwo! rks.com> <5E956A69-0C7F-4DA9-BCD0-8914319D79B1@delong.com> <564975C! F.7000908@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/KZ5l88nJx-egHFcmalN-CcGI8Hg>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2015 20:41:57 -0000

>>>> In the case of a NAT, however (more specifically a NAPT), it is not
>>>> possible to program multiple port 80 terminations to land on different
>>>> hosts behind the NAT.
>>> 
>>> That's like saying that the problem with cars is that they cannot fly --
>>> yes, that's what a NAT is.
>> 
>> Well… That is certainly a limitation of most automobiles, but I’m happy to
>> report that there are working alternatives such as the Terrafugia Transition
>> and some older prototypes as well.
> 
> Then that's not a car. And that's my point. You're complaining about
> something that is a characteristic of NAT.

By what possible definition do you claim that the Terrafugia Transition
is not a car? It is most certainly a car which is capable of doing all the
things a car does and is also capable of becoming an aircraft.

> That said, there's no conceptual reason for which HTTP must run at port
> 80. And would be perfectly sensible to have multiple instances of
> different HTTP implementations at the same host, without having to
> resort to other hacks such as ip aliases.

Indeed many people run HTTP on non-standard ports for a variety of reasons
and many people (myself included) run other things (such as an SSH server)
on port 80 for other reasons (after the first time I encountered an airport lounge
that thought the only internet access I could possibly need was to ports 80
and 443, I set up an SSH server on port 80 to work around this limitation).

The problem is that there’s no DNS provision for A+P records or AAAA+P records
or even meaningful definitions of P records, so while it’s perfectly reasonable
to have http servers at [2001:db8::1]:80, [2001:db8::1]:81, …, there’s no good
way to make www.foo.com map to [2001:db8::1]:80 and www.bar.com map
to [2001:db8::1]:81 in the real world.

> Again: here NATs are making it very evident that harcoding HTTP to port
> 80 comes at a price.

No… They’re making it very evident that NAT comes at a price and part of
that price may come from the convenience of having HTTP linked to a
well-known port (there’s nothing magic about 80).

Unless you can convince client resolver libraries and applications to make
better use of SRV records, this is where we are in the real world.

It wasn’t broken before NAT. Sure it represents certain assumptions that
can be violated and NAT most definitely violates them in an extreme way.

However, it is a fundamental tenant of the architecture that I expect
the devices in the network not to edit my packets, but rather to forward
them without mutilation. NAT most definitely violates this and as a result,
it breaks things.

Claiming that this fundamental tenant is incomplete and that NAT is
not the problem is like claiming that it would be OK to introduce a
square ball into a basketball game, claiming that the fact the hoops
are round is a design flaw in the hoop.

> You don't want a full directory service? -- Fine... then pay the price
> for taking a shortcut.

I want a directory service that is adequate to the task. DNS does that
(mostly) and this is certainly not one of the areas where I consider it
to be meaningfully deficient.

The fact that NAT makes this capability more necessary than the network
without NAT does not make NAT inherently acceptable.

>>> I might also add that this is another kludge that is made evident by
>>> NAT: there's no reason whatsoever for which a given service should run
>>> in any specific transport protocol port. Consider that a kludge or
>>> shortcut than a principle.
>> 
>> Meh… There’s no mechanism available for signaling port numbers in response
>> to name lookups (modulo SRV records that don’t seem to be very popular in
>> practice). 
> 
> As you note, there is: SRV.
> 
> Regarding popularity, when did popularity became a metric of correctness?

It’s not a metric of correctness, but it is a metric of acceptance and more importantly,
a metric of usefulness.

Clearly SRV has not been deemed adequately useful to achieve wide-spread support
in client software.

>> There are certain advantages to the idea of well known port numbers
>> and whether or not you consider them a kludge, they are certainly in widespread
>> use and have a great deal of history and support in the IETF and IANA.
> 
> Can we have a technical discussion, please?
> 
> I'm arguing that there are many pieces of the puzzle missing, and you
> answer "having a full puzzle is not popular.. besides, everyone loves
> it, and we have done it for a long time”.

You’re arguing that NAT isn’t broken and/or doesn’t break things, but rather
that the design assumptions in the internet are what is broken and NAT being
not broke proves it.

It was never a technical discussion on either side. It has inherently been your
religious support of diode firewalls and NAT that has driven it away from a
technical discussion from the beginning.

> That's like arguing that McDonald's sells quality beef because their
> restaurants are usually crowded, and Mc has made a lot of profit for years.

No, it’s like arguing that Fred’s Burgers is probably not going to succeed
since there’s never anybody in their restaurants.

I’m not arguing that the popularity of the present system makes it not broken.
I’m arguing that solutions which do not achieve adoption are not solutions.

> McD might make a lot of money. There might be certain advantages of
> eating at McD (price (in some countries), timeliness, or whatever). But
> that doesn't make a Big Mac good beef.

Depends on where you go… In Moscow, the McDonald’s actually does
use decent beef (or at least did the last time I ate there in 1993).

Normally I’m not a fan of the golden arches, but it was what was open at
this particular hour and I was pleasantly surprised how much higher the
quality of the food was compared to US operations.

However, that’s a side issue.

The simple reality is that arguing that everyone should eat soy tofu burgers
because beef burgers are somehow inadequate or soy burgers are healthier
or whatever doesn’t seem to change the fact that people like beef and will
go to McDonald’s or wherever else and nobody goes to the Soy Burger
Drivethru. When was the last time you saw a Soy Burger Drivethru restaurant?
If you’re wondering why, it’s because when nobody buys your “solution”,
then your solution clearly didn’t solve anything.

Owen