On Wed, Dec 08, 2010 at 11:51:37PM +0100, Steinar H. Gunderson wrote:
> Den 8. desember 2010 20:10 skrev William Ahern
> <william_at_25thandclement.com> f??lgende:
> > Some will route an IPv4-mapped address through the IPv4 network.
> This would be correct behavior.
> > Others will route it through the IPv6 network regardless.
> This would be broken behavior. (Mapped addresses are explicitly not
> meant to be sent on the wire.)
> > Still others will just
> > drop them entirely because of security concerns--on OpenBSD IPv4-mapped
> > addresses are rejected immediately inside both bind(2) and connect(2).
> This would be ???OpenBSD just wants to be difficult???. :-)
You get the same behavior on KAME stacks when net.inet6.ip6.v6only is 1,
which is the default value on NetBSD and, I think, FreeBSD. All OpenBSD did
was take away the check in netinet6/in6_pcb.c.
> > So an interface isn't really being helpful in crafting mapped addresses
> > because the application still has to deal with all of the policy regardless.
> You can turn it around; c-ares shouldn't be ignoring to do The Right
> Thing(TM) just because there are broken operating systems out there.
There's a difference between doing the Right Thing with default settings and
shoe-horning policy into an interface lacking the ability to select the
setting or to even know that a response has been manufactured.
Because c-ares is so widely used I think there's a responsibility to get the
interface right just as much as the default policy. A gethostbyname-type
interface is wholly ill-suited for handling IPv6 issues and should probably
be deprecated entirely. Something closer to getaddrinfo which has a hint
structure where PF_INET and PF_INET6 are strictly obeyed, but where
PF_UNSPEC along with additional flags (i.e. mapped_fallback) seems on its
face a decent solution. I'm not convinced, though, that that is _all_ that's
needed, and it's why I haven't altered any of the interfaces in my own dns
library yet. It'd be interesting to hear exactly what people want to do,
including all the corner cases. The problem is that most people just want to
waive away the IPv6 transition problems and not consider what needs to be
done going forward, as opposed to merely making things mostly work for
existing broken software. It's a perennial issue and why the IPv6 transition
has been and will be so painful.
Received on 2010-12-09