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

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

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

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.