Diskussion:IPv4/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:IPv4/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:IPv4/Archiv/1#Thema_1

RFC 1700 ist obsolet

RFC 3232 besagt: "RFC 1700 is Replaced by an On-line Database" - ich habe als ersten Schritt mal alle RFC-1700-Referenzen (außer "Class E", wo auch die Website noch auf RFC 1700 verweist) durch einen Verweis auf http://www.iana.org/assignments/ipv4-address-space ersetzt, aber nicht im Einzelnen geprüft, ob es eine bessere Referenz gäbe 84.130.51.180 15:25, 14. Apr. 2008 (CEST)

Type of Service

Hallo Echoray. Was heisst Type of Service nicht verwendet? Für mich heisst das ignore. Nehmen die Firewalls an, dass es gleich Null sein muss und verwerfen dann? Hubi 20:53, 13. Feb 2004 (CET)

Frag' mich doch nicht immer so schwere Sachen ;-)... Früher hatte www.kernel.org direkt auf der Startseite eine nette Erklärung und weiterführende Links zu dem Problem, inzwischen sagen die aber nur noch, dass sie ECN benutzen und man evtl. seine Firewall upgraden soll, wenn's klemmt. Ich habe jetzt auf die Schnelle auch keine überaus tolle Erklärung gefunden, als Einstieg mag aber dieses Posting auf lkml dienen: http://www.ussg.iu.edu/hypermail/linux/kernel/0009.1/0027.html --Echoray 21:11, 13. Feb 2004 (CET)

Hallo Echoray, jetzt hab ich's. RFC 1349 sagt klar, dass das TOS-Feld nicht bemängelt werden darf. Da es normalerweise gleich Null, mäkeln die standardverletzendens Firewalls als rum, wenn es nicht null ist und verstossen also gegegen diese RFC. Ich werd's im Artikel entsprechend anpassen. Hubi 21:27, 13. Feb 2004 (CET)

Hab den Abschnitt zum Type of Service umformuliert. Die Seite zu ECN gab es nicht, die Seite Network congestion avoidance enthält eine Beschreibung der Funktionsweise von ECN, und auch einen Hinweis auf die Probleme mit dem TOS-Feld. --Macfiron 23:22, 28. Sep 2005 (CEST)

Netzklassen

Zwei Host-Adressen fallen immer weg – die erste Adresse (zum Beispiel 192.168.0.0) bezeichnet das Netz selber, die letzte Adresse

(zum Beispiel 192.168.0.255) ist für den Broadcast (alle Teilnehmer werden angesprochen) reserviert.

Ist das in der heutigen Zeit noch aktuell? Ich bekomme manchmal eine auf .0 endende IP zugewiesen und ein Bekannter von mir, der bei einem großen Provider als Techniker arbeitet, hat mir, als ich ihn darauf angesprochen habe, gesagt, dass das oben stehende auf dem Papier richtig wäre, aber dass man aufgrund der Knappheit an IPv4-Adressen dazu übergeht diese IPs ganz normal zu vergeben. (nicht signierter Beitrag von 62.48.72.6 (Diskussion | Beiträge) 14:24, 2. Aug. 2007 (CEST))

