요약

  • RFC 1191은 IPv4 발신지가 Don't Fragment 비트를 설정하고, 크기를 제한하는 라우터가 다음 홉 MTU를 담은 ICMP 메시지를 반환하는 데 의존하도록 만들었습니다. 라우터가 근거를 제공했고, 엔드포인트가 패킷 크기를 줄이는 방식을 선택했습니다.
  • RFC 2923은 ICMP가 필터링되거나 유실될 때 생기는 블랙홀을 기록했습니다. TCP 연결은 시작된 뒤 더 큰 패킷이 사라지면서 멈출 수 있었습니다. TCP MSS는 경로 정보의 완전한 대체물이 아니었습니다.
  • Cloudflare의 2015년 ECMP 사건은 또 다른 실패를 보여주었습니다. TCP와 ICMP가 서로 다르게 해싱되어, 정당한 Packet Too Big 메시지가 해당 연결을 소유하지 않은 백엔드에 도달할 수 있었습니다.
  • PLPMTUD와 DPLPMTUD는 엔드포인트가 ICMP 수신에 의존하지 않고 크기를 탐칠 수 있게 합니다. 이들은 침묵에서 벗어나는 길을 복원하지만, 탐색 트래픽, 상태, 전달 확인 그리고 MTU 한계와 다른 종류의 손실을 구별하는 규율이 필요합니다.

데이터는 도착했지만 설명은 오지 않았다

Cloudflare의 2015년 2월 기록은 내부 라우팅 변경에서 시작됩니다. TCP 트래픽이 등가 다중 경로(ECMP) 라우팅으로 여러 서버에 분산되었습니다. 라우터는 익숙한 4-튜플을 해싱했기 때문에 하나의 연결에 속한 패킷들은 같은 백엔드로 돌아왔습니다.

ICMP는 라우터가 사용하는 형태로는 같은 정보를 담고 있지 않았습니다. Cloudflare에 따르면 ECMP 경로는 이런 메시지에 대해 발신지·수신지 주소를 해싱했습니다. 따라서 TCP 흐름은 계속 올바른 백엔드에 도달하면서도 Packet Too Big 경고는 다른 백엔드에 도달할 수 있었습니다. 회사는 자신들의 사건에서 정확히 이런 일이 일어났다고 기술했습니다.

IPv6 터널을 통해 접속한 몇 명의 사용자만이 이 증상을 보고했습니다. 이 숫자만으로 전 세계적 발생 규모를 입증할 수는 없습니다. 그 사후분석이 확립하는 보다 분명한 점은 이것입니다. 제어 메시지는 올바른 조직에 도달하면서도 그것에 의미를 부여하는 상태를 놓칠 수 있다는 것입니다.

Cloudflare는 먼저 IPv6 MTU를 1280으로 낮추고 IPv4에 대해 RFC 4821 탐색을 활성화했습니다. 이후의 장기 데몬은 IPv4 fragmentation-needed와 IPv6 Packet Too Big 메시지를 수집해 백엔드 네트워크 전체에 브로드캐스트했습니다. 함께 공개된 저장소는 발신지 하나당 초당 1패킷, 인터페이스 하나당 초당 10패킷의 제한을 두었습니다.

브로드캐스트는 연결별 근거를 공유된 내부 근거로 바꾸었습니다. 동시에 새로운 검증·분배·속도 제어 책임을 만들었습니다. 이 수리는 Cloudflare의 아키텍처에 특화된 것이었고, 보편적인 설계 지침이 아니었습니다.

탐색 이전의 네트워크는 조각이나 작은 패킷으로 대가를 치렀다

1990년 11월에 발표된 RFC 1191은 경로 MTU를 발신지와 수신지 사이 홉들의 MTU 중 가장 작은 값으로 정의했습니다. 이 정의는 이미 두 차원에서 불안정했습니다. 경로에는 숨겨진 크기 제한 링크가 있을 수 있고, 라우팅이 나중에 어느 링크가 가장 작은지를 바꿀 수 있었습니다.

이전의 보수적 관행은 576옥텟과 첫 홉 MTU 중 작은 값을 사용했습니다. 이는 알 수 없는 경로가 큰 데이터그램을 운반할 수 있다고 가정하지 않기 위함이었습니다. 동시에 더 큰 패킷을 운반할 수 있는 경로에서 용량을 낭비하면서도, 이후 홉이 발신지가 예상한 것보다 작으면 여전히 단편화를 허용했습니다.

