Netzwerkmasken, IPs und Netze, reservierte IP-Adressen

[TS]

Hello,

ist es erlaubt, das Netz 0.0.0.0 zu benutzen, egal mit welcher Netzwerkmaske?

Haben die IPs 10.0.0.0 und 16.0.0.0 ein gültiges gemeinsames (kleinstes) Netzwerk?

Freue mich auf kreative Antworten und viele Links zu ggf. widersprüchlichen Quellen.

[edit 20181030-2000 ff, TS]

1. Kapitel: Reservierte IP-Adressen und Subnetze
2. Reservierte IPv4-Adressen

[edit 20181031-0915, TS]
Ist bei CIDR das Netz 1.1.0.0/16 zulässig?

Glück Auf
Tom vom Berg

[pl]

Hello,

ist es erlaubt, das Netz 0.0.0.0 zu benutzen, egal mit welcher Neetzwerkmaske?

Guck mal bei Cisco Subnet Zero

Haben die IPs 10.0.0.0 und 16.0.0.0 ein gültiges gemeinsames (klienstes) Netzwerk?

Das lässt sich berechnen. Stichworts: Supernetting, summarize route

Keine Ursache.

[Rolf B]

Hallo Tom,

ich weiß gerade nicht welche Widersprüche Du siehst.

Das Netz 0.0.0.0/8 ist sozusagen der this-Pointer deines Computers. Ob Du es nun mit Präfixlänge 8 oder 31 verwendest, die Definition von IPv4 sagt: 0.0.0.0/8 ist Dein Computer und darf nur eine Absender-IP sein.

Anders wäre das wenn Du bspw. 0.0.0.0/7 verwenden würdest - in dem Moment könntest Du die Subnetzadresse 1.0.0.0 als Subnetz von 0.0.0.0/7 betrachten. Das würde aber mit dem ehemaligen reservierten Class A Netz 1.0.0.0/8 kollidieren, das mittlerweile vom APNIC verwaltet wird. Präfixlängen die kleiner als 8 sind, sind formal erlaubt, aber praktisch im existierenden Netz nicht einsetzbar. Es sei denn, du bleibst damit brav hinter deinem Router und verzichtest auf die Nutzung der von deinem eigenen Range überlagerten Internet-Adressen.

Das Class A Netz 10.0.0.0/8 ist reserviert. Adressen dieses Netzes dürfen nicht als Internetadresse verwendet werden, weil es zum Aufbau von Intranets vorgesehen ist. D.h. wenn die Firma Ten-Masters die IP 10.10.10.10 haben wollte, wäre sie aus keinem Groß-Intranet dieser Welt heraus erreichbar. Weil der Router die IP-Pakete, die dorthin sollen, aus dem Intranet nicht hinauslässt.

16.0.0.0/8 ist dagegen als historische Altlast Hewlett Packard zugeteilt und damit kein Intranet.

Wenn diese Sonderrolle von 10.0.0.0/8 nicht wäre, könnte man rein theoretisch einen Ansatz für eine gemeinsame Netzwerkmaske finden:

10.0.0.0/8 = 00001010.xxxxxxxx.xxxxxxxx.xxxxxxxx  
16.0.0.0/8 = 00010000.xxxxxxxx.xxxxxxxx.xxxxxxxx  
Maske:       11100101.00000000.00000000.00000000  

Damit ist man aber dann gescheitert, denn man hat kein zusammenhängendes Präfix. Man müsste also das Netz 0.0.0.0/3 verwenden, es würde die Class A Klassen 0-31 überdecken und wäre die genaueste gültige Netzwerkmaske, die das 10er und 16er Netz umfasst .

Rolf

[pl]

Unterscheide zwischen classless und classful!

Ein Router der classful konfiguriert ist, entscheidet anhand der führenden Bits ob der Classe A,B,C,D oder E.

Siehe auch hier.

[dedlfix]

Tach!

Unterscheide zwischen classless und classful!

Welche Rolle spielen heutzutage noch Router, die nur classful routen?

dedlfix.

[TS]

Hello,

Unterscheide zwischen classless und classful! Welche Rolle spielen heutzutage noch Router, die nur classful routen?

