netdev - Re: Why does a connect to IPv6 LLA address fail ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4732151B.70309@hp.com>
Date:	Wed, 07 Nov 2007 14:42:19 -0500
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Jiri Bohac <jbohac@...e.cz>
Cc:	netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org, kkeil@...e.de
Subject: Re: Why does a connect to IPv6 LLA address fail ?

Jiri Bohac wrote:
> Hi,
> 
>> For this it create a socket for datagram and
>> protocol IPPROTO_IP and then try to connect it with the destination
>> address. This fails in the case of a LLA, because connect returns EINVAL,
>> since here is no device bind to this socket at this time.
> 
> [snip]
> 
>> Why do we have this check in ip6_datagram_connect() ?
> 
> This problem has been nicely described in
> http://www.linux-ipv6.org/ml/usagi-users/msg03062.html
> without any response. 
> 
> RFC2461, Appendix A, really suggests performing neighbour
> discovery on all the links. I like the idea, it would make LLAs
> much more useful. 

The reason this is in an Appendix is because it doesn't work all
the time.  It was there to document some experiments that were going
on.

> 
> Has anyone experimented with this? Is there any good reason why
> we don't send NSs to all the links to find out which link the
> destination LLA is on?

The reason is that 2 different hosts may have the same link-local
address as long as they are on different links.  If the sender is
connected to both links then it may send the packet to the wrong
destination.

Link local addresses are unqualified without the scope/zone id.
The application must pass this information to the kernel as part of
the connect() call.

A different and some might say 'better' alternative is to define a
default link.  Thus when the zone id is not specified the default is used.
This will work fine for link-scoped addresses.  A default zone would also
need to be defined for other scopes as well.  That's just one idea.

-vlad
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html