RFC 903: RARP는 주소를 찾았지만 전체 구성은 아니었다

요약

RFC 903은 특정한 콜드 스타트 문제를 다루었습니다. 디스크 없는 호스트는 자신의 하드웨어 주소를 알고 있었지만, IP를 사용하려면 그 전에 프로토콜 주소가 필요했습니다.
RARP는 이 조회를 데이터 링크 계층에 두었습니다. 서버가 관리 중인 하드웨어 주소–프로토콜 주소 대응표에서 응답했으며, 이 응답은 기기를 인증하거나 부팅이 완료되었음을 증명하지 않았습니다.
이 프로토콜에는 명시적인 '찾지 못함' 응답이 없었습니다. 아무 응답을 듣지 못한 클라이언트는 매핑이 없는 것인지, 요청이 유실된 것인지, 서버가 응답하지 않은 것인지 알지 못한 채 타임아웃을 기다려야 했습니다.
RFC 950과 BOOTP는 하나의 주소가 부트 구성의 일부에 불과했던 이유를 보여줍니다. 호스트는 게이트웨이, 네임 서버, 서브넷 마스크, 부트 파일까지 필요로 할 수 있었습니다.

IP보다 먼저 제기된 첫 번째 질문

로컬 디스크가 없는 워크스테이션을 상상해 보십시오. 부팅 코드는 이더넷 인터페이스의 하드웨어 주소를 읽을 수 있지만, 저장된 인터넷 주소는 없습니다. IP 요청으로는 이 문제를 해결할 수 없습니다. 기기가 아직 요청을 보낼 때 사용할 발신 주소를 모르기 때문입니다.

Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer가 1984년 6월에 발표한RFC 903에서 RARP를 제안했습니다. 이 메모는 호스트가 이더넷과 같은 브로드캐스트 매체에서 외부 소스에 자신의 프로토콜 주소를 요청하는 방식을 설명합니다. ARP는 반대 방향을 해결했습니다. 즉, 프로토콜 주소가 이미 알려져 있을 때 하드웨어 주소를 찾아내는 것이었습니다. RARP는 하드웨어 주소에서 출발하여 그에 대응하는 프로토콜 주소를 물었습니다.

이것은 범용 신원 서비스가 아니었습니다. RARP는 워크스테이션의 소유자가 누구인지, 또는 어떤 사람이 주소를 사용할 자격이 있는지를 묻지 않았습니다. 정상적인 IP 통신이 가능해지기 전에, 구성되지 않은 호스트가 특정한 하나의 매핑을 요청할 수 있는 방법을 제공했을 뿐입니다.

로컬 서버가 답을 보유

RFC 903은 의도적으로 RARP를 별도의 데이터 링크 프로토콜로 만들었습니다. ARP의 패킷 구조를 재사용하면서 역방향 요청과 역방향 응답을 위한 오퍼레이션 코드를 새로 배정했습니다. 자신의 주소를 요청할 때 호스트는 발신 하드웨어 필드와 대상 하드웨어 필드 양쪽에 자신의 하드웨어 주소를 넣었습니다. 이 주소를 인식한 서버는 대상 프로토콜 주소로 응답할 수 있었습니다.

그 응답은 서버의 상태에 의존했습니다. 이 RFC는 하나 이상의 RARP 서버가 하드웨어 주소–프로토콜 주소 매핑 데이터베이스를 유지 관리한다고 명시합니다. 이는 호스트들이 피어 매핑을 캐시에 학습하고 클라이언트/서버 구분이 없는 일반적인 ARP와 다릅니다. 따라서 RARP는 운영상의 의존 관계를 도입했습니다. 클라이언트는 물어볼 수 있었지만, 서버의 대응표를 유용하게 유지하는 것은 현지 운영자의 몫이었습니다.

응답은 자격 증명이 아니라 매핑 확인에 불과했습니다. 이 RFC는 하드웨어 주소를 특정 사람, 소유자 또는 승인된 기기와 결합하는 인증을 규정하지 않습니다. 또한 응답이 호스트가 주소를 올바르게 설정했는지, 게이트웨이에 도달했는지, 운영체제를 적재했는지를 증명하지도 않습니다. 이것들은 그 이후 단계입니다.

