IPv6 MTU 및 경로 MTU 탐색: 단편화 문제 방지

패킷 단편화는 모든 것을 망가뜨릴 때까지 눈치채지 못하는 문제 중 하나입니다.

IPv6에서 MTU가 더 중요한 이유#

IPv6는 라우터 기반 단편화를 완전히 제거했습니다. IPv4에서 라우터가 다음 홉에 비해 너무 큰 패킷을 수신하면 단편화할 수 있습니다. IPv6 라우터는 그렇게 할 수 없습니다—패킷을 드롭하고 소스에 ICMPv6 「패킷 너무 큼」메시지를 다시 보냅니다.

소스 호스트가 모든 단편화를 담당합니다. 이 설계 결정은 라우터 성능을 향상시키고 프로토콜을 단순화하지만 엔드포인트에 부담을 전가하고 경로 MTU 탐색(PMTUD)을 중요하게 만듭니다.

PMTUD가 실패하면 연결이 신비롭게 중단됩니다. TCP 핸드셰이크가 완료되지만 데이터 전송이 정지됩니다. HTTP 요청이 시간 초과됩니다. SSH 세션이 인증 후 동결됩니다. 이것들은 전형적인 MTU 블랙홀 증상입니다.

IPv6 최소 MTU#

모든 IPv6 링크는 최소 1280바이트를 지원해야 합니다. 이것은 최소 MTU이며 협상의 여지가 없습니다. 링크가 1280바이트 패킷을 처리할 수 없으면 IPv6 준수가 아닙니다.

대부분의 네트워크는 1500바이트(표준 이더넷 MTU)를 사용하며, 이는 40바이트 IPv6 헤더 + 1460바이트 페이로드를 위한 공간을 제공합니다. 이것은 IPv4의 일반적인 TCP MSS인 1460과 동일합니다.

터널 및 캡슐화 프로토콜은 사용 가능한 MTU를 줄입니다. IPv6-in-IPv4(6in4), 6to4 또는 ISATAP를 실행하는 경우 외부 헤더로 바이트를 잃습니다. VPN, IPsec, GRE 및 VXLAN은 모두 MTU 공간을 소비합니다.

접하게 될 일반적인 MTU 값:

• 1500: 표준 이더넷
• 1480: PPPoE (PPP 오버헤드로 8바이트 손실)
• 1460: 6in4 터널 (IPv4 헤더로 20바이트 손실)
• 1420: PPPoE를 통한 6in4
• 1280: 최소 IPv6 MTU, 폴백 값
• 9000: 점보 프레임 (데이터 센터 네트워크)

경로 MTU 탐색 작동 방식#

PMTUD는 단편화 없이 소스와 대상 사이의 경로를 통과할 수 있는 가장 큰 패킷 크기를 결정합니다.

프로세스는 간단합니다:

1. 호스트가 현재 MTU로 패킷 전송
2. 경로를 따라 라우터에 더 작은 MTU가 있으면 패킷 드롭
3. 라우터가 소스에 ICMPv6 유형 2 「패킷 너무 큼」메시지를 다시 보냄
4. 메시지에 다음 홉의 MTU 포함
5. 호스트가 경로 MTU를 줄이고 재전송
6. 패킷이 전체 경로를 통과할 때까지 프로세스 반복

「패킷 너무 큼」메시지(ICMPv6 유형 2, 코드 0)에는 메시지 페이로드에 MTU 값이 포함됩니다. 이것은 소스에게 패킷이 얼마나 클 수 있는지 정확히 알려주며 단순히 너무 크다는 것만이 아닙니다.

ICMPv6 메시지는 다음과 같습니다:

ICMPv6 패킷 너무 큼:
  유형: 2
  코드: 0
  MTU: 1280
  [최소 MTU까지의 원래 패킷 헤더]

호스트는 일반적으로 10분 후에 만료되는 항목이 있는 경로 MTU 캐시를 유지합니다(RFC 8201 권장 사항). 네트워크 경로가 변경되면 오래된 캐시 항목이 만료될 때까지 문제를 일으킬 수 있습니다.

PMTUD 블랙홀#

ICMPv6 유형 2 메시지가 차단되면 시스템이 중단됩니다. 이것은 패킷이 조용히 사라지는 「PMTUD 블랙홀」을 생성합니다.

일반적인 원인:

과도한 방화벽: 관리자가 때때로 모든 ICMP 트래픽을 보안 위험으로 취급하여 차단합니다. 이것은 잘못되었습니다. ICMPv6는 IPv6 작동에 필수적이며 ping과 같은 선택적 진단 프로토콜이 아닙니다.

상태 검사 문제: 일부 방화벽은 ICMPv6 오류 메시지를 기존 연결과 제대로 연결하지 않아 원치 않는 트래픽으로 드롭합니다.

속도 제한: 보안 장치는 ICMPv6를 속도 제한하여 바쁜 기간 동안 합법적인 PMTUD 메시지를 드롭할 수 있습니다.

