info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
IPv6 EUI64 und 64-Bit interface identifier laut RFC 4291 erzwungen?
30 views
Skip to first unread message
Marco Moock
Jul 17, 2022, 3:16:16 AM7/17/22
to
Hallo zusammen,
es gab schonmal ne Diskussion zur Präfixlänge bei IPv6 hier, aber ich
mache das Fass wieder auf.
Aus technischer Sicht kann ich sagen, dass Präfixlängen !=64 problemlos
funktionieren (Autokonfiguration geht natürlich nicht). Hier getestet
mit nem Cisco-Router und Linux-Rechnern.
Jetzt habe ich aber RFC 4291 gelesen: ftp://ietf.org/rfc/rfc4291
Da steht:
| For all unicast addresses, except those that start with the binary
| value 000, Interface IDs are required to be 64 bits long and to be
| constructed in Modified EUI-64 format.
GUA ist aktuell 2000::/3, also ist die ersten 4 Bits sind 0010
und damit nicht 000.
Für 2000::/3 ist also festgelegt, dass der interface identifier 64 Bit
lang sein muss (die Präfixlänge damit auch) und dass modified EUI-64
gemacht werden muss.
Würde sich das nicht mit den Privacy Extensions und mit DHCPv6
(mit anderen Adressen) beißen (seitens der Spezifikation)?
Die Privacy Extensions sind mittlerweile ausgenommen, sind ja ebenso
als RF definiert.
Auch interessant ist ftp://ietf.org/rfc/rfc7421.txt
Da werden die Vor- und Nachteile von anderen Präfixlängen gelistet.
Zudem wird auch beschrieben, dass andere Präfixlängen in der Praxis
(meist mit DHCPv6) genutzt werden.
--
Marco
es gab schonmal ne Diskussion zur Präfixlänge bei IPv6 hier, aber ich
mache das Fass wieder auf.
Aus technischer Sicht kann ich sagen, dass Präfixlängen !=64 problemlos
funktionieren (Autokonfiguration geht natürlich nicht). Hier getestet
mit nem Cisco-Router und Linux-Rechnern.
Jetzt habe ich aber RFC 4291 gelesen: ftp://ietf.org/rfc/rfc4291
Da steht:
| For all unicast addresses, except those that start with the binary
| value 000, Interface IDs are required to be 64 bits long and to be
| constructed in Modified EUI-64 format.
GUA ist aktuell 2000::/3, also ist die ersten 4 Bits sind 0010
und damit nicht 000.
Für 2000::/3 ist also festgelegt, dass der interface identifier 64 Bit
lang sein muss (die Präfixlänge damit auch) und dass modified EUI-64
gemacht werden muss.
Würde sich das nicht mit den Privacy Extensions und mit DHCPv6
(mit anderen Adressen) beißen (seitens der Spezifikation)?
Die Privacy Extensions sind mittlerweile ausgenommen, sind ja ebenso
als RF definiert.
Auch interessant ist ftp://ietf.org/rfc/rfc7421.txt
Da werden die Vor- und Nachteile von anderen Präfixlängen gelistet.
Zudem wird auch beschrieben, dass andere Präfixlängen in der Praxis
(meist mit DHCPv6) genutzt werden.
--
Marco
Wuns Haerst
Jul 17, 2022, 1:32:46 PM7/17/22
to
Am 17.07.2022 um 09:16 schrieb Marco Moock:
> Hallo zusammen,
> es gab schonmal ne Diskussion zur Präfixlänge bei IPv6 hier, aber ich
> mache das Fass wieder auf.
>
> Aus technischer Sicht kann ich sagen, dass Präfixlängen !=64 problemlos
> funktionieren ...
> Hallo zusammen,
> es gab schonmal ne Diskussion zur Präfixlänge bei IPv6 hier, aber ich
> mache das Fass wieder auf.
>
> Aus technischer Sicht kann ich sagen, dass Präfixlängen !=64 problemlos
Aber nicht > 64.
Marco Moock
Jul 17, 2022, 3:13:45 PM7/17/22
to
Auffälligkeiten.
Zudem wurde in einem RFC auch beschrieben, dass /120 gerne in
Kombination mit DHCPv6 genutzt wird/wurde.
Hätte das Probleme gemacht wäre das sicher aufgefallen.
Wuns Haerst
Jul 18, 2022, 3:30:38 AM7/18/22
to
Am 17.07.2022 um 21:13 schrieb Marco Moock:
> Am Sonntag, 17. Juli 2022, um 19:33:40 Uhr schrieb Wuns Haerst:
>
>> Am 17.07.2022 um 09:16 schrieb Marco Moock:
>>> Hallo zusammen,
>>> es gab schonmal ne Diskussion zur Präfixlänge bei IPv6 hier, aber
>>> ich mache das Fass wieder auf.
>>>
>>> Aus technischer Sicht kann ich sagen, dass Präfixlängen !=64
>>> problemlos funktionieren ...
>>
>> Aber nicht > 64.
>
> hatte ich hier schon testweise für ein ULA in Betrieb. Keine
> Auffälligkeiten.
Da kommst Du dir ganz schön originell vor, Dinge zu tun die
> Am Sonntag, 17. Juli 2022, um 19:33:40 Uhr schrieb Wuns Haerst:
>
>> Am 17.07.2022 um 09:16 schrieb Marco Moock:
>>> Hallo zusammen,
>>> es gab schonmal ne Diskussion zur Präfixlänge bei IPv6 hier, aber
>>> ich mache das Fass wieder auf.
>>>
>>> Aus technischer Sicht kann ich sagen, dass Präfixlängen !=64
>>> problemlos funktionieren ...
>>
>> Aber nicht > 64.
>
> hatte ich hier schon testweise für ein ULA in Betrieb. Keine
> Auffälligkeiten.
sonst kein anderer tut. Die andren tun es nicht weil es eben
sinnloser Schnickschnack ist.
Marco Moock
Jul 18, 2022, 2:27:29 PM7/18/22
to
Am Montag, 18. Juli 2022, um 09:31:34 Uhr schrieb Wuns Haerst:
> Am 17.07.2022 um 21:13 schrieb Marco Moock:
> > hatte ich hier schon testweise für ein ULA in Betrieb. Keine
> > Auffälligkeiten.
>
> Da kommst Du dir ganz schön originell vor, Dinge zu tun die
> sonst kein anderer tut. Die andren tun es nicht weil es eben
> sinnloser Schnickschnack ist.
Nicht nur ich, das haben auch schon andere gemacht.
> Am 17.07.2022 um 21:13 schrieb Marco Moock:
> > hatte ich hier schon testweise für ein ULA in Betrieb. Keine
> > Auffälligkeiten.
>
> Da kommst Du dir ganz schön originell vor, Dinge zu tun die
> sonst kein anderer tut. Die andren tun es nicht weil es eben
> sinnloser Schnickschnack ist.
Es gäbe da auch einen Einsatzzweck der mir einfällt: Mann kann kleinere
Netze als Admin schneller abscannen, um sich eine Übersicht der Rechner
geben zu lassen.
Wuns Haerst
Jul 18, 2022, 10:59:29 PM7/18/22
to
Am 18.07.2022 um 20:27 schrieb Marco Moock:
> Am Montag, 18. Juli 2022, um 09:31:34 Uhr schrieb Wuns Haerst:
>
>> Am 17.07.2022 um 21:13 schrieb Marco Moock:
>>> hatte ich hier schon testweise für ein ULA in Betrieb. Keine
>>> Auffälligkeiten.
>>
>> Da kommst Du dir ganz schön originell vor, Dinge zu tun die
>> sonst kein anderer tut. Die andren tun es nicht weil es eben
>> sinnloser Schnickschnack ist.
>
> Nicht nur ich, das haben auch schon andere gemacht.
Das ist sicher kein Zeichen von Expertise, sondern von Dummheit.
> Am Montag, 18. Juli 2022, um 09:31:34 Uhr schrieb Wuns Haerst:
>
>> Am 17.07.2022 um 21:13 schrieb Marco Moock:
>>> hatte ich hier schon testweise für ein ULA in Betrieb. Keine
>>> Auffälligkeiten.
>>
>> Da kommst Du dir ganz schön originell vor, Dinge zu tun die
>> sonst kein anderer tut. Die andren tun es nicht weil es eben
>> sinnloser Schnickschnack ist.
>
> Nicht nur ich, das haben auch schon andere gemacht.
> Es gäbe da auch einen Einsatzzweck der mir einfällt: Mann kann kleinere
> Netze als Admin schneller abscannen, um sich eine Übersicht der Rechner
> geben zu lassen.
Marco Moock
Jul 19, 2022, 2:38:43 AM7/19/22
to
Am Dienstag, 19. Juli 2022, um 05:00:15 Uhr schrieb Wuns Haerst:
> Wieso soll man sein eigenes Netz abscannen, was man sowieso kennt?
Gerade im Firmenumfeld ist sowas manchmal gewünscht, um zu prüfen,
> Wieso soll man sein eigenes Netz abscannen, was man sowieso kennt?
welche Geräte da sind und ob die Serverdienste anbieten (bei Windows
ist das standardmäßig so). So kann man dann gezielt ein paar hundert
Adressen per NDP-Abfrage auf Erreichbarkeit prüfen und dann
gezielt Portscans durchführen.
Das ist bei /64 aufgrund der Anzahl der Adressen nicht sinnvoll machbar.
Da kann man die all-nodes-link-local-Multicast-Adresse pingen, nur
antworten da nicht alle Systeme drauf (Windows bei FW mit Profil
öffentlich z.B. nicht).
Eine andere Möglichkeit wäre, den NDP-Cache beim Router zu nutzen. Dann
muss aber in den letzten Stunden Traffic vorhanden gewesen sein.
Wuns Haerst
Jul 19, 2022, 8:31:16 AM7/19/22
to
Am 19.07.2022 um 08:38 schrieb Marco Moock:
>> Wieso soll man sein eigenes Netz abscannen, was man sowieso kennt?
> Gerade im Firmenumfeld ist sowas manchmal gewünscht, ...
>> Wieso soll man sein eigenes Netz abscannen, was man sowieso kennt?
Du hast zu viel Phantasie.
Wuns Haerst
Jul 19, 2022, 8:32:29 AM7/19/22
to
Am 19.07.2022 um 08:38 schrieb Marco Moock:
> Da kann man die all-nodes-link-local-Multicast-Adresse pingen, nur
> antworten da nicht ...
Ja, ist ja auch so wahrscheinlich, dass jemand in einer Firma
auf dem Client eine SOHO-Firewall nutzt. Was rauchst Du eigentlich?
Marc Haber
Jul 19, 2022, 8:51:44 AM7/19/22
to
hier diesen Diskussionsstil erlauben?
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Marco Moock
Jul 19, 2022, 8:57:12 AM7/19/22
to
Am Dienstag, 19. Juli 2022, um 14:51:43 Uhr schrieb Marc Haber:
> Wer bist Du, was kannst Du, wo kommst Du her, und warum kannst Du Dir
> hier diesen Diskussionsstil erlauben?
Weil es höchstwahrscheinlich der Vollidiot "Bonita Montero" mit neuen
> Wer bist Du, was kannst Du, wo kommst Du her, und warum kannst Du Dir
> hier diesen Diskussionsstil erlauben?
Account bei aioe ist. Der ist halt nicht so helle.
Ich würde vorschlagen, dass wir den jetzt ignorieren und einfach nicht
mehr drauf eingehen. Dann hat er kein Publikum mehr und fühlt sich
schlecht. Muhaha. ]:-)
Peter J. Holzer
Jul 19, 2022, 11:57:09 AM7/19/22
to
On 2022-07-19 06:38, Marco Moock <mo...@posteo.de> wrote:
> Am Dienstag, 19. Juli 2022, um 05:00:15 Uhr schrieb Wuns Haerst:
>> Wieso soll man sein eigenes Netz abscannen, was man sowieso kennt?
>
> Gerade im Firmenumfeld ist sowas manchmal gewünscht, um zu prüfen,
> welche Geräte da sind und ob die Serverdienste anbieten (bei Windows
> ist das standardmäßig so). So kann man dann gezielt ein paar hundert
> Adressen per NDP-Abfrage auf Erreichbarkeit prüfen und dann
> gezielt Portscans durchführen.
Das letzte mal, dass ich das gebraucht habe, war für IPv4-Netze. Da habe
> Am Dienstag, 19. Juli 2022, um 05:00:15 Uhr schrieb Wuns Haerst:
>> Wieso soll man sein eigenes Netz abscannen, was man sowieso kennt?
>
> Gerade im Firmenumfeld ist sowas manchmal gewünscht, um zu prüfen,
> welche Geräte da sind und ob die Serverdienste anbieten (bei Windows
> ist das standardmäßig so). So kann man dann gezielt ein paar hundert
> Adressen per NDP-Abfrage auf Erreichbarkeit prüfen und dann
> gezielt Portscans durchführen.
ich aber auch nicht die Netze gescannt, sondern die Switches abgefragt,
auf welchem Port welche MAC-Adresse(n) erreichbar sind und auf
ARP-Requests gelauscht, um das IP/MAC-Mapping zu bekommen. So hatte ich
eine stets aktuelle Liste, was wo dranhängt und von neuen Geräten konnte
ich innerhalb von Minuten verständigt werden. Das sollte sinngemäß auch
bei IPv6 funktionieren, alle 281474976710656 möglichen Adressen in einem
/48 durchzuprobieren ist also nicht notwendig :-).
hp
Marco Moock
Jul 19, 2022, 1:44:03 PM7/19/22
to
Am Dienstag, 19. Juli 2022, um 17:57:07 Uhr schrieb Peter J. Holzer:
> Das letzte mal, dass ich das gebraucht habe, war für IPv4-Netze. Da
> habe ich aber auch nicht die Netze gescannt, sondern die Switches
> abgefragt, auf welchem Port welche MAC-Adresse(n) erreichbar sind und
> auf ARP-Requests gelauscht, um das IP/MAC-Mapping zu bekommen. So
> hatte ich eine stets aktuelle Liste, was wo dranhängt und von neuen
> Geräten konnte ich innerhalb von Minuten verständigt werden. Das
> sollte sinngemäß auch bei IPv6 funktionieren, alle 281474976710656
> möglichen Adressen in einem /48 durchzuprobieren ist also nicht
> notwendig :-).
Das ist richtig, das geht auch. Ich nutze hierfür einfach den NDP-Cache
> Das letzte mal, dass ich das gebraucht habe, war für IPv4-Netze. Da
> habe ich aber auch nicht die Netze gescannt, sondern die Switches
> abgefragt, auf welchem Port welche MAC-Adresse(n) erreichbar sind und
> auf ARP-Requests gelauscht, um das IP/MAC-Mapping zu bekommen. So
> hatte ich eine stets aktuelle Liste, was wo dranhängt und von neuen
> Geräten konnte ich innerhalb von Minuten verständigt werden. Das
> sollte sinngemäß auch bei IPv6 funktionieren, alle 281474976710656
> möglichen Adressen in einem /48 durchzuprobieren ist also nicht
> notwendig :-).
des Routers. Bei Cisco kann man den auslesen. Bei Heimroutern leider
oft nicht.
Zudem funktioniert das ja mit dem ARP-Cache bei IPv4. Praktisch am Scan
ist halt, dass man damit wirklich alle Geräte erwischt - auch wenn
diese für ein paar Stunden keinen Traffic hatten, z.B. bei einem
Drucker.
0 new messages