Prawidłowo wskazany zakres 172.16.4.1 ÷ 172.16.4.254 wynika bezpośrednio z maski /24. Notacja CIDR „/24” oznacza, że 24 bity przeznaczone są na część sieciową, a 8 bitów na część hosta. Dla adresu 172.16.4.0/24 maska to 255.255.255.0, więc wszystkie adresy od 172.16.4.0 do 172.16.4.255 należą do jednej tej samej sieci logicznej. W tej puli dwa adresy są zarezerwowane: pierwszy (172.16.4.0) to adres sieci, a ostatni (172.16.4.255) to adres rozgłoszeniowy (broadcast). Z tego powodu realne adresy, które można przypisać hostom (komputerom, drukarkom, routerom na interfejsach itp.) mieszczą się w zakresie od 172.16.4.1 do 172.16.4.254. To jest klasyczna reguła: w każdej podsieci zgodnej z IPv4 nie używamy adresu z samymi zerami w części hosta (adres sieci) i z samymi jedynkami w części hosta (broadcast). W praktyce, gdy konfigurujesz serwer DHCP w małej sieci biurowej, właśnie taki zakres wpisujesz jako „scope” – np. 172.16.4.10–172.16.4.200, ale zawsze w ramach całego dostępnego przedziału 172.16.4.1–172.16.4.254. Moim zdaniem warto od razu przyzwyczaić się do liczenia tego „z głowy”: przy /24 od razu wiesz, że masz 256 adresów w podsieci, z czego 254 dla hostów. To jest standardowa, podręcznikowa sytuacja, często spotykana w małych sieciach LAN, konfiguracjach routerów SOHO czy prostych projektach sieci szkolnych. W większych środowiskach, przy projektowaniu adresacji według dobrych praktyk (np. VLSM, podział na VLAN-y), ta sama zasada nadal obowiązuje – zawsze pierwszy adres to sieć, ostatni to broadcast, a hosty mieszczą się pomiędzy nimi.
Adresacja IPv4 w notacji z maską, takiej jak 172.16.4.0/24, opiera się na bardzo konkretnej zasadzie: w każdej podsieci istnieje adres sieci i adres rozgłoszeniowy, których nie wolno używać jako adresów hostów. To jest zapisane w standardowym sposobie interpretowania masek i nie jest tylko „umową”, którą można zignorować. W tym przykładzie maska /24 oznacza, że pierwsze 24 bity to część sieciowa, a pozostałe 8 bitów to część hosta. Daje to łącznie 2^8 = 256 adresów w podsieci. Z mojego doświadczenia typowy błąd polega na tym, że ktoś patrzy tylko na zakres liczbowy od .0 do .255 i zakłada, że wszystkie te adresy da się przydzielić urządzeniom. To prowadzi do błędnego wniosku, że hostem może być np. 172.16.4.0 lub 172.16.4.255. Tymczasem 172.16.4.0 to adres identyfikujący samą sieć 172.16.4.0/24, używany w konfiguracjach routerów, tablicach routingu czy dokumentacji. Z kolei 172.16.4.255 to adres rozgłoszeniowy, na który wysyłane są pakiety broadcast w obrębie tej jednej podsieci, np. zapytania ARP czy różne protokoły usługowe. Gdyby taki adres przypisać hostowi, ruch broadcastowy zacząłby się zachowywać nieprzewidywalnie. Innym typowym nieporozumieniem jest mylenie „zakresu sieci” z „zakresem hostów”. Cała sieć obejmuje rzeczywiście adresy od 172.16.4.0 do 172.16.4.255, ale to nie oznacza, że każdy z nich może być wykorzystany przez komputer. Dobre praktyki sieciowe, stosowane w realnych firmowych sieciach, mówią jasno: zakres hostów zaczyna się od pierwszego adresu po adresie sieci i kończy na ostatnim adresie przed broadcastem. W tym przypadku jest to 172.16.4.1–172.16.4.254. Warto też uważać na odpowiedzi, które „uczynnie” obcinają tylko część z końca lub z początku zakresu, ale nie biorą pod uwagę obu zarezerwowanych adresów. Jeśli w przyszłości będziesz projektować bardziej złożone podsieci (np. /25, /26), dokładnie ta sama logika dalej obowiązuje: zawsze pierwszy adres w podsieci to sieć, ostatni to broadcast, a hosty są pomiędzy nimi.