Based on my past experience with VZ DSL, the Westell isn't doing anything funny (NAT, etc.) so it should pass the traffic you need just fine.

Since you're running DD-WRT on your router, why not set that up for IPv6 then use your routed /48 for your Windows host?

See the tutorial at http://www.dd-wrt.com/wiki/index.php/IPv6 for directions.

What you're implying is that your ISP gives you only a 192.168.1.x private address and that others connected to that ISP share the same network. That's not normally the case - typically there's a per-customer router that has a public internet address that provides address translation for a separate (non-shared) private network. It's possible you're running in to a CGN (Carrier-Grade NAT) situation where your ISP uses one public IP for multiple home users; if that's the case, you don't have a router dedicated to your connection and then can't get the HE tunnel to work.

However, we're guessing here. If you don't understand how the IPv4 connectivity to your home well enough for us to figure out how it works, then there's little chance we can get you working.

Hello guys. I tried to configure the tunnel on my Windows 7, but I'm not getting because I do not have a real IP. I received a IP 192.*, and IP provider is 189.* (real). It is impossible to use Hurricane Electric tunnels without a real IP? Has anyone experienced this?

That 192.168.* address is a Network Address Translation (NAT) address provided by your router. You must configure that router to forward the traffic from the HE endpoint to your Windows 7 host, which means that you must have the ability to manage that router. If it's a router supplied by your ISP and managed by them, you're probably out of luck unless you can set up something like a "DMZ Host" as a catch-all. The answer to your question depends on what kind of NAT router that you're using.

how would i know..that he is pinging me???

You'll need to explain what you're asking and answer questions without more questions if you need help.

For the IPv4 address that you mention, 139.190.31.105, I can ping it from the Internet. Are you still having troubles when you try to configure that as your tunnel endpoint?

What kind of router are you using between the Internet and your Windows system that you're trying to use with the tunnel? We need to know what that is to help you configure that properly.

Sorry, Apple doesn't think you need to be able to set a preference. At least under OSX Lion, the system tries to obtain both IPv4 and IPv6 addresses and maintains a cache of what protocol works better and prefers that.

See, for example, http://lists.apple.com/archives/Ipv6-dev/2011/Jul/msg00009.html

(This thread starts here if you want to read the whole thing: http://lists.apple.com/archives/Ipv6-dev/2011/Jul/msg00007.html)

[only]

what did u mean, doesn't it need to put the prefix that i got from HE 2001:470:36:270/64??

There are TWO networks involved. One is the tunnel between you and Hurricane Electric.
Your configuration details seem to imply that the tunnel uses 2001:470:36:270::/64, which is what you're telling RADVD to advertise to your LAN. Since that's not your network, that's not going to work. That network is only used with the connection between your endpoint and the servers at HE.

In addition to the tunnel /64, HE provides you with a routed /64 or a routed /48. That is the network that RA should be advertising to your LAN. Basically, HE sets up routing for IPv6 to send any traffic to that network prefix towards your server, which then routes the traffic onto your internal LAN.

You're mixing up the tunnel IP range and your routed network. Looking at your configuration, you have the tunnel using 2001:470:35:270::/64 (HE's end at ::1 and your end at ::2).
Your public IP is on interface eth1. So, why are you running RADVD on that interface?

The way this works is you have a tunnel network and a routed network. The tunnel network runs between you and HE's servers. If all you want is one IPv6 host, then you're done. Use the tunnel's IPv6 client endpoint - 2001:470:35:270::2 in your case - to talk to your client.

If you want to support multiple IPv6 hosts, then you use the client that's running the tunnel to HE (the WAN side) as a gateway between your LAN and the tunnel. This implies that the gateway must have multiple network adapters.

In this case, your LAN connection must use a DIFFERENT network interface from the one that's connected to the Internet, and assign your routed IPv6 range to that, for example ::1. Now you should configure RADVD to give out addresses in the routed network - what you've done is to configure it to give out addresses on the Internet side for the address range assigned to the tunnel. Your DHCP configuration is also trying to give out addresses on the wrong network and wrong interface.

[2001:470:36:270]

now, the client get ip add from server, but i dont what exactly it is

For this interface?

wlan0     Link encap:Ethernet  HWaddr 48:5d:60:53:2f:6b 
          inet6 addr: 2001:470:36:270:4a5d:60ff:fe53:2f6b/64 Scope:Global

