[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
How to configure a tunnel
- Subject: How to configure a tunnel
- From: [email protected] (Masaki Hirabaru)
- Date: Tue, 06 Aug 1996 20:17:10 -0400
- In-reply-to: Your message of "Tue, 30 Jul 1996 19:06:09 +0900." <[email protected]>
I wrote this a couple of days ago, but it seems I've forgot to
> Gee. Why don't you, a member of WIDE project, use one of WIDE
> implementations? Actually Nara implementation provides a good
I personally tried. You may remember I asked you. Our main
purpose is to implement ipv6 routing protocols, currently working
on ripng, so we'll use an ipv6 kernel which provides functions we
need. INRIA version is almost enough. I tried Solaris one, but I
need to wait its next release due to luck of setsockopt extension
for ipv6 multicasting, although their ripng is working on solaris.
To implement ripng, we need,
o Basic Socket Interface Extensions for IPv6 defined in the draft,
o ipv6 extension to socket ioctl's to obtain interface info,
o ipv6 extension to access method to kernel resident routing table,
o ipv6 link-local multicasting and related setsockopt functions, and
o handling link-local addresses properly with Neighbor Discovery
even in case of multiple ethernet interfaces.
Ripng on solaris sends an update packet with a global ipv6
address as its source, and our current implementation does so.
Ripng ID says that a link-local address must be used. So,
capability to bind a socket with a link-local address will be
needed. And also, the routing daemon wants to identify the
incoming interface even for packets with a link-local source
address. Neighbor Discovery may be able to ask all the interfaces
where that link-local address is on (although the cache may
answer). I know INRIA version does well in part.
When these become available on your implementation, I'd like to
try it. Thanks.