요약

  • IPv4 옵션 타입의 최상위 비트는 해당 옵션을 첫 번째 프래그먼트에만 넣을지, 모든 프래그먼트에 복사해야 하는지를 조각 생성자(fragmenter)에게 알려 주었습니다.
  • 프래그먼테이션은 헤더를 복제하는 것이 아니라 도출했습니다. 옵션 집합, IHL, 총 길이, 프래그먼트 오프셋, More Fragments, 헤더 체크섬은 하나의 재조합 그룹 안에서 합법적으로 달라질 수 있었습니다.
  • Copy 1은 관할권을 부여했을 뿐이며, 처리, 인증, 전달, 동일한 바이트의 도착을 보장하지 않습니다. 복사된 옵션은 서로 다른 경로에서 갈라질 수 있고, 프래그먼트 0은 복사되지 않은 상태에 대해 여전히 권위를 유지합니다.

프래그먼트는 데이터 바이트가 줄어든 복사본이 아니었다

흔히 보는 IP 프래그먼테이션 도식은 긴 페이로드가 짧은 조각들로 나뉘는 모습을 보여 줍니다. 각 조각 위의 헤더가 같다는 인상을 주기 전까지는 유용합니다. 옵션을 담은 데이터그램을 조각내는 IPv4 모듈은 단순히 자르고 복제하는 것 이상을 해야 합니다. 각 도출물이 독립적으로 이동하기 위해 어떤 네트워크 계층 의미를 필요로 하는지 해석해야 합니다.

RFC 791은 옵션의 타입 옥텟을 1비트 복사(copied) 플래그, 2비트 클래스, 5비트 번호로 나눕니다. 0은 해당 옵션이 첫 번째 프래그먼트에만 복사됨을, 1은 모든 프래그먼트에 복사됨을 의미합니다.

여기서 "첫 번째"는 구조적 용어입니다. 프래그먼트 오프셋이 0인 프래그먼트이지, 반드시 가장 먼저 도착하는 프래그먼트는 아닙니다. 그 프래그먼트는 원본 옵션 집합 전체를 운반합니다. 오프셋이 0이 아닌 프래그먼트는 Copy 비트가 분할 이후에도 컨텍스트가 따라가야 한다고 말하는 옵션만 운반합니다.

Loose Source and Record Route는 타입 131이므로 최상위 비트가 1입니다. Record Route는 타입 7이므로 최상위 비트가 0입니다. 두 옵션을 원본 헤더에 함께 넣으면 이후 프래그먼트들은 프래그먼트 0보다 짧은 인터넷 헤더 길이(IHL)를 가질 수 있습니다. 그 차이는 공통 정체성을 깨지 않습니다. 타입 문법이 요청한 결과입니다.

선택적 관할은 권위적인 IPv4 RFC보다 앞섰다

1980년 1월자RFC 760은 이미 모든 프래그먼트에 복사되는 옵션과 첫 프래그먼트에만 유지되는 옵션을 구분했습니다. 그 프래그먼테이션 절차는 다음 프래그먼트를 만들 때 인터넷 헤더를 선택적으로 복사한다고 기술했습니다.

RFC 791은 이 결정을 옵션 타입에 직접 읽히게 만들었습니다. 조각 생성자는 옵션의 우선순위를 매기기 위해 외부 권위를 필요로 하지 않았고, 지역 목록을 만들 재량도 받지 못했습니다. 객체 자신이 갖고 있는 결정적 비트를 적용하면 되었습니다.

공통 규칙은 작았지만 실행은 정확해야 했습니다. 첫 프래그먼트는 원본 헤더로 시작했습니다. 이후의 헤더는 선택적으로 구성되었습니다. 복사되지 않은 옵션을 제거하면 IHL이 바뀌고, 그 프래그먼트에 배정된 데이터가 총 길이를 바꾸고, 위치가 프래그먼트 오프셋을 바꾸고, 더 따라올 데이터가 있는지가 More Fragments를 바꾸며, 헤더가 바뀔 때마다 새 헤더 체크섬이 필요했습니다.

결과는 도출된 헤더들의 가족이었습니다. 출처와 재조합 상태는 공유하지만 모든 옵션 바이트나 필드 값을 공유하지는 않았습니다. 프래그먼테이션은 맹목적인 패킷 절단기가 아니라 좁은 사양이 제약하는 의미적 변환이었습니다.

유효한 체크섬이 유효한 상속을 증명할 수는 없었다