일상적인 단편화는 작업을 경로 안으로 옮겼습니다. 라우터는 하나의 IPv4 데이터그램을 수신지가 재조립해야 하는 조각들로 나눌 수 있었습니다. 조각 하나를 잃으면 원본 데이터그램 전체가 무효화될 수 있었습니다. 이후의 운영 작업은 필터링, 상태 유지 장치, 비대칭 경로, 터널과 관련된 더 많은 어려움을 기록했습니다.

1990년의 선택은 완벽한 탐색 시스템과 무모한 단편화 사이의 선택이 아니었습니다. 발신지는 작게 유지하거나, 허용되는 경우 라우터의 단편화에 맡기거나, 명시적 경로 피드백을 얻거나, 이들을 결합할 수 있었습니다. RFC 1191은 피드백을 선택했습니다. 그래야 모든 라우터가 크기 초과 패킷마다 단편화하지 않으면서도 실제 경로의 유용한 크기에 접근할 수 있었기 때문입니다.

RFC 1191은 지식을 경로에, 행동을 발신지에 할당했다

고전적 IPv4 메커니즘은 짧은 제어 루프를 갖습니다. 발신지가 Don't Fragment 비트를 설정합니다. 다음 홉에서 단편화 없이는 전달할 수 없는 라우터는 데이터그램을 폐기하고 fragmentation-needed 코드가 담긴 ICMP Destination Unreachable을 보냅니다.

RFC 1191은 라우터가 다음 홉 MTU를 포함하도록 요구합니다. 발신지는 경로 추정치를 낮춥니다. 더 작은 패킷을 보내거나 Don't Fragment 설정을 멈출 수 있습니다. 라우터는 로컬 제약을 보고하지만 발신지의 전송 정책을 선택하지는 않습니다.

이 비대칭이 중요합니다. 라우터는 하나의 인터페이스에 대한 직접 지식을 갖고, 엔드포인트는 패킷화를 소유하며 추정치를 유지합니다. 어느 쪽도 상대의 제어 지점을 갖지 않으므로, ICMP 메시지는 선택적 장식 설명이 아닙니다. 관찰과 교정 능력 사이의 다리입니다.

이 표준은 손쉬운 증가도 의심했습니다. 엔드포인트는 ICMP 메시지가 더 큰 값을 알린다고 해서 추정치를 올려서는 안 됩니다. 나중에 직접 탐칠어야 합니다. RFC 1191은 감소 후 최소 5분, 바람직하게는 10분을 기다린 뒤에 상향을 시험할 것을 권고했습니다.

이 간격들은 모든 스택에 대한 측정이 아니라 당시의 구현 지침입니다. 설계자들이 두려워한 것이 무엇이었는지를 보여줍니다. 경로 변경과 거짓 또는 오래된 메시지가 이전에 학습된 값을 어느 방향으로든 위험하게 만들 수 있다는 점입니다.

IPv6는 라우터 단편화를 없앴지만, 학습의 필요를 없애지는 않았다

IPv6는 책임의 배분을 더 선명하게 했습니다. 현재 기본 규격은 모든 링크가 1280옥텟 IPv6 패킷을 운반하거나, 그렇지 않으면 IP 아래에서 링크별 단편화와 재조립을 제공하도록 요구합니다. 라우터는 전달되는 IPv6 패킷을 단편화하지 않습니다. Fragment 헤더를 추가할 수 있는 것은 발신지뿐입니다.

RFC 8200은 발신지가 1280보다 큰 크기를 사용할 수 있도록 PMTUD를 강력히 권고합니다. 최소 구현은 1280보다 큰 패킷을 보내지 않는 방식을 선택할 수도 있습니다. 이는 완전한 탐색에서 벗어나는 정당한 출구이지만, 모든 경로의 MTU가 1280이라는 증명이 아니라 효율성의 절충입니다.

RFC 8201에 따라, 전달할 수 없는 IPv6 라우터는 ICMPv6 Packet Too Big을 반환합니다. 엔드포인트는 인용된 패킷이 자신이 보낸 트래픽에 해당하는지 검증해야 합니다. 정당한 메시지는 추정치를 낮출 수 있지만, IPv6 최소값인 1280 미만으로는 낮출 수 없습니다.

