요약

  • IPv6 젬보그램에서 기본 헤더의 페이로드 길이 0은 바로 뒤의 Hop-by-Hop Options 헤더에 있는 Jumbo Payload 옵션으로 수신자를 안내합니다.
  • 이 옵션은 실제 페이로드 길이를 32비트로 담고 있으며 65,535옥텟을 초과하는 경우에만 유효합니다. 0이라는 사실만으로는 비어 있음도 유효성도 입증되지 않습니다.
  • 문법이 올바르더라도 경로상의 모든 장치가 패킷을 운반할 수 있는지, 또는 ICMP 오류 메시지가 없다는 것이 성공적인 전달을 입증하는지는 증명하지 않습니다.

권한을 넘겨주는 작은 필드

일반적인 IPv6 기본 헤더에는 16비트 페이로드 길이 필드가 있습니다. 이 값은 고정 40옥텟 헤더 뒤에 오는 모든 것, 확장 헤더를 포함하여 계산합니다. 페이로드가 65,535옥텟을 초과할 때까지는 이 방식이 작동합니다. RFC 2675는 최대값을 재해석하지도, 기본 헤더에 바이트를 추가하지도 않습니다. 대신 0을 센티널 값으로 사용하고 권위 있는 길이를 Jumbo Payload 옵션으로 옮깁니다.

이 넘겨주기는 조건부입니다. 기본 페이로드 길이가 0인 패킷을 받고, 다음 헤더가 Hop-by-Hop Options 헤더이며, IPv6 헤더 뒤에 아직 옥텟이 남아 있는 노드는 해당 옵션 헤더를 처리해야 합니다. 거기에 Jumbo Payload 옵션이 있다면 부호 없는 32비트 Jumbo Payload 길이를 담습니다. 이 값은 IPv6 기본 헤더 뒤의 확장 헤더와 상위 계층 데이터를 모두 포괄하며, 반드시 65,535를 초과해야 합니다.

바로 그렇기 때문에 “페이로드 길이: 0”에서 멈춘 패킷 목록은 한 필드 일찍 멈춘 것입니다. 트리거는 보고했지만 트리거가 위임하는 값은 보고하지 않은 것입니다. 방어 가능한 판정에는 다음 헤더 값, 옵션의 존재와 위치, 선언된 길이, 캡처된 바이트 수가 필요합니다. 캡처가 잘렸다면 분석자는 불완전한 관측과 변형된 패킷을 구분해야 합니다.

짝이 곧 수표

표준은 무효 조합을 보기 드물게 명확하게 정의합니다. 0 뒤에 Hop-by-Hop Options 헤더가 오지만 Jumbo Payload 옵션이 없으면 오류입니다. 0이 아닌 기본 페이로드 길이와 Jumbo 옵션이 결합되면 오류입니다. 65,536 미만의 Jumbo Payload 길이는 오류입니다. Jumbo Payload 옵션과 Fragment 헤더를 함께 담는 패킷도 오류입니다. RFC 2675는 모순을 만든 필드나 옵션을 가리키는 포인터와 함께 ICMP Parameter Problem 응답을 지정합니다.

이 규칙들은 근거를 관계적으로 만듭니다. 어느 쪽 값도 단독으로는 신뢰할 수 없습니다. 기본 헤더의 0과 옵션의 큰 값이 짝을 이루어 하나의 서술을 구성하며, 주변 헤더 체인이 이 짝이 일관되는지를 결정합니다. 0을 “비어 있음”으로 라벨링하는 디코더는 유효한 트래픽을 잃습니다. 모든 0을 젬보그램으로 받아들이는 디코더는 변형된 트래픽을 허용합니다. 더 안전한 기록은 기본 필드와 옵션, 그리고 검증 결과를 모두 보존합니다.

RFC 4443은 오류 근거에 경계를 하나 더합니다. Parameter Problem 메시지는 타입 4이며 코드 0은 오류가 있는 헤더 필드를 만났다는 뜻입니다. 문제 패킷은 폐기되며, ICMPv6 응답은 프로토콜 규칙에 따라 전송되어야 합니다. 그러나 그 응답이 없다는 것은 패킷이 수락되었다는 증거가 아닙니다. 필터, 레이트 리밋, 비대칭 라우팅 또는 부재하는 복귀 경로가 모두 가시적 신호를 지울 수 있습니다.

별도로 규율되는 또 하나의 0

UDP는 또 하나의 겉보기 0을 도입합니다. IPv6 젬보그램에 담긴 UDP 데이터그램의 경우, 실제 UDP 길이가 65,535를 초과하면 RFC 2675는 UDP 길이 필드가 0이 되는 것을 허용합니다. 수신자는 중간 확장 헤더들의 길이를 빼고 Jumbo Payload 길이에서 그 길이를 도출합니다. 체크섬 계산은 0이 아니라 도출된 실제 길이를 사용합니다.

따라서 두 개의 0은 조화되어 있지만 별개의 의미를 지닙니다. IPv6의 0은 Jumbo Payload 옵션을 가리키고, UDP의 0은 UDP 전용 젬보그램 규칙을 발동합니다. 하나를 관측했다고 해서 분석자가 다른 하나를 추론할 자격이 생기는 것은 아닙니다. TCP에는 대응하는 패킷 길이 필드가 없습니다. 이 맥락에서 TCP의 최대 세그먼트 크기 값 65,535는 무한 상한으로 취급되며, 실용적인 세그먼트 크기는 Path MTU Discovery와 실제 경로에 의해 제한됩니다.

서류상으로는 유효, 실제로는 경로에 의존

젬보그램은 MTU가 65,575옥텟을 초과하는 링크에서만 의미가 있습니다. 40옥텟 IPv6 헤더에 65,535를 넘는 페이로드를 더한 값입니다. 그런 링크에 연결되지 않는 구현은 이를 지원할 의무가 없습니다. RFC 8201은 더 나아가 경로 용량을 발견되는 속성으로 만듭니다. 경로 MTU는 경로상 링크 MTU의 최솟값이며, 초과 크기 패킷은 ICMPv6 Packet Too Big 메시지와 함께 폐기될 수 있습니다.

따라서 Jumbo 옵션은 전달을 입증하지 않은 채 문법적 유효성만 확립할 수 있습니다. 송신자, 수신자, 첫 링크는 이 형식을 지원하면서 터널, 미들박스 또는 이후 링크가 지원하지 않을 수 있습니다. 반대로, Jumbo 옵션이 들어 있다는 이유만으로 모든 패킷을 거부하는 정책은 IPv6 표준이 유효하다고 인정하는 형식을 거부하는 것입니다. RFC 9288은 과도하게 광범위한 확장 헤더 필터링을 논하면서 이 구분을 명시적으로 만듭니다.

운영상 근거는 세 가지 주장을 분리해 두어야 합니다. 패킷이 무엇을 선언했는지, 헤더 체인이 표준을 충족했는지, 경로가 그것을 어떻게 처리했는지가 그 세 가지입니다. 첫째는 필드에서 옵니다. 둘째는 파싱과 일관성 검사에서 옵니다. 셋째는 경로 관측—수신 성공, 카운터, Packet Too Big 메시지, 통제된 프로브 또는 교차 확인되는 트레이스—을 필요로 합니다. 이 셋을 합치면 절약적인 센티널이 거짓 판정으로 변합니다.

출처