Allerdings gibt es auch einige Kernel-Parameter (z.B. accept_ra) die das Verhalten von netfilter auch ohne eigene Firewall beeinflussen und diese könnte in der Standartkonfiguration zu restriktiv eingestellt sein:

root@myHost:~ # for sz in /proc/sys/net/ipv6/conf/*/accept_ra; do echo "$sz=$(cat $sz)"; done;
/proc/sys/net/ipv6/conf/all/accept_ra=1
/proc/sys/net/ipv6/conf/default/accept_ra=1
/proc/sys/net/ipv6/conf/eth0/accept_ra=1
/proc/sys/net/ipv6/conf/eth1/accept_ra=1
/proc/sys/net/ipv6/conf/eth2/accept_ra=1
/proc/sys/net/ipv6/conf/lo/accept_ra=1
/proc/sys/net/ipv6/conf/ppp0/accept_ra=1

Aha, schauen wir uns dazu mal die Definitionen an:

accept_ra - INTEGER
 Accept Router Advertisements; autoconfigure using them.

 It also determines whether or not to transmit Router
 Solicitations. If and only if the functional setting is to
 accept Router Advertisements, Router Solicitations will be
 transmitted.

 Possible values are:
  0 Do not accept Router Advertisements.
  1 Accept Router Advertisements if forwarding is disabled.
  2 Overrule forwarding behaviour. Accept Router Advertisements
    even if forwarding is enabled.

Functional default: enabled if local forwarding is disabled. disabled if local forwarding is enabled.

Man sollte also /proc/sys/net/ipv6/conf/default/forwarding=1 aktiviert haben, seltsamerweise erhalte ich trotz gesetztem /proc/sys/net/ipv6/conf/default/accept_ra=1 Parameter nur eine Link-Local-Adresse. Abhelfen kann man sich hier indem man die Forwarding Einstellung schlicht ignoriert und damit Router Advertisement grundsätzlich akzeptiert z.B. durch /proc/sys/net/ipv6/conf/ppp0/accept_ra=2.
Die paranoiden Admin dürften nun mittlerweile im Dreieck springen und diesmal nicht ganz zu unrecht, so eine Einstellung sollte man nicht als Standard für alle Geräte setzen denn es würde Angreifern erlauben über jede Netzwerkverbindung dem LAN neue Netzwerke anzukündigen unabhängig davon ob der betreffende Host nun ein Router ist oder nicht. Daher werden wir nur dem ppp0 Gerät diese Einstellung erlauben.

Als ersten Lösungsansatz kommt einem vielleicht folgendes in den Sinn, in der /etc/network/interfaces Konfigurationsdatei setzt man im pre-up Ereignis:

...
iface dsl0 inet ppp
 pre-up echo 2 > /proc/sys/net/ipv6/conf/ppp0/accept_ra
 provider telekom
...

Leider klappt das nur für Geräte die zu diesem Zeitpunkt dem System wirklich bekannt sind also z.B. eth0, eth1, … da aber das ppp0 ein virtuelles Gerät ist das erst mit dem Start von pppd sein Leben beginnt, ist dieser Ansatz zum scheitern verurteilt. Wer das up statt dem pre-up-Ereignis verwendet stellt ernüchtert fest dass es dann schon wieder zu spät ist denn die PPP Negotiation ist zu dem Zeitpunkt bereits vollständig ausgeführt. Man kann hier nachträglich mit Werkzeugen wie rdisc6 basteln allerdings muß man dann mit allerlei Bash-KungFu dafür sorgen das diese IP auch dem System bekannt gemacht werden, zu aufwendig und fehleranfällig.
Auch der Versuch diese Konfiguration via sysctl Einstellung zu setzen ist problematisch:

root@myHost:~ # cat /etc/sysctl.conf | grep accept_ra
net.ipv6.conf.ppp0.accept_ra=2

Dann funktioniert zwar der erste Verbindungaufbau beim Bootvorgang noch aber alle nachfolgenden Verbindungen zeigen wieder das ursprüngliche Fehlerverhalten und das ist auch logisch weil nachdem einmal eine ppp0-Verbindung abgerissen wurde wird /proc/sys/net/ipv6/conf/ppp0/accept_ra wieder durch /proc/sys/net/ipv6/conf/default/accept_ra=1 auf den Standart zurückgesetzt.
Abhilfe schafft hier eine udev Rule die den Wert jedesmal setzt wenn das ppp0 Gerät im System angelegt wird z.B. durch:

root@myHost:~ # cat /etc/udev/rules.d/21-ppp.rules 
# allow router advertisment only for ppp0 and only when it comes up!
KERNEL=="ppp0", SUBSYSTEM=="net", ACTION=="add", RUN+="/bin/bash -c 'echo 2 >/proc/sys/net/ipv6/conf/ppp0/accept_ra'"

Ein Blick offenbart nun das gewünschte Resultat bei jedem Start des pppd erhält man eine öffentliche, anklingelbare IPv6-Adresse:

root@myHost:~ # ip -6 addr show dev ppp0
23: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qlen 3
    inet6 2003:40:1111:2222:3333:4444:5555:6666/64 scope global temporary dynamic 
       valid_lft 14291sec preferred_lft 1691sec
    inet6 2003:40:1111:2222:3333:4444:5555:7777/64 scope global dynamic 
       valid_lft 14291sec preferred_lft 1691sec
    inet6 fe80::1111:2222:3333:4444/10 scope link 
       valid_lft forever preferred_lft forever

Das schöne an dieser Lösung ist, wer seinen paranoiden Tendenzen weiterhin frönen möchte könnte theroretisch das Filtern des betreffenden Router Advertisement Pakets zumindest für den Zeitraum indem die PPP-Verbindung aufgebaut wird gestatten. Sollte die Verbindung wieder stehen und die Firewall wieder aktiv sein würden zukünftige Router Advertisement Anfragen blockiert.