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

Mark Andrews <marka@isc.org> Mon, 12 August 2013 22:05 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 2763F21F9EB6 for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 15:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level:
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 zdqdRCXvLX-l for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 15:04:57 -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 40BA021F9F5E for <v6ops@ietf.org>; Mon, 12 Aug 2013 15:04:57 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 84A7CC9425; Mon, 12 Aug 2013 22:04:42 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376345096; bh=hlsR1plxlPs91y1r3NuC7oxzogmFoDccXWu8iXfye98=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=g2X8YinkPlwY6yQBASblrU7zt6BjxNy5jnHR+9HFX64HYPX72pQgRgrOFwRss2RxJ AGVsx6Hacv+EdEWkg8DqyGDOhqRhSnFClTVe1GhUXFLrjEDDXJdS5e/yhk3/K/SR2q 4zPx0alTEtEQjARO4Vb1eel3cPcv1LmpU7H9BL2I=
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:04:42 +0000 (UTC) (envelope-from marka@isc.org)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DF11216042F; Mon, 12 Aug 2013 22:09:21 +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 3M7OH6JHTolf; Mon, 12 Aug 2013 22:09:21 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2BEEF160434; Mon, 12 Aug 2013 22:09:21 +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 C406B160431; Mon, 12 Aug 2013 22:09:20 +0000 (UTC)
Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1295538453A1; Tue, 13 Aug 2013 08:04:39 +1000 (EST)
To: Owen DeLong <owen@delong.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>
In-reply-to: Your message of "Mon, 12 Aug 2013 10:00:33 -0700." <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com>
Date: Tue, 13 Aug 2013 08:04:39 +1000
Message-Id: <20130812220439.1295538453A1@drugs.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
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:05:02 -0000

In message <8C0CB3D0-1D03-4A2D-BEF5-166A8BFB9B94@delong.com>om>, Owen DeLong writes:
>
> 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.

Sorry Owen, you need to apply IPv6 think, in particular ULA think
to the problem space which is different to both IPv4 think and
general IPv6 think.

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

Copying a documentation prefix is NOT a error.

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

And I'm sure you will see routes leaked for fc00::/7 as well.  Those
leaks do not in general cause problem for anyone but the leakers
themselves.  The fact that people leak has nothing to do with
documentation prefixes.

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

So a site has already choosen a ULA prefix that happens to match
the soon to be documention prefix.  They have done NOTHING wrong.
It is causing NO operational problem.  By creating a documentation
prefix and telling them it is a poision prefix you have just forced
them to renumber the moment they attempt to connect to anyone.

You are trying to solve a non existent problem.  All you are doing
is saving the occasional site that was too stupid to pick a prefix
for themselves and copied one from some documentation from renumbering
when they connected to another site that was equally stupid and
copied from the same documention examples when ULA doesn't say you
won't have to renumber when you connect and exchange ULA routes.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org