네트워크 계층 프로토콜

네트워크 계층(3계층)은 여러 네트워크를 거쳐 패킷을 목적지 호스트까지 보내는 일을 한다. 핵심인 IP는 "최선을 다해 전달하지만 보장은 하지 않는" 프로토콜이고, 주변 프로토콜들이 주소 변환·오류 보고·경로 선택을 돕는다.

IP (Internet Protocol)

• 출발지·목적지 IP 주소를 지정하고 최적 경로로 패킷을 전달한다.
• 비신뢰성·비연결성: 도착·순서를 보장하지 않는다. 신뢰성은 상위 계층(TCP)이 맡는다.
• 서로 다른 LAN을 연결하려면 라우터가 필요하다.

IPv4 헤더

옵션이 없으면 20바이트이고, 옵션(최대 40바이트)이 붙으면 최대 60바이트(IHL 15)까지 늘어난다. 이더넷 프레임에서는 Ethernet Type 0x0800이 "페이로드는 IPv4"라는 표시다.

단편화(Fragmentation)와 MTU

링크마다 한 번에 실을 수 있는 최대 크기 MTU(Maximum Transmission Unit)가 있다. 이더넷은 보통 1500바이트다. 패킷이 다음 링크의 MTU보다 크면 IPv4는 패킷을 조각으로 나눈다.

예: 데이터 3,980바이트(헤더 포함 4,000바이트)를 MTU 1500 링크로 보낼 때. 조각마다 20바이트 헤더가 붙으므로 데이터는 1,480바이트(8의 배수)씩 실린다.

• 세 조각은 같은 Identification 값을 가진다. 재조립은 최종 목적지 호스트만 한다. 조각마다 다른 경로로 올 수 있으므로 중간 라우터는 조각을 합치지 않는다. 헤더는 조각마다 복사되고 Flags·Offset·Total Length·Checksum만 바뀐다.
• 조각 하나는 헤더만 보고 위치를 안다. MF = 1, Offset = 0이면 첫 조각, MF = 0, Offset ≠ 0이면 마지막 조각이다. 예를 들어 Offset 100, IHL 5, Total Length 100인 조각은 헤더 20바이트 + 데이터 80바이트이고, 원래 데이터의 800번(100 × 8)부터 879번 바이트를 담는다.
• 조각 하나만 잃어도 데이터그램 전체를 버린다. 목적지는 재조립 타이머 안에 조각이 다 오지 않으면 모은 조각을 모두 버리고 ICMP Time Exceeded(Code 1)를 보낸다. 그래서 단편화는 성능과 신뢰성 모두에 불리하다.
• 그래서 보통 DF를 켜고 경로 MTU 탐색(PMTUD)을 한다. DF가 켜진 패킷이 MTU를 넘으면 라우터가 버리고 ICMP "Fragmentation Needed"(Type 3, Code 4)로 허용 크기를 알려 준다. 송신 측은 그 크기에 맞춰 다시 보낸다. TCP는 연결 수립 때 MSS(최대 세그먼트 크기)를 맞춰 애초에 단편화가 일어나지 않게 한다.
• IPv6에서는 라우터가 단편화하지 않는다. 출발지 호스트만 단편화 확장 헤더로 나눌 수 있고, 너무 큰 패킷에는 라우터가 ICMPv6 "Packet Too Big"을 돌려보낸다.

IP 주소와 PC의 네트워크 설정

PC의 네트워크 설정에는 보통 세 값이 들어간다.

• Classful 주소: A·B·C 클래스처럼 정해진 크기로 네트워크를 나눠 쓰는 방식. 대역이 경직되어 IP 주소가 낭비·부족해지는 문제가 있었다. 첫 옥텟의 앞 비트로 클래스를 정했다.

  클래스	첫 비트	범위	기본 마스크	블록(네트워크) 수	네트워크당 호스트
  A	0	0.0.0.0 ~ 127.255.255.255	/8	2⁷ = 128	2²⁴ − 2 (약 1,677만)
  B	10	128.0.0.0 ~ 191.255.255.255	/16	2¹⁴ = 16,384	2¹⁶ − 2 (65,534)
  C	110	192.0.0.0 ~ 223.255.255.255	/24	2²¹ = 약 210만	2⁸ − 2 (254)
  D	1110	224.0.0.0 ~ 239.255.255.255	-	-	멀티캐스트
  E	1111	240.0.0.0 ~ 255.255.255.255	-	-	예약(연구용)

  클래스 방식은 주소를 netid(기관에 배정) → hostid(기관이 호스트에 배정) 두 단계로 나눴다. CIDR에서는 같은 역할을 접두사(prefix)와 접미사(suffix)가 맡고, 주소만 보고는 접두사 길이를 알 수 없어 /n을 반드시 함께 적는다.

  C 클래스 하나(254개)는 회사에 모자라고 B 클래스 하나(65,534개)는 너무 커서 낭비가 심했다. 1993년 CIDR 도입 뒤로 클래스는 주소를 읽는 관용 표현으로만 남았다.

• Classless 주소: 서브넷 마스크로 네트워크 부분과 호스트 부분을 자유롭게 나눈다(CIDR). 받은 대역을 팀별 크기에 맞게 더 잘게 나누는 것이 서브네팅이다. 예를 들어 /24 하나를 /25 두 개(각 126대)로 쪼갤 수 있다. 쪼갤수록 서브넷마다 네트워크·브로드캐스트 주소 2개와 게이트웨이 주소 1개를 빼야 하므로, 호스트 3대짜리 망이라도 주소는 최소 6개(/29) 필요하다.

• 공인 IP와 사설 IP: 인터넷에서는 공인 IP로만 통신하고, 외부에서는 내부의 사설 IP 대역이 보이지 않는다. 공인 IP 하나 뒤에 여러 사설 IP 기기를 둘 수 있게 해 주는 것이 아래의 NAT다.

서브넷 계산

IP 주소와 서브넷 마스크를 비트 AND 하면 네트워크 주소가 나온다. 네트워크 주소가 같은 두 호스트는 같은 네트워크라 라우터 없이 직접 통신하고, 다르면 게이트웨이로 보내야 한다. 마스크는 앞에서부터 연속한 1의 개수로 줄여 쓴다(CIDR 표기, /24 = 255.255.255.0).

마스크를 쓰는 방식은 세 가지이고 뜻은 같다.

마스크의 1은 앞에서부터 끊김 없이 이어져야 한다. 255.0.255.0(11111111.00000000.11111111.00000000)처럼 1과 0이 섞인 마스크는 옛 RFC 950이 금지하지는 않았지만, CIDR(RFC 4632)이 접두사 길이로만 대역을 표현하면서 쓸 수 없게 됐다. 최장 프리픽스 일치, 경로 요약(aggregation) 같은 라우팅 동작이 모두 「앞 n비트」를 전제로 하므로, 지금의 OS와 장비는 이런 마스크를 설정 단계에서 거부한다. 방화벽 ACL의 와일드카드 마스크(0.0.0.255, 1이 「무시할 비트」)는 서브넷 마스크가 아니라 별개의 표기다.

블록 안의 주소 하나와 접두사 길이 n만 알면 블록 전체를 구할 수 있다.

주소 개수   = 2^(32 − n)
첫 주소     = 주소 AND 마스크            (네트워크 주소)
마지막 주소 = 주소 OR (NOT 마스크)       (브로드캐스트 주소)

경계가 마지막 옥텟이 아니어도 계산은 같다. 110.23.120.14/20은 마스크 255.255.240.0, 주소 4,096개이고, 셋째 옥텟 120을 16 단위로 내리면 112이므로 블록은 110.23.112.0 ~ 110.23.127.255다.

• 네트워크 주소와 브로드캐스트 주소는 장비에 줄 수 없다. 그래서 /30은 2개, /24는 254개만 쓸 수 있다. 예외로 점대점 링크에는 둘 다 버리지 않는 /31을 쓸 수 있다(RFC 3021).
• 라우터의 인터페이스마다 서로 겹치지 않는 네트워크를 줘야 한다. 같은 대역을 두 인터페이스에 주면 어느 쪽으로 보낼지 정할 수 없다.

크기가 다른 서브넷으로 나누기(VLSM)

블록을 나눌 때 지킬 조건은 두 가지다. 블록 크기는 2의 거듭제곱이고, 시작 주소는 블록 크기의 배수여야 한다. 그래서 필요한 주소 수를 2의 거듭제곱으로 올리고, 큰 서브넷부터 앞에서 차례로 배정한다. 접두사 길이는 원래 n + log₂(원래 크기 ÷ 서브넷 크기)다.

예: 10.20.30.0/24(256개)를 호스트 100대, 50대, 12대짜리 서브넷으로 나눈다.

작은 것부터 배정하면 .0/28 다음 64개짜리 블록이 64의 배수에서 시작해야 해서 중간에 빈 구멍이 생긴다. 큰 것부터 배정하는 이유다.

경로 요약(슈퍼네팅)

서브네팅의 반대로, 이어진 작은 블록 여러 개를 큰 블록 하나로 묶어 라우팅 테이블 항목을 줄이는 것이 경로 요약(route aggregation, 슈퍼네팅)이다. 묶으려면 블록 수가 2의 거듭제곱이고, 첫 블록이 묶은 크기의 경계에서 시작하며, 그 범위의 블록이 모두 있어야 한다.

특수 주소

라우팅 테이블

호스트와 라우터는 모두 [목적지 네트워크] → [다음 홉 또는 인터페이스] 규칙의 목록을 갖는다.

• 목적지가 여러 규칙에 걸리면 프리픽스가 가장 긴(가장 구체적인) 규칙을 고른다(최장 프리픽스 일치, longest prefix match). /28 규칙은 /0 기본 경로보다 우선한다.
• 같은 프리픽스를 여러 출처에서 배웠으면 출처의 신뢰도인 관리 거리(administrative distance)가 작은 쪽을 고른다. Cisco 기준으로 직접 연결 0, 정적 경로 1, eBGP 20, OSPF 110, RIP 120이다. 출처까지 같으면 그 라우팅 프로토콜의 메트릭(홉 수, 대역폭, 지연을 반영한 비용)이 작은 경로를 쓰고, 메트릭도 같으면 여러 경로로 나눠 보낸다(ECMP).
• 규칙은 범위로 나뉜다. 네트워크 하나를 가리키는 네트워크 경로가 기본이고, 특정 호스트 하나만 다른 길로 보내는 호스트 경로(/32)는 시험·관리용으로 쓴다. 나머지를 모두 받는 것이 기본 경로(0.0.0.0/0)다. 다음 홉만 적고 전체 경로는 적지 않으므로 테이블이 작다.
• 어느 규칙에도 맞지 않고 기본 경로도 없으면 패킷을 버리고 ICMP "Destination Unreachable"을 돌려보낸다.
• 통신은 양방향이다. 가는 길뿐 아니라 돌아오는 경로도 상대 쪽 라우팅 테이블에 있어야 응답이 온다.
• 리눅스에서는 ip route로 확인한다(리눅스 네트워크 네임스페이스와 ip 명령).

