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

Owen DeLong <owen@delong.com> Mon, 12 August 2013 17:17 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 AD04521F9BAB for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 10:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level:
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 Ik0b67u8NMw1 for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 10:17:38 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 70EFC21F944C for <v6ops@ietf.org>; Mon, 12 Aug 2013 10:06:02 -0700 (PDT)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r7CH0Vru012281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 10:00:31 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r7CH0Vru012281
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1376326832; bh=Gcu+TftE7zBx9nydV4TqmPL7LGU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=deLNoYr2GM2edi1+m7+qetuWlIoDQsMKm+dyG2uFxaxykzg8C7eDzcr4nKGEcuKPR urOjL6uSZ/ddvxQN+GnHCu+LBGp1tXQEV33wJHRKUe7SN0Q26tYLntYFGmUMFHq2ER hZv+lrYXNaSTnGf17PjEtAjBfvpB5Q9EEPFKCx2E=
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: <20130812002740.34191383D34B@drugs.dv.isc.org>
Date: Mon, 12 Aug 2013 10:00:33 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com>
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>
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 [IPv6:2620:0:930::200:2]); Mon, 12 Aug 2013 10:00:32 -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 17:17:39 -0000

On Aug 11, 2013, at 17:27 , Mark Andrews <marka@isc.org> wrote:

> 
> In message <52082128.5090503@nic.br>br>, "Antonio M. Moreiras" writes:
>> On 11/08/13 19:29, Owen DeLong wrote:
>>> I support the idea. It might be worth also asking for a ULA Doc slice at th
>> e same time.
>>> I think a /48 is probably sufficient for most ULA examples.
>>> 
>>> But I think it would be good to be able to write up ULA examples and traini
>> ng that use
>>> actual ULA prefixes intended for documentation.
>> 
>> I agree. An organization could generate an ULA prefix specifically to
>> use in a course, or document. But it could be copied and used in
>> production environments. This would break the "global uniqueness", and
>> could lead to other problems.
> 
> FUD.
> 

Is FUD actually FUD when there is proof that it has happened before?

> You either do the correct thing and generate your own prefix or you
> don't and copy one and hope that no one else has copied it that you
> are connecting to.  Having a reserved prefix will not help you here.

I disagree. See my previous message. It has helped in IPv4 and I see
no reason it would not help in IPv6.

It may not do much to prevent mistakes, but it makes them much easier
to identify and resolve.

> ULA are not "globally unique", they are locally unique with a
> extrememly low probability of collision when *locally* connecting.
> If you use them in a global context (i.e. publish to the world in
> AAAA records) without some global differentiator you will cause
> problems.

Q.E.D.:
route-views>sh ip bgp 10.0.0.0/8 longer-prefixes 
BGP table version is 297146110, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.30.10.0/24    217.75.96.60             0             0 16150 31027 35376 i
route-views>sh ip bgp 172.12.0.0/12 long
route-views>sh ip bgp 172.12.0.0/12 longer-prefixes 
BGP table version is 297170440, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  172.0.0.0/12     154.11.11.113            0             0 852 2914 7018 i
*                   208.74.64.40                           0 19214 174 7018 i
*                   4.69.184.193             0             0 3356 7018 i
*                   194.85.102.33                          0 3277 3267 3356 7018 i
*                   154.11.98.225            0             0 852 2914 7018 i
*                   207.172.6.20             0             0 6079 3356 7018 i
*                   193.0.0.56                             0 3333 3356 7018 i
*                   69.31.111.244            3             0 4436 2914 7018 i
*                   66.59.190.221                          0 6539 577 7018 i
*                   194.85.40.15                           0 3267 3356 7018 i
*                   209.124.176.223                        0 101 101 7018 i
*                   128.223.253.10                         0 3582 3701 3356 7018 i
*                   207.172.6.1              0             0 6079 3356 7018 i
*                   134.222.87.1                           0 286 7018 i
*                   157.130.10.233                         0 701 7018 i
*                   66.185.128.48            7             0 1668 7018 i
*                   202.249.2.86                           0 7500 2497 7018 i
*                   216.218.252.164                        0 6939 1299 7018 i
*                   114.31.199.1             0             0 4826 6939 1299 7018 i
*                   144.228.241.130                        0 1239 7018 i
*                   208.51.134.254           0             0 3549 7018 i
*                   207.46.32.34                           0 8075 7018 i
*                   129.250.0.11             7             0 2914 7018 i
*                   217.75.96.60             0             0 16150 1299 7018 i
*                   202.232.0.2                            0 2497 7018 i
*                   89.149.178.10           10             0 3257 7018 i
*                   66.110.0.86                            0 6453 7018 i
*                   203.62.252.186                         0 1221 4637 3561 7018 i
*                   203.181.248.168                        0 7660 2516 3356 7018 i
*                   164.128.32.11                          0 3303 3320 7018 i
*                   206.24.210.102                         0 3561 7018 i
*>                  12.0.1.63                              0 7018 i
route-views>sh ip bgp 192.168.0.0/16 lon
route-views>sh ip bgp 192.168.0.0/16 longer-prefixes 

route-views>


> 
> 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