Dass alle ".0"- bzw ".255"-Adressen Netz- bzw. Broadcastadressen sind, stimmt nicht! Zum Beispiel im privaten Netz 10.0.0.0/8 ist 10.0.0.0 die Netzadresse und 10.255.255.255 die Broadcastadresse (soweit ja logisch, aber jetzt kommt's!). Alle dazwischenliegenden ".0"- und ".255"-Adressen wie z.B. 10.23.42.0 oder 10.100.200.255 sind ganz normale Hostadressen! Ist ja auch logisch, denn per Definition sind bei der Netzadresse alle Host-Bits 0, und bei einer Subnetzmaske von /8 gehört zu den Host-Bits eben nicht nur der letzte "Block" sondern auch die beiden mittleren.

Moritz-G 14:02, 9. Sep. 2008 (CEST)

Private IP Adressen

Es wurden nur die privaten IP Bereiche 10.x.x.x sowie 192.168.x.x aufgefuehrt. Also das ClassA und ClassC Netz fuer den privaten Gebrauch. Wenn ich mich nicht sehr irre gibt es noch ein ClassB und zwar: 172.16.0.0 bis 172.31.0.0 (172.16.0.0 255.240.0.0 bzw. 172.16.0.0/12). Siehe auch http://www.foobar-cpa.de/documents/admin-_-security/scriptch2.html#x4-90002.4.1 mfg Jens (nicht signierter Beitrag von 192.124.248.125 (Diskussion | Beiträge) 12:21, 6. Apr. 2005 (CEST))

Hallo Jens,

da hast du Recht, es gibt ebenfalls einen reservierten IP-Adressbereich für Class B Netzwerke.

Dieser leigt aber von 172.16.0.0 bis 172.31.255.255 !

Viele Grüße

Piccolo2045 (nicht signierter Beitrag von 62.48.72.6 (Diskussion | Beiträge) 15:09, 21. Okt. 2006 (CEST))

Bitte um Umformulierung

Gerade der Teil "Adressformat" ist zu großen Teilen wirklich unglücklich und missverständlich formuliert. Es wäre schön, wenn jemand mit einer besseren Schreibgewandheit diesen Teil überarbeiten könnte. Als Beispiel dieser Satz:

Die Adresse mit dem Adressteil 0 bezeichnet das Netz selber, die Adresse mit dem Adressteils 1 ist für den Broadcast reserviert
Er mag richtig sein, aber es ist nicht eindeutig zu erkennen, dass der gesamte Hostteil entweder aus 0en bzw. 1en besteht.
Besten Dank schonmal --MrManiac 13:19, 2. Mai 2005 (CEST)

--Vielen Dank, Hella. Viel besser :) (nicht signierter Beitrag von MrManiac (Diskussion | Beiträge) 20:55, 4. Mai 2005 (CEST))

24...

Ich habe schon Server aus den USA gesehen, die eine IP-Adresse mit 24.x.x.x hatten. Deshalb meine Frage: Ist mit 24.0.0.0 etwa 24.x.x.x gemeint oder doch ausschließlich 24.0.0.0? --Redeemer 00:54, 30. Dez 2005 (CET)

24.0.0.0/8 (also 24.x.x.x) ist für verschiedene US Cabel Anstalten reserviert, diese haben aber natürlich Kabel-Modem Kunden, von daher ist es kein Wunder dass 24.x.x.x Addressen im Internet auftauchen, die werden ganz normal verwendet (siehe auch whois). BerndEckenfels 06:35, 2. Jan 2006 (CET)

Mit dem Aufkommen von IP in Kabelnetzen haben einige (v.a. US-amerikanische) Kabelgesellschaften plötzlich grosse zusammenhängende IP-Bereiche gewünscht, grösser als jene, die nach den geltenden Richtlinien durch die Regional Internet Registries (wie ARIN oder RIPE) zugeteilt werden durften. Aus diesem Grund wurden den Kabelgesellschaften grosse Adressblöcke direkt durch die IANA zugeteilt, die den gesamten Pool von freien Adressen verwaltet. IANA hat zu diesem Zweck den Bereich 24.0.0.0/8 verwendet. Eine kleine Übersicht über diese Vorgänge findet sich z.B. hier, im Abschnitt REVISION OF ASSIGNMENT PROCEDURES FOR IP ADDRESS SPACE FOR THE CABLE TELEVISION INDUSTRY.

Es ist irreführend, wenn die 24.0.0.0/8 Adressen unter für spezielle Zwecke reserviert aufgeführt sind, denn es handelt sich lediglich um einen administrativen Vorgang, bei dem lediglich die Aufgabenteilung zwischen IANA und den RIRs etwas geändert wurde; die Adressen sind sowieso nicht mehr reserviert, sondern zugeteilt. Es gibt auch keinen RFC, der diesem Bereich einen besonderen Status gäbe, im Gegensatz zu bspw. 10.0.0.0/8. Ich werde diesen Adressbereich im Artikel deshalb aus der Tabelle entfernen. -- Stefan506 10:25, 2. Jan 2006 (CET)

frage: ist der Satz korrekt ?

Ich habe diesen Artikel gelesen und wunderte mich über diesen Satz (im Abschnitt Adressformat): "Eine alternative Notation ist z. B. 192.68.0.0/16; die '16' bedeutet, dass die linken 16 Bits gleich 1 sind." Ist die IP 192.68.0.0/16 wirklich richtig? heisst es nicht 192.168.0.0/16?

MfG, DeveLord --Develord 18:06, 26. Jun 2006 (CEST)

