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

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