Zum Inhalt springen
View in the app

A better way to browse. Learn more.

Fachinformatiker.de

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Empfohlene Antworten

Veröffentlicht

Moin allerseits!

Ich habe mir gerade mal den Artikel zum Thema RFC950 vs. RFC1878 hier im Forum angeschaut. OK, ich nehme zur Kenntnis, daß die IHK Lösungswege in beiden Varianten angibt und dann (bei Nennung des verwendeten RFCs) wohl auch beiderlei Lösungen akzeptiert. Aber ist das nicht ein wenig "museal"? Immerhin ist RFC1878 bereits von 1995 und schon damals hieß es dort:

block sizes using calculations which exclude all-zeros and all-ones

subnets [2]. Many vendors only support subnetting based upon this

premise. This practice is obsolete! Modern software will be able to

utilize all definable networks.

Anders gefragt: wann ist jemandem hier zuletzt ein Produkt begegnet (im Einsatz, versteht sich), das darauf besteht, die komplett aus Nullen bzw. komplett aus Einsen bestehenden Subnetze einer Maske nicht benutzen zu können? Und wenn ja, mit welcher Begründung? Welche rationalen Gründe für die Nicht-Nutzung dieser beiden Subnetze gab es ursprünglich? Das würde mich mal interessieren.

Habs vor kurzem schonmal hier im Forum begründet bzw aus der RFC zitiert

Zitat:

Special Addresses:

From the Assigned Numbers memo [9]:

"In certain contexts, it is useful to have fixed addresses

with functional significance rather than as identifiers of

specific hosts. When such usage is called for, the address

zero is to be interpreted as meaning "this", as in "this

network". The address of all ones are to be interpreted as

meaning "all", as in "all hosts". For example, the address

128.9.255.255 could be interpreted as meaning all hosts on

the network 128.9. Or, the address 0.0.0.37 could be

interpreted as meaning host 37 on this network."

It is useful to preserve and extend the interpretation of these

special addresses in subnetted networks. This means the values

of all zeros and all ones in the subnet field should not be

assigned to actual (physical) subnets.

In the example above, the 6-bit wide subnet field may have

any value except 0 and 63.

Habs vor kurzem schonmal hier im Forum begründet bzw aus der RFC zitiert

Ähem, na jaaaa, aber: wenn ich die Frage stelle, inwiefern eine bestimmte in der Vergangenheit gültige Konvention sich evtl. überlebt hat, kann es da eine sinnvolle Antwort sein, aus eben jener Konvention zu zitieren? Das ist doch ein selbstbezügliches Argument.

Natürlich ist es sinnvoll, in einem Netz eine Adresse für das Netz selbst und eine Broadcastadresse zu haben, aber Subnetting verfolgt ja gerade das Ziel, Netze flexibel dem Kapazitätsbedarf anzupassen. Insofern habe ich dann eben 2, 4, 8... Teilnetze, die ich individuell verwalten kann und die ihre eigenen Netz- und BC-Adressen haben. Warum sollte ich bei diesem Vorgang Adressen verschenken? Wenn ich ein sehr kleines Netz in Teilnetze aufteilen möchte, habe ich u.U. nix zu verschenken, keine "Manövriermasse". Wenn ich dagegen ein sehr großes Netz aufteile, "verscchenke" ich damit sofort sehr viele Hostadressen.

Anders ausgedrückt: nenne mir ein Beispielszenario, in dem der m.E. geringe Mehrwert, den mir die direkte Adressierbarkeit des Supernetzes (aus der Sicht der einzelnen Subnets) bzw. aller Hosts im Supernetz den Nachteil eines potentiell recht großen ungenutzten Adressraums bei Verwendung von RFC950 wirklich aufwiegt.

Ich laß mich gerne überzeugen, aber mit Deiner ersten Antwort ist Dir das noch nicht gelungen, sorry...

Die RFC950 brauchst Du heute noch, wenn Du Routingprotokolle nutzt die VLSM (Variable Length of Subnet Masks) nicht beherrschen.

Mal eben ein museumsreifes RIPv1 aktiviert und schon brauchst Du diese wieder.;)

Auch ist der Status der RFC1878 informational, die RFC950 ist Inhalt des Standard Tracks.

D.h. Du kannst die RFC1878 unter bestimmten Bedingungen nutzen, Standard ist aber nachwievor RFC950.

Du hast in beiden RFCs pro Subnetz jeweils eine Adresse fuer Subnetz-ID und Broadcast.

Das Problem liegt darin, dass aeltere Routingprotokolle nur klassenbasierte Subnetze routen koennen und einige Router Probleme mit subnet-zero Netzen hatten.

Die RFC950 brauchst Du heute noch, wenn Du Routingprotokolle nutzt die VLSM (Variable Length of Subnet Masks) nicht beherrschen.

Mal eben ein museumsreifes RIPv1 aktiviert und schon brauchst Du diese wieder.;)

Eben, "museumsreif", daher hatte ich ja gefragt, wann das jemand zuletzt in der Praxis gesehen hat :)

Auch ist der Status der RFC1878 informational, die RFC950 ist Inhalt des Standard Tracks.

D.h. Du kannst die RFC1878 unter bestimmten Bedingungen nutzen, Standard ist aber nachwievor RFC950.

OK, das ist ein wenn auch "nur" formales Argument, das ich in der Tat überlesen hatte, danke.

Du hast in beiden RFCs pro Subnetz jeweils eine Adresse fuer Subnetz-ID und Broadcast.

Das Problem liegt darin, dass aeltere Routingprotokolle nur klassenbasierte Subnetze routen koennen und einige Router Probleme mit subnet-zero Netzen hatten.

Wie gesagt, "hatten"...

Nach Deinem Hinweis auf RFC vs. STD habe ich übrigens gerade noch einmal verifiziert, was ich heute mittag wohl nur "aus den Augenwinkeln" wahrgenommen hatte: Im MS-KB-Artikel Nummer 171061 heißt es

A complete discussion of this practice can be found in RFC 1878, which has superceded RFC950,...

Und das ist natürlich in der Tat Mumpitz, denn eine solche Ablösung eines RFCs durch ein anderes stünde im Dokumentenkopf (Obsoletes RFC####).

Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.