From: Matthew Oswalt <email@example.com>
Subject: Historical reason for differences in v4/v6 Any-IP for nonlocal binds
Date: Tue, 22 Feb 2022 17:08:30 -0500 [thread overview]
Message-ID: <CAKrN56vUv_WDHu8AK_J5mxEHq3tWpmMQ5zmN2NwPxfRtObZHnQ@mail.gmail.com> (raw)
I'm working with binding TCP sockets to nonlocal addresses (not
configured on an interface). I noticed that both IPv4 and IPv6 sockets
will succeed using options like IP_FREEBIND, but unlike IPv6, sockets
using IPv4 can also succeed if a matching Any-IP route is present,
without configuring any options or sysctl settings.
I noticed an old email in this mailing list that also describes this behavior:
I'm running a somewhat recent kernel (5.10) and my testing shows
identical results using TCP as well, so I believe this is still true.
For IPv4 sockets, either the presence of a matching Any-IP route,
**or** setting IP_FREEBIND (etc), results in a successful bind() to a
nonlocal address. However, with IPv6, it doesn't appear to matter
whether or not an Any-IP route is present. For these to succeed, an
option like IP_FREEBIND **must** be set (or
ipv6.sysctl.ip_nonlocal_bind, or IP_TRANSPARENT I believe would also
After looking through "net/af_inet6.c" a bit, it seems obvious that
this is intended behavior. I believe I'm able to follow that bit of
the kernel code and understand how the decision is made.
However, is there any historical reason for this discrepancy? Why does
the IPv4 implementation perform a FIB lookup and allow a bind to
proceed if an Any-IP route is found, but the IPv6 implementation
doesn't? I'm really just curious if there is a specific reason why
this aspect of the IPv4 implementation wasn't brought over to the IPv6
implementation, or if it was just left out in favor of the more
explicit approach via options like IP_FREEBIND, or any other reason I
could be missing.
reply other threads:[~2022-02-22 22:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).