Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

Owen DeLong <owen@delong.com> Tue, 13 August 2013 04:56 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82821E80BB for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 21:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQhbgbweMp6Z for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 21:56:19 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF121E80AC for <v6ops@ietf.org>; Mon, 12 Aug 2013 21:56:16 -0700 (PDT)
Received: from [10.255.251.216] (kiwi.he.net [216.218.252.66]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7D4qWw9032357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 21:52:32 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7D4qWw9032357
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376369557; bh=Y/ptHHLcnbL7XU4/xgqRxQKXzl4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=3SkD7K3T05QieopWXWnk5nRV05uTzrvsoNhfy2atK5fqSYqkARW7j+Trj0b5l12jY EL6MD7KcPEHbBsoSLgv997tGf3KZ5OKfvIbiwJ3moapwGO5PRoGAnOzHRCq9wVZpUM JbTzP/jE41jvBAxMdvBpthwTxzR4I4MG5hGVMCas=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20130813025336.918353846F7A@drugs.dv.isc.org>
Date: Mon, 12 Aug 2013 21:52:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <696F80F4-97A7-4A52-B9F0-8A3CFA4B0B30@delong.com>
References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <B66D2D0C-DE6D-49CC-A87A-7C65B5360DB4@delong.com> <20130811233819.AE71C383CF0C@drugs.dv.isc.org> <5773BB43-B910-482A-A6EF-AFCD2B6AE181@delong.com> <20130812211453.89A833845161@drugs.dv.isc.org> <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com> <20130813025336.918353846F7A@drugs.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1508)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 12 Aug 2013 21:52:37 -0700 (PDT)
Cc: Alejandro Acosta <aacosta@rocketmail.com>, v6ops@ietf.org
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 13 Aug 2013 04:56:24 -0000

On Aug 12, 2013, at 7:53 PM, Mark Andrews <marka@isc.org> wrote:

> 
> In message <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@delong.com>om>, Owen DeLong writes:
>> Given the wide prevalence of RFC-1918 islands that were merged with
>> double NATs instead of repaired in the IPv4 world (which I believe =
>> likely
>> outnumber the number of environments where one or the other entity
>> was actually renumbered into non-conflicting space), I think we have
>> strong evidence that this is not true.
> 
> And how many RFC-1918 islands had alternate address space to renumber
> into?

The vast majority of the ones I am aware of. Very few companies are using
all of the RFC-1918 space entirely.

> How many RFC-1918 islands started out knowing they would have to
> renumber if there was a collision when they connected to someone
> else?

Virtually all of them.

> How many RFC-1918 islands were designed to run with multiple addresses
> per interface from day one?

A few, but not many.

> How many RFC-1918 islands run dual IPv4 addressed?

A few, but not many.

> Now ask the same questions of ULA islands.  You have different
> solutions available with ULA than you do with RFC-1918.  NAT is not
> required to fix ULA collisions.  ULA sites with collisions don't
> even need to renumber out of the colliding prefixes if they don't
> want to.

1. Same answer.
2. Same answer.
3. Admittedly, this is reversed, but I don't think that will make a significant difference.
4. Admittedly, this is reversed, but I consider it pretty much identical to question 3.

NAT is not required to fix RFC-1918 collisions IN MOST CASES. It's simply a lot
more convenient (for the people making the decision) at the cost of great woes
for the people using the networks.

So far, you've offered NOTHING to suggest that this would be different with ULA.

Owen