IPv4 - Versionsgeschichte

Mandy28: /* Lokale/Private Netzwerkadressen */

2013-02-19T08:48:54Z

Lokale/Private Netzwerkadressen

← Nächstältere Version		Version vom 19. Februar 2013, 08:48 Uhr
Zeile 112:		Zeile 112:
	! Adressbereich		! Adressbereich
	! Klassenbeschreibung		! Klassenbeschreibung
	! größter ~~[[Classless Inter-Domain Routing\|~~CIDR]]-Block		! größter CIDR-Block
	! Anzahl IP-Adressen		! Anzahl IP-Adressen
	\|-----		\|-----

Mandy28: /* Besondere Netzwerkadressen */

2013-02-19T08:47:50Z

Besondere Netzwerkadressen

← Nächstältere Version		Version vom 19. Februar 2013, 08:47 Uhr
Zeile 79:		Zeile 79:
	\| 100.64.0.0/10 \|\| Shared Transition Space \|\| RFC 6598		\| 100.64.0.0/10 \|\| Shared Transition Space \|\| RFC 6598
	\|----		\|----
	\| 127.0.0.0<!--sic!-->/8 \|\| [[Loopback]] (Lokaler Computer) \|\| RFC 1122		\| 127.0.0.0<!--sic!-->/8 \|\| Loopback (Lokaler Computer) \|\| RFC 1122
	\|----		\|----
	\| 169.254.0.0/16 \|\| Privates Netzwerk (link local), [[APIPA]] \|\| RFC 3927		\| 169.254.0.0/16 \|\| Privates Netzwerk (link local), APIPA \|\| RFC 3927
	\|----		\|----
	\| 172.16.0.0/12 \|\| 16x Private Netzwerke der Klasse B \|\| RFC 1918		\| 172.16.0.0/12 \|\| 16x Private Netzwerke der Klasse B \|\| RFC 1918
Zeile 99:		Zeile 99:
	\| 203.0.113.0/24 \|\| Test-Netzwerke \|\| RFC 5735		\| 203.0.113.0/24 \|\| Test-Netzwerke \|\| RFC 5735
	\|----		\|----
	\| 224.0.0.0/4 \|\| ~~[[Multicast]]s~~ (ehemals Klasse-D-Netzwerk) \|\| RFC 3171		\| 224.0.0.0/4 \|\| Multicasts (ehemals Klasse-D-Netzwerk) \|\| RFC 3171
	\|----		\|----
	\| 240.0.0.0/4 \|\| Reserviert (ehemals Klasse-E-Netzwerk) \|\| RFC 1700		\| 240.0.0.0/4 \|\| Reserviert (ehemals Klasse-E-Netzwerk) \|\| RFC 1700

Mandy28: /* Quellenangaben */

2013-02-19T08:45:35Z

Quellenangaben

