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
