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

Mark Andrews <marka@isc.org> Mon, 12 August 2013 22:31 UTC

Return-Path: <marka@isc.org>
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 42A5021F9AED for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 15:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.457
X-Spam-Level:
X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[AWL=-1.824, BAYES_00=-2.599, MANGLED_SMALL=2.3, SARE_URI_EQUALS=1.666]
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 livxtaCjU5aq for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 15:30:59 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C05FD21F99CF for <v6ops@ietf.org>; Mon, 12 Aug 2013 15:30:59 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6548DC9494; Mon, 12 Aug 2013 22:30:39 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376346653; bh=dGpSh3kX2e0sSB666HRrMWNqdlYnojQ4WRCt/tPrH8E=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=FgfmQCT4P7fN9JOk1n2eNowBdPC+W8NoQos9mpG/rteA4b5F03xvig9vaC1WrssuV RvcXFTU0CmLJXEHwFVeEnQ6yjtWhTDjexmWxPb7jWfY0cApG49LMrv6Vu5PUy/q0sY /bjRnbRFzkWjBSwQM59kcc5IFRuP8C0mNnnMJSoY=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 12 Aug 2013 22:30:39 +0000 (UTC) (envelope-from marka@isc.org)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D407316042F; Mon, 12 Aug 2013 22:35:18 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id j2gsim-mNO3E; Mon, 12 Aug 2013 22:35:18 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0621C160431; Mon, 12 Aug 2013 22:35:18 +0000 (UTC)
Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 9518016042F; Mon, 12 Aug 2013 22:35:17 +0000 (UTC)
Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id B5F793845539; Tue, 13 Aug 2013 08:30:35 +1000 (EST)
To: Bill Jouris <bill.jouris@insidethestack.com>
From: Mark Andrews <marka@isc.org>
References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <B66D2D0C-DE6D-49CC-A87A-7C65B5360DB4@delong.com> <52082128.5090503@nic.br> <20130812002740.34191383D34B@drugs.dv.isc.org> <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com> <1376330247.41781.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>
In-reply-to: Your message of "Mon, 12 Aug 2013 10:57:27 -0700." <1376330247.41781.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>
Date: Tue, 13 Aug 2013 08:30:35 +1000
Message-Id: <20130812223035.B5F793845539@drugs.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Cc: "v6ops@ietf.org" <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:31:04 -0000

In message <1376330247.41781.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com>om>, Bill Jouris writes:
> --===============0047193473602130639==
> Content-Type: multipart/alternative; boundary="1510626085-1351415829-1376330247=:41781"
> 
> --1510626085-1351415829-1376330247=:41781
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: quoted-printable

Bill replace your MUA with one that DOES printed-quotable CORRECTLY.
This garbage is not correct.
 
> > From: Owen DeLong <owen@delong.com>=0A> To: Mark Andrews <marka@isc.org> =
> =0A> Cc: Alejandro Acosta <aacosta@rocketmail.com>om>; v6ops@ietf.org =0A> Sen=
> t: Monday, August 12, 2013 10:00 AM=0A> Subject: Re: [v6ops] draft-moreiras=
> -v6ops-rfc3849bis-00=0A =0A>=0A>> =0A>> All a documentation prefix will do =
> is have one potentially toxic=0A>> prefix compared to a handful of potentia=
> lly toxic prefixes.=A0 There=0A>> are 1099511627776 prefixes in fd00::/8.=
> =A0 Even if there were thousands=0A>> of documentation prefixes the odds of=
>  you hitting one when generating=0A>> your own prefix are astronomically sm=
> all.=A0 Additionally the more=0A>> prefixes that are used in documentation =
> the less toxic a particular=0A>> prefix will be.=0A=0A> No, it will also he=
> lp to constrain such errors to an easily identifiable single=0A> prefix whi=
> ch will make the errors easier to identify and correct. This is, IMHO,=0A> =
> a worth while goal in the real world where operators actually run networks=
> =0A> and have to deal with less than ideally trained predecessors and colle=
> agues.=0A>=0A> Owen=0A=0AOne other thing: if you have a single documentatio=
> n prefix, you can actually build that knowledge into your firewalls and rou=
> ters -- meaning that anyone who does a copy without change will immediately=
>  find that his addresses simply don't work.=A0 Making that particular error=
>  essentially self-correcting,=0A=0ABill Jouris=0AInside Products, Inc.=0Aww=
> w.insidethestack.com=0A831-659-8360=0A925-855-9512 (direct)=0A

> > From: Owen DeLong <owen@delong.com>
> > To: Mark Andrews <marka@isc.org>
> > Cc: Alejandro Acosta <aacosta@rocketmail.com>om>; v6ops@ietf.org
> > Sent: Monday, August 12, 2013 10:00 AM
> > Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
>
> >
> >>
> >> All a documentation prefix will do is have one potentially toxic
> >> prefix compared to a handful of potentially toxic prefixes.  There
> >> are 1099511627776 prefixes in fd00::/8.  Even if there were thousands
> >> of documentation prefixes the odds of you hitting one when generating
> >> your own prefix are astronomically small.  Additionally the more
> >> prefixes that are used in documentation the less toxic a particular
> >> prefix will be.
>
> > No, it will also help to constrain such errors to an easily
> identifiable single
> > prefix which will make the errors easier to identify and correct. This
> is, IMHO,
> > a worth while goal in the real world where operators actually run
> networks
> > and have to deal with less than ideally trained predecessors and
> colleagues.
> >
> > Owen
>
> One other thing: if you have a single documentation prefix, you can
> actually build that knowledge into your firewalls and routers -- meaning
> that anyone who does a copy without change will immediately find that his
> addresses simply don't work.  Making that particular error essentially
> self-correcting,

For Locally Assigned ULA you default to filtering *all* prefixes.
ULA is not the same as GUA.  You can't just plug sites together
without *first* checking for collisions in ULA space like you can
with GUA.  It is a recipe for disaster if you don't check.

A-B-C-A will work if you just want to talk to your direct neighbors.
If it is a federation you need to get one or both of the A's to
renumber and you also need someone/thing to ensure uniqueness within
the federation.

> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com
> 831-659-8360
> 925-855-9512 (direct)
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org