Subject: Re: IPv6 capable tun
To: Michael Richardson <email@example.com>
From: None <firstname.lastname@example.org>
Date: 01/09/2001 00:17:04
> >> I understand that one reason why tun0 does not support IPv6 is that
> >> it does not support multicast. I can live without neighbour discovery
> >> messages and stuff, and I think I have the right code otherwise.
> >> Are there other downsides of setting IF_MULTICAST on the tun interface?
> >> I've sent a PR on this.
for IFF_MULTICAST, I believe we need to have proper multicast group
management code in tunioctl().
> itojun> what did you do about TUN_PREPADDR (TUNSLMODE)?
> On ingress (data written to tun0), one prepends a sockaddr of some kind. The
>only use of this is to determine the addressing family (e.g. which queue to
>use). I extended the switch statement to look for AF_INET6. If you aren't
>in TUNSLMODE, then I peek at the first bype to see of it is 0x4x or 0x6x.
> On egress, the destination address is again a sockaddr, so it does the
>right thing. I haven't tested with TUNSLMODE yet. I should probably be using
>it for my protocol.
> The situation that I don't know how to deal with is the BPF case.
BPF cases should be okay if we prepend AF_INET6.
> Two questions:
> 1) if peeing the header is the right thing to do, is this the right way to
> do it?
> 2) tun0 seems to assume that things were IPv4. Why would assuming IP be any
> worse than what we had before?
> I realize that many people want a more general tunnel device.
i'd mandate TUN_PREPADDR (set it to always on), not sure if it is
okay with applications.
another issue - there's no compatibility between *BSD, regarding to
packet encoding on character device side...