Re: 6to4 using ::FFFF:0000:0000/96 (mail.comcast.net AAAA record weirdness)

["Erik Kline" <ekline@ekline.com>]

On 1/27/08, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> On 2008-01-28 10:58, Florian Weimer wrote:
> > * Brian E. Carpenter:
> >
> >>> So, I think it's XP not doing the right thing here... XP should be
> >>> selecting its own v4 stack instead of trying to shove packets to
> >>> ::ffff:0:0/96 down 6to4... correct?
> >> It seems to be a matter of taste which is the default.
> >
> > Uhm, I think for a public anycast gateway (that's what we're talking
> > about, right?), there's no other option than using the v4 stack instead.
> > So the sane default seems clear to me.
>
> I don't know any reason why one couldn't reach a NAT-PT via
> an anycast-addressed 6to4 relay. The point is that we ended
> up overloading the usage of the mapped-IPv4 prefix - not only
> the sin of encoding semantics in the address bits, but also the
> sin of doing so ambiguously. So no default can be "correct".
> Probably local mapping to the IPv4 stack is slightly saner.
>
>     Brian
>
>

These are excellent points -- I hadn't thought about the case of an
IPv6-only client behind a dual-stack 6to4 host trying to reach
(through) a translator.  That seems perfectly legitimate to me.  I
would have to agree, though, that if the packet originates on a
dual-stack host then it should probably have defaulted to using its
own IPv4 stack.

Thanks for the clarification,
-Erik