요약

  • RFC 791은 Total Length를 헤더와 데이터를 모두 포함한 옥텟 단위의 전체 IPv4 데이터그램 길이로 정의합니다. IHL은 그 데이터가 어디서 시작하는지 별도로 알려줍니다.
  • RFC 894는 이 설계상 이득을 명확히 드러냅니다. 짧은 IP 패킷보다 이더넷 패딩이 더 길어질 수 있지만, 그 패딩 옥텟은 패킷의 일부가 아니며 Total Length에서 제외됩니다.

짧은 IPv4 데이터그램은 이더넷에서 의외로 많은 것을 드러내는 문제를 낳습니다. 링크 계층은 데이터 필드의 끝이 IP 패킷의 끝과 정확히 일치하는 프레임을 항상 전송할 수는 없습니다. RFC 894는 이더넷 데이터 필드가 최소 46옥텟이어야 한다고 요구하므로, 그보다 짧은 IP 데이터그램 뒤에는 0으로 채운 패딩이 붙어야 합니다. 수신 측은 따라서 네트워크 계층 패킷이 실제로 소유한 옥텟보다 많은 옥텟을 담은 프레임을 보게 됩니다.

IPv4 헤더는 패킷 내부에서 이 분쟁을 해결합니다. 16비트 Total Length 필드는 IP 헤더와 데이터를 합산한 옥텟 단위 데이터그램 길이를 선언합니다. RFC 894는 이더넷이 덧붙인 패딩이 그 길이 밖에 있음을 명시합니다. 프레임은 운반을 담당하고, 데이터그램은 자기 경계를 스스로 밝힙니다.

하나의 페이로드를 정의하는 두 가지 측정

RFC 791은 IPv4에 서로 다른 두 가지 길이 표현을 부여합니다. Internet Header Length(IHL)는 헤더를 32비트 워드 단위로 셉니다. 최솟값은 5이며, 이는 옵션이 없는 보통 헤더가 20옥텟임을 의미합니다. Total Length는 전체 데이터그램을 옥텟 단위로 셉니다. 이 두 필드를 합하면 데이터의 양쪽 끝을 모두 찾을 수 있습니다. 데이터는 IHL 뒤에서 시작해 Total Length까지 이어집니다.

이 구분 덕분에 페이로드 길이를 세 번째 독립 필드로 만들 필요가 없었습니다. 헤더 길이와 전체 데이터그램 길이를 알면 데이터 길이는 뺄셈으로 구해집니다. 옵션이 헤더를 늘리면 IHL이 시작 경계를 옮기고 Total Length는 여전히 최종 경계를 표시합니다. 두 측정값은 모두 자신이 기술하는 패킷 안에 함께 담겨 이동합니다.

Total Length가 헤더까지 세는 방식은 처음에는 데이터만 세는 것보다 직관적이지 않아 보일 수 있습니다. 그러나 전체 길이야말로 이식 가능한 측정입니다. 하나의 데이터그램은 프레임 헤더, 트레일러, 최소 크기, 전송 한도가 서로 다른 여러 링크 기술을 거칠 수 있습니다. 그 어떤 포장도 IPv4가 자기 바이트로 여기는 대상을 바꾸지 못합니다. 네트워크 계층은 모든 둘러싼 매체로부터 크기를 추론하는 대신, 하나의 자기 한정적 객체를 검증하고 처리할 수 있습니다.

이더넷에 속했던 바이트들

이더넷은 바깥 페이로드 크기에 의존하면 왜 실패하는지 보여줍니다. RFC 894는 이더넷 데이터 필드에서 IP 헤더 바로 뒤에 IP 데이터가 이어진다고 규정합니다. 그 뒤이어 이 필드가 46옥텟보다 짧아질 경우, 이더넷 최소 프레임 크기를 맞추기 위해 0 패딩을 추가해야 한다고 말합니다. 결정적으로, 이 명세는 그 0들을 IP 패킷 밖에, IPv4 Total Length 밖에 둡니다.

옵션 없는 IPv4 데이터그램이 단 몇 옥텟의 데이터만 담는 경우를 가정해 봅시다. IHL은 첫 번째 데이터 옥텟을 식별하고, Total Length는 마지막 IP 옥텟을 식별합니다. 이더넷 데이터 필드에 남는 옥텟은 링크 패딩이며, 전송 계층 세그먼트나 다른 캡슐화된 프로토콜의 일부가 아닙니다. 이 내부 끝점이 없다면 수신 측은 뒤따르는 0들 중 어느 것이 의미 있는 것인지 판단하기 위해 매체별 가정이 필요해집니다.

이 필드는 물리적 프레임의 전체 크기를 드러내지 않습니다. 이더넷 주소, 타입 필드, 검사값, 프리앰블 등 다른 링크 장치들을 세지도 않습니다. 그 권한은 더 좁고 더 유용합니다. 이더넷 페이로드로 위로 전달되는 바이트 가운데 몇 개가 이 IPv4 데이터그램에 속하는지를 밝힙니다.

하나의 상한, 여러 실질 한도

16비트는 Total Length가 65,535옥텟까지의 값을 표현하게 합니다. RFC 791은 바로 이 산술적 최댓값에 단서를 달아, 그런 긴 데이터그램은 대부분의 호스트와 네트워크에 비실용적이라고 말합니다. 또한 목적지가 576옥텟까지의 데이터그램을, 통째로 오든 조각으로 오든 받을 준비를 해야 한다고 요구하고, 그보다 큰 데이터그램은 목적지가 받을 수 있음을 확신할 때만 보내라고 권고합니다.

이 구분은 표현과 전달을 나눕니다. 어떤 형식은 특정 링크가 한 프레임으로 옮길 수 있는 크기보다 큰 데이터그램을 기술할 수 있습니다. RFC 894는 이더넷에서 실려 가는 IP 데이터그램의 최댓값을 1,500옥텟으로 정하고, 그 이더넷을 떠나는 트래픽은 더 넓은 인터넷의 더 작은 전제와 마주칠 수 있음을 언급합니다. 따라서 헤더의 65,535옥텟 어휘는 경로 MTU도, 권장 패킷 크기도, 수신자 용량의 보장도 아닙니다.

이러한 분리 덕분에 네트워크 매체가 바뀌어도 Total Length는 안정적으로 남을 수 있었습니다. 이 필드는 객체의 크기를 말하고, 다른 메커니즘이 다음 링크가 그 객체를 하나의 단위로 옮길 수 있는지를 결정합니다. 이 두 질문을 섞었다면 IPv4의 기본 문법이 한 링크 기술의 포장에 묶였을 것입니다.

단편화 이후에도 같은 측정

단편화는 패킷을 바꾸지만 측정 규칙은 유지합니다. RFC 791의 절차는 각 조각에 헤더를 부여하고 그 조각의 Total Length를 자기 헤더와 조각 데이터의 합으로 설정합니다. 조각에 담긴 값은 단편화되기 전 원본 데이터그램의 길이가 아닙니다. 현재 전달되고 있는 IPv4 객체의 전체 길이입니다.

다른 필드들은 각자 다른 역할을 맡습니다. Identification은 같은 원본 데이터그램에서 나온 조각들을 연관시키는 데 도움을 줍니다. Fragment Offset은 조각의 데이터가 재조립 공간 안에서 차지하는 위치를 정합니다. More Fragments는 다음 조각이 더 있는지 알려줍니다. Total Length는 수신자에게 이 특정 조각이 어디서 끝나는지를 말합니다. 이 메커니즘들은 협력하지만, 어느 하나도 다른 것을 대신할 수 없습니다.

재조립 시점에서는 마지막 조각의 오프셋과 데이터 길이가 원본 데이터의 범위를 확정하는 데 도움이 됩니다. 여기서도 조각 자신의 전체 길이와 헤더 길이를 알 수 있기 때문에 유용한 값이 복원됩니다. Total Length는 수신자가 조각이 속한 더 큰 객체를 추론하기 전에 일관된 국소 경계를 제공합니다.

경계이지 증명이 아니다

선언된 길이는 비정상일 수 있습니다. 패킷은 잘릴 수 있고, 구현에는 버그가 있을 수 있으며, 하위 계층은 서로 모순되는 데이터를 보고할 수 있습니다. 인용된 명세들은 그런 실패가 얼마나 자주 발생했는지, 현대의 오프로드 하드웨어와 캡처 도구가 그것을 어떻게 드러내는지 측정하지 않습니다. Total Length는 수신된 바이트를 해석할 수 있는 기준 규칙을 제공할 뿐, 그 바이트를 인증하거나 선언된 모든 옥텟이 온전히 도착했음을 보장하지는 않습니다.

또한 이 필드는 애플리케이션 레코드를 식별하지 않습니다. 그 데이터는 전송 계층 헤더와 상위 계층 메시지의 일부만 담고 있을 수도, 여러 개의 상위 계층 단위를 담고 있을 수도 있습니다. 패킷 경계는 IPv4에 속합니다. 전송 계층과 애플리케이션 프로토콜은 필요한 곳에서 자기 경계와 길이 규칙을 유지합니다.

이 설계의 오래된 교훈은 계층 간 권한에 관한 것입니다. 이더넷은 프레임 규약을 만족하려고 패딩을 더할 수 있습니다. 이후의 링크는 다른 전송 한도를 부과할 수 있습니다. 단편화는 하나의 원본 데이터그램을 여러 개의 새 IPv4 객체로 쪼갤 수 있습니다. 그 어떤 변화 속에서도 Total Length는 헤더를 포함해 현재 IP 패킷이 소유를 주장하는 옥텟이 무엇인지 계속 말합니다. IPv4는 프레임에게 패킷을 정의해 달라고 하지 않았습니다. 경계를 몸에 지니고 다녔습니다.

출처