RFC 826 - Versionshistorik

Admin den 24 november 2024 kl. 17.20

2024-11-24T17:20:28Z

← Äldre version		Versionen från 24 november 2024 kl. 17.20
Rad 9:		Rad 9:

	== Sammanfattning ==		== Sammanfattning ==
	När implementationen av protokoll P på en avsändande värd S bestämmer sig, genom P:s routningsmekanism, för att skicka data till en målvärd T som är ansluten till samma Ethernet-kabel, behöver en 48-bitars Ethernet-adress genereras. Adresser i protokoll P är inte alltid kompatibla med Ethernet-adresser (olika längder eller värden). Här presenteras ett protokoll som dynamiskt distribuerar information för att bygga tabeller som kan översätta en adress A i P:s adressrymd till en 48-bitars Ethernet-adress.		När implementationen av protokoll P på en avsändande värd S bestämmer sig, genom P:s routningsmekanism, för att skicka data till en målvärd T som är ansluten till samma Ethernet-kabel, behöver en 48-bitars Ethernet-adress genereras. Adresser i protokoll P är inte alltid kompatibla med Ethernet-adresser (olika längder eller värden). Här presenteras ett protokoll som dynamiskt distribuerar information för att bygga tabeller som kan översätta en adress A i P:s adressrymd till en 48-bitars Ethernet-adress.

	Generaliserade lösningar gör det möjligt att använda protokollet på annan hårdvara än 10Mbit Ethernet, till exempel vissa paketradiobaserade nätverk.		Generaliserade lösningar gör det möjligt att använda protokollet på annan hårdvara än 10Mbit Ethernet, till exempel vissa paketradiobaserade nätverk.
Rad 20:		Rad 20:
	* Adresser presenteras i Ethernet-standardens högsta byte först-format. Detta skiljer sig från exempelvis PDP-11 och VAX.		* Adresser presenteras i Ethernet-standardens högsta byte först-format. Detta skiljer sig från exempelvis PDP-11 och VAX.
	* En central auktoritet krävs för att hantera namnrymden för hårdvaruvärden. Fram tills en sådan existerar kan förfrågningar skickas till:		* En central auktoritet krävs för att hantera namnrymden för hårdvaruvärden. Fram tills en sådan existerar kan förfrågningar skickas till:
	David C. Plummer		David C. Plummer
	Symbolics, Inc.		Symbolics, Inc.
	243 Vassar Street, Cambridge, Massachusetts 02139		243 Vassar Street, Cambridge, Massachusetts 02139
	Alternativt via nätverkspost: DCP@MIT-MC.		Alternativt via nätverkspost: DCP@MIT-MC.

	== Problemet ==		== Problemet ==
Rad 36:		Rad 36:

	== Definitioner ==		== Definitioner ==
	~~* ~~ether_type$XEROX_PUP:** Protokolltyp för Xerox PUP.		* ether_type$XEROX_PUP: Protokolltyp för Xerox PUP.
	~~* ~~ether_type$DOD_INTERNET:** Protokolltyp för Internet.		* ether_type$DOD_INTERNET: Protokolltyp för Internet.
	~~* ~~ether_type$CHAOS:** Protokolltyp för CHAOS.		* ether_type$CHAOS: Protokolltyp för CHAOS.
	~~* ~~ether_type$ADDRESS_RESOLUTION:** Protokolltyp för adressupplösning.		* ether_type$ADDRESS_RESOLUTION: Protokolltyp för adressupplösning.
	~~* ~~ares_op$REQUEST:** Begäran om adressupplösning (värde = 1).		* ares_op$REQUEST: Begäran om adressupplösning (värde = 1).
	~~* ~~ares_op$REPLY:** Svar på adressupplösning (värde = 2).		* ares_op$REPLY: Svar på adressupplösning (värde = 2).
	~~* ~~ares_hrd$Ethernet:** Ethernet-hårdvara (värde = 1).		* ares_hrd$Ethernet: Ethernet-hårdvara (värde = 1).

	== Paketformat ==		== Paketformat ==
	För att kommunicera mappningar från <protokolltyp, protokolladress> till 48-bitars Ethernet-adresser används ett specifikt paketformat:		För att kommunicera mappningar från <protokolltyp, protokolladress> till 48-bitars Ethernet-adresser används ett specifikt paketformat:
	~~* ~~Hårdvarutyp (ar$hrd):** Typ av nätverkshårdvara (t.ex. Ethernet).		* Hårdvarutyp (ar$hrd): Typ av nätverkshårdvara (t.ex. Ethernet).
	~~* ~~Protokolltyp (ar$pro):** Typ av nätverksprotokoll (t.ex. IP).		* Protokolltyp (ar$pro): Typ av nätverksprotokoll (t.ex. IP).
	~~* ~~Hårdvarulängd (ar$hln):** Antal byte i en hårdvaruadress.		* Hårdvarulängd (ar$hln): Antal byte i en hårdvaruadress.
	~~* ~~Protokollängd (ar$pln):** Antal byte i en protokolladress.		* Protokollängd (ar$pln): Antal byte i en protokolladress.
	~~* ~~Operation (ar$op):** Typ av operation (förfrågan eller svar).		* Operation (ar$op): Typ av operation (förfrågan eller svar).
	~~* ~~Avsändarens hårdvaruadress (ar$sha):** Ethernet-adressen för avsändaren.		* Avsändarens hårdvaruadress (ar$sha): Ethernet-adressen för avsändaren.
	~~* ~~Avsändarens protokolladress (ar$spa):** Protokolladressen för avsändaren.		* Avsändarens protokolladress (ar$spa): Protokolladressen för avsändaren.
	~~* ~~Mottagarens hårdvaruadress (ar$tha):** Ethernet-adressen för mottagaren (om känd).		* Mottagarens hårdvaruadress (ar$tha): Ethernet-adressen för mottagaren (om känd).
	~~* ~~Mottagarens protokolladress (ar$tpa):** Protokolladressen för mottagaren.		* Mottagarens protokolladress (ar$tpa): Protokolladressen för mottagaren.

	== Protokollfunktioner ==		== Protokollfunktioner ==
