Re: broken IPv6 code
>>>>> "James" == James Antill <james@and.org> writes:
>> If you are worried that an application might bind to a port
>> (IPv6 with IPv4 support implied) and have it taken over by an
>> IPv4 application, I would be surprised if this is an issue.
James> Why wouldn't it be an issue ? Either it lets another uid
James> do it and so is a major security problem, or it doesn't
James> ... and bind calls can magically fail (say you have a
James> daemon that has random uid's for each network connected
James> process ... then the calls will fail). Personally I think
James> it should always fail, or that bind()'ing ipv6 address
James> shouldn't do anything with any ipv4 ones.
I would have assumed that binding to an IPv4 address would fail if the
IPv4 address was already binded to, even this was implied by an IPv6
bind operation. However, I realize it is often dangerous to make
assumptions...
Hopefully that makes sense ;-)
James> But the one that failed will have been told so with -1 and
James> errno.
This is meaningless if the application is forced to ignore the error.
If an error is returned from an IPv4 bind operation, how is the
application to know if:
a) the port is already in use by another application
b) the IPv6 bind has also implies a bind to the IPv4 port.
which is really dependent on the OS being used.
>> IPv6 should be treated as a unique protocol, just like any
>> other protocol supported by the sockets API. If this is not
>> possible for reasons I don't understand, then the API should be
>> changed so that applications can be protocol independent
>> (eg. getaddrinfo shouldn't return IPv4 addresses in this case).
James> Yeh it might be nice if this was the last change in the
James> socket() API for a while at least.
I think I can see why Linux has chosen the current approach, I suspect
it means IPv4 applications can be converted to IPv6 more easily, as
chances are the author has assumed only one socket will exist. If IPv4
and IPv6 are treated as separate protocols, then 2 sockets are now
required.
However, I think this is at a cost:
a) not standard, so program will probably have to be updated to
support many sockets anyway, for other operating systems.
b) not expandable to support other protocols which currently exist (eg
Unix domain sockets) or may exist in the future (eg perhaps ATM or
something might one day become popular).
I think there are two solutions:
1. getaddrinfo should not return IPv4 addresses if an IPv6 address exist,
since using the IPv6 address implies usage of the IPv4 address.
2. IPv4 and IPv6 protocols kept completely separate.
Either one or the other, it doesn't really matter, either way it is
possible to create portable applications that aren't broken. The
choice could vary depending on operating system too, I think.
(then again, I only have Linux 2.2.18 - does 2.4.0x behave any
differently?)
--
Brian May <bam@debian.org>
Reply to: