Re: glibc's getaddrinfo() sort order
On Fri, Sep 07, 2007 at 06:54:21PM +1000, Anthony Towns wrote:
> OTOH, getaddrinfo is meant to give a "close" answer, and doing prefix
> matching on NATed addresses isn't the Right Thing. For IPv6, that's fine
> because it's handled by earlier scoping rules. For NATed IPv4 though the
> prefix we should be using is whatever the host is going to be NATed *to*.
> And that would imply that the Right Thing would be to have an option
> more like:
>
> pretend-that 10/8 is-really 1.2.3.4/32
>
> That doesn't seem likely to work though because it requires extra
> manual configuration, which won't happen.
>
> Giving up on actually getting getaddrinfo to give "close" answers for
> NATed boxes leaves the option of trying to avoid getaddrinfo going out
> of its way to give "far" answers instead, which would mean turning off
> prefix-matching for NATed boxes; which could be done by ignoring rule
> 9 by default for private IPv4 addresses.
The problem with IPv4 is not only about NAT. It just happens to show
the problem better.
With the IPv6 allocation policies, it's likely that the more higher bits
match, the closer it is network wise. It is rather unlikly in the IPv4
case, specially if you go above /16.
Kurt
Reply to: