From owner-freebsd-arch Tue Jun 20 10:56:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 56EB837BFAE for ; Tue, 20 Jun 2000 10:56:32 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.9.3/8.9.3) with ESMTP id SAA10474; Tue, 20 Jun 2000 18:52:31 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id SAA64474; Tue, 20 Jun 2000 18:52:29 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200006201752.SAA64474@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: arch@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: Suggested change to BSD sockets API In-Reply-To: Message from Terry Lambert of "Tue, 20 Jun 2000 17:26:32 -0000." <200006201726.KAA19419@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jun 2000 18:52:29 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I believe Julian E did some work on this at one point but never finished it. The real problem is that once you've sent that first packet, your local IP number is cast in stone. You only have a chance of doing something prior to that - ie, at the point where data arrives at the interface and the interface decides it has to do something to establish an IP number. This is already done in ppp(8) if you use -nat and -auto. Ppp will retain the old IP number, assign the just-negotiated IP number with SIOCAIFADDR and NAT the outgoing packet just-in-time so that the initial connection succeeds. This isn't the most elegant way (it would be better to be able to bind to an interface that has no IP number and then retrospectively resolve the binding when an IP number is assigned), but it works. > One common problem I run into is that of cached state. > > In particular, if I have a dial-on-demand device that uses > a dynamic IP address assignment negotiated with the remote > side of the link, then all of my servers currently bound > and listening for incoming connections have to be clobbered > over the head for them to notice the IP address change. > > It seems to me that this could be better handled. > > The problem appears to be cached state information (I have > been meaning to write a white paper on "cached state considered > harmful"). > > For example, an inetd, a DNS server, or a sendmail bound to a > network address on an interface must be rebound when the IP > address changes. > > > I'd like to suggest that a new socket binding type be used; one > that binds not to an IP addres, but to an interface. > > The changes to support this don't seem that difficult; what do > others think about this? > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message