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