Packet Too Big 메시지는 절대로 추정치를 올리는 데 사용해서는 안 됩니다. 발신지는 나중에 상향 탐색을 할 수 있으며, 감소 후 최소 5분, 바람직하게는 10분보다 자주 할 수 없습니다. 여기서도 규칙은 근거를 구속합니다. 라우터는 제약을 보고할 수 있지만, 엔드포인트가 맥락을 인증하고 그것을 얼마나 유지할지 결정해야 합니다.

RFC 4890은 Packet Too Big을 방화벽이 폐기해서는 안 되는 ICMPv6 트래픽으로 분류했습니다. 그런 통신은 차단되거나 심각하게 손상될 수 있기 때문입니다. 이것은 분명한 운영 지침입니다. 그러나 모든 방화벽이 이를 따른다는 증명도, 다른 모든 ICMP 메시지가 동일한 대우를 받아야 한다는 증명도 아닙니다.

침묵은 블랙홀이 되었다

RFC 2923은 이 피드백 실패에 지속되는 증상을 부여했습니다. 라우터, 방화벽, 커널 결함 또는 설정이 ICMP 오류의 반환을 막으면, 발신지는 경로에 비해 너무 큰 패킷을 계속 보냅니다. 경로는 그것들을 폐기하고, 엔드포인트는 이유를 알지 못합니다.

TCP 핸드셰이크는 패킷이 작기 때문에 성공할 수 있었습니다. 데이터가 이동하기 시작합니다. 그런 다음 더 큰 세그먼트가 사라지고, 재전송이 같은 실수를 반복하며 연결이 멈춘 것처럼 보였습니다. 이 문서의 FTP 예제에서는 작은 제어 채널은 작동하는 가운데 대량 전송이 실패했습니다.

이 패턴은 검증할 가치가 있는 증거이지 판결이 아닙니다. 혼잡, 손상, 비대칭 정책 및 다른 필터링도 패킷을 잃게 만들 수 있습니다. 진지한 진단은 한 번의 실패한 다운로드로 MTU 블랙홀이라 이름 붙이는 대신, 크기, 주소 체계, DF 또는 Fragment 동작, 재전송, 인용된 ICMP 메시지를 기록해야 합니다.

TCP MSS는 이 불확실성을 제거하지 않습니다. MSS는 수신자가 받아들일 준비가 된 가장 큰 TCP 페이로드를 상대 엔드포인트에게 알려줍니다. 전방 경로의 모든 터널과 링크를 드러내지 않으며, 반환 경로는 다를 수 있습니다.

RFC 2923은 ICMP 경로를 수리하는 쪽을 선호했습니다. 또한 엔드포인트의 블랙홀 탐지를 설명했습니다. 재전송 시간 초과 후 더 작은 패킷을 보내는 것입니다. 이는 세션을 복구할 수 있지만, 수 초를 추가하고 다른 트래픽에 계속 영향을 줄 경로 결함을 감추었습니다.

방화벽은 제약 없이 거부권을 쥐었다

운영자는 자신의 네트워크에서 트래픽을 필터링할 정당한 권한을 가질 수 있습니다. 이 역사적 실패는 그런 운영자가 불법적이거나 악의적이거나 보안 근거 없이 행동했다는 증명이 아닙니다. 더 어려운 질문은 그 필터가 무엇을 결론지을 자격이 있었는가입니다.

제어 메시지를 드롭한다고 해서 더 큰 패킷이 전달 가능해지지는 않았습니다. 링크 제약은 그대로 두면서 엔드포인트에서 근거를 제거했을 뿐입니다. 따라서 로컬 정책은 라우터의 지식이나 엔드포인트의 책임을 얻지 않은 채 적응에 대한 실질적 거부권을 얻었습니다.

터널은 이 분열을 심화했습니다. 캡슐화는 엔드포인트가 패킷 크기를 선택한 뒤 헤더를 추가하여 원래 패킷에 사용 가능한 유효 용량을 줄입니다. 트래픽 분배기와 애니캐스트 시스템은 그 다음 데이터 트래픽과 오류 트래픽에 서로 다른 인스턴스 신원을 부여할 수 있습니다. "그 MTU"라 불리는 수는 시간, 방향, 흐름, 캡슐화 맥락이 있어야만 의미를 갖습니다.

