How does it work? When software supports both IPv4 and IPv6, I see
only a tcp6-line? I'm totally surprised here. Thank you for any
information on this.
How does it work? When software supports both IPv4 and IPv6, I see
only a tcp6-line? I'm totally surprised here. Thank you for any
information on this.
I have a program (whose source code I don't know) listening on TCP port
8547. I connect to it by using an IPv4 address. When I look at
netstat's output, I can't see the ``tcp'' line relative to port 8547. I
see the following type of output:
%netstat -na | grep LISTEN
[...]
tcp 0 0 0.0.0.0:1234 0.0.0.0:* LISTEN [...]
tcp6 0 0 :::8547 :::* LISTEN [...]
Because I can connect to it by specifying the machine's IPv4 address, I expected to see a ``tcp'' line with the port 8547 on it. Instead, I see
a ``tcp6'' line, so that surprised me.
The IPv6 address space contains all of the IPv4 address space in form of so-called IPv6-mapped-IPv4 addresses: An IPv6 address of the form
::ffff:aabb:ccdd
is equivalent to the IPv4 address
aa.bb.cc.dd
and the usual textual notation for these addresses is actually
:ffff:aa.bb.cc.dd
Transparent support for this feature enables programs using IPv4 to
talk to other program with no explicit support for IPv4.
Rainer Weikusat <rweikusat@talktalk.net> writes:^^
[...]
The IPv6 address space contains all of the IPv4 address space in form of
so-called IPv6-mapped-IPv4 addresses: An IPv6 address of the form
::ffff:aabb:ccdd
is equivalent to the IPv4 address
aa.bb.cc.dd
Right, except that IPv6 addresses are normally written in hex and
IPv4 addresses in decimal, so for example
::ffff:904c:23fc
would be equivalent to
144.76.35.252
(I picked the IP address of my Usenet server)
and the usual textual notation for these addresses is actually
:ffff:aa.bb.cc.dd
Wikipedia says it starts with "::ffff", not ":ffff".
Boris Dorestand <bdorestand@example.com> writes:
How does it work? When software supports both IPv4 and IPv6, I see
only a tcp6-line? I'm totally surprised here. Thank you for any
information on this.
See IPV6_V6ONLY in https://man7.org/linux/man-pages/man7/ipv6.7.html
On 1/30/21 5:02 AM, Boris Dorestand wrote:
How does it work? When software supports both IPv4 and IPv6, I see
only a tcp6-line? I'm totally surprised here. Thank you for any
information on this.
This is an oddity of IPv6 support. It's possible, though I don't know
under what conditions, for an IPv6 socket to support IPv4 clients.
This was designed on purpose to make it easy to migrate programs to
support IPv6.
IMHO this is the expected behavior.
So I guess this server on port 8547 is setting IPV6_V6ONLY to zero and
so it is listening on both IPv4 and IPv6? My question is why doesn't
netstat actually report both IPv4 and IPv6? It only reports ``tcp6''.
%netstat -na | grep LISTEN | grep 8547
tcp6 0 0 :::8547 :::* LISTEN
%
Thank you so much for the documentation reference.
Thank you. I read your answer as saying that if the program writer
set IPV6_V6ONLY (https://man7.org/linux/man-pages/man7/ipv6.7.html)
to zero, then the socket binds to both IPv4 and IPv6 and netstat only
reports the tcp6-line. (See my follow-up (<86ft2f1ziv.fsf@example.com>)
to Richard Kettlewell.) If that's correct, okay, that answers my
question.
Thanks to all other thread participants too. I read all posts and
appreciate all comments.
Grant Taylor <gtaylor@tnetconsulting.net> writes:
On 1/30/21 5:02 AM, Boris Dorestand wrote:
How does it work? When software supports both IPv4 and IPv6, I see
only a tcp6-line? I'm totally surprised here. Thank you for any
information on this.
This is an oddity of IPv6 support. It's possible, though I don't know
under what conditions, for an IPv6 socket to support IPv4 clients.
This was designed on purpose to make it easy to migrate programs to
support IPv6.
IMHO this is the expected behavior.
Thank you. I read your answer as saying that if the program writer set IPV6_V6ONLY (https://man7.org/linux/man-pages/man7/ipv6.7.html) to zero,
then the socket binds to both IPv4 and IPv6 and netstat only reports the tcp6-line.
Boris Dorestand <bdorestand@example.com> writes:
Grant Taylor <gtaylor@tnetconsulting.net> writes:
On 1/30/21 5:02 AM, Boris Dorestand wrote:
How does it work? When software supports both IPv4 and IPv6, I see
only a tcp6-line? I'm totally surprised here. Thank you for any
information on this.
This is an oddity of IPv6 support. It's possible, though I don't know
under what conditions, for an IPv6 socket to support IPv4 clients.
This was designed on purpose to make it easy to migrate programs to
support IPv6.
IMHO this is the expected behavior.
Thank you. I read your answer as saying that if the program writer set
IPV6_V6ONLY (https://man7.org/linux/man-pages/man7/ipv6.7.html) to zero,
then the socket binds to both IPv4 and IPv6 and netstat only reports the
tcp6-line.
That's not quite correct: Sockets don't "bind to protocols" but they
will be bound (either automatically or by calling bind) to protocol addresses. Both IPv4 and IPv6 share the same "port namespace". If a
TCPv4 segment destined to a certain port arrives and there's only an
IPv6 socket using this port, the kernel will forward the segment to it
and the IPv4 source address will appear as IPv6-mapped-IPv4 address to
the application.
Conceptually, there's a sort of automatic network address translation happening here: An IPv4 datagram from 1.2.3.4 sent to 4.3.2.1 will
appear at the application level as IPv6 datagram from ::ffff:0102:0304
to ::ffff:0403:0201 and a reply from the application conceptually from ::ffff:0403:0201 to ::ffff:0102:0304 will cause an IPv4 datagram from
4.3.2.1 to be sent to 1.2.3.4.
There's is only one socket.
Thanks for the correction. I see. They share the same port namespace.
So I guess I can also say that IPv6 generalizes IPv4. It seems
that this solves some of the so-called ``IPv6 mess'' that Daniel
J. Bernstein talked about some years ago:
https://cr.yp.to/djbdns/ipv6mess.html
Does it not? I mean, there's a backward compatibility now. A software writer can now worry about IPv6 and still support IPv4. If that's so,
who's responsible for this solution? Kernel writers?
Rainer Weikusat <rweikusat@talktalk.net> writes:
Boris Dorestand <bdorestand@example.com> writes:
Grant Taylor <gtaylor@tnetconsulting.net> writes:
On 1/30/21 5:02 AM, Boris Dorestand wrote:
How does it work? When software supports both IPv4 and IPv6, I see
only a tcp6-line? I'm totally surprised here. Thank you for any
information on this.
This is an oddity of IPv6 support. It's possible, though I don't know >>>> under what conditions, for an IPv6 socket to support IPv4 clients.
This was designed on purpose to make it easy to migrate programs to
support IPv6.
IMHO this is the expected behavior.
Thank you. I read your answer as saying that if the program writer set
IPV6_V6ONLY (https://man7.org/linux/man-pages/man7/ipv6.7.html) to zero, >>> then the socket binds to both IPv4 and IPv6 and netstat only reports the >>> tcp6-line.
That's not quite correct: Sockets don't "bind to protocols" but they
will be bound (either automatically or by calling bind) to protocol
addresses. Both IPv4 and IPv6 share the same "port namespace". If a
TCPv4 segment destined to a certain port arrives and there's only an
IPv6 socket using this port, the kernel will forward the segment to it
and the IPv4 source address will appear as IPv6-mapped-IPv4 address to
the application.
Conceptually, there's a sort of automatic network address translation
happening here: An IPv4 datagram from 1.2.3.4 sent to 4.3.2.1 will
appear at the application level as IPv6 datagram from ::ffff:0102:0304
to ::ffff:0403:0201 and a reply from the application conceptually from
::ffff:0403:0201 to ::ffff:0102:0304 will cause an IPv4 datagram from
4.3.2.1 to be sent to 1.2.3.4.
There's is only one socket.
Thanks for the correction. I see. They share the same port namespace.
So I guess I can also say that IPv6 generalizes IPv4. It seems that
this solves some of the so-called ``IPv6 mess'' that Daniel J. Bernstein talked about some years ago:
https://cr.yp.to/djbdns/ipv6mess.html
Does it not? I mean, there's a backward compatibility now. A software writer can now worry about IPv6 and still support IPv4.
If that's so, who's responsible for this solution? Kernel writers?
Rainer Weikusat <rweikusat@talktalk.net> writes:
That's not quite correct: Sockets don't "bind to protocols" but they
will be bound (either automatically or by calling bind) to protocol
addresses. Both IPv4 and IPv6 share the same "port namespace". If a
TCPv4 segment destined to a certain port arrives and there's only an
IPv6 socket using this port, the kernel will forward the segment to it
and the IPv4 source address will appear as IPv6-mapped-IPv4 address to
the application.
It seems that this solves some of the so-called ``IPv6 mess'' that
Daniel J. Bernstein talked about some years ago:
https://cr.yp.to/djbdns/ipv6mess.html
Does it not?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 90:35:44 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,565 |