Why does a connect to IPv6 LLA address fail ?

Why does a connect to IPv6 LLA address fail ?

[Karsten Keil]

Hi,

currently I do some cerification test for IPv6 with the TAHI ct testsuite.
With the default-addr-select tests for compliance with RFC3484 here are
FAILs with Destination Address Selection Check Rule 2(Prefer matching
scope). Yes I know that Destination Address Selection is done in glibc,
but it seems that the kernel behaves wrong in the connect system call
with IPv6 link local addresses. 

The glibc getaddrinfo function try to verify if a address is valid and
examine the source address. 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. So getaddrinfo
mark this candidate address as not reachable and so it will never prefered
because of rule 1 of RFC3484 Destination Address Selection.

Why do we have this check in ip6_datagram_connect() ?

The posix manpage for connect says about EINVAL:
"EINVAL - The address_len argument is not a valid length for the address family; or
invalid address family in the sockaddr structure."

Which is not the case here.

-- 
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)

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

[Jiri Bohac]

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. 

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?

Regards,

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

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

[Vlad Yasevich]

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

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

[Andreas Gruenbacher]

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.

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
  ping6 fe80::20f:20ff:fe3b:e9c3%lo		succeeds

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

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

Thanks,
Andreas

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

[Vlad Yasevich]

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

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

[Karsten Keil]

On Thu, Nov 08, 2007 at 01:15:52PM -0500, Vlad Yasevich wrote:
> 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.
> 

OK I run into this issue while running the TAHI testsuite. The test is as
follows:

  Check 03:
    DNS Address: fec0::9
    Candidate Source Addresses: fec0::1(SS) or LLA(LS)
    Destination Address List: 3fff::2(GS) or fe80::2(LS)
    Result: fe80::2 (src LLA) then 3fff::2 (src fec0::1)

    Scope(fe80::2) = Scope(LLA) and Scope(3fff::2) <> Scope(fec0::1), then prefer fe80::2

the nameserver send following answer for the query:

| | | | DNS_Question                    (length:21)
| | | | | DNS_QuestionEntry               (length:21)
| | | | | | Name                             = server.tahi.org.
| | | | | | Type                             = 28 (AAAA)
| | | | | | Class                            = 1
| | | | DNS_Answer                      (length:86)
| | | | | DNS_RR_AAAA                     (length:43)
| | | | | | Name                             = server.tahi.org.
| | | | | | Type                             = 28
| | | | | | Class                            = 1
| | | | | | TTL                              = 0
| | | | | | Length                           = 16
| | | | | | Address                          = 3fff::2
| | | | | DNS_RR_AAAA                     (length:43)
| | | | | | Name                             = server.tahi.org.
| | | | | | Type                             = 28
| | | | | | Class                            = 1
| | | | | | TTL                              = 0
| | | | | | Length                           = 16
| | | | | | Address                          = fe80::2



So how we should handle this issue, claim that the test is wrong, the test
should not use LLA for this ?

-- 
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)

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

[Vlad Yasevich]

Karsten Keil wrote:
> 
> OK I run into this issue while running the TAHI testsuite. The test is as
> follows:
> 
>   Check 03:
>     DNS Address: fec0::9
>     Candidate Source Addresses: fec0::1(SS) or LLA(LS)
>     Destination Address List: 3fff::2(GS) or fe80::2(LS)
>     Result: fe80::2 (src LLA) then 3fff::2 (src fec0::1)
> 
>     Scope(fe80::2) = Scope(LLA) and Scope(3fff::2) <> Scope(fec0::1), then prefer fe80::2
> 
> the nameserver send following answer for the query:
> 
> | | | | DNS_Question                    (length:21)
> | | | | | DNS_QuestionEntry               (length:21)
> | | | | | | Name                             = server.tahi.org.
> | | | | | | Type                             = 28 (AAAA)
> | | | | | | Class                            = 1
> | | | | DNS_Answer                      (length:86)
> | | | | | DNS_RR_AAAA                     (length:43)
> | | | | | | Name                             = server.tahi.org.
> | | | | | | Type                             = 28
> | | | | | | Class                            = 1
> | | | | | | TTL                              = 0
> | | | | | | Length                           = 16
> | | | | | | Address                          = 3fff::2
> | | | | | DNS_RR_AAAA                     (length:43)
> | | | | | | Name                             = server.tahi.org.
> | | | | | | Type                             = 28
> | | | | | | Class                            = 1
> | | | | | | TTL                              = 0
> | | | | | | Length                           = 16
> | | | | | | Address                          = fe80::2
> 
> 
> 
> So how we should handle this issue, claim that the test is wrong, the test
> should not use LLA for this ?
> 

You could argue that a DNS server should not return link-local addresses because there
is no way for the DNS server to specify a correct zone.

I believe this is actually documented somewhere...

-vlad