From owner-tcp-impl@lerc.nasa.gov  Tue Dec  5 10:46:10 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20313
	for <tcpimpl-archive@odin.ietf.org>; Tue, 5 Dec 2000 10:46:10 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA13319
	for tcp-impl-outgoing; Tue, 5 Dec 2000 08:14:24 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA13256
	for <tcp-impl@grc.nasa.gov>; Tue, 5 Dec 2000 08:14:18 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id IAA09746; Tue, 5 Dec 2000 08:14:17 -0500
Received: from mercury.spider.com(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma009484; Tue, 5 Dec 00 08:12:21 -0500
Received: from asimov.spider.com (asimov.spider.com [212.240.99.66])
	by mercury.spider.com (8.8.8/8.8.8) with ESMTP id NAA06232
	for <tcp-impl@grc.nasa.gov>; Tue, 5 Dec 2000 13:12:19 GMT
	(envelope-from ian@asimov.spider.com)
Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93])
	by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA17530;
	Tue, 5 Dec 2000 13:12:18 GMT
Received: (from ian@localhost)
	by malatesta.spider.com (8.9.1b+Sun/8.9.1) id NAA25257;
	Tue, 5 Dec 2000 13:12:18 GMT
Date: Tue, 5 Dec 2000 13:12:18 +0000
From: Ian Heavens <ian@spider.com>
To: tcp-impl@grc.nasa.gov
Subject: protocol theology discussion mailing list
Message-ID: <20001205131218.A25245@malatesta.spider.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre4i
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk


Excuse me if this is somewhat off-topic (is the end2-end list still
in use?  Perhaps someone could post it there), but I've started the
following mailing list:

protocol-theology@tardis.ed.ac.uk

Charter: to discuss the pros and cons of good protocol design,
with reference to their origins and development (XNS, SNA, OSI,
TCP/IP, SS7, etc.).  Starting point: the reissue of Michael
Padlipsky's 1985 treatise on the subject, "The Elements
of Networking Style" ($19.95)  
http://www.iuniverse.com/marketplace/bookstore/book_detail.asp?isbn=0%2D595%2D08879%2D1).

To subscribe: Send "subscribe protocol-theology" to listar@tardis.ed.ac.uk

cheers
ian

-- 
Ian Heavens, Spider Software Ltd., http://www.spider.com/
8 John's Place, Leith, Edinburgh EH6 7EL. 
Tel +44 131 475 7015 fax. +44 131 475 7001  ian@spider.com


From owner-tcp-impl@lerc.nasa.gov  Fri Dec  8 16:54:49 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07125
	for <tcpimpl-archive@odin.ietf.org>; Fri, 8 Dec 2000 16:54:48 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA28216
	for tcp-impl-outgoing; Fri, 8 Dec 2000 14:04:14 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA28183
	for <tcp-impl@grc.nasa.gov>; Fri, 8 Dec 2000 14:04:11 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id OAA28671; Fri, 8 Dec 2000 14:04:10 -0500
Received: from sol.extremenetworks.com(216.52.8.2) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma028606; Fri, 8 Dec 00 14:03:38 -0500
Received: by SOL with Internet Mail Service (5.5.2653.19)
	id <YPBH6KKA>; Fri, 8 Dec 2000 10:45:12 -0800
Message-ID: <2F5F27915881D411B43F00508BD8935F2E3676@sc-sol-04.extremenetworks.com>
From: Marylou Orayani <morayani@extremenetworks.com>
To: "'tcp-impl@grc.nasa.gov'" <tcp-impl@grc.nasa.gov>
Cc: Marylou Orayani <morayani@extremenetworks.com>
Subject: TIME_WAIT problem on Solaris 2.7
Date: Fri, 8 Dec 2000 10:46:08 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk

I'm trying to track down a TIME_WAIT problem on one of our Solaris boxes. We
have a Web server that opens telnet connections that are not being cleaned
up. When we do a netstat, we see very many ports in the TIME_WAIT state and
have been there for several days (not just the requisite 2MSL period). They
simply are not going away. Have you heard of this problem on Solaris 2.7
before?

Marylou Orayani


From owner-tcp-impl@lerc.nasa.gov  Fri Dec 15 11:42:23 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21166
	for <tcpimpl-archive@odin.ietf.org>; Fri, 15 Dec 2000 11:42:22 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA05624
	for tcp-impl-outgoing; Fri, 15 Dec 2000 09:21:10 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA05557
	for <tcp-impl@grc.nasa.gov>; Fri, 15 Dec 2000 09:21:04 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id JAA14819; Fri, 15 Dec 2000 09:21:00 -0500
Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma014677; Fri, 15 Dec 00 09:20:41 -0500
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id JAA03793;
	Fri, 15 Dec 2000 09:20:24 -0500 (EST)
Date: Fri, 15 Dec 2000 09:20:24 -0500 (EST)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200012151420.JAA03793@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: tcp-impl@grc.nasa.gov
Subject: Multiple TCP source addresses?
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 8bit

I've got a problem I'm trying to invent a solution to and I thought I'd
ask if there's any past work I should look at, or perhaps it's already
been solved and I just don't know it.

Most of the hosts on my home LAN are multihomed; I have address space
from two different places and I run both subnets over the same house
Ethernet.  (Network interfaces are configured to have both addresses.)
Sometimes one block of address space is reachable while the other one
isn't, and outgoing packets are routed to one of two tunnels (one to
each provider of address space) based on which subnet their source
addresses fall into.

This all works well in normal circumstances.  The problem is with
outgoing connections when one block of address space is unreachable for
some reason.  All the hosts have their default routes pointing to the
off-LAN gateway, but I had to pick one of its two addresses, and the
source address for the outgoing connection is always in the
corresponding subnet.  When that subnet is unreachable from the
destination host, outgoing connections fail even if I do have
connectivity to that host via the other subnet.

I could deal with the case where a subnet goes completely unreachable
with a routing protocol of some sort, perhaps.  But reachability is not
always all-or-nothing; depending on where the outage is, which hosts
can reach which subnet varies.

So I'd like to do something so that outgoing connections for which the
application has not specified a source address don't always try with
one source address and give up if that doesn't work; conceptually, I'd
like to try from all local addresses.  I was thinking of sending out
multiple SYNs, one for each local address; as soon as one gets
SYN-ACKed, that would commit the local address and SYN-ACKs for the
others would draw RSTs.  It does occur to me that I may want to do this
round-robin among the addresses, rather than in bursts, to avoid
creating unnecessary embryonic connections on the taget host in case
both addresses work.  (Of course, they would be torn down quickly in
response to the RST, but still.)

Comments?  Thoughts?  Prior art?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From owner-tcp-impl@lerc.nasa.gov  Fri Dec 15 13:26:34 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23285
	for <tcpimpl-archive@odin.ietf.org>; Fri, 15 Dec 2000 13:26:34 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA04235
	for tcp-impl-outgoing; Fri, 15 Dec 2000 11:29:08 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA04203
	for <tcp-impl@grc.nasa.gov>; Fri, 15 Dec 2000 11:29:04 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id LAA06261; Fri, 15 Dec 2000 11:29:03 -0500
Received: from ertpg14e1.nortelnetworks.com(47.234.0.35) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma006204; Fri, 15 Dec 00 11:28:39 -0500
Received: from zsc4c000.us.nortel.com by ertpg14e1.nortelnetworks.com;
          Fri, 15 Dec 2000 11:02:24 -0500
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <YXD3NBLS>; Fri, 15 Dec 2000 08:02:20 -0800
Message-ID: <8B888AAAAB0FD31189590008C791844303C3E03B@zbl6c002.corpeast.baynetworks.com>
From: "Ruth Fax" <rfax@nortelnetworks.com>
To: "'der Mouse'" <mouse@Rodents.Montreal.QC.CA>, tcp-impl@grc.nasa.gov
Subject: RE: Multiple TCP source addresses?
Date: Fri, 15 Dec 2000 08:02:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C066B0.678B6600"
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C066B0.678B6600
Content-Type: text/plain;
	charset="iso-8859-1"

The problem is what routing protocols were designed for.  When a destination
subnet is unreachable, packets will be routed to the second provider
(assuming that provider has a route to the destination and back to you).

Varying the source address, to force packets onto the second provider, is a
solution.  But it
doesn't scale and may not work.  If the problem is with the destination,
trying to get there via another provider won't work.  If the problem is with
the first provider, it will work, but so will routing.

I may have missed something in your solution, but I think you mean you'd
only try one source address from the second subnet.  i.e. multiple SYNs from
an address on each subnet.  Sending multiple SYNs from multiple addresses on
the same subnet won't help.

I'd like to know why the block of addresses goes unreachable before
proposing a solution.  Try some traceroutes from each subnet when this
happens.  It could be network congestion, route flaps, crashes, etc. I've
had providers mysteriously lose routes back to me at times.

--Ruth

-----Original Message-----
From: der Mouse [mailto:mouse@Rodents.Montreal.QC.CA]
Sent: Friday, December 15, 2000 9:20 AM
To: tcp-impl@grc.nasa.gov
Subject: Multiple TCP source addresses?


I've got a problem I'm trying to invent a solution to and I thought I'd
ask if there's any past work I should look at, or perhaps it's already
been solved and I just don't know it.

Most of the hosts on my home LAN are multihomed; I have address space
from two different places and I run both subnets over the same house
Ethernet.  (Network interfaces are configured to have both addresses.)
Sometimes one block of address space is reachable while the other one
isn't, and outgoing packets are routed to one of two tunnels (one to
each provider of address space) based on which subnet their source
addresses fall into.

This all works well in normal circumstances.  The problem is with
outgoing connections when one block of address space is unreachable for
some reason.  All the hosts have their default routes pointing to the
off-LAN gateway, but I had to pick one of its two addresses, and the
source address for the outgoing connection is always in the
corresponding subnet.  When that subnet is unreachable from the
destination host, outgoing connections fail even if I do have
connectivity to that host via the other subnet.

I could deal with the case where a subnet goes completely unreachable
with a routing protocol of some sort, perhaps.  But reachability is not
always all-or-nothing; depending on where the outage is, which hosts
can reach which subnet varies.

So I'd like to do something so that outgoing connections for which the
application has not specified a source address don't always try with
one source address and give up if that doesn't work; conceptually, I'd
like to try from all local addresses.  I was thinking of sending out
multiple SYNs, one for each local address; as soon as one gets
SYN-ACKed, that would commit the local address and SYN-ACKs for the
others would draw RSTs.  It does occur to me that I may want to do this
round-robin among the addresses, rather than in bursts, to avoid
creating unnecessary embryonic connections on the taget host in case
both addresses work.  (Of course, they would be torn down quickly in
response to the RST, but still.)

Comments?  Thoughts?  Prior art?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

------_=_NextPart_001_01C066B0.678B6600
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Multiple TCP source addresses?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The problem is what routing protocols were designed =
for.&nbsp; When a destination subnet is unreachable, packets will be =
routed to the second provider (assuming that provider has a route to =
the destination and back to you).</FONT></P>

<P><FONT SIZE=3D2>Varying the source address, to force packets onto the =
second provider, is a solution.&nbsp; But it</FONT>
<BR><FONT SIZE=3D2>doesn't scale and may not work.&nbsp; If the problem =
is with the destination, trying to get there via another provider won't =
work.&nbsp; If the problem is with the first provider, it will work, =
but so will routing.</FONT></P>

<P><FONT SIZE=3D2>I may have missed something in your solution, but I =
think you mean you'd only try one source address from the second =
subnet.&nbsp; i.e. multiple SYNs from an address on each subnet.&nbsp; =
Sending multiple SYNs from multiple addresses on the same subnet won't =
help.</FONT></P>

<P><FONT SIZE=3D2>I'd like to know why the block of addresses goes =
unreachable before proposing a solution.&nbsp; Try some traceroutes =
from each subnet when this happens.&nbsp; It could be network =
congestion, route flaps, crashes, etc. I've had providers mysteriously =
lose routes back to me at times.</FONT></P>

