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

Owen DeLong <owen@delong.com> Mon, 12 August 2013 22:06 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 3C86821E8054 for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 15:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level:
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 Nxueg0Wyqehm for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 15:06:11 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5496121E8050 for <v6ops@ietf.org>; Mon, 12 Aug 2013 15:06:10 -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 r7CM4ZVZ019500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 15:04:35 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CM4ZVZ019500
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376345077; bh=rw+3mAj3oOK4wI07XudOC8rghhA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=I8gJxWfGadqi0lO1KoPlcLOqMiJoIFMiDo3Ns4BJsvpfKXSrwN//b7ArI4dDxbjjw 5JBn8qNiLdTCEtfklbdyEGqhhvT2sMIfuwu3Yb+V6lX2KsoucQrgUSa3YwdqAfN4Be 25sHwSFDuuoJm4+DDCsQsrs35Kg+X7CZl6nsOe60=
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: <20130812211453.89A833845161@drugs.dv.isc.org>
Date: Mon, 12 Aug 2013 15:04:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B5D3829-C490-4A7A-B185-9D072ACCF4F5@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>
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 15:04: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: Mon, 12 Aug 2013 22:06:12 -0000

>> Because, as history has shown, if there isn't a prefix documented as "you
>> should use this for documentation and training only", people tend to copy
>> examples verbatim instead.
> 
> And it causes NO damage unless they decide to exchange routes at
> which time the sites that decide to not generate their own prefix
> have to renumber.  Note that doesn't stop them communicating.  They
> can use GUA.  They can add another ULA in parallel and exchange
> that prefix then remove the other prefix.  This is no different
> than changing PA addresses.

I suppose that depends on your definition of no damage.

In my experience, when someone does something like this and it is easily
identified (thus more likely to be identified early), that is a win.

It's much easier to correct a network addressing error that affects 10s of systems
in one building than one that has become pervasive across thousands of systems
world wide.

If you make the error harder to detect by not having a documentation prefix and
thus having every document choose numbers at random, you greatly reduce the
probability of the problem being detected early.

What harm is there in allocating the additional documentation prefix? Your only
argument seems to be that you don't feel it is necessary in your little corner
of the world.

>> Admittedly, I still run into the occasional internal network numbered out
>> of doc-prefix space in IPv4 because they copied the examples, but I run
>> into a lot more cases where they improperly copied examples that used
>> other prefixes than the documentation prefix.
>> 
>> The point of a documentation prefix is not only to avoid clashing with
>> registry space. It is also so that if you blindly copy examples, this fact
>> is instantly obvious to any network engineer who knows what they are
>> doing and can be more easily identified and corrected (hopefully before
>> it becomes entrenched beyond repair).
> 
> There is no such thing as "entrenched beyound repair" with ULA as there
> is *always* a probability that you will need to renumber when merging
> whether at the company level or just at the routing / address space levels.
> That is something that you accept when you use ULA addresses.

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.

I would consider using double NAT not a repair, but a workaround which
has significant adverse consequences.

Owen