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