<P><FONT SIZE=3D2>--Ruth</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: der Mouse [<A =
HREF=3D"mailto:mouse@Rodents.Montreal.QC.CA">mailto:mouse@Rodents.Montre=
al.QC.CA</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, December 15, 2000 9:20 AM</FONT>
<BR><FONT SIZE=3D2>To: tcp-impl@grc.nasa.gov</FONT>
<BR><FONT SIZE=3D2>Subject: Multiple TCP source addresses?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I've got a problem I'm trying to invent a solution to =
and I thought I'd</FONT>
<BR><FONT SIZE=3D2>ask if there's any past work I should look at, or =
perhaps it's already</FONT>
<BR><FONT SIZE=3D2>been solved and I just don't know it.</FONT>
</P>

<P><FONT SIZE=3D2>Most of the hosts on my home LAN are multihomed; I =
have address space</FONT>
<BR><FONT SIZE=3D2>from two different places and I run both subnets =
over the same house</FONT>
<BR><FONT SIZE=3D2>Ethernet.&nbsp; (Network interfaces are configured =
to have both addresses.)</FONT>
<BR><FONT SIZE=3D2>Sometimes one block of address space is reachable =
while the other one</FONT>
<BR><FONT SIZE=3D2>isn't, and outgoing packets are routed to one of two =
tunnels (one to</FONT>
<BR><FONT SIZE=3D2>each provider of address space) based on which =
subnet their source</FONT>
<BR><FONT SIZE=3D2>addresses fall into.</FONT>
</P>

<P><FONT SIZE=3D2>This all works well in normal circumstances.&nbsp; =
The problem is with</FONT>
<BR><FONT SIZE=3D2>outgoing connections when one block of address space =
is unreachable for</FONT>
<BR><FONT SIZE=3D2>some reason.&nbsp; All the hosts have their default =
routes pointing to the</FONT>
<BR><FONT SIZE=3D2>off-LAN gateway, but I had to pick one of its two =
addresses, and the</FONT>
<BR><FONT SIZE=3D2>source address for the outgoing connection is always =
in the</FONT>
<BR><FONT SIZE=3D2>corresponding subnet.&nbsp; When that subnet is =
unreachable from the</FONT>
<BR><FONT SIZE=3D2>destination host, outgoing connections fail even if =
I do have</FONT>
<BR><FONT SIZE=3D2>connectivity to that host via the other =
subnet.</FONT>
</P>

<P><FONT SIZE=3D2>I could deal with the case where a subnet goes =
completely unreachable</FONT>
<BR><FONT SIZE=3D2>with a routing protocol of some sort, perhaps.&nbsp; =
But reachability is not</FONT>
<BR><FONT SIZE=3D2>always all-or-nothing; depending on where the outage =
is, which hosts</FONT>
<BR><FONT SIZE=3D2>can reach which subnet varies.</FONT>
</P>

<P><FONT SIZE=3D2>So I'd like to do something so that outgoing =
connections for which the</FONT>
<BR><FONT SIZE=3D2>application has not specified a source address don't =
always try with</FONT>
<BR><FONT SIZE=3D2>one source address and give up if that doesn't work; =
conceptually, I'd</FONT>
<BR><FONT SIZE=3D2>like to try from all local addresses.&nbsp; I was =
thinking of sending out</FONT>
<BR><FONT SIZE=3D2>multiple SYNs, one for each local address; as soon =
as one gets</FONT>
<BR><FONT SIZE=3D2>SYN-ACKed, that would commit the local address and =
SYN-ACKs for the</FONT>
<BR><FONT SIZE=3D2>others would draw RSTs.&nbsp; It does occur to me =
that I may want to do this</FONT>
<BR><FONT SIZE=3D2>round-robin among the addresses, rather than in =
bursts, to avoid</FONT>
<BR><FONT SIZE=3D2>creating unnecessary embryonic connections on the =
taget host in case</FONT>
<BR><FONT SIZE=3D2>both addresses work.&nbsp; (Of course, they would be =
torn down quickly in</FONT>
<BR><FONT SIZE=3D2>response to the RST, but still.)</FONT>
</P>

<P><FONT SIZE=3D2>Comments?&nbsp; Thoughts?&nbsp; Prior art?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>der =
Mouse</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mouse@rodents.montreal.qc.ca</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; 7D C8 61 52 5D E7 2D 39&nbsp; 4E F1 =
31 3E E8 B3 27 4B</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C066B0.678B6600--


From owner-tcp-impl@lerc.nasa.gov  Fri Dec 15 14:51:39 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22102
	for <tcpimpl-archive@odin.ietf.org>; Fri, 15 Dec 2000 14:51:38 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA18667
	for tcp-impl-outgoing; Fri, 15 Dec 2000 13:04:31 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA18629
	for <tcp-impl@grc.nasa.gov>; Fri, 15 Dec 2000 13:04:29 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id NAA19526; Fri, 15 Dec 2000 13:04:28 -0500
Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma019404; Fri, 15 Dec 00 13:03:26 -0500
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA04141;
	Fri, 15 Dec 2000 13:03:22 -0500 (EST)
Date: Fri, 15 Dec 2000 13:03:22 -0500 (EST)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200012151803.NAA04141@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 8bit

>> So I'd like to do something so that outgoing connections for which
>> the application has not specified a source address don't always try
>> with one source address and give up if that doesn't work;
>> conceptually, I'd like to try from all local addresses.  I was
>> thinking of sending out multiple SYNs, [...]

> The problem is what routing protocols were designed for.  When a
> destination subnet is unreachable, packets will be routed to the
> second provider (assuming that provider has a route to the
> destination and back to you).

I'm not sure what you mean; perhaps I didn't describe the problem in
enough detail.

Let's give a concrete example.  My home mailserver,
twig.rodents.montreal.qc.ca, is at 132.206.78.3 and 216.46.5.3.  The
off-LAN gateway is stone, 132.206.78.33 and 216.46.5.9.  Twig's default
route points to 216.46.5.9; if twig initiates a connection, it will
come from 216.46.5.3.

Something went wrong recently with a router on the path from the
outside world to 216.46.5.3 (packets can get out but can't get back in,
though for these purposes it might as well have fallen over entirely).
216.46.5.3 can reach anything on the near side of that router;
132.206.78.3 can reach anything else - but neither address can reach
any host the other one can.  (I've put a bug in the ear of the relevant
techies; it may have been fixed by the time you read this for all I
know.)  Incoming connections to 216.46.5.3 from beyond the dead router
time out, but 132.206.78.3 works; for hosts on the near side of it, the
converse is true.

How is a routing protocol supposed to deal with this?  Remember, my
house LAN doesn't have its own AS.

> Varying the source address, to force packets onto the second
> provider, is a solution.  But it doesn't scale

In what sense does it not scale?  Doesn't scale to a larger house LAN?
Doesn't scale to more than a few addresses per host?  Doesn't scale in
that it would be a disaster if every multihomed host did it?  What?

> I may have missed something in your solution, but I think you mean
> you'd only try one source address from the second subnet.

Yes.  (Actually, I would probably have the code try once per address
the machine has, which in my case has the same effect.)

> Sending multiple SYNs from multiple addresses on the same subnet
> won't help.

I'm not convinced; I've seen cases where one host is reachable and the
host next to it isn't.  (Not often, mind you.)

> I'd like to know why the block of addresses goes unreachable before
> proposing a solution.  Try some traceroutes from each subnet when
> this happens.  It could be network congestion, route flaps, crashes,
> etc. I've had providers mysteriously lose routes back to me at times.

Oh, I know what happened, in a functional sense: a router went wonky,
incorrectly returning host unreachables for inbound (ie, to my house
LAN) packets.  Perhaps it just lost a route; perhaps it broke more
seriously - I don't know details.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From owner-tcp-impl@lerc.nasa.gov  Sat Dec 16 06:33:28 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12541
	for <tcpimpl-archive@odin.ietf.org>; Sat, 16 Dec 2000 06:33:27 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA10515
	for tcp-impl-outgoing; Sat, 16 Dec 2000 04:15:06 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA10509
	for <tcp-impl@grc.nasa.gov>; Sat, 16 Dec 2000 04:15:04 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id EAA24527; Sat, 16 Dec 2000 04:15:04 -0500
Received: from mail3.microsoft.com(131.107.3.123) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma024475; Sat, 16 Dec 00 04:14:19 -0500
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 16 Dec 2000 01:12:07 -0800 (Pacific Standard Time)
Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58)
	id <Y0JGWHF3>; Fri, 15 Dec 2000 16:24:07 -0800
Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9BFB@red-msg-06.redmond.corp.microsoft.com>
From: Richard Draves <richdr@microsoft.com>
To: "'der Mouse'" <mouse@Rodents.Montreal.QC.CA>, tcp-impl@grc.nasa.gov
Cc: "'multi6@ops.ietf.org'" <multi6@ops.ietf.org>
Subject: RE: Multiple TCP source addresses?
Date: Fri, 15 Dec 2000 14:44:48 -0800
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk

I'm cc'ing multi6@ops.ietf.org, which was recently formed to discuss site
multihoming issues like this, albeit in the context of IPv6 instead of IPv4.
This is definitely an important problem to solve.

You're headed down the path to one possible solution, in which hosts have
multiple addresses and are smart enough to try different combinations of
src/dst address to find a working path.

There are other approaches that are more routing based. For example suppose
your house has one address prefix, which was allocated out of a block
assigned to your metro area/region. Your house network prefix is advertised
inside all ISP networks in your region, but not to other regions. Only the
shorter region prefix is advertised to other regions. Then routing protocols
take care of finding a working path inside the metro region.

Rich

> -----Original Message-----
> From: der Mouse [mailto:mouse@Rodents.Montreal.QC.CA]
> Sent: Friday, December 15, 2000 6:20 AM
> To: tcp-impl@grc.nasa.gov
> Subject: Multiple TCP source addresses?
> 
> 
> I've got a problem I'm trying to invent a solution to and I 
> thought I'd
> ask if there's any past work I should look at, or perhaps it's already
> been solved and I just don't know it.
> 
> Most of the hosts on my home LAN are multihomed; I have address space
> from two different places and I run both subnets over the same house
> Ethernet.  (Network interfaces are configured to have both addresses.)
> Sometimes one block of address space is reachable while the other one
> isn't, and outgoing packets are routed to one of two tunnels (one to
> each provider of address space) based on which subnet their source
> addresses fall into.
> 
> This all works well in normal circumstances.  The problem is with
> outgoing connections when one block of address space is 
> unreachable for
> some reason.  All the hosts have their default routes pointing to the
> off-LAN gateway, but I had to pick one of its two addresses, and the
> source address for the outgoing connection is always in the
> corresponding subnet.  When that subnet is unreachable from the
> destination host, outgoing connections fail even if I do have
> connectivity to that host via the other subnet.
> 
> I could deal with the case where a subnet goes completely unreachable
> with a routing protocol of some sort, perhaps.  But 
> reachability is not
> always all-or-nothing; depending on where the outage is, which hosts
> can reach which subnet varies.
> 
> So I'd like to do something so that outgoing connections for which the
> application has not specified a source address don't always try with
> one source address and give up if that doesn't work; conceptually, I'd
> like to try from all local addresses.  I was thinking of sending out
> multiple SYNs, one for each local address; as soon as one gets
> SYN-ACKed, that would commit the local address and SYN-ACKs for the
> others would draw RSTs.  It does occur to me that I may want 
> to do this
> round-robin among the addresses, rather than in bursts, to avoid
> creating unnecessary embryonic connections on the taget host in case
> both addresses work.  (Of course, they would be torn down quickly in
> response to the RST, but still.)
> 
> Comments?  Thoughts?  Prior art?
> 
> 					der Mouse
> 
> 			       mouse@rodents.montreal.qc.ca
> 		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> 


From owner-tcp-impl@lerc.nasa.gov  Mon Dec 18 15:04:33 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14324
	for <tcpimpl-archive@odin.ietf.org>; Mon, 18 Dec 2000 15:04:33 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA18934
	for tcp-impl-outgoing; Mon, 18 Dec 2000 12:36:08 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA18879
	for <tcp-impl@grc.nasa.gov>; Mon, 18 Dec 2000 12:36:05 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id MAA02606; Mon, 18 Dec 2000 12:36:02 -0500
Received: from persephone.cfrq.net(207.245.2.4) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma002522; Mon, 18 Dec 00 12:35:45 -0500
Received: from penelope.ve3tla.ampr.org (IDENT:root@cr1023351-a.ym1.on.wave.home.com [24.157.66.12])
	by persephone.cfrq.net (8.11.0/8.11.0) with ESMTP id eBIHZ9d24151;
	Mon, 18 Dec 2000 12:35:15 -0500
