Diskussion:Address Resolution Protocol/Archiv

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:Address Resolution Protocol/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

nochmal ich

sorry, da ich nicht angemeldet bin, hinterlasse ich mal hier meine mail adresse.

hellenicwar@hotmail.com

mfg

anesti

arp und routing vs. ethernet und subnetz

Hi, Bin an dem Satz "Das ARP-Protokoll kann nur die MAC-Adressen der Geräte im gleichen Subnetz auflösen, da Ethernet-Broadcasts auf Subnetze beschränkt sind". Sinngemäß stimmts, aber die erklärung ist falsch. Für ethernet gib es keine Subnetze, sondenen lediglich ein Netze, für die dann auch broadcasts undeingeschrängt gelten. Ein ethernet kann meherer ip-subnetze beinhalten. Mich verwirrt dieser Abschnitt mehr als er hilft. Eigentlich gehts um ARP und nicht um weiterleitung/routing. Falls er doch als beispiel gelassen werden soll, mein Vorschlag: ersten Satz weglassen danach weiter wie gehabt, oder ändern in "Das ARP-Protokoll _muss lediglich_ die MAC-Adressen der Geräte im gleichen Subnetz auflösen." Bin vielleicht ein bisschen spiesig, aber stimmt halt nicht. Zu der Diskussion wegen schichten: bei der TCP/IP Familie isses Schicht 2, (vermittlungsschicht). Am besten so benennen wies bei TCP/IP bezeichnet wird. Bei osi ist es schicht 3, keinensfalls schicht 2.5. Warum? ARP setzt komplett auf der Sicherungschicht(data link layer - mac) auf, also eher ein ip-hilfsprotokoll. mfg Tobi

Funktionsweise

Hi.

Folgender Text im Abschnitt "Funktionsweise":

Bei Broadcasts ist das Erzeugen eines Ethernetframes kein Problem, da als MAC-Zieladresse die Broadcast-Adresse ff-ff-ff-ff-ff-ff16 verwendet wird. Jeder Rechner, der diese ARP-Broadcast-Anforderung empfängt, aktualisiert damit seinen so genannten ARP-Cache, wenn die Absender-IP-Adresse darin nicht enthalten ist.

impliziert, daß _jeder_ Rechner seinen arp-cache bei einer vorbeikommenden arp-Anforderung aktualisiert. Ich konnte das bei Tests mit Linux nicht feststellen, es steht zwar auch so im CCNA v3.1.1 aber auch ausgebildetete Cisco-Leute konnten mir das Verhalten nicht bestätigen. Ebenfalls konnte ich im RFC nichts finden.

ARP und Routing

Ich musste den Abschnitt zu ARP und Routing stark überarbeiten, habe erstmal nur alles falsche rausgenommen und ein wenig umformuliert, damit es wenigstens korrekt ist. Damit der Kontext gewahrt wird, habe ich den Abschnitt "ARP im globalen Zusammenhang" umbenannt. Kurze Erklärung:

1. ARP hat überhaupt nichts mit Routing zu tun. ARP löst für Protokolle höherer Schichten die Ethernetadressen auf. Dass bei Internetkommunikation Routing stattfindet ist ja schön und gut, aber ARP spielt sich nur im lokalen Netz ab, um Router kümmert sich IP.
2. Zu behaupten in den unteren Schichten dürfen Pakete verloren gehen, daher verwirft man sie mal eben, anstatt auf die ARP Antwort zu warten, geht weit an der Realität vorbei. Ich persönlich kenne keine Implementierung von IP und ARP, die Pakete während der MAC Adressauflösung verwirft, und ich habe mich schon mit einigen auseinandergesetzt, auch eine selbst implmentiert. Soll heißen: IP wartet eine gewisse Zeit auf die ARP Antwort und verwirft erst, wenn es annehmen muss, dass der gesuchte Host nicht im lokalen Netz ist. Das ist selbst auf eingebetteten Systemen so, die sich großartige Paketpuffer kaum leisten können.
3. Die Abbildung zeigt schön, wie ARP und IP interagieren können, aber eigentlich ist sie nur ein Beispiel. Das es tatsächlich so abläuft steht nirgends festgeschrieben und ist bei jeder Implementierung leicht anders.

