요약

  • IPv4의 16비트 체크섬은 헤더만 다루며, 데이터그램을 처리하고 전달하는 데 쓰이는 정보를 보호하고 페이로드 오류는 다른 메커니즘에 맡깁니다.
  • 모든 처리 지점에서 이를 검증하고 가변 필드가 바뀐 뒤에는 다시 계산하며, 이후 나온 점진적 갱신 정정은 0의 두 표현에서도 정확히 같은 1의 보수 동작을 유지했습니다.

전달 결정을 보호하는 방식

RFC 791은 체크섬을 IPv4 헤더의 모든 16비트 워드를 1의 보수 방식으로 더한 뒤 다시 1의 보수를 취한 값으로 정의합니다. 계산할 때는 체크섬 필드 자체를 0으로 취급합니다. 그 결과는 라우터가 어차피 파싱해야 하는 헤더 안의 16비트에 담깁니다.

이 범위는 의도된 것입니다. 헤더에는 데이터그램을 처리하는 데 쓰이는 목적지, 길이, 단편화 상태, 수명, 프로토콜 식별자가 들어 있습니다. RFC 791은 체크섬이 이 처리 정보가 올바르게 전송되었는지 검증한다고 규정하면서, 데이터에는 여전히 오류가 있을 수 있음을 명시적으로 허용합니다. 헤더 검사가 실패하면 이를 감지한 장치는 데이터그램을 즉시 폐기해야 합니다.

따라서 IPv4는 패킷 내용에 대한 종단 간 무결성을 주장하지 않습니다. 네트워크 계층 제어 정보, 즉 손상되면 전달을 잘못 이끌거나 헤더 자체를 모순되게 만들 수 있는 정보 주변에 방어막을 세웁니다. 페이로드 보호는 그 자리에 있는 링크, 전송 계층 또는 애플리케이션 메커니즘의 몫이며, IPv4 체크섬은 어느 것이 존재하는지에 대해 아무 말도 하지 않습니다.

고정될 수 없는 체크섬

종단 간 봉인과 달리 IPv4 헤더 체크섬은 전송 중에 정당하게 바뀝니다. 라우터가 데이터그램을 처리할 때 Time to Live가 줄어듭니다. 단편화는 새 헤더를 만듭니다. 소스 라우팅과 주소 수정은 다른 보호 대상 워드를 바꿀 수 있습니다. 그래서 RFC 791은 인터넷 헤더가 처리되는 모든 지점에서 체크섬을 다시 계산하고 검증할 것을 요구합니다.

이 규칙은 체크섬을 국소적이고 갱신 가능한 것으로 만듭니다. 라우터는 받은 헤더를 먼저 검사하고, 허용된 헤더 변경을 수행하고, 자신이 전달하는 헤더와 일치하는 체크섬을 남깁니다. 다음 처리 지점은 원본 헤더 없이도 같은 절차를 반복할 수 있습니다.

이 설계에는 비용도 드러납니다. 한 워드가 바뀐 뒤 헤더 전체의 합을 다시 계산하는 것은 단순하지만 항상 필요한 것은 아닙니다. 구현은 이전 값과 변경된 필드만으로 체크섬을 갱신할 수 있는데, 이 지름길이 처음부터 다시 계산한 것과 산술적으로 동일해야 한다는 조건이 붙습니다.

0에 숨어 있던 경계 사례

RFC 1624는 이 조건이 왜 중요했는지를 문서로 남겼습니다. 점진적 갱신은 TTL 변경, 단편화, 소스 경로 갱신 같은 일상적 작업에 유용합니다. 그러나 RFC 1141에서 표준화된 방식은 좁은 사례에서 전체 재계산과 다른 저장 체크섬을 만들어낼 수 있었습니다.

원인은 1의 보수 산술입니다. 이 산술에는 0의 두 표현, 즉 모두 0인 비트와 모두 1인 비트가 있고, 관례상 양의 0과 음의 0이라 부릅니다. 산술에 0이 하나만 있는 것처럼 보수 연산을 분배한 공식은 잘못된 표현을 선택할 수 있었습니다. 일부 검증 방식은 여전히 패킷을 수용했지만, 체크섬을 직접 계산해 저장된 필드와 비교하는 구현에서는 차이를 관찰할 수 있었습니다.

RFC 1624는 점진적 갱신 등식을 바로잡고 중간 시스템에서 이를 사용할 것을 권고했습니다. 회선상의 필드는 바뀌지 않았습니다. 바뀐 것은 지름길이 전체 재계산과 같은 체크섬을 만들도록 보장하기 위해 필요한 구현 규칙이었습니다.

출처