Limity czasu ARP. Dlaczego naprawiono okresowy?

Question

Ten od wielu lat mnie dręczy.

Podstawowe pytanie: Czy jest jakiś powód, dla którego ARP ma być z ustalonymi limitami czasu na wpisy pamięci podręcznej ARP?

Wykonuję dużo pracy w czasie rzeczywistym. Obecnie wykonujemy większość naszych komunikatów między systemami na dedykowanych łączach UDP/IP. To w przeważającej mierze działa niezawodnie w czasie rzeczywistym, ale na jeden punkt: limity czasu wejścia ARP.

Sposób typowe implementacje zrobić ARP jest następujący:

• Gdy klient prosi, aby wysłać pakiet IP do adresu IP z nieznanego adresu MAC, zamiast wysyłać że pakiet IP, stos wysyła Żądanie ARP. Jeśli górna warstwa (TCP) ponownie wysyła, nie ma problemu. Ale ponieważ używamy UDP, oryginalna wiadomość jest tracona. W momencie uruchomienia jest to OK, ale w środku działania jest to Zła rzecz ™.
• (Dynamiczny) Pozycje tablicy ARP są okresowo usuwane z tabeli ARP, nawet jeśli właśnie otrzymaliśmy pakiet z tego systemu milisekundę temu. Oznacza to, że model Bad Thing ™ dzieje się regularnie w naszym systemie.

Oczywistym rozwiązaniem (którego używamy religijnie) jest sprawienie, by wszystkie wpisy ARP były statyczne. Jest to jednak królewska PITA (szczególnie w systemach RTOS, gdzie znalezienie adresu MAC interfejsu nie zawsze jest kwestią kilku prostych kliknięć GUI).

Kiedy napisaliśmy własny stos IP, rozwiązałem ten problem, nigdy (nigdy) nie przerywając wpisów w tablicy ARP. Ma to oczywiste wady. Bardziej niezawodnym i całkowicie rozsądnym rozwiązaniem może być odświeżenie limitu czasu wejścia, gdy tylko pojawi się pakiet z tego samego zestawu MAC/IP. W ten sposób wejście uzyskałoby tylko limit czasu, gdyby nie komunikowało się ze stackiem w tym czasie.

Ale teraz używamy stosu IP naszego dostawcy i wracamy do głupich limitów czasu ARP. Mamy wystarczająco dużo dźwigni w stosunku do tego dostawcy, że mógłbym skłonić ich do zastosowania mniej uciążliwego schematu. Jednak uniwersalność tego algorytmu limitu czasu martwego w mózgu prowadzi mnie do przekonania, że ​​może to być wymagana część implementacji.

To jest pytanie. Czy to zachowanie jest jakoś wymagane?

Answer 1

RFC1122 Requirements for Internet Hosts omawia to.

 2.3.2.1 ARP Cache Validation 

     An implementation of the Address Resolution Protocol (ARP) 
     [LINK:2] MUST provide a mechanism to flush out-of-date cache 
     entries. If this mechanism involves a timeout, it SHOULD be 
     possible to configure the timeout value. 

     ... 

     DISCUSSION: 
      The ARP specification [LINK:2] suggests but does not 
      require a timeout mechanism to invalidate cache entries 
      when hosts change their Ethernet addresses. The 
      prevalence of proxy ARP (see Section 2.4 of [INTRO:2]) 
      has significantly increased the likelihood that cache 
      entries in hosts will become invalid, and therefore 
      some ARP-cache invalidation mechanism is now required 
      for hosts. Even in the absence of proxy ARP, a long- 
      period cache timeout is useful in order to 
      automatically correct any bad ARP data that might have 
      been cached. 

Sieci mogą być bardzo dynamiczne; Serwery DHCP mogą przypisać ten sam adres IP do różnych komputerów, gdy wygasną stare czasy dzierżawy (unieważniając bieżące dane ARP), mogą wystąpić konflikty IP, które nie zostaną zauważone, dopóki nie zostaną okresowo wysłane żądania ARP itp.

Udostępnia także mechanizm sprawdzania, czy host nadal znajduje się w sieci. Wyobraź sobie, że przesyłasz wideo przez UDP do pewnego adresu IP 192.168.0.5. Jeśli na zawsze buforujesz adres MAC tego komputera, będziesz nadal spamował pakiety UDP, nawet jeśli host przestanie działać. Wykonywanie żądania ARP co jakiś czas spowoduje zatrzymanie strumienia z powodu nieosiągalnego błędu miejsca docelowego, ponieważ nikt nie odpowiedział adresem MAC dla tego adresu IP.

Answer 2

Powstał z braku zaufania do protokołów routingu, szczególnie w świecie innym niż Ethernet (w szczególności sieci CHAOS MIT). Chris Moon, jeden z wczesnych "ARPAnautów", był o tym konkretnie cytowany w oryginalnym ARP RFC.

Możesz, oczywiście, utrzymywać pamięć podręczną ARP innych użytkowników z wyprzedzeniem, aktywnie wysyłając własne ogłoszenia ARP. Większość warstw Ethernetu akceptuje nieodpłatne odpowiedzi ARP w swoich pamięciach podręcznych bez prób korelowania ich z wcześniej wysłanymi żądaniami ARP.