Subject: Re: ipip and gif
To: None <tech-net@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-net
Date: 04/19/2000 15:05:51
[ On Wednesday, April 19, 2000 at 13:42:16 (-0400), der Mouse wrote: ]
> Subject: Re: ipip and gif
>
> No, though that is a problem - when a host trying to do MTU discovery
> is behind such a misconfigured router, communication breaks down.  I've
> tried writing to a few such; so far I've gotten only one response, from
> a site saying "we used to but then we fixed it because of exactly the
> problem you bring up - I don't know why you're still having trouble".
> I offered to do what I could to help track down the problem, but never
> got a reply to that.
> 
> No, the reasons I couldn't use existing tunnel code were:
> 
> - One of the inner tunnel addresses (my home end) is liable to change
>    with no warning; somehow this has to be communicated to the other
>    end so it knows where to send packets.

"outer", no?  I.e. the address of the PPP interface or whatever....

In any case I'd rather do these sorts of control functions done in
user-land.  I.e. I'd have an "out-of-tunnel" communications channel open
permanently to the remote host to handle this sort of thing.  Then when
you're about to release your currently assigned address you use this
channel to tell the other end that you're shutting down the tunnel
temporarily and then once you have the new address assigned and running
you open a new control channel to contact the remote host and ask it to
re-open the tunnel using the new outer interface address at your end.

The tunnel monitor could also run a keep-alive packet over the control
channel and if it breaks then the tunnel inside interfaces could be
marked down to prevent sending packets to whomever might be assigned the
current address in case the link is down on the dynamic line and it gets
re-assigned by the provider.

> - There are actually two tunnels, decision between which is made based
>    on the *source* address of the packet.  (For example, 132.206.78.3
>    and 216.46.5.3 are the same machine; if an outgoing packet has
>    source address 132.206.78.3 it goes down one tunnel, whereas if it
>    has source address 216.46.5.3 it goes down the other.)

Hmmm....  I've had several more generic needs for routing based on the
source address in the past....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>