Soweit ich das sehe ist dieser Satz so korrekt. 192.68.0.0 wäre nach dem Konzept der Netzklassen zwar eine Class-C Adresse und müsste daher imho die Subnetzmaske 255.255.255.0 haben, jedoch werden die Netzklassen ja nicht mehr verwendet. Somit ist auch 192.68.0.0/16 korrekt. 192.168.0.0/16 oder 192.68.0.0/16 ist dabei egal, erstere ist lediglich für Privatnetze reserviert. --Ente2k 16:43, 8. Jul 2006 (CEST)

Bitte Edit prüfen

Ich bitte darum, daß jemand mit mehr Ahnung als ich diesen Edit überprüft, von dieser IP kam ansonsten nur Unsinn, hier in diesem Fall kann ich es leider nicht beurteilen. Danke. --Magadan  ?! 14:47, 15. Jan. 2007 (CET)

Weder in dem angegeben RFC 4554 noch bei http://www.iana.org/ipaddress/ip-addresses.htm steht was über 12.0.0.0/8 oder über Project "Internet of Future". Bei http://www.iana.org/assignments/ipv4-address-space (last updated 2006-10-03) steht

012/8 Jun 95 AT&T Bell Laboratories

Ich vermute daher eine freie Erfindung und reverte. --Fomafix 15:04, 15. Jan. 2007 (CET)

Die Rache des dummen Netzes

Hallo,
die folgende Quelle bietet wohl gute Infos für den Artikel hier.

• Die Rache des dummen Netzes: Portnummern als IP-Adresszusatz – Artikel bei heise online, vom 28. Oktober 2008

MfG .. Conrad 15:05, 29. Okt. 2008 (CET)

Anzahl IP-Adressen

Ich fände es schön, wenn hier stehen würde wieviele IP-Adressen Deutschland, Österreich, Schweiz, EU, Europa hat. Habe leider nur folgende Seite gefunden: http://modernl.com/article/ips-assigned-per-capita Rupert Späth (nicht signierter Beitrag von 217.82.113.72 (Diskussion) 10:08, 18. Feb. 2011 (CET))

Fehler in den Gruppen (Classe C und Class D)

Versuche das hier kurz zu halten weil mich persönlich lange Artikel stören.

Fehlerquelle gefunden in der Tabelle mit den Klassen!

Class C

192.0.0.0/24 bis 223.255.255.255

Begründung: Class C wurde richtig definiert als 110 Netzwerk >> max. für die ersten 8 bit also 11011111 > 223

Class D

224.255.255.255 - 239.255.255.255

Begrüdung:

11101111 > 239.255.255.255 usw (ohne Benutzername signierter Beitrag von 213.47.82.133 (Diskussion) )

Ich verstehe nicht ganz, was Du genau meinst. Die Tabelle mit den IP-Netzklassen enthält eine sehr schlechte Formulierung: „Class B: Netze 128.0.0.0/16 bis 191.255.255.255“. Richtig wäre „Class B: Adressen von 128.0.0.0 bis 191.255.255.255 und Netze von 128.0.0.0/16 bis 191.255.0.0/16“. --Fomafix 10:37, 2. Dez. 2011 (CET)

Header

siehe Diskussion:IPv6#Header --Hamburger 16:03, 4. Dez. 2011 (CET)

Zukunfstprognosen

Hoi, Es heist immer, dass bei IPv4 die Adressen demnächst knapp werden, allerdings habe ich noch nie eine genaue Prognose gefunden, wie lange wir noch damit auskommen, bzw wann der Pool vorraussichtlich komplett erschöpft sein wird oder es wirklich zu problemen kommen kann.

Wäre es möglich, im Artikel mal so eine Vorhersage zu wagen? --88.74.83.5 15:35, 2. Nov. 2007 (CET)

ist das erledigt? unter "Vergangenheit und Zukunft" steht ja eine solche Prognose... (-- ~~~~).

Ich empfehle dies hier als Lektüre. --134.147.31.253 00:43, 7. Dez. 2011 (CET)

IP4-Adressen ausgeschöpft

Auf der Seite der Tagesschau steht, Das die IP4-Adressen Aufgebraucht sind. Könnte man das in den Artikel aufnehmen? http://www.tagesschau.de/ausland/ipadressen100.html --Nighthorse 19:29, 3. Feb. 2011 (CET)

Moin, steht bereits im Abschnitt "Vergangenheit und Zukunft" am Ende des Artikels. Wohlgemerkt gibt es noch freie Adressen, erst mal ist nur der Vorrat der IANA erschöpft.--ThorJH ^Disk. 20:37, 3. Feb. 2011 (CET)

