IPv4는 전송 중에 단편화하지만, IPv6는 대신 패킷이 너무 큼 메시지를 보낸다

IPv6 장애는 원인이 된 패킷 크기보다 프로토콜 탓으로 훨씬 자주 돌려진다. 두 체계는 너무 큰 패킷을 실제로 다르게 처리하며, 그 차이를 중요하게 만드는 것은 터널이다. IPv4 라우터는 규칙이 허용할 때 패킷을 단편화할 수 있지만, IPv6 라우터는 전송 중에 단편화해서는 안 된다. IPv6는 대신 송신자에게 알리며, 송신자가 반응하기를 기대한다. 그 뒤에 벌어지는 모든 문제는 그 메시지가 도착하는지에 달려 있다.

각 체계가 하는 일

표는 네 줄로 된 원리이며, 한 줄이 혼란의 대부분을 설명한다.

IPv6에는 전송 중 단편화도, 지울 DF 플래그도 없으므로 패킷이 너무 클 때 기댈 것이 없다. 송신자에게 알려야 하고, 송신자는 그것을 믿어야 한다.

터널은 경로를 조용히 좁힌다

VPN은 패킷이 호스트를 떠나기 전에 바깥 헤더를 추가하고, 암호화된 경우 무결성 데이터도 추가한다. 안쪽 패킷은 자신이 보는 인터페이스 MTU에 들어갈 수 있지만 바깥 패킷은 다음 링크의 한도를 넘기 때문에, 이 문제가 터널에서 먼저 드러난다. 터널 인터페이스의 MTU를 의도적으로 낮추거나 경로에서 TCP MSS를 조이거나, 선택한 숫자와 이유를 적어 두어라.

ESP 오버헤드는 모드와 알고리즘에 따라 달라지므로 올바른 터널 MTU는 관습이 아니라 계산이다. 무엇을 고르든, 모든 IPv6 링크가 그만큼을 실어야 하므로 1280바이트의 온전한 안쪽 IPv6 패킷을 위한 자리를 남겨야 한다. 1280바이트의 IPv6를 실을 수 없는 터널은 튜닝 문제가 아니라 그 체계에게 끊긴 경로다. IPv4 전용 배포에서 MTU 값을 복사할 때 사라지는 것이 바로 이 제약이다.

증상이 멈춤으로 보이는 이유

장애는 깔끔한 오류가 아니어서 잘못 진단된다. TCP 핸드셰이크가 끝나고 작은 응답이 도착하며, 큰 응답이나 대량 업로드가 시작되는 순간 연결이 멈추는데, 그것들이 버려질 만큼 큰 첫 패킷이기 때문이다. SSH는 연결된 뒤 첫 큰 출력에서 멈추고, 페이지는 헤더가 로드되어도 본문이 끝나지 않는다.

ICMPv6의 패킷이 너무 큼 메시지가 필터링되면, 송신자는 영영 알지 못하고 같은 크기를 계속 재시도한다. 그것은 느린 경로가 아니라 블랙홀이며, 그 특징은 무작위 손실이 아니라 반복 가능한 크기 경계다. 관련 제어 트래픽을 허용해 두는 것은 동작하는 IPv6 배포의 일부이지 친절이 아니다.

자신의 경로가 의존하는 메시지를 꺼 두고 그 결과를 IPv6 결함이라고 묘사하지 마라. 같은 논리는 IPv4의 Fragmentation Needed 메시지에도 적용되며, 그것들 역시 방화벽 작성자에게 똑같이 인기가 없고 똑같이 필요하다.

경계를 측정한 뒤 계층을 고쳐라

추측하지 말고 확인하라: IPv4에서는 don't-fragment 플래그를, IPv6에서는 고정 페이로드 크기를 사용하고 응답이 어디서 멈추는지 기록하라. ping -M do -s 1472 그리고 ping -6 -s 1400 는 문제의 형태를 파악하기에 충분하며, tracepath 는 도중에 발견한 경로 MTU를 보고한다.

그다음 그 숫자를 소유한 계층, 즉 터널 인터페이스의 MTU, TCP용 MSS 클램프, 또는 경로 자체를 고쳐라. IPv6 규칙의 참조는 RFC 8200이며, 그것이 예방하는 사고보다 짧게 읽힌다.

이중 스택 이름은 한 체계에서는 응답하고 다른 체계에서는 응답하지 않을 수 있고 네트워크 변경 뒤 애플리케이션이 전환될 수도 있으므로, 애플리케이션이 실제로 사용하는 체계를 시험하라. A 레코드에 대한 결과는 AAAA 레코드에 대해 아무것도 말해 주지 않으므로 시험한 주소를 기록하라.

크기 경계를 증거로 다루어라

반복 가능한 크기 경계는 매번 같은 바이트 수에서, 같은 출처로부터 정확히 재현되는 몇 안 되는 네트워크 장애 중 하나다. 그래서 그것은 수수께끼가 아니라 선물이며, 수정을 기대하는 대신 검증할 수 있다는 뜻이기도 하다.

발견한 MTU, 구성한 터널 MTU, 차이를 입증한 시험을 티켓에 적어라. 다음 사람은 다른 링크에서 같은 산수를 만나게 된다.