TCP using IPv4-mapped IPv6 address as source

TCP using IPv4-mapped IPv6 address as source

[Jonathan T. Leighton]

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.

$ uname -a
Linux ubuntu 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux

Best regards,
Jon

Re: TCP using IPv4-mapped IPv6 address as source

[Eric Dumazet]

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

Re: TCP using IPv4-mapped IPv6 address as source

[Jonathan T. Leighton]

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).

> Thanks
>
>

Re: TCP using IPv4-mapped IPv6 address as source

[Eric Dumazet]

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.

Thanks !

Re: TCP using IPv4-mapped IPv6 address as source

[Jonathan T. Leighton]

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 !
>
>

Re: TCP using IPv4-mapped IPv6 address as source

[Sowmini Varadhan]

On (01/11/17 14:48), Jonathan T. Leighton wrote:
> 
> 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.
> 

BTW, linux probably has a number of bugs in this space. 

you can do a number of "interesting" things, where the
v4-mapped address ends up being treated as a global address.
E.g., you can configure a v4 mapped address on an interface
using /sbin/ip, then you can add an onlink route, like
 # ip -6 route add ::ffff:13.0.0.1 nexthop onlink dev eth1
and you can ping6 ::ffff:13.0.0.1, and (if you do this
on both sides) watch a merry little packet exchange on
the wire, where we send out an NS for ::ffff:13.0.0.1
to the solmcast of the v4 mapped address, the peer politely
responds, and the 2 nodes then have a nice chat. 

I think the RFC states somewhere that you should never ever
send out a v4 mapped address on the wire.

--Sowmini
  

Re: TCP using IPv4-mapped IPv6 address as source

[Eric Dumazet]

On Wed, 2017-01-11 at 14:59 -0500, Sowmini Varadhan wrote:

> I think the RFC states somewhere that you should never ever
> send out a v4 mapped address on the wire.

Can you point the exact RFC ?

https://tools.ietf.org/html/rfc2765  seems to allow just that.


Jonathan issue is about terminating such flows in TCP stack, which is
likely not needed/useful.

Re: TCP using IPv4-mapped IPv6 address as source

[Sowmini Varadhan]

On (01/11/17 12:43), Eric Dumazet wrote:
> 
> On Wed, 2017-01-11 at 14:59 -0500, Sowmini Varadhan wrote:
> 
> > I think the RFC states somewhere that you should never ever
> > send out a v4 mapped address on the wire.
> 
> Can you point the exact RFC ?
> 
> https://tools.ietf.org/html/rfc2765  seems to allow just that.

I have not read the details of 2765, but from a cursory look,
it talks about "IPv4-translatable addresses", not v4-mapped
addrs, and says,
"The address translation mechanisms for the stateless and the stateful
 translations are defined in [RFC6052]"
It's also not clear to me that 2765 warrants the use of these
as ip6 src, or ip6 dst, or the target(s) of NS/NA.

https://www.rfc-editor.org/rfc/rfc4038.txt refers to security
considerations about sending v4-mapped addrs on the wire
Looks like these security considerations are discussed in
 https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02

In general, I think BSD and Solaris (and probably most
router implementations, esp the BSD-based ones) will not allow
v4 mapped addresses as src or dst of ip6 packets.

> Jonathan issue is about terminating such flows in TCP stack, which is
> likely not needed/useful.

sure. but if you configure the v4 mapped address as
a src addr "everything should be fine!"

--Sowmini

Re: TCP using IPv4-mapped IPv6 address as source

[Jonathan T. Leighton]

On 1/11/17 3:43 PM, Eric Dumazet wrote:
> On Wed, 2017-01-11 at 14:59 -0500, Sowmini Varadhan wrote:
>
>> I think the RFC states somewhere that you should never ever
>> send out a v4 mapped address on the wire.
> Can you point the exact RFC ?
>
> https://tools.ietf.org/html/rfc2765  seems to allow just that.

Link was in my original post. See table 20:

https://tools.ietf.org/html/rfc6890#page-14

> Jonathan issue is about terminating such flows in TCP stack, which is
> likely not needed/useful.

I'm sure I understand what you're saying here. There should be no flow 
to terminate.

>
>
>
>

Re: TCP using IPv4-mapped IPv6 address as source

[Eric Dumazet]

On Wed, 2017-01-11 at 16:26 -0500, Jonathan T. Leighton wrote:

> I'm sure I understand what you're saying here. There should be no flow 
> to terminate.

rfc2765 describes a way to use IPv4-mapped IPv6 packets on the wire.

What I meant by 'terminating' was that it does not tell if an end system
(a host) is allowed to natively generate these packets.

Anyway,
https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00 

(which does not appear to be an RFC), tells us this would be
dangerous ;)

Re: TCP using IPv4-mapped IPv6 address as source

[Jonathan T. Leighton]

On 1/11/17 4:47 PM, Eric Dumazet wrote:
> On Wed, 2017-01-11 at 16:26 -0500, Jonathan T. Leighton wrote:
>
>> I'm sure I understand what you're saying here. There should be no flow
>> to terminate.

I think you figured out that I meant "I'm not sure I understand...".

>> rfc2765 describes a way to use IPv4-mapped IPv6 packets on the wire.

I don't agree - I didn't read rfc2765 because it's obsolete, but the 
current version does not allow the use of IPv4-mapped IPv6 addresses. 
rfc2765 is obsoleted by rfc6145, and that in turn by rfc7915. rfc7915 
refers to both rfc6052 and rfc6219 for descriptions of the allowable 
mechanisms for translating from IPv4 to IPv6, and the mechanisms in each 
of those documents preclude the use of IPv4-mapped IPv6 addresses 
(::ffff:0:0/96). There's no conflict with rfc6890 (BCP153), which 
explicitly precludes the use of IPv4-mapped IPv6 addresses as a source 
(or destination) address.

> What I meant by 'terminating' was that it does not tell if an end system
> (a host) is allowed to natively generate these packets.
>
> Anyway,
> https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00
>
> (which does not appear to be an RFC), tells us this would be
> dangerous ;)
>
>
>