-> Eigentlich wär ich dafür den Abschnitt zum Routing ganz rauszunehmen, brings aber grad nicht übers Herz, weil sich da jemand soviel Mühe mit der Grafik gegeben hat. Letztlich muss man aber sagen, dass ARP und IP-Routing zwei komplett verschiedene paar Schuhe sind und das Routing besser bei IP erklärt würde -- von mir aus inkl. der Grafik, da es auch die IP Implementierung ist, die ARP aufruft, und nicht umgekehrt. --JonKowal 16:20, 11. Jul. 2007 (CEST)

alte Schichtendiskussion

Wird Arp eigentlich auch für WLAN verwendet? Schließlich gibt es ja Ethernet/WLAN-Bridges, und Bridges arbeiten ja auf Schicht 2... Wenn ja, dann wäre das ein erwähnenswertes Beispiel...

Zugegeben, einige Formulierungen waren etwas unglücklich. Arp gehört aber doch niemals zur Internetschicht, die sich ja mit Routing beschäftigt. Manche Quellen ordnen ARP als Low Level Protocol dem Layer 2 zu (Netzzugang). Ich würde es sogar zwischen Layer 2 und Layer 3 einordnen, da es ja die Adressierung von beiden Schichten verwendet und damit "Wissen" aus beiden Schichten enthält. Der Satz es gehört zur Internetschicht der TCP/IP Protokollfamilie kann so nicht stehenbleiben

Außerdem würde mich mal interessieren, wie ich ohne MAC-Adresse einen vollständigen Frame erzeugen soll?

Und dann verwendet die Literatur zwar oft Frame für Layer 2 und Paket für Layer 3, aber dann doch nicht durchgehend (bei Layer4 heisst dann Datagram). Insbesondere bei Erklärungen für Protokollstacks heißt dann plötzlich alles wieder Paket. Hubi 07:19, 27. Sep 2003 (CEST)

zu 1. Wir sprechen hier vom TCP/IP-Referenzmodell, nicht dem OSI-Modell. In Ersterem gehört es zur Internet- oder Netzzugangsschicht. Die Einordnung ist da nicht ganz eindeutig, aber ich habe es der Einheitlichkeit (in der Wikipedia) halber in der Internetschicht gelassen.

zu 2. Das ARP-Paket ist auch nicht vollständig (wenn man so will), da dort auch die MAC-Adresse fehlt. Der Punkt ist, dass der Frame nicht versendet werden kann.

zu 3. Also mein Stevens verwendet für Ethernet Frame, für IP und UPD Datagram (=Paket) und für TCP Segment (wird im Deutschen wohl nicht so oft verwendet). --diddi 11:30, 27. Sep 2003 (CEST)

Dazu noch einige Anmerkungen. Das TCP/IP-Referenzmodell ist ein Kunstprodukt (jedenfalls nach meiner Meinung), das das etablierte OSI-Referenzmodell nachahmt, jedoch kein eingeführtes und allgemein akzeptiertes Modell. Das OSI-Modell passt nicht so ganz auf das TCP/IP-Protokoll, daher ein eigenes Modell. Im Wikipedia-Artikel wird zwar ARP auf die Netzwerkschicht (nicht Internetschicht) dgestellt, dies ist jedoch keinesfalls zwingend so. Internet heisst ja gerade "Zwischen"-"Netz", betrifft also gerade mehrere Netze. ARP ist aber ein reines LAN-Protokoll, daher bleiben meine Bedenken gegenüber gehört zur Internetschicht bestehen. Vielleicht in gehört zur Netzwerkschicht ändern, damit wäre der Artikel auch konform zum TCP/IP-Referenzmodell-Artikel und ich hätte keine Bedenken mehr.

And now for something completely different: Ich hab mir heute die ganze Sache noch mal durch den Kopf gehen lassen und bin zu dem Schluß gekommen, dass der Aspekt, dass ARP ein LAN-Protokoll ist, eigentlich in dem Artikel zu kurz kommt bzw. erst gar nicht erwähnt wird. Dort heisst es: wird ein ARP-Request-Broadcast mit der IP-Adresse des anderen Computers gesendet. Dies ist so richtig, aber es wird nicht gesagt welche IP-Adresse für den Broadcast verwendet wird. ARP kann ja nur lokale Adresszuordnungen auflösen. Was wirklich geschieht ist folgendes:

