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

Nick Hilliard <nick@foobar.org> Fri, 06 November 2015 10:08 UTC

Return-Path: <nick@foobar.org>
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 53C871B3879 for <v6ops@ietfa.amsl.com>; Fri, 6 Nov 2015 02:08:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 DepfMIU066EO for <v6ops@ietfa.amsl.com>; Fri, 6 Nov 2015 02:08:14 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF571B3876 for <v6ops@ietf.org>; Fri, 6 Nov 2015 02:08:13 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id tA6A81H9040050 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2015 10:08:01 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.local
To: Lorenzo Colitti <lorenzo@google.com>, "Howard, Lee" <lee.howard@twcable.com>
References: <D25D5920.C914E%Lee.Howard@twcable.com> <5637FDD0.70300@jvknet.com> <D25E32F1.C9507%Lee.Howard@twcable.com> <CAKD1Yr1VvzkSmJo3hu6t_3CUguLN_UkNZjRUqvU_ygPBTyb+8g@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2319739@nkgeml506-mbx.china.huawei.com> <CAKD1Yr3g-ZV+MkbtDrusbtYaZ_wmCxDG9XbT25Ldma4koGpV6A@mail.gmail.com> <D25E7DDF.C9709%Lee.Howard@twcable.com> <CAKD1Yr3Vsn7Ny_xSCr_=sVCHyU+=ZrRh2iQDUPx-5FWdHajv2w@mail.gmail.com> <D2614A6A.CA099%Lee.Howard@twcable.com> <563B9D1E.4030606@umn.edu> <D261FE8E.CA1FB%Lee.Howard@twcable.com> <CAKD1Yr3jip0NBkDxg=MvgZXg0LMS+PtREDw2jSRx0xJLqHwhGQ@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <563C7C01.6010703@foobar.org>
Date: Fri, 06 Nov 2015 10:08:01 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr3jip0NBkDxg=MvgZXg0LMS+PtREDw2jSRx0xJLqHwhGQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------080301020707040301080103"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/5BZkP0NRV2qvVRJNOJQtBjx80OQ>
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: Fri, 06 Nov 2015 10:08:18 -0000

On 06/11/2015 00:20, Lorenzo Colitti wrote:
> It breaks any application that requires that the application know its
> source address. Examples are SIP, FTP, audio/video chat, etc.
your argument is the wrong way around: some protocols deliberately
introduce layering violations by demanding that transport identifier
information is encoded at the application layer.  Transport identifier
translation merely shows up this brokenness.  The brokenness is not with
the translation mechanism but with the higher level protocols.

You could argue that this is an angels-on-the-head-of-a-pin style argument
and that it doesn't matter which bit is broken because at the end of the
day, breakage happens and users get hurt.  The point is that is IETF
working groups like to get up on their collective high horses about
identifier translation but apparently don't bat an eyelid when people
create entirely new protocols with glaring layering violations.

I'd happy to see disapproval notices for NPTv6 appearing in this draft if
the IETF first issues explicit recommendations against using SIP, FTP,
audio/video chat and all other protocols which mandate layering violations.

I.e. at least the IETF should be even handed about this and not pretend
that the root cause of the problem is somewhere where in fact it isn't.

Nick