RFC 826

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

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

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

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