Received: from ve3tla.ampr.org (chk@localhost [127.0.0.1])
	by penelope.ve3tla.ampr.org (8.8.7/8.8.7) with ESMTP id MAA28331;
	Mon, 18 Dec 2000 12:34:56 -0500
Message-Id: <200012181734.MAA28331@ve3tla.ampr.org>
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses? 
References: <200012151803.NAA04141@Twig.Rodents.Montreal.QC.CA>
In-reply-to: Your message of "Fri, 15 Dec 2000 13:03:22 -0500".
	 <200012151803.NAA04141@Twig.Rodents.Montreal.QC.CA> 
From: Harald Koch <chk@pobox.com>
Date: Mon, 18 Dec 2000 12:34:56 -0500
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk

Of all the gin joints in all the towns in all the world, der Mouse
had to walk into mine and say:
> 
> How is a routing protocol supposed to deal with this?  Remember, my
> house LAN doesn't have its own AS.

In modern UNIX kernels, the TCP source address is chosen by doing a
routing table lookup, finding the *outgoing* interface, and using its
address.

If you run a dynamic routing protocol (even RIP will do with the right
configuration files), then you can set the default route based on which
gateway is up and/or primary.

If the primary gateway goes down, the default route will switch to the
other gateway. At that point, *new* connections will get the new source
IP address.

The details of "appropriate configuration files" are left as an exercise
to the reader; IIRC, both zebra and gated have a way to prefer one of
two equal-cost gateways; this would allow you to set the
primary/secondary gateway separately on each host on your LAN.


Now, if you wanted to still advertise one of your LAN address when its
gateway was down, *then* you'd need your own AS and a BGP connection to
each of your providers. For most situations, that's overkill; you can
handle it with multiple MX and IP address records in the DNS, for
example.

-- 
Harald Koch     <chk@pobox.com>

"It takes a child to raze a village."
		-Michael T. Fry


From owner-tcp-impl@lerc.nasa.gov  Mon Dec 18 15:49:41 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15206
	for <tcpimpl-archive@odin.ietf.org>; Mon, 18 Dec 2000 15:49:41 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA29914
	for tcp-impl-outgoing; Mon, 18 Dec 2000 13:44:13 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA29878
	for <tcp-impl@grc.nasa.gov>; Mon, 18 Dec 2000 13:44:10 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id NAA12333; Mon, 18 Dec 2000 13:44:09 -0500
Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma012271; Mon, 18 Dec 00 13:43:54 -0500
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA11322;
	Mon, 18 Dec 2000 13:43:45 -0500 (EST)
Date: Mon, 18 Dec 2000 13:43:45 -0500 (EST)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200012181843.NAA11322@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 8bit

>> How is a routing protocol supposed to deal with this?  Remember, my
>> house LAN doesn't have its own AS.

> If you run a dynamic routing protocol (even RIP will do with the
> right configuration files), then you can set the default route based
> on which gateway is up and/or primary.

Yes, if the failure were in my adjacent gateway or the link to it, this
would work.

But that wasn't the case.  I could reach my next-hop gateway just fine.
The point of lossage was a hop or two further away.

Also note that which route is correct depends on the host being
contacted; no single default route will do, and while I could perhaps
traceroute to each address from the other in order to determine where
the broken gateway is, I have no way of knowing enough topology to know
what hosts are on which side of it (and therefore can't install a bunch
of network routes for the smaller set of hosts).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From owner-tcp-impl@lerc.nasa.gov  Mon Dec 18 16:07:08 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15561
	for <tcpimpl-archive@odin.ietf.org>; Mon, 18 Dec 2000 16:07:08 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA02948
	for tcp-impl-outgoing; Mon, 18 Dec 2000 14:03:10 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA02899
	for <tcp-impl@grc.nasa.gov>; Mon, 18 Dec 2000 14:03:07 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id OAA15009; Mon, 18 Dec 2000 14:03:06 -0500
Received: from calcite.rhyolite.com(192.188.61.3) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma014760; Mon, 18 Dec 00 14:01:40 -0500
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.11.1/8.11.1) id eBIJ1cn18929
	for tcp-impl@grc.nasa.gov  env-from <vjs>;
	Mon, 18 Dec 2000 12:01:38 -0700 (MST)
Date: Mon, 18 Dec 2000 12:01:38 -0700 (MST)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200012181901.eBIJ1cn18929@calcite.rhyolite.com>
To: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk

> From: Harald Koch <chk@pobox.com>

> ...
> If you run a dynamic routing protocol (even RIP will do with the right
> configuration files), then you can set the default route based on which
> gateway is up and/or primary.
>
> If the primary gateway goes down, the default route will switch to the
> other gateway. At that point, *new* connections will get the new source
> IP address.
>
> The details of "appropriate configuration files" are left as an exercise
> to the reader; IIRC, both zebra and gated have a way to prefer one of
> two equal-cost gateways; this would allow you to set the
> primary/secondary gateway separately on each host on your LAN.

The `routed` daemon in several flavors of UNIX including FreeBSD, NetBSD,
and perhaps OpenBSD will do that by default for IPv4 using RIP, RIPv2,
and Router Discovery.

In flavors of UNIX that make it reasonable to tell whether the host's
Ethernet or other interface is alive (e.g. more packets received and sent
than errors), that `routed` pays attention to the state of interfaces.


Vernon Schryver    vjs@rhyolite.com


From owner-tcp-impl@lerc.nasa.gov  Wed Dec 20 02:42:04 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18552
	for <tcpimpl-archive@odin.ietf.org>; Wed, 20 Dec 2000 02:42:03 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA26213
	for tcp-impl-outgoing; Wed, 20 Dec 2000 00:36:49 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA26195
	for <tcp-impl@grc.nasa.gov>; Wed, 20 Dec 2000 00:36:47 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id AAA20654; Wed, 20 Dec 2000 00:36:46 -0500
Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma020614; Wed, 20 Dec 00 00:36:10 -0500
Received: from isi.edu (ink-i.isi.edu [128.9.102.4])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id VAA29760;
	Tue, 19 Dec 2000 21:35:24 -0800 (PST)
