요약

  • RFC 894는 EtherType0800이 IPv4를 선택하도록 하고, 이더넷 데이터 필드가 46옥텟보다 짧아지는 경우 제로 패딩을 요구했으며, 추가된 바이트가 IP 패킷과 IPv4 Total Length 필드 어느 쪽에도 속하지 않도록 유지했습니다.
  • 이 구분으로 두 가지 유효한 측정이 동시에 성립했습니다. 수신자는 링크가 실제 전달한 페이로드를 저장해야 했지만, IP 파싱은 Total Length에서 멈춰야 했습니다. 이후 RFC 6274는 이 중첩 관계를 명시하고, 링크가 전달한 바이트가 IP가 주장하는 양보다 적으면 폐기하도록 요구했습니다.
  • IP 의미가 없는 바이트가 위험 없는 것은 아니었습니다. CERT/CC는 일부 드라이버가 오래된 버퍼 내용을 패딩으로 재사용하여, 데이터그램에서 제외된 접미사도 여전히 메모리 내용을 회선상에 노출할 수 있음을 문서화했습니다. 해당 RFC 자체의 "minimum 1500" 오타 역시 원문과 검증된 정정이 서로 구별되는 증거로 남아야 하는 이유를 보여줍니다.

캐리어에는 IP가 만들지 않은 바이트가 필요했다

가장 작은 보통의 IPv4 헤더를 생각해 보십시오. 20옥텟이고 페이로드가 없습니다. 이더넷의 46옥텟 최소 데이터 필드는 여전히 26옥텟을 설명해야 합니다. 이 바이트들은 애플리케이션이 제공하지 않았기 때문에 발명된 애플리케이션 데이터일 수 없습니다. 발신자가 IP Total Length 필드에 20을 썼기 때문에 IP 데이터그램을 키우는 것도 아닙니다. 그러나 최소 프레임 크기를 충족하려면 링크가 이를 생략할 수도 없습니다.

1984년 4월에 발표된RFC 894는 소유권 문제를 직접 해결했습니다. IP 데이터그램은 타입 필드에 16진수0800을 담은 표준 이더넷 프레임으로 전송되었습니다. 데이터 필드는 IP 헤더로 시작하여 바로 IP 데이터가 이어졌습니다. 이 필드가 46옥텟보다 짧아지면 발신자는 0(제로) 옥텟을 추가했습니다. 문서는 이어서 추가된 접미사의 IP 소속을 부정하고 Total Length에서 제외했습니다.

이는 관찰된 하나의 길이를 모든 계층의 진실로 취급하는 것보다 강한 설계입니다. 이더넷은 물리적 컨테이너를 보고했습니다. IPv4는 그 안의 프로토콜 객체를 기술했습니다. 컨테이너가 더 길어도 객체는 변하지 않습니다.

RFC 791은 이미 내부 자를 정의해 두었습니다. Total Length는 IP 헤더와 IP 데이터를 포함하여 데이터그램을 옥텟 단위로 측정합니다. IHL은 헤더를 32비트 워드 단위로 별도로 측정하므로 데이터 시작 위치를 알려줍니다. 이 두 필드는 이더넷 패딩을 고려하기 전에 경계가 정해진 객체를 정의합니다. 헤더는 데이터그램 안에 들어가야 하고, 데이터그램은 그다음 더 큰 링크 페이로드 안에 들어갈 수 있습니다.

0800은 문법을 선택했을 뿐, 옥텟을 세지 않았다

외부 2옥텟 필드는 이더넷과 IEEE 802.3 프레임이 하나의 케이블을 공유하면서 또 다른 역사적 부담을 떠안게 되었습니다. 이 필드는 같은 위치를 차지했지만, 한 프레이밍은 이를 프로토콜 타입으로, 다른 프레이밍은 길이로 다루었습니다.

RFC 1122는 1989년 이 수치적 구분을 기술했습니다. 802.3 길이는 1500 이하였고, 유효한 EtherType 값은 1500을 넘었습니다. 16진수0800은 10진수 2048입니다. 따라서 이 값은 수신자에게 뒤따르는 바이트를 IPv4로 해석하라고 알려줄 뿐, 2048옥텟 프레임을 알리는 것이 아니었습니다.

권위의 순서가 중요합니다. 외부 값이 먼저 문법을 선택합니다. IPv4가 선택되면 IPv4 헤더 내부의 Total Length 필드가 그 데이터그램의 끝을 지정합니다. 수신자는 더 많은 바이트가 도착했다는 이유만으로 링크 버퍼의 끝을 대용으로 사용하지 않습니다.

