IP·ICMP·ARP·DHCP 차이: 패킷 전송에서 각 프로토콜의 역할

IP, ICMP, ARP, DHCP는 모두 네트워크 연결 과정에서 보이지만 해결하는 문제가 다르다. 층 이름만 외우면 ARP가 왜 게이트웨이 주소를 찾는지, ping이 되지 않아도 서비스가 동작할 수 있는지 설명하기 어렵다.

한 장치가 네트워크 설정을 받고 다른 네트워크의 서버로 패킷을 보내는 흐름에 놓으면 역할이 분명해진다.

먼저 역할을 한 표로 구분한다

프로토콜	해결하는 문제	범위와 특징
IP	주소 지정과 네트워크 간 전달	best-effort datagram 전달, 신뢰성 보장 없음
ICMP	IP 처리 중 제어·오류·진단 정보 전달	echo는 여러 ICMP 메시지 중 하나
ARP	같은 링크에서 IPv4 next hop의 IP를 MAC 주소로 해석	브로드캐스트 도메인 안에서 동작
RARP	자신의 MAC 주소로 IPv4 주소 요청	역사적 프로토콜, BOOTP·DHCP 이전 방식
DHCP	IP 주소와 네트워크 옵션을 동적으로 임대	IPv4에서는 UDP 기반 애플리케이션 프로토콜

OSI 계층 번호에 억지로 맞추기보다 실제 패킷 처리 경로를 보는 편이 낫다. 특히 ARP는 IPv4와 link-layer 주소 사이를 잇기 때문에 교재와 도구에 따라 표현하는 계층이 다를 수 있다.

IP는 목적지까지 보낼 주소와 경로를 제공한다

IP는 출발지와 목적지 주소를 담은 datagram을 네트워크 사이에서 전달한다. 라우터는 라우팅 테이블을 보고 다음 hop을 선택한다.

IP 자체는 패킷이 반드시 도착하거나 순서대로 도착한다고 보장하지 않는다. 중복, 손실, 순서 변경이 생길 수 있다. 필요한 신뢰성과 순서 제어는 TCP 같은 상위 프로토콜이나 애플리케이션이 담당한다.

목적지 IP가 같은 서브넷인지 아닌지도 중요하다. 같은 링크면 목적지 장치로 직접 보내고, 다른 네트워크면 기본 게이트웨이를 next hop으로 선택한다.

ARP는 원격 서버가 아니라 다음 hop의 MAC 주소를 찾는다

Ethernet frame을 보내려면 같은 링크에 있는 next hop의 MAC 주소가 필요하다. IPv4 환경에서 ARP가 IP 주소를 link-layer 주소로 해석한다.

같은 서브넷의 서버로 전송
내 장치 → ARP로 서버 MAC 확인 → 서버로 frame 전송

다른 서브넷의 서버로 전송
내 장치 → ARP로 기본 게이트웨이 MAC 확인 → 게이트웨이로 frame 전송

두 번째 경우 ARP로 원격 서버의 MAC 주소를 찾지 않는다. 라우터를 지날 때마다 frame의 link-layer 주소는 해당 링크의 next hop에 맞게 바뀌지만, 일반적인 전달 중 IP 목적지 주소는 최종 서버를 가리킨다.

ARP 요청은 로컬 링크의 브로드캐스트로 보내고 응답을 캐시에 보관한다. 그래서 ARP는 라우터를 넘어 인터넷 전체의 주소를 찾는 프로토콜이 아니다.

IPv6는 ARP를 사용하지 않는다. ICMPv6 기반의 Neighbor Discovery가 이웃 주소 해석과 router discovery 등의 역할을 맡는다.

ICMP는 IP를 신뢰성 있는 프로토콜로 바꾸지 않는다

ICMP는 IP 패킷 처리 과정의 오류와 제어 정보를 전달한다. 대표적으로 다음 메시지가 있다.

• 목적지에 도달할 수 없음을 알리는 destination unreachable
• hop limit 또는 TTL이 소진됐음을 알리는 time exceeded
• 경로 진단 등에 쓰이는 echo request와 echo reply