← Nächstältere Version		Version vom 19. Februar 2013, 08:45 Uhr
Zeile 328:		Zeile 328:

	[[#top\|<span style="color:#4876FF;">[ nach Oben ]</span>]]<br>		[[#top\|<span style="color:#4876FF;">[ nach Oben ]</span>]]<br>
	[[Local Area Network (LAN)\|~~<span style="color:#4876FF;">[~~Zurück zu Netzwerk~~]</span>~~]]~~<br>~~
	[[Hauptseite\|~~<span style="color:#4876FF;">[~~Zurück zu Hauptseite]~~</span>~~]~~]</div> </div>~~		*[[Local Area Network (LAN)\|Zurück zu Netzwerk]]
	[[Category:Netzwerk]]		*[[Hauptseite\|Zurück zu Hauptseite]]

			[[Category:Netzwerk]]

Mandy28: /* Quellenangaben */

2013-02-19T08:42:35Z

Quellenangaben

← Nächstältere Version		Version vom 19. Februar 2013, 08:42 Uhr
Zeile 324:		Zeile 324:
	==Quellenangaben==		==Quellenangaben==
	http://de.wikipedia.org/		http://de.wikipedia.org/


	*[[Hauptseite\|Zurück zu Hauptseite]]




			[[#top\|<span style="color:#4876FF;">[ nach Oben ]</span>]]<br>
			[[Local Area Network (LAN)\|<span style="color:#4876FF;">[Zurück zu Netzwerk]</span>]]<br>
			[[Hauptseite\|<span style="color:#4876FF;">[Zurück zu Hauptseite]</span>]]</div> </div>
	[[Category:Netzwerk]]		[[Category:Netzwerk]]

Mandy28: /* Quellenangaben */

2013-02-18T22:13:59Z

Quellenangaben

← Nächstältere Version		Version vom 18. Februar 2013, 22:13 Uhr
Zeile 315:		Zeile 315:
	*nicht registrierte Ports (49.152–65.535)		*nicht registrierte Ports (49.152–65.535)


			==Vergangenheit und Zukunft==
			[[Datei:Zahl der Internet Hosts.png\|miniatur\|Zahl der Rechner im Internet (1981 bis 2003)]]
			IPv4 hat lange nahezu unverändert überlebt. Ab 1983 wurde die IP-Protokoll-Familie als einzige Protokollfamilie für das Arpanet übernommen, das dann später zum Internet wurde. Damals waren nur einige hundert Rechner an das Netz angeschlossen. 1989 wurde die Grenze von 100.000 Rechnern überschritten, und im selben Jahr der Backbone auf 1,5 MBit/s aufgerüstet. Am Anfang der 1990er-Jahre war erkennbar, dass die IP-Adressen bald knapp würden. Dies führte zuerst zur Entwicklung eines Entwurfes für einen Standard mit der Versionsnummer 7 (TP/IX), der dann aber zugunsten von IPv6 verworfen wurde. TP/IX sollte dabei einen 64-Bit-Adressbereich unterstützen. Die Versionsnummer 5 wurde 1995 für das Internet Stream Protocol Version 2 (ST2) benutzt, das nicht als IPv4-Nachfolger geplant war, sondern als gleichzeitig benutzbares, für Streaming optimiertes Protokoll. Mittlerweile ist das Projekt jedoch eingestellt. Einige Eigenschaften, wie Fragmentierung, werden nicht mehr benötigt, da sie für die heutigen schnellen Netze zu aufwendig sind. Path Maximum Transmission Unit Discovery löst dieses Problem. IPv4 scheint auch in nächster Zukunft noch das allgemein verwendete Protokoll im Internet zu bleiben. Schließlich hat IP auch die konkurrierenden LAN-Protokolle wie DECnet verdrängt. NetWare, AppleTalk und NetBIOS wurden als neue Versionen hervorgebracht, die auf IP aufsetzen.

			Am 3. Februar 2011 vergab die IANA die letzten IPv4-Adressen an die Regional Internet Registries[1][2]. Am 15. April 2011 teilte APNIC die letzten frei zu vergebenden Adressen für die Region Südostasien zu.[3] Ab diesem Zeitpunkt haben alle APNIC-Mitglieder nur noch Anspruch auf eine einzelne Zuteilung von IPv4-Adressraum der minimalen Zuteilungsgröße.[4]

	==Quellenangaben==		==Quellenangaben==

Mandy28: /* Quellenangaben */

2013-02-18T22:13:17Z

Quellenangaben

← Nächstältere Version		Version vom 18. Februar 2013, 22:13 Uhr
Zeile 297:		Zeile 297:

	Um ein Paket wieder zusammenzusetzen, kombiniert der Empfänger alle Fragmente, welche die gleiche Kennung (Identifikation), den gleichen Absender, Empfänger und das gleiche Protokoll haben. Dabei erkennt er das erste Fragment daran, dass Fragment-Offset den Wert 0 hat. Das jeweils nächste Fragment erkennt er ebenfalls am Fragment-Offset und das letzte Fragment daran, dass ''more-fragments'' den Wert 0 hat.		Um ein Paket wieder zusammenzusetzen, kombiniert der Empfänger alle Fragmente, welche die gleiche Kennung (Identifikation), den gleichen Absender, Empfänger und das gleiche Protokoll haben. Dabei erkennt er das erste Fragment daran, dass Fragment-Offset den Wert 0 hat. Das jeweils nächste Fragment erkennt er ebenfalls am Fragment-Offset und das letzte Fragment daran, dass ''more-fragments'' den Wert 0 hat.


			==Höhere Protokolle==
			IPv4 ist ein geroutetes Protokoll (Schicht 2 im TCP/IP-Referenzmodell – Schicht 3 im ISO/OSI-Modell). Auf IPv4 werden weitere Protokolle aufgesetzt, das heißt in den Datenteil des IP-Pakets werden die Header, Daten und eventuelle Trailer der oberen Protokolle eingefügt (Protokollstapel). Eine Liste der registrierten Protokolle findet sich in unixoiden Betriebssystemen in der Datei „/etc/protocols“.

			Neben dem erwähnten ICMP wird TCP verwendet, das TCP/IP zusammen mit IP den Namen gegeben hat. TCP ist ein verbindungsorientiertes Protokoll, das einen byteorientierten, bidirektionalen, zuverlässigen Datenstrom zur Verfügung stellt. Es wird im WAN-Bereich praktisch für alle Arten von Daten- und Informationsübertragungen eingesetzt.

			UDP, ein paketorientiertes Protokoll, setzt ebenfalls auf IP auf. Es ist ein einfaches Protokoll, das die Paketeigenschaften von IP im Wesentlichen beibehält (verbindungslos, unzuverlässig, Verdoppelung etc.). TCP und UDP fügen IP eine Prüfsumme über die Daten (die Prüfsumme im IP-Header prüft nur die Headerdaten) und als Quell- und Zielport jeweils eine 16-Bit-Zahl hinzu. Diese Ports bilden zusammen mit der jeweiligen Quell- und Zieladresse im IP-Paket sogenannte Endpunkte. Prozesse kommunizieren über diese Endpunkte. TCP baut eine Verbindung nicht zwischen IP-Adressen, sondern zwischen zwei Endpunkten auf.

			Die weiteren Protokolle setzen alle entweder auf TCP oder auf UDP auf. Ein wichtiges Protokoll ist das Domain Name System DNS, das eine Umsetzung von Rechnernamen zu IP-Adressen erlaubt. Es überträgt Informationen normalerweise über UDP, der Abgleich zwischen zwei DNS-Servern kann aber auch TCP verwenden.

			Die Ports teilen sich auf in:


			*privilegierte Ports (1 – 1023); diese dürfen nur vom Benutzer Root verwendet werden.
			*registrierte Ports (1024 – 49.151); die Registrierung unterliegt der IANA. Eine Liste findet sich auf Unix-Systemen in der Datei „/etc/services“.
			*nicht registrierte Ports (49.152–65.535)

Mandy28: /* Quellenangaben */

2013-02-18T22:12:16Z

Quellenangaben

← Nächstältere Version		Version vom 18. Februar 2013, 22:12 Uhr
Zeile 283:		Zeile 283:

	Eine spezielle Bedeutung kommt in modernen Implementierungen dem Feld ''Type of Service'' zu. Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. In modernen Implementierungen wird dieses Feld im Zusammenhang mit der Vermeidung von Überlastungen verwendet.		Eine spezielle Bedeutung kommt in modernen Implementierungen dem Feld ''Type of Service'' zu. Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. In modernen Implementierungen wird dieses Feld im Zusammenhang mit der Vermeidung von Überlastungen verwendet.

			== Fragmentierung ==
			Auf dem Weg vom Sender zum Empfänger kann es vorkommen, dass ein Datagramm ein Netz durchlaufen muss, welches nur kleine Datagramme unterstützt. Jedes Datagramm erhält vom Sender eine Kennung (Identification). Stellt ein Router auf dem Weg zum Ziel fest, dass das Datagramm für das nächste Teilnetz zu groß ist, so kann er es in zwei Fragmente aufteilen. Dazu sind folgende Schritte notwendig:

			* Aufteilen der Nutzdaten an einer 64-Bit-Grenze (das zweite Fragment enthält dann nicht unbedingt ein Vielfaches von 64 Bit Daten)
			* Kopieren der Headerdaten des Originaldatagramms in die neuen Header
			* Setzen des „more-fragments“-Flags beim ersten Fragment
			* Beim zweiten Fragment erhält das more-fragments Flag den Wert des Originaldatagramms, da das Originaldatagram bereits ein Fragment gewesen sein kann.
			* Erneutes Setzen der Länge-Felder in den Headern
			* Beim zweiten Fragment enthält Fragment-Offset die Summe aus Fragment-Offset des Originaldatagramms und Anzahl (Nutzdaten-)Bytes im ersten Fragment.

			Das Fragmentieren in n > 2 Fragmente funktioniert entsprechend.

			Um ein Paket wieder zusammenzusetzen, kombiniert der Empfänger alle Fragmente, welche die gleiche Kennung (Identifikation), den gleichen Absender, Empfänger und das gleiche Protokoll haben. Dabei erkennt er das erste Fragment daran, dass Fragment-Offset den Wert 0 hat. Das jeweils nächste Fragment erkennt er ebenfalls am Fragment-Offset und das letzte Fragment daran, dass ''more-fragments'' den Wert 0 hat.


	==Quellenangaben==		==Quellenangaben==

Mandy28: /* Header-Format */

2013-02-18T22:12:00Z

Header-Format

← Nächstältere Version		Version vom 18. Februar 2013, 22:12 Uhr
Zeile 282:		Zeile 282:
	\|}		\|}

	Eine spezielle Bedeutung kommt in modernen Implementierungen dem Feld ''Type of Service'' zu. Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. In modernen Implementierungen wird dieses Feld im Zusammenhang mit der ~~[[Network congestion avoidance\|~~Vermeidung von Überlastungen]] verwendet.		Eine spezielle Bedeutung kommt in modernen Implementierungen dem Feld ''Type of Service'' zu. Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. In modernen Implementierungen wird dieses Feld im Zusammenhang mit der Vermeidung von Überlastungen verwendet.

	==Quellenangaben==		==Quellenangaben==

Mandy28: /* Header-Format */

2013-02-18T22:11:45Z

Header-Format

← Nächstältere Version		Version vom 18. Februar 2013, 22:11 Uhr
Zeile 262:		Zeile 262:
	! width="12%" \| 28–31		! width="12%" \| 28–31
	\|-----		\|-----
	\| ~~[[IP-Paket#~~Version~~\|Version]]~~		\| Version
	\| ~~[[IP-Paket#~~IHL ~~(IP Header Length)\|IHL]]~~		\| IHL
	\| colspan="2" \| ~~[[IP-Paket#TOS (~~Type of Service~~)\|Type of Service]]~~		\| colspan="2" \| Type of Service
	\| colspan="4" ~~\| [[IP-Paket#Total Length~~\|Gesamtlänge]]		\| colspan="4" \| Gesamtlänge
	\|-----		\|-----
	\| colspan="4" ~~\| [[IP-Paket#Identification~~\|Identifikation]]		\| colspan="4" \| Identifikation
	~~\| [[IP-Paket#Flags~~\|Flags]]		\| Flags
	\| colspan="3" ~~\| [[IP-Paket#Fragment Offset~~\|Fragment Offset]]		\| colspan="3" \| Fragment Offset
	\|-----		\|-----
	\| colspan="2" ~~\| [[Time-to-live~~\|TTL]]		\| colspan="2" \| TTL
	\| colspan="2" ~~\| [[Protokoll (IP)~~\|Protokoll]]		\| colspan="2" \| Protokoll
	\| colspan="4" \| Header-[[Prüfsumme]]		\| colspan="4" \| Header-Prüfsumme
	\|-----		\|-----
	\| colspan="8" \| Quell-IP-Adresse		\| colspan="8" \| Quell-IP-Adresse

Mandy28: /* Quellenangaben */

2013-02-18T22:10:35Z

Quellenangaben

← Nächstältere Version		Version vom 18. Februar 2013, 22:10 Uhr
Zeile 240:		Zeile 240:

	ICMP kann zusammen mit dem ''Don’t-Fragment''-Bit des IP-Pakets auch eingesetzt werden, um die maximale Paketgröße MTU eines Übertragungsweges zu ermitteln (sogenannte PMTU ''Path Maximum Transmission Unit''). Dies ist die MTU desjenigen Netzwerkes mit der kleinsten MTU aller passierten Netzwerke. Dadurch kann auf Fragmentierung verzichtet werden, wenn der Sender nur Pakete mit der maximalen Größe der PMTU erzeugt.		ICMP kann zusammen mit dem ''Don’t-Fragment''-Bit des IP-Pakets auch eingesetzt werden, um die maximale Paketgröße MTU eines Übertragungsweges zu ermitteln (sogenannte PMTU ''Path Maximum Transmission Unit''). Dies ist die MTU desjenigen Netzwerkes mit der kleinsten MTU aller passierten Netzwerke. Dadurch kann auf Fragmentierung verzichtet werden, wenn der Sender nur Pakete mit der maximalen Größe der PMTU erzeugt.

			== IPv4 auf Ethernet ==
			IPv4 kann auf vielen verschiedenen Medien aufsetzen, zum Beispiel auf serielle Schnittstellen (PPP oder SLIP), Satellitenverbindungen usw. Im LAN-Bereich wird heute fast immer Ethernet eingesetzt. Ethernet verwaltet eigene 48-Bit-Adressen. Wenn IP über Ethernet gesendet wird, wird ein 14 (oder bei VLAN 18) Byte großer Ethernet-Header vor dem IP-Header gesendet. Nach den Daten folgt eine 32-Bit-CRC-Prüfsumme. Neben der maximalen Paketlänge von 1522 (bzw. 1518) Bytes kann Ethernet keine kleineren Pakete als 64 Bytes übertragen, so dass zu kurze IP-Pakete (Datenlänge kleiner als 46 Bytes) mit Nullbytes erweitert werden (sogenanntes Padding). Die Länge im IP-Header gibt dann Auskunft über die tatsächliche Paketgröße.

			Im Ethernet hat jede Netzwerkkarte ihre eigene, herstellerbezogene 48-Bit-Adresse, zusätzlich gibt es eine Ethernet-Broadcastadresse. Ein Sender muss die Ethernetadresse der Zielnetzwerkkarte kennen, bevor ein IP-Paket gesendet werden kann. Dazu wird ARP (Address Resolution Protocol) verwendet. Jeder Rechner verwaltet einen ARP-Cache, in dem er ihm bekannte Zuordnungen von Ethernet-Kartenadressen speichert. Unbekannte Adressen erfährt er über ARP mittels einer Anfrage (ARP-Request) über einen Ethernet-Broadcast (Nachricht an alle Empfänger), die der zugehörige Empfänger beantwortet (ARP-Reply).

			== Header-Format ==

			Der IPv4-Header ist normalerweise 20 Bytes lang. Bei Übertragung auf Basis von Ethernet folgt er dem Ethernet-Typfeld, das für IP-Pakete auf 0800<sub>16</sub> festgelegt ist. Auf anderen Übertragungsmedien und Protokollen kann der Header auch der erste Eintrag sein.

			IPv4 bietet verschiedene, größtenteils ungenutzte Optionen, die den Header bis auf 60 Bytes (in 4-Byte-Schritten) verlängern können.

			{\| border="1" cellpadding="4" cellspacing="0" style="text-align:center;margin:auto;"
			! width="12%" \| 0–3
			! width="12%" \| 4–7
			! width="12%" \| 8–11
			! width="12%" \| 12–15
			! width="9%" \| 16–18
			! width="15%" \| 19–23
			! width="12%" \| 24–27
			! width="12%" \| 28–31
			\|-----
			\| [[IP-Paket#Version\|Version]]
			\| [[IP-Paket#IHL (IP Header Length)\|IHL]]
			\| colspan="2" \| [[IP-Paket#TOS (Type of Service)\|Type of Service]]
			\| colspan="4" \| [[IP-Paket#Total Length\|Gesamtlänge]]
			\|-----
			\| colspan="4" \| [[IP-Paket#Identification\|Identifikation]]
			\| [[IP-Paket#Flags\|Flags]]
			\| colspan="3" \| [[IP-Paket#Fragment Offset\|Fragment Offset]]
			\|-----
			\| colspan="2" \| [[Time-to-live\|TTL]]
			\| colspan="2" \| [[Protokoll (IP)\|Protokoll]]
			\| colspan="4" \| Header-[[Prüfsumme]]
			\|-----
			\| colspan="8" \| Quell-IP-Adresse
			\|-----
			\| colspan="8" \| Ziel-IP-Adresse
			\|-----
			\| colspan="8" \| ''evtl. Optionen …''
			\|}

			Eine spezielle Bedeutung kommt in modernen Implementierungen dem Feld ''Type of Service'' zu. Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. In modernen Implementierungen wird dieses Feld im Zusammenhang mit der [[Network congestion avoidance\|Vermeidung von Überlastungen]] verwendet.

	==Quellenangaben==		==Quellenangaben==

← Nächstältere Version		Version vom 18. Februar 2013, 22:11 Uhr
Zeile 262:		Zeile 262:
	! width="12%" \| 28–31		! width="12%" \| 28–31
	\|-----		\|-----
	\| ~~[[IP-Paket#~~Version~~\|Version]]~~		\| Version
	\| ~~[[IP-Paket#~~IHL ~~(IP Header Length)\|IHL]]~~		\| IHL
	\| colspan="2" \| ~~[[IP-Paket#TOS (~~Type of Service~~)\|Type of Service]]~~		\| colspan="2" \| Type of Service
	\| colspan="4" ~~\| [[IP-Paket#Total Length~~\|Gesamtlänge]]		\| colspan="4" \| Gesamtlänge
	\|-----		\|-----
	\| colspan="4" ~~\| [[IP-Paket#Identification~~\|Identifikation]]		\| colspan="4" \| Identifikation
	~~\| [[IP-Paket#Flags~~\|Flags]]		\| Flags
	\| colspan="3" ~~\| [[IP-Paket#Fragment Offset~~\|Fragment Offset]]		\| colspan="3" \| Fragment Offset
	\|-----		\|-----
	\| colspan="2" ~~\| [[Time-to-live~~\|TTL]]		\| colspan="2" \| TTL
	\| colspan="2" ~~\| [[Protokoll (IP)~~\|Protokoll]]		\| colspan="2" \| Protokoll
	\| colspan="4" \| Header-[[Prüfsumme]]		\| colspan="4" \| Header-Prüfsumme
	\|-----		\|-----
	\| colspan="8" \| Quell-IP-Adresse		\| colspan="8" \| Quell-IP-Adresse

← Nächstältere Version		Version vom 18. Februar 2013, 22:10 Uhr
Zeile 240:		Zeile 240:

	ICMP kann zusammen mit dem ''Don’t-Fragment''-Bit des IP-Pakets auch eingesetzt werden, um die maximale Paketgröße MTU eines Übertragungsweges zu ermitteln (sogenannte PMTU ''Path Maximum Transmission Unit''). Dies ist die MTU desjenigen Netzwerkes mit der kleinsten MTU aller passierten Netzwerke. Dadurch kann auf Fragmentierung verzichtet werden, wenn der Sender nur Pakete mit der maximalen Größe der PMTU erzeugt.		ICMP kann zusammen mit dem ''Don’t-Fragment''-Bit des IP-Pakets auch eingesetzt werden, um die maximale Paketgröße MTU eines Übertragungsweges zu ermitteln (sogenannte PMTU ''Path Maximum Transmission Unit''). Dies ist die MTU desjenigen Netzwerkes mit der kleinsten MTU aller passierten Netzwerke. Dadurch kann auf Fragmentierung verzichtet werden, wenn der Sender nur Pakete mit der maximalen Größe der PMTU erzeugt.

			== IPv4 auf Ethernet ==
			IPv4 kann auf vielen verschiedenen Medien aufsetzen, zum Beispiel auf serielle Schnittstellen (PPP oder SLIP), Satellitenverbindungen usw. Im LAN-Bereich wird heute fast immer Ethernet eingesetzt. Ethernet verwaltet eigene 48-Bit-Adressen. Wenn IP über Ethernet gesendet wird, wird ein 14 (oder bei VLAN 18) Byte großer Ethernet-Header vor dem IP-Header gesendet. Nach den Daten folgt eine 32-Bit-CRC-Prüfsumme. Neben der maximalen Paketlänge von 1522 (bzw. 1518) Bytes kann Ethernet keine kleineren Pakete als 64 Bytes übertragen, so dass zu kurze IP-Pakete (Datenlänge kleiner als 46 Bytes) mit Nullbytes erweitert werden (sogenanntes Padding). Die Länge im IP-Header gibt dann Auskunft über die tatsächliche Paketgröße.

			Im Ethernet hat jede Netzwerkkarte ihre eigene, herstellerbezogene 48-Bit-Adresse, zusätzlich gibt es eine Ethernet-Broadcastadresse. Ein Sender muss die Ethernetadresse der Zielnetzwerkkarte kennen, bevor ein IP-Paket gesendet werden kann. Dazu wird ARP (Address Resolution Protocol) verwendet. Jeder Rechner verwaltet einen ARP-Cache, in dem er ihm bekannte Zuordnungen von Ethernet-Kartenadressen speichert. Unbekannte Adressen erfährt er über ARP mittels einer Anfrage (ARP-Request) über einen Ethernet-Broadcast (Nachricht an alle Empfänger), die der zugehörige Empfänger beantwortet (ARP-Reply).

			== Header-Format ==

			Der IPv4-Header ist normalerweise 20 Bytes lang. Bei Übertragung auf Basis von Ethernet folgt er dem Ethernet-Typfeld, das für IP-Pakete auf 0800<sub>16</sub> festgelegt ist. Auf anderen Übertragungsmedien und Protokollen kann der Header auch der erste Eintrag sein.

			IPv4 bietet verschiedene, größtenteils ungenutzte Optionen, die den Header bis auf 60 Bytes (in 4-Byte-Schritten) verlängern können.

			{\| border="1" cellpadding="4" cellspacing="0" style="text-align:center;margin:auto;"
			! width="12%" \| 0–3
			! width="12%" \| 4–7
			! width="12%" \| 8–11
			! width="12%" \| 12–15
			! width="9%" \| 16–18
			! width="15%" \| 19–23
			! width="12%" \| 24–27
			! width="12%" \| 28–31
			\|-----
			\| [[IP-Paket#Version\|Version]]
			\| [[IP-Paket#IHL (IP Header Length)\|IHL]]
			\| colspan="2" \| [[IP-Paket#TOS (Type of Service)\|Type of Service]]
			\| colspan="4" \| [[IP-Paket#Total Length\|Gesamtlänge]]
			\|-----
			\| colspan="4" \| [[IP-Paket#Identification\|Identifikation]]
			\| [[IP-Paket#Flags\|Flags]]
			\| colspan="3" \| [[IP-Paket#Fragment Offset\|Fragment Offset]]
			\|-----
			\| colspan="2" \| [[Time-to-live\|TTL]]
			\| colspan="2" \| [[Protokoll (IP)\|Protokoll]]
			\| colspan="4" \| Header-[[Prüfsumme]]
			\|-----
			\| colspan="8" \| Quell-IP-Adresse
			\|-----
			\| colspan="8" \| Ziel-IP-Adresse
			\|-----
			\| colspan="8" \| ''evtl. Optionen …''
			\|}

			Eine spezielle Bedeutung kommt in modernen Implementierungen dem Feld ''Type of Service'' zu. Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. In modernen Implementierungen wird dieses Feld im Zusammenhang mit der [[Network congestion avoidance\|Vermeidung von Überlastungen]] verwendet.

	==Quellenangaben==		==Quellenangaben==