헤더 체크섬은 존재하는 헤더를 보호할 뿐, 도출되었어야 할 헤더를 기억하지 않습니다. 조각 생성자는 Copy-1 옵션을 실수로 빠뜨리고도 그 결함 있는 결과와 일치하는 체크섬을 계산할 수 있습니다. 첫 프래그먼트 전용 옵션을 모든 프래그먼트에 복사해 각 체크섬을 내부적으로 올바르게 만들 수도 있습니다.

이것은 두 가지 증거 질문을 분리합니다. 이 헤더는 산술적으로 온전한가? 이 헤더는 Copy 규칙에 따라 원본에서 내려온 것인가? 첫 질문만 답한 캡처는 두 번째 질문을 닫지 못한 상태입니다.

같은 경계는 재조합 정체성에도 적용됩니다. 출처, 목적지, 프로토콜, Identification 관련 상태, 오프셋과 플래그는 구현체가 지정된 규칙에 따라 조각들을 묶게 해 줍니다. 동일한 IHL이나 동일한 옵션 집합을 요구하지는 않습니다. 프로토콜이 도출을 정의하는 곳에서 동일성을 요구하는 것은 더 엄격한 검증이 아니라 잘못된 객체에 대한 검증입니다.

1이 중요하거나 0이 버려도 되는 것을 뜻하지 않았다

Strict Source and Record Route, 타입 137,과 Stream Identifier, 타입 136,은 Copy 1입니다. Timestamp, 타입 68,과 Record Route, 타입 7,은 Copy 0입니다. 이전의 Basic Security Option, 타입 130,도 Copy 1이었습니다. 이 분포는 귀한 것부터 사소한 것까지의 순위가 아닙니다.

Copy 0은 해당 옵션을 독립적으로 전달되는 각 파생물에 재현할 필요가 없다는 뜻입니다. 오프셋 0 프래그먼트에는 남아 있으며, 원본 옵션 선택 전체가 거기 보존됩니다. Copy 1은 각 파생물이 옵션을 받는다는 뜻이며, 우선순위, 신뢰성, 암호화, 인증, 무결성, 전달 확인 영수증을 추가하지 않습니다.

이 경계는 특히 Security Option에서 중요합니다. 별도의 레이블 의미는 정책에 영향을 줄 수 있지만, 복사 플래그 자체는 어떤 보안 속성도 제공하지 않았습니다. 보안 관련 옵션 하나가 사용한다는 이유로 그것을 "보안 비트"라고 부르는 것은 용기 규칙과 담긴 주장을 혼동하는 일입니다.

IANA 인터넷 프로토콜 버전 4 파라미터 레지스트리는 할당된 옵션 타입의 Copy, Class, Number, Value, Name, Reference를 기록합니다. 표준화된 할당을 증명하고 문서상의 권위를 가리킵니다. 하지만 현재의 트래픽 점유율, 제품 지원, 성공적인 처리, 옵션이 도착한 상태를 증명하지는 않습니다.

할당, 구현, 발송, 전달 중, 수신, 효과는 별개의 단계입니다. 레지스트리는 그중 첫 단계만 닫습니다.

절단 이후 복사본들은 서로 다른 이력을 가질 수 있었다

"모든 프래그먼트에 복사됨"은 쉽게 "모든 프래그먼트에서 동일함"으로 줄어듭니다. 이는 도출 순간에는 맞을 수 있지만 도착 시점은 아닙니다.RFC 815는 하나의 데이터그램 조각들이 서로 다른 경로로 이동할 수 있다고 밝힙니다. 복사된 소스 경로 및 기록 경로 옵션은 서로 다른 라우터에 의해 갱신될 수 있습니다.

그러면 옵션 버전들은 하나의 원본 상태에서 시작했음에도 기록된 경로가 다른 채 도착할 수 있습니다. Copy 비트는 각 프래그먼트가 옵션을 운반할 능력과 의무를 보존했을 뿐, 옵션 의미가 이후 노드가 쓰도록 허용하는 필드를 고정하지 않았습니다.

그가 기술한 재조합 동작에 대해 RFC 815는 첫 프래그먼트에 기록된 귀환 경로를 사용하고 나머지의 대안 버전들은 무시합니다. 경로를 병합하거나 가장 흔한 것을 고르지 않습니다. 이 규칙은 출처에 따라 권한을 배정합니다. 오프셋 0 프래그먼트의 버전을 사용하라는 것입니다.

