I'm really freaking out here.
This Fritzbox doesn't do PPPoE Passthrough with current firmware 6.something.
My other modem doesn't sync and now I'm pissed with this crappy software / hardware.

Seems like I need even another Modem.

It's my understanding the broadcast are gone in IPv6 so you need to specify your router (Ra) in ipv6 in the absence of a dhcp server. That way devices will know their gateway. I wouldn't advertise my router on the wan and but could be missing something.

@Derelict:

DHCPv6 is out because you can't set up DHCPv6 on a dynamic interface, which a "Track Interface/WAN" is.

Because you can't get into that menu, you can't set any RA characteristics for that segment either.

There is a way to run DHCPv6 on a dynamic LAN interface.  It is probably considered unsupported and exploitation of a bug.  But, mine has been running this way for over a year.  This is with 2.1.x

Configure your LAN for a static IPv6 address (just make something up).

Enable DHCPv6 Server/RA.

Go back and change the LAN interface to dynamic with WAN Tracking.    It will prompt you to disable DHCPv6 Server.  Do so and then finish the LAN interface configuration.

config.xml will be left with a remnant like …

<dhcpdv6><lan><ramode>assist</ramode> <rapriority>high</rapriority> <rainterface><radomainsearchlist><range><prefixrange><defaultleasetime><maxleasetime><netmask><failover_peerip><domain><domainsearchlist><ddnsdomain><tftp><ldap><nextserver><filename><rootpath><dhcpv6leaseinlocaltime>yes</dhcpv6leaseinlocaltime></rootpath></filename></nextserver></ldap></tftp></ddnsdomain></domainsearchlist></domain></failover_peerip></netmask></maxleasetime></defaultleasetime></prefixrange></range></radomainsearchlist></rainterface></lan> 4) The DHCPv6 Server will continue to run and hand out address on the dynamic IPv6 network.  To make any changes to the DHCPv6 Server/RA you need to directly edit the config.xml. **Caveats** + I have not tried to make a lot of edits to the config,  have just let it run on "auto-pilot".  No advanced configurations. + This is apparently "unsupported" and may stop working at anytime, due to code changes to the base system. + Not recommended to production environments.  **Other** This explains why I noticed this behavior:  https://forum.pfsense.org/index.php?topic=83534.0 It is possible that this behavior lead to major problem when I upgraded to 2.2-BETA:  https://forum.pfsense.org/index.php?topic=83256.0</dhcpdv6>

Hey guys,

Thanks for your help.
I did exactly what you described but hdas Addition was the missing Piece and got me on track.

It is now working as I thought it has to be and similiar to my second Fritz.box.
I'm playing around a bit and will come back if I have more questions.

Thanks again.  :D

Here's the post that was published on the account's main news feed:

Authentication updates
[January 31, 2014]
In order to improve account security, some changes have been made to how tunnel endpoint updates are authenticated.

Tunnels made after this post now are configured with an "Update Key" (under the "Advanced" tab on the tunnel information page), which is used instead of the general account password when performing automated updates via either the https://ipv4.tunnelbroker.net/ipv4_end.php or the /nic/update (Dyn-alike) mechanisms.  Do not MD5() this value before use.

When an "Update Key" exists, the account password will not work for updates on that tunnel.  Existing tunnels can set an "Update Key" to take advantage of this new mechanism.

Thank you for updating the docs! :)

@Satras:

Who needs IPv6 right now ? I just want to be prepared and start my first tests with it.
I won't get a 2001 or similar public Network for various reasons.

So still the questions, how do I configure it to work now ?

As I can see you're running a german Windows.
So whats your Provider right now?

Several Cable Providers and Telekom can give you IPv6 prefix to get your stuff runing.

What the others tried to tell you. There are some Options via Tunneling but right now  what do you have and what you done, is creating an "internal" Network with FDxx adresses also known as ULAs (unique LOCAL adresses).

These adresses where invented as replacement for site local adresses and as a Transition technique and These adresses are designed not to be routable.

You Need a tunnel Broker which is able to encaplsulate IPv6 through IPv4 or the mentioned ISP with IPv6 UGA prefix (unique GLOABL adresses, similiar to IPv4 public adresses).

I'm prepraring a Video tutorial series in english and german to explain all these basics and walk trough the processes.

if you interested stay tuned and give me some Feedback and Inputs.
call for ideas is open. ;)

How often are you losing IPv6 connectivity/routing? I wonder if it's the same problem I am seeing with my LAN clients losing ability to route IPv6 to and from internet every few days. I thought I had checked the default route, but perhaps not. Next time it happens, I will check what the RAs are doing.

To post a follow-up about this, I am still suffering from the issue where the tunnel stops working even though the sixxs-aiccu daemon is still running. I am 99% certain that this is due to me daily resetting the PPPoE session in pfsense (stupid ISP policy here that will disconnect PPPoE sessions older than 36 hours). I made a thread over at the sixxs forums as I thought one of the advantages of aiccu would be to survive this kind of scenario. I'm guessing it can (changing IP address), but there might be a bug in the daemon. Then again, the daemon is from 2007 so I don't expect much feedback from sixxs. Anyway, the thead is over here: https://www.sixxs.net/forum/?msg=general-12505873

As a work-around I manually kill the sixxs-aiccu daemon every night when I reset my PPPoE session and restart it afterwards. This is done via a cron script in pfsense. I've put the script online at https://gist.github.com/fvdnabee/4defa281bcb7fe676b56. Be sure to heed the FAQ item Jeroen linked to though when using this script:

I am blocked from TIC!

Due to some people seeing a need for quering the TIC server every couple of seconds, as they most likely put AICCU or another TIC client in some sort of looping construct, eg by using daemontools/launchd/scripting/cron/etc, we have configured a ratelimit on the service to avoid it from being overburdened by misconfigured clients.

If a client connects too frequently it will be blocked by the TIC server and a 500 error will be given pointing to this FAQ. If the client keeps on attempting to contact the TIC server even though it has been told that it is blocked, the block will be extended for a longer period of time. If we are able to determine the user causing this we will of course notify the user that this happened. It seems though that people even though informed rarely fix the problem and just keep on hammering.

As in general you will not have to connect more than once this should not pose a problem to normal clients.

To make it clear: do not run AICCU in a automatic restarting manner.

If AICCU stops working there is a reason why it did that. Check the logs and the output of the program to check why and report problems to SixXS Staff or ask the forums on how to solve a problem.

Both AYIYA and heartbeat have been designed for a variety of scenarios, eg frequently changing IP addresses there is thus no need to restart AICCU. Even if you have a mobile client you do not have to restart AICCU.

As I only run the script once every 24 hours, I don't consider this a problem.

I have a router running on time warner cable that does exactly the same thing.  Very annoying.

I keep forgetting to switch that one to HE.  Maybe tomorrow…

I wonder why any government would want to control what types of routers its citizens can use?

Only one thing comes to mind…

The one-size fits all solution of forcing a particular (usually crappy) router to be used is bad for many many people.

Its all there under the hood to make it happen I believe. The Web GUI needs to be updated/modify to allow the different IPv6 configurations to be generated.

I guess I'm confused by the "Only request a IPv6 prefix, don't request a IPv6 address" checkbox.

That setting is only available if DHCPv6 is selected as an interface type and there's no alternate way to set an IPv6 interface address.

You might do better asking this in the 2.2 snapshots forum under the Development category… or maybe a mod can move it there.

Solved:

System > Routing > Gateways > WAN_SLAAC >
Check  Disable Gateway Monitoring

Ipv6 all suddenly starts responding properly.