What do they mean by "IPv6 forwarding" and why is it "not available"?
Linode's article on An Overview of IPv6 on Linode states that:
For security reasons, IPv6 forwarding is not available on the Linode network. This is enforced by our network infrastructure.
What is being implied under "IPv6 forwarding" and what exactly is "not available" (and why)?
Forwarding refers to using a device (in this case a Linode) as a router, so that other devices (Linodes) may access the Internet.
In order to prevent Linodes from spoofing traffic and seeing traffic that is not destined for them, Linode has rules on the host which drop traffic inbound to the Linode that does not have an address assigned to the Linode as the destination, as well as traffic originating from the Linode that does not have an address assigned to the Linode as the source. Two types of addresses apply here: layer 2 addresses (MAC addresses) and layer 3 addresses (IPv4/IPv6 addresses). Certain very narrow exceptions apply so that ARP and NDP (Neighbor Discovery Protocol, IPv6 equivalent of ARP) can work.
When routing/forwarding traffic, the layer 2 address is set to the router, but the layer 3 address is set to the final destination. Because the layer 3 address does not match an address assigned to the Linode being used as a router, the traffic is dropped by the host before it reaches the Linode.
You can work around this by encapsulating traffic in a tunnel or VPN, but that will reduce throughput due to overhead, and if you're not careful, create a single point of failure.
I understand the concept of forwarding. What I was asking is, basically, even though I have a /64 prefix on my IPv6 link, I cannot just take any other address on that prefix and use it (for whatever purpose, be it containers or running my own private IPv6 tunnel broker)?
Finally, Linode has an option to request another IPv6 prefix. Then how can I ever use that prefix, if I'm not allowed to do forwarding?
Without any additional configuration other than bringing the address up, you can use any address in the /64 you've been assigned on the Linode that the /64 is routed to, as this doesn't require any forwarding outside of the Linode (this includes containers). So for example, if you had 2600:3c00:e000:0::/64 routed to 2600:3c00::f03c:91ff:fedf:906b, you could use any address in 2600:3c00:e000:0::/64 on the Linode whose main IPv6 address was 2600:3c00::f03c:91ff:fedf:906b, but, out of the box, you couldn't use that /64 on any of your other Linodes in that same datacenter and have those Linodes be able to reach the Internet from that /64 address (technically outbound would work, but inbound would not without a tunnel). Any kind of tunnel or VPN on the "router" Linode will also work fine, because the traffic exiting the "router" Linode will be using addresses that are assigned to the Linode, because the real traffic is encapsulated. I've personally run tunnel brokers on my Linodes (one was 6in4, like HE's tunnelbroker service, and the other used GRE because I needed to carry both IPv4 and IPv6).
(Honestly that part of the IPv6 guide just needs to go; it's really confusing and refers to a specific use-case that it does not elaborate well and almost nobody does anyway.)
Could that be the reason why I can't get icmp6 replies when I use ipv6 autoconfigured "privacy" address?
I use openVPN to set up a v6 tunnel to our LAN, managed on our Linode and our gateway. Hosts on the LAN get their addresses using SLAAC and route advertisements (radvd) from the gateway box.
The Linode folks were kind enough to give me a routed /56 to work with since this is the recommended prefix size for this kind of address block subdivision. We've had no problems with speed at all. The only problem we've had is that some websites block v6 traffic from Linode IP addresses, for reasons I don't understand. Lately I've also had to turn off the v6 tunnel when trying to access the Apple App Store from our iPhones using our SOHO network, although this is probably Apple's problem. We didn't have this problem for several years, but it started recently.