>    >> 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...

itojun