요약
- IPv4 수신자는 어떤 프래그먼트에서든 재조립 상태를 할당할 수 있습니다. 오프셋 0 프래그먼트가 도착하지 않더라도 뒤에 온 조각들이 메모리를 소모하고 최종 길이를 드러낼 수 있습니다.
- RFC 1122는 타이머가 만료되면 불완전한 상태를 폐기할 것을 요구하지만, ICMP Time Exceeded Code 1은 프래그먼트 0이 수신되어 원래 헤더가 저장된 경우에만 요구합니다.
- 그 결과 생기는 침묵은 설계상 모호합니다. 프래그먼트 0이 없었거나, 오류 보고가 억제되거나 유실되었거나, 구현이 다르게 동작했음을 의미할 수 있으며, 재조립 실패가 없었다는 증거가 될 수 없습니다.
버퍼는 실패했음을 알면서도 증언할 수는 없다
하나의 IPv4 데이터그램 조각 세 개를 수신자가 받는 상황을 상상해 봅시다. 발신 주소, 수신 주소, 프로토콜, Identification 값이 일치하므로 수신자는 이들을 하나의 재조립 컨텍스트에 넣습니다. 한 조각은 More Fragments 플래그가 지워져 있어 데이터그램이 끝나야 할 지점을 드러냅니다. 오프셋에는 빈틈이 있습니다. 집합이 불완전하다는 것을 알 정보도 있고, 메모리를 차지할 데이터도 있지만, 오프셋 0에서 시작하는 조각은 없습니다.
재조립 메커니즘은 프래그먼트가 번호 순서대로 도착할 것을 요구하지 않습니다. 마지막 조각이 첫 조각보다 먼저 올 수 있습니다. 가운데 조각이 관찰된 첫 패킷일 수 있습니다. 유실이 시작 부분만 제거하고 이후의 모든 조각은 목적지에 도달하게 할 수 있습니다. 따라서 수신자는 두 종류의 상태를 필요로 합니다: 도착한 바이트들, 그리고 아직 없는 내용에 대한 기술.
대기 구간이 만료되면 수신자에게는 명확한 로컬 사실이 있습니다: 이 컨텍스트는 제시간에 완전한 데이터그램이 되지 못했다. IPv4는 그 사실이 메모리를 영원히 붙잡게 두지 않습니다. 부분 객체는 파괴되어야 합니다. 그러나 파괴와 통지는 다른 작업입니다. 첫째는 수신 시스템을 보호합니다. 둘째는 원격 발신자를 위한 증거를 구성하며, 그 증거 계약은 더 엄격한 전제 조건을 갖습니다.
그 전제 조건이 프래그먼트 0입니다.
재조립은 첫 바이트가 아니라 식별자에서 시작한다
RFC 791은 재조립 버퍼를 네 값으로 식별합니다: 발신 주소, 수신 주소, 상위 계층 프로토콜, 그리고 16비트 Identification 필드. 프래그먼트의 오프셋은 수신자에게 그 데이터가 어디에 속하는지 알려 줍니다. 오프셋 0은 첫 프래그먼트를, 지워진 More Fragments 플래그는 마지막 프래그먼트를 표시합니다. 이 두 사실은 서로 다른 패킷으로 도착할 수 있습니다.
예시 절차는 명시적입니다. 프래그먼트가 기존 컨텍스트에 속하지 않으면 수신자는 재조립 자원을 할당합니다. 데이터를 오프셋이 가리키는 위치에 복사하고 해당 블록을 존재함으로 표시합니다.FO = 0일 때만 헤더를 별도의 헤더 버퍼에 넣습니다. 프래그먼트에MF = 0이 있어야만 전체 데이터 길이를 계산할 수 있습니다. 완성은 알려진 끝과, 시작부터 그 끝까지 끊기지 않은 수신 블록 집합, 둘 다를 요구합니다.
이렇게 하면 프래그먼트 0은 특별해지지만 시간적으로 첫 번째가 되지는 않습니다. 나중 프래그먼트가 컨텍스트를 열 수 있습니다. 마지막 프래그먼트가 목표 길이를 정의할 수 있습니다. 둘 다 원래 데이터그램의 시작을 제공하지 않습니다. 따라서 재조립 상태는 수신자가 원래 패킷을 발신자에게 돌려 설명하는 데 쓸 재료를 갖기 전에도 존재할 수 있습니다.
이 구분이 중요한 이유는 부분 상태에 실제 비용이 있기 때문입니다. RFC 791의 예시는 데이터 버퍼, 헤더 버퍼, 수신 블록 표, 전체 길이 필드, 타이머를 할당합니다. 프래그먼트는 단순한 통계를 남기지 않습니다. 전체가 도착하거나 수신자가 포기할 때까지 유한한 메모리에 대한 청구권을 만듭니다.
첫 타이머는 TTL로부터 시계를 빌렸다
1981년 사양은 재조립 타이머를 도착하는 프래그먼트들의 Time to Live 값에 묶었습니다. 15초의 초기 하한을 제안했습니다. 다른 프래그먼트가 도착할 때마다 타이머는 현재 값과 그 프래그먼트의 남은 TTL 중 큰 값이 되었습니다. 더 작은 TTL은 대기를 줄일 수 없었고, 더 큰 TTL은 필드의 최대값 방향으로까지 대기를 늘릴 수 있었습니다.
문서는 자원 등식도 직접 밝힙니다: 데이터 전송률 곱하기 타이머 값은 버퍼 용량과 같다. 이것은 구현 각주가 아닙니다. 타임아웃 안에 숨겨진 정책을 드러냅니다. 더 긴 대기는 지연된 프래그먼트를 허용하지만 불완전한 컨텍스트가 더 오래 메모리를 점유하게 합니다. 더 짧은 대기는 메모리를 더 빨리 회수하지만 누락된 조각이 단지 지연되었던 데이터그램을 파괴할 수 있습니다.
원래 설계는 TTL이 경과 시간의 증거가 될 수 있다고 다루었습니다. 배포는 그 가정을 점점 더 약하게 만들었습니다. 라우터들은 TTL을 네트워크에서 보낸 정확한 초가 아니라 홉 수로 감소시키는 것이 일반적이 되었습니다. 따라서 남은 필드에서 대기 정책을 도출하는 수신자는 경로 길이와 시간을 섞어 어느 쪽도 신뢰할 수 있게 기술하지 않는 값을 얻게 됩니다.
ICMP는 시작 부분을 증거의 닻으로 만들었다
RFC 792는 ICMP Time Exceeded Type 11을 정의했습니다. Code 0은 전송 중 TTL 만료를 보고합니다. Code 1은 호스트에서 프래그먼트 재조립 시간 초과를 보고합니다. 메시지는 원래 IP 헤더와 원래 데이터의 처음 64비트를 포함하며, 사양은 이것이 발신원이 실패를 적절한 프로세스와 연관 짓는 데 도움이 될 것으로 기대했습니다.
그 인용은 나중에 도착한 프래그먼트가 아니라 원래 데이터그램의 시작에 관한 것입니다. 같은 RFC는 ICMP 오류가 프래그먼트 0 처리의 오류에 관한 것이라는 일반 규칙을 세웁니다. 재조립에 관해서는, 누락된 프래그먼트가 시간 한도 내 완성을 막으면 호스트가 Time Exceeded를 보낼 수 있지만 프래그먼트 0이 없다면 그런 보고를 보낼 필요가 없다고 말합니다.
나중 프래그먼트는 익명이 아닙니다. 그 IPv4 헤더에는 여전히 재조립 컨텍스트를 찾는 데 필요한 필드들이 들어 있습니다. 규칙은 더 좁습니다: 0이 아닌 프래그먼트는 ICMP 오류의 호출(invoking) 패킷 대용으로 받아들여지지 않습니다. 프래그먼트 0이 없으면 수신자는 프로토콜이 승인한 원래 시작과 그 첫 데이터 비트를 갖지 못합니다. 자신의 상태를 해제할 수는 있지만, 더 약한 인용을 만들어 발신자의 진단 증거로 내놓을 의무는 없습니다.
이 선택은 유혹적이지만 해로운 축약을 피합니다. 발신 주소를 아는 것과 오류 형식이 약속한 원래 컨텍스트를 소유하는 것은 다릅니다. 답장을 보낼 수 있다는 것과 답장의 주장을 뒷받침할 수 있다는 것은 다릅니다.
효율적인 장부 관리가 증거 문제를 해결하지는 못했다
RFC 815는 재조립 장부 관리가 우아할 수 있음을 보여 주었습니다. 수신된 모든 블록을 기록하는 대신 구현은 남아 있는 구멍에 대한 기술자를 유지할 수 있습니다. 새 프래그먼트는 구멍을 줄이거나, 하나를 둘로 나누거나, 없앨 수 있습니다. 구멍이 남지 않으면 데이터그램이 완성된 것입니다.
이 알고리즘은 순서가 뒤바뀐 도착에서도 작동했습니다. 그것은 또한 헤더 문제와 마주했습니다: 일부 IPv4 옵션은 모든 프래그먼트에 복사되지만 다른 것들은 첫 프래그먼트에만 나타납니다. 첫 프래그먼트가 도착하기 전까지 수신자는 최종 원래 헤더 구성을 알 수 없습니다. 문서는 실용적인 버퍼 배치를 제안했지만 중심 기여는 효율적인 완성 감지였습니다.
효율성은 없어진 증거를 만들어 낼 수 없습니다.RFC 1122는 Clark의 알고리즘을 권고한 뒤 의미심장한 정정을 추가했습니다: RFC 815의 서술과는 달리, 첫 프래그먼트 헤더는 ICMP Time Exceeded 재조립 시간 초과 메시지에 포함될 가능성을 위해 저장되어야 한다. 헤더는 더 이상 성공적으로 재구성된 데이터그램을 전달하는 데 필요한 재료에 그치지 않았습니다. 재구성이 실패했음을 설명하기 위해 유지되는 근거이기도 했습니다.
호스트 요구사항은 두 개의 시계를 분리한다
RFC 1122는 타이머 규칙을 명시적으로 만들고 그 권위의 출처를 바꾸었습니다. IPv4 호스트는 재조립을 구현해야 하고 재조립 타임아웃을 가져야 합니다. 값은 남은 TTL에서 도출되기보다 고정되어야 합니다. 문서는 60~120초를 권고하며, 너무 작은 값은 지연된 정상 트래픽을 폐기할 수 있고 너무 큰 값은 버퍼 자원을 불필요하게 묶어 둔다고 설명합니다.
규범적 결과는 두 절로 이루어집니다. 타임아웃이 만료되면 부분적으로 재조립된 데이터그램은 폐기되어야 합니다. 프래그먼트 0이 수신된 경우에는 ICMP Time Exceeded 메시지가 발신원에게 전송되어야 합니다.
그 괄호가 바로 아키텍처입니다. 메모리 안전은 보고 허가를 기다리지 않습니다. 증거는 메모리가 소모되었다는 이유만으로 의무가 되지 않습니다. 하나의 의무는 만료 시 무조건적이고, 다른 하나는 적법한 호출 프래그먼트의 소유에 조건부입니다.
60~120초 권고는 현재 커널에 대한 조사가 아니라 역사적 사양 증거입니다. 보편적인 현재 기본값으로 인용해서는 안 됩니다. 여기서 그 가치는 개념적입니다: 수신자가 로컬 대기 정책을 소유하며, 그 정책은 배포된 의미가 홉 수가 되어 버린 TTL 필드에 위임될 수 없다는 것입니다.
라우터는 패킷이 라우터 자신을 위한 것일 때만 역할을 바꾼다
프래그먼테이션 언어는 모든 네트워크 장치가 재조립자처럼 들리게 만들 수 있습니다.RFC 1812는 역할 경계를 정확하게 유지합니다. 통과 패킷을 전달하는 라우터는 그들을 계속 전달하기 위해 통상 재구성하지 않습니다. 프래그먼트화된 패킷이 라우터 자신을 향하고 라우터가 그것을 재조립한다면, 라우터는 인터넷 호스트로 행동하며 호스트 요구사항을 따릅니다.
라우터 요구사항은 또한 첫 프래그먼트가 아닌 프래그먼트에 대한 ICMP 오류 응답의 금지를 유지합니다. 그 제한은 다른 오류 생성 요구사항보다 우선합니다. 이 규칙은 경로상의 모든 장치가 같은 프래그먼트 상태를 유지한다고 추론하라는 초대가 아닙니다. 그것은 목적지 쪽 재조립 컨텍스트를 소유한 노드를 다룹니다.
타이머는 식별자 지평선도 점유한다
불완전한 바이트들이 긴 대기로 유지되는 유일한 상태는 아닙니다. 프래그먼트는 유한한 Identification 필드와 발신, 수신, 프로토콜을 함께 사용해 연관됩니다. 오래된 프래그먼트가 여전히 존재할 수 있는 상태에서 새 데이터그램이 같은 튜플을 재사용하면 조각들이 혼동될 수 있습니다.
RFC 6864는 이후 재조립 타임아웃, 최대 데이터그램 수명, Identification 값이 모호하지 않아야 하는 구간 사이의 관계를 기술했습니다. 요점은 하나의 타이머 값이 자동으로 재사용을 안전하게 만든다는 것이 아닙니다. 유지 정책이 메모리와 작은 이름공간에서의 식별자 주장의 지속 기간 둘 다에 영향을 미친다는 것입니다.
이 글은 IPv4 Identification의 더 넓은 역사를 반복하지 않습니다. 하나의 한정된 결과를 위해 이 연결을 사용합니다: 재조립 대기를 늘리는 것은 바이트와 모호성 둘 다를 더 오래 열어 둠으로써 지연에 대한 관용을 산 것입니다.
침묵은 관찰이지 판결이 아니다
Code 1을 받은 발신자는 유용하지만 좁은 증거를 갖습니다. 목적지 쪽 재조립자가 불완전한 데이터그램을 타이머 만료까지 유지했고 원래 시작을 인용할 만큼 충분히 프래그먼트 0을 소유하고 있었다고 말하는 것입니다. 이 보고는 어떤 프래그먼트가 유실되었는지, 누가 유실시켰는지, 방화벽이 개입했는지, 같은 경로가 다시 실패할지 식별하지 않습니다.
아무것도 받지 못한 발신자는 더 적게 압니다. 프래그먼트 0이 목적지에 도달하지 않았을 수 있습니다. 목적지가 ICMP를 억제하거나 속도 제한했을 수 있습니다. 오류가 반환 경로에서 유실되거나 필터링되었을 수 있습니다. 구현이 다른 동작을 할 수 있고, 관찰 지점이 단지 놓쳤을 수 있습니다. 침묵은 재조립이 완료되었거나 프래그먼트가 도착하지 않았다는 증명으로 승격될 수 없습니다.
이 모호성은 더 자신감 있는 대시보드로 수리할 수 있는 결함이 아닙니다. 그것은 증거 경계에서 비롯됩니다. 수신자의 로컬 처분은 수신자 내부에서만 신뢰할 수 있습니다. 원격 증언은 조건부이며, 원래 데이터그램의 일부를 잃어 버린 바로 그 불완전한 네트워크에 의해 운반됩니다.
출처와 증거 한계
- RFC 791 — Internet Protocol
- RFC 792 — Internet Control Message Protocol
- RFC 815 — IP Datagram Reassembly Algorithms
- RFC 1122 — Requirements for Internet Hosts — Communication Layers
- RFC 1812 — Requirements for IP Version 4 Routers
- RFC 6864 — Updated Specification of the IPv4 ID Field
이 RFC들은 프로토콜 규칙, 알고리즘, 명시된 설계 절충을 확립합니다. 그것들은 현재 구현 기본값, IPv4 프래그먼테이션 비율, Code 1 전달, 필터링, 준수 여부를 측정하지 않습니다. 특정 공급업체나 실제 네트워크에 대한 추론은 표준 문서만으로 이루어지지 않습니다.
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