Da muss ich nur in eine meiner Kisten greifen, wenn ich mal wieder Geräte-Engpass habe und schon ist solch ein Gerät wieder aktiv ;-P

Und die alten Gurken können sogar noch "Übergriffskonfiguration", also mit Nullen zwischen den Einsen in der Netzwerkmaske...
Zum Glück hat man sich davon verabschiedet!

Glück Auf
Tom vom Berg

[pl]

Es dient dem Verständnis in Sachen IP!

So ist in classful die Default class eines localhost mit der IP 127.1.2.3 ein Class A Netz mit 16777214 möglichen localhosts.

Weil:

printf "%08b", 127; # 01111111

# führende Bits in erster Oktette
# bestimmen die Default Class
0    class A  0-127
10   class B  128-191
110  class C  192-223
111  class D  224-239
1111 class E  ab 240

im ersten Bit eine 0 steht.

Welche Rolle spielen heutzutage noch Router, die nur classful routen?

Classful hat mit Routing nichts zu tun sondern mit Class!

MfG

[TS]

Hello,

danke für die Antwort. (+1)

Allerdings klärt sie (für mich) noch nicht eindeutig die Frage, ob das Netz 0.0.0.0 benutzt werden darf. Die Aussagen (auch im Web) bewegen sich nach meinem Empfinden immer noch im "Radio-Eriwan-Bereich".

Glück Auf
Tom vom Berg

[Christian Kruse]

Hallo TS,

Allerdings klärt sie (für mich) noch nicht eindeutig die Frage, ob das Netz 0.0.0.0 benutzt werden darf.

Nein, darf es nicht. 0.0.0.0 ist reserviert, siehe RFC8190. 0.0.0.0 ist eine nicht-routbare Meta-Adresse, die als Host-Adresse auf für „irgendeine IP-Adresse“ (INADDR_ANY), als Netzwerk-Adresse für „dieses Netzwerk“ und als Route für den Default-Gateway steht. DHCPDISCOVER geht iirc auch an diese Adresse.

Don't do that, hic sunt dracones!

LG,
CK

[pl]

Allerdings klärt sie (für mich) noch nicht eindeutig die Frage, ob das Netz 0.0.0.0 benutzt werden darf.

Nein, darf es nicht. 0.0.0.0 ist reserviert, siehe RFC8190. 0.0.0.0 ist eine nicht-routbare Meta-Adresse,

0.0.0.0 ist eine Netzadresse. Erst wenn eine Maske angegeben ist, ergibt sich die Broadcastadresse und damit ein Adressbereich bzw. BLock. So stehts in RFC s.o.

MfG

[Christian Kruse]

Hallo pl,

was möchtest du mir sagen? Deine Aussage und das stehengelassene Zitat von mir kann ich nicht in Zusammenhang bringen.

LG,
CK

[Rolf B]

Hallo Christian,

wieder was gelernt, man muss mehrere RFC lesen. Es gibt verschiedene Angaben zur Bedeutung von 0.0.0.0/8. Mit RFC1122 wird es klar: 0.0.0.0 (Adresse) ist der eigene Computer im eigenen Netz, 0.x.x.x steht für "ein Host in diesem Netzwerk". Und dahinter steht jeweils: MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address.

Vermutlich müsste ich jetzt noch ARP studieren um zu wissen, was damit genau gemeint ist.

Deine Gleichsetzung von 0.0.0.0 als INADDR_ANY ist aber eine Eigenschaft des Socket-API der C Runtime, die dem eigentlich verbotenen Wert \x00000000 eine Sonderrolle zuweist: INADDR_ANY bindet den Socket an alle lokalen Interfaces.

Rolf

[Christian Kruse]

Hallo Rolf,

wieder was gelernt, man muss mehrere RFC lesen. Es gibt verschiedene Angaben zur Bedeutung von 0.0.0.0/8. Mit RFC1122 wird es klar: 0.0.0.0 (Adresse) ist der eigene Computer im eigenen Netz, 0.x.x.x steht für "ein Host in diesem Netzwerk". Und dahinter steht jeweils: MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address.