테이블을 찾은 결과는 둘 중 하나다. 목적지가 내 인터페이스와 같은 네트워크면 직접 전달(direct delivery)로 목적지 IP의 MAC을 ARP로 찾아 바로 보낸다. 다르면 간접 전달(indirect delivery)로 다음 홉 라우터 IP의 MAC을 찾아 넘긴다. 경로의 마지막 라우터만 직접 전달을 한다.

예: 라우터의 테이블이 다음과 같을 때.

목적지 주소를 테이블에서 찾는 대신, 미리 경로를 정해 두고 패킷에 붙인 짧은 레이블로 교환 테이블을 바로 찾는 레이블 기반 포워딩도 있다(MPLS).

라우팅과 포워딩

라우팅 프로토콜이 배운 경로를 모은 것이 RIB(Routing Information Base)이고, 그중 실제로 쓸 최선 경로만 뽑아 빨리 찾도록 다시 담은 것이 FIB(Forwarding Information Base)다. FIB 항목은 목적지 프리픽스 → 다음 홉 IP, 출력 인터페이스이고, 다음 홉의 MAC 주소를 담은 인접 테이블(ARP 결과)과 짝을 이룬다. 장비는 최장 프리픽스 일치를 빠르게 하려고 트라이(trie) 구조나 TCAM(모든 항목을 한 번에 비교하는 메모리)을 쓴다.

라우터 한 대가 패킷 하나를 포워딩하는 과정은 다음과 같다.

flowchart TB
  s1["1. 입력 포트: 프레임 수신 → FCS 검사<br/>목적지 MAC이 내 인터페이스면 이더넷 헤더를 벗긴다"] --> s2["2. IP 헤더 검사: 버전·헤더 체크섬 확인"]
  s2 -->|"목적지가 라우터 자신"| up["위 계층으로 올린다"]
  s2 --> s3["3. TTL을 1 줄인다"]
  s3 -->|"0이면"| drop1["버리고 ICMP Time Exceeded를 출발지에 보낸다"]
  s3 --> s4["4. 헤더 체크섬을 다시 계산한다<br/>(TTL이 바뀌었으므로)"]
  s4 --> s5["5. FIB에서 목적지 IP로 최장 프리픽스 일치<br/>→ 다음 홉과 출력 인터페이스 결정"]
  s5 -->|"없으면"| unr["ICMP Destination Unreachable"]
  s5 --> s6["6. 출력 링크 MTU보다 크면 단편화"]
  s6 -->|"DF가 켜졌으면"| drop2["버리고 ICMP로 알린다"]
  s6 --> s7["7. ARP 캐시에서 다음 홉의 MAC을 찾아 새 이더넷 헤더를 씌운다<br/>(출발지 MAC = 출력 인터페이스)"]
  s7 --> s8["8. 출력 큐에 넣는다"]
  s8 -->|"큐가 넘치면"| drop3["버린다(혼잡 손실)"]

IP 주소는 끝까지 그대로이고 MAC 주소만 홉마다 바뀐다(네트워크 기초의 「홉마다 바뀌는 MAC, 그대로인 IP」).

주소 변환: ARP와 RARP

ARP가 필요한 이유와 동작 과정

IP 패킷도 실제로 링크를 건너려면 이더넷 프레임에 담겨야 하고, 프레임에는 목적지 MAC 주소가 있어야 한다. 보내는 쪽은 상대의 IP만 알기 때문에 ARP로 MAC 주소를 알아낸다.

flowchart TB
  s1{"1. 목적지 IP가 같은 네트워크인지<br/>서브넷 마스크로 판단"}
  s1 -->|"같은 네트워크"| same["목적지 IP의 MAC을 찾는다"]
  s1 -->|"다른 네트워크"| gw["기본 게이트웨이 IP의 MAC을 찾는다"]
  same --> s2{"2. ARP 캐시에 있나"}
  gw --> s2
  s2 -->|"있으면"| use["바로 사용"]
  s2 -->|"없으면"| s3["3. ARP 요청을 브로드캐스트<br/>프레임 목적지 FF:FF:FF:FF:FF:FF<br/>#quot;192.168.0.10 가진 사람 MAC 알려 줘#quot;"]
  s3 --> s4["4. 해당 IP를 가진 호스트만 ARP 응답을 유니캐스트로 회신<br/>(요청자의 IP·MAC도 자기 캐시에 기록)"]
  s4 --> s5["5. 요청자는 결과를 ARP 캐시에 저장하고 프레임을 보낸다"]

다른 네트워크로 가는 패킷에서 ARP로 찾는 것은 최종 목적지가 아니라 다음 홉(게이트웨이)의 MAC이다. 라우터도 같다. 다음 홉이 또 다른 라우터면 그 라우터 IP를, 목적지가 붙은 마지막 네트워크면 목적지 IP를 ARP로 묻는다. 그래서 IP 주소는 끝까지 같고 MAC 주소는 홉마다 바뀐다(네트워크 기초).

ARP 패킷 구조

이더넷 프레임의 Ethernet Type 0x0806이 ARP라는 표시다. ARP는 IP 헤더 없이 이더넷 프레임에 바로 실린다.

자기 IP를 대상으로 스스로 보내는 Gratuitous ARP는 IP 충돌을 확인하거나, 주소가 바뀐 사실을 이웃의 캐시에 미리 알릴 때 쓴다.

ARP 캐시(테이블) 확인

