Zum Inhalt springen

Subnetting: heutige Relevanz von RFC950?


TheFinn

Empfohlene Beiträge

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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...

Link zu diesem Kommentar
Auf anderen Seiten teilen

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.

Link zu diesem Kommentar
Auf anderen Seiten teilen

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####).

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...