(usagi-users 03743) Re: anyone using ftp6 ??

Bruno STEVANT <[email protected]> Fri, 29 Sep 2006 00:06:21 +0200
Newsgroups gmane.linux.ipv6.usagi.users
Message-ID <[email protected]>
OK do it the IETF way, switch a MUST with a SHOULD ;)
More seriously, I agree that scope ID lacks some normative definition  
into URI and that applications don't usually put scope_id into  
consideration.
But technically,  there may be some room for solutions, using the  
neighbor cache  for instance : when establishing the data connection,  
a FTP server can use his neighbor list to know on which interface the  
local address is valid. But I agree this is overkill, that  
application don't want to do that and that protocols don't need to be  
more complicated because of IPv6.

Le 28 sept. 06 à 21:04, Rémi Denis-Courmont a écrit :

> Le jeudi 28 septembre 2006 21:05, Bruno STEVANT a écrit :
>> Any application must handle Link-Local and Global address in the same
>> way.
>
> That's *RIDICULOUS* a statement. There is not even a standard notation
> for the scope ID part of link-local addresses, which are otherwise not
> usable (the infamous EINVAL error when using connect() or sendto()).
>
> While the standard IPv6 APIs RFCs define the sin6_scope_id field  
> within
> the sockaddr_in6 structure, and if_nametoindex and if_indextoname
> functions, it does not standardize the "IPv6_address%interface"
> notation, which is in fact not quite portable in practice.
>
> To name a few, you simply cannot use link-local addresses within SDP
> payload, which makes them unsuitable for RTSP, SAP[1] and SIP - the
> latter protocol being one of the expected driver for IPv6 in the first
> place.
> Similarly, you can't embed a link-local scope in a SMTP email address
> with IP address instead of host name, and, AFAIK, scope ID is not
> standardized in any URL schemes (rendering HTTP impossible for clients
> and proxies).
>
> [1] Well, ok, you can use SAP if you assume the scope ID is that  
> the SAP
> payload was received from (VLC media player does that for instance).
>
> Oh, and we were talking about FTP - how do you pass the scope ID to  
> the
> server if you want to establish an active data transfer? You simply
> can't, since you don't even know the would-be correct scope ID from  
> the
> server perspective (it might be eth0 = 2 for you and eth1 = 18 on the
> server). Honestly, a FTP with link-local address might work only if  
> you
> use Extended Passive (EPSV) mode; this forbids server-to-server
> transfer. And then the server and client implementations would have to
> be extra careful as to not "loose" the scope ID from the control
> connection to the data connections.
>
> And finally, worst of all, you cannot put link-local addresses in the
> DNS; same problem as with active FTP: you cannot specify the scope ID,
> and, even if you could, it would be host-specific.
>
> Link-local addresses are not meant for general applications.
>
>> For example, local service discovery protocol such as Bonjour only
>> resolves service name to  link-local address.
>
> Link-local addresses are certainly useful, e.g. for autoconf. And they
> are useful for unmanaged multicast use cases. These kind of use
> requires specific support code anyway.
>
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/