arp -a              # ARP 캐시 보기 (Windows·macOS·Linux)
arp -d <IP>         # 항목 삭제
arp -s <IP> <MAC>   # 정적 항목 추가
ip neigh            # Linux의 현행 명령 (IPv6 이웃 탐색 결과도 함께 보인다)

캐시 항목은 동적 항목과 직접 넣은 정적 항목으로 나뉜다. 동적 항목은 일정 시간이 지나면 지워지고 다시 ARP 요청을 보낸다.

동적 항목은 상태를 가진다. 요청을 보내고 응답을 기다리는 동안(대기, Linux ip neigh의 INCOMPLETE)에는 그 주소로 보낼 IP 패킷을 큐에 쌓아 두고, 응답이 오면(확인, REACHABLE) 큐의 패킷을 MAC과 함께 한꺼번에 내려보낸다. 정해진 횟수만큼 다시 물어도 답이 없으면 항목과 큐를 버리고 상위에 도달 불가를 알린다. 확인된 항목도 시간이 지나면 STALE이 되어 다음에 쓸 때 다시 확인한다. IPv6에는 ARP가 없고 ICMPv6 기반 이웃 탐색(NDP)이 같은 일을 한다.

ARP는 요청하지 않은 응답도 받아들이기 때문에, 위조된 응답으로 캐시를 오염시키는 ARP 스푸핑(ARP Cache Poisoning) 공격에 취약하다. 스푸핑·스니핑 같은 공격 기법은 정보 시스템 보안에 정리했다.

주소 할당: DHCP

IP 주소를 주는 방법은 관리자가 직접 넣는 정적 할당과 서버가 자동으로 나눠 주는 동적 할당이 있다. 서버·라우터처럼 주소가 바뀌면 안 되는 장비는 정적으로, 수가 많고 주소가 바뀌어도 되는 PC·휴대폰은 DHCP(Dynamic Host Configuration Protocol)로 받는다. 가정용 공유기에는 DHCP 서버가 들어 있다.

DHCP는 UDP 위에서 도는 응용 계층(7계층) 프로토콜이다. 하는 일이 IP 주소 설정이라 3계층으로 착각하기 쉽지만, 메시지는 UDP 데이터그램에 실려 오간다. UDP를 쓰는 이유는 다음과 같다.

• 주소를 받기 전의 클라이언트는 자기 IP도, 서버의 IP도 모른다. 출발지 0.0.0.0, 목적지 255.255.255.255로 브로드캐스트해야 하는데, TCP는 상대 하나와 연결을 맺어야 해서 브로드캐스트를 할 수 없다.
• 요청·응답이 몇 개의 짧은 메시지라 연결 수립 비용이 아깝다. 손실은 클라이언트가 타임아웃 뒤 다시 보내는 것으로 충분하다.

주소 말고도 여러 설정을 옵션으로 함께 내려준다.

주소는 영구히 주지 않고 임대(lease) 기간을 붙여 빌려준다. 할당은 네 단계(DORA)다. UDP 위에서 클라이언트는 68번, 서버는 67번 포트를 쓴다.

sequenceDiagram
    participant C as 클라이언트 (아직 IP 없음)
    participant S as DHCP 서버
    C->>S: DHCPDISCOVER (브로드캐스트) "DHCP 서버 있나요?"
    S->>C: DHCPOFFER "192.168.0.23 어때요?"
    C->>S: DHCPREQUEST (브로드캐스트) "그 주소 쓸게요"
    Note over C,S: 다른 서버의 제안은 거절된다
    S->>C: DHCPACK "확정. 임대 기간은 N시간"

DISCOVER는 브로드캐스트라 라우터를 넘지 못한다. 서버가 다른 네트워크에 있으면 라우터가 DHCP 릴레이로 요청을 전달한다.

임대 기간은 표준이 정한 값이 없고 서버 관리자가 정한다. 기기가 자주 바뀌는 카페·공항 Wi-Fi는 수십 분몇 시간으로 짧게 잡아 주소를 빨리 회수하고, 사무실·가정처럼 기기가 고정된 망은 하루며칠로 길게 잡아 갱신 트래픽을 줄인다. Windows Server DHCP의 기본값은 8일이고, 가정용 공유기는 보통 하루 안팎이다.

공유기의 「고정 IP 할당」은 DHCP 예약(reservation)이다. 프로토콜은 그대로 DHCP지만, 서버가 특정 MAC 주소(또는 클라이언트 식별자)에는 늘 같은 주소를 주도록 표에 묶어 둔다. 기기는 평소처럼 DORA로 주소를 받으므로 기기 쪽 설정은 바꿀 필요가 없다. 이와 별개로 ISP가 공유기에 주는 공인 IP는 대개 유동이라, 바깥에서 집에 접속하려면 고정 IP 상품이나 DDNS(주소가 바뀔 때마다 도메인의 A 레코드를 갱신)를 쓴다. 휴대폰·노트북은 기본 설정으로 Wi-Fi마다 무작위 MAC을 쓰는 경우가 많으므로, 예약을 걸려면 그 네트워크에서 무작위화를 끈다.

ICMP

ICMP는 IP의 비신뢰성을 보완해 오류·제어 메시지를 원래 패킷의 출발지에 보고한다. 오류를 고치지는 않고 알리기만 하며, 고치는 일은 상위 계층에 맡긴다. ICMP 메시지는 IP 패킷의 페이로드에 실린다(Protocol = 1). 헤더는 Type, Code, Checksum으로 시작하고, Type이 큰 분류, Code가 세부 이유다.

• 오류 메시지의 데이터 부분에는 문제를 일으킨 패킷의 IP 헤더와 페이로드 앞 8바이트 이상을 담는다. 8바이트면 TCP·UDP의 포트 번호가 들어 있어, 출발지가 어느 연결·소켓의 패킷인지 알아낸다.
• 오류가 오류를 낳아 망이 넘치지 않도록, 다음 패킷에는 ICMP 오류를 만들지 않는다: ICMP 오류 메시지를 실은 패킷, 첫 조각이 아닌 조각, 멀티캐스트·브로드캐스트 목적지 패킷, 출발지가 127.0.0.0/8·0.0.0.0 같은 특수 주소인 패킷.
• 라우터가 모든 문제를 발견하지는 못한다. ICMP 오류가 오지 않았다고 전달에 성공했다는 뜻은 아니다.

ICMP로 동작하는 두 도구는 다음과 같다.

• 유닉스 계열 traceroute는 기본으로 높은 번호의 UDP 포트로 보내고, 목적지에 닿으면 Port Unreachable(Type 3, Code 3)이 와서 끝을 안다. Windows tracert는 ICMP Echo를 쓴다.
• 방화벽이 ICMP를 막으면 ping이 실패해도 서비스는 정상일 수 있다. 응답이 없다는 것만으로 "죽었다"고 단정하지 않는다.

IPv6

IPv4(32비트, 8비트씩 4부분)의 주소 고갈 문제를 해결하려고 만든 128비트 주소 체계로, 16비트씩 8부분을 :으로 구분한다. IPv4 주소는 2011년 2월 IANA의 미할당 주소 풀이 바닥났고, 이후 지역 인터넷 레지스트리(RIR)들도 차례로 소진되었다. 그래서 IPv4는 NAT로 주소를 나눠 쓰고, IPv6 전환이 함께 진행된다. 구글 서비스에 IPv6로 접속하는 비율은 2025~2026년에 전 세계 50% 안팎에 이르렀지만 나라별 편차가 크다(프랑스·인도 70%대, 일부 유럽 국가 10%대). 최신 수치는 Google IPv6 통계에서 본다.

• IPsec(인증·기밀성·무결성)을 염두에 두고 설계되었다. 초기 표준(RFC 4294)은 모든 IPv6 노드에 IPsec 구현을 필수로 요구했지만, RFC 6434 이후로는 권장(SHOULD) 으로 완화되었다(현행 RFC 8504).
• Traffic Class, Flow Label 필드로 서비스 품질(QoS)을 다루기 쉽다.
• 주소 자동 설정(SLAAC)으로 DHCP 서버 없이도 같은 링크 안에서 스스로 주소를 만들어 통신한다(아래 「ICMPv6와 주소 자동 설정」).
• 모바일 IPv6(RFC 6275)는 단말이 다른 망으로 옮겨 가도 고정된 홈 주소를 유지하게 한다. 실제 휴대폰 망은 이 대신 이동통신 코어망이 단말 주소를 지켜 준다.
• 주소 종류

IPv4와 IPv6 비교

헤더를 고정 길이로 단순화하고 홉마다 하던 일(체크섬 재계산, 단편화)을 없앤 덕에 라우터의 패킷 처리가 빨라진다.

주소 표기와 종류

표기는 두 규칙으로 줄인다. 16비트 묶음마다 앞쪽 0을 생략하고(0db8 → db8), 0으로만 된 묶음이 이어지면 한 번만 ::로 접는다. 2001:0db8:0000:0000:0000:0000:0000:0010은 2001:db8::10이 된다. ::를 두 번 쓰면 각각 몇 묶음이 접혔는지 알 수 없어 금지다.

인터페이스 ID는 원래 48비트 MAC 가운데에 fffe를 끼워 64비트로 늘리는 EUI-64로 만들었다. 그러면 망을 옮겨도 주소 뒤 64비트가 같아 기기가 추적되므로, 지금 OS는 망마다 다른 무작위 ID(RFC 7217)와 주기적으로 바뀌는 임시 주소(RFC 8981)를 기본으로 쓴다.

확장 헤더와 Next Header

IPv4의 Protocol 필드 자리를 Next Header가 맡는다. 기본 헤더 뒤에 확장 헤더가 있으면 그 종류를, 없으면 상위 프로토콜을 가리키고, 확장 헤더도 각자 Next Header를 가져 사슬을 이룬다.

flowchart LR
  h0["기본 헤더<br>Next=44"] --> h1["단편 헤더<br>Next=6"] --> tcp["TCP 세그먼트"]

ICMPv6와 주소 자동 설정(SLAAC)

ICMPv6는 IPv4의 ICMP에 ARP와 IGMP의 일까지 흡수했다.

IPv6에는 브로드캐스트가 없다. 그래서 NS는 모든 호스트가 아니라 찾는 주소의 끝 24비트로 만든 요청 노드 멀티캐스트 주소로 보내고, 그 주소에 가입한 극소수 호스트만 처리한다.

DHCP 없이 주소를 정하는 SLAAC(Stateless Address Autoconfiguration)는 다음 순서다.

1. 인터페이스 ID를 만들고 fe80::/64와 합쳐 링크 로컬 주소를 만든다
2. 중복 주소 검사(DAD): 출발지 ::, 목적지 = 그 주소의 요청 노드 멀티캐스트로 NS를 보낸다
   NA 응답이 오면 이미 쓰는 주소이므로 쓰지 않는다. 응답이 없으면 그 주소를 쓴다
