IETF Logo Mail Archive

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

"Fred Baker (fred)" <fred@cisco.com> Mon, 09 November 2015 02:44 UTC

Return-Path: <fred@cisco.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 209C01B5A1A for <v6ops@ietfa.amsl.com>; Sun, 8 Nov 2015 18:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.51
X-Spam-Level:
X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 u20DwJ_E3ZTG for <v6ops@ietfa.amsl.com>; Sun, 8 Nov 2015 18:44:48 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECBE1B5A15 for <v6ops@ietf.org>; Sun, 8 Nov 2015 18:44:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5178; q=dns/txt; s=iport; t=1447037089; x=1448246689; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VnEeabmcoCdjb8lOKvz6D3h2IDPl6q5vwE9mYWMJakc=; b=A4C1xVCKlFOHQiXArRa0cL3wgJHZXbbOpXDId4a0b4+UQ3w1QkTNg8/B HsxC+9EWiyqfyeVje6rbIzk+m633zL4mXNqSQpUNjOf5humhzmwDLyUfO /qjMC8MVe+MnkBIUq4mN3paiVniJG0OQoaCx/EZiVqZkj5OeliXWnyjxB g=;
X-Files: signature.asc : 833
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CwAgBLCEBW/5tdJa1egm5NgUIGvicOgWGGEAKBJzgUAQEBAQEBAYEKhDUBAQEDAXkFCwIBCAQKCi4yJQIEDgUOiBgIv1wBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCYhkgm6IJIEVBY0biS0BglKBYYhznEQBHwFDhARyhF+BBwEBAQ
X-IronPort-AV: E=Sophos;i="5.20,264,1444694400"; d="asc'?scan'208,217";a="206356741"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 09 Nov 2015 02:44:48 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA92ikxu018113 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2015 02:44:47 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 8 Nov 2015 21:44:46 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.000; Sun, 8 Nov 2015 21:44:46 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Fernando Gont <fgont@si6networks.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?
Thread-Index: AQHRGpiYLIJZzDje/USsgQB0Rmj57w==
Date: Mon, 09 Nov 2015 02:44:46 +0000
Message-ID: <6CB67A6E-FA1A-41EC-93A3-B8CC97D56B02@cisco.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> <563FA84C.7030601@si6networks.com> <CAKD1Yr0F888Aw0opSigtC8HV6esUrE1JECKQ4gT737s+43ayfw@mail.gmail.com> <CAG6TeAs8ie=c0F8RMioBpemCw949Bf9c7ZTNvqgaZP=10rmNcQ@mail.gmail.com> <CAKD1Yr1EqbiGJ8EZo8E909zujUt49skcz1SNe8stEWfHnbUsTw@mail.gmail.com> <CAG6TeAsHMTyhbRrOenb1kA9XEDdOCBBbuN3ZGF3LJ=8ToyGtiQ@mail.gmail.com> <CAKD1Yr3RUc9FEw7VyJ=ENH_sJY85m1BESo77v_maShPvCkj6rA@mail.gmail.com> <CAG6TeAv9DPYUCsNG_vHCTOpwwJ8KdhjWeGE=-s6dEuMgaVHf1g@mail.gmail.com>
In-Reply-To: <CAG6TeAv9DPYUCsNG_vHCTOpwwJ8KdhjWeGE=-s6dEuMgaVHf1g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.141.46.11]
Content-Type: multipart/signed; boundary="Apple-Mail=_15C61558-294E-4B4E-9605-D673FAAB2399"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/HYyL5U4d3QjnEteKt-DgK60YEcw>
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, 09 Nov 2015 02:44:52 -0000

> On Nov 9, 2015, at 11:27 AM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> layer 3 addrs in layer 7 protocols is not clean design. Period.

To my way of thinking, this is very fundamental. RFC 3439 makes a point about coupling, and how coupling causes problems. When an application presumes that an address that is meaningful in its environment is meaningful in another, that is a very basic coupling. If the remote system were given a name - an L7 identifier - that could be translated into an address in the remote environment, which would resolve many of the issues. The problem is not that NAT broke IPv4, or that IPv4 is broken; it is that the applications written using IPv4 made an unfortunate coupling which NATs exaggerate.

I have a similar comment about the socket layer. Having the application ask the OS for a translation and then connect to the address has been very unfortunate for IPv6 deployment; had the socket layer been designed to have the application present a character string (an address in textual form or a name) and return a connected socket, IPv6 deployment would have been invisible to the applications. It's a bad design at the socket layer, and it's not IPv4's fault or IPv6's.

v2.23.0 | Report a Bug | By Email