RFC 1122는 또한 이 공존 정책을 호스트 요구사항으로 만들었습니다. 10 Mb/s 이더넷 케이블의 호스트는 RFC 894 형식을 송수신해야 했습니다.RFC 1042에서 규정된 IEEE 802 형식은 수신해야 했고(should), 전송할 수도 있었습니다(may). 이중 전송자는 기본값이 RFC 894인 구성 선택이 필요했습니다. 공통 물리 매체가 두 표현을 서로 바꿔 쓸 수 있게 만들지는 않았습니다. 수신자는 올바르게 선택할 충분한 근거가 필요했습니다.

바깥의 여덟 옥텟은 MTU를 바꿨을 뿐, 데이터그램의 구성을 바꾸지 않았다

RFC 1042는 IP를 IEEE 802.2 LLC와 SNAP 위에 실었습니다. LLC와 SNAP 헤더가 합쳐 8옥텟을 차지했고, SNAP의 마지막 16비트는 익숙한 EtherType을 유지했습니다. IP는 2048, ARP는 2054였습니다. 최소 크기 패딩은 여전히 0으로 채워졌고 여전히 IP Total Length 밖에 있었습니다.

이 문서는 그 맥락에서 최소 IP 패킷을 28옥텟으로 기술했습니다. 20옥텟 최소 IP 헤더에 LLC와 SNAP의 8옥텟을 더한 값으로, MAC 헤더는 제외합니다. 이 숫자는 이더넷의 46옥텟 최소 데이터 필드가 아닙니다. 두 값은 서로 다른 회계 질문에 답합니다.

이후 RFC 1122는 이더넷 MTU 1500과 802.3 MTU 1492를 제시했습니다. 8옥텟 차이는 LLC/SNAP 추가 운반을 반영한 것입니다. 이는 구현이 IPv4 헤더에서 8옥텟을 제거하거나, 링크 패딩을 Total Length에 포함하거나, 외부 오버헤드를 애플리케이션 데이터로 취급할 권한을 부여하지 않습니다.

자매 문서인RFC 895는 이 불변 규칙을 더 분명하게 보여줍니다. 그 대상은 8비트 주소를 쓰는 더 오래된 3 Mb/s 실험용 이더넷이었습니다. 타입 값과 1536옥텟 최대값은 RFC 894와 달랐습니다. 그러나 패딩 규칙은 같았습니다. 링크 최소 크기를 채우는 데 필요한 바이트는 여전히 IP Total Length 밖에 있었습니다. 이 불변성은 특정 마법의 이더넷 크기가 아니라 계층 간 인계에 속했습니다.

하나의 오타가 표준 안에 증거 경계를 만들었다

RFC 894의 원문에는 1500옥텟을 이더넷 데이터 필드의 "최소(minimum)" 길이라고 부르면서 같은 문장에서 최대 IP 데이터그램 1500을 도출하는 문장이 있습니다. 앞 단락은 이미 실제 최소값을 46으로 제시했습니다. 이 단어는 기술적으로 중요한 결과를 낳고 내부적으로도 불가능합니다.

RFC Editor의 검증된 기술정오표 570은 "minimum"을 "maximum"으로 고칩니다. 2001년에 보고되었습니다. 2017년에 보고되어 2024년에 검증된정오표 5141도 같은 정정을 기록합니다. 나중 날짜는 새 이더넷 한계를 뜻하지 않습니다. 정정 장부에 기록된 또 하나의 검토된 항목을 뜻합니다.

현재의RFC Editor 정오표 정책은 증거의 양쪽을 모두 보존합니다. 발행된 RFC는 변경되지 않습니다. 검증된 정오표는 정확한 것으로 간주되지만 TXT, PDF, XML 출판 형식에 반영되지는 않습니다. 독자는 무엇이 인쇄되었는지 알기 위해 불변 기록이 필요하고, 문장을 어떻게 해석해야 하는지 알기 위해 검증된 정오표가 필요합니다.

로컬 사본을 조용히 고쳐버리면 단락은 매끄러워지지만 출처 추적성이 약해집니다. 인쇄된 실수를 물리적 진실로 취급하면 출처는 보존되지만 공학적 판단은 버려집니다. 올바른 답은 한쪽 기록을 선택해 다른 쪽을 없애는 것이 아니라 원문과 정정을 연결해 함께 유지하는 것입니다.

패딩은 트레일러 캡슐화가 아니었다