3. 링크 로컬 주소를 출발지로 RS를 ff02::2(모든 라우터)에 보낸다
4. RA로 받은 /64 접두사에 인터페이스 ID를 붙여 전역 주소를 만들고(다시 DAD), RA를 보낸 라우터를 기본 게이트웨이로 삼는다

DNS 서버는 RA의 RDNSS 옵션이나 DHCPv6로 받는다. 서버 주소를 중앙에서 관리해야 하는 망은 DHCPv6를 함께 쓴다.

전환 기술

두 프로토콜은 서로 직접 통신할 수 없어서, 공존을 위한 방법이 필요하다.

NAT (Network Address Translation)

사설 IP와 공인 IP를 서로 변환하는 기술. 라우터가 패킷의 출발지·목적지 IP 주소와 TCP/UDP 포트 번호를 바꿔 기록하면서 여러 내부 기기가 하나의 공인 IP를 공유할 수 있게 한다. 즉 "특정 IP·포트로 가는 패킷을 다른 IP·포트로 바꿔 주는 것"이다. P2P 통신(예: WebRTC)에서는 NAT 뒤의 기기끼리 직접 연결하기 어려워 별도의 우회 기법이 필요하다.

sequenceDiagram
    participant L as 노트북 192.168.0.10:51000
    participant N as 공유기(NAT)
    participant I as 인터넷(서버)
    L->>N: 요청
    N->>I: 출발지 203.0.113.7:40001
    Note over N: 변환표에 기록: 192.168.0.10:51000 ↔ 203.0.113.7:40001
    I->>N: 서버의 응답 (목적지 203.0.113.7:40001)
    N->>L: 공유기가 표를 보고 192.168.0.10:51000으로 되돌림

목적

1. 공인 IP 주소 절약: 한정된 IPv4 주소 문제 해결. NAT가 없었다면 IPv4 주소는 훨씬 일찍 바닥나 인터넷이 지금처럼 커지지 못했다
2. 주소 공유: 집·회사의 여러 기기가 공인 IP 하나를 함께 쓴다
3. 기본적인 방화벽 효과: 외부에서 내부 기기의 실제 주소가 보이지 않고, 안에서 시작하지 않은 연결은 들어오지 못한다
4. 관리 편의: 내부 주소 체계를 바깥과 무관하게 설계하고 바꿀 수 있다

예: AWS NAT Gateway

프라이빗 서브넷의 인스턴스는 VPC 밖 서비스에 연결할 수 있어야 하지만, 외부에서는 이 인스턴스에 직접 접속할 수 없어야 한다. NAT Gateway가 이를 처리한다.

• Public NAT Gateway: 퍼블릭 서브넷에 만들고 탄력적 IP(Elastic IP)를 연결한다. 인스턴스의 출발지 IP를 NAT Gateway의 IP로 바꿔 인터넷으로 내보낸다.
• Private NAT Gateway: 프라이빗 서브넷에 만들며 탄력적 IP를 붙일 수 없다. Transit Gateway나 가상 프라이빗 게이트웨이를 통해 다른 VPC·온프레미스로 트래픽을 라우팅한다.

NAT와 프록시 서버 비교

포트 포워딩

NAT를 응용한 기술로, 특정 IP·포트로 들어온 요청을 미리 정한 다른 IP·포트로 전달한다. 게이트웨이(외부망) 반대편 사설 네트워크에 있는 호스트의 서비스를 외부에 공개할 때 쓴다.

• [외부(호스트) 포트]:[내부 포트] 형식으로 표현한다.
• 예: docker run -p 8080:9090 ... → 호스트의 8080 포트로 들어오는 트래픽을 컨테이너의 9090 포트로 전달(VM과 컨테이너)
• 용도: 원격 데스크톱, 집 안 서버에 외부에서 접속하기 등 가정용 네트워크와 원격 기기를 직접 연결할 때

NAT의 종류

"NAT", "포트 포워딩", "IP 마스커레이드"는 섞어 쓰이지만 가리키는 범위가 다르다.

NAPT 표의 항목은 안에서 밖으로 나갈 때 생긴다. 그래서 밖에서 먼저 들어오는 연결은 받을 수 없다. 외부에 서비스를 열려면 포트 포워딩(DNAT 고정 규칙)을 추가한다. NAT는 IP 헤더와 체크섬을 고쳐 쓰므로, 패킷 본문에 IP 주소를 담는 프로토콜(FTP 액티브 모드, SIP)은 별도 처리(ALG)가 필요하다.

라우팅 프로토콜

라우터끼리 네트워크 상태 정보를 교환해 목적지까지의 경로를 정하는 프로토콜이다. 경로마다 드는 비용을 메트릭(metric)이라 하고, 라우팅은 메트릭의 합이 가장 작은 경로를 찾는 일이다.

• 정적 라우팅: 관리자가 경로를 직접 입력
• 동적 라우팅: 라우터 간 정보 교환으로 자동 결정. 망 모양이 바뀌면 테이블도 저절로 바뀐다
• 자율 시스템(AS): 한 기관이 관리하는 라우터·네트워크 묶음. AS 안의 경로는 IGP(RIP, OSPF), AS 사이의 경로는 EGP(BGP)가 정한다

동적 라우팅의 경로 계산 알고리즘은 누가 무엇을 아느냐로 갈린다.

