ARP·RARP·ICMP의 역할

ARP는 IPv4의 다음 홉 주소를 같은 링크의 MAC 주소로 해석한다. 주소 임대인 DHCP, 초기 장치의 역주소 요청인 RARP, 오류·진단 메시지인 ICMP와 역할을 구분한다. 아래 ARP 예는 Ethernet을 전제로 한다.

1. ARP 요청과 응답

ARP Request: “이 IPv4 주소를 누가 사용하고 있는가?”

호스트 A의 ARP 캐시에 192.0.2.20의 MAC 주소가 없다면 ARP Request를 보낸다.

개념적으로 다음과 같은 질문이다.

송신자: 192.0.2.10 / 02:00:5e:10:00:0a
질문  : 192.0.2.20을 사용하는 장치의 MAC 주소는 무엇인가?

요청 시점에는 상대방의 MAC 주소를 모르므로 Ethernet 목적지 주소를 브로드캐스트인 다음 값으로 보낸다.

FF:FF:FF:FF:FF:FF

같은 브로드캐스트 도메인의 장치들이 요청을 받지만, 요청된 IPv4 주소를 가진 장치가 응답한다.

ARP Reply: “내 MAC 주소는 이것이다”

192.0.2.20을 사용하는 호스트 B가 자신의 MAC 주소를 알고 있다면 A에게 ARP Reply를 보낸다.

예를 들어 B의 MAC 주소가 02:00:5e:10:00:14라면 다음 매핑이 얻어진다.

192.0.2.20 → 02:00:5e:10:00:14

일반적인 요청-응답 흐름에서는 ARP Request가 브로드캐스트되고 ARP Reply는 요청자에게 유니캐스트된다.

호스트 A는 이 매핑을 ARP 캐시에 저장한 뒤 실제 IP 패킷을 Ethernet 프레임에 넣어 전송할 수 있다.

Ethernet 목적지 MAC: 02:00:5e:10:00:14
IP 목적지 주소      : 192.0.2.20

MAC 주소와 IP 주소는 서로 대체되는 값이 아니다. 하나의 프레임 안에서 링크 계층 주소와 네트워크 계층 주소가 각각 다른 역할을 한다.

2. ARP는 ‘최종 목적지 IP의 MAC’을 무조건 찾는 프로토콜이 아니다

시험에서 자주 틀리는 지점이다.

호스트 A가 이번에는 198.51.100.20으로 통신한다고 하자.

호스트 A: 192.0.2.10/24
목적지  : 198.51.100.20
게이트웨이: 192.0.2.1

198.51.100.20은 192.0.2.0/24 밖에 있으므로 같은 링크의 직접 목적지가 아니다. A는 라우팅 판단을 통해 기본 게이트웨이 192.0.2.1을 다음 홉으로 선택한다.

따라서 A가 ARP로 물어보는 주소는 다음과 같다.

틀린 생각: “198.51.100.20의 MAC 주소는?”
올바른 생각: “다음 홉 192.0.2.1의 MAC 주소는?”

게이트웨이의 MAC 주소를 02:00:5e:10:00:01이라고 하면 A가 전송하는 첫 Ethernet 프레임은 다음 관계를 가진다.

Ethernet 목적지 MAC = 02:00:5e:10:00:01   ← 게이트웨이
IP 목적지 주소       = 198.51.100.20        ← 최종 목적지

라우터가 패킷을 다음 네트워크로 전달할 때는 그 링크에서 사용할 새로운 링크 계층 프레임을 만든다. 따라서 IP의 최종 목적지와 현재 프레임의 목적지 MAC은 서로 다른 장치를 가리킬 수 있다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

3. Gratuitous ARP는 별도의 새로운 프로토콜이 아니다

Gratuitous ARP(GARP)라는 표현은 일반적으로 어떤 장치가 요청을 받기 전에 자신의 IPv4/MAC 매핑을 로컬 링크에 알리는 형태의 ARP 사용을 가리킨다.

대표적인 목적은 다음과 같다.

• 새로 사용하려는 IPv4 주소가 이미 사용 중인지 충돌 여부를 확인하는 데 도움을 준다.
• 자신의 주소 사용 시작을 네트워크에 알린다.
• 다른 장치에 남아 있는 오래된 ARP 캐시 정보를 갱신하는 데 도움을 준다.
• 장애 조치나 MAC 변경 뒤 새로운 매핑을 빠르게 알리는 운영에 활용될 수 있다.