같은 1984년 4월의 다른 메모도 이더넷 패킷 끝 부근의 바이트를 다루었기 때문에 이 구분은 잃기 쉽습니다.RFC 893은 트레일러 캡슐화를 다루었는데, 이는 가변적인 상위 계층 헤더를 데이터 뒤로 의도적으로 옮겨 적합한 수신자의 정렬을 개선하는 방식이었습니다. 이는 수신자 지원과 이후 피어별 규율을 요구하는 대안적 링크 표현이었습니다.

RFC 894의 패딩은 그중 어느 것도 하지 않았습니다. IPv4 헤더는 그대로 첫머리에 있었습니다. IP 데이터가 그 뒤를 이었습니다. 0 접미사는 링크가 더 많은 물리적 길이를 필요로 할 때만 추가되었습니다. 수신자는 재정렬된 헤더를 재구성하지 않았습니다. 다만 Total Length가 지명한 앞선 끝을 단순히 존중했습니다.

따라서 이 글은 패드를 트레일러, IP 옵션 또는 FCS로 취급하지 않습니다. 각각은 끝 경계 근처에 나타날 수 있지만, 각각은 서로 다른 문법에 속하고 서로 다른 권한을 가집니다.

수신자는 동시에 두 개의 길이가 필요했다

2011년RFC 6274는 원래 경계의 보안 결과를 표현했습니다. IP 모듈은 IP Total Length보다 큰 링크 페이로드를 받을 수 있었습니다. 정당한 링크 패딩이 흔한 이유였지만, 악의적 활동도 가능했습니다.

그 문서는 더 작은 IP Total Length가 아니라 링크 계층이 보고한 페이로드 크기에 따라 메모리 버퍼를 할당하라고 조언했습니다. 이는 접미사를 IP로 승격시키지 않았습니다. 프로그램이 확보한 저장 공간보다 큰 컨테이너를 받는 상황을 막았습니다.

파싱에는 반대 규율이 필요했습니다. IHL에 4를 곱한 값은 Total Length보다 클 수 없었습니다. 링크가 넘겨준 바이트 수는 최소 Total Length 이상이어야 했습니다. 외부 페이로드가 내부의 IP 주장보다 짧으면 패킷은 폐기되고 이벤트가 기록되어야 했습니다.

그 결과로 나오는 관계는 비대칭입니다:

IHL × 4 <= IP Total Length <= 링크 계층 페이로드 크기

첫 경계에서의 등식은 IP 페이로드가 없는 데이터그램에서 가능합니다. 두 번째 등식은 보이는 패딩이 없을 때 가능합니다. 어느 등식도 필수는 아닙니다. 필수인 것은 내부 객체가 컨테이너 안에 들어가야 한다는 점입니다.

IP에 무의미하다고 정보가 없다는 뜻은 아니었다

제로 요구사항은 기밀성 통제이기도 했습니다. 2003년 1월,CERT/CC 취약점 노트 VU#412115는 많은 네트워크 장치 드라이버가 널 옥텟을 쓰는 대신 오래된 프레임 버퍼 데이터를 재사용해 짧은 프레임을 패딩한다고 보고했습니다. 구현에 따라 노출된 자료는 커널 메모리, 정적 드라이버 메모리 또는 하드웨어 버퍼에서 나올 수 있었습니다.

유출된 바이트는 유효한 IP 페이로드가 되지 않았습니다. 올바른 IP 파서는 여전히 Total Length에서 멈춥니다. 그러나 이더넷 프레임을 관찰하는 피어는 그것을 읽을 수 있었습니다. 프로토콜은 접미사의 의미적 소속을 부인했을 뿐, 물리적 가시성을 부인하지는 않았습니다.

이것이 1984년 설계의 가장 날카로운 시험입니다. 패딩을 만드는 계층은 다음 계층이 해석을 거부하더라도 자신이 방출하는 것에 대한 책임을 집니다. 접미사를 지우는 것은 외양상 준수가 아닙니다. 캐리어 요구사항이 무관한 메모리를 네트워크 출력으로 바꾸는 것을 막습니다.

CERT의 기록은 모든 드라이버가 취약했다는 것을 증명하지 않습니다. 벤더 자료는 영향받은, 영향받지 않은, 알 수 없는 시스템을 구분합니다. 역사적으로 보장할 수 있는 주장은 더 좁습니다. 보고된 구현들에서 그 실패가 발생했고, 오래된 패딩이 원격 정보 유출 메커니즘을 만들었다는 것입니다.

출처