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]

Date:	Thu, 08 Nov 2007 13:15:52 -0500
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Andreas Gruenbacher <agruen@...e.de>
Cc:	Jiri Bohac <jbohac@...e.cz>, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org, kkeil@...e.de
Subject: Re: Why does a connect to IPv6 LLA address fail ?

Andreas Gruenbacher wrote:
> On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
>> 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.
> 
> Good point.
> 
> What's confusing is that connect(2) fails even if the host itself has the 
> specified address. This isn't necessary.

Yes and no.  Since linux doesn't have the concept of default zone, we have
to fail, because from the perspective of the kernel, the address was not
fully specified.  OTOH, since this is our address, we 'could' have all
the info.

The problem is that this verification happens before we hit the routing logic.
It's an explicit check the if the sin6_scope_id is not set and we are not bound
to an interface, it's an error.

> 
> What's even more confusing is that the kernel doesn't seem to honor the 
> interface in all cases: with
>    fe80::20f:20ff:fe3b:e9c3 on eth0 and
>    ::1 on lo,
> I get the following:
> 
>   ping6 fe80::20f:20ff:fe3b:e9c3		fails with EINVAL
>   ping6 fe80::20f:20ff:fe3b:e9c3%eth0		succeeds

Yes, but if you run a capture, you'll see the packet on loopback.  That's
because you have a route to this address.

>   ping6 fe80::20f:20ff:fe3b:e9c3%lo		succeeds

Yes, same thing.  Routing code takes care of it.

> 
> At least the last ping should fail, shouldn't it?

No, because both pings really go over loopback.  You are on the same system
and have 'local' routes for those addresses:
  ip -6 r l t local

> 
>> 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.
> 
> I think at least for host with only one link (in addition to loopback), 
> selecting that link for non-local addresses would make sense.
> 

Yes, you could do that.  Or you can push the interface check to the routing code
and do some logic to see if you can "select" an interface.

-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