Das ist mir im wesentlichen bekannt, es widerspricht nur nicht dem, was ich geschrieben habe. Zumindest sehe ich nicht, wo es widersprechen sollte. Ich schrieb ja explizit mehrere Anwendungsfälle auf um klarzumachen, dass die Bedeutung vom Kontext abhängig ist. Meine Rückfrage bezieht sich also darauf, dass ich ganz explizit nicht verstehe, was Hotti mir sagen will. Er scheint mir widersprechen zu wollen, aber ich weiß nicht inwiefern.

Vermutlich müsste ich jetzt noch ARP studieren um zu wissen, was damit genau gemeint ist.

Damit ist das hier gemeint.

Deine Gleichsetzung von 0.0.0.0 als INADDR_ANY ist aber eine Eigenschaft des Socket-API der C Runtime, die dem eigentlich verbotenen Wert \x00000000 eine Sonderrolle zuweist: INADDR_ANY bindet den Socket an alle lokalen Interfaces.

Ja. Wie gesagt: es steht für „(irgend)eine IP-Adresse“ (im eigenen Netz). Die C-API widerspricht da dem RFC nicht.

LG,
CK

[Rolf B]

Hallo Christian,

was Hotti genau meint weiß ich auch nicht, aber meine Einrede war, dass laut IPv4 Protokoll mehr als 0.0.0.0 reserviert ist. 0.0.0.0/8 ist ein ganzes Class A Netz, das offenbar für die IP-Adresszuweisung reserviert ist, und die erste Adresse davon hat nochmal die von Dir genannte Sonderbedeutung. Irgendwie liest sich das von Hotti ähnlich.

Und für Tom bleibt hier nur übrig: Finger weg. Dicke Eidechsen und so...

Zur Diskussion über special values im C API: Ja, ich hätte genauer auf das META in deinem Beitrag achten sollen.

Rolf

[Christian Kruse]

Hallo Rolf,

was Hotti genau meint weiß ich auch nicht, aber meine Einrede war, dass laut IPv4 Protokoll mehr als 0.0.0.0 reserviert ist. 0.0.0.0/8 ist ein ganzes Class A Netz, das offenbar für die IP-Adresszuweisung reserviert ist, und die erste Adresse davon hat nochmal die von Dir genannte Sonderbedeutung.

Nachdem ich meinen Beitrag nochmal geprüft habe: ja, das hätte ich explizit erwähnen sollen. Für mich war das offensichtlich, aber aus dem Beitrag kann man das nicht herauslesen, stimmt – dazu müsste man meinem Link auf die RFC folgen, erst dort wird das erwähnt.

👍 danke für die Ergänzung.

LG,
CK

[ursus contionabundo]

DHCPDISCOVER geht iirc auch an diese Adresse.

Wikipedia behauptet:

Wenn ein Client erstmals eine IP-Adresse benötigt, schickt er eine DHCPDISCOVER-Nachricht (mit seiner MAC-Adresse) … Dieser Broadcast hat als Absender-IP-Adresse 0.0.0.0 und als Zieladresse 255.255.255.255

Das sind aber eher Platzhalter im Paket. Denn eigentlich geht das im OSI-Level 2 an die MAC-Adresse FF:FF:FF:FF:FF:FF (An "alle"). Die Nachricht bleibt aber im eigenen lokalen Netz, wird nicht geroutet.

Wikipedia behauptet weiter:

Die DHCP-Server antworten mit DHCPOFFER und machen Vorschläge für eine IP-Adresse. Das geschieht entweder mit einem Broadcast an die Adresse 255.255.255.255 mit UDP-Quellport 67 und UDP-Zielport 68 oder mit einem Unicast an die vorgeschlagene IP-Adresse und die MAC-Adresse des Clients, je nachdem ob der Client in der DHCPDISCOVER-Nachricht das Broadcast-Bit gesetzt hat.

In der Regel dürfte das Broadcast-Bit aber gesetzt sein.

0.0.0.0 als IP steht für "weltweit lesbar" (Verwendung aber auch als Synonym für "jede eigene IP-Adresse", mysql: bind-address = 0.0.0.0). 255.255.255.255 ist (wie die DHCP-Geschichte zeigt) eine Art "Super-Broadcast-Adresse".

[Christian Kruse]

Hallo ursus,

