[fli4l] IPv6 dhcp-relay only

Alexander Dahl lespocky at web.de
Di Jun 2 13:45:44 CEST 2020 

Hallo Kay,

Kay Martinen schrieb Dienstag,  2. Juni 2020, 11:36 (CEST):
> Am 02.06.20 um 08:49 schrieb Alexander Dahl:
>> Bin nicht sicher, was Du erreichen willst. 
>
> Hmm. Das IPv4 und 6 funktionieren aber beides auch gefiltert werden
> kann. Um unerwünschte Verbindungen von Innen zu blockieren und von außen
> auch.

Wie machst Du das denn für IPv4? 

>> Das übliche Setup ist, Adressverteilung im lokalen Netz per SLAAC, d.h.
>> für Deine lokalen Subnets automatische Adressvergabe per Router
>> Advertisement (RA), also ohne DHCPv6. Das macht fli4l, ich meine sogar
>> schon in 3.10.
>
> Da wäre meine Frage was der FLI per RA verteilt. Seine Eigene IPv6 oder
> die eines vorgelagerten Routers.

Na seine eigene link local adresse von dem device, auf das das
entsprechende IPv6 LAN konfiguriert ist. Das Endgerät kommuniziert über
diese link local Adresse mit dem (fli4l) Router. Beispiel (fli4l 4.0)
von mir:

 IPV6_NET[1]='{ula-clients}+::1/64'
 {
   DEV='br0'
   ADVERTISE='yes'
   ADVERTISE_DNS='yes'
 }

Sieht dann auf dem fli4l so aus (ip addr show):

2: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:0d:b9:16:6f:4d brd ff:ff:ff:ff:ff:ff
    inet 192.168.243.1/24 brd 192.168.243.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2001:16b8:504c:f3f1::1/64 scope global dynamic 
       valid_lft 6064sec preferred_lft 2464sec
    inet6 fd5b:86e0:557e::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:b9ff:fe16:6f4d/64 scope link 
       valid_lft forever preferred_lft forever

Und auf einem Endgerät, das sich per SLAAC seine IPv6 gegeben und die
Informationen über's Gateway per RA erhalten hat:

    alex at falbala ..rschiedenes/fli4l/configs/config.sandy (hg)-[default] % ip -6 route show
    2001:16b8:504c:f3f1::/64 dev eth0 proto kernel metric 256  expires 5938sec pref medium
    fd5b:86e0:557e::/64 dev eth0 proto kernel metric 256  pref medium
    fe80::/64 dev eth0 proto kernel metric 256  pref medium
    default via fe80::20d:b9ff:fe16:6f4d dev eth0 proto ra metric 1024  expires 1663sec hoplimit 64 pref medium

Hier siehst Du, dass das default gateway auf dem endgerät genau die link
local adresse des fli4l ist. Von dem dem fli4l vorgelagerten Router
weiß das Endgerät nichts. Das würde auch nicht funktionieren, wie bei
legacy IP auch, braucht der Client ja ein gateway im selben Subnetz,
über das er seinen Internettraffic abwerfen kann.

>> Prefix Delegation (PD) passiert per DHCPv6. Wenn der vorgelagerte Router
>> das nicht macht, da bin ich ein bisschen neugierig, woher der fli4l dann
>> sein Prefix bekommt? Statisch? (Hier ist es im Moment so, dass fli4l da
>> ein prefix bekommen und verarbeiten kann, aber nicht an nachgelagerte
>> Netze weiter delegieren kann.)
>
> Du willst vermutlich sagen das der FLI auf dem WAN-Seitigem Interface
> ein Präfix bekommt. 

In einem typischen Setup bekommt der fli4l-Router auf dem WAN-seitigen
Interface zwei Dinge: eine Adresse für sich selbst und ein Präfix aus
einem anderen, meist daneben liegenden Subnetz, woraus er selbst dann
seine LAN-Netze bauen kann.

Beispiel vom WAN-Interface meines fli4l-Routers:

4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:0d:b9:16:6f:4c brd ff:ff:ff:ff:ff:ff
    inet 192.168.35.11/24 brd 192.168.35.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 2001:16b8:504c:f300:20d:b9ff:fe16:6f4c/64 scope global dynamic mngtmpaddr 
       valid_lft 6827sec preferred_lft 3227sec
    inet6 fdb1:f000:199a:0:20d:b9ff:fe16:6f4c/64 scope global dynamic mngtmpaddr 
       valid_lft 6827sec preferred_lft 3227sec
    inet6 fe80::20d:b9ff:fe16:6f4c/64 scope link 
       valid_lft forever preferred_lft forever
