You didn't say who your ISP was, but the following works on Comcast in areas where they have rolled out IPv6.

I had to use wide-dhcpv6-client since none of the other DHCPv6 clients could handle all of getting an address for the ISP-facing interface, prefix delegation, and Comcast's maximum /60 network mask at the same time.

After installing wide-dhcpv6-client, edit /etc/network/interfaces so your eth1 IPv6 settings look like this:

iface eth1 inet6 auto
        post-up sysctl -w net.ipv6.conf.ext0.accept_ra=2

Edit /etc/wide-dhcpv6/dhcp6c.conf so it looks like this:

profile default
{
  information-only;

  request domain-name-servers;
  request domain-name;

  script "/etc/wide-dhcpv6/dhcp6c-script";
};

interface eth1 {
    send rapid-commit;

    send ia-na 0;
    send ia-pd 0;
};

id-assoc na 0 {

};

id-assoc pd 0 {
    prefix ::/60 infinity;

    # Internal interface (LAN)
    prefix-interface eth0 {
        sla-len 4;
        sla-id 0;
        ifid 1;
    };
};

The "na" section gets an IPv6 address for eth1 (facing your ISP). The "pd" section gets a prefix delegation for your internal network and will assign the IPv6 address "[prefix]::1" to eth0 (your internal interface). If you have additional internal networks, you can add additional "prefix-interface" sections for those interfaces and increment the "sla-id" for each one.

Then you need a router advertisement daemon on the system for your internal network. You can use either radvd or dnsmasq.

If you are using dnsmasq, the necessary additions to /etc/dnsmasq.conf for IPv6 are

# Enable IPv6 Router Advertisement (RA) features.
enable-ra

# Advertise delegated prefix based on the IPv6 address of eth0.
dhcp-range = ::1,constructor:eth0,   ra-stateless, ra-names, 4h

You'll need to install the dnsmasq from Debian testing since the version that ships with Debian wheezy does not do router advertisements properly.

Then ifdown and ifup your external interface, make sure dhcp6c is running, and see if both your external and internal interface have IPv6 addresses other than the link-local ones (the "fe80::..." addresses). If all of that worked, restart dnsmasq, and the systems on your LAN should start automatically configuring IPv6 addresses for themselves.

There is a vital piece of information missing here:

1. The router Technicolor 7200 does not support prefix delegation and neither bridging (13.10.14). It is disabled by Unitymedia Germany and KabelBW.
2. Prefix delegation is required for operating two routers behind each other, as seen here (read answers 1, 2 and 4e, this is from a CPE, I didn't find the actual spec): http://www.psg.com/lists/v6ops/v6ops.2008/msg00086.html

Knowing 1) and 2) you have to be clear about one thing: Because of the TC7200 inability to offer prefix delegation and because you cannot change your router, the only thing which can save you is some kind of hack. I doubt your WDR3600 will implement this hack (I don't think such a hack exists or is even possible).

Having said that, let's talk about at least a theoretical solution. Keep one thing in mind: ipv6 does not have NAT.

ipv4 works, because your router knows how to route it:

1. your pc requests a ipv4 package.
2. it goes to the WDR, the WDR rewrites the source, wiki: "When a computer on the private (internal) network sends an IPv4 packet to the external network, the NAT device replaces the internal IP address in the source field of the packet header (sender's address) with the external IP address of the NAT device" ( Google wikipedia, NAT Translation_of_the_endpoint)
3. The TC7200 does the same (and then routes it through unitymedias ds-lite system) When it comes back the opposite happens and your PC receives the packet.

--> NAT allows the package to traverse all routers, because the package knows at every step where to go.

ipv6

1. your pc sends a ipv6 package
2. your router forwards it as-is (maybe)
3. TC7200 same
4. it comes back
5. The TC7200 can't route it further, because your PC is behind the WDR and the TC7200 does not know it's there. It doesn't know how to route it further. It didn't delegate its subnet, so it's the master of all addresses of this subnet. If it did delegate its subnet, it would send the package to the next router the subnet was delegated to. It has no reason to contact your router.
6. Package dropped --> No NAT means that the target has to be in the routers own network unless that piece of the network was delegated to another router.

So the reason your setup doesn't work is: NAT doesn't exist. TC7200 doesn't know about other router, who took the same subnet.

In that sense I also disagree with the OpenWRT solution you posted: The solution you mentioned is best explained in this thread (I did not check the explanation for validity but it does make sense: URL: unitymediakabelbwforum)

Loose translation: "The OpenWRT solution doesn't bridge the interfaces, but reuses the same subnet prefix as the WAN (thus also breaking the ipv6 spec). Then you will have a router in between, which has its own ipv6 firewall, its own DNS, etc. (...) All this would not be necessary, if it would just support prefix delegation. (...)"

I don't know how this should be possible without OpenWRT faking the devices or bridging the networks to be honest (thereby undermining the whole router behind router idea). The ONLY possible solution I see is if the OpenWRT router would create a virtual bridged interface on the WAN interface with the mac address of every single DHCP-v6 Client and route all traffic 1:1 (through the firewall of course) to the bridged IP. That would make it known to the TC7200. I would ask the author of the forum post and maybe the OpenWRT devs about that solution.