Das sind aber eher Platzhalter im Paket. Denn eigentlich geht das im OSI-Level 2 an die MAC-Adresse FF:FF:FF:FF:FF:FF (An "alle").

Ja, das ist ein Platzhalter. Verwenden sollte man diese Adresse halt trotzdem nicht 😉

Die Nachricht bleibt aber im eigenen lokalen Netz, wird nicht geroutet.

Deshalb schrieb ich auch „nicht-routbare Meta-Adresse.“

(Verwendung aber auch als Synonym für "jede eigene IP-Adresse"

Nein, das ist ein Übersetzungsfehler der deutschen Wikipedia. Es steht nicht für „jede eigene Adresse,“ sondern für „eine beliebige Adresse.“ Bei Sockets würde man INADDR_ANY setzen.

mysql: bind-address = 0.0.0.0)

Ja, genau. INADDR_ANY, eine beliebige Adresse.

LG,
CK

[ursus contionabundo]

Ja, das ist ein Platzhalter. Verwenden sollte man diese Adresse halt trotzdem nicht

Gute Güte: tunlichst nicht!

Ja, genau. INADDR_ANY, eine beliebige Adresse.

Nein ungenau: INADDR_ANY, jede beliebige eigene Adresse beim Listen, beim Senden (Request) wird zumeist 127.0.0.1 gewählt. (Ping, Nmap, Http)

[Christian Kruse]

Hallo ursus,

Ja, genau. INADDR_ANY, eine beliebige Adresse.

Nein ungenau: INADDR_ANY, jede beliebige eigene Adresse beim Listen,

Den listen()-Kontext gab dein Beispiel vor, deshalb habe ich den nicht mehr erwähnt 😉

beim Senden (Request) wird zumeist 127.0.0.1 gewählt. (Ping, Nmap, Http)

War das nicht eher so, dass beim Senden das „erste“ Interface gewählt wird? Mal googeln… hm, ich finde nichts sinnvolles. In der Manpage steht nur „an appropriate interface is chosen by the system.“

LG,
CK

[ursus contionabundo]

beim Senden (Request) wird zumeist 127.0.0.1 gewählt. (Ping, Nmap, Http)

War das nicht eher so, dass beim Senden das „erste“ Interface gewählt wird? Mal googeln… hm, ich finde nichts sinnvolles. In der Manpage steht nur „an appropriate interface is chosen by the system.“

Das ist kein Widerspruch. Der localhost (lo) dürfte stets das erste Interface sein, denn für den braucht es keinen Treiber. Es ist vorhanden und "geeignet".

Freilich könnte ein Progger auf die Idee kommen /etc/network/interfaces auszuwerten und das erste Gerät zu suchen, dann zu prüfen ob es auch bereit ist, ggf. das nächste und so weiter. Aber da stellt er sich ein Bein. Erstens: Mehrarbeit. Denn 127.0.0.1 ist per Definition nach dem Starten des Netzwerkes ein vorhandenes(!) "appropriate interface" (geeignete Schnittstelle) und Zweitens stellt sich die Frage, wie viel Arbeit er sich aufhalsen will, wenn es mal /etc/network/interfaces nicht mehr gibt oder wenn er sein Programm z.B. für Windows oder DOS kompilieren will.

[Christian Kruse]

Hallo ursus,

beim Senden (Request) wird zumeist 127.0.0.1 gewählt. (Ping, Nmap, Http)

War das nicht eher so, dass beim Senden das „erste“ Interface gewählt wird? Mal googeln… hm, ich finde nichts sinnvolles. In der Manpage steht nur „an appropriate interface is chosen by the system.“

Das ist kein Widerspruch.

Nicht zwangsläufig, aber möglicherweise. Und du wolltest es ja genau 😉

Der localhost (lo) dürfte stets das erste Interface sein, denn für den braucht es keinen Treiber.

Hm. Da bin ich nicht so sicher, bzw ich würde diese Behauptung nicht argumentieren müssen wollen. Ein Nachweis fiele mir schwer. Das Gegenteil zu beweisen allerdings auch.

Freilich könnte ein Progger auf die Idee kommen /etc/network/interfaces auszuwerten

/etc/network/interfaces ist ein Debian-Konstrukt. Für Arch etwa gibt es das gar nicht.

