[🌐CN] Internet Protocol(1) - ARP

Posted Sep 1, 2025 Updated Sep 1, 2025

By xmoonanx

18 min read

🌐 Internet Protocol 전공 수업 정리

네트워크 통신의 핵심! IP 주소만으로는 데이터를 전송할 수 없다. 실제 물리적 네트워크에서 통신하려면 MAC 주소가 필요한데, 바로 이 IP와 MAC 주소 사이를 연결해주는 것이 ARP 프로토콜이다.

ARP (Address Resolution Protocol)

📚ARP (Address Resolution Protocol): IP 주소를 MAC 주소로 변환하는 프로토콜

Link-layer 프로토콜 (RFC 826)
IP connectivity를 부트스트랩하기 위해 필수적
Internet은 IP 주소 기반, 데이터 링크 프로토콜(Ethernet, FDDI, ATM)은 다른 MAC 주소 사용
ARP와 RARP 프로토콜이 IP 주소와 MAC 레이어 주소 간의 변환 수행

Network Layer에서의 ARP 위치

┌─────────────────────────────┐
│   Transport Layer           │
│   TCP          UDP          │
└─────────────────────────────┘
           ↕
┌─────────────────────────────┐
│   Network Layer             │
│   IP    ICMP    IGMP        │
└─────────────────────────────┘
           ↕
┌─────────────────────────────┐
│   Link Layer                │
│   ARP  Network Access  RARP │
└─────────────────────────────┘
           ↕
         Media

Why MAC address?

Ethernet, WiFi는 공유형 데이터링크
- 여러 컴퓨터/호스트가 하나의 네트워크에 연결됨
- 공유형 매체에 연결된 여러 인터페이스 중 어느 것이 frame을 수신해야 하나?
- → MAC address로 구분!
IP의 한계
- IP는 다음 hop의 IP를 알아도 MAC 주소는 모름
- 물리 계층에서 실제 통신하려면 MAC 주소 필요
- ARP 프로토콜은 공유 매체형 링크에 연결된 모든 컴퓨터(혹은 인터페이스)에 구현되어 있음

주소 변환의 방향
IP address (32 bit) → Ethernet MAC address (48 bit): ARP
Ethernet MAC address (48 bit) → IP address (32 bit): RARP

ARP 동작 원리

기본 동작: Request & Reply

Step 1: ARP Request (Broadcast)

송신자가 네트워크의 모든 스테이션에 ARP request 브로드캐스트
질문: “Who has IP address X.X.X.X?”
예시: “What is the MAC address of 128.143.137.1?”

Step 2: ARP Reply (Unicast)

해당 IP 주소를 가진 호스트만 ARP Reply로 응답
자신의 하드웨어 주소 포함
예시: “The MAC address of 128.143.137.1 is 00:e0:f9:23:a8:20”

ARP Request/Reply 예시

Alice의 ARP Request:

Source hardware address:  00:a0:24:71:e4:44
Source protocol address:  128.143.137.144
Target hardware address:  00:00:00:00:00:00  ← 모르니까 빈 값!
Target protocol address:  128.143.137.1

Router137의 ARP Reply:

Source hardware address:  00:e0:f9:23:a8:20  ← 답변!
Source protocol address:  128.143.137.1
Target hardware address:  00:a0:24:71:e4:44
Target protocol address:  128.143.137.144

ARP Cache

📚ARP Cache: IP datagram마다 ARP request/reply를 보내는 것은 비효율적! 호스트는 한 번 학습한 정보를 캐시에 저장하여 재사용

특징

⏰ 캐시 수명: 엔트리는 20분 (1200초) 후 만료
캐시 조회 명령
- Linux: arp 또는 arp -a
- Windows: arp -a

ARP Cache 예시

Linux 시스템:

  
$ arp -a
(128.143.71.37) at 00:10:4B:C5:D1:15 [ether] on eth0
(128.143.71.36) at 00:B0:D0:E1:17:D5 [ether] on eth0
(128.143.71.35) at 00:B0:D0:DE:70:E6 [ether] on eth0
(128.143.136.90) at 00:05:3C:06:27:35 [ether] on eth1

Windows 시스템:

  
c:\> arp -a
Interface: 10.0.0.56 --- 0x2
  Internet Address     Physical Address      Type
  10.0.0.1            00-0d-66-4f-60-00     dynamic
  10.0.0.4            00-0a-95-87-38-6a     dynamic

