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

Alejandro,

I like that. From a teacher's PoV it would probably very illustrative to
have this proposed /20 or /24 but _made up from non-contiguous prefixes_.
In the end the goal is to provide each 'team' with a dedicated /32, but if
the blocks that these /32s come from are quite different, well, it would
look a lot like the 'real' Internet.

I can't speak from anyone, but if 4 more blocks like 2001:dbX/29 could be
obtained, I think we've mostly solved the problem, in a better way than
originally envisioned. The problem of operators having to revisit their
prefix lists / ingress ACLs remains, though.

Just a thought.

~Carlos

On Mon, Aug 19, 2013 at 3:52 PM, Alejandro Acosta <
alejandroacostaalamo@gmail.com> wrote:

> Hi,
>   That is a good option.
>   Another posibility is to tale another RIR similar space and to use
> something like 2800:db8::/nn
>
> Thanks,
>
>
> -----Mensaje original-----
> De: Fred Baker (fred)
> Enviados:  08/19/2013 1:08:24 PM
> Asunto:  Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
>
>
> On Aug 19, 2013, at 5:34 AM, Gert Doering <gert@space.net> 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#IPv6Allocationnotes 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 internet-drafts@ietf.orgthat 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================