Discussion:
ipv6_addr_type() and mapped IPv4 loopback
Chuck Lever
2008-11-03 23:01:48 UTC
Permalink
The __ipv6_addr_type() function does not recognize the mapped IPv4
loopback address:

::ffff:7f00:0001

as type IPV6_ADDR_LOOPBACK. Is this intentional?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Brian Haley
2008-11-04 02:33:04 UTC
Permalink
Post by Chuck Lever
The __ipv6_addr_type() function does not recognize the mapped IPv4
::ffff:7f00:0001
as type IPV6_ADDR_LOOPBACK. Is this intentional?
I would think that since the IPv6 loopback address is ::1, and
ipv4-mapped is ::ffff:* that this would be IPV6_ADDR_MAPPED. That's
what RFC 4291 seems to say.

-Brian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chuck Lever
2008-11-04 16:44:59 UTC
Permalink
Hi Brian-
Post by Chuck Lever
The __ipv6_addr_type() function does not recognize the mapped IPv4
::ffff:7f00:0001
as type IPV6_ADDR_LOOPBACK. Is this intentional?
I would think that since the IPv6 loopback address is ::1, and ipv4-
mapped is ::ffff:* that this would be IPV6_ADDR_MAPPED. That's what
RFC 4291 seems to say.
So the answer to my original question is then "yes, this is
intentional," correct?

On a system with an AF_INET6 listener, legacy applications use
127.0.0.1 to contact a local listener. The incoming source address
will be ::ffff:7f00:0001, not ::1. This means IPv6-enabled
applications have to perform a separate check for ::ffff:7f00:0001 if
they are looking for loopback addresses.

The kernel's lockd must verify that an NLM request comes from the
local user space. It's not a lot of extra logic, but it is a subtlety.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Stevens
2008-11-04 20:19:15 UTC
Permalink
There is actually a difference.

The mapped-v4 loopback address uses IPv4 for packet
delivery while the IPv6 loopback uses IPv6. So, theoretically,
an application using a protocol-specific feature would need
to distinguish between the two.

I don't think it's a good idea to remap those to ::1.

+-DLS

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Brian Haley
2008-11-04 21:16:48 UTC
Permalink
Post by Chuck Lever
Hi Brian-
Post by Brian Haley
Post by Chuck Lever
The __ipv6_addr_type() function does not recognize the mapped IPv4
::ffff:7f00:0001
as type IPV6_ADDR_LOOPBACK. Is this intentional?
I would think that since the IPv6 loopback address is ::1, and
ipv4-mapped is ::ffff:* that this would be IPV6_ADDR_MAPPED. That's
what RFC 4291 seems to say.
So the answer to my original question is then "yes, this is
intentional," correct?
I didn't design the Linux IPv6 stack, but it looks right to me.
Post by Chuck Lever
On a system with an AF_INET6 listener, legacy applications use 127.0.0.1
to contact a local listener. The incoming source address will be
::ffff:7f00:0001, not ::1. This means IPv6-enabled applications have to
perform a separate check for ::ffff:7f00:0001 if they are looking for
loopback addresses.
Right, applications have to see if it's really an IPv4 address if
necessary. If you're just looking for loopback and it's in the kernel,
it's only about this much code:

if (ipv6_addr_type(addr->sin6_addr) == IPV6_ADDR_MAPPED) {
__be32 v4addr = addr->sin6_addr.s6_addr32[3];
if (ipv4_is_loopback(v4addr)) {
/* it's 127.0.0.* */
}
}

There's the IN6_IS_ADDR_V4MAPPED() macro for user-space as well.
Post by Chuck Lever
The kernel's lockd must verify that an NLM request comes from the local
user space. It's not a lot of extra logic, but it is a subtlety.
Agreed.

-Brian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chuck Lever
2008-11-04 21:33:47 UTC
Permalink
Hi Brian-
Post by Brian Haley
Post by Chuck Lever
Hi Brian-
Post by Brian Haley
Post by Chuck Lever
The __ipv6_addr_type() function does not recognize the mapped
::ffff:7f00:0001
as type IPV6_ADDR_LOOPBACK. Is this intentional?
I would think that since the IPv6 loopback address is ::1, and
ipv4-mapped is ::ffff:* that this would be IPV6_ADDR_MAPPED.
That's what RFC 4291 seems to say.
So the answer to my original question is then "yes, this is
intentional," correct?
I didn't design the Linux IPv6 stack, but it looks right to me.
Post by Chuck Lever
On a system with an AF_INET6 listener, legacy applications use
127.0.0.1 to contact a local listener. The incoming source address
will be ::ffff:7f00:0001, not ::1. This means IPv6-enabled
applications have to perform a separate check for ::ffff:7f00:0001
if they are looking for loopback addresses.
Right, applications have to see if it's really an IPv4 address if
necessary. If you're just looking for loopback and it's in the
if (ipv6_addr_type(addr->sin6_addr) == IPV6_ADDR_MAPPED) {
__be32 v4addr = addr->sin6_addr.s6_addr32[3];
if (ipv4_is_loopback(v4addr)) {
/* it's 127.0.0.* */
}
}
There's the IN6_IS_ADDR_V4MAPPED() macro for user-space as well.
Thanks for the steer. I'll submit this fix for 2.6.29. I'm hoping to
introduce AF_INET6-based kernel RPC services (namely NFSD and lockd)
in that release.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...