Message-ID: <3A404230.F9B0A78C@isi.edu>
Date: Tue, 19 Dec 2000 21:22:56 -0800
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Harald Koch <chk@pobox.com>
CC: der Mouse <mouse@Rodents.Montreal.QC.CA>, tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
References: <200012151803.NAA04141@Twig.Rodents.Montreal.QC.CA> <200012181734.MAA28331@ve3tla.ampr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 7bit



Harald Koch wrote:
> 
> Of all the gin joints in all the towns in all the world, der Mouse
> had to walk into mine and say:
> >
> > How is a routing protocol supposed to deal with this?  Remember, my
> > house LAN doesn't have its own AS.
> 
> In modern UNIX kernels, the TCP source address is chosen by doing a
> routing table lookup, finding the *outgoing* interface, and using its
> address.
> 
> If you run a dynamic routing protocol (even RIP will do with the right
> configuration files), then you can set the default route based on which
> gateway is up and/or primary.
> 
> If the primary gateway goes down, the default route will switch to the
> other gateway. At that point, *new* connections will get the new source
> IP address.
> 
> The details of "appropriate configuration files" are left as an exercise
> to the reader; IIRC, both zebra and gated have a way to prefer one of
> two equal-cost gateways; this would allow you to set the
> primary/secondary gateway separately on each host on your LAN.

See the appendix of:


http://www.isi.edu/touch/pubs/icnp97/



> 
> Now, if you wanted to still advertise one of your LAN address when its
> gateway was down, *then* you'd need your own AS and a BGP connection to
> each of your providers. For most situations, that's overkill; you can
> handle it with multiple MX and IP address records in the DNS, for
> example.
> 
> --
> Harald Koch     <chk@pobox.com>
> 
> "It takes a child to raze a village."
>                 -Michael T. Fry


From owner-tcp-impl@lerc.nasa.gov  Wed Dec 20 02:42:12 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18563
	for <tcpimpl-archive@odin.ietf.org>; Wed, 20 Dec 2000 02:42:12 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA26364
	for tcp-impl-outgoing; Wed, 20 Dec 2000 00:39:53 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA26347
	for <tcp-impl@grc.nasa.gov>; Wed, 20 Dec 2000 00:39:50 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id AAA20882; Wed, 20 Dec 2000 00:39:49 -0500
Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma020853; Wed, 20 Dec 00 00:39:33 -0500
Received: from isi.edu (ink-i.isi.edu [128.9.102.4])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id VAA29929;
	Tue, 19 Dec 2000 21:39:26 -0800 (PST)
Message-ID: <3A404322.76B386F2@isi.edu>
Date: Tue, 19 Dec 2000 21:26:58 -0800
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Harald Koch <chk@pobox.com>
CC: der Mouse <mouse@Rodents.Montreal.QC.CA>, tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
References: <200012151803.NAA04141@Twig.Rodents.Montreal.QC.CA> <200012181734.MAA28331@ve3tla.ampr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 7bit



Harald Koch wrote:
> 
> Of all the gin joints in all the towns in all the world, der Mouse
> had to walk into mine and say:
> >
> > How is a routing protocol supposed to deal with this?  Remember, my
> > house LAN doesn't have its own AS.
> 
> In modern UNIX kernels, the TCP source address is chosen by doing a
> routing table lookup, finding the *outgoing* interface, and using its
> address.

Which is not always the best answer. Esp. if the interface has aliases.

> If you run a dynamic routing protocol (even RIP will do with the right
> configuration files), then you can set the default route based on which
> gateway is up and/or primary.
> 
> If the primary gateway goes down, the default route will switch to the
> other gateway. At that point, *new* connections will get the new source
> IP address.
> 
> The details of "appropriate configuration files" are left as an exercise
> to the reader; IIRC, both zebra and gated have a way to prefer one of
> two equal-cost gateways; this would allow you to set the
> primary/secondary gateway separately on each host on your LAN.

See the appendix of:

"Dynamic Host Routing for Production Use of Developmental Networks"
J. Touch and T. Faber, Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292. 
http://www.isi.edu/touch/pubs/icnp97/

> Now, if you wanted to still advertise one of your LAN address when its
> gateway was down, *then* you'd need your own AS and a BGP connection to
> each of your providers. For most situations, that's overkill; you can
> handle it with multiple MX and IP address records in the DNS, for
> example.

But in that case, there's no control over which IP address is used.

Joe


From owner-tcp-impl@lerc.nasa.gov  Wed Dec 20 07:56:44 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22123
	for <tcpimpl-archive@odin.ietf.org>; Wed, 20 Dec 2000 07:56:43 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA13816
	for tcp-impl-outgoing; Wed, 20 Dec 2000 06:08:29 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA13699
	for <tcp-impl@grc.nasa.gov>; Wed, 20 Dec 2000 06:08:26 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id GAA20975; Wed, 20 Dec 2000 06:08:22 -0500
Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma020901; Wed, 20 Dec 00 06:07:35 -0500
Received: from regan.ee.surrey.ac.uk ([131.227.89.11])
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 148h4y-0006VY-00; Wed, 20 Dec 2000 11:06:40 +0000
Date: Wed, 20 Dec 2000 11:06:21 +0000 (GMT)
From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
X-Sender: eep1lw@regan.ee.surrey.ac.uk
Reply-To: L.Wood@eim.surrey.ac.uk
To: Joe Touch <touch@ISI.EDU>
cc: Harald Koch <chk@pobox.com>, der Mouse <mouse@Rodents.Montreal.QC.CA>,
        tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
In-Reply-To: <3A404322.76B386F2@isi.edu>
Message-ID: <Pine.GSO.4.21.0012201105210.12597-100000@regan.ee.surrey.ac.uk>
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk

On Tue, 19 Dec 2000, Joe Touch wrote:

> > The details of "appropriate configuration files" are left as an exercise
> > to the reader; IIRC, both zebra and gated have a way to prefer one of
> > two equal-cost gateways; this would allow you to set the
> > primary/secondary gateway separately on each host on your LAN.
> 
> See the appendix of:
> 
> "Dynamic Host Routing for Production Use of Developmental Networks"
> J. Touch and T. Faber, Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292. 
> http://www.isi.edu/touch/pubs/icnp97/

Not Found

