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

["George, Wes" <[e-mail]>]

> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Antonio M. Moreiras
> Sent: Monday, August 12, 2013 6:12 PM
>
> (repeating myself) Generally our IPv6 trainings are the first contact
> with IPv6 for some network guys. Their biggest difficulties generally
> lies in understanding the IPv6 addresses. The types of addresses, where
> to use each of them, the new format, etc.
[WEG] What I think you're saying above is that new folks are intimidated by IPv6 (the hex, the colons, etc). The best way to get past that is probably to keep reiterating the aphorism "96 more bits, no magic" in order to build on their familiarity with IPv4, rather than being overly concerned about the type of addresses used in different parts of training labs. A basic familiarity with IPv6 is going to be more important than being able to recognize different types of IPv6 addresses on sight.
That said, I do understand the value in being consistent on the types of addresses used in documentation based on their purpose within the documentation in order to lessen confusion.

>From a didactic point of view,
> it would be a 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. Something looking more
> like GUAs would be better. The prefix 2001:db8::/32 do represent GUAs in
> documentation.
[WEG] Here's the problem I have with this argument: Every training class I've ever attended was either using RFC1918 space, or taking advantage of the fact that they essentially had the entirety of IPv4 space at their disposal because this wasn't connected to the internet (e.g. pod 1 was 10.x/8, pod 2 was 20.x/8, pod 3 was 30.x/8 etc.) and same with ASNs (using AS100, 200, 300 instead of RFC5398 ASNs). Somehow most of us survived this and were able to apply what we learned to real networks.
>
> It is difficult to convince people that private addresses and NATs are
> not to be used in all situations. Using ULAs in the labs, instead of
> Globals, would not help.
[WEG] That is a matter of educating them on *why* you've chosen to use ULA in the lab - i.e. because it's not connected to the global internet, etc. It gives you an opportunity to reiterate exactly why they *shouldn't* do that for an internet-connected deployment.

 I fear that using ULAs would result in people
> used to see them in the wrong places, and 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.
[WEG] I don't think that the choice of IP block during a training is going to have a material impact on this. People are either going to make an educated design decision based on their needs, guidance, and best common practice, or they're going to do what they're going to do in spite of guidance to the contrary. Hanging the justification for a larger/additional block of documentation prefixes on concerns over enabling people to do stupid things with NAT on IPv6 based on what they saw in a lab conflates two issues in a way that's not helpful. Let's stick to discussing the merits of the need for a larger block of IPv6 addresses for documentation. Right now, your draft isn't nearly specific enough about the scenarios where something larger than a /32 is required, nor how you arrived at a /20 as the recommended size.

>
> I would prefer to choose an arbitrary prefix, inside or outside
> 2000::/3, but that "looks like" a GUA, than use ULAs in the classes.
[WEG] Might I suggest repurposing all or part of 0200::/7? (RFC4048). Even if we don't officially allocate it as additional documentation space, that seems a safe squat point for things like training, likely to already be filtered by SPs as bogon space, etc.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.