NAT64 게이트웨이: IPv6와 IPv4 간의 변환은 게이트웨이가 ICMP 메시지를 제대로 변환하지 않으면 PMTUD 정보를 잃을 수 있습니다.

PMTUD 블랙홀의 증상:

• TCP 연결이 설정됨 (SYN, SYN-ACK, ACK 완료)
• 작은 패킷이 작동 (DNS 쿼리, SSH 로그인 배너)
• 큰 패킷이 실패 (파일 전송, 본문이 있는 HTTP POST, 인증 후 SSH 대화식 세션)
• 오류 메시지 없음, 시간 초과만
• 문제가 간헐적으로 나타남 (패킷 크기에 따라 다름)

MTU 문제 진단#

ping으로 시작합니다. 특정 크기의 패킷을 보내 경로 MTU를 테스트합니다:

# 1280바이트로 테스트 (최소 MTU)
ping6 -M do -s 1232 2001:db8::1
 
# 1500바이트로 테스트 (표준 이더넷)
ping6 -M do -s 1452 2001:db8::1
 
# 1280바이트 페이로드
ping6 -c 5 -s 1280 2001:db8::1

-M do 플래그는 단편화를 금지합니다(단편화하지 않음). -s 인수는 페이로드 크기를 지정합니다—ICMPv6 헤더에 8바이트, IPv6 헤더에 40바이트를 추가하여 전체 패킷 크기를 얻습니다.

1452바이트가 실패하지만 1232가 성공하면 경로 MTU가 1280과 1500 사이입니다. 이진 검색으로 정확한 값을 찾습니다:

# 1400 시도
ping6 -M do -s 1352 2001:db8::1
 
# 1450 시도
ping6 -M do -s 1402 2001:db8::1

traceroute를 사용하여 MTU가 변경되는 위치를 식별합니다:

traceroute6 -n 2001:db8::1

그런 다음 각 홉에 개별적으로 MTU를 테스트합니다. 큰 패킷이 실패하기 시작하는 홉이 문제 지점입니다.

TCP 연결의 경우 실제 동작을 관찰합니다:

# 패킷 캡처
tcpdump -i eth0 -n 'ip6 and (icmp6 or tcp)'

다음을 찾습니다:

• 초기 핸드셰이크 후 TCP 재전송
• ICMPv6 유형 2 메시지 (PMTUD가 작동하면 나타나야 함)
• ICMPv6 유형 2 부재 (차단 또는 블랙홀을 나타냄)

최신 도구는 이를 자동화할 수 있습니다. MTR은 traceroute와 패킷 크기 테스트를 결합합니다:

# 1400바이트 패킷으로 테스트
mtr -6 -s 1400 2001:db8::1

TCP MSS 클램핑#

MSS(최대 세그먼트 크기)는 각 세그먼트에서 보낼 수 있는 데이터 양을 상대방에게 알려주는 TCP 옵션입니다. MSS = MTU - IP 헤더 - TCP 헤더.

IPv6의 경우: MSS = MTU - 40 (IPv6) - 20 (TCP) = MTU - 60

표준 1500바이트 MTU의 경우: MSS = 1440

MSS 클램핑은 TCP 연결이 PMTUD에 의존하지 않고 더 낮은 MSS 값을 사용하도록 강제하여 MTU 문제를 해결합니다. 이것은 터널이나 PPPoE 연결을 종료하는 라우터에서 일반적입니다.

Linux에서 MSS 클램핑 구성:

# IPv6에 대해 MSS를 1280으로 클램프
ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1220

값 1220은 헤더에 대해 1280 MTU에서 60바이트를 뺀 것입니다.

1492 MTU의 PPPoE의 경우:

ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1432

MSS 클램핑은 TCP에만 영향을 줍니다. UDP, SCTP 및 기타 프로토콜은 여전히 PMTUD 또는 애플리케이션 수준 단편화에 의존합니다.

방화벽 구성#

방화벽은 PMTUD가 작동하려면 ICMPv6 유형 2 메시지를 허용해야 합니다. 이것은 프로덕션 IPv6 네트워크에 협상의 여지가 없습니다.

IPv6 작동에 필요한 최소 ICMPv6 유형:

• 유형 1: 대상 도달 불가
• 유형 2: 패킷 너무 큼 (PMTUD)
• 유형 3: 시간 초과
• 유형 4: 매개변수 문제
• 유형 133-137: 이웃 탐색 프로토콜

PMTUD에 대한 iptables 규칙:

# ICMPv6 패킷 너무 큼 허용
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type 2 -j ACCEPT

더 나은 접근 방식—필요한 모든 ICMPv6 허용:

# 설정된 ICMPv6 허용
ip6tables -A INPUT -p ipv6-icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# 필요한 ICMPv6 유형 허용
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT    # 대상 도달 불가
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT    # 패킷 너무 큼
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 3 -j ACCEPT    # 시간 초과
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 4 -j ACCEPT    # 매개변수 문제
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -j ACCEPT  # 에코 요청
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT  # 에코 응답
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 133 -j ACCEPT  # 라우터 요청
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 134 -j ACCEPT  # 라우터 광고
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 135 -j ACCEPT  # 이웃 요청
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 136 -j ACCEPT  # 이웃 광고