It's getting 200:470:36:270::/64 as the prefix from your radvd.conf

interface eth0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 3;
        prefix 2001:470:36:270::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
};

If your routable /64 isn't 2001:470:36:270, then you'll need to fix your radvd.conf and restart radvd.

If you're wondering where the rest of the stateless address comes from, it's the MAC address of the interface converted to EUI-64.

Is your DD-WRT device used to route to your ISP? The DD-WRT instructions assume that. If you're using some other router in front of the WRT, you'll need to adjust for that. (The outside router will need to forward IP protocol 41 to the WRT device.)

The link-local address for the default gateway is OK - for example, mine looks like

Ethernet adapter Local Area Connection:

   IPv6 Address. . . . . . . . . . . : 2001:470:1:11:cd68:7896:da8d:9ce9
   Temporary IPv6 Address. . . . . . : 2001:470:1:11:2d96:9288:a6db:f71a
   Link-local IPv6 Address . . . . . : fe80::cd68:7896:da8d:9ce9%10
   IPv4 Address. . . . . . . . . . . : 192.168.1.203
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::214:22ff:fe2c:2cb4%10
                                       192.168.1.1

The default gateway tells me that the MAC is 00:14:22:2c:2c:b4, which is correct for my firewall host:

bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:14:22:2c:2c:b4
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
        status: active
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::214:22ff:fe2c:2cb4%bge0 prefixlen 64 scopeid 0x1
        inet6 2001:470:1:11::1 prefixlen 64

(IPv6 edited for privacy reasons.)

This is unfortunately common behavior for a number of "load balancer" products. The "engineers" of those products didn't consider IPv6 and don't know how to handle AAAA requests.

These products are unsuitable for use on the Internet, but they're still popular, unfortunately.

I had one site accuse me of "hacking" their DNS servers when I supplied them DIG output demonstrating the erroneous response to AAAA queries.
Of course, it's probably still broken.

That's intentional - see http://www.tunnelbroker.net/forums/index.php?topic=2081.0
IRC networks are blocked by default due to IRC abuse. You can re-enable IRC access if you're a Sage.

Which version of SEP are you using? I don't recall seeing this on my work laptop which runs SEP 11.x

Repost done.

Test :
when i ping from another PC using IPv6 1 can ping 2001:470:1F08:1570::1 (server) but not my 2001:470:1F08:1570::2 (client)

I have change with another BOX but it 's the same...

Your configuration shows tunnel0 as having ipv6 address 2001:470:1F08:1570::2 - that's why you can't reach that client, it needs a different unique address.

We might adjust this, however all those with 1500 seem to have completed without issue. If we wanted people to script against it, and not interact with trying to find relevant IPv6 information and game the system by essentially setting up a data mining bot and walking away, yeah we could have it reset every day at like 3am.

I would like to mention that the current scheme can be frustrating. OK, so I've already posted in the last 24 hours - why not tell me when, so I don't have to keep clicking until the window opens up. Not a really big deal, mind you, but it could be a bit more friendly.

Well, this problem will be fixed soon. From ARIN's announcement mailing list:

ARIN announces a pending change to Whois query behavior on port 43.

Prior to 25 June 2011, a query for an IP address in the ARIN region would return with that assignment/allocation within the ARIN region, and a query in the ARIN region for an IP address with no assignment/allocation would result in a "no match" response. On 25 June, a change was misapplied. The intent of this change was to return ARIN's /8 for IP queries within ARIN's region for which there is no assignment/allocation, a behavior meant to align ARIN's Whois output with that of the other RIRs. However, this change introduced an unintended behavior of returning ARIN's /8, in addition to the desired results, in responses where IP addresses had been assigned or allocated.

This change in behavior has created some confusion. On 2 October, ARIN will reinstate the previous behavior for Whois IP queries so that results are returned the way they were before 25 June.

ARIN has provided two examples of a Whois query for reference:

* Query with ARIN's /8 returned in the result set hierarchy:
https://www.arin.net/announcements/2011/20110919.html#example1

* Query without ARIN's /8 returned in the result set:
https://www.arin.net/announcements/2011/20110919.html#example2

Whois-RWS behavior will not change as it was not affected by the configuration change made on 25 June.

We apologize for any confusion this has caused.

Regards,
Mark Kosters
Chief Technical Officer
American Registry for Internet Numbers (ARIN)