Hallo, mal ne Frage: Es ist überall zu lesen, die IANA hätte alle freien Adressblöcke vergeben. Wenn ich mir dieses Dokument ansehe: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml dann stelle ich fest, daß noch 32 "/8-Netze" als "reserved" bezeichnet werden, also eigentlich frei sind. Das ist 1/8 des gesamten Adressbereiches. 2010 wurden von der IANA 19 /8-Netze vergeben, würde man die restlichen 32 auch noch vergeben, würde man vielleicht bis mitte 2012 auskommen. Gibt es einen Grund, warum das (noch?) nicht gemacht wird? -- 79.222.23.111 00:01, 4. Feb. 2011 (CET)

Moin, reserved beduetet halt, dass diese Blöcke für bestimmte Verwendungen vorgesehen sind. Man muss immer beachten, dass man in technischen Systemen Zuordnungen nicht beliebig ändern kann, sondern immer die Kompatibilität zu dem Bisherigen gewahrt werden muss. Darüber hinaus würde es nichts bringen, man hätte dann vielleicht noch für ein Jahr zusätzliche Adressen, aber welchen Vorteil hat es? Die einzige langfristige Lösung ist die Migration nach IPv6. --ThorJH ^Disk. 08:14, 4. Feb. 2011 (CET)

Ich empfehle dies hier als Lektüre. --134.147.31.253 00:51, 7. Dez. 2011 (CET)

Artikel komplett überarbeiten bzw. neu schreiben.

Hallo,

hier haben sicherlich einige Leute viel Arbeit reingesteckt, das weiß ich durchaus zu würdigen. Aber wenn ich mir diesen Artikel in Ruhe durchlese, so fällt mir schnell auf, dass doch alles nur sehr oberflächlich erklärt wird (z.B. Header-Format, Fragmentierung) und manche Informationen hier gar nicht hergehören (z.B. Port-Aufteilung unter "Höhere Protokolle") oder zu ausführlich erklärt werden, obwohl diese Informationen eher in einen anderen Artikel gehören (z.B. bei "Höhere Protokolle"). Außerdem ist mir der Aktikel teilweise zu UNIX/LINUX-lastig geschrieben (z.B. bei "Höhere Protokolle").

Wesentlich besser finde ich den englischen Artikel zu IPv4, da ist sehr schön und ausführlich erklärt, wie das Paket aufgebaut ist und wie die Fragmentierung funktioniert.

Aus meiner Sicht wäre es am besten, den deutschen Artikel "über den Haufen zu werfen" und den englischen zu übersetzen. Ich hoffe, dass dieser Wunsch nun nicht zu ketzerisch rüberkommt, aber aus meiner Sicht taugt der deutsche Artikel einfach nicht viel und man kann nicht von jedem deutschen "Muttersprachler" erwarten, dass er/sie sich die fehlenden Infos aus dem englischen Artikel holt.

Wie seht Ihr das? Wäre jemand bereit, sich die Mühe zu machen? Wenn keine komplette Übersetzung, dann doch zumindest die fehlenden Informationen ergänzen. Zumindest die Teile "Packet structure" und "Fragmentation and reassembly" könnte man doch komplett übernehmen. Die Tabellen sind schön gemacht und die Erklärungen sehr ausführlich und gut strukturiert.