무한 계수를 줄이는 장치는 세 가지다. 무한대를 작은 수(RIP은 16)로 정해 몇 번 만에 끝나게 하고, 스플릿 호라이즌(split horizon)으로 어떤 경로를 배운 인터페이스로는 그 경로를 다시 광고하지 않는다. 그런데 광고가 없으면 「안 알려 준 것」인지 「경로가 없는 것」인지 구분이 안 되므로, 포이즌 리버스(poison reverse)는 아예 거리를 무한대로 실어 되돌려 보내 그 경로를 쓰지 말라고 못 박는다.

다익스트라 알고리즘 자체는 다익스트라 최단 경로에 정리했다. 링크 상태 라우팅은 ① 라우터마다 자기 링크 상태를 담은 LSA를 만들고 ② 영역 전체에 범람시켜 모두가 같은 지도를 갖게 한 뒤 ③ 각자 자신을 뿌리로 최단 경로 트리를 계산해 ④ 그 트리로 테이블을 만든다. 지도는 같아도 뿌리가 다르므로 라우터마다 테이블은 다르다.

BGP: 인터넷을 잇는 신뢰 기반 프로토콜

자율 시스템(AS, Autonomous System) 은 한 조직이 관리하는 네트워크 묶음이다(통신사, 클라우드, 대형 서비스). 각 AS는 자기가 가진 IP 대역(prefix)을 이웃 AS에 광고(announce) 하고, 광고는 이웃을 타고 인터넷 전체로 퍼진다. 라우터는 받은 경로 중 정책과 AS 경로 길이로 최선 경로를 고른다.

문제는 광고를 기본적으로 믿는다는 점이다.

2021년 10월 Facebook(Meta) 장애는 세 번째에 가깝다. 백본 점검 명령이 데이터센터 사이 연결을 모두 끊었고, 백본이 끊긴 것을 감지한 DNS 서버들이 스스로 BGP 광고를 거두었다. 그 결과 Facebook의 DNS 서버에 아무도 닿지 못해 도메인 자체를 찾을 수 없게 되었고, 장애를 진단하는 사내 도구와 원격 접속 경로까지 같은 망에 의존해, 엔지니어가 데이터센터에 직접 가야 했다. 복구 경로가 장애 대상과 같은 의존성을 공유하면 안 된다는 사례다.

방어 수단은 다음과 같다.

• RPKI(ROV): 대역 소유자가 "이 대역은 이 AS만 광고할 수 있다"는 서명(ROA)을 등록하고, 라우터가 이를 검증해 맞지 않는 광고를 버린다. 주요 통신사·클라우드가 도입해 적용 범위가 넓어지고 있다.
• BGPsec·ASPA: 출발지뿐 아니라 경로 전체가 정당한지 검증하려는 확장이다. 아직 널리 쓰이지 않는다.
• 이웃 AS에서 받을 수 있는 대역을 필터로 제한하는 운영 관행(MANRS)도 함께 쓴다.

제어 평면과 데이터 평면, SDN

라우터·스위치의 일은 둘로 나뉜다.

전통적인 장비는 두 평면을 장비마다 함께 가지고 있어, 정책을 바꾸려면 장비를 하나씩 설정해야 한다. SDN(Software-Defined Networking) 은 제어 평면을 장비에서 떼어 소프트웨어 컨트롤러로 모으고, 장비는 데이터 평면만 맡게 한다.

flowchart TB
    app["응용: 자동화·모니터링·과금"]
    ctrl["SDN 컨트롤러<br/>네트워크 전체를 한곳에서 프로그래밍"]
    app ---|"Northbound API (REST 등)"| ctrl
    subgraph dp["데이터 평면만"]
        sw1["스위치"]
        sw2["스위치"]
        rt["라우터"]
    end
    ctrl ---|"Southbound API (OpenFlow, NETCONF 등)"| sw1
    ctrl --- sw2
    ctrl --- rt

• 장점: 중앙 관리와 자동화, VM·컨테이너가 수시로 생기고 옮겨 다니는 클라우드에서 가상 네트워크를 빠르게 구성, 장비 벤더 종속 완화.
• NFV(Network Function Virtualization)는 방화벽·로드 밸런서 같은 네트워크 기능을 전용 장비 대신 범용 서버의 소프트웨어로 돌리는 것으로, SDN과 짝을 이룬다.
• 쿠버네티스의 CNI 플러그인, 클라우드의 VPC도 같은 생각, 즉 선언한 정책을 컨트롤러가 데이터 평면에 내려보내는 구조다.

IP 멀티캐스트

멀티캐스트는 송신자가 그룹 주소로 한 번만 보내고, 경로가 갈라지는 라우터에서만 패킷을 복사하는 전달 방식이다. 유니캐스트로 N명에게 보내면 송신자 근처 링크에 같은 데이터가 N번 지나가지만, 멀티캐스트는 링크마다 사본이 많아야 하나다. 브로드캐스트와 달리 라우터를 넘어가고, 가입한 호스트만 받는다(통신 방식 비교는 네트워크 기초).

IPTV, 사내 영상 송출, 시세 배포, 라우팅 프로토콜 메시지(OSPF, RIPv2)에 쓴다. 공용 인터넷 사업자들은 망 사이 멀티캐스트를 거의 열어 두지 않아서, 실제로는 한 사업자·한 회사 망 안에서 쓰고 인터넷 전체 배포는 CDN과 라이브 스트리밍의 유니캐스트 계층 구조가 맡는다. 시세 멀티캐스트의 쓰임은 백엔드 지연 최적화에 있다.

그룹 주소

IPv4 클래스 D(224.0.0.0/4)가 멀티캐스트용이고, 주소 하나가 호스트가 아니라 그룹을 가리킨다.

