On 1/11/17 1:31 PM, Eric Dumazet wrote:
On Wed, 2017-01-11 at 12:34 -0500, Jonathan T. Leighton wrote:
On 1/11/17 11:20 AM, Eric Dumazet wrote:
On Thu, 2017-01-05 at 16:25 -0500, Jonathan T. Leighton wrote:
I've observed TCP using an IPv4-mapped IPv6 address as the source
address, which I believe contradicts
https://tools.ietf.org/html/rfc6890#page-14 (BCP 153). This occurs when
an IPv6 TCP socket, bound to a local IPv4-mapped IPv6 address, attempts
to connect to a remote IPv6 address. Presumable connect() should return
EAFNOSUPPORT in this case. Please advise me if this is not to
appropriate list to report this.
Hi Jonathan
I believe your concern makes sense.
Do you have a patch to address this issue ?
Thanks for responding Eric. I have limited experience with kernel
patches. Nevertheless, unless there's someone with the experience and
time to jump on this, I'm interested in taking a crack at it. I think
the issue certainly warrants attention: instead of returning immediately
with EAFNOSUPPPORT, connect() retransmits its SYN 6 times, ultimately
returning ETIMEDOUT after 127 sec (1+2+4+...+64).
I am not aware of an application trying to perform a bind() to an IPV4
address before a connect() to an IPv6 destination.
A kernel fix is certainly something that would detect application bugs
in a more friendly way.
I would say that an IPv6 socket binds to an IPv4-mapped IPv6 address,
but yes - using it to connect to an IPv6 address would be an application
bug. It also think that having connect() spend 2 minutes sending packets
containing an illegal source address is a bug. (And unfriendly!) I'll
look into writing a patch for this, and let you know whether or not I
think I'm up to it.
- Jon
Thanks !