The requested object does not exist on this server. The link you
followed is either outdated, inaccurate, or the server has been
instructed not to let you have it. Please inform the site
administrator of the referring page.

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>



From owner-tcp-impl@lerc.nasa.gov  Wed Dec 20 14:55:40 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12738
	for <tcpimpl-archive@odin.ietf.org>; Wed, 20 Dec 2000 14:55:39 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA09623
	for tcp-impl-outgoing; Wed, 20 Dec 2000 12:17:35 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA09591
	for <tcp-impl@grc.nasa.gov>; Wed, 20 Dec 2000 12:17:33 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id MAA10025; Wed, 20 Dec 2000 12:17:30 -0500
Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma009951; Wed, 20 Dec 00 12:17:16 -0500
Received: from isi.edu (sci.isi.edu [128.9.160.93])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA29132;
	Wed, 20 Dec 2000 09:17:13 -0800 (PST)
Message-ID: <3A40E94B.22614109@isi.edu>
Date: Wed, 20 Dec 2000 09:15:55 -0800
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Vernon Schryver <vjs@calcite.rhyolite.com>
CC: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
References: <200012181901.eBIJ1cn18929@calcite.rhyolite.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 7bit



Vernon Schryver wrote:
> 
> > From: Harald Koch <chk@pobox.com>
> 
> > ...
> > If you run a dynamic routing protocol (even RIP will do with the right
> > configuration files), then you can set the default route based on which
> > gateway is up and/or primary.
> >
> > If the primary gateway goes down, the default route will switch to the
> > other gateway. At that point, *new* connections will get the new source
> > IP address.
> >
> > The details of "appropriate configuration files" are left as an exercise
> > to the reader; IIRC, both zebra and gated have a way to prefer one of
> > two equal-cost gateways; this would allow you to set the
> > primary/secondary gateway separately on each host on your LAN.
> 
> The `routed` daemon in several flavors of UNIX including FreeBSD, NetBSD,
> and perhaps OpenBSD will do that by default for IPv4 using RIP, RIPv2,
> and Router Discovery.
> 
> In flavors of UNIX that make it reasonable to tell whether the host's
> Ethernet or other interface is alive (e.g. more packets received and sent
> than errors), that `routed` pays attention to the state of interfaces.
> 
> Vernon Schryver    vjs@rhyolite.com

That works only if your interface is UP or DOWN. If it's malfunctioning
or there's a break somewhere else in the LAN (e.g., on the next wire in
a switched ethernet), there's no indication.

It's even worse if you can receive but not send. In that case,
you get RIP announcements and set your route accordingly, but
the packets drop on the floor...

(it would be nice if there were a version that at least tests next-hop 
connectivity in the forward case after receiving an announcement - is
there one that does this??)

Joe


From owner-tcp-impl@lerc.nasa.gov  Wed Dec 20 15:44:26 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14277
	for <tcpimpl-archive@odin.ietf.org>; Wed, 20 Dec 2000 15:44:25 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA15529
	for tcp-impl-outgoing; Wed, 20 Dec 2000 12:57:52 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA15512
	for <tcp-impl@grc.nasa.gov>; Wed, 20 Dec 2000 12:57:49 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id MAA16084; Wed, 20 Dec 2000 12:57:47 -0500
Received: from calcite.rhyolite.com(192.188.61.3) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma016020; Wed, 20 Dec 00 12:57:31 -0500
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.11.1/8.11.1) id eBKHvTe29972
	for tcp-impl@grc.nasa.gov  env-from <vjs>;
	Wed, 20 Dec 2000 10:57:29 -0700 (MST)
Date: Wed, 20 Dec 2000 10:57:29 -0700 (MST)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200012201757.eBKHvTe29972@calcite.rhyolite.com>
To: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk

> From: Joe Touch <touch@ISI.EDU>

> ...
> > In flavors of UNIX that make it reasonable to tell whether the host's
> > Ethernet or other interface is alive (e.g. more packets received and sent
> > than errors), that `routed` pays attention to the state of interfaces.

> That works only if your interface is UP or DOWN. If it's malfunctioning
> or there's a break somewhere else in the LAN (e.g., on the next wire in
> a switched ethernet), there's no indication.

On the contrary, what I wrote is accurate, based not only on my own testing
of my code, but the quieting of some bug reports and other complaints.
Flavors of UNIX that support the 4.4BSD style interface statistics and
that do a reasonable job of noticing errors do talk to my version of
`routed` and cause it to do the obvious right things, which in some cases
includes switching the interface between UP and DOWN.  Of course, it is
not a panacea.


> It's even worse if you can receive but not send. In that case,
> you get RIP announcements and set your route accordingly, but
> the packets drop on the floor...

Ethernet drivers that notice missing 10BASE-T and 100BASE-T heartbeats or
coax no-carrier errors such as are cause by partially disconnected cables
cause my `routed` to do the right thing.  Of course, while those are the
most common causes of receive-but-not-send, there are other causes.


> (it would be nice if there were a version that at least tests next-hop 
> connectivity in the forward case after receiving an announcement - is
> there one that does this??)

That would be hard in RIP, RIPv2, or Router Discovery, although you might
glue some periodic thing with ICMP on the outside.

Blackholes have always been hassles, which may be why they're
mentioned so often in RFC's.


Vernon Schryver    vjs@rhyolite.com


From owner-tcp-impl@lerc.nasa.gov  Wed Dec 20 18:47:44 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19765
	for <tcpimpl-archive@odin.ietf.org>; Wed, 20 Dec 2000 18:47:44 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA23831
	for tcp-impl-outgoing; Wed, 20 Dec 2000 16:50:24 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA23801
	for <tcp-impl@grc.nasa.gov>; Wed, 20 Dec 2000 16:50:21 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id QAA22525; Wed, 20 Dec 2000 16:50:21 -0500
Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma022410; Wed, 20 Dec 00 16:49:49 -0500
Received: from isi.edu (sci.isi.edu [128.9.160.93])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id NAA02637;
	Wed, 20 Dec 2000 13:49:45 -0800 (PST)
Message-ID: <3A412973.C3553710@isi.edu>
Date: Wed, 20 Dec 2000 13:49:39 -0800
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Vernon Schryver <vjs@calcite.rhyolite.com>
CC: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
References: <200012201757.eBKHvTe29972@calcite.rhyolite.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 7bit



