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

["Antonio M. Moreiras" <[e-mail]>]

On 11/08/13 21:36, cb.list6 wrote:

> As a network operator i already must block the documentation prefix today.
> 
> I see no good reason why i must update all my acls for this new prefix
> 
> If your docs require more than /32, use ULA. If you must make another
> official documentation prefix do not take it from 2000/3
> 
> If you take it from 2000/3 you are creating work for network operators
> 
> CB

This is a very good point, thank you for your comment.

I work with IPv6 trainings for network operators, and my team writes a
lot of documentation (regarding these trainings). There are a some
situations where we have to use prefixes shorter than /32. In our
trainings for Autonomous Systems, for example, we need at least a /27 in
order to correctly represent the scenario for the laboratory.

I don't want to use ULA addresses for teaching IPv6, in these trainings,
or to write the examples and documentation. I will try to explain why.

Generally these trainings are the first contact with IPv6 for our
students. Their biggest difficulties generally lies in understanding the
IPv6 addresses. The types of addresses, where to use each of them, the
new format, etc. From a didactic point of view, it would be a very bad
idea to use ULAs and tell them: please don't forget to pretend that this
ULA block is our Global Unicast block, and this other ULA prefix will be
the "real" ULA in our lab. It also would be a bad idea to give them a
/48 and just tell: please, let's pretend that it is a /32, and work in
the address plan for your ISP.

We have a really bad time trying to convince people that private
addresses and NATs are not necessary in all situations. Using ULAs in
the practice, instead of Globals, would not help. I fear that using ULAs
in the labs and examples could lead us to a situation where some
networks would finish having just ULA addresses, and NAT66, in scenarios
where it would not be the better choice.

Maybe we could use addresses outside 2000::/3 for documentation. One of
the other authors was trying to convince me that would be better ask
IANA for something like 4D0C::/20, before this comment.

Personally I think that something outside 2000::/3 is bad for didactic.
I also think that it would just postpone the problem. Probably the
chosen block would be assigned as Global Unicast sometime in the future.
And it would be very strange if the block were assigned to something
other than global. But maybe it would be acceptable.

I can't argue against the point presented. With a new block, there would
be extra work for some networks.

What I can do is to ask how bad it would be?

I would like also to consider that people are already using other
prefixes than 2001:db8::/32 in laboratories, and documentation. Wouldn't
be better to define one new prefix, and have the possibility to update
the filters to prevent operational problems?

Please, let's also consider that the IPv6 deployment in the Internet is
far from reach the majority of the networks. So, for most of them, the
filters are not yet implemented, and there wouldn't be extra work.

Moreiras.