Yes, always worth reminding people: 2000::/3 is the currently active "Global Unicast" pool ... and that doesn't mean native IPv6
(2002::/16 = 6to4, 2001::/32 = Teredo ... ISATAP may be in play, and not discretely indicated in prefix side of address ... and non-auto tunnels cold be mentioned here as well, using global-scope prefixes ) Back to the topic at hand, and in the subject line, global routing of arbitrary /48s is far from guaranteed. /32 is the default cutoff (routing for /35s probably pretty reliable as well) Up to /48s for Critical Infra / Micro-Allocations and PI-designated blocks ... anything else AFAIK is quite possibly troublesome today. /TJ >-----Original Message----- >From: Michael Sinatra [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 19, 2008 4:16 PM >To: Jack Bates >Cc: nanog list >Subject: Re: IPv6 routing /48s > >On 11/19/08 14:05, Jack Bates wrote: >> Nathan Ward wrote: >>> The problem here is XPSP2/Vista assuming that non-RFC1918 = >>> unfiltered/unNATed for the purposes of 6to4. >>> Well, deeper problem is that they're using 6to4 on an end host I >>> suppose - it's supposed to be used on routers. >>> >> >> While I don't doubt that the 6to4 is broken in such circumstances, how >> many IPv6 content providers are using 6to4 addressing and not 2001:: >> addressing? > >[other references to 2001:: addressing snipped] > >I hope I am not being toooo picky here, and I realize this is not part of >your main point... > >If your reference to 2001:: addressing simply means "non-tunneled, globally >routable IPv6 addressing," then I suppose it is okay. But please note that >there is now a lot of native (non-tunneled), globally routable IPv6 >addressing that is outside of 2001::/16. ARIN, for example, is allocating >blocks out of 2607::/16 and there are quite a large number of prefixes >elsewhere in the designated globally-routable >2000::/3 that are *not* 6to4 addresses. > >The reason I bring this up is that I have already seen certain applications, >such as one for registering AAAA records for DNS servers in a certain TLD, >that don't allow anything other than 2001::/16. >(Fortunately that application was fixed quickly when those responsible were >notified.) Just making sure others aren't careening toward making the same >mistake. > >michael