요약

  • RFC 768은 0에 서로 다른 두 가지 의도된 의미를 부여했습니다. 계산된 0은 전부 1로 변환되고, 전부 0인 필드는 체크섬이 생성되지 않았음을 선언했습니다.
  • 감지되지 않은 오류에 대한 보고는 지역적 효율 선택을 종단 간 증거 문제로 바꾸었고, 그 결과 IPv6는 UDP 체크섬을 기본 요구사항으로 만들었습니다.
  • 이후의 IPv6 터널 예외는 평범한 UDP의 자유가 아닙니다. 그것은 포트 범위로 제한되고, 종단에서 구성되며, 무결성·경로·보안 의무를 수반합니다.

판정을 거부할 수 있었던 필드

UDP의 8바이트 헤더는 최소한처럼 보였지만, 그 체크섬은 페이로드 이상을 커버했습니다. RFC 768은 발신·수신 주소, 프로토콜 번호, UDP 길이를 담은 개념적 IP 의사 헤더(pseudo-header)를 앞에 붙였습니다. 그 결과는 훼손을 감지할 뿐 아니라 데이터그램이 잘못된 네트워크 종단으로 전달된 사고도 감지할 수 있었습니다.

1의 보수(ones' complement) 산술은 결과가 0이 되는 경우를 계산할 수 있습니다. 명세는 그 유효한 결과를 위해 전부 1을 예약했습니다. 전부 0인 필드는 다른 의미였습니다. 송신자가 디버깅을 위해, 또는 상위 계층이 신경 쓰지 않기 때문에 체크섬을 생성하지 않았다는 뜻이었습니다.

이 인코딩은 역사적으로 중요합니다. 0은 “데이터가 통과했다”고 말하지 않았습니다. 이 계층이 판정을 제공하지 않았다고 말한 것입니다.

사적인 절약이 만든 공적 맹점

RFC 1122는 여전히 애플리케이션이 체크섬 생성을 제어하는 것을 허용했지만, 체크섬이 기본으로 켜져 있어야 한다고 요구했습니다. 그 논의는 지역 네트워크에 국한된 애플리케이션들이 효율을 위해 체크섬을 끈 후 수많은 미감지 오류가 발생했다는 사실을 기록했습니다.

발신자는 즉시 작업을 절약했습니다. 반면 하류의 모든 수신자, 애플리케이션, 운영자는 훼손이나 오전달을 거부할 독립적인 수단을 잃었습니다. 지역적 선택이 그 선택을 승인하지 않은 낯선 이들에게 제공되는 증거를 바꾸어 버린 것입니다.

여기에 메커니즘과 권한의 차이가 있습니다. UDP는 부재를 표현할 수 있었지만, 그렇다고 해서 어느 한 종단이 알 수 없는 경로와 알 수 없는 수신자를 위해 그 증거가 불필요하다고 결정할 권한이 있는 것은 아니었습니다.

IPv6가 최소한의 공통 판정을 회복하다

IPv4는 자신의 헤더는 검사했지만 UDP 페이로드는 검사하지 않았습니다. IPv6는 인터넷 계층 헤더 체크섬을 의도적으로 두지 않았습니다. 따라서 RFC 2460은 UDP의 체크섬을 의무화하고, 체크섬 필드가 0인 패킷은 수신자가 폐기하도록 지시했습니다. 전송 계층 체크섬의 의사 헤더는 IPv6 주소와 전달 맥락에 대한 보호의 일부가 되었습니다.

RFC 8200은 그 기본값을 유지합니다. IPv6 발신자는 체크섬을 계산하고 계산된 0을 16진수 FFFF로 변환합니다. 수신자는 체크섬이 0인 UDP 패킷을 폐기하며, 오류를 기록해야 합니다.

이 변경은 16비트 체크섬이 발신자를 인증한다는 주장이 아니었습니다. 그렇지 않습니다. 이는 최소한의 전달 증거가 발신자가 작업을 덜 하고 싶다는 이유만으로 사라져서는 안 된다는 결정이었습니다.

부분 커버리지는 자신이 남긴 노출을 공개하다

일부 미디어 애플리케이션은 페이로드가 아예 없는 것보다 훼손된 페이로드를 선호합니다. RFC 3828에서 표준화된 UDP-Lite는 위험이 사라졌다고 가장하지 않으면서 그 수요에 답했습니다. 애플리케이션은 부분 커버리지를 선택할 수 있지만, UDP-Lite 헤더와 IP 의사 헤더는 체크섬 안에 남습니다. 전부 0으로 전송되는 체크섬은 금지됩니다.

따라서 보호되는 영역과 보호되지 않는 영역은 명시적으로 선언됩니다. 수신자는 부분 커버리지에 옵트인하고 자체 최소치를 설정할 수 있습니다. 이 설계는 선택을 지역화하면서 “증거 없음”을 보편적 관행으로 바꾸지 않습니다.

소유자를 명명한 터널 예외

고속 터널 종단은 때로 외부 페이로드 전체를 읽지 않고 이미 보호된 패킷을 캡슐화해야 합니다. RFC 6935는 제한된 상황, 주로 터널 전송에서 IPv6가 UDP 체크섬 0을 허용하도록 갱신했습니다. RFC 6936은 그 빠진 헌법을 제공했습니다.

0 모드는 기본적으로 비활성화된 채로 유지됩니다. 애플리케이션이나 프로토콜이 송신·수신 포트를 선택합니다. 0을 받아들이는 수신 포트는 계산된 체크섬도 받아들여야 합니다. 설계자는 먼저 체크섬을 계산하는 UDP와 UDP-Lite를 고려하고, 제어 정보와 상태를 보호하며, 단편화와 훼손을 감안하고, 비관용 미들박스가 있을 수 있는 경로를 검증하며, 주입이나 과부하에 저항해야 합니다.

이 규칙들은 허가의 위치를 바꿉니다. 예외는 그 종단과 운영자가 구성하고, 감시하고, 철회할 수 있는 명명된 터널 관계에 속합니다. 모든 발신자가 공개 인터넷으로 들고 나가는 백지 수표가 아닙니다.

출처와 한계

이 역사는RFC 768,RFC 1122,RFC 2460,RFC 3828,RFC 6935,RFC 6936,RFC 8085,RFC 8200에 문서화되어 있습니다. 이들은 균일한 배포 상황이나 측정된 전 세계 오류율이 아니라, 프로토콜 규칙과 기록된 우려를 확정합니다. 체크섬은 우연한 훼손의 한 부류를 감지하며, 암호학적 인증이 아닙니다.