Vernon Schryver wrote:
> 
> > From: Joe Touch <touch@ISI.EDU>
> 
> > ...
> > > In flavors of UNIX that make it reasonable to tell whether the host's
> > > Ethernet or other interface is alive (e.g. more packets received and sent
> > > than errors), that `routed` pays attention to the state of interfaces.
> 
> > That works only if your interface is UP or DOWN. If it's malfunctioning
> > or there's a break somewhere else in the LAN (e.g., on the next wire in
> > a switched ethernet), there's no indication.
> 
> On the contrary, what I wrote is accurate, based not only on my own testing
> of my code, but the quieting of some bug reports and other complaints.

Only if sent-on-the-floor is recorded as an error. There are
cases where it is not. Ethernet isn't one of these, as you note
later in your reply, but there are others (esp. wireless).

Joe


From owner-tcp-impl@lerc.nasa.gov  Thu Dec 21 02:17:57 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12903
	for <tcpimpl-archive@odin.ietf.org>; Thu, 21 Dec 2000 02:17:56 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA22355
	for tcp-impl-outgoing; Thu, 21 Dec 2000 00:27:27 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA22345
	for <tcp-impl@grc.nasa.gov>; Thu, 21 Dec 2000 00:27:26 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id AAA09282; Thu, 21 Dec 2000 00:27:25 -0500
Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma009256; Thu, 21 Dec 00 00:27:10 -0500
Received: (from mouse@localhost)
	by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA18074;
	Thu, 21 Dec 2000 00:27:07 -0500 (EST)
Date: Thu, 21 Dec 2000 00:27:07 -0500 (EST)
From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200012210527.AAA18074@Twig.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 8bit

>>> That works only if your interface is UP or DOWN.  If it's
>>> malfunctioning or there's a break somewhere else in the LAN (e.g.,
>>> on the next wire in a switched ethernet), there's no indication.
>> On the contrary, what I wrote is accurate, based [...]
> Only if sent-on-the-floor is recorded as an error.  There are cases
> where it is not.  Ethernet isn't one of these, as you note later in
> your reply, but there are others (esp. wireless).

Actually, Ethernet *doesn't* notice sent-on-the-floor, provided you've
got an appropriate arp entry (eg, wired in, or not yet timed out).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From owner-tcp-impl@lerc.nasa.gov  Thu Dec 21 15:24:43 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29563
	for <tcpimpl-archive@odin.ietf.org>; Thu, 21 Dec 2000 15:24:42 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA07287
	for tcp-impl-outgoing; Thu, 21 Dec 2000 13:21:22 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA07263
	for <tcp-impl@grc.nasa.gov>; Thu, 21 Dec 2000 13:21:20 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id NAA06624; Thu, 21 Dec 2000 13:21:19 -0500
Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma006523; Thu, 21 Dec 00 13:21:03 -0500
Received: from isi.edu (sci.isi.edu [128.9.160.93])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA04834;
	Thu, 21 Dec 2000 10:19:31 -0800 (PST)
Message-ID: <3A4249AA.D98F441@isi.edu>
Date: Thu, 21 Dec 2000 10:19:22 -0800
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
CC: tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
References: <200012210527.AAA18074@Twig.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 7bit



der Mouse wrote:
> 
> >>> That works only if your interface is UP or DOWN.  If it's
> >>> malfunctioning or there's a break somewhere else in the LAN (e.g.,
> >>> on the next wire in a switched ethernet), there's no indication.
> >> On the contrary, what I wrote is accurate, based [...]
> > Only if sent-on-the-floor is recorded as an error.  There are cases
> > where it is not.  Ethernet isn't one of these, as you note later in
> > your reply, but there are others (esp. wireless).
> 
> Actually, Ethernet *doesn't* notice sent-on-the-floor, provided you've
> got an appropriate arp entry (eg, wired in, or not yet timed out).

If you keep sending, wouldn't it fail to timeout?
(e.g., UDP streams)

Joe


From owner-tcp-impl@lerc.nasa.gov  Thu Dec 21 16:01:08 2000
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00721
	for <tcpimpl-archive@odin.ietf.org>; Thu, 21 Dec 2000 16:01:08 -0500 (EST)
Received: (from listserv@localhost)
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA14284
	for tcp-impl-outgoing; Thu, 21 Dec 2000 13:56:43 -0500 (EST)
Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12])
	by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA14236
	for <tcp-impl@grc.nasa.gov>; Thu, 21 Dec 2000 13:56:39 -0500 (EST)
Received: by seraph3.lerc.nasa.gov; id NAA11820; Thu, 21 Dec 2000 13:56:38 -0500
Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5)
	id xma011625; Thu, 21 Dec 00 13:55:21 -0500
Received: from isi.edu (sci.isi.edu [128.9.160.93])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA09540;
	Thu, 21 Dec 2000 10:53:40 -0800 (PST)
Message-ID: <3A4251AB.E472912F@isi.edu>
Date: Thu, 21 Dec 2000 10:53:31 -0800
From: Joe Touch <touch@ISI.EDU>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: L.Wood@eim.surrey.ac.uk
CC: Harald Koch <chk@pobox.com>, der Mouse <mouse@Rodents.Montreal.QC.CA>,
        tcp-impl@grc.nasa.gov
Subject: Re: Multiple TCP source addresses?
References: <Pine.GSO.4.21.0012201105210.12597-100000@regan.ee.surrey.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Content-Transfer-Encoding: 7bit



Lloyd Wood wrote:
> 
> On Tue, 19 Dec 2000, Joe Touch wrote:
> 
> > > The details of "appropriate configuration files" are left as an exercise
> > > to the reader; IIRC, both zebra and gated have a way to prefer one of
> > > two equal-cost gateways; this would allow you to set the
> > > primary/secondary gateway separately on each host on your LAN.
> >
> > See the appendix of:
> >
> > "Dynamic Host Routing for Production Use of Developmental Networks"
> > J. Touch and T. Faber, Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292.
> > http://www.isi.edu/touch/pubs/icnp97/
> 
> Not Found

I thought there was something missing from the URL:

http://www.isi.edu/touch/pubs/icnp97/icnp97.ps

Joe