Address Resolution 과정

패킷 전송 시
- ARP 테이블 조회하여 목적지 IP → 목적지 MAC 매핑
- 데이터 패킷 캡슐화 및 전송
IP 주소가 테이블에 없는 경우
- 송신자 브로드캐스트: “Who has IP address 1.2.3.156?”
- 수신자 응답: “MAC address 58-23-D7-FA-20-B0”
- 송신자가 결과를 ARP 테이블에 캐시

효율성의 비결: 한 번 학습한 MAC 주소는 20분간 재사용하므로, 매번 브로드캐스트할 필요가 없다!

ARP Packet Format

Ethernet Frame 구조

┌────────────┬────────────┬──────┬─────────────────┬─────────┬─────┐
│Destination │  Source    │ Type │  ARP Request    │ Padding │ CRC │
│ address(6) │ address(6) │(0x80)│  or Reply (28)  │  (18)   │ (4) │
└────────────┴────────────┴──────┴─────────────────┴─────────┴─────┘

ARP Packet 필드 상세

필드	크기	설명	예시 값
Hardware type	2 bytes	하드웨어 타입	Ethernet = 1
Protocol type	2 bytes	프로토콜 타입	IP = 0x0800
Hardware address length	1 byte	하드웨어 주소 길이	6 (MAC)
Protocol address length	1 byte	프로토콜 주소 길이	4 (IPv4)
Operation code	2 bytes	요청(1) 또는 응답(2)	1 or 2
Source hardware address	Variable	송신자 MAC 주소	00:a0:24:71:e4:44
Source protocol address	Variable	송신자 IP 주소	128.143.137.144
Target hardware address	Variable	대상 MAC 주소	00:00:00:00:00:00
Target protocol address	Variable	대상 IP 주소	128.143.137.1

실전 시나리오: Host A → Host B 패킷 전송

네트워크 구성

LAN 1 (111.111.111.0/24)          LAN 2 (222.222.222.0/24)
┌─────────────┐                   ┌─────────────┐
│   Host A    │                   │   Host B    │
│111.111.111  │                   │222.222.222  │
│    .111     │    ┌──────┐       │    .222     │
│74-29-9C-E8  │────│Router│───────│49-BD-D2-C7  │
│   -FF-55    │    │  R   │       │   -56-2A    │
└─────────────┘    └──────┘       └─────────────┘
              111.111.111.110  222.222.222.220
              E6-E9-00-17-BB  1A-23-F9-CD-06
                  -4B              -95

전송 과정 4단계

Step 1: Host A의 결정

B로 보낼 IP 패킷 생성
- Source: 111.111.111.111
- Destination: 222.222.222.222
B가 다른 네트워크(222.222.222.0/24)에 있으므로 게이트웨이 라우터 R 사용
R의 주소(111.111.111.110)는 DHCP를 통해 학습

Step 2: Host A가 R의 MAC 주소 학습

ARP request: "Who has 111.111.111.110?" (Broadcast)
ARP response: "00:e0:f9:23:a8:20입니다!" (Router R의 응답)
Host A가 패킷을 Ethernet Frame에 캡슐화하여 R로 전송

Step 3: Router R의 포워딩 결정

R의 어댑터가 패킷 수신
Ethernet 프레임에서 IP 패킷 추출
목적지 222.222.222.222 확인
포워딩 테이블 조회: “222.222.222.0/24는 다른 인터페이스로!”

Step 4: Router R이 B에게 전송

ARP request: "Who has 222.222.222.222?" (Broadcast)
ARP response: "49-BD-D2-C7-56-2A입니다!" (Host B의 응답)
R이 패킷을 캡슐화하여 B로 전송 완료!

ARP의 특수 기능들

1. Gratuitous ARP (G-ARP)

📚Gratuitous ARP: 호스트가 자신의 IP 주소에 대한 ARP request를 스스로 발송

특징
- 동일한 IP 주소로 ARP request 발송
- 일반적으로 본인 외에는 아무도 응답하지 않음
주요 목적
목적 1: 하드웨어 주소 변경 알림
- 하드웨어 주소 변경 시 네트워크의 다른 호스트들에게 알림
- 다른 호스트들의 캐시 엔트리 자동 업데이트
- RFC에 명시되어 있지만, 모든 ARP 캐시 구현이 이를 따르지는 않음
목적 2: DAD (Duplicate Address Detection) - 중복 주소 검출
- 다른 호스트가 동일한 IP 주소로 구성되었는지 확인
- 응답이 오면 → IP 충돌! (중복 IP 주소의 MAC 주소 확인 가능)
- IP 충돌 감지 및 사용자에게 경고