여기에 미묘한 증거 문제가 생깁니다. 옵션을 즉시 중복 제거하는 수집기는 조각들이 갈라졌다는 증거를 지울 수 있습니다. 어떤 차이든 변조로 보고하는 수집기는 허용된 변경을 범죄로 만들 수 있습니다. 원시 조각들, 도착 순서, 재조합 선택은 서로 구분 가능해야 합니다.

복사는 인스턴스를 늘립니다. 그 자체로 조정 정책을 만들지는 않습니다. 그 정책은 적용되는 사양에서 나와야 하고 감사 기록에 드러나야 합니다.

완전한 헤더는 가장 늦게 도착할 수 있었다

RFC 815는 선택적 복사의 또 다른 결과를 지목합니다. 첫 프래그먼트가 도착하기 전까지는 최종 헤더 크기를 알 수 없을 수 있습니다. 오프셋이 0이 아닌 프래그먼트는 모든 Copy-0 옵션을 합법적으로 생략하고 더 짧은 IHL을 드러낼 수 있습니다.

그 프래그먼트가 시간상 먼저 도착하면, 그 헤더는 그 프래그먼트에 대해서는 완전하지만 원본의 증거로서는 불완전합니다. 가장 먼저 관측된 IHL을 최종으로 취급하면 네트워크 스케줄링이 권한 규칙으로 격상됩니다.

RFC 6274는 이 경계를 보안 검사로 옮깁니다. 재조합된 패킷이 주장된 전송 계층 헤더를 담을 수 있는지 판단하려면 첫 프래그먼트의 IHL이 필요합니다. 프래그먼트 0이 없으면 구현체는 예비 검사만 수행할 수 있고, 권위 있는 헤더가 도착하면 전체 검사를 적용해야 합니다.

이 잠정 상태는 되돌릴 수 있기 때문에 유용합니다. 누락된 증거가 중요하지 않은 것처럼 꾸미지 않고도 제한된 진행을 할 수 있게 해 줍니다. 위험한 최적화는 예비 계산이 아니라, 계산을 다시 수행하게 만들 조건을 버리는 것입니다.

따라서 재조합 큐는 페이로드 구간 이상을 보유합니다. 원본 헤더의 모양에 대한 미해결 주장도 함께 갖습니다.

종료와 정렬이 이 연산을 문법적으로 만들었다

End of Option List와 No Operation은 모든 옵션이 각자 Copy 선택을 가진 분리 불가능한 업무 기록이라는 거친 이야기에 맞지 않습니다. 이들은 옵션 영역을 종료하거나 정렬합니다. 복사되지 않은 옵션이 이후 헤더에서 사라질 때, 조각 생성자는 도출된 헤더가 여전히 32비트 경계에서 끝나도록 마무리와 패딩을 다시 구성해야 할 수 있습니다.

올바른 구현체는 최상위 비트가 0인 임의의 바이트를 찾아 삭제할 수 없습니다. 옵션 경계와 길이를 파싱하고, 다중 옥텟 옵션을 잘라내지 않도록 주의하며, 영역을 닫고, IHL을 갱신한 뒤 체크섬을 다시 계산해야 합니다.

알 수 없는 옵션도 여전히 구문을 갖습니다. 구현체가 모든 운영적 결과를 이해하지 못할 수 있지만, 무지가 자유로운 재해석의 허가를 주지는 않습니다. 공통 형식은 통과하거나, 타입에 따라 복사하거나, 명시적으로 실패할 수 있을 만큼의 구조를 제공합니다.

이것이 규율 있는 최소 공통 계층의 모습입니다. 공유해야 할 것만 결정하되, 그 결정을 독립된 코드가 로컬에서 검증할 수 있을 만큼 엄격하게 정의합니다.

취약한 기제가 존재하지 않았던 기제는 아니었다

RFC 8900은 옵션 결과를 직접 말합니다. 모든 IPv4 옵션은 첫 프래그먼트에 나타나고, 후속 프래그먼트에는 Copy 1 옵션만 나타난다는 것입니다. 또한 배포된 네트워크에서 IP 프래그먼테이션이 취약한 이유를 문서화합니다. 손실, 미들박스 동작, 상위 계층 헤더를 볼 수 없는 필터, 재조합 자원에 대한 압박 등입니다.

이것들은 기제와 운영적 관찰이며, 보편적인 실패 조사가 아닙니다. 이 문서는 모든 프래그먼트화된 흐름이 실패하거나, 모든 미들박스가 똑같이 동작하거나, 특정 역사적 옵션이 여전히 흔하다는 것을 증명하지 않습니다. 아키텍처적 경고를 소스가 측정하지 않은 배포 사실로 확장할 수 없습니다.

