>> ume and I discussed it a little bit, directly.
>Tested the patch on a 4.0S system against KRB5 tunnelled through VPN
>(pipsecd for now) then NATed (using IP Filter at the remote side) to my
>employer's network. Kerberos rlogin and KRB5 telnet now work however
>KRB5 ftp still has problems.
I personally believe the patch to getaddrinfo(3) by ume is
not very relevant - the patch may change part of its API,
and it can choke some of the callers. I personally prefer fixing
ftp(1) and other callers if necessary.
However, the change (IPv4 mapped address handling) leaves me very
fuzzy feeling... The specification is not well defined, and
the change itself breaks certain network setup (the configuration
is rather rare, though). here's a comment I left in KAME
netbsd/usr.bin/ftp/ftp.c. I try to persuade ipngwg folks...
itojun
--
for (res = res0; res; res = res->ai_next) {
/*
* make sure that ai_addr is NOT an IPv4 mapped address.
* IPv4 mapped address complicates too many things in FTP
* protocol handling, as FTP protocol is defined differently
* between IPv4 and IPv6.
*
* This may not be the best way to handle this situation,
* since the semantics of IPv4 mapped address is defined in
* the kernel. There are configurations where we should use
* IPv4 mapped address as native IPv6 address, not as
* "an IPv6 address that embeds IPv4 address" (namely, SIIT).
*
* More complete solution would be to have an additional
* getsockopt to grab "real" peername/sockname. "real"
* peername/sockname will be AF_INET if IPv4 mapped address
* is used to embed IPv4 address, and will be AF_INET6 if
* we use it as native. What a mess!
*/
ai_unmapped(res);
...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
