Why does a connect to IPv6 LLA address fail ?
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) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does a connect to IPv6 LLA address fail ?
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 <[EMAIL PROTECTED]> SUSE Labs, SUSE CZ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does a connect to IPv6 LLA address fail ?
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:e9c3fails 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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does a connect to IPv6 LLA address fail ?
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 () | | | | | | Class= 1 | | | | DNS_Answer (length:86) | | | | | DNS_RR_ (length:43) | | | | | | Name = server.tahi.org. | | | | | | Type = 28 | | | | | | Class= 1 | | | | | | TTL = 0 | | | | | | Length = 16 | | | | | | Address = 3fff::2 | | | | | DNS_RR_ (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) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does a connect to IPv6 LLA address fail ?
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 () > | | | | | | Class= 1 > | | | | DNS_Answer (length:86) > | | | | | DNS_RR_ (length:43) > | | | | | | Name = server.tahi.org. > | | | | | | Type = 28 > | | | | | | Class= 1 > | | | | | | TTL = 0 > | | | | | | Length = 16 > | | | | | | Address = 3fff::2 > | | | | | DNS_RR_ (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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
