• on netstat's ``tcp'' and ``tcp6''

    From Boris Dorestand@21:1/5 to All on Sat Jan 30 09:02:17 2021
    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:

    --8<---------------cut here---------------start------------->8---
    %netstat -na | grep LISTEN
    [...]
    tcp 0 0 0.0.0.0:1234 0.0.0.0:* LISTEN [...]
    tcp6 0 0 :::8547 :::* LISTEN [...]
    --8<---------------cut here---------------end--------------->8---

    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. To prove that there is no
    8547-line that's not a tcp6-line, let me show you this:

    --8<---------------cut here---------------start------------->8---
    %netstat -na | grep LISTEN | grep 8547
    tcp6 0 0 :::8547 :::* LISTEN
    %
    --8<---------------cut here---------------end--------------->8---

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Boris Dorestand on Sat Jan 30 17:32:55 2021
    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

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Boris Dorestand on Sat Jan 30 19:02:47 2021
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Boris Dorestand on Sun Jan 31 23:07:46 2021
    Boris Dorestand <bdorestand@example.com> writes:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Rainer Weikusat on Sun Jan 31 17:43:31 2021
    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".

    And my example in that notation would be, as I understand it:

    ::ffff:144.76.35.252

    (IPv6 uses decimal rather than hex in this one context.)

    https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses

    Transparent support for this feature enables programs using IPv4 to
    talk to other program with no explicit support for IPv4.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    Working, but not speaking, for Philips Healthcare
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Keith Thompson on Mon Feb 1 15:16:11 2021
    Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
    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".

    That's because :: represents the largest, consecutive stream of
    zero-bytes in an IPv6 address. Thanks for pointing out the typo, but I
    didn't forget about this since I wrote the ::-using example above.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Boris Dorestand@21:1/5 to Richard Kettlewell on Mon Feb 1 14:14:16 2021
    Richard Kettlewell <invalid@invalid.invalid> writes:

    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

    %uname -a
    Linux ip-172-26-10-188 5.4.0-1032-aws #33~18.04.1-Ubuntu SMP
    Thu Dec 10 08:19:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

    I guess my kernel is 5.4?

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Boris Dorestand@21:1/5 to Grant Taylor on Mon Feb 1 14:18:15 2021
    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. (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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Kettlewell@21:1/5 to Boris Dorestand on Mon Feb 1 17:41:38 2021
    Boris Dorestand <bdorestand@example.com> writes:
    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.

    netstat lists sockets, and there’s only one socket, which accepts both address families.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Boris Dorestand on Mon Feb 1 10:25:45 2021
    On 2/1/21 10:18 AM, Boris Dorestand wrote:
    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.

    That summary makes perfect sense and matches (or exceeds) my working understanding.

    Thanks to all other thread participants too. I read all posts and
    appreciate all comments.

    :-)



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Boris Dorestand on Mon Feb 1 20:00:27 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Boris Dorestand@21:1/5 to Rainer Weikusat on Wed Feb 3 18:38:11 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Boris Dorestand on Wed Feb 3 16:16:08 2021
    On 2/3/21 2:38 PM, Boris Dorestand wrote:
    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?

    It helps.

    The socket is backwards compatible.

    But programs still have to be able to handle an IPv6 address. E.g. 4
    bytes won't store an IPv6 address. ;-) Database fields need to be bigger.

    But it does remove (or lessen) one (of many) aspects of the problem.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jorgen Grahn@21:1/5 to Boris Dorestand on Thu Feb 4 07:00:25 2021
    On Wed, 2021-02-03, Boris Dorestand wrote:
    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

    The text is undated, but it seems to be ~20 years old.

    Does it not? I mean, there's a backward compatibility now. A software writer can now worry about IPv6 and still support IPv4.

    Ever since getaddrinfo(3) was invented, 15--20 years ago, as a
    programmer you don't have to worry much about IPv4 versus IPv6[1].

    This doesn't solve the problem that your Internet is going to be quite
    small if you bring down the IPv4 half of your internet connection.
    /That/ part of DJB's text still applies.

    If that's so, who's responsible for this solution? Kernel writers?

    I don't think the thing you discussed upthread is really vital for
    dual IPv4/IPv6 hosts to work. It's more like a convenience.

    /Jorgen

    [1] If you're using ordinary TCP or UDP.

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Boris Dorestand on Thu Feb 4 15:03:15 2021
    Boris Dorestand <bdorestand@example.com> writes:
    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?

    I don't think so. IPv6-mapped-IPv4 addresses handle a specific
    application use-case: An IPv6 application binding to the wildcard
    address on a host which has both a public IPv4 address and a public IPv6 address can communicate with IPv4 applications running on other hosts
    sending traffic to the public IPv4 address.

    Obviously, this only works for protocols which don't use internet
    addresses anywhere except in the IP datagram header.

    There's still no way an IPv4 application can (directly) interact with applications running on IPv6-only hosts.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)