속도 제한은 허용되지만 관대한 제한을 설정합니다:

# 속도 제한으로 ICMPv6 허용
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 \
  -m limit --limit 10/sec --limit-burst 20 -j ACCEPT

ICMPv6를 완전히 차단하지 마십시오. 보안 위험이 아닙니다—프로토콜 요구 사항입니다.

터널 MTU 고려 사항#

터널은 캡슐화 헤더의 오버헤드만큼 유효 MTU를 줄입니다.

일반적인 터널 유형 및 오버헤드:

문제를 피하기 위해 터널 MTU를 명시적으로 구성합니다:

# 6in4 터널
ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 198.51.100.1
ip link set tun6in4 mtu 1480
ip link set tun6in4 up

WireGuard의 경우:

[Interface]
MTU = 1420

일부 터널 프로토콜은 MTU 탐색을 지원하지만 명시적 구성이 더 신뢰할 수 있습니다.

점보 프레임 및 데이터 센터#

데이터 센터 네트워크는 대량 전송의 처리량을 향상시키기 위해 9000바이트 MTU(점보 프레임)를 자주 사용합니다.

인터페이스에서 점보 프레임 활성화:

ip link set eth0 mtu 9000

경로의 모든 스위치와 라우터가 점보 프레임을 지원하는지 확인합니다. 1500바이트 MTU를 가진 하나의 장치가 병목 현상이 됩니다.

PMTUD는 여전히 적용됩니다. 패킷이 점보 프레임 네트워크를 떠나 인터넷으로 향하면 1500 이하로 줄여야 합니다.

테스트 및 확인#

호스트의 MTU 구성 확인:

ip -6 link show

각 인터페이스에서 MTU 값을 찾습니다.

현재 경로 MTU 캐시 확인:

ip -6 route get 2001:db8::1

출력은 해당 대상에 대해 캐시된 MTU를 표시합니다.

다양한 패킷 크기로 엔드 투 엔드 연결 테스트:

for size in 1232 1352 1402 1452; do
  echo "$size 바이트 테스트:"
  ping6 -M do -s $size -c 3 2001:db8::1
done

netcat를 사용하여 TCP MSS 협상 테스트:

# 서버
nc -6 -l 8080
 
# 클라이언트
nc -6 2001:db8::1 8080

tcpdump로 패킷을 캡처하고 SYN 패킷의 MSS 값을 확인합니다.

일반적인 시나리오 및 수정#

문제: 웹 페이지가 느리게 로드되고 이미지가 실패 원인: 방화벽이 ICMPv6 유형 2를 차단하여 PMTUD 블랙홀 수정: 방화벽이 ICMPv6 유형 2를 허용하도록 구성

문제: SSH가 연결되지만 로그인 후 동결 원인: MTU가 너무 크고 PMTUD가 작동하지 않음 수정: 클라이언트 인터페이스에서 MTU 줄이기 또는 라우터에서 MSS 클램핑 활성화

문제: VPN이 작은 전송에는 작동하지만 큰 파일에는 실패 원인: 터널 MTU가 올바르게 구성되지 않음 수정: 캡슐화 오버헤드를 고려하도록 터널 MTU 줄이기

문제: IPv6가 로컬 네트워크에서 작동하지만 인터넷에서 실패 원인: 업스트림 라우터에 더 작은 MTU가 있지만 제대로 광고하지 않음 수정: ISP에 연락하거나 로컬 MTU를 1280(최소)으로 줄이기

문제: 일부 대상은 작동하지만 다른 대상은 실패 원인: 경로별 MTU 문제 수정: ping으로 테스트하여 작동하는 MTU 식별, 그에 따라 인터페이스 구성

모범 사례#

1. 방화벽에서 항상 ICMPv6 유형 2 허용
2. 터널 MTU를 명시적으로 구성 자동 감지에 의존하지 않음
3. 최소 MTU(1280)로 테스트 기본 연결 보장
4. 터널 엔드포인트 및 PPPoE 연결에서 MSS 클램핑 사용
5. 문제 해결 중 패킷 캡처로 PMTUD 실패 모니터링
6. 네트워크의 MTU를 각 계층에서 문서화 (물리적, 터널, 애플리케이션)
7. 의심스러울 때 보수적인 MTU 값 설정 (1280은 항상 작동)

관련 문서#

• ICMPv6 설명 - IPv6의 제어 프로토콜 이해
• IPv6 방화벽 구성 - 기능을 깨지 않고 IPv6 보안
• IPv6 문제 해결 - 일반적인 IPv6 연결 문제 디버그

추가 자료#

• RFC 8201: IPv6용 경로 MTU 탐색
• RFC 4821: 패킷화 계층 경로 MTU 탐색
• IPv6 MTU 문제 - RIPE Labs