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

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$