Mir fehlt leider die Zeit, um mich um diese Arbeit zu kümmern. Außerdem habe ich auch schon zu oft mit Wikipedia-Wahnsinnigen zu tun gehabt, die der Meinung waren, dass "Ihr" Artikel perfekt ist und nichts mehr daran geändert werden muss. :-( Da sind mir dann meine Zeit und meine Nerven doch zu schade, um mich mit solchen Zeitgenossen herumzuschlagen.

--der_fahrer 14:18, 11. Jul. 2010 (CEST)

Tja, so ist das nunmal. Das der Artikel hier so schlecht ist und niemand mehr daran arbeiten will können wir unseren deutschen Wikipediaadmins und Löschtrollen verdanken, die alles Löschen, Benutzer & IP trotz deren Mitarbeit sperren, ihnen dann noch fehlende Mitarbeit vorwerfen, obwohl das Logbuch der IP-Mitarbeiter das Gegenteil beweist und dann, falls man sich wegen nem Admin beschwert, die Seilschaften der Admins sich gegenseitig aushelfen. Ich könnte den Artikel überarbeiten, denn das technische Hintergrundwissen habe ich dazu, aber ich habe keine Lust an etwas zu arbeiten, was, so meine Erfahrung ja eh wieder revertiert, gelöscht wird oder zu Streitigkeiten führen, die mich wieder den ganzen Sonntag kosten. Nö Danke. Ich beschränke meine Mitarbeit seit Monaten an der deutschen Wikipedia nur noch auf das allernötigste, kleinste Häppchen, hier ein Satz, da ein Wort, das erspart mir Ärger und Zeitaufwand. Aber im Grund ist das zu tiefst traurig, da ja gerade IPv4 schon so alt ist, sich bewährt hat und somit ausgereift ist, kurz vor der Ablösung durch IPv6 steht und hier immer noch kein brauchbarer Artikel zustande gekommen ist. Insofern stimme ich dir voll und ganz zu. --84.59.21.8 23:03, 6. Feb. 2011 (CET)

Kann ich so unterschreiben. Ich bearbeite auch nur noch Kleinigkeiten die offensichtlich falsch sind oder Rechtschreibfehler. Früher hab ich wirklich versucht viel mitzuarbeiten, Artikel zu überarbeiten oder neue Artikel zu schreiben. Die Erfahrung war ernüchternd. Daher schreibe ich auch nur noch anonym über IP-Adresse, da ich WP keine Rechtfertigung mehr geben möchte, dass sie "einen User mehr" haben.

Mit "WP" meine ich übrigens nur die deutsche Wikipedia. Auf der englischen hat man diese Probleme nicht, und ich schreibe dort gerne. --134.147.31.253 00:49, 7. Dez. 2011 (CET)

Eine allgemeine WP-Systemkritik bringt uns hier nicht weiter, ob sie nun berechtigt sein mag oder nicht. Den Artikel komplett zu verwerfen und auf Basis von en:WP neu aufzubauen, dazu sehe ich ohne ausführlichere vorherige Debatte keine Grundlage. Die Absätze packet structure und fragmentation sind auf en:WP in der Tat gut gelungen. Fraglich ist aber aus meiner Sicht, ob diese nicht teilweise über das Maß an allgemein relevanter Information hinausgehen. Der Header ist auch im Deutschen ausreichend dokumentiert. Zu IP-Paket gibt es einen ganz eigenen Artikel. Es kann nicht Aufgabe der WP sein Fachlektüre zu ersetzen. --Hamburger 12:27, 27. Dez. 2011 (CET)

Ergänzung: Artikel auf Liste der QS Informatik gesetzt. --Hamburger 12:39, 27. Dez. 2011 (CET)

Überarbeiten u.a. der Struktur

Hallo wer auch immer :) Ich lerne gerade für eine Diplomprüfung in diesem Bereich, daher ist mir einiges an diesem Artikel aufgefallen, was mir leider misfällt. Ich bin im Moment zeitlich nicht in der Lage, das alles zu korrigieren, aber ich würde eine deutliche, große Umarbeitung dieses Artikels vorschlagen.

Insbesondere sehe ich folgende Probleme: schlechte Struktur (Der Artikel wirkt z.B. die ersten 60% wie ein Artikel "IPv4-Adressen" - die Zahl 536870912 ist nun wirklich nicht wichtiger als z.B. das Thema Routing, das die wesentliche Aufgabe von IP ist), fehlende Abstraktion in Bezug auf die entsprechenden Schichtenmodelle (Details von Ethernet und TCP (Portnummern, Header-Konstanten!) werden genannt, die hier überhaupt nicht hingehören, sondern eben auf andere Schichten), Spezialfälle (der Satz "Eine Liste der registrierten Protokolle findet sich in /etc/protocols" bezieht sich beispielsweise nur auf Linux-/Unix-Systeme).

Mein Vorschlag für eine Struktur:

• Nach kurzer Einleitung zunächstmal auf die entsprechenden TCP/IP- bzw. ISO/OSI-Referenzmodelle verweisen.

• Dann sagen, was IP tun soll, also den Service beschreiben, den IP den Protokollen auf höheren Ebenen bietet. So kapiert man, was man überhaupt mit IP erreichen will, worauf das alles hier abzielt.

• Anschließend beschreiben, worauf IP aufsetzt, was es also für Anforderungen an niedrigere Schichten stellt. Damit ist dann eine Spezifikation für das System gegeben, d.h. Voraussetzungen und Ziel des Protokolls.

• Danach kann man anfangen, zu erzählen, wie IP das erreicht. Dabei ist Routing IMHO wichtiger als das Thema Adressierung - dieses Thema sollte wirklich nicht in diversen Tabellen 60% des Artikels einnehmen! Man muß an dieser Stelle eben die innere Struktur von IP beschreiben - Routing-Mechanismen, Adressierung, Headerformat, Paketlänge, Hilfsmittel wie ICMP, ...