ping은 echo request/reply를 사용하는 도구다. 하지만 ICMP 전체가 ping인 것은 아니고, 모든 패킷 손실이 ICMP 오류로 돌아오는 것도 아니다. 방화벽이나 장비 정책이 echo만 차단할 수도 있으므로 ping 실패만으로 서버와 모든 통신이 불가능하다고 결론 내릴 수 없다.

ICMP는 오류 상황을 알리는 데 도움을 주지만 손실된 데이터를 재전송하거나 전달 순서를 복구하지 않는다. IP를 신뢰성 있는 전송으로 바꾸는 프로토콜은 아니다.

DHCP는 주소뿐 아니라 네트워크 설정을 임대한다

IPv4 DHCP 클라이언트는 초기에는 자신의 주소와 DHCP 서버 위치를 모를 수 있다. 그래서 broadcast를 활용해 서버를 찾고, 서버가 제안한 설정을 요청해 임대를 받는다. 일반적으로 다음 네 메시지를 DORA라고 묶어 설명한다.

DHCPDISCOVER → DHCPOFFER → DHCPREQUEST → DHCPACK

서버는 IP 주소뿐 아니라 subnet mask, 기본 router, DNS 서버, 임대 시간 같은 option을 함께 전달할 수 있다. DHCPv4는 UDP를 사용하고, 클라이언트와 서버가 다른 서브넷에 있다면 라우터의 DHCP relay가 메시지를 전달할 수 있다.

RARP는 디스크 없이 부팅하는 장치가 자신의 하드웨어 주소를 바탕으로 IP 주소를 얻기 위해 만든 초기 방식이었다. 하지만 제한된 정보와 로컬 링크 범위 때문에 BOOTP가 등장했고, DHCP는 BOOTP의 형식과 relay 모델을 바탕으로 동적 임대와 다양한 옵션을 확장했다. 따라서 단순히 “RARP가 바로 DHCP로 교체됐다”기보다 RARP → BOOTP → DHCP로 요구가 확장됐다고 이해하는 편이 정확하다.

IPv6의 주소 설정은 별도 체계다. Router Advertisement를 이용한 SLAAC와 DHCPv6를 상황에 따라 사용하며, IPv4 DHCP 과정을 그대로 대입하지 않는다.

실제 전송 흐름에 연결해 본다

노트북이 Wi-Fi에 연결한 뒤 다른 네트워크의 웹 서버에 접속하는 예를 보자.

1. DHCP로 IPv4 주소, subnet mask, 기본 gateway와 DNS 서버 정보를 받는다.
2. DNS로 도메인의 IP 주소를 조회한다.
3. routing table을 보고 목적지가 다른 서브넷임을 판단한다.
4. ARP로 기본 gateway의 MAC 주소를 확인한다.
5. 목적지 IP는 웹 서버, frame의 목적지 MAC은 gateway로 두고 전송한다.
6. 각 router가 IP 패킷을 다음 hop으로 전달한다.
7. 중간에 전달할 수 없거나 TTL이 소진되면 ICMP 오류가 돌아올 수 있다.

문제를 진단할 때도 이 순서를 거꾸로 확인하면 된다. IP 설정과 route, ARP 또는 neighbor cache, DNS 응답, TCP/TLS/HTTP 순으로 범위를 좁힌다. DNS 경로는 재귀·반복 DNS resolver의 차이에서, 명령어를 이용한 점검 흐름은 Linux 네트워크 트러블슈팅에서 이어서 볼 수 있다.

참고 자료

• RFC 792: Internet Control Message Protocol
• RFC 826: An Ethernet Address Resolution Protocol
• RFC 903: A Reverse Address Resolution Protocol
• RFC 951: Bootstrap Protocol
• RFC 2131: Dynamic Host Configuration Protocol
• RFC 4861: Neighbor Discovery for IP version 6
• RFC 8200: Internet Protocol, Version 6 Specification