For mail anti-spam techniques I would probably block it as well, but for a non-sensitive web service I don't know that I would personally worry about it that much.

Answering a question with a question admittedly, but why deny the connection?  I doubt I would ever intentionally configure a host to use such an address, and I'm not an expert, but I can't think of any reason why it would be invalid or really advantageous to block the connection.

The NXDOMAIN response should not be cached for that long, most servers that actually cache that response usually expire it after 2 hours.

If the rDNS servers are entered for the tunnel, then you probably want to go ahead and open up a ticket by sending an e-mail to ipv6@he.net.  From what I can see here, it does not appear the rDNS delegation is in effect.

Code:

dig 8.0.1.d.0.7.4.0.1.0.0.2.ip6.arpa

; <<>> DiG 9.4.2-P1 <<>> 8.0.1.d.0.7.4.0.1.0.0.2.ip6.arpa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25624
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;8.0.1.d.0.7.4.0.1.0.0.2.ip6.arpa. IN   A

;; AUTHORITY SECTION:
d.0.7.4.0.1.0.0.2.ip6.arpa. 900 IN      SOA     ns1.he.net. hostmaster.he.net. 2008082107 10800 1800 604800 86400

;; Query time: 61 msec
;; SERVER: 68.87.74.162#53(68.87.74.162)
;; WHEN: Thu Aug 21 13:07:03 2008
;; MSG SIZE  rcvd: 107

Actually, you're doing better than most - the router method is a bit more complex.  The ifconfig results would definitely be helpful, but my bet without seeing it is that the br0 interface does not have a real IPv6 address (2001:470...) which is why it cannot forward the packet from the br0 interface to the he-ipv6 interface.  You can also try the ping or ping6 from the router and see if that works to help verify.  Based on your ipconfig results, yes, radvd has setup the route.

Your Windows XP computer should not be in the DMZ unless there is a specific reason to do so unrelated to IPv6.  If your goal is still to have the router be your IPv6 endpoint, the first thing I would do is remove the Windows XP machine from the DMZ and remove any configuration you did on the Windows XP box to try and obtain IPv6 connectivity other than installing the Microsoft IPv6 protocol stack, then reboot the XP machine.  Since you're using radvd on the router, you will not need to make any configuration changes to either the XP machine or the laptop other than loading the Microsoft IPv6 protocol stack in order to obtain basic IPv6 connectivity. 

I am more familiar with OpenWRT than I am DD-WRT, but here are some basic thoughts.  It looks like br0 is your bridge which I presume is your lan and from the web site you copied instructions to create a new tunnel interface called he-ipv6.  From the commands you entered you have created an IPv6 tunnel on he-ipv6 and assigned it an address of 2001:470:1f06:74d::2/64.  Which is good.  Have you added an ipv6 address to your br0 interface from your delegated /64 of 2001:470:1f07 ?  If DD-WRT supports shell access or running commands, it would be helpful to see the results of the ifconfig from the router. 

To answer your radvd question directly, you can use radvdump if installed on the router to see when radvd sends advertisements to the network.  Radvd only sends announcements periodically, so it may take a while for one to show up.  The format from the dump is similar to the configuration but also includes the default parameters.  From the configuration you posted, I would remove the MTU entry and the Base6to4Interface entry which is for a 6to4 setup.

You're trying to set up rDNS on the transit 1f0a prefix rather than the routed 1f0b prefix.  On the afraid.org web site, you want to use the routed /64 which is 2001:0470:1f0b:6f2 and set your computers to use addresses from the 2001:0470:1f0b prefix where rDNS is a concern. 

sysctl -w will only write the values to the current running kernel, after the next reboot the options will be back to their default values.  Depending on your distribution, you will need to add or modify the options in /etc/sysctl.conf or perform the adjustments through an init script.

Not an answer, but a little more information in case someone else runs in to this situation.  It would seem that the default configuration of K/Ubuntu 8.04 is the source of this issue.  The host in question was upgraded via fresh install from Ubuntu 7.10 to Ubuntu 8.04 about a month before the tunnel was switched and I probably did not try to do a trace route from the host during that period to realize it was no longer working.  I have since restaged the host to openSuSE for other reasons and it does not exhibit the problem, however another workstation that is running Kubuntu 8.04 is still exhibiting the problem.

Similar routing is also seen from Comcast. 

traceroute to 209.51.161.58 (209.51.161.58), 30 hops max, 40 byte packets
 1  c-76-108-48-1.hsd1.fl.comcast.net (76.108.48.1)  9.267 ms  9.230 ms  9.080 ms
 2  ge-1-1-ur01.boynton.fl.pompano.comcast.net (68.85.230.145)  8.880 ms  8.808 ms  8.743 ms
 3  te-8-1-ur01.lakeworth.fl.pompano.comcast.net (68.86.165.174)  8.870 ms  9.312 ms  9.311 ms
 4  te-8-2-ur02.lakeworth.fl.pompano.comcast.net (68.86.165.178)  9.245 ms  9.180 ms  9.540 ms
 5  te-9-1-ur02.staterd7.fl.pompano.comcast.net (68.86.165.101)  9.605 ms  9.899 ms  9.868 ms
 6  te-9-4-ur01.staterd7.fl.pompano.comcast.net (68.86.165.93)  9.801 ms  17.683 ms  17.573 ms
 7  * * te-7-1-ar02.northdade.fl.pompano.comcast.net (68.86.91.82)  8.974 ms
 8  pos-0-7-0-0-cr01.miami.fl.ibone.comcast.net (68.86.85.194)  9.755 ms  9.983 ms  9.903 ms
 9  pos-0-11-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.193)  22.956 ms  25.558 ms  25.435 ms
