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

[Owen DeLong <[e-mail]>]

On Aug 13, 2013, at 09:38 , "George, Wes" <[e-mail]> wrote:

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

Wes,

I don't know how much ab initio IPv6 training you do.

What you are describing is part of it, but not the whole issue.

Antonio and I have taught quite a few classes by now. We repeatedly see students struggling with the idea of how the different types of IPv6 addresses are determined, what exactly they mean and how the pieces fit together.

It's hard enough for them to understand the difference between ULA, GUA, multicast, Link Local, etc.

Having them pretend one ULA prefix is GUA while the other one is representing ULA makes it much more confusing for them.

While the issue you describe (96 more bits, no magic) is a prevalent one, it really isn't the only one and isn't the one this proposal seeks to address.

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

My training classes (I don't know the details of Antonio's) are actually connected to the internet. Yes, we use RFC-1918 IPv4 space and they are NATed for IPv4. However, the IPv6 GUA that I use for the actual student routers is part of a GUA prefix (we use a /48 for the class and divide it up into smaller prefixes for the lab).  However, the training materials are written using the doc prefix (or a variant of it).

The lab gets a real BGP feed and is really on the IPv6 internet. When the students reach the later exercises in the lab, they're working with real IPv6 applications over a routed infrastructure that they built using OSPF3 and BGP/IPv6. My training lab consists of 16 routers comprising 4 autonomous systems with 4 routers each and a synthetic internet exchange point. Each ASN is linked IXP->R4->R3->R1->R2->(R2a) where (R2a) represents a private peering with the adjacent AS R2. (AS65501<->AS65502 and AS65503<->AS65504).

There's a 17th router which acts as a classroom gateway and provides wifi so that the students can ssh in with their laptops. It does the IPv6 tunnel termination and the BGP session with the upstream routers. It's connected to the IXP and it provides transit to all of the student ASNs.

The entire lab is portable in a laser cut acrylic case that fits (with my clothes) in a roll-aboard carry-on bag.

For example, when I talk about how to deal with a larger environment, I show an example of carving up a /28 and we pretend that 2001:db80::/28 is the doc prefix for that purpose. It would be much better to have an actual shorter doc prefix to use instead of having to pervert the existing one.

After all, at some point, 2001:db80::/28 (or longer) may belong to someone.

>> 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 don't disagre, but as long as we have ULA, the only hope of avoiding having it misused with things like NPT is good education. Having a ULA doc prefix for that purpose can and will be helpful. Having a shorter GUA prefix can and will be very helpful.

> 
> 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 think (and this is likely my fault) that we're conflating two requests here.

The original proposal for a larger doc prefix is all about being able to write books and training scenarios that use a doc prefix and talk about carving up larger chunks of address space. For ab initio training, trying to teach students that these ULA examples are not really applicable to ULA, but should be used with GUA is very confusing and it really does break their brains. Allocating a larger doc prefix would help with this scenario a lot.

Secondarily, I mentioned that while we were considering an additional doc prefix, it might make sense to also look at allocating a third doc prefix for creating ULA examples. I think this should come from the fc00::/8 space which is currently unusable  anyway, and which would allow examples describing the use of (and reasons not to use) ULA with a prefix that would be easily identified if the examples were erroneously copied into the real world.

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

Works for me.

I would suggest 0200:2000::/20 to fit with the other requestors' desire for a /20. For my needs, even 0200:2200::/24 would be adequate.

Owen