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

Fernando Gont <fgont@si6networks.com> Mon, 16 November 2015 13:47 UTC

Return-Path: <fgont@si6networks.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 5E7BF1AD1DB for <v6ops@ietfa.amsl.com>; Mon, 16 Nov 2015 05:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.341
X-Spam-Level: **
X-Spam-Status: No, score=2.341 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 TlkE4-sFYFlQ for <v6ops@ietfa.amsl.com>; Mon, 16 Nov 2015 05:47:10 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A1F1AD1A6 for <v6ops@ietf.org>; Mon, 16 Nov 2015 05:47:10 -0800 (PST)
Received: from host77.186-109-138.telecom.net.ar ([186.109.138.77] helo=[192.168.1.84]) by web01.jbserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from <fgont@si6networks.com>) id 1ZyK7b-0007DN-NU; Mon, 16 Nov 2015 14:47:04 +0100
To: Owen DeLong <owen@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>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <564975CF.7000908@si6networks.com>
Date: Sun, 15 Nov 2015 22:21:03 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5E956A69-0C7F-4DA9-BCD0-8914319D79B1@delong.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/_TvsPX5ZrbxtLqfJOCO4CrQgcoo>
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 13:47:11 -0000

On 11/12/2015 08:53 PM, Owen DeLong wrote:
>>>
>>>> On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) <evyncke@cisco.com
>>>> <mailto:evyncke@cisco.com>> wrote:
>>>>
>>>>> Nope. It is much easier to establish a connection across a diode
>>>>> firewall than to establish one across a NAT. In the former case, all
>>>>> the endpoints need to do is send each other packets at about the same
>>>>> time. In the latter, they need to implement NAT traversal via relays.
>>>>
>>>> It is only 'slightly' easier... Because guessing the TCP sequence
>>>> number of the other party... Well good luck :-)
>>>
>>> With a diode firewall, you don’t have to guess. Most diode firewalls
>>> don’t look at TCP sequence numbers actively. They look only at the L3
>>> and L4 identifiers to determine state.
>>> Some look at SYN bits and toss SYN packets going in the wrong direction,
>>> but most just look for an ACK bit.
>>>
>>> Nonetheless, it’s also much easier because a diode firewall can easily
>>> be given an exception to permit a particular flow or the initiation of a
>>> class of flows to a particular protected host or set of hosts.
>>
>> The problem is how to do this automagically.
> 
> Why does it have to be automagic?

Because the regular user is, alas, a user, and not a fw adminsitrator.



>>> 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.

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.

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

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


>> 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?



> 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".

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.

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.


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492