On 31/07/11 18:03, Andrew O. Shadoura wrote:
The explanation is, when you connect to any of 127.1/8 addresses, you
get back to the localhost, as per RFC 3330:
A datagram sent by a higher level protocol to an address anywhere
within this block should loop back inside the host.
I have been reading my rfc's too, but didn't end up in the same place as
you, so thanks very much for spending time on this issue. RFC3330 seems
to clinch it, but I will add my own research to the documentation.
I've just inspected several machines, running various versions of
ubuntu. Some of them have NO programs listening on the IPv4 0.0.0.0
wildcard address. Others have a mixture of explicit loopbacks from some
programs, and the wildcard from others.
Looking carefully at the lo interface (address 127.0.0.1 with a class A
mask of 255.0.0.0), there is no reason (prior to RFC3330) why 127.0.1.1
should be associated with that interface... exactly why I reported the
bug in the first place.
RFC5735 says:-
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher-level protocol to an
address anywhere within this block loops back inside the host. This
is ordinarily implemented using only 127.0.0.1/32 for loopback. As
described in [RFC1122], Section 3.2.1.3, addresses within the entire
127.0.0.0/8 block do not legitimately appear on any network anywhere.
So RFC3330 is echoed in this section, but until you picked it out, I had
not interpreted it as definitively - it doesn't say "must", "should", or
suchlike.
RFC1122 Section 3.2.1.3 PROTOCOL WALK-THROUGH, Addressing says just this:
(g) { 127, <any> }
Internal host loopback address. Addresses of this form
MUST NOT appear outside a host.
I guess some "magic" is happening in the tcp/ip stack to deliver an
incoming IPv4 datagram with a destination address of 127.0.1.1 (in our
case) to an application listening on all addresses, even though no
interface is explicitly associated with 127.0.1.1.
That works only if your dæmon listens on 0.0.0.0 or ::, and not
explicitly 127.0.0.1.
I have no explanation, however, why didn't it work before. At least,
I couldn't reproduce it (yet).
If I am right, then the "magic" must have changed some time in the past,
but has been masked by the behaviour of ifupdown (and customised hosts
files used by many people). By removing ifupdown's explicit assignment
of address(es) to the loopback interface and simplifying the hosts file,
we seem to have permitted the underlying "magic" to work properly for
any application listening on a server socket bound to all network
interfaces.
"man 7 ip" says:
When INADDR_ANY is specified in the bind call, the socket will be
bound to all local interfaces.
Quite possible, that migration to iproute changed something, but I
can't find anything important changed.
Thanks for looking into it, Andrew.
I am satisfied with the ifupdown change resolving this problem, although
a simple patch might need a bit of untangling from all the other changes
the alpha brings. Are you heading towards something stable that might be
better back-ported in its entirety?
However, this is a subtle change of behaviour and I am worried about
doing a lot of work to make the behaviour "correct", only to trigger
loads of complaints from previously satisfied users who don't like the
new behaviour. I think it is better to take this slowly...
Brian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