10  TenGigabitethernet4-1.ar1.ATL2.gblx.net (146.82.35.121)  25.281 ms  25.273 ms  25.150 ms
11  HURRICANE-ELECTRIC-LLC-Ashburn.TenGigabitEthernet4-4.ar3.DCA3.gblx.net (64.214.121.170)  44.790 ms  41.514 ms  41.593 ms
12  10gigabitethernet1-1.core1.mia1.he.net (72.52.92.54)  66.595 ms  66.518 ms  66.439 ms
13  tserv12.mia1.ipv6.he.net (209.51.161.58)  66.432 ms  66.355 ms  66.653 ms

Thank you both for responding.  I definitely agree it is probably something on my side, I've just been having a dandy of a time trying to figure out what would allow inbound but not allow outbound other than iptables.  I've tried reconnecting to the NYC broker with the same results and I did see the thread on TTL affecting trace routes.  The TTL in the stanza has always been set, but I did try the command referenced in the thread with the same results. 

I know this is probably something on my side, but for the life of me I can't seem to figure it out and would appreciate any thoughts.  I recently switched from the NY tunnel broker to the new Miami tunnel broker and everything is working great except for outbound IPv6 trace routes.  Using the new Miami tunnel, when I do an outbound trace route I do not receive back the intermediary hosts, just the final destination.  What seems odd to me is that I am able to trace route to my host through the Miami tunnel as shown in the last trace route.  I've tried disabling all iptable rules on the Linux host, but it didn't make a difference.  At this point I can't say for sure if this was occurring using the NYC tunnel, I am assuming during the change over I forgot to reconfigure something on the host, but I can't seem to figure it out at the moment.  Again, any thoughts are welcome.  Thanks!

Example from Miami to HE:

traceroute to ipv6.tunnelbroker.net (2001:470:0:63::2), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  tunnelbroker.com (2001:470:0:63::2)  276.364 ms  173.176 ms  173.242 ms

Example from Newark to HE:

traceroute to ipv6.tunnelbroker.net (2001:470:0:63::2), 30 hops max, 40 byte packets
 1  avongaussnj.tunnel.tserv4.nyc4.ipv6.he.net (2001:470:1f06:61d::1)  11.226 ms  13.153 ms  17.455 ms
 2  gige-g3-8.core1.nyc4.he.net (2001:470:0:5d::1)  17.560 ms  17.553 ms  21.242 ms
 3  10gigabitethernet3-1.core1.sjc2.he.net (2001:470:0:33::1)  98.529 ms  98.532 ms  98.527 ms
 4  10gigabitethernet1-1.core1.fmt1.he.net (2001:470:0:2f::1)  98.582 ms  98.577 ms  98.608 ms
 5  tunnelbroker.com (2001:470:0:63::2)  98.510 ms  98.504 ms  98.498 ms

Example from Newark to Miami:

traceroute to 2001:470:5:3::5 (2001:470:5:3::5), 30 hops max, 40 byte packets
 1  avongaussnj.tunnel.tserv4.nyc4.ipv6.he.net (2001:470:1f06:61d::1)  14.380 ms  16.899 ms  18.333 ms
 2  gige-g3-8.core1.nyc4.he.net (2001:470:0:5d::1)  18.825 ms  18.822 ms  20.609 ms
 3  10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1)  24.599 ms  24.594 ms  24.621 ms
 4  10gigabitethernet1-1.core1.mia1.he.net (2001:470:0:4b::2)  49.885 ms  49.879 ms  49.912 ms
 5  2001:470:0:8c::2 (2001:470:0:8c::2)  49.907 ms  49.900 ms  49.934 ms
 6  2001:470:5:3::5 (2001:470:5:3::5)  118.919 ms  107.232 ms  111.479 ms

D-Link DGL-4500, Firmware 1.02, Virtual Server Rule (protocol 41 to endpoint)

Actually, afraid.org uses a rather user-friendly interface for IPv6 RDNS to where you only need to enter the prefixes and then you can create the individual hosts without worrying about RDNS zones or formatting. 

I believe karlbrose is correct in that it is using the transit address as the "best" source address rather than the one assigned from the delegated prefix.  If you were running Linux I could tell you how to set the source address and I'm sure Windows XP has the ability as well.  The terms you definitely want to look/google for is "source address". IPV6 and for Windows local prefix policy table. 

I don't have any tunnels on a Windows machine, but I believe if you do the following from a command prompt:

netsh
interface ipv6
show prefixpolicy
add prefixpolicy

You will see the current prefix policies and the syntax of the command(s) you will need to do in order to setup a local policy to prefer the delegated prefix rather than the transit prefix for new outbound connections such as your browser.  Also, if you haven't done so already you will need to add an IPv6 address from your delegated prefix to the adapter, such as 2001:470:1f15:af::10.