It occurred to me that Ignatios Souvatzis wrote in
gmane.os.netbsd.devel.network:
> Caution - rant follows.
>
>|"Slightly dodgy"? Your network setup is so sick that I wonder how your
>|machines survive. Do you understand know why reasonable people frown upon
>|NAT?

Rant utterly ignored. As much as I'd love not to use NAT, I have no choice
in this matter, as my provider-supplied modem forces it on me. If I would've
known that getting a third-party modem would magically fix it, I'd be running
out of the door as we speak, but:

1) It is NOT related to the problem at hand (As I managed to reproduce the
   problem on a local network, no NATting involved)
2) I've read too many bad reports from people trying to replace their modem,
   only to find out that their connection stopped working.

Yes, it's nasty. I consider myself a reasonable person. Yes, I know it's a
possible cause of problems, but I'm *convinced* it's not the culprit here. And
yes, I guess I could fix it by getting a slower ADSL connection for more money,
using a provider which doesn't hand out crippled modems, but which suffers from
unreliable connections instead. Thank you, I think I'll pass.

> Ok, seriously now:
>
> Adding 85.145.84.197 to your _ethernet_ interface should work. 

Should, but didn't (at least in the past, in case of an stf tunnel. Outgoing
stf packets would get the wrong source IP)

> Somehow you have to convince your machine to accept that packet in the first
> place, before gif can see it.

_gif sees the packets_. I can see packets leaving the gif (tcpdump on the
ethernet interface). They arrive at the remote end. I can see packets entering
the gif (tcpdump on both the gif, as well as the ethernet interface).

Oh, and a gif tunnel tunneling IPv4 traffic works like a charm. But if I 
try to tunnel IPv6 traffic through the very same tunnel (which works for ipv4),
it does not work for IPv6. But it will continue working for IPv4.

[snip]

> Maybe you need to switch routing on for this to work.
>
> Oh, yes, did you swithc routing on? (What does
> sysctl net.inet.ip.forwarding say?)

yes. The machine is doing NAT itself (Yeah, I feel another rant coming on)
for my Windows desktop, my laptop, and whatever other hardware I feel like
connecting, and it's routing my IPv6 range.

And this has been working for *quite a while*. It mysteriously stopped working
last week, and I can "fix" it by putting last weeks kernel back in. Obviously,
this is no solution, but doesn't it at least indicate that the scope6 changes
committed last week *ARE* possibly involved?  Why people refuse to even
*consider* that there's something odd with -current's gif is beyond me.

Like I said in another mail, I managed to reproduce it on my local network,
no NATting involved. An ipv6 gif tunnel between -current and 3.0 is just
*not working right*. Traffic is entering and leaving, from both sides, but
neither side feels like responding to it. If I boot last week's current, it
works.  I'll compile a -current kernel for my laptop, and see what that brings.
Heck, I'll even install FreeBSD and NetBSD/i386 if that makes you happy. 

Kind regards,

Martijn.

-- 
    Martijn van Buul - pino@dohd.org - http://www.stack.nl/~martijnb/
	 Geek code: G--  - Visit OuterSpace: mud.stack.nl 3333
 The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac Asimov