I'll have to look into that check and why it is triggering the private address check.

Strange.

You are right though, it should just work.

i think they are suggesting using prefix delegation with dhcp 6.

Set the wan to dhcp6 and set the prefix size to 56.

On the lan page you can select track interface for ipv6 and fill in a number. 0 is fine too.

That should be it although you might need a reboot. I think the current version goes about it better.

the slow nanobsd issue has been here for a while in freebsd 8.3. We don't have a fix for that issue.

I recently changed the script that sets up php.ini.

I could imagine that causing it, but it should then happen on normal updates as well.

if you do a ls -l /conf/config.xml does that list the config? Not sure if that is /cf/conf/config.xml

sounds good, we'll add some validation

At this point in time it is probably a better idea to use the current 2.1 BETA snapshots from the snapshots server.

I can not think of a reason why people would want to keep running the older FreeBSD 8.1 images.

not touching that with a long stick. Someone else will need to apply.

Checked in, test

There might be a race condition here where it has not yet set the LAN address to ::1.

I'm still considering switching out the wide dhcp6 client since others have reported it going away without any logs. It's been on the roadmap for a while, looks it needs to happen.

The intention is to always configure <prefix>::1 on the router for the sake of simplicity.

Good news, thank you for the feedback!

Just a tip for anyone interested. My advice is to make sure your servers are Dual Stacked so you won't have to care where the client is coming from. It will just work.

4in6, tunnel IPv4 over IPv6, the reverse of
6in4(6over4), tunnel IPv6 packets over IPv4 to a relay on the other side.

6to4, this automatically generates a IPv6 prefix you can use based on your public IPv4 Address. This breaks if you don't get a public IPv4 address. Which is the case soon since most Local registries will run out of public v4 "soon" and thus start giving users a private address and NAT everything. This transition tech has limited lifetime. Always starts with 2002::/16. It carries the IPv6 traffic over IPv4 like 6in4.

DS-Lite, tunnels your IPv4 over IPv6, you still get NAT from the ISP but the base carrier is IPv6, like 4in6. The benefit from the ISP is that they don't need Public IPv4 to rollout, which is what any starting ISP will need to do starting 2013 because they will get a single /22 for transition purposes only.

6rd, based on the 6to4 mechanism, but the ISP controls the relay which means they can offer a more reliable service, it also works with private IP addresses on the WAN because they can define the relay the client uses. It uses a similar "calculate the local prefix based on the WAN address" as 6to4, but it can have a different prefix from 2002::/16 and is ISP prefix instead.

ISATAP, Teredo, ignore. It's going away. Windows thing. Automatic tunneling mechanism.

NAT64, DNS64, This is what you will use if you have a v6 client, that can not speak IPv4. We'll need this in the near future, mostly for mobile since it's hard to do dual stack there. Otherwise a v6 only device can not reach IPv4 sites. T-Mobile US is running limited scope testing, but most things work fine.
You'll need a black belt in packet capture foo to decode the NAT though. It's positively unreadable. But it's required to go forward.

4rd, rapid IPv4 deployment, but over IPv6. Tunnel your IPv4 over IPv6. This might be used somewhere in the future. This is for ISPs deploying IPv6 only to the client and then to give them a small bit of IPv4 so they can atleast dual stack. It means all equipment between your CPE and the ISP is IPv6 only. Which is something that will happen in 2013+. See DS-Lite which so far the ISPs prefer better.

NAT-PT, NAPT-PT. You mean something like Carrier(Crummy) Grade Nat, or Large Scale(Sucky) NAT.
I feel for anyone that's going to see their internet connection end up like this, sharing a single IP with a few hundred customers and then wondering why the single IP block from the forum just took out a whole lot of customers. All the automatic blocking mechanisms we have today in forum software in the like will wreck havoc with this.

The FBI was complaining about not being ready to track IPv6, that's just silly, they should try and decode connections from such a large NAT and then try to find which of the few hundred users was it.

Strange, it's supposed to add the scope, need to look the code through to see what's happening

you set the wan to dhcp-pd prefix size 60

You set the lan to track interface wan. That should be enough.

a lan is always a /64.

If you don't see any addresses you need to check if radvd is still running.

If your LAN is automatically configured we setup both router advertisements and DHCP6 for the LAN so everything just works.

We don't have support for manually overriding this sort of configuration.

If your WAN address never changes you can statically configure the LAN address and then it all comes available to configure manually.