Well, I'm screwed.
I set up the Linksys router so that the FreeBSD machine is the "DMZ"
host on the inside. Sending 6to4 to the router's outside address
results in tcpdump showing these on the inside:
22:09:36.138924 [linksys mac address] > ff:ff:ff:ff:ff:ff, ethertype
ARP (0x0806), length 60: arp who-has [linksys outside ip] tell [linksys
Which, quite frankly, is laughable. If that weren't enough, the packets
come out of the linksys router with the source IP address being from
the inside (meaning, it didn't get NATted). Humph.
So it appears that for now, I will have to keep a 2nd interface active
on this box solely for the purpose of doing IPv6. What a nightmare.
On Mar 11, 2005, at 4:38 PM, Nick Sayer wrote:
> Hajimu UMEMOTO wrote:
>> I posted my proposed patch to current@ for review in the past. But,
>> no one responded. Could you test this? This is for 6-CURRENT at Feb
>> If it doesn't apply cleanly, please let me know.
> Domo arigato gozaimasu!
> It had fuzz when applied to 5.3-RELEASE, but it did apply.
> I am at work, behind the wrong firewall, so I cannot test this
> completely, but with your patch applied and turned on, I can see that
> configuring my machine (which lives in 172.16 space) with a "foreign"
> 6to4 prefix on stf0 results in ping6 packets being transmitted
> correctly (tcpdump shows a correct ipv6 packet and shows an ipv4
> header with the packet being from my 172.16 machine and going to the
> correct destination). I have high hopes that the return side will work
> when it's deployed for real.
> email@example.com mailing list
> To unsubscribe, send any mail to