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

Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> Mon, 12 August 2013 19:58 UTC

Return-Path: <carlosm3011@gmail.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 52DBD21F9D7E for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 12:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.083
X-Spam-Level:
X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 LtPpsL8uSEn0 for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 12:58:13 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B90AD21F9D5A for <v6ops@ietf.org>; Mon, 12 Aug 2013 12:58:12 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id eo20so5021355lab.6 for <v6ops@ietf.org>; Mon, 12 Aug 2013 12:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ea6wIOL2JQ4CV/QqaF2Mepc/LKpW/gTdOEid3li8InA=; b=Q1zexgaXEUeHZUjZvEZ/Wrd8+R22b+w2dfyca4W5p2r9/HeWdOxUKz7ZKF/JfxjZE4 NFIzD94Jv6KlN1o5af1cSLVSe8jx5qW/F2bOr/KTIaZH9zOfuDkef5cLEy6E86j9GwMN 813PfZgaKFJg6oM20pB4GKRQhr5HMk8FeP5kso6HHqwtGqaDnP0DxmSbRbJrZZp6i2St C4raVLL57M7idlGDVbNEu2iGW+WdmPL34U8UPvJUO84rI2vvGT7BIQSd6H6wHJYRl/7o sdBqUDYSBuIhu4aHAiyUYbc00waYyI6DIYyjroKhSSvGaAixqWsEi3Pp+perUVwJgoT0 f32g==
MIME-Version: 1.0
X-Received: by 10.112.35.225 with SMTP id l1mr418304lbj.37.1376337491524; Mon, 12 Aug 2013 12:58:11 -0700 (PDT)
Received: by 10.112.168.225 with HTTP; Mon, 12 Aug 2013 12:58:11 -0700 (PDT)
In-Reply-To: <CAOmxzdyxwKDRU=BNFVVerOs-mDnZaqC1bntEc5tW863bemJwVQ@mail.gmail.com>
References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <CAD6AjGQz0A30O7iPovHFcdg_-nErJq936CzZ6C4M3vno1i+MbA@mail.gmail.com> <CAOmxzdyxwKDRU=BNFVVerOs-mDnZaqC1bntEc5tW863bemJwVQ@mail.gmail.com>
Date: Mon, 12 Aug 2013 16:58:11 -0300
Message-ID: <CA+z-_EWnxDdPFnzCh4=CQNuVdMggT9ykoEKLrcRY8ZjVR_c3FQ@mail.gmail.com>
From: Carlos Martinez-Cagnazzo <carlosm3011@gmail.com>
To: Alejandro Acosta <alejandroacostaalamo@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c369424602b104e3c58be9
Cc: Alejandro Acosta <aacosta@rocketmail.com>, IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: carlos@lacnic.net
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 19:58:14 -0000

First, I want to comment that I support the idea behind the draft. I think
there is need for such a larger prefix for training and documentation
purposes.

Now, thinking about where to get that documentation prefix form, I'm
somewhat torn:

- taking it from 2000/3 could either generate less or more confusion,
depending on who you talk to, and would require all operators (well, all
those wise enough to do ingress filtering) to modify acls and perhaps
prefix-lists as well. However, looking in detail at 2000::/3 I found some
weird things that one should probably be filtering out anyways, like
2001:10::/28. So maybe revisiting ingress filters is not such a bad a idea
after all.

- taking it from outside 2000/3 might be a bit harder to explain to newbies
(although I believe it shouldn't be that hard, it might be a good moment to
introduce them to the IANA registry and allocation policies), but would not
require extensive filter reconfiguration. However, it would somehow
'pollute' empty reserved blocks, and I'd hate it to regret this at some
point in the future.

- there might be other choices, like blocks that have been previously used
for other purposes and then deprecated or returned, I'm specifically
looking at:

0200::/7, which is marked as deprecated since 2004. Maybe we can re-use it
again for a purpose with no critical operational consequences ?
3ffee::/16, former 6bone? It's been a while since 6bone was decommissioned.

I found a very interesting bogon entry, within 2000/3 and that people might
be already filtering out: 2002:e000:: /20 (6to4 mapped IPv4 multicast). I'm
not sure about the possible side-effects though.

Overall, I'd be leaning to choosing something outside 2000::/3 but I could
live with a different choice, too.

Thanks Antonio for bringing this up.

regards

~Carlos






On Mon, Aug 12, 2013 at 12:36 AM, Alejandro Acosta <
alejandroacostaalamo@gmail.com> wrote:

> My comments below:
>
> On 8/11/13, cb.list6 <cb.list6@gmail.com> wrote:
> > On Aug 11, 2013 12:24 PM, "Antonio M. Moreiras" <moreiras@nic.br> wrote:
> >>
> >> Hi.
> >>
> >> I would like to ask you to please review and comment the following
> draft:
> >>
> >> http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00
> >>
> >> It intends to ask IANA to reserve another IPv6 prefix for documentation.
> >> Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago.
> >>
> >> The prefix 2001:db8::/32 showed to be very useful. It is widely used.
> >> But we are still facing the same problem that RFC 3849 tried to address:
> >> in some kind of documents, tutorials and didactic laboratories, we have
> >> been using other prefixes, because a /32 isn't enough to represent the
> >> scenario.
> >>
> >> We consider that a /20 would be enough.
> >>
> >> If possible, we would like to ask IANA to reserve something easy to
> >> remember, and self explaining, such as:
> >>
> >> 2D0C::/20
> >>
> >> but *this suggestion is not stated in the document*. This prefix is from
> >> the global unicast space, and 2d00::/8 is currently marked as reserved
> >> by IANA [1], so it would be possible. Anyway, we think it would be
> >> better to discuss the question in the mailing-list.
> >>
> >> Reviewing the archives from when draft-huston-ipv6-documentation-prefix
> >> (that became RFC 3849) was being discussed, both questions (the
> >> necessity of a larger prefix, or multiple prefixes, and the possibility
> >> to reserve something easier to remember and self explaining) were
> >> raised. I am not sure why none of them led to something concrete.
> >> Probably because the draft just intended to document an allocation
> >> already made by APNIC, and maybe it was not so clear then how useful it
> >> would be.
> >>
> >> If you agree in principle with the proposal, other point to discuss is
> >> if this subject is compatible with v6ops. Maybe it should be addressed
> >> in 6man, or other place.
> >>
> >
> > As a network operator i already must block the documentation prefix
> today.
>
> As most of us.
>
> >
> > I see no good reason why i must update all my acls for this new prefix
>
> We tried to explain the reasons in the drafts. So far the
> documentation prefix has been incredible useful at all levels, however
> we know that there are _many_ cases where a /32 for documentation is
> not enough, we mentioned many situations in the draft and I do not
> doubt that there are probably more.
>
> >
> > If your docs require more than /32, use ULA. If you must make another
> > official documentation prefix do not take it from 2000/3
>
> In that case let's obsolete 3849.., sorry just kidding.
>
> >
> > If you take it from 2000/3 you are creating work for network operators
>
> In somehow the authors considered the idea of using 4D0C::/20 instead
> of using 2D0C::/20 however we really want to hear everyone opinions
> here. In this case, using 4D0C nobody need to update the ACLs as you
> mention.
>
> Thanks,
>
> Alejandro,
>
> >
> > CB
> >
> >> Thanks.
> >> Moreiras.
> >>
> >> [1]
> >>
> >
> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
> >>
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
>
>
> --
> =====
> ^A.......o$
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================