Dlaczego transmisja jest używana na etapie DHCPREQUEST?

To jest proces DHCPdziałania,

Moje pytanie jest na trzecim etapie, dlaczego klient wysyła transmisję rozgłoszeniową, a nie emisję pojedynczą, ponieważ po dwóch poprzednich operacjach adres serwera DHCP / serwera przekaźnikowego powinien być znany?

dhcp

— Mahomet
źródło

Czy jakaś odpowiedź ci pomogła? Jeśli tak, powinieneś zaakceptować odpowiedź, aby pytanie nie wyskakiwało wiecznie, szukając odpowiedzi. Alternatywnie możesz podać i zaakceptować własną odpowiedź.

— Ron Maupin

Odpowiedzi:

https://tools.ietf.org/html/rfc2131#page-13

Serwery odbierają transmisję DHCPREQUEST od klienta. Te serwery, które nie zostały wybrane w komunikacie DHCPREQUEST, wykorzystują ten komunikat jako powiadomienie, że klient odrzucił ofertę tego serwera.

Protokół zakłada, że może istnieć wiele serwerów DHCP. Nadając komunikat z żądaniem, wszystkie serwery, które mogły wydać ofertę, mogą być świadome wyboru klienta.

— boomi
źródło

Możesz potencjalnie mieć wiele serwerów DHCP - żądanie jest wysyłane w formie rozgłaszania, aby powiadomić inne serwery DHCP, które potencjalnie wysłały oferty, że ich oferta nie została przyjęta.

— Zac67
źródło

Ponieważ dopóki serwer nie wyśle DHCPACK, klient nadal nie ma adresu IP. Serwer DHCP może odpowiedzieć na żądanie za pomocą DHCPNACK.

— YLearn
źródło

Dlaczego miałoby to sugerować, że rozgłaszanie musiałoby być użyte? Klient zna adres MAC serwera z komunikatu DHCPOFFER, aby mógł wysłać unicast DHCPREQUEST na ten serwer - nie ma potrzeby, aby tak się stało.

— psmears

@psmears, ponieważ transmisje L3 są wysyłane jako transmisje L2. DHCP nie jest protokołem L2, więc jesteś związany zasadami, ponieważ dane są przekazywane z L3 do L2.

— YLearn

@YLearn: Potrzebujesz także źródłowego i docelowego adresu IP dla pakietu multiemisji lub emisji L3, więc to oczywiście nie jest problem :) Nie ma teoretycznego powodu, dla którego pakiet DHCPREQUEST nie mógł zostać wysłany z docelowym adresem IP i MAC serwer i (jak w pakiecie rozgłoszeniowym) źródłowy adres IP 0.0.0.0. Powodem emisji jest powiadomienie innych serwerów DHCP (jeśli istnieją), że klient odrzuca ich oferty.

— psmears,

@psmears, miejscem docelowym transmisji L3 jest 255.255.255.255. Możesz zdobyć transmisję L3 od 0.0.0.0. Nie można jednak pobrać emisji pojedynczej L3 z wersji 0.0.0.0.

— YLearn

@YLearn: Z pewnością możesz wysłać pakiet z bajtami dla adresu źródłowego ustawionego na zero! Może to być zabronione przez niektóre RFC - czy znasz jedno? RFC1700 mówi, że 0.0.0.0 „może być używany tylko jako adres źródłowy” (ale nic o emisji pojedynczej / emisji); RFC1122 mówi 0.0.0.0 „NIE MOŻE być wysyłany, z wyjątkiem adresu źródłowego w ramach procedury inicjalizacji, dzięki której host uczy się własnego adresu IP” (ponownie, bez ograniczeń uni / broadcast). Czy jest to wymagane gdzie indziej?

— psmears,