2. Address Conflict Detection (ACD)

📚ACD: DAD를 위해 개선된 G-ARP 방식, 보안을 강화하기 위해 G-ARP를 2단계 프로세스로 분리

기존 G-ARP의 문제점:

공격자 A가 실수(또는 의도적으로) G-ARP (IP_C, MAC_A) 전송
     ↓
네트워크의 모든 호스트들이 캐시 업데이트: "IP_C는 MAC_A다!"
     ↓
실제 C로 가는 트래픽이 모두 A로 hijacking! (ARP Poisoning)

✅ ACD 동작 방식:

Phase 1: ARP Probe 단계

ARP Probe Packet:
  Src_ip: 0.0.0.0           ← 핵심! 자신의 IP가 아닌 0.0.0.0
  Src_mac: [자신의 MAC]
  Target_ip: [할당받을 IP]
  Target_mac: 00:00:00:00:00:00

Cache에 매칭되는 entry가 없으므로 poisoning 발생하지 않음 (harmless)
응답이 있으면 → IP 주소 충돌! (ACD 검출)
응답이 없으면 → 다음 단계로 진행 ✅

Phase 2: ARP Announcement 단계

ARP Announcement Packet:
  Src_ip: [할당받은 IP]     ← 이제 정상적인 IP 사용
  Src_mac: [자신의 MAC]
  Target_ip: [할당받은 IP]
  Target_mac: 00:00:00:00:00:00

할당받은 IP 사용 가능!
네트워크의 다른 호스트들이 캐시 업데이트

ACD의 핵심: Source IP를 0.0.0.0으로 설정함으로써, 캐시 오염 없이 안전하게 IP 중복을 검사할 수 있다!

3. Proxy ARP

📚Proxy ARP: 라우터나 호스트가 다른 네트워크에 연결된 호스트를 대신해서 ARP 응답

사용 시나리오 1: 서브넷 간 통신

Alice (128.143.137.144/16)  →  Router137  →  Bob (128.143.71.21/24)

Alice: "Who has 128.143.71.21?"
         ↓
Router137: "나(00:e0:f9:23:a8:20)한테 보내!" (Proxy 응답)
         ↓
Alice → Router137 → Bob (실제 전달은 Router가 중계)

사용 시나리오 2: Mobile IP

Home Network                Foreign Network
┌──────────────┐            ┌──────────────┐
│  Home Agent  │            │ Mobile Node A│
│  (Proxy ARP) │ ←─────────→│ (IP 유지)    │
└──────────────┘            └──────────────┘
      ↑
      │ "A의 IP로 온 패킷을
      │  Foreign Network로!"

Mobile node A가 IP를 유지한 채 다른 network로 이동
Home agent가 node A를 대리하며 relay
Foreign network에서도 같은 IP로 통신 가능

4. Directed ARP

📚Directed ARP: ARP request를 unicast로 요청하여 특정 호스트의 ARP 캐시 엔트리를 갱신

목적: 수명이 다한 (1200초/20분) ARP cache entry 업데이트
방식: Broadcast 대신 특정 MAC 주소로 직접 ARP request 전송
장점: 네트워크 브로드캐스트 트래픽 감소

Wireshark 캡처 예시:

Ethernet II, Src: Dongwon_82:0d:aa, Dst: 72:f0:ec:4b:d8:70
Address Resolution Protocol (request)
  Hardware type: Ethernet (1)
  Protocol type: IPv4 (0x0800)
  Sender MAC: Dongwon_82:0d:aa (00:07:89:82:0d:aa)
  Sender IP: 172.30.1.254
  Target MAC: 00:00:00:00:00:00  ← Unicast이지만 MAC은 모름
  Target IP: 172.30.1.13

ARP Cache Update 정책

Cache Update 시나리오

상황: A가 B로부터 ARP request를 받은 경우

✅ Case 1: ARP request가 A의 MAC 주소를 요구하는 경우

A는 request의 source MAC-IP (B)를 cache에 저장
A는 자신의 MAC-IP를 가지고 response 전송
B는 response의 source MAC-IP (A)를 cache에 저장
→ 정상적인 ARP 동작!

✅ Case 2: ARP request가 C의 MAC 주소를 요구하는 경우