• Das "Vergangenheit und Zukunft" paßt dann natürlich ans Ende.

Wie gesagt kann ich diese Umarbeitung im Moment leider nicht selbst leisten, aber ich hoffe, daß sich hier Freiwillige finden, die sich zwei, drei gute Lehrbücher schnappen und hier mal aufräumen :) Evtl. sind ja auch andere der Meinung, daß hier mal mittels irgendeiner Wiki-Vorlage wie Qualitätssicherung/Überarbeiten etc. (kenne mich da leider nicht aus) ein wenig Aufmerksamkeit auf den Artikel gelenkt werdne sollte :)

Dankeschön schon mal an alle Diskutierenden und fleißigen Autoren :) Drbashir117 01:48, 13. Aug 2006 (CEST)

Mittlerweile zum Großteil betreffs der Strukturierung so oder ähnlich umgesetzt.

Nicht erledigt sind inhaltlich:

• Routing kommt vergleichsweise kurz daher
• Zugrunde liegende niedrigere Schichten werden eher knapp besprochen

--Hamburger 16:53, 3. Jan. 2012 (CET)

Grafik bei "Vergangenheit und Zukunft" > www.isc.org bitte erneuern

die Grafik zeigt nur die Daten bis 2003.

Danke (nicht signierter Beitrag von 134.93.51.36 (Diskussion) 16:21, 24. Jan. 2007 (CET))

Immer noch nicht behoben. Stellt sich aber auch die Frage ob das nicht in einem allgemeineren Artikel über das Internet besser aufgehoben wäre. --Hamburger 17:14, 3. Jan. 2012 (CET)

Literatur

Primär- und Sekundärliteratur, analog zu IPv6, fehlt hier komplett. --Hamburger 17:10, 3. Jan. 2012 (CET)

Ungültiges Archivierungsziel

Die Zielangabe bei der automatischen Archivierung dieser Seite ist ungültig. Sie muss mit demselben Namen wie diese Seite beginnen. Wende dich bitte an meinen Besitzer, wenn das ein Problem darstellen sollte. ArchivBot 03:27, 4. Jan. 2012 (CET)

erledigtErledigt Harry8 09:13, 4. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Harry8 09:13, 4. Jan. 2012 (CET)

Abschnitt Siehe auch

Diese Einträge werden nicht motiviert/ abgegrenzt und sind damit weitgehend nutzlos. Können diese in den Fließtext integriert werden? --Hamburger 17:11, 3. Jan. 2012 (CET)

Tabelle: IP-Netzklassen

Ich denke, entweder man schreibt dort (am Beispiel für Class C) 192.0.0.0 bis 223.255.255.255 oder man schreibt einfach nur 192.0.0.0/24, aber 192.0.0.0/24 bis 223.255.255.255, so wie es gerade dort steht, ist sicherlich falsch. --Jobu0101 (Diskussion) 11:06, 19. Jul. 2012 (CEST)

Bei der aktuellen Netzklassen-Tabélle belegt zur Zeit jede Subklasse für sich bereits den gesamten Adressraum. Vielleicht spendiert Ihr jeweils ca, 1 Bit weniger, manchmal auch ein paar mehr Bits, pro Class-Address !? Tatsächlich ist die Angabe einer solchen Tabelle zwar üblich, aber niemals richtig. Schaut mal bei < http://www.edv-lehrgang.de/adressklassen-in-netzwerken/ > nach. (nicht signierter Beitrag von 31.150.230.167 (Diskussion) 17:33, 5. Jun. 2015 (CEST))

N-ID BC Freigabe

Im Artikel steht: "Zwei Host-Adressen sind gemäß einer Empfehlung in der RFC 950 reserviert – die erste Adresse (zum Beispiel 192.168.0.0) bezeichnet das Netz selbst, die letzte Adresse (zum Beispiel 192.168.0.255) ist für den Broadcast (alle Teilnehmer werden angesprochen) reserviert. Diese Einschränkung wird in der RFC 1878 aufgehoben."

