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

Philip Homburg <pch-v6ops-3@u-1.phicoh.com> Sun, 08 November 2015 19:47 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.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 BF5AD1A8A58 for <v6ops@ietfa.amsl.com>; Sun, 8 Nov 2015 11:47:49 -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] 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 J5wCRybFFIWA for <v6ops@ietfa.amsl.com>; Sun, 8 Nov 2015 11:47:47 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0961A89A6 for <v6ops@ietf.org>; Sun, 8 Nov 2015 11:47:47 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZvVwA-0000CLC; Sun, 8 Nov 2015 20:47:38 +0100
Message-Id: <m1ZvVwA-0000CLC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.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> <563C7C01.6010703@foobar.org> <CAKD1Yr1rKjkDhhuD9L=R_MJ+ofOAZ2Nt+5mszZKQxCh-kH4vqw@mail.gmail.com> <563F3AC3.6000205@foobar.org>
In-reply-to: Your message of "Sun, 8 Nov 2015 12:06:27 +0000 ." <563F3AC3.6000205@foobar.org>
Date: Sun, 08 Nov 2015 20:47:32 +0100
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/IbIZxBopxi5409fKB0riixeX7Io>
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: Sun, 08 Nov 2015 19:47:49 -0000

>On 08/11/2015 05:25, Lorenzo Colitti wrote:
>> On Fri, Nov 6, 2015 at 7:08 PM, Nick Hilliard <nick@foobar.org> wrote:
>>>    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.
>> 
>> Nope. Those protocols aren't broken, they worked fine for years until NAT
>> arrived and broke them. They still work fine on networks that operate the
>> way the Internet was originally designed with end-to-end connectivity.
>
>NAT predates both sip and the vast majority of other protocols which encode
>inline transport layer identifiers (skype, other chat, etc).
>
>Also, I hope you're not arguing that protocol layering violations are
>acceptable from a design point of view.
>
>You're correct that ftp predates nat but having said that, its layering
>violations were recognised from the earliest days of the internet as being
>atrocious protocol design because of the problems they caused.

Call me old fashioned, but what NAT breaks is not what is traditionally
called a protocol layering violation. (The TCP checksum is one of the classical
layering violations in the IP protocol stack)

At the transport layer you have transport level network addresses. In transport
protocols such as TCP or UDP, a transport level address consists of an
IP address and a port number. Since the start of the internet, that's how we
refer to transport level sockets.

So it is perfectly normal for protocols above the transport layer to pass
transport layer addresses around. How else would a distributed application
organise itself?

But NAT breaks that.

But NAT also breaks the core internet protocols. Suppose a host uses dynamic
DNS to register its IP address in DNS (alternatively, a DHCP server can
register on behalf of the client). This will completely fail in the context
of NAT unless all DNS servers where such an address might be registered are
aware of NAT and avoid returning those resource records to parties outside
the NAT.

So a network level device requires changes in a application layer protocol.
A clear layering violation.