1. Ein Host will an eine beliebige IP-Adresse (LAN oder WAN) ein Paket senden
2. Die IP-Adresse wird mit der Routingtabelle geroutet, Ergebnis ist ein Interface und die lokale IP-Adresse des Ziels (im Falle nicht-lokaler Hosts die Adresse des Gateways, die sich von der Original-IP-Adresse unterscheiden kann)
3. Die IP-Adresse aus der Routingtabelle ist garantiert eine LAN-Adresse. Diese wird in der ARP-Tabelle gesucht, Ergebnis ist ein Interface und eine MAC-Adresse
4. Falls der Eintrag in der ARP-Tabelle nicht zu alt ist wird die ermittelte MAC-Adresse verwendet und das Paket losgeschickt.
5. Andernfalls wird gewartet und über das Interface und der IP-Adresse aus dem Routing zunächst über ARP die MAC-Adresse des anderen Hosts bzw. Gateways ermittelt. Erst danach kann das Paket gesendet werden. Die MAC_Adressen weiterer Pakete mit demselben Ziel können ohne zusätzlichen ARP-Zwischenschritt mit Hilfe der ARP-Tabelle aufgelöst werden.

Ergebnis ist, dass ARP nur die lokalen IP-Adressen behandelt und auch nur behandeln muss. Dies sollte IMHO unbedingt in den Artikel rein und so erklärt werden, dass möglichst keine Unklarheiten mehr übrigbleiben. Hubi 23:05, 27. Sep 2003 (CEST)

Das mit dem TCP/IP-Referenzmodell ist leider alles ziemlich WischiWaschi im Deutschen. Der Network-Layer heißt bei uns Netzwerkschicht _oder_ Internetschicht. Man muss man dann auch den Data Link-Layer als Netzwerkschicht (!) _oder_ Netzzugang (oder sonstwie) übersetzen. Anyway, wir können statt "Internetschicht" auch "Netzwerkschicht" schreiben -- das wäre kein Problem.