Rad 68:		Rad 68:

	### Exempel		### Exempel
	Maskiner X och Y på samma nätverk:		Maskiner X och Y på samma nätverk:
	1. X skickar en ARP-förfrågan för att få Y:s Ethernet-adress.		1. X skickar en ARP-förfrågan för att få Y:s Ethernet-adress.
	2. Y svarar med sin Ethernet-adress och sparar X:s adress i sin ARP-tabell.		2. Y svarar med sin Ethernet-adress och sparar X:s adress i sin ARP-tabell.
	3. X mottar svaret och kan nu kommunicera med Y.		3. X mottar svaret och kan nu kommunicera med Y.

	== Begränsningar ==		== Begränsningar ==

Admin: Skapade sidan med '= RFC 826 - Ett Ethernet-adressupplösningsprotokoll = Författare: David C. Plummer (DCP@MIT-MC) Publicerad: November 1982 == Titel == Ett Ethernet-adressupplösningsprotokoll -- eller -- Konvertering av nätverksprotokolladresser till 48-bitars Ethernet-adresser för överföring på Ethernet-hårdvara. == Sammanfattning == När implementationen av protokoll P på en avsändande värd S bestämmer sig, genom P:s routningsmekanism, för att skicka...'

2024-11-24T17:19:09Z

Skapade sidan med '= RFC 826 - Ett Ethernet-adressupplösningsprotokoll = Författare: David C. Plummer (DCP@MIT-MC) Publicerad: November 1982 == Titel == Ett Ethernet-adressupplösningsprotokoll -- eller -- Konvertering av nätverksprotokolladresser till 48-bitars Ethernet-adresser för överföring på Ethernet-hårdvara. == Sammanfattning == När implementationen av protokoll **P** på en avsändande värd **S** bestämmer sig, genom **P**:s routningsmekanism, för att skicka...'

Ny sida

= RFC 826 - Ett Ethernet-adressupplösningsprotokoll =
Författare: David C. Plummer (DCP@MIT-MC)
Publicerad: November 1982

== Titel ==
Ett Ethernet-adressupplösningsprotokoll
-- eller --
Konvertering av nätverksprotokolladresser till 48-bitars Ethernet-adresser för överföring på Ethernet-hårdvara.

== Sammanfattning ==
När implementationen av protokoll **P** på en avsändande värd **S** bestämmer sig, genom **P**:s routningsmekanism, för att skicka data till en målvärd **T** som är ansluten till samma Ethernet-kabel, behöver en 48-bitars Ethernet-adress genereras. Adresser i protokoll **P** är inte alltid kompatibla med Ethernet-adresser (olika längder eller värden). Här presenteras ett protokoll som dynamiskt distribuerar information för att bygga tabeller som kan översätta en adress **A** i **P**:s adressrymd till en 48-bitars Ethernet-adress.

Generaliserade lösningar gör det möjligt att använda protokollet på annan hårdvara än 10Mbit Ethernet, till exempel vissa paketradiobaserade nätverk.

== Introduktion ==
Det föreslagna protokollet är resultatet av diskussioner med flera personer, bland andra J. Noel Chiappa, Yogen Dalal och James E. Kulp, samt värdefulla kommentarer från David Moon.

