It occurred to me that Hubert Feyrer wrote in gmane.os.netbsd.devel.network:
> On Sat, 7 Jan 2006, Jonathan A. Kollasch wrote:
>> is on 3.0/macppc if that makes any difference.  Is there a way to
>> get stf(4) to decapsulate *all* protocol 41 packets, and base
>> everything on the internal destination address?
>
> I have no idea.
>
> But...
> if I were a stf proccessing unit, and would get a 6to4 packet for an IPv4 
> address on an interface where that IPv4 address is not assigned, I'd 
> probably start wondering (and possibly drop that packet).

It doesn't. It seems it'll get forwarded to the interface that *does* know
how to deal with it.

I have a similiar - but not identical - setup as the OP, except for the fact
that my modem casually 'forgets' to do the NATing, even though it should
(and even though it's instructed to do so). I have a stupid modem which
cannot handle either gif or stf[1] tunnels, and which I cannot put into
bridging mode, so I configured it to forward all incoming data to 192.168.5.2,
the private IP of my NetBSD machine. Apperently, the modem doesn't know what
to do with the proto 41 traffic, and forwards it entirely, without even
rewriting the IPv4 container, to the specified MACaddress.

So right now, gif-packets are coming in on my external interface - which has
not been assigned my public IP. Instead, I gave that address as an alias to 
lo0. Likewise, I set my gif0 endpoint at my public address. And that Just
Worked. TM. 

I've been playing with stf on this same machine as well, and it started 
working once I assigned the alias to lo0 - not to my external interface.  
I didn't need any BINAT rules, but that's probably because my modem is
so braindead. Apperently, it sees no harm in forwarding traffic with its own
outside address from the inside to the outside, as long as it's a packet
type it doesn't know how to handle. If I assign the alias to my outside
address, my outgoing packets would have the wrong source address - it would
get the 'official' address of my external interface, not the alias I assigned
to it.

I'll immediately admit that it's a dirty hack, and that the fact that it
works is more a result of the implementation than of the design, but the
point is that apperently stf and gif are happy. They see an interface with
the address they're expecting, and all outgoing traffic they generate
apperently automagically gets routed through my public interface, using the
correct address.

For completeness' sake: My ifconfig of the relevant interfaces lists:


rtk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:50:fc:f0:60:58
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 192.168.5.2 netmask 0xffffff00 broadcast 192.168.5.255
        inet6 fe80::250:fcff:fef0:6058%rtk0 prefixlen 64 scopeid 0x3
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33192
        inet 127.0.0.1 netmask 0xff000000
        inet alias 85.145.84.197 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet6 2001:610:1108:5220:250:fcff:fef0:6058 prefixlen 64
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        tunnel inet 85.145.84.197 --> 131.155.141.2
        inet6 2001:610:1108:5001::3f ->  prefixlen 64
        inet6 fe80::240:f4ff:fece:5b43%gif0 ->  prefixlen 64 scopeid 0x5

IPv4 default route is to 192.168.5.1, which is my modem.

[1] I seem to recall that gif and stf are remarkably the same, as far as the
    actual ipv6-in-ipv4 containment is concerned.
-- 
    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