침묵은 부정 응답이 아니었다

RFC 903은 역방향 요청과 응답을 정의하지만 '찾지 못함' 또는 오류 패킷은 정의하지 않습니다. 저자들은 많은 서버가 요청에 자유롭게 응답할 수 있다고 설명합니다. 별도의 거부 응답을 정의하는 대신, 이 RFC는 요청자에게 합리적인 시간 내에 응답이 오지 않으면 타임아웃 처리하라고 지시합니다.

이 선택은 교환을 단순하게 유지했지만, 클라이언트에게 모호한 관측 결과를 남겼습니다. 타임아웃은 어떤 서버도 매핑을 갖고 있지 않았다는 뜻일 수도 있고, 요청이나 응답이 유실되었거나, 링크가 다운되었거나, 가용한 서버가 없다는 뜻일 수도 있습니다. 침묵은 어느 조건이 해당하는지 식별해 주지 않았습니다. 'RARP 타임아웃'만 보고하는 부팅 로그로는 원인을 확정할 수 없었습니다.

장애를 재구성할 때 이 구분이 중요합니다. 응답 부재는 클라이언트가 무엇을 받았는지에 대한 근거일 뿐, 주소가 미할당 상태였다는 증명이 아닙니다. 원래 메모는 모든 원인을 구분하는 진단 체계를 규정하지는 않지만, 이 경계에 대해서는 명확합니다.

주소 하나만으로는 호스트를 구성하지 못했다

더 넓은 부팅 문제는 곧 드러났습니다.RFC 950은 RARP를 새로 부팅된 호스트가 자신의 인터넷 주소를 알아내는 방법 중 하나로 언급한 뒤, 호스트가 추가로 필요로 할 수 있는 정보를 나열합니다. 즉, 게이트웨이의 하드웨어 주소, 네임 서버의 IP 주소, 서브넷 마스크입니다. 여러 매개변수를 하나의 요청으로 얻는 편이 여러 번 브로드캐스트를 보내는 것보다 바람직하다고 주장합니다.

다음 해에 규격화된BOOTP는 하드웨어–IP 조회를 유지하면서 선택적 파일 이름을 포함한 더 많은 부팅 정보를 전달했습니다. 설계상 게이트웨이를 통한 부팅도 가능했습니다. RFC 951은 RARP의 하드웨어 링크 계층 패킷과 이를 접근하기 위해 필요한 커널 또는 드라이버의 특수 작업과 대비하여 자신의 IP/UDP 방식을 명시적으로 설명합니다. 이후RFC 1542는 BOOTP 릴레이 동작을 명확히 했고,RFC 2131은 DHCP가 재사용 가능한 자동 주소 할당과 구성 옵션을 통해 BOOTP를 기반으로 발전했다고 설명합니다.

이 일련의 흐름이 모든 네트워크가 특정 날짜에 RARP를 버렸다는 증명은 아닙니다. 이것은 문제 정의의 이동을 보여줍니다. 미리 할당된 하나의 주소를 알아내는 것은 유용했지만, 라우팅된 네트워크를 건너 부팅하려면 더 폭넓은 교환과 릴레이 경로가 필요했습니다.

기록은 기기가 아니다

Lu Heng의노트 72는 1984년에 대한 근거가 아니라 이후의 분석적 렌즈를 제공합니다. 즉, 레지스트리 기록은 현실을 서술하지만 현실을 만들지는 않는다는 것입니다. RARP는 전역 레지스트리가 아니었지만, 이 구분은 여전히 적용됩니다. 서버의 대응표는 로컬 매핑을 조율할 수 있었지만, 반환된 주소가 하드웨어 소유권, 사용자 신원 또는 성공적인 작동의 증거가 되게 하지는 못했습니다.

이 프로토콜의 역사적 기여는 더 좁고 실용적이었습니다. 호스트가 이미 도달할 수 있는 링크에 IP 통신을 시작하는 데 필요한 단 하나의 주소를 물을 수 있게 한 것입니다. 그 경계가 곧 비용이기도 했습니다. 로컬 매핑은 유지 관리되어야 했고, 침묵은 스스로를 설명할 수 없었으며, 응답은 완전한 구성에 미치지 못했습니다.