I get most of that, but the thing that doesn't make sense is how in the tunnel details pages for HE, it has 'Client IPv4 address: 173.x.x.11' listed, which is my WAN IP. However, I couldn't ping Google until I changed the D-Link 'Local IPV4 Address' from 173.x.x.11 to an internal LAN IP in the range of 192.168.1.2-.254. I would think that the 'Client IPv4' and 'Local IPV4' would be the same thing. The thing I base this off is that the first 4 categories of the tunnel details shows:
Server IPv4 address: 126.96.36.199
Server IPv6 address: 2001:470:1f04:6db::1/64
Client IPv4 address: 173.x.x.11
Client IPv6 address: 2001:470:1f04:6db::2/64
Where the D-Link shows:
Remote IPV4 Address: 188.8.131.52
Remote IPV6 Address: 2001:470:1f04:6db::1
Local IPV4 Address: 192.168.0.2
Local IPv6 Address : 2001:470:1f04:6db::2
Is this an issue with D-Link not following standards?
I also noticed that the DLink does not allow 2 simultaneous connection to the internet. When I try to ping from 2 separate PC's, one work and the other fails. If I wait a while, then the one that was not working will. I found a post on this that shows some recommended settings. http://forums.dlink.com/index.php?topic=3847.msg25668#msg25668
Can I make this work with 2 PC's simultaneously?
The Local IPv4 in this context is the IPv4 address you want to use as your tunnel end point. That is, the IPv4 address that your router will use to originate and receive the IPv4 6in4 tunnel traffic which it uses to tunnel the IPv6 packets.
I presumed you were using the D-Link as your edge router, and it had a public IPv4 address on its outside interface. If you are using it behind another router which has your public IP address, and the D-Link has a NATed private IP (192.168.x.x), then you would specify the NATed address as your local IPv4.
The HE website can only see your public IP, since when you access the internet, your private IPs are NATed to the public. So, the HE website will always list your public IP as the "client IPv4 address" since it can't know what your "real" address is. If you were establishing the tunnel from a PC or router which had the public IP, it'd be correct. But since it appears you're behind a NAT, it wont work, and that line should be ignored.
When behind a NAT, the way it works is that the tunnel traffic uses your private IPv4 address as the source address of the 6in4 packets. When this packet reaches your NAT firewall/router, it will NAT this source address to your public IP, and "remember" which internal private IP originated the traffic via its connection/nat table. When return traffic comes back to the public IP, it will NAT it back to the original private IP and deliver it to your DIR-615. However, since 6in4 doesn't have ports, it only "remembers" the last internal host which sent IPv4 protocol 41 (6in4) traffic out, and sets that as the place to send any return traffic, unless
you set up a static NAT entry for 6in4 and point it to a specific IP.
As for only one IPv6 host working at once, this is really odd. It's either a bad bug with the DIR-615, or the LAN side of your IPv6 network isn't set up properly, or there's more than one host on the inside (something other than your 615) trying to do 6in4 and "poisoning" your NAT table on your edge firewall/router. Or a combo of the last two.
Make sure that autoconfiguration, or DHCPv6 are setting proper IPv6 IPs and default gateways on your LAN hosts. The IPv6s should be addresses in your routed /64, and the default gateway should be the IPv6 LAN interface for your DIR-615. It may use one of your routed /64 addresses, but it may also use the link local IPv6 address of your DIR-615 for the def gateway. Either should work.
Also make sure nothing else on your LAN is generating 6in4 traffic. I've heard windows vista and/or 7 tries to do 6to4 before it tries Teredo. If this is the case, 6to4 actually uses 6in4 for the actual tunnels it establishes. So if this is happening it's "poisoning" your NAT device and shunting 6in4 traffic to itself instead of your DIR-615.
You should really establish a static NAT entry on the edge firewall/router, sending all IPv4 proto 41 traffic to your 615, if possible (some routers only allow static NATs rules matching TCP or UDP ports, and not IPv4 protocol numbers). If you can't do that, then see if you can block outgoing IPv4 protocol 41 traffic from any inside host but the 615 (likely the security policy won't let you match on proto numbers either, if the NAT rules doesn't). If you can't that, you could try setting DMZ to the 615. But that probably wouldn't prevent the hijacking of the 6in4 traffic, since the "DMZ" setting usually only applies to unsolicited traffic. If you can't do any of that, you'll just have to stop any other host but the 615 from trying to do 6in4. If all your hosts have proper IPv6 global unicast addresses from your routed /64, this should prevent them from trying 6to4 or Teredo.