Na ja, ich habe nochmal ein paar Quellen bemüht und im Englischen ist die Bezeichnung wohl auch nicht ganz eindeutig: Networklayer = Internetlayer und Netzwerkschicht = Internetschicht. Ist es ok für dich, wenn wir ARP im OSI-Modell auch der Netzwerkschicht (#3) (oder doch lieber Netzzugangsschicht (#2)) zuordnen? --diddi 00:03, 28. Sep 2003 (CEST)

Der Routing-Aspekt im ARP-Artikel steht bei mir auch schon seit längerer Zeit auf der Todo-Liste, aber ich kenne mich leider zu wenig mit Routing aus, als das ich dazu was ausführlich schreiben könnte. Wäre schön, wenn du das im Artikel ergänzen könntest. --diddi 23:43, 27. Sep 2003 (CEST)

Also ich hab im Hinterkopf immer so Assoziationen Netzwerk=einzelnes Netzwerk=Subnetz im LAN und Internet=Netzwerk von Netzwerken=WAN bzw. LAN mit Routern. Die deutschen Bezeichnungen im TCP/IP-Referenzmodell Artikel sind soweit ich's bisher sehe ok, dort wird Netzwerkschicht und Internetschicht synonym verwendet. Man kann es so darstellen und der Artikel gefällt mir irgendwie :-). Im ARP-Artikel würde ich unbedingt Netzwerkschicht und nicht Internetschicht schreiben, da auf einzelne Subnetze beschränkt. Diese sprachliche Feinheit sei gestattet.

Bzgl. Einordnung von TCP/IP-Protokollen in's OSI-Modell gibt es immer schwierigkeiten. Wenn ich mich entscheiden müsste, würde ich von der Funktion her zu Layer 2 tendieren, da z. B. Ethernetadressen verwendet werden (zwar nur für Vergleiche, ARP hat ja eine abstrakte Sicht der Adressen, aber trotzdem). Wenn ich könnte, würde ich ein kleines Kästchen als Link zwischen Schicht 2 und Schicht 3 zeichnen, etwa so

              +--------------------+          --
              |  IP       +--------+      Schicht 3
              +-----------| ARP    |          --
              |  MAC      +--------+      Schicht 2   
              +--------------------+          --

Wir müssen die Protokolle ja der Funktion nach zuordnen. Ich hab's mal mit einfachem Headerzählen probiert. Bei Ethernetframes kommt man bei einen TCP-Paket dann auf (Preamble und Delimiter)->Schicht1, MAC-Header->Schicht2, IP->Schicht3 und TCP-Schicht4, also alles ok. ARP würde dann auf Schicht3 landen, aber, leider leider, ICMP auf Schicht4, da Schicht3 ja durch IP belegt ist. ICMP kann aber keinesfalls auf Schicht4. Daher geht's nicht so einfach.

(Übrigens: TCP gehört auch nicht eindeutig zur OSI-Schicht4, denn wenn man den Verbindungsabbau mit den halboffenen Verbindungen nimmt, so gehört diese Funktion eindeutig (in OSI) zu Schicht 5, TCP daher 90% OSI-Schicht4 und ca. 10% OSI-Schicht5). Meiner Meinung nach sind Schichtenmodelle hilfreich und dienen der Ordnung und dem Verständnis, aber bei so Sachen wie ARP muss einfach wieder die Meta-Ebene her.

Wie kommen wir aus der Zwickmühle ARP Schicht2 oder 3 heraus - ganz einfach: Wir stellen im ARP-Artikel einfach die Schwierigkeit der Zurodnung dar und schreiben, dass es manchmal der Schicht2 und manchmal der Schicht3 zugeordnet wird.

Bzgl. Routing würde ich im ARP-Artikel einen kleinen Abschnitt (ARP und Routing) einfügen in dem in 2-3 Sätzen auf die IP-Adresse -> Routingtabelle -> IP-Adresse im Subnetz Konvertierung hingewiesen wird und dann auf den Routing-Artikel verwiesen wird. In nächster Zeit schau ich mir mal den Routingartikel an.

Noch ein privates Wort zum Schluss: Ich freu mich sehr darüber, wie sich das hier entwickelt Hubi 07:55, 28. Sep 2003 (CEST)

Zum ARP-Cache

Ist der ARP-Cache in Software oder in Hardware implementiert? oder anders gefrag: baut mein Betriebssystem in einer Datei diesen ARP-Cache auf, oder hat meine Netzwerkkarte einen z.B. Flash-Speicher, in dem der ARP-Cache drinsteckt?

Danke, --Abdull 15:34, 22. Jan 2005 (CET)

Das ist normalerweise eine Tabelle im Kernel des Betriebssystems, also reine Software. Also so ähnlich wie die Prozesstabelle. Unter Unix/Linux kann man die Tabelle mit dem arp-Kommando anschauen und manipulieren. Netzwerkkarten, die ARP unterstützen, sind mir für PCs nicht bekannt. Man könnte dies machen, und es ist wahrscheinlich auch schon gemacht worden, man spart aber wohl nicht viele Prozessorzyklen wenn man den ARP-Cache mit guten Algorithmen (Hash-Verfahren) in Software implementiert. --Hubi 09:35, 23. Jan 2005 (CET)

Zum ARP Paketformat

Die Tabelle welche den Aufbau eines ARP Paketes darstellt sieht so aus als ob ein ARP Paket 5 Bytes "breit" wäre, da die Tabelle 5 Spalten hat. So könnte man leich fälschlicherweise annehmen dass der Eintrag für die Quell-MAC Adresse 7 Bytes lang ist (auf zwei "Zeilen" verteilt), was natürlich nicht stimmt, eine MAC Adresse hat bekanntermaßen nur 6 Bytes

MfG Heinz Drache -- Benutzer:85.72.140.102, 02:09, 19. Sep 2005 Unterschrift erg, -- 10:02, 19. Sep 2005 (CEST)

Die Tabellen waren tatsächlich irreführend. Ich habe die fünfte Spalte entfernt. -- Stefan506 10:02, 19. Sep 2005 (CEST)

ok danke

ARP Umarbeitung

Hallo, ich habe einen Teil des ARP Artikels umgearbeitet an dem Du ja maßgeblich beteiligt warst. Ich wollte damit weder Dich noch Eure vorherige Diskussion übergehen, aber es waren wirklich Fehler und Ungenauigkeiten im Text, 16:28, 11. Jul. 2007 (CEST) (Kopie aus der Diskussionsseite von Hubi

Schau mal in RFC826 rein

Packet Generation:

As a packet is sent down through the network layers, ...

If it finds the pair, it gives the corresponding 48.bit Ethernet address back to the caller (hardware driver) which then transmits the packet. If it does not, it probably informs the caller that it is throwing the packet away (on the assumption the packet will be retransmitted by a higher network layer), and generates an Ethernet packet with a type field of ether_type$ADD.. --18:34, 11. Jul. 2007 (CEST)

Mal davon abgesehen, dass dort sowieso alles auf einer "probably"-Basis formuliert ist (die exakten Abläufe unterscheiden sich in der Praxis erheblich zwischen verschiedenen Internetstacks), steht dort nur, dass sich ARP nicht auf das Reply wartet, sondern seine Pflicht erfüllt sieht wenn es ein Request gesendet hat. Im ARP Artikel stand aber, dass verworfen wird, weil TCP ja neusenden würde. Tatsächlich ist es aber IP, welches geduldig wartet bis ein ARP Reply eintrudelt. Da es für ARP aber völlig unerheblich ist, wer sich darum kümmert, habe ich diesen Teil aus dem Artikel entfernt. --JonKowal 14:45, 13. Jul. 2007 (CEST)

Nachtrag: Ich find das aber auch etwas missverständlich im RFC 826 formuliert. Da ARP sowieso nur die Ethernetadresse auflöst, hat es mit dem eigentlich zu versendenden Paket überhaupt nichts zu tun. Die Information es würde das Paket wegwerfen ist völlig überflüssig, da ARP mit dem Paket auch bei erfolgreicher Adressauflösung nichts macht (es also auch dann verwirft). Vielleiht war ja mal die Intention zu schreiben, dass ARP im Erfolgsfall selbst den Versand des Pakets übernehmen könnte, aber das steht so erstens nicht im RFC und zweitens macht es auch nur bedingt Sinn, da ARP so mehr als nur die Rolle der Adressauflösung zukommen würde. --JonKowal 15:07, 13. Jul. 2007 (CEST)

Mindestens TCP muss neu senden. Dass IP neu sendet, steht so jedenfalls mWn in keiner RFC. ARP kann ein IP-Paket überschreiben und darf den IP-Layer darüber informieren, muss aber nicht. Warten muss auch niemand (optionaler blauer Teil), effizient ist das aber nicht --Hubi 08:21, 15. Jul. 2007 (CEST)

Nochmal von vorne, ich glaub Du hast mich missverstanden. Ich sehe die Abarbeitung im Stack wie folgt:

1. IP möchte ein Paket über die Netzzugangsschicht zu senden, ihm fehlt aber die Zieladresse der Netzzugangsschicht, um dies zu tun.
2. Die Netzzugangsschicht bietet (z.B. als Teil des Hardwaretreibers) die Auflösung von IP Adressen an.
3. IP bittet um Auflösung der IP Adresse des lokalen Netzwerkziels.
4. Im Falle von Ethernet kümmert sich ARP um diese Auflösung. Findet es den Eintrag nicht in der Cache muss es ein Request lossenden und auf die Antwort warten. Zu diesem Zeitpunkt wird kein Paket verworfen oder ähnliches.
5. Der Hardwaretreiber oder IP wartet nun auf die Adressauflösung. Wer wartet hängt von der Implementierung ab, Fakt ist (definitiv, zu diesem Zeitpunkt wird nicht verworfen), dass gewartet wird.
   1. Wenn die Adresse aufgelöst wurde, kann ARP sie an IP geben, welches damit die Senderoutine des Hardwaretreibers bedient.
   2. Wenn die Adresse nicht aufgelöst (Timeout der wartenden Instanz) wurde, erfährt die IP ebenfalls und meldet nach oben "Host not found".

Ein Paket wird also nur dann verworfen, wenn innerhalb eines bestimmten Timeouts die Hardwareadresse nicht aufgelöst werden konnte. Das kannst Du nachvollziehen, indem Du mal von Deinem Rechner einen Ping an einen Host schickst, zu dem Du zuvor noch keinen Kontakt hattest, und somit auch keinen Eintrag im ARP Cache. Der erste Ping geht hierbei nicht verloren, sondern es wird auf die ARP Auflösung gewartet. Dass nicht verworfen wird siehst Du daran, dass kein TCP oder sonstiges Protokoll im Spiel, welches Retransmits unterstützt; der nicht-Verlust des ersten Pings liegt also nicht am Neusenden irgendeiner Schicht, sondern am Warten auf das ARP Reply.

Dass ARP (wie Du schreibst) in der Lage ist IP Pakete zu überschreiben finde ich wiederum nirgendwo. JonKowal 11:26, 10. Aug. 2007 (CEST)

Quelle?

"Moderne Implementierungen ändern die ARP-Tabelle nur für ARP-Antworten, für die vorher von dem betreffenden Host eine -Anforderung generiert wurde."

Wo ist die Quelle dafür? ARP-Spoof Funktioiert trotzdem, auch mit ARP-Replys wofür kein entsprechender ARP-Request gesendet wurde.

---

Ich finde es auch nicht "modern", wenn ARP-Antworten nicht ohne Anfrage angenommen werden. Ein ändern vor dem Timeout ist damit nicht möglich.

Weiterhin stört mich die Verlinkung: Wenn "Implementierungen" verlinkt ist, vermutet der Leser, dass der Link zu Details dieser Implementierung führt und nicht zur Erklärung des Wortes "Implementation".

212.123.98.160 14:31, 15. Jan. 2008 (CET)

Schichtenzuordnung von ARP

Ich habe hier mal eine neue Überschrift für die Schichtendiskussion aufgemacht, da ich das Gefühl hab, dass sich die alte Diskussion (siehe unten) festgefahren hat.

Letztlich ist wohl klar, dass man für die Einordnung von ARP in die Internetschicht genauso Argumente findet, wie für die Einordnung in das Data Link Layer. IMHO sollten wir das nicht daran festmachen, was einzelne für richtighalten, sondern wie es in der Literatur behandelt wird. In allen Quellen, die mir dazu vorliegen, wird ARP als Teil des Data Link Layer (Teil der TCP/IP Netzzugangsschicht) behandelt. Ein paar Quellen zur Untermauerung:

• RISP: address resolution protocol in network layer: Ein Paper, wo es eben darum geht die Adressauflösung aus dem Linklayer rauszukriegen.

  "Conventionally, the network layer (such as IP) to link layer (such as Ethernet and ATM) address translation is done in the link layer.This approach requires link technology-specific solutions such as ARP for Ethernet, and ATMARP or NHRP for ATM."

• RFC 1122 "Requirements for Internet Hosts -- Communication Layers": Hier wird ARP auch eindeutig im Link Layer platziert. Aufgabe von ARP ist es nämlich Link Layer Adressen zu finden, und das hat mit anderen Schichten als dem Link Layer erstmal nicht viel zu tun. (Seite 21)

  "On an Ethernet, packets encapsulated with trailers use a distinct Ethernet type [LINK:1], and trailer negotiation is performed at the time that ARP is used to discover the link-layer address of a destination system."

Da diese Quellen für mich überzeugender sind, als die hier geführte Diskussion, und ich in dieser Diskussion bisher auch keine Quellenangaben gesehen habe, werde ich die Schichteneinordnung im Artikel ändern und ARP der Netzzugangsschicht zuordnen.

Für die weitere Diskussion bin ich natürlich offen, fände es aber gut, wenn hier nicht weiter nach Gefühl diskutiert wird, sondern Quellen benannt werden, denen man abnimmt, dass sie nicht nur bei Wikipedia nachgelesen haben. --JonKowal 15:44, 11. Jul. 2007 (CEST)

aber ohne Ethernet funktioniert ARP nicht, es müsste über Ethernet, aber noch in die DLL Schicht --Michinaugk 08:14, 23. Aug. 2007 (CEST)

Nun, es steht nirgends, dass ein Dienst nicht auch andere Dienste aus der eigenen Schicht nutzen darf. ICMP geht auch nicht ohne IP, obwohl es zur gleichen Schicht gehört. JonKowal 18:36, 9. Nov. 2007 (CET)

Ich habe den Protokollstapel nun so angepasst, dass es zur Netzzugangschicht/Sicherungsschicht gehört, aber auf Ethernet (und anderen Netzzugangsprotokollen, wo es auch verwendet wird) aufbaut. Ich hoffe damit können alle leben.--Merlissimo 15:45, 12. Jun. 2008 (CEST)

ARP und IPv6

Vor einiger Zeit habe ich einen Hinweis in die Seite eingearbeitet, dass ARP für IPv6 nicht verwendet werden wird, was mir die Seite jedoch immer noch zu nahe zu legen scheint. In der englischen Darstellung ist das sehr deutlich. Ich würde diesen Hinweis gerne ganz nach oben ziehen und das zweite Header-Beispiel mit IPv6 löschen. Soll ich? Jan Rischmüller

NDP nach oben ziehen - gute Idee, Header-Beispiel 2 nur dann löschen, wenn ein"ARP-Verbot" explizit aus einem RFC ableitbar. --Kgfleischmann 13:24, 12. Okt. 2008 (CEST)

OK, RFC4861 sagt: "This specification defines the Neighbor Discovery (ND) protocol for Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use Neighbor Discovery to determine the link-layer addresses for neighbors known to reside on attached links..." Niemand verbietet das Packen von solchen ARP-Paketen, aber für die IPv6-Auflösung sollen sie in keiner Implementierung verwendet werden. Das Beispiel ist daher meinem didaktischen Empfinden nach irreführend und erschwert die dringend notwendige Aufgabe der Aufklärung über IPv6. Es wird noch genug Menschen geben, die verzweifelt die ARP-Tabelle aufrufen und darin nach IPv6-Adressen suchen :-/ Jan Rischmüller

Schlage vor, warte mit den Änderungen, wenn sich bis Mitte der Woche niemand wiederspricht, ändern.--Kgfleischmann 14:46, 12. Okt. 2008 (CEST)

Proxy-ARP

Momentan steht: "Die Hosts befinden sich dabei in verschiedenen Netzen"

Jedoch: wenn ein Host ein Gerät aus einem anderen Netz erreichen möchte, so wird er kein Arp-Request senden, sondern über sein default gateway gehen, Proxy-Arp funkioniert also nur, wenn der anfragende Host denkt, sein Ziel liegt im gleichen Netz. Dies kann auf Grund unterschiedlicher Subnetzmasken der Fall sein. Host A mit einer /16 Maske fragt per ARP an, der Router mit einer /24 Maske antwortet mit seiner MAC-Adresse. --Mgoerke 15:00, 25. Apr. 2009 (CEST) (nicht signierter Beitrag von Mgoerke (Diskussion | Beiträge) 18:47, 24. Apr. 2009 (CEST))

Bezeichnungen

guten tag

ich lese gerade den text über arp und muss leider festellen, das für das ein und das selbe (ip-adresse) viele verschiedene bezeichnungen genannt werden. ich finde es sehr unübersichtlich und verwirrend. ok, hardwareadresse ist klar, das damit die mac-adresse gemeint ist. aber seid ihr nicht gleicher meinung, das für den begriff ip-adresse 3 alternativen zuviel ist? Netzwerkadresse, internetadresse und ethernetadresse. sorry, aber bei soviel vielfalt werde ich bala bala.

mfg annesti

---> Mit Ethernetadresse wird meistens die MAC-Adresse und mit Internetadresse eine Domain bezeichnet.

Gruss Nadine

Das kommt auch darauf an, in welchem Zusammenhang die Adressen genannt werden

• Netzwerkadresse = allgemeine Bezeichnung für eine Adresse im N.
• Internetadresse = bringen die meisten sicherlich mit einer Adresse wie http://de.wikipedia.org in Verbindung
• Ethernetadresse: Spezifisch, vgl. 1.

Nächstes Mal bitte auch Signieren, ich weiß gar nicht, wie alt dein Beitrag ist. --BlueScreen-Bertrand 15:09, 25. Nov. 2009 (CET)

Tabelle falsch

Die Tabelle auf dieser Seite ist schon seit über einem Jahr falsch. Bitte mal mit dem englischen Wikiartikel vergleichen oder auf die verlinkten RFC's schauen. Da ich leider nicht genau weiß wie man die Tabelle ändert, kann ich das nicht selber machen. Die MAC-Felder sind jeweils 48 Bit groß und die IP-Felder nur 32 Bit! Ich denke der Ersteller wollte das auch so machen, nur müssen teilweise halbe statt durchgängige Linien verwenden werden. (nicht signierter Beitrag von 78.49.120.52 (Diskussion | Beiträge) 18:45, 19. Jan. 2010 (CET))

Abschnitte Probleme und Gratuitous ARP

Im Abschnitt "Probleme" steht:

Moderne Implementierungen ändern die ARP-Tabelle nur für ARP-Antworten, für die vorher vom betreffenden Host eine Anforderung generiert wurde.

Wenn das so ist, dürfte "Gratuitous ARP" ja völlig nutzlos geworden sein? Kann das jemand bestätigen? --Martinschneider 10:58, 11. Aug. 2011 (CEST)