A의 cache에 B의 MAC-IP가 이미 있는 경우:
- cache의 정보 = 수신한 B의 MAC-IP → OK, 그대로 유지 * cache의 정보 ≠ 수신한 B의 MAC-IP → ARP poisoning 의심!
A의 cache에 B의 MAC-IP가 없는 경우:
- 새로운 엔트리로 추가하지 않음 (보안상 이유)
- 요청받은 것도 아닌데 저장하면 poisoning 공격에 취약!

Cache Update 보안 개선

구분	과거 방식	현재 방식 (ACD)
방법	announcement만 사용	Probe + Announcement
보안	❌ Poisoning 공격에 취약	✅ Source IP 0.0.0.0 사용으로 안전
단계	1단계	2단계 (검증 후 알림)

ARP 보안 취약점 분석

주요 취약점 3가지

❌ 취약점 1: 인증 없음

ARP는 request나 reply를 인증하지 않음
누구든지 ARP Request와 Reply를 위조 가능
신뢰할 수 있는 검증 메커니즘 부재

❌ 취약점 2: Stateless 프로토콜

ARP Reply는 대응하는 ARP Request 없이도 전송 가능
누군가 물어보지 않았는데도 답변할 수 있음
Unsolicited ARP Reply 공격 가능

❌ 취약점 3: 무조건적 캐시 업데이트

ARP 패킷(Request 또는 Reply) 수신 시
수신 노드는 이미 해당 IP 주소에 대한 엔트리가 있으면
source 필드의 정보로 로컬 ARP 캐시를 반드시 업데이트
검증 없이 맹목적으로 신뢰하는 구조

ARP Poisoning / Spoofing 공격

📚ARP Poisoning: 공격자가 의도적으로 잘못된 ARP 정보를 전송하여 다른 호스트의 ARP 캐시를 오염시키는 공격

공격 시나리오:

정상 네트워크: A --- B --- C --- D (Ethernet)

공격자 A의 행동:
  1. G-ARP (IP_C, MAC_A) 전송  ← "IP_C는 나(A)한테 보내!"
  2. B, D는 캐시 업데이트: IP_C → MAC_A
  3. B, D가 C에게 보내는 모든 frame이 A로 전달됨!

공격 결과:

피해자 C는 일부 트래픽만 수신 → 느린 인터넷 체감
공격자 A는 C로 가는 트래픽 도청 가능
MITM (Man-in-the-Middle) 공격의 기반

방어 방법:

라우터가 주기적(~10초)으로 ARP request 반복 → A, C 모두 응답
응답에 randomness 발생 → 트래픽 분산
❌ 하지만 완벽한 방어는 어려움
✅ 근본적 해결: Static ARP 테이블, ARP 모니터링 도구, Network Access Control

ARP Poisoning의 심각성: ARP는 인증 메커니즘이 없어 본질적으로 취약하다. 보안이 중요한 환경에서는 반드시 추가 보안 계층(802.1X, Static ARP, IDS/IPS)이 필요하다!

ARP 특수 상황 처리

존재하지 않는 호스트에 대한 ARP

동작: 여러 ARP request를 점점 증가하는 시간 간격으로 전송
결과: 결국 ARP가 포기함 (give up) → “No route to host” 에러

실제 예시:

  
Linux% date ; telnet 10.0.0.99 ; date
Fri Jan 29 14:46:33 PST 2010
Trying 10.0.0.99...
telnet: connect to address 10.0.0.99: No route to host
Fri Jan 29 14:46:36 PST 2010    ← 3초 후 포기

Linux% arp -a
? (10.0.0.99) at <incomplete> on eth0  ← 응답 없음

tcpdump 캡처:

21:12:07.440845  arp who-has 10.0.0.99 tell 10.0.0.56
21:12:08.436842  arp who-has 10.0.0.99 tell 10.0.0.56  ← 1초 후 재시도
21:12:09.436836  arp who-has 10.0.0.99 tell 10.0.0.56  ← 1초 후 재시도
   → 3번 시도 후 포기

ARP Cache 갱신 (Linux)

Linux의 적극적 갱신 전략
- 호스트가 주기적으로 ARP Cache에 나열된 모든 주소에 대해 ARP Request 전송
- ✅장점: ARP cache 내용 최신 상태 유지
- ❌단점: 네트워크 브로드캐스트 트래픽 증가

CS, Internet Protocol

This post is licensed under CC BY 4.0 by the author.