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

Mark Andrews <marka@isc.org> Mon, 12 August 2013 03:00 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 87A8121E80B0 for <v6ops@ietfa.amsl.com>; Sun, 11 Aug 2013 20:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Level:
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 IX4xqkstJRmC for <v6ops@ietfa.amsl.com>; Sun, 11 Aug 2013 20:00:23 -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 ACEAC21E805A for <v6ops@ietf.org>; Sun, 11 Aug 2013 19:54:01 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 733FDC9432; Mon, 12 Aug 2013 02:53:46 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1376276039; bh=q9/dQScfS0qEmjT+KHTIWrDkjMXevu7Tvyqm2hQELhU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Zoe6+sxIQy2YEmJ1VIbMYVPcLpanpBjyfLh2CNzWsW+oWU3IbfjbiduPAg7OFbYGb 7bj05wPA4e1AZhwmTGYefMUrixNU91K5Epgd/0L5wRartAtu6lttPxL3n70nPN7sYe +bgmwGqbZLQxzRhwTT7KhCVam8+KhFIMhfBBvOUA=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 12 Aug 2013 02:53:46 +0000 (UTC) (envelope-from marka@isc.org)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 55FD516030C; Mon, 12 Aug 2013 02:58:22 +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 GVFdfqbeSbdc; Mon, 12 Aug 2013 02:58:21 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C96F616042F; Mon, 12 Aug 2013 02:58: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 5FF6716042E; Mon, 12 Aug 2013 02:58:21 +0000 (UTC)
Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id AB2E6383EF22; Mon, 12 Aug 2013 12:53:42 +1000 (EST)
To: "Antonio M. Moreiras" <moreiras@nic.br>
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> <52084137.3000602@nic.br>
In-reply-to: Your message of "Sun, 11 Aug 2013 22:58:15 -0300." <52084137.3000602@nic.br>
Date: Mon, 12 Aug 2013 12:53:42 +1000
Message-Id: <20130812025342.AB2E6383EF22@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 03:00:29 -0000

In message <52084137.3000602@nic.br>br>, "Antonio M. Moreiras" writes:
> On 11/08/13 21:27, Mark Andrews 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.
> > 
> > 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 can agree with you, in parts.
> 
> We should expect that people generate their own ULA prefix, following
> RFC 4193.
> 
> But can we count on that? I think that one of the points in having
> documentation prefixes it's because they can be filtered "in advance" in
> our networks. So if an intern, a trainee, or a newbie just copy the
> configs from a howto document, and manages to put it in our production
> environment, we will be safe.
> 
> So, let's suppose that you write a brilliant book, or howto, about how
> to use ULA addresses in some kind of application for a corporate
> network. Let's suppose that you generate your own ULA for your document.
> Your prefix may be copied and implemented in hundreds, maybe thousands
> of networks.
> 
> It isn't a big problem, because ULA is for private use. But if two of
> these companies merge, or have some kind of private agreement and want
> to connect their networks and make their ULA blocks reachable, it would
> be a problem... Ok, it is a big if.

Then both of the companies had to be stupid and they need to renumber
one or both of the networks as part of the merger.  This is a cost
of being clueless.  Having a reserved prefix does not help with
this sort of cluelessness.  It just makes it worse.

> But, what would be the downside of having an ULA prefix reserved for
> documentation?

Because it actually makes the clueless problem worse.
 
> If the local filters are updated and block this prefix, when a newbie
> try to copy your example and put it to work, it will not work. He will
> realize that he is doing something wrong, and maybe he can learn how he
> can use ULA addresses in the right way.

You should be filtering all of fc00::/7 anyway at the border / bgp
feeds anyway.  When you merge you add exceptions.

Locally assigned ULA are not the same as global addresses.  The do
not have the same security properties as GUA.  You have to assume
that the sites you connect to will have choosen the same prefix as
you have choosen as there is no one co-ordinating things.

> Please let's also remember that the current version of the *draft is not
> asking for an ULA documentation prefix*.
> 
> The draft is asking for a bigger *unicast global* prefix for documentation.
> 
> > 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.
> > 
> > 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.
> > 
> > Mark
> > 
> >> It would be nice to have a specific ULA documentation prefix.
> >>
> >> I would suggest a prefix with the L bit cleared, easy to remember, and
> >> maybe slightly shorter than /48. For example FC00:0:D0C0::/44.
> >>
> >> []s
> >> Moreiras.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org