Ich habe die entsprechende RFC extra nochmal überflogen, die steht im Zusammenhang mit All-Zero und All-One Subnetting, siehe z.B. bei Cisco http://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/13711-40.html Abschnitt: Problems with Subnet Zero and the All-Ones Subnet Soll heißen, dass alle Subnetze genutzt werden dürfen, was ist der ursprünglichen RFC wegen möglicher Doppeldeutigkeiten noch strongly discouraged war. Ich bin kein gelernter Netzwerktechniker, deswegen will ich den Artikel nicht verschlimmbessern, weil ich was falsch sehe, aber mindestens die Belegung des Broadcasts mit einer Host-IP dürfte mehr als problematisch sein. Und da dem Abschnitt die Anzahl möglicher Hosts in einem Netzwerk vorangeht ist das wohl genau so gemeint. Bitte von einem Wissenden nochmal überprüfen.

Widersprüchliche Informationen bezüglich erster und letzter Adresse.

Im Abschnitt "Netzklassen" wird darauf hingewiesen, dass die früheren Einschränkungen bezüglich der ersten und letzten Adresse aufgehoben wurden:

"Zwei Host-Adressen sind gemäß einer Empfehlung in der RFC 950 reserviert – die erste Adresse (zum Beispiel 192.168.0.0) bezeichnet das Netz selbst, die letzte Adresse (zum Beispiel 192.168.0.255) ist für den Broadcast (alle Teilnehmer werden angesprochen) reserviert. Diese Einschränkung wird in der RFC 1878 aufgehoben."

Im Abschnitt "Beispiel" werden jedoch die ersten und letzten Adressen bezüglich der alten Einschränkung angegeben, ohne dabei zu erwähnen, dass dies nur nach der alten Regelung gilt. Das sollte man vielleicht irgendwie verbessern. Mir fällt aber gerade kein guter Weg dazu ein. --217.252.186.33 14:09, 27. Jun. 2017 (CEST)

Siehe dazu auch vorherige Diskussion "N-ID BC Freigabe" --217.252.186.33 14:11, 27. Jun. 2017 (CEST)

Relevant ist dazu auch die technische Erleuterung unter Subnetz, Verwendung auf Netzwerksegmenten. --217.252.186.33 14:14, 27. Jun. 2017 (CEST)

A- und B-Notation

Wäre es nicht sinnvoll, irgendwo auf die A- und B-Notationen von IPv4-Adresen hinzuweisen:

• 127.1 = 127.0.1 = 127.0.0.1
• 10.66051 = 10.1.515 = 10.1.2.3

-- Lemmi18 (Diskussion) 22:53, 7. Jul. 2017 (CEST)

Imho nein, diese Darstellungen mögen sogar erlaubt sein, sind aber bei IPv4 absolut unüblich.--Kgfleischmann (Diskussion) 05:40, 8. Jul. 2017 (CEST)

Sie sind definitiv gültig. Linux und Windows unterstützen sie (z.B. Test mit: ping 127.1). Und gerade diese Kurzform 127.1 wird bei alten Hasen gar nicht so selten verwendet. Aber auch unübliches ist kein Ausschlusskriterium, insbesondere nicht bei technischen Artikeln.

Da wir gerade beim Testen sind: Windows und Linux machen aus 127.010 => 127.0.0.8

-- Lemmi18 (Diskussion) 12:22, 8. Jul. 2017 (CEST)

Adressformat

Ich zitiere: "Die genaue Aufteilung zwischen Netzanteil und Hostanteil wird durch eine Subnetzmaske festgelegt, beispielsweise 255.255.255.0. Bei Verwendung dieser Maske würde die IP-Adresse in der CIDR-Notation dann als 192.168.0.23/24 geschrieben, wobei die „24“ bedeutet, dass die ersten 24 Bits der Subnetzmaske gleich 1 sind. Die Bits der Subnetzmaske, die „1“ sind, legen die Stellen der IP-Adresse fest, die zum Netzanteil gehören. Alle restlichen Stellen der IP-Adresse (entsprechend der Anzahl Bits der Maske die auf 0 gesetzt sind) gehören dann zum Hostanteil."

Nach der Lektüre dieses Absatzes hatte ich genau folgendes verstanden: BAHNHOF. Ein Weiterlesen habe ich mir dann erspart.

Ist Wikipedia ein für durchschnittlich gebildete Menschen gedachtes Lexikon oder ein Tummelplatz für Fachidioten? --194.96.12.72 14:04, 22. Dez. 2017 (CET)

Das hat mit "Fachidioten" nichts zu tun, sondern ist die einfachste, minimalste Grundlage zum Thema Subnetzmaske. Nebenbei ist es auch sehr verständlich und absolut korrekt formuliert. Da es sich um Basiswissen handelt, dass ein IT-Ausbzubildender allerspätestens in seiner ersten Ausbildungswoche erwirbt, handelt es sich auch nicht wirklich um schwer verständlichen Stoff. Selbstverständlich sind Subnetzmasken aber nichts für die 90-jährige Ur-Oma. --2001:470:9AB4:0:24D2:2E96:7740:E607 22:18, 7. Mai 2019 (CEST)