그룹 주소에는 ARP에 답할 주인이 하나가 아니므로, 이더넷은 MAC 주소를 계산으로 만든다. 앞 25비트를 01:00:5E + 0으로 고정하고 IP 주소의 하위 23비트를 붙인다.

239.1.2.3 → 하위 23비트 0000001.00000010.00000011 → 01:00:5E:01:02:03

IP 쪽은 앞 4비트(1110)를 뺀 28비트가 그룹을 구분하는데 MAC에는 23비트만 들어가므로, IP 그룹 32개가 MAC 주소 하나를 공유한다. NIC가 받은 프레임이 정말 가입한 그룹의 것인지는 IP 계층에서 한 번 더 거른다.

IGMP: 그룹 가입 관리

라우터는 자기 LAN에 어떤 그룹의 수신자가 있어야 그쪽으로 내보낸다. IGMP(Internet Group Management Protocol) 는 호스트와 바로 옆 라우터 사이에서 이 가입 정보를 주고받는다. IP 프로토콜 번호 2로 실리고 TTL 1이라 LAN 밖으로 나가지 않는다.

• 질의(Query): 라우터가 묻는다. 모든 그룹에 대한 일반 질의(224.0.0.1로), 특정 그룹 질의, 특정 그룹·송신자 질의(v3)가 있다.
• 보고(Report): 호스트가 답하거나, 가입할 때 먼저 보낸다.
• v2에서 명시적 탈퇴가, v3에서 송신자 지정(SSM의 바탕)이 더해졌다.

스위치는 원래 멀티캐스트 프레임을 모든 포트로 뿌리므로, IGMP 메시지를 엿보고 가입한 포트로만 보내는 IGMP 스누핑을 켜는 경우가 많다. 라우터끼리 가입 정보를 퍼뜨려 전달 트리를 만드는 일은 아래 멀티캐스트 라우팅 프로토콜이 맡는다.

멀티캐스트 라우팅: 전달 트리 만들기

유니캐스트는 목적지마다 최단 경로 하나면 되지만, 멀티캐스트는 송신자에서 여러 수신자로 뻗는 트리가 필요하다.

송신자 기반 트리의 전달 정책은 플러딩의 약점을 하나씩 고친 단계로 이해한다.

RPF는 「송신자로 가는 최단 경로의 반대 방향으로 들어온 패킷만 최단 경로 트리를 따라온 것」이라는 판정이다. 기존 라우팅 테이블을 재활용하므로 멀티캐스트용 경로 계산이 따로 필요 없고, 지금의 PIM도 이 검사를 쓴다.

• DVMRP: RIP식 거리 벡터에 RPM을 얹었다. 느린 수렴, 홉 제한 같은 RIP의 약점을 물려받았다.
• MOSPF: OSPF 링크 상태로 (송신자, 그룹)마다 다익스트라 트리를 계산한다. 가입·탈퇴마다 다시 계산해 작은 환경에만 맞는다.
• CBT: 코어 하나를 뿌리로 한 공유 트리. 송신자는 패킷을 유니캐스트로 감싸 코어에 보내고, 수신 측 라우터는 코어에 명시적으로 가입한다.
• PIM(Protocol Independent Multicast): 어떤 유니캐스트 라우팅 프로토콜이 만든 테이블이든 RPF에 그대로 쓴다. 현재 가장 많이 쓴다. PIM-DM(밀집 모드)은 수신자가 많다고 보고 뿌린 뒤 가지치고, PIM-SM(희소 모드)은 랑데부 포인트(RP)를 뿌리로 한 공유 트리로 시작해 트래픽이 많아지면 송신자 기반 최단 경로 트리로 갈아탄다.

멀티캐스트를 모르는 라우터가 중간에 있으면 멀티캐스트 라우터끼리 유니캐스트 터널로 잇는다. 멀티캐스트 패킷을 터널 반대편 주소로 가는 유니캐스트 패킷에 넣어 보내고 받은 쪽이 꺼내 다시 뿌리는 방식으로, 초기 실험망 MBONE이 이렇게 만들어졌다.

데이터 교환 방식

세 방식은 앞의 약점을 차례로 푼다. 회선 교환은 쓰지 않는 동안에도 선을 붙잡아 비싸고 유연하지 않다. 대신 대역폭을 혼자 다 쓸 수 있어 지금도 금융·군 시설은 전용 회선을 산다. 메시지 교환은 우편처럼 중간 지점마다 다음 목적지를 표로 골라 넘기므로 한 경로가 막혀도 돌아갈 수 있다. 하지만 큰 메시지가 한 구간을 통째로 지나가는 동안 그 구간이 묶여, 1KB짜리 메일도 대용량 파일 뒤에서 기다려야 한다. 패킷 교환은 메시지를 잘게 쪼개 이 막힘을 없애고, 패킷마다 남는 경로로 보낸다. 중앙 통제소가 없어 한 지점이 무너져도 전체가 멈추지 않는다.

패킷 교환은 다시 두 가지로 나뉜다.

• 가상 회선 방식: 논리적 경로를 먼저 설정(호 설정 → 전송 → 해제)하고 패킷이 순서대로 같은 길로 간다. 연결형.
• 데이터그램 방식: 경로 설정 없이 패킷마다 독립적으로 전송. 유연하지만 도착 순서가 바뀔 수 있어 재조립이 필요하다. 비연결형 (IP).

관련 노트: 네트워크 기초, 프록시: 포워드 프록시와 리버스 프록시, 리눅스 네트워크 네임스페이스와 ip 명령, IP QoS, 가입자망과 광역망