Marco d'Itri a écrit :
On Jan 20, Guillaume Gimenez <ggime...@free.fr> wrote:
- for the client side part of this issue, it forces applications
>> which migrate from ipv4 to ipv6 to keep legacy code.
If your application is broken, you use the setsockopt to enable the
compatibility mode for its sockets.
You are off topic, I mean that this parameter related to bind breaks the
operation of "IPv4-compatible IPv6 address" on client side. Isn't
::ffff:206.12.19.114 a valid IPv6 address ?
- for the server part of this issue, it is a good thing to unify
>> TCP part of TCP/IP(V4) and TCP/IP(v6). And it's not a sufficient reason
>> for debian to take the wrong way because "all major OSes" go ahead
in the wall.
Unification happens in the kernel, the API does not matter.
if an application needs a socket only binded to IPv6, it must use
IPV6_V6ONLY socket option on ALL OSes, if not it's broken.
Remember, keep things simples :
- a simple IPv4 server socket accepts all IPv4 connections
- a simple IPv6 server socket accepts both IPv4 and IPv6 connections
(with IPv4 mapped addresses)
- a simple IPv6 server socket wich wants only IPv6 connections uses
IPV6_V6ONLY
By the way you can continue to code your picky program which bind twice
on IPv4 and IPv6 and then separate logs for both protocols (if it is all
what matters)
Finaly if unification happens in the kernel why to separate both stacks
at tcp level ? (I do not speak about API, but you do by saying that such
and such program is broken)
Regards,
Guillaume
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
