Re: specifying scopid's for link-local IPv6 addrs

[Vlad Yasevich <vladislav.yasevich@hp.com>]

Rick Jones wrote:
>> Rick,
>>
>> I don't see any way around this.  For example, on one of my test
>> systems, I have the following link local routes:
>>
>> chance% netstat -A inet6 -rn | grep fe80::/64
>> fe80::/64                                  
>> ::                                      U     256    0        0 eth0
>> fe80::/64                                  
>> ::                                      U     256    0        0 eth2
>> fe80::/64                                  
>> ::                                      U     256    0        0 eth3
>> fe80::/64                                  
>> ::                                      U     256    0        0 eth4
>> fe80::/64                                  
>> ::                                      U     256    0        0 eth5
>> fe80::/64                                  
>> ::                                      U     256    0        0 eth6
>>
>> So if I want to run a link local test to fe80::202:b3ff:fed4:cd1,
>> the system has no way to choose which is the correct interface to
>> use for the test, and will give an error if the interface isn't
>> specified. 
> 
> Yeah, I was wondering about that.  I'm not sure if the attempts on
> "those other OSes" happened to involve multiple interfaces or not.

Yes, there have been attempts.   BSD has a concept of default interface.
The default interface is used when the user did not specify the interface/
scope_id.

Other OSs do different things.  For example, Tru64 (to pick on a dead system)
would try to find the right interface base on the preferences you could
set up.

But, in the end the whole thing is really utterly broken since no-one has
truly implemented scoped address architecture for link-local addresses.
The concept of the link is so closely tied to the 'interface' that I don't
know anyone who has separated the two.


>  Even
> so, it "feels" unpleasant for an application to deal with and I wonder
> if there is a way for a stack to deal with it on the application's
> behalf.  I guess that might involve some sort of layer violation between
> neightbor discovery and routing (typing while I think about things I
> know little about...)
> 
> Is there RFC chapter and verse I might read about routing with multiple
> link-local's on a system?

See RFC 4007 for the concepts.  

> 
>> You must explicitly specify the desired interface.  For example,
>> on my test system, the correct interface is eth6 which is interface 8
>> (lo eth0 eth1 eth2 ... eth5 eth6).  Here is an example nuttcp test
>> specifying interface 8:
>>
>> chance% nuttcp -P5100 fe80::202:b3ff:fed4:cd1%8
>>  1178.5809 MB /  10.02 sec =  986.2728 Mbps 12 %TX 15 %RX
>>
>> nuttcp uses getaddrinfo() which parses the "%<ifindex>" field,
>> and then copies the sin6_scope_id from the res structure to the
>> server's sockaddr_in6 structure before initiating the connect().
> 
> OK, I'll give that a quick try with netperf:
> 
> [root@hpcpc106 ~]# netperf -H 192.168.2.107 -c -C -i 30,3 -- -s 1M -S 1M
> -m 64K -H fe80::207:43ff:fe05:9d%2
> TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to
> fe80::207:43ff:fe05:9d%2 (fe80::207:43ff:fe05:9d) port 0 AF_INET6 :
> +/-2.5% @ 99% conf.
> 
> Cool - it establishes the data connection just fine.
> 
> 
> To further demonstrate my ignorance :)  is that %n suffix something one
> might expect in most/all getaddrinfo()'s or is that unique to the one in
> Linux?

This is becoming more generic.  I believe HP-UX supports it (if the don't
you should kick them :).

-vlad