lkml.org 
[lkml]   [1997]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: IPIP Tunnelling.
Date
From

alan@lxorguk.ukuu.org.uk said:
> A tunnel should be placing the output device as the encapsulating
> address for the tunnel.

Or, as RFC2003 puts it:
> The fields in the outer IP header are set by the encapsulator as
> follows:
<...>
>
> Source Address
>
> The IP address of the encapsulator, that is, the tunnel entry
> point.

Has anyone done any work on ICMP handling for the tunnel driver?

alan@lxorguk.ukuu.org.uk said:
>>> Another thing I'd like to do is add IPIP compression to the tunnel
>>> driver. What's the best way to go about it?
>> I believe you need to invent new protocol and register it to avoid
>> conflicts :-)

Someone beat me to it :)

> Another option is to implement L2F/PPTP.

Or even IPPCP - which is almost precisely what I'm after. The only bit I'm not
too happy about with IPPCP is the negotiation using ISAKMP. However, as things
like IPsec are appearing in the kernel, I hope^H^H^H^Hsuppose someone's
already working on that - can anyone confirm this?

If I'm going to use IPPCP, I'll put together a driver without the negotiation,
which needs the compression type setting manually, but has hooks for proper
ISAKMP configuration when it's complete. Does that sound like the right way to
proceed?

/* IPPCP: IP Payload Compression Protocol
* ftp://ietf.org/internet-drafts/draft-ietf-ippcp-protocol-00.txt
*/






--
David Woodhouse, CB3 9AN http://dwmw2.robinson.cam.ac.uk/
dwmw2@cam.ac.uk Tel: 0976 658355
D.W.Woodhouse@nortel.co.uk Tel: 01279 402332



\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.067 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site