Die genaue Bedeutung ist m.W. nirgendwo dokumentiert von AVM, aber man kann sich die Auswirkungen in einem Paketmitschnitt ansehen und daraus (in den Grenzen, die einem von der Verschlüsselung gesetzt werden) seine Schlüsse ziehen.
"always_renew" sorgt wohl dafür, daß eine abgelaufene SA auch dann erneuert wird, wenn gerade keine Pakete über den Tunnel zu übertragen sind - die Verbindung quasi "auf Vorrat" aktiv gehalten wird, allerdings erst nach dem ersten Herstellen einer Verbindung, denn den initialen Aufbau übernimmt "always_renew" wohl nicht, zumindest nicht in jeder AVM-Version.
Durch die Angabe von "keepalive_ip" werden in regelmäßigen Abständen ICMP-Pakete an die angegebene Adresse generiert (die enthalten 25x die Zeichenkette "PING" als Payload) ... diese lösen dann den Aufbau der Verbindung aus, wenn versucht wird, sie zu übertragen. Die Adresse muß auch nicht existieren (bzw. da muß kein IP-Client antworten), weil sich niemand für eventuelle Antworten interessiert - entscheidend ist nur die Tatsache, daß da ein Paket für ein Ziel im "entfernten Netz" existiert und der Rest der Firmware alle Anstrengungen unternimmt, dieses Paket korrekt zuzustellen.
Damit ergibt sich aber - zumindest den Tests nach, die ich vor längerer Zeit dazu gemacht hatte mit einem Peer auf einem Linux-System anstelle einer anderen FRITZ!Box - auch ein abweichendes Verhalten durch das "always_renew". Während dieses (solange die SA für P1 noch gültig ist) nur eine Erneuerung der SA und damit praktisch die Wiederholung von P2 auslöst, werden ohne diese Einstellung die alten SA immer komplett abgeräumt und danach startet dann (entweder wegen eines ICMP-Pakets aus dem "keepalive"-Generator oder wegen "tatsächlichen" Verkehrs) eine komplett neue Verbindung, die wieder mit der Aushandlung in P1 beginnt.
Durch "keepalive_ip" ergibt sich also auch ein regelmäßiger Datenaustausch (allerdings recht wenig), während durch "always_renew" nur die SAs (beim Ablauf bzw. 10% früher, zumindest hinsichtlich der "lifetime" in Sekunden - ob das beim Erreichen des Volumens auch so wäre mit den 10%, habe ich nie getestet) ermeuert werden, was mit entsprechend weniger Traffic verbunden ist.
Allerdings wird dadurch dann (weil so ein Erneuern der SAs nicht in entsprechend kurzen Abständen erfolgt) auch keine UDP-Portzuordnung bei einem Provider mit "carrier grade"-NAT offengehalten, egal ob es um DS-Lite oder ein IP4-CGN (wie im Mobilfunk häufig noch anzutreffen) geht ... daher wird "always_renew" in einem solchen Szenario, wo ein Datenpfad offengehalten werden muß, nicht ausreichen - und das oben angerissene Problem, daß "always_renew" selbst keine P1 startet, bleibt dann auch noch über.
Daher sollte man sich (solange nicht wirklich ein extrem kleines Volumenkontingent im Spiel ist) eher auf "keepalive_ip" kaprizieren ... die 100 Byte (als Payload wie gesagt, da kommen dann noch Header-Daten hinzu) alle fünf Sekunden - in diesem Intervall werden die ICMP-Messages gesendet - sollte man verkraften können und diese Pakete halten dann auch einigermaßen zuverlässig jeden Pfad über ein "connection tracking" offen.
EDIT: Allerdings reicht es normalerweise auch, wenn man auf einer Seite einer VPN-Verbindung "keepalive_ip" verwendet, sofern der adressierte IP-Client auf der Gegenseite existiert - dann sollte dessen Antwort die SA auch für die Gegenrichtung (denn das sind bei IPSec zwei getrennte Keys, die da verwendet werden) aktiv halten. Setzt man hingegen auf beiden Seiten "keepalive_ip" ein, erzeugt man (zumindest war es mal so) auch den doppelten Traffic, weil dann auf beiden Seiten die Pakete generiert werden ... die Antworten wertet die AVM-Software, wie geschrieben, gar nicht wirklich aus. Eine ausbleibende Antwort ist also auch kein Grund für die "Schlußfolgerung": "VPN-Verbindung wurde abgebaut".