RFC 8200은 이후의 대조를 제공합니다. IPv6는 프래그먼테이션을 출처에 맡기고, 조각별 재료와 첫 조각화 가능 부분과 함께 운반되는 헤더를 다른 방식으로 분리합니다. 이 비교는 제어 경계가 이동했음을 보여 줄 뿐, IPv4의 복사 플래그를 소급적으로 무의미하게 만들지는 않습니다.

IPv4는 특정 문제를 풀어야 했습니다. 출처나 중간 라우터가 옵션을 담은 데이터그램을 나눌 수 있고, 모든 파생물이 여전히 원래 규칙에 따라 전달될 만큼의 네트워크 계층 의미를 가져야 한다는 것입니다. Copy 비트는 그 간결한 해답이었습니다.

조각 생성자가 의미의 소유자가 되지는 않았다

서두에서 라우터를 사용한 것은 중간 변환이 관할 질문을 생생하게 만들기 때문입니다. IPv4 프래그먼테이션은 패킷, 경로 MTU, Don't Fragment 상태에 따라 출처에서도 일어날 수 있습니다. 라우터를 보편화하는 것은 부정확합니다.

절단을 수행하는 자는 좁은 권한을 받습니다. 페이로드를 나누고, 재조합 필드를 유지하고, Copy에 따라 옵션 집합을 도출하고, 정렬을 복원하고, 헤더 체크섬을 다시 계산할 수 있습니다. Copy-0 옵션이 무의미하다고 선언하거나, Copy-1 옵션의 진실을 인증하거나, 하류 경로가 그것을 처리할 것을 약속할 수는 없습니다.

원본 발신자가 프로토콜의 제약 아래에서 옵션 선택을 소유합니다. 조각 생성자는 지정된 변환을 소유합니다. 이후 경로의 라우터들은 그 옵션 형식이 허용하는 처리만 소유합니다. 수신자는 정의된 출처 규칙에 따라 재조합을 소유합니다.

이 분리는 두 극단을 피합니다. 공통 계층은 모든 가능한 상태를 모든 프래그먼트에 복사할 필요가 없고, 각 구현체도 무엇이 살아남는지 결정할 재량적 권한을 받지 않습니다. 좁고 결정적인 규칙이 그 사이에 위치합니다.

캡처는 정당한 불평등을 보존해야 한다

유용한 조사는 출처, 목적지, 프로토콜, Identification, 프래그먼트 오프셋, MF, IHL, 옵션 타입, Copy 값, 도착 순서를 상호 대조합니다. 그리고 정확한 질문을 던집니다. Copy-0 옵션이 오프셋이 0이 아닌 프래그먼트에 나타났는가? 필요한 Copy-1 옵션이 사라졌는가? 옵션이 잘렸는가? 정렬이 실패했는가? 오프셋 0이 도착한 후 예비 검사가 다시 수행되었는가?

"헤더가 다르다"는 충분한 경보가 아닙니다. "모든 체크섬이 통과한다"는 충분한 통과 판정도 아닙니다. 기대되는 객체는 그 합법적 차이를 사전에 기술할 수 있는, 제약된 도출입니다.

프래그먼트 0이 없을 때 보고서는 그 부재를 증거 한계로 유지해야 합니다. "완전한 옵션 집합이 관측되지 않았다"를 "원본에 복사되지 않은 옵션이 없었다"로 바꿀 수 없습니다. 가변적인 복사 옵션이 서로 다를 때, 분석가는 먼저 그 옵션이 경로 기록을 허가했는지 검증해야 합니다.

가장 강한 기록은 잎과 나무를 모두 보존합니다. 수신된 각 프래그먼트, 그것을 원본 데이터그램과 묶는 관계, 재조합에 선택된 버전을 함께 유지합니다. 정규화된 합성 헤더는 이후 분석에 편리할 수 있지만, 그것이 도출된 증거를 대체해서는 안 됩니다.

출처와 증거 경계

소스 집합은 RFC 760, RFC 791, RFC 815,RFC 1122,RFC 1812, RFC 6274, RFC 8900, RFC 8200 및 IANA IPv4 레지스트리로 구성됩니다. 이들은 사양, 역사, 경계된 운영적 결과를 확립합니다. 현재의 옵션 유행, 보편적인 구현 적합성, 공격 발생률, 성공적인 전달, 모든 실제 경로의 동작을 확립하지 않습니다.