From owner-freebsd-arch@FreeBSD.ORG Fri Oct 22 15:23:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93DEF16A4D3 for ; Fri, 22 Oct 2004 15:23:06 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6FD843D46 for ; Fri, 22 Oct 2004 15:23:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 87400 invoked from network); 22 Oct 2004 15:21:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 15:21:31 -0000 Message-ID: <417925D8.C426261E@freebsd.org> Date: Fri, 22 Oct 2004 17:23:04 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <4177C8AD.6060706@freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 15:23:06 -0000 Dag-Erling Smørgrav wrote: > > Andre Oppermann writes: > > o T/TCP only available on FreeBSD. No other Operating System or TCP/IP > > stack implements it to my knowledge. Certainly no OS that is common. > > AFAIK, both Linux and Windows support it, at least on the server side > (i.e. they can receive T/TCP connections even if they can't initiate > them). Any fully TCP compliant stack should be able to accept T/TCP connection attempts. However if it didn't implement T/TCP itself it would simply do the standard 3WSH. So yes, you can use T/TCP from the client side towards any TCP server but you don't get any benefit from it. Neither Windows or Linux implement it. Windows during the NT4 days had a bug in the TCP stack that allowed something like T/TCP but it wasn't T/TCP and didn't work with T/TCP compliant clients. > > o T/TCP requires different API calls than TCP to use it (UDP like). > > Only on the client side, I believe. Yes, on the client side. sendto() instead of connect()+write(). > > o T/TCP is not supported by any common network application. > > Prior to libfetch, fetch(1) used it by default. Only if T/TCP was enabled on the machine (net.inet.tcp.rfc1644). > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > Unlike your proposal, T/TCP is described in Internet RFCs (1379 and > 1644) and well-known by the Internet community. Well known for its gaping security holes and left unimplemented on any other OS except FreeBSD. -- Andre