From owner-freebsd-current  Tue May 30  1:29:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lychee.itojun.org (INS28.chiba-ap2.dti.ne.jp [210.170.183.156])
	by hub.freebsd.org (Postfix) with ESMTP
	id C031D37BA48; Tue, 30 May 2000 01:29:35 -0700 (PDT)
	(envelope-from itojun@itojun.org)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by itojun.org (8.10.0/3.7W) with ESMTP id e4U85Fs00781;
	Tue, 30 May 2000 17:05:15 +0900 (JST)
To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
Cc: Alexander Langer <alex@big.endian.de>,
	Hajimu UMEMOTO <ume@bisd.hitachi.co.jp>, andrews@technologist.com,
	stable@FreeBSD.ORG, current@FreeBSD.ORG
In-reply-to: Cy.Schubert's message of Mon, 29 May 2000 23:44:03 MST.
      <200005300644.e4U6idT19592@cwsys.cwsent.com> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: ftp(1) breakage w/ passive mode? 
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Tue, 30 May 2000 17:05:15 +0900
Message-ID: <779.959673915@lychee.itojun.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


>> 	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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message