[Bug libc/4980] gethostbyname() etc break for /etc/hosts with both ::1 and 127.0.0.1 localhost entries

["mokomull at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From mokomull at gmail dot com  2008-07-08 02:04 -------
Created an attachment (id=2816)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2816&action=view)
test case for IN6_IS_ADDR_V4COMPAT

This does not appear to violate any RFCs.

Howard Chu claims that this behavior violates RFC 2553.  First of all,
"IPv4-compatible addresses" have been deprecated by RFC 4291, section 2.5.5.1. 
Even if it had not been, this is an incorrect assumption.  "IPv4-compatible
addresses" would have implied that you could send an IPv6 packet over the wire
addressed to, say ::209.132.176.174, and a router would then encapsulate it in
an IPv4 packet to 209.132.176.174.  This has been superceded by the 6to4
dynamic tunneling scheme, which instead gives each IPv4 address a /48 in
IPv6-space.  But I digress.

What RFC 2553 means by 'IPv6 hex addresses "::" and "::1" MUST NOT be treated
as IPv4-compatible addresses' is that a router may not encapsulate ::1 in an
IPv4 packet to 0.0.0.1.  This behavior does not happen, because a host will
drop packets to ::1 if it did not come through the "lo" loopback interface. 
Even if this were to happen, it would be beyond the scope of libc; it would be
a kernel IP stack issue instead.

As for the macro behavior quoted from RFC 2553, I wrote some test code (see
attachment), and I get:
IN6_IS_ADDR_V4COMPAT( ::1 ) = false
IN6_IS_ADDR_V4COMPAT( :: ) = false

There is nothing in the RFCs that specifies how /etc/hosts should behave, since
that is not something that belongs in a protocol specification.  If glibc
decides to have "::1 localhost" implicitly act as if you had also typed
"127.0.0.1 localhost", then so be it.  None of the function behavior that I
have tested violates what is described in the RFCs.

That is not to say that I don't find this behavior a bit odd.  I would love to
hear from Ulrich what problem this functionality was intended to fix, but I
don't believe that this is in any way a violation of spec.  It's just a bit
different from the way soe people might interpret it.

phelix, this has nothing whatsoever to do with 6to4 tunneling.	6to4 tunneling
describes embedding IPv6 packets within IPv4 packets.  In Linux, that is
handled completely by the kernel, and all applications, including libc, know is
that they are opening an IPv6 socket.  The RFC that you quote is saying that an
IPv6 packet within an IPv4 packet sent to, for example, 127.0.0.1 is invalid.

For the record, I tested this against glibc 2.7 on Ubuntu hardy.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4980

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.