LG,
CK

[ursus contionabundo]

Der localhost (lo) dürfte stets das erste Interface sein, denn für den braucht es keinen Treiber.

Hm. Da bin ich nicht so sicher, bzw ich würde diese Behauptung nicht argumentieren müssen wollen. Ein Nachweis fiele mir schwer. Das Gegenteil zu beweisen allerdings auch.

Ich hatte an Treiber für reale (oder virtuell bereit gestellte) Hardware gedacht.

[TS]

Hello,

beim Senden (Request) wird zumeist 127.0.0.1 gewählt. (Ping, Nmap, Http)

War das nicht eher so, dass beim Senden das „erste“ Interface gewählt wird? Mal googeln… hm, ich finde nichts sinnvolles. In der Manpage steht nur „an appropriate interface is chosen by the system.“

Das kann man zuweisen. Aber frage mich bitte nicht, wo dies genau geschieht. Ich benutze die Möglichkeiten jedenfalls intensiv bei meinen PHP-Localhost-Versuchen. Da kennzeichne ich die unterschiedlichen VirtHosts auch mit mehreren unterschiedlichen 127.x.x.x-IPs und trage diese auch brav in meine Hosts- oder LMHosts-Dateien ein.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

an appropriate interface is chosen by the system

Was appropriate ist, kann auch durch die Routing-Tabellen des Servers festgelegt sein. Die Webserver bei uns im Keller haben Front- und Backendnetze, und über Routing-Tabellen wird festgelegt, welche Ziel-IP über welchen Netzwerkanschluss erreichbar ist. Ist der Standard-Bug wenn ich neue Services nutzen will - das Routing stimmt nicht.

Und da eine IP an einen Netzwerkanschluss gebunden ist (soweit ich weiß), muss der Protokollstack bei einem Kommunikationsversuch mit bspw. 10.4.7.11 wissen, dass das Subnetz 10.4.7.0/24 über den Backend-Anschluss erreichbar ist, und die dafür gebundene IP als Absender setzen.

Rolf

[ursus contionabundo]

Und da eine IP an einen Netzwerkanschluss gebunden ist (soweit ich weiß), muss der Protokollstack bei einem Kommunikationsversuch mit bspw. 10.4.7.11 wissen, dass das Subnetz 10.4.7.0/24 über den Backend-Anschluss erreichbar ist, und die dafür gebundene IP als Absender setzen.

So ist es. Abgesehen davon, dass das, was Du "Netzwerkanschluss" nennst, nicht zwingend Hardware ist sondern nur danach klingt.

Was appropriate ist, kann auch durch die Routing-Tabellen des Servers festgelegt sein.

Das für Dich "appropriate interface" muss nicht das sein, welches "chosen by the system" ist. Denn "the system" kennt Deine Aufgabe nicht.

Ist der Standard-Bug wenn ich neue Services nutzen will - das Routing stimmt nicht.

Hm. Ein "bug" ist es dann, wenn vor dem "Ausrollen" alles fein säuberlich festgelegt war. Sonst heißt die Motte nicht "Bug"( erst recht nicht "Bunny") sondern "Kommunikationsproblem".

[TS]

Hello CK,

Allerdings klärt sie (für mich) noch nicht eindeutig die Frage, ob das Netz 0.0.0.0 benutzt werden darf.

Nein, darf es nicht. 0.0.0.0 ist reserviert, siehe RFC8190.

Der RFC-Tipp ist für mich Gold wert ;-)

0.0.0.0 ist eine nicht-routbare Meta-Adresse, die als Host-Adresse auf für „irgendeine IP-Adresse“ (INADDR_ANY), als Netzwerk-Adresse für „dieses Netzwerk“ und als Route für den Default-Gateway steht. DHCPDISCOVER geht iirc auch an diese Adresse.

Genau! Das hatte ich ja auch im Hirn. Es wird auch als Hint für den Standard-Gateway zu allen nicht näher bezeichneten Netzen genutzt, usw.

Glück Auf
Tom vom Berg

[pl]

Antwort Hier issue 0.0.0.0

Hättest Du aber auch über die von mir gestern hier verlinkte Cisco seite gefunden.

MfG