14
FritzBox erstes LAN-Prefix für WAN nutzen - wie funktioniert das Routing zum Kunden?
Hallo zusammen,
wie funktioniert das Routing beim Provider, wenn man in der FB die Option nutzt, das erste /64er-Netz aus dem LAN-Prefix (manuell eingegeben oder per DHCPv6-PD) für das Transportnetz (WAN) zu nutzen?
Konfigurationsbeispiel: https://www.tal.de/fileadmin/anleitungen/IPv6_Fritzbox/ipv6-2.png
Für das ausgehende Routing (Kunde --> Provider) wäre das Router-Advertisement vom Provider nutzbar, aber wie findet der Provider sicher die WAN-Adresse des Kunden-Routers raus, um das in seine Routingtabelle zu packen?
Die FB nimmt ihren eigenen Interface-Identifier (vermutlich MAC-Adresse) + dieses /64er-Präfix als WAN-IP. Natürlich könnte der Provider die DAD-Nachrichten lesen und anhand dieser die eigene Routingtabelle (Provider --> Kunde) füllen, weil da ja die Adresse drinstehen muss. Doch wird das wirklich so gemacht oder gibt es da einen anderen Mechanismus?
IP6CP und DHCPv6 sind mir bekannt, werden in diesem Beispiel aber (vermutlich?) nicht eingesetzt (oder doch)?
Gruß
Marco
wie funktioniert das Routing beim Provider, wenn man in der FB die Option nutzt, das erste /64er-Netz aus dem LAN-Prefix (manuell eingegeben oder per DHCPv6-PD) für das Transportnetz (WAN) zu nutzen?
Konfigurationsbeispiel: https://www.tal.de/fileadmin/anleitungen/IPv6_Fritzbox/ipv6-2.png
Für das ausgehende Routing (Kunde --> Provider) wäre das Router-Advertisement vom Provider nutzbar, aber wie findet der Provider sicher die WAN-Adresse des Kunden-Routers raus, um das in seine Routingtabelle zu packen?
Die FB nimmt ihren eigenen Interface-Identifier (vermutlich MAC-Adresse) + dieses /64er-Präfix als WAN-IP. Natürlich könnte der Provider die DAD-Nachrichten lesen und anhand dieser die eigene Routingtabelle (Provider --> Kunde) füllen, weil da ja die Adresse drinstehen muss. Doch wird das wirklich so gemacht oder gibt es da einen anderen Mechanismus?
IP6CP und DHCPv6 sind mir bekannt, werden in diesem Beispiel aber (vermutlich?) nicht eingesetzt (oder doch)?
Gruß
Marco
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5020209435
Url: https://administrator.de/forum/fritzbox-erstes-lan-prefix-fuer-wan-nutzen-wie-funktioniert-das-routing-zum-kunden-5020209435.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
14 Kommentare
Neuester Kommentar
wie findet der Provider sicher die WAN-Adresse des Kunden-Routers raus
https://danrl.com/ipv6/Dan%20Lüdtke%20-%20IPv6-Workshop%20%5BDritte ...Seite 114 ff. 😉
aber wie findet der Provider sicher die WAN-Adresse des Kunden-Routers raus, um das in seine Routingtabelle zu packen?
Der Provider vergibt doch selbst das Subnet das der Kunde per Prefix-Delegation zugewiesen bekommt (z.B. 56er). Und aus diesem Subnet nimmt sich der Kunden-Router dann bspw. das erste 64er Netz.Da dieses 64er Netz bereits im 56er enthalten ist und dadurch bereits zum Kunden geroutet wird sind schon alle nötigen Routen beim Provider vorhanden
. Die LinkLocal-Address fürs Routing zwischen Provider und Kunde erhält der Provider beim PD-Vorgang über das ND Solicitation an die DHCPv6 Server.Gruß S.
Quote from @4863114660:
Der Provider vergibt doch selbst das Subnet das der Kunde per Prefix-Delegation zugewiesen bekommt (z.B. 56er). Und aus diesem Subnet nimmt sich der Kunden-Router dann bspw. das erste 64er Netz.
Der Provider vergibt doch selbst das Subnet das der Kunde per Prefix-Delegation zugewiesen bekommt (z.B. 56er). Und aus diesem Subnet nimmt sich der Kunden-Router dann bspw. das erste 64er Netz.
Das wäre dann DHCPv6. Der von mir genannte Provider macht aber kein DHCPv6-PD, sonder gibt einem das feste Präfix direkt. Natürlich könnte der eigene Router trotzdem per DHCPv6 ne Adresse bekommen, sofern man DHCPv6 aktiviert hat.
Das bleibt technisch dann trotzdem so wie schlepper es beschreibt — nur anstatt mit DHCP mit statischen Informationen auf beiden Seiten 
Zitat von @LordGurke:
Das bleibt technisch dann trotzdem so wie schlepper es beschreibt — nur anstatt mit DHCP mit statischen Informationen auf beiden Seiten
Das bleibt technisch dann trotzdem so wie schlepper es beschreibt — nur anstatt mit DHCP mit statischen Informationen auf beiden Seiten
Eben. 😉
Vielleicht sollte sich der TO mal mit dem Neighbor Discovery intensiver auseinandersetzen
https://www.computernetworkingnotes.com/networking-tutorials/ipv6-neighb ...
Die von @aqui genannte Lektüre geht da natürlich noch mehr ins Detail, die sollte Pflicht sein wenn man mit IPv6 arbeitet.
Wenn der Provider als Einwahl bspw. PPPoE nutzt ist das Prefix in deren Radius DB für den jeweiligen Account hinterlegt, Traffic an dieses Subnet wird dann automatisch auf diese PPPoE Session geroutet.
Da PPP sieht der Provider-Router innerhalb dieser Session auch nur den Kundenrouter. Works as designed.
1
Bei PPP findet realistisch betrachtet überhaupt keine ND statt, du schickst einfach alles was zur Session gehört in den PPP-Tunnel hinein — es gibt ja nur die eine Gegenstelle.
1Zitat von @LordGurke:
Bei PPP findet realistisch betrachtet überhaupt keine ND statt, du schickst einfach alles was zur Session gehört in den PPP-Tunnel hinein — es gibt ja nur die eine Gegenstelle.
Bei PPP findet realistisch betrachtet überhaupt keine ND statt, du schickst einfach alles was zur Session gehört in den PPP-Tunnel hinein — es gibt ja nur die eine Gegenstelle.
Bedeutet das, dass für die IP-Adressen keine neighbor solicitation/advertisement wie bei Ethernet stattfindet?
Der Rest vom NDP wird in machen Fällen ja benötigt.
Ein Router Advertisement (eigentlich auch Teil des NDP) scheint es in manchen Konfigurationen zu geben, so käme man an die IPv6-Adresse vom Router für die eigene Routingtabelle.
Das steht auch in folgendem Dokument: https://www.broadband-forum.org/download/TR-187.pdf
"In contrast with IPCP which provides other configuration information, IPV6CP only negotiates an interface identifier. Other configuration information is provided via Neighbor Discovery and DHCPv6."
Das würde dann eigentlich ausreichen. Provider und Kunde handeln den interface-identifier aus, Kundenrouter nimmt erstes /64er-Präfix und baut sich die Adresse, Provider-Router schreibt diese in seine Routingtabelle. Kunden-Router bekommt durch RA die IP (link-local) vom Router.
PS: Ich werde meinen Router konfigurieren und dann am Schalttag sehen, ob das IPv6-Routing funktioniert.
Stimmt, ich meinte nur Neighbor Solicitation (und generell alles was bei Point-to-Point nicht benötigt wird).
Bei PPP bist du mit einer einzigen Gegenstelle verbunden, es macht also keinen Sinn per ND nach einer Gegenstelle zu suchen
Davon abgesehen ist eine PPP-Verbindung ein reiner Layer 3-Transport, eine Auflösung von IP-Adressen in MAC-Adressen kann also prinzipbedingt nicht stattfinden.
Bei PPP bist du mit einer einzigen Gegenstelle verbunden, es macht also keinen Sinn per ND nach einer Gegenstelle zu suchen
Davon abgesehen ist eine PPP-Verbindung ein reiner Layer 3-Transport, eine Auflösung von IP-Adressen in MAC-Adressen kann also prinzipbedingt nicht stattfinden.
1
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread als erledigt zu markieren!
Es gibt neue Erkenntnisse und die sind recht banal: Bei PPP reicht es, wenn der Kram einfach in den Tunnel geht, keine NDS/NDA für MAC-Adressen notwendig.
Es werden bei sh ipv6 neigh auch keine angezeigt.
Hier ausführlicher:
https://de.comm.provider.misc.narkive.com/CPra9jFA/tal-de-ipv6-wan-konfi ...
Es werden bei sh ipv6 neigh auch keine angezeigt.
Hier ausführlicher:
https://de.comm.provider.misc.narkive.com/CPra9jFA/tal-de-ipv6-wan-konfi ...
bei sh ipv6 neigh auch keine angezeigt.
Jetzt bist du aber bei einem Cisco, oder? Eine FritzBox kennt so ein Kommando ja nicht. 😉
Richtig, aber ich musste halt vorher abklären, was da technisch passiert, damit ich das passend beim Cisco einrichten kann.
Und dabei habe ich mehr über PPP und IPv6CP gelernt als in den ganzen vergangenen Jahren.
Und dabei habe ich mehr über PPP und IPv6CP gelernt als in den ganzen vergangenen Jahren.
damit ich das passend beim Cisco einrichten kann.
Steht doch schon alles im Tutorial?! 😉Und dabei habe ich mehr über PPP und IPv6CP gelernt
👍 So sollte es sein...Zitat von @aqui:
damit ich das passend beim Cisco einrichten kann.
Steht doch schon alles im Tutorial?! 😉Ja, aber ich wusste halt nicht, wie dieser ISP das macht und ob man da z.B. DHCPv6 zwingend braucht. Daher veröffentliche ich das, sodass ich a) später nachgucken kann und b) andere nicht die gleiche Frage haben.
