Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01

Owen DeLong <owen@delong.com> Thu, 01 May 2014 22:33 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 33D4A1A06DB for <v6ops@ietfa.amsl.com>; Thu, 1 May 2014 15:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.641
X-Spam-Level:
X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 Ad0AQYUp26eu for <v6ops@ietfa.amsl.com>; Thu, 1 May 2014 15:33:27 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD81A09D4 for <v6ops@ietf.org>; Thu, 1 May 2014 15:33:27 -0700 (PDT)
Received: from [10.5.16.141] (adsl-69-228-81-237.dsl.pltn13.pacbell.net [69.228.81.237]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s41MVe0I026836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 15:31:49 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s41MVe0I026836
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1398983515; bh=hixHDbA5BVBDoBF4XG0UIAOVPw8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KrixBnC93442UVaaY3fxDB1r+Qd8jLvkglnaNbHFNDHmP2bQTP878FgnQAfj/RFSL 00PoPA86M//RPauKVY2FpFm+gTIO+W3plA7gs8bbt1qtTSL32z2X89pagjQmGmsvoU qRedvH/t55vQUOjC8B4y3StO/2c9kVUiubbMoQkg=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <5361DBFA.3010403@bogus.com>
Date: Thu, 01 May 2014 15:31:40 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6D62ADF-63DF-41CE-92F2-361E3120CFB5@delong.com>
References: <DA7557DA-C003-4FAC-A1C5-2FAD5BD028EC@cisco.com> <CAKD1Yr3JA8jKjfk1BMA4dfMQ8CQ5L5V5txnEmXPLjE=CnOR9VQ@mail.gmail.com> <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <CAKD1Yr2AZN7+czefosQG9uaJ0dDLmtrAp7+QHKOP+Kpk+rBvcA@mail.gmail.com> <5361DBFA.3010403@bogus.com>
To: joel jaeggli <joelja@bogus.com>
X-Mailer: Apple Mail (2.1874)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 01 May 2014 15:31:55 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mE2CZskOGDhHdx4LPiR47AUSVk4
Cc: V6 Ops List <v6ops@ietf.org>, "Byrne, Cameron" <Cameron.Byrne@t-mobile.com>
Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01
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: <http://www.ietf.org/mail-archive/web/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: Thu, 01 May 2014 22:33:29 -0000

On Apr 30, 2014, at 10:30 PM, joel jaeggli <joelja@bogus.com> wrote:

> On 4/30/14, 7:55 PM, Lorenzo Colitti wrote:
>> On Thu, May 1, 2014 at 8:24 AM, Fred Baker (fred) <fred@cisco.com
>> <mailto:fred@cisco.com>> wrote:
>> 
>>   Ask me someday what thoughts go through my mind about applications
>>   making inferences from network layer addresses.
>> 
>> 
>> The wording in RFC 3927 is much stronger. For example, it states
>> multiple times that packets sourced from 169.254/16 MUST NOT be
>> forwarded, and that they MUST NOT ever be sent to any router for
>> forwarding. I think it's perfectly reasonable for an app (or even an
>> OS!) to assume that such addresses have no connectivity.
>> 
>> 
>>   Hey, 192.168.0.0/16 <http://192.168.0.0/16>is for networks that
>>   don’t connect to the Internet. You want proof? From RFC 1918, the
>>   motivation is
>> 
>>      With the proliferation of TCP/IP technology worldwide, including
>>      outside the Internet itself, an increasing number of non-connected
>>      enterprises use this technology and its addressing capabilities for
>>      sole intra-enterprise communications, without any intention to ever
>>      directly connect to other enterprises or the Internet itself.
>> 
>> 
>> Funny, that's what the proponents of ULA-only networks say too - "no,
>> this network will NEVER connect to the Internet, ever!!11" I suspect
>> they do so because they know that saying "we want to use NAT to connect
>> this network to the Internet like we do in IPv4" is going to result in
>> strong opinions and removal of support for the use case. But that's
>> off-topic here.
> 
> site-local unicast in ipv6  and rfc 1918 are relatively contemporaneous
> ideas...
> 
> I don't thing the pressures that produce such solutions are particularly
> new in fact it's pretty easy to assert that they co-evolved.

Yes, but unlike RFC-1918, we came to our senses and deprecated site-local.

ULA came later as a result of pressure from people who loved their NAT. Sad, really, that the problem was not addressed through education instead of better RIR policies for global unicast.

Owen