다만 주소 충돌 감지 절차에서는 ARP Probe와 ARP Announcement를 구분할 수 있다. 단순히 “GARP는 무조건 ARP Reply를 브로드캐스트하는 것”처럼 패킷 한 형태로 고정해 외우면 정확하지 않다.

4. RARP는 ARP의 단순한 ‘검색 방향 반대 명령’이 아니다

RARP는 Reverse Address Resolution Protocol이다. 초기의 디스크리스 워크스테이션처럼 부팅 시 자신의 하드웨어 주소는 알지만 IPv4 주소는 모르는 장치를 위해 설계되었다.

동작 관계는 다음과 같다.

ARP  : 알고 있는 IPv4 주소 → 해당 장치의 하드웨어 주소를 찾음
RARP : 알고 있는 하드웨어 주소 → 자신에게 사용할 프로토콜 주소를 서버에 요청

RARP Request를 보내는 클라이언트는 자신의 하드웨어 주소를 알고 있으며, RARP 서버는 하드웨어 주소와 프로토콜 주소의 대응 정보를 관리한다.

RARP의 대표 Operation 값은 다음과 같다.

RARP Request = 3
RARP Reply   = 4

ARP와 RARP 비교

RARP는 링크 계층에 의존하고 제공할 수 있는 구성 정보가 제한적이다. 이후 BOOTP가 하드웨어 주소를 바탕으로 IP 주소뿐 아니라 부팅에 필요한 추가 정보를 전달할 수 있도록 설계되었고, DHCP는 BOOTP를 기반으로 주소 임대와 다양한 네트워크 설정 전달 기능을 확장했다. 따라서 현대 일반 IP 네트워크에서 호스트 자동 설정은 DHCP를 중심으로 이해하고, RARP는 역할과 방향성을 구분해야 하는 레거시 기술로 이해하면 된다.

5. ICMPv4는 IP의 오류·상태를 알려주는 제어 메시지다

IPv4는 패킷 전달 자체를 수행하지만, 패킷이 목적지에 도달하지 못했거나 TTL이 만료되었거나 잘못된 헤더가 발견되는 등의 상황을 원래 송신자에게 알려줄 수단도 필요하다. 이때 사용하는 것이 ICMPv4다.

ICMP는 TCP나 UDP처럼 응용 프로그램 간 데이터를 전달하기 위한 일반 전송 계층 프로토콜이 아니다. IPv4 패킷의 Protocol 필드 값 1로 직접 식별된다.

따라서 ICMP 자체를 다음처럼 생각하면 안 된다.

틀림: ICMP도 TCP/UDP처럼 포트 번호를 가진다.

ICMP 메시지에는 TCP/UDP 포트 대신 일반적으로 다음과 같은 핵심 정보가 있다.

Type | Code | Checksum | 메시지 유형별 추가 필드/데이터

• Type: 큰 메시지 종류를 구분한다.
• Code: 같은 Type 안에서 세부 원인을 구분한다.
• Checksum: ICMP 메시지의 오류 검출에 사용한다.

6. 시험에서 우선 알아둘 ICMPv4 메시지

Destination Unreachable(Type 3)

Type 3은 하나의 원인만 의미하지 않는다. Code가 세부 이유를 나타낸다.

대표적인 예시는 다음과 같다.

• Code 0: Network Unreachable
• Code 1: Host Unreachable
• Code 3: Port Unreachable
• Code 4: Fragmentation Needed and DF Set

따라서 “ICMP Type 3 = 호스트가 꺼져 있다”처럼 하나의 원인으로 단정하면 안 된다.

Time Exceeded(Type 11)

IPv4 라우터는 패킷을 전달하면서 TTL을 감소시킨다. 전달 과정에서 TTL이 0이 되면 패킷은 폐기되고, 일반적인 유니캐스트 패킷의 경우 송신자에게 ICMP Time Exceeded(Type 11, Code 0)가 돌아올 수 있다.

이 동작이 traceroute 계열 도구가 중간 라우터를 발견하는 핵심 원리다.

Source Quench(Type 4)는 현재 사용 기술처럼 외우면 안 된다

과거 ICMP에는 네트워크 혼잡을 알리기 위한 Source Quench(Type 4)가 정의되어 있었다. 그러나 현재 표준에서는 Source Quench의 생성과 이에 대한 반응이 폐지(deprecated)되었다.

따라서 오래된 표에 Type 4가 존재하더라도 다음처럼 구분한다.

역사적 정의: ICMP Source Quench Type 4
현재 판단   : 혼잡 제어 수단으로 사용하지 않음 / 폐지된 메시지