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

["Fred Baker (fred)" <[e-mail]>]

</chair>

On Aug 21, 2013, at 6:33 AM, "George, Wes" <[e-mail]>
 wrote:

> The main problem with extending 2001:db8::/32 to a /29, or allocating 2xxx:db8::/xx is that it requires everyone to make changes to their Martian routing and packet filters, unlike pulling something from outside of 2000::/3. I don't view that as "less expensive", at least operationally.


> Also, if we're talking about your heartburn with a fairly large requested prefix (e.g. a /20 or /27 or whatever), that lends support to the idea of reusing space that otherwise is likely to become the IPv6 version of IPv4 Class E space (e.g. 6bone space, or 0200::) - formerly reserved, now reclaimable, but unusable as "normal" space on account of currently existing filters (and probably some dumb implementation hardcoding of "invalid" space).

Well, that is how we came up with 10.0.0.0/8; that was the ARPANET's allocation. He could include that in the IANA section of the 6man draft as another alternative, and come to that conclusion in 6man.

Understand my heartburn, please. To my mind, there are two arguments for IPv6 deployment: more addresses, and operational simplicity. When Axel Clauberg talks about his Terastream architecture, he shows an interesting slide in which he identifies the set of technologies in use in his network and which he has to manage, and he observes that there is nothing in it that can't be replaced by one of four protocol technologies - IPv6, optical communications, a management architecture (for which he selects NetConf), and an overlay architecture (for which he selects L2TPv3/IPv6). He figures he is saving operational expense by converting his network to exactly that set of technologies. When I talk about heartburn, I'm talking about things that chew up address space unnecessarily (the difference between "need" and "want") or which add complexity - of which the random filters you comment on are an example.

> Thanks,
> 
> Wes
> 
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Owen DeLong
>> Sent: Monday, August 19, 2013 1:52 PM
>> To: Fred Baker (fred)
>> Cc: Alejandro Acosta; [e-mail]; [e-mail] WG
>> Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
>> 
>> I think all of Fred's recommendations below are spot on. I support the
>> changes and I like the idea of 2001:db0::/28.
>> 
>> In such a case, should we stick with fc00:db8::/44 or should we consider
>> fc00:db0::/28 for parity? I'm OK either way, just looking to minimize
>> potential confusion and wondering if the tradeoff in space is worth
>> while or not. What do others think?
>> 
>> Owen
>> 
>> On Aug 19, 2013, at 10:38 , "Fred Baker (fred)" <[e-mail]> wrote:
>> 
>>> 
>>> On Aug 19, 2013, at 5:34 AM, Gert Doering <[e-mail]> wrote:
>>> 
>>>> 2001:db8 came from APNIC, that's why :-) - their delegated file lists
>>>> 
>>>> apnic|AU|ipv6|2001:db0::|32|20031112|allocated
>>>> apnic|AU|ipv6|2001:dc0::|32|20030124|assigned
>>>> 
>>>> so an extention to /29 would technically be possible, to a /28 won't.
>>> 
>>> Hmm. Tell me about 2001:da0:: and 2001:d80::? Per
>> ftp://ftp.apnic.net/public/stats/apnic/delegated-apnic-ipv6-assigned-
>> latest
>>> 
>>>> apnic|AU|ipv6|2001:7fa:b::|48|20050922
>>>> apnic|AU|ipv6|2001:7fa:c::|48|20050922
>>>> apnic|AU|ipv6|2001:7fa:d::|48|20050922
>>>> apnic|AU|ipv6|2001:7fa:e::|48|20050922
>>>> apnic|ID|ipv6|2001:7fa:f::|48|20050929
>>>> apnic|CN|ipv6|2001:7fa:10::|48|20060531
>>>> apnic|AU|ipv6|2001:7fa:11::|48|20061031
>>>> apnic|AU|ipv6|2001:dc0::|32|20030124
>>>> apnic|TW|ipv6|2001:dc1::|32|20030331
>>>> apnic|JP|ipv6|2001:dc2::|32|20030529
>>>> apnic|JP|ipv6|2001:dc3::|32|20030619
>>> 
>>> 
>>> To my small mind, that suggests 2001:d80::/26 (64 prefixes),
>> 2001:da0::/27 (32), 2001:db0::/28 (16), or 2001:db8::/29 (8). Shorter
>> than /26 includes 2001:dc0:: and 2001:de0::, which have been allocated.
>> The neighborhood, however, includes 2001:db8::, which we already use. I,
>> for one, would like to see one documentation range, at least for the
>> global unicast address space, which is to say a prefix shorter than and
>> including 2001:db8::/32.
>>> 
>>> http://www.apnic.net/publications/research-and-insights/ip-address-
>> trends/apnic-resource-range#IPv6Allocation notes that 2001:DB8::/29 is
>> reserved and by definition available.
>>> 
>>> I note that we are not discussing the recommendation per se; we are
>> narrowing in on the length of the prefix. Unless someone disagrees, I
>> think we have pretty much agreed that something shorter than /32 makes
>> sense.
>>> 
>>> Here's my suggestion. The 6man chairs tell me that RFC 3489 was their
>> work group product, so it's replacement should be. I'd suggest
>> respinning the draft as draft-moreiras-6man-rfc3849bis (and tell
>> [e-mail] that it replaces this one). You want to do two
>> separate things:
>>> 
>>> a) argue for a shorter prefix in 2000::/3, and make a separate-but-
>> analogous argument for a prefix in fc00::/8.
>>> In those, focus on need, not want. "We designed a lab that has 2^128
>> different addresses in it, we obviously need the entire IPv6 address
>> space" doesn't follow. Say what you *need* and why you *need* it. While
>> the request was for a /20, I have not heard a cogent argument for a /26
>> or shorter, I heard that there was a training lab somewhere that
>> required a /27 (32 /32s) but have not heard that the intent of the lab
>> could not have been done with 16 /32s, and observe that a nibble
>> boundary would suggest a /28 (16 /32s).
>>> 
>>> b) in the IANA considerations section, note:
>>> b.1) the availability of 2001:d80::/26, 2001:da0::/27, 2001:db0::/28,
>> or 2001:db8::/29
>>> b.2) the suggestion of fc00:db8:?::/44, which I think we more or less
>> agreed to in the thread
>>> b.3) the fact that this would also affect
>> http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-
>> special-registry.xhtml#iana-ipv6-special-registry-1
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 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.

	• Make things as simple as possible, but not simpler.
Albert Einstein