5

Vergleiche hier die 2001:16b8:504c:f300:20d:b9ff:fe16:6f4c/64 vom
WAN-Interface des fli4l mit der 2001:16b8:504c:f3f1::1/64 vom
LAN-Interface des fli4l (s.o.). Auf dem WAN hat der fli4l eine IP aus
2001:16b8:504c:f300::/64 und das LAN ist 2001:16b8:504c:f3f1::/64,
beides Teil des selben /56, aber separate Netze, weil der fli4l-Router
die vom vorgelagerten Router auch über unterschiedliche Mechanismen
erhalten hat. Seine eigene Adresse hat er aus 2001:16b8:504c:f300::/64
und als Prefix für hinterlagerte Router 2001:16b8:504c:f3f0::/60
bekommen, woraus er dann wiederum ein /64 rausgenommen hat für dieses
eine LAN-Interface. Ein anderes LAN-Interface hat hier bspw.
2001:16b8:504c:f3f2::/64 und da sieht man leicht, dass es Teil des
selben /60 ist, das der fli4l über PD bekommen hat.

> Nur was die "Magie" angeht die dies "verarbeitet"
> und auf SLAAC Adressen umwandelt weiß ich nicht wie diese aussieht oder
> heißen sollte. Denn wenn er das Präfix nicht weiter delegieren kann dann
> geht es doch nur so.

Adressvergabe (bspw. über SLAAC) und Prefix Delegation sind zwei
verschiedene Dinge, das ist vielleicht am Beispiel von oben schon klar
geworden. Das erste sind direkt für das Endgerät nutzbare Adressen, das
zwei sind Addressbereiche ganzer Subnetze für hinterlagerte Netze.

>> Man kann die Adressen für die Clients theoretisch auch per DHCPv6
>> verteilen, aber ich meine das ist eher unüblich und die nötige DHCPv6
>> Client Software läuft auf vielen Endgeräten gar nicht?
>
> Die kann man ja aktivieren. Aber sowohl SLAAC als auch DHCPd6 wollen ja
> immer mit einem /64 Präfix arbeiten. Und das Problem ist ja das der
> Vorgelagerte Speedport Hybrid nur eines Raus gibt und das würde hier auf
> der WAN-Seite eines Zwischenrouters (wie u.a. FLI) landen.

Ja genau. Das heißt aber auch, dass Du keine global gerouteten Adressen
für Deine lokalen Netze nutzen kannst. Dass Dein vorgelagerter Speedport
keine Präfixe rausgibt, ist aber kein Problem von fli4l, sondern von dem
Gerät davor oder dem Provider davor.

> Da gibt es doch nur m.E. nur zwei möglichkeiten. von der SLAAC IP
> umsetzen (NAT6?, ???) auf die UniqueIP/64 

Das wäre äquivalent zu dem, was man mit NAT/Masquerading auch bei IPv4
macht. Dort bekommt man ja in der Regel auch nur genau eine öffentliche
IP-Adresse und keine ganzen Subnetze zum spielen.

> oder die Adressvergabe an den
> vorgelagerten Router durch zu leiten und von dort beziehen.

Mit anderen Worten: den fli4l komplett umgehen für IPv6? Ich sehe nicht,
wie das gehen soll.

> Und was davon kann man nun mit FLI machen? Und was macht er von Haus
> aus? Bin verwirrt.

Man kann mit fli4l NAT/Masquerading auch mit IPv6 machen. Das hat gerade
im Mai jemand im IRC berichtet.

Man kann versuchen die vorgelagerte Infrastruktur zu fixen, wobei das
nervige Telefonate mit dem Provider bedeuten kann.

Was noch geht, wüsste ich jetzt gerade nicht, von einem DHCPv6 relay in
dem sinne hab ich noch nicht gehört (was nicht heißt, dass es das nicht
gibt). Es reicht aber vermutlich nicht, den Clients eine Adresse zu
geben, sie müssten ja auch ihren Traffic loswerden. Für mich klingt Dein
Vorhaben im Moment wie eine hässliche Chimäre, IPv4-Clients sollen
hinter den fli4l-Router, aber IPv6-Clients sollen quasi ins selbe Netz
neben den fli4l-Router und die Clients sollen am besten beides
gleichzeitig und nicht durcheinander kommen. Puh.

Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6

Mehr Informationen über die Mailingliste Fli4L