이것이 PMTU가 주소 블록이나 프리픽스의 영구 속성이 아닌 이유입니다. RIR은 번호 자원을 할당할 수 있지만, 보유자에게 이르는 모든 경로의 단대단 패킷 크기를 인증하지는 않습니다. 경로 상태는 할당 이후의 라우팅과 운영이 만들어냅니다.

패킷화 계층 탐색은 실험을 엔드포인트로 옮겼다

2007년의 RFC 4821은 근거의 출처를 바꾸었습니다. 패킷화 계층 PMTUD는 점점 더 큰 탐색 패킷을 보내고 전송 또는 패킷화 계층의 전달 피드백으로부터 학습합니다. ICMP가 도착하지 않아도 진전을 이룰 수 있습니다.

엔드포인트는 확실성이 아니라 침묵에서 벗어나는 출구를 얻습니다. 고립된 탐색 패킷의 손실은 시험한 크기가 한계를 넘었다는 뜻일 수 있습니다. 탐색 패킷 주변의 손실은 결과를 불확정으로 만듭니다. 혼잡이나 다른 장애가 원인일 수 있기 때문입니다. 따라서 이 방법은 탐색 상태, 시간 제어, 신중한 해석이 필요합니다.

IETF PMTUD 워킹그룹 헌장은 기존 PMTUD의 약점이 새 링크와 터널에 대한 만성적 장애물이라고 기술했습니다. 그 제안 방향은 작은 패킷에서 시작해 ICMP에 의존하지 않고 상향 탐색하는 것이었습니다. 헌장은 제도적 문제 진술을 기록한 것입니다. 보편적 합의, 채택, 성공을 증명할 수는 없습니다.

RFC 8899는 이후 이 접근을 데이터그램 패킷화 계층으로 확장했습니다. DPLPMTUD 구현은 크기를 시험하고, 전달 확인 후 확정 값을 올리며, 블랙홀을 감지하면 값을 낮춥니다. 검증된 Packet Too Big 메시지를 사용할 수 있지만, 그 메시지에만 의존할 수는 없고 그것으로 크기를 올리는 일은 결코 할 수 없습니다.

UDP 자체는 응답 확인을 제공하지 않습니다. 전송 계층이나 응용이 탐색 패킷의 확인 방법을 제공해야 합니다. 이것이 제어를 위로 옮긴 대가입니다. 단순히 데이터그램만 보내던 응용이 이제는 경로 속성을 학습하기 위해 상태와 피드백이 필요할 수 있습니다.

이제 이전과 새 메커니즘이 공존한다

현재 TCP 규격은 PMTUD를 강력히 권고하고 PLPMTUD를 권고합니다. 고정된 폴백 크기도 여전히 정의되어 있지만, RFC 9293은 작은 패킷만 보내면 성능이 손상될 수 있다고 경고합니다. 표준 기록은 하나의 보편 메커니즘을 다른 것으로 교체한 것이 아니라, 유용한 라우터 피드백과 함께 엔드포인트의 대안을 만들었습니다.

현재 Linux 문서는 이 공존을 노출합니다.tcp_mtu_probing=0은 TCP 탐색을 비활성화합니다. 모드1은 스택이 ICMP 블랙홀을 감지한 후에 이를 활성화합니다. 모드2는 설정된 기본 MSS로 이를 계속 활성화합니다. 문서화된 탐색 간격의 기본값은 10분입니다.

이러한 제어는 전역 설정이 아니라 운영자의 선택을 증명합니다. 또한 락인을 드러냅니다. 호스트는 여전히 정당한 ICMP 메시지의 이득을 취하거나, 침묵을 의심할 때 탐색으로 폴백하거나, 탐색하지 않도록 구성된 채 남아 있을 수 있습니다. 방화벽, 터널, 커널, 응용은 하나의 조율된 사건으로 함께 바뀌지 않았습니다.

따라서 RFC 8900은 단편화가 폐지되었다고 선언하는 데 그치지 않았습니다. 취약점을 목록화하고 상위 계층에 그것에 대한 의존을 줄이도록 조언했습니다. 그 결과는 계층적 합의입니다. 명시적 경로 신호를 유지하고, 검증하고, 탐색이라는 탈출 경로를 만들며, 어느 쪽도 신뢰할 수 없을 때 보수적인 크기를 계속 사용할 수 있도록 하는 것입니다.