=== Noter ===
* Detta protokoll är designat för DEC/Intel/Xerox 10Mbit Ethernet men har generaliserats för att kunna användas på andra nätverkstyper.
* Adresser presenteras i Ethernet-standardens högsta byte först-format. Detta skiljer sig från exempelvis PDP-11 och VAX.
* En central auktoritet krävs för att hantera namnrymden för hårdvaruvärden. Fram tills en sådan existerar kan förfrågningar skickas till:
**David C. Plummer**
**Symbolics, Inc.**
**243 Vassar Street, Cambridge, Massachusetts 02139**
Alternativt via nätverkspost: **DCP@MIT-MC**.

== Problemet ==
Nätverksarkitekturer är komplexa och innehåller många protokoll på olika lager. Till exempel:
* För fjärrinloggning finns TELNET och SUPDUP.
* På transportlager finns CHAOS, TCP, Xerox PUP eller DECnet.

Ethernet möjliggör samexistens mellan dessa protokoll genom att använda ett typfält i Ethernet-pakets huvuden. Ethernet kräver dock 48-bitars adresser på det fysiska lagret, vilket inte nödvändigtvis matchar protokolladressernas längd eller struktur. Ett protokoll behövs för att översätta mellan protokoll- och Ethernet-adresser dynamiskt.

== Motivation ==
10Mbit Ethernet används allt mer eftersom flera tillverkare nu erbjuder gränssnitt enligt standarden från DEC, Intel och Xerox. En standard för adressupplösning är därför önskvärd för att säkerställa interoperabilitet och underlätta implementation.

== Definitioner ==
* **ether_type$XEROX_PUP:** Protokolltyp för Xerox PUP.
* **ether_type$DOD_INTERNET:** Protokolltyp för Internet.
* **ether_type$CHAOS:** Protokolltyp för CHAOS.
* **ether_type$ADDRESS_RESOLUTION:** Protokolltyp för adressupplösning.
* **ares_op$REQUEST:** Begäran om adressupplösning (värde = 1).
* **ares_op$REPLY:** Svar på adressupplösning (värde = 2).
* **ares_hrd$Ethernet:** Ethernet-hårdvara (värde = 1).

== Paketformat ==
För att kommunicera mappningar från <protokolltyp, protokolladress> till 48-bitars Ethernet-adresser används ett specifikt paketformat:
* **Hårdvarutyp (ar$hrd):** Typ av nätverkshårdvara (t.ex. Ethernet).
* **Protokolltyp (ar$pro):** Typ av nätverksprotokoll (t.ex. IP).
* **Hårdvarulängd (ar$hln):** Antal byte i en hårdvaruadress.
* **Protokollängd (ar$pln):** Antal byte i en protokolladress.
* **Operation (ar$op):** Typ av operation (förfrågan eller svar).
* **Avsändarens hårdvaruadress (ar$sha):** Ethernet-adressen för avsändaren.
* **Avsändarens protokolladress (ar$spa):** Protokolladressen för avsändaren.
* **Mottagarens hårdvaruadress (ar$tha):** Ethernet-adressen för mottagaren (om känd).
* **Mottagarens protokolladress (ar$tpa):** Protokolladressen för mottagaren.

== Protokollfunktioner ==
### Generering av ARP-förfrågningar
När en värd behöver skicka data men saknar en känd Ethernet-adress för mottagaren:
1. Ett ARP-förfrågningspaket skapas och fylls med känd information (avsändarens adresser, mottagarens protokolladress).
2. Paketet sänds som en broadcast på Ethernet-nätverket.

### Mottagning av ARP-paket
När en värd tar emot ett ARP-paket:
1. Värden kontrollerar om den känner igen hårdvaru- och protokolltypen.
2. Om paketet är en begäran och värden är målet, skickas ett svarspaket med sin Ethernet-adress till avsändaren.

### Exempel
Maskiner **X** och **Y** på samma nätverk:
1. **X** skickar en ARP-förfrågan för att få **Y**:s Ethernet-adress.
2. **Y** svarar med sin Ethernet-adress och sparar **X**:s adress i sin ARP-tabell.
3. **X** mottar svaret och kan nu kommunicera med **Y**.

== Begränsningar ==
Protokollet stöder endast en adressförfrågan per paket. Tidsgränser och rensning av inaktuella ARP-tabellposter hanteras inte av protokollet utan lämnas till implementationen.

== Relaterade frågor ==
Adressupplösning kan påverkas av nätverksfel eller om en värd byter Ethernet-adress. Mekanismer som tidsgränser eller ARP-daemoner kan användas för att hantera detta.

== Referenser ==
* RFC 826
* DEC/Intel/Xerox Ethernet-standard

== Källa ==
Detta dokument är en översättning av RFC 826 och tillhandahålls i MediaWiki-format för att underlätta användning och redigering.