ToS veraltet

Gibt es hierzu Bedenken oder weshalb hat das noch keiner gesichtet? Aus RFC 3168 kann ich noch zwei Stellen zitieren:

The definitions for the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet have been superseded by the six-bit DS (Differentiated Services) Field [RFC2474, RFC2780]. [...]

RFC 1349 and RFC 1455 have been obsoleted by "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] in which bits 6 and 7 of the DS field are listed as Currently Unused (CU).

Zwar wird das zweite Oktett manchmal noch ToS genannt, aber nur im historischen Kontext. Heutzutage ist das eigentlich das DS-Feld. So findet man auf [1] nicht mal mehr einen Hinweis auf "ToS".
In der englischen Wikipedia hat man das schon lange aktualisiert: https://en.wikipedia.org/wiki/IPv4#Header. --129.247.247.239 11:04, 6. Mai 2019 (CEST)

Mittlerweile wurde der Abschnitt gesichtet, danke! --129.247.247.239 16:18, 8. Mai 2019 (CEST)

IPv4 = vierte Version von IP?

Im Einleitungssatz steht: „[IPv4] ist die vierte Version des Internet Protocols (IP).“. Im Artikel zu Internet Protocol steht aber: „Dass es sich beim heute gebräuchlichen Protokoll IPv4 um die vierte Generation des Internet-Protokolls handelt, ist ein populärer Irrtum. Die Versionsnummer 4 bezieht sich lediglich darauf, dass die vierte Version des TCP-Protokolls zum Einsatz kommt.“. Das klingt für mich wiedersprüchlich - was ist richtig und haben wir einen Beleg dafür? (Ich glaube, dass, angesichts von IPv3, der Satz hier im Artikel richtig und der andere falsch ist - aber ist das so?) --Jb31 (Diskussion) 07:34, 21. Jun. 2019 (CEST)

Laut RFC 791 bezeichnet das Versionsfeld die Version 4 des IP-Headers: "The Version field indicates the format of the internet header. This document describes version 4."

Es gab mehr als vier verschiedene Fassungen der Protokollspezifikation. RFC 791 sagt dazu: "This document is based on six earlier editions of the ARPA Internet Protocol Specification"

Man kann die Auffassung vertreten, dass es sich bei denjenigen Spezifikationen, die dasselbe Header-Format verwenden, um verschiedene Arbeitsentwürfe desselben Protokolls handelt. Nach dieser Auffassung wären IEN 41, IEN 54, IEN 80, IEN 111, IEN 123 und IEN 128/RFC 760 (verwenden allesamt dasselbe Header-Format mit Versionsnummer 4) Entwürfe des IPv4-Protokolls, das schließlich mit RFC 791 finalisiert wurde. IEN 28 hingegen, was ein anderes Header-Format mit Versionsnummer 2 verwendet, wäre ein Vorläuferprotokoll. Die Aussage "IPv4 ist die vierte Version des Internet Protocols" verkürzt diesen Sachverhalt, ist aber nicht gänzlich verkehrt.

TCP und IP wurden gemeinsam entwickelt: ursprünglich als gemeinsames "Transmission Control Program" (TCP), aus dem später IP als eigene Protokollspezifikation herausgetrennt wurde. Tatsächlich haben die oben genannten IPv4-Entwürfe ein TCP-Gegenstück, die anfangs auch als TCP Version 4 bezeichnet wurden (IEN 40, IEN 55, IEN 81) und später keine Versionsnummer trugen (IEN 112, IEN 124, IEN 129/RFC 761). Allerdings: IEN 28, IP Version 2, bezieht sich auf TCP Version 3. Dass sich die Versionsnummer im IP-Header lediglich auf die Version von TCP beziehe, stimmt also nicht. IP verwendet eine eigene Versionszählung. --Matthäus Wander 16:09, 8. Feb. 2020 (CET)

Darstellung

Es fehlt ein Abschnitt dazu dass folgende Darstellungen möglich sind:

Binärdarstellung Dezimaldarstellung Dotted Decimal Hex Dotted Hex usw. (nicht signierter Beitrag von 93.204.133.188 (Diskussion) 20:51, 2. Mai 2020 (CEST))