요약

  • RFC 1141은 IP 헤더의 한 필드가 바뀔 때 저장된 검사합을 곧바로 고치는 공식을 제시했다. 라우터가 TTL을 줄이는 경우가 익숙한 예였다.
  • RFC 1624는 그 공식이 특정 0의 경계에서 0xFFFF를 내지만 전체를 다시 계산하면 0x0000이 됨을 보이고 공식을 수정했다.

라우터는 패킷을 넘길 때 TTL을 줄인다. 헤더의 나머지 내용이 그대로라면 검사합도 변한 부분만 고치면 된다. 작은 일을 크게 만들지 말자는 발상은 좋았다. 그러나 컴퓨터가 쓰는 이 덧셈에는 0을 적는 방법이 둘이었고, 지름길은 중요한 순간에 다른 쪽을 집었다.

1988년 9월의 RFC 1071은 인터넷 검사합의 기본 작업을 설명했다. 바이트를 16비트 단어로 묶어 1의 보수 방식으로 더하고, 그 합을 뒤집은 값을 검사합 칸에 넣는다. 받는 쪽은 검사합까지 포함해 다시 더한 결과가 모두 1인지 살필 수 있다. 문서는 계산을 빠르게 하는 방법도 세세하게 다뤘다. 바이트 순서와 병렬 덧셈, 올림 처리의 지연, 메모리 복사와 계산의 결합까지 살폈다. 헤더의 한 필드만 바뀌면 차이만 반영하는 방법도 제시했다.

1990년 1월 RFC 1141은 이미 패킷에 기록된 검사합 값을 직접 바꾸는 식을 마련했다. TTL이 16비트 단어의 높은 바이트에 있을 때 하나 줄어들면 검사합 필드에 0x100을 더하는 예를 들었다. 모든 헤더 단어를 다시 훑지 않아도 되는 이점은 분명했다. 자주 일어나는 전달 작업일수록 작은 절약이 반가웠다.

문제는 1의 보수 산술이 0을 두 가지 비트 모양으로 표현한다는 점이었다. 0x0000은 양의 0, 0xFFFF는 음의 0이다. 1994년 5월 RFC 1624는 RFC 1141이 식을 정리하면서 0에서 성립하지 않는 분배 성질을 가정했다고 밝혔다. 수학 기호로는 같은 0이라고 부르기 쉬워도, 네트워크로 보내는 헤더에는 둘 중 한 비트열이 실제로 쓰인다.

RFC 1624의 예시는 계산대를 그대로 재현할 수 있다. 한 16비트 필드가 0x5555에서 0x3285로 바뀌고, 다른 헤더 단어의 합은 0xCD7A다. 원래 검사합은 0xDD2F. 새 헤더를 처음부터 계산하면 검사합은 0x0000이다. RFC 1141의 지름길은 0xFFFF를 낸다. 고친 식 HC' = ~(~HC + ~m + m')은 다시 0x0000을 만든다. 해당 IP 헤더에 0이 아닌 필드가 있으므로 전체 계산으로 검사합 칸에 0xFFFF가 나오지는 않는다.

그렇다면 잘못 적힌 쪽은 모든 수신자에게 거절당했을까. RFC 1624는 검사 방식에 따라 답이 달라진다고 했다. 검사합 필드까지 포함한 헤더 전체를 더해 모두 1인지 보는 방식은 이 예시의 두 값 모두 통과시킨다. 검사합 칸을 새로 계산해 받은 칸과 직접 비교하는 방식은 0xFFFF를 거부할 수 있다. 전달 장치의 비트 선택과 도착 장치의 판정법이 함께 결과를 만든다.

RFC 1624는 오류를 발견한 경위도 적었다. RFC 1141 알고리즘을 구현한 제품의 시험에서 이 경계 조건이 드러났고, 수정안은 시뮬레이션으로도 확인했다. 제품 이름이나 오류가 발생한 패킷 수는 제시하지 않았다. 대신 누구나 따라 계산할 수 있는 값과 실패한 식, 고친 식을 남겼다. 명령어 두 개의 비용이 걱정되는 구현을 위해 빌림을 이용한 뺄셈 형태도 설명했다.

바뀐 부분만큼 검사합을 갱신하는 생각은 계속 유용했다. 새 조건은 마지막 16비트를 정확히 써야 한다는 것이었다. 칠판 위의 쌍둥이 0은 비슷해 보였지만, 패킷을 받는 기계는 어느 쪽이 왔는지 구별할 수 있었다.