요약

  • RFC 1931은 여러 대의 조율된 Dynamic RARP 서버를 가용성 조치로 기술했지만, 세그먼트의 모든 서버가 동일한 논리적 주소 권한과 통신하도록 요구했습니다.
  • 권한 데이터베이스의 기록이 곧 현실 자체로 취급되지는 않았습니다. 할당 전에 구현은 ARP나 ICMP로 네트워크를 확인할 수 있었는데, '가용'으로 표시된 주소가 이미 사용 중일 수 있었기 때문입니다.
  • 1996년 4월에 Informational로 발표되었고 현재는 Legacy로 기록된 이 문서는 1988년부터 특정 Sun 플랫폼에서 사용된 시스템을 문서화했습니다. 인터넷 표준을 정의하지 않았고, 이후 DHCP로 이어진 인과 경로를 확립하지도 않았습니다.

침묵한 부팅 요청에는 너무 많은 의미가 있었다

최초의Reverse Address Resolution Protocol은 하드웨어 주소는 알지만 프로토콜 주소를 모르는 기기를 위해 만들어졌습니다. 기기는 요청을 브로드캐스트하고 하드웨어-IP 매핑을 보유한 하나 이상의 서버에 의존했습니다. RARP는 의도적으로 부정 응답을 두지 않았습니다. 어느 한 서버만이 다른 서버가 모르는 바인딩을 알고 있을 수 있었기 때문입니다. 침묵은 개방성을 유지했지만 진단에는 부적합했습니다. 유실된 패킷, 응답 불가 서버, 미등록 기기, 잘못된 케이블 세그먼트, 그리고 서버가 아예 없는 상태가 모두 똑같이 들렸습니다.

이 모호성은 무인 설치 과정에서 문제가 되었습니다. 새 기기는 지수 백오프로 재전송할 수 있었지만, 기다림이 도움이 될지는 알 수 없었습니다. 케이블이 모든 것을 알려줄 수도 없었습니다. 사이트에는 여전히 관리적으로 준비된 IP 네트워크와 이름 시스템이 필요했고, 주소 획득은 이름 등록, 부팅 자원, 키, 초기 비밀번호가 프로비저닝되기 전의 첫 단계에 불과했습니다.

RFC 1931은 이 좁은 운영 문제에 대한 하나의 해답으로 Dynamic RARP, 즉 DRARP를 기록했습니다. 특정 Sun Microsystems 플랫폼은 1988년부터 이를 사용해 왔습니다. 문서가 1996년 4월에 발표될 무렵 그 플랫폼들은 더 이상 판매되지 않았고, 문서는 DHCP가 이 역할을 어느 정도 대신해 왔다고 언급했습니다. 이는 역사적 설계의 보존이었지, DRARP가 더 새로운 프로토콜을 대체해야 한다는 주장이 아니었습니다.

상태 경계는 명시적입니다.RFC Editor의 현재 기록은 이 문서를 Legacy 스트림의 Informational로 분류하며 인터넷 표준을 정의하지 않는다고 말합니다. 발표 날짜는 연대기적 사실이지 4월 우스개가 아니라는 증거입니다.

동적이었다는 것은 답을 준다는 뜻이지, 서버가 자율적이라는 뜻이 아니었다

모든 DRARP 서버는 RARP 서버이기도 했고 익숙한 패킷 형식과 링크 계층 캡슐화를 재사용했습니다. 세 개의 추가 오프코드가 대화를 바꾸었습니다.DRARP_REQUEST는 오프코드 5를 사용했습니다. 권한이 이미 영구 바인딩을 보유하고 있다면 서버는 평범한REVARP_REPLY를 반환했습니다. 그렇지 않다면 보통 임시 바인딩을 만들고 오프코드 6인DRARP_REPLY를 반환했습니다. 실패는 오프코드 7인DRARP_ERROR로 명시적으로 표현되었습니다.

오류 코드들은 침묵이 뭉개버렸던 조건들을 구분했습니다.RESTRICTED는 현재 정책이 해당 세그먼트에서 동적 서비스를 금지한다는 뜻이었습니다.NOADDRESSES는 주소 풀이 고객되었다는 뜻이었습니다.SERVERDOWN은 일시적으로 사용 불가하거나 느린 할당기를 가리켰습니다.MOVED는 잘못된 세그먼트에 도착한 기존에 알려진 기기를 인식했습니다.FAILURE는 나머지 원인을 알 수 없다고 인정했습니다. 분류는 클라이언트 행동을 개선했지만, 오류 이름이 응답자를 인증하거나 그 설명을 증명해 주지는 않았습니다.

DRARP는 또한 모든 요청에 대한 응답을 요구했습니다. 이 약속은 서비스를 관측 가능하게 만들었습니다. 운영자는 거절과 지연을, 주소 풀 고갈과 토폴로지 불일치를 구분할 수 있었습니다. 그러나 회선에서 응답하는 서버가 할당을 임의로 만들 권한은 없었습니다. 문서가 기술한 구현은 NIS와IPalloc이라는 중앙화된 RPC 서비스를 주소 권한으로 사용했습니다. 관리자와 DRARP 서버는 그 데이터베이스를 변경할 권한을 받을 수 있었습니다. 문서는 이 배치를 기록했지만, 권한 프로토콜이나 그 보안 선택을 표준화하지는 않았습니다.

여러 입, 하나의 진실 기술

결정적인 규칙은 여러 서버가 같은 브로드캐스트를 들었을 때 나타납니다. 응답들은 송신 서버를 식별하는 필드를 제외하고 서로 달라서는 안 됩니다. 불일치는 프로토콜 오류입니다. 이것은 여러 프로세스의 집합을, 여러 응답자를 통해 노출되는 하나의 DRARP 서비스로 바꿉니다.

각 케이블 세그먼트에 서버를 두면 파티션의 비용을 줄일 수 있었습니다. 두 대 이상을 두면 죽은 기기나 고장난 세그먼트를 견딜 수 있었습니다. 그러나 모든 서버는 동일한 주소 권한과 통신해야 했습니다. 중복성은 응답 평면의 것이었습니다. 할당 권한은 논리적 의미에서 단일하게 남았습니다. 영구 바인딩, 임시 바인딩, 가용 풀이 하나의 일관된 계정을 이루어야 했습니다.

'하나'가 반드시 물리적 컴퓨터 한 대를 뜻하지는 않습니다. RFC 1931은 권한이 분할될 수 있음을 허용하면서 상당한 구현 및 관리 복잡성을 경고했습니다. 불변 조건은 기기의 수가 아니었습니다. 동시 요청이 정당하게 상충하는 바인딩을 만들어서는 안 된다는 것이었습니다. 잘못된 공유 결정을 더 빨리 내는 복제는 고가용성이지만 올바르지는 않습니다.

따라서 권한에는 단순한 목록 이상이 필요했습니다. 바인딩을 생성하고, 조회하고, 삭제하고, 정리할 수 있어야 했고, 영구 할당과 임시 할당을 구분하고, 동시 요구를 직렬화하고, 변경을 인가하고, 설치 기록이 전파되는 구간 동안 임시 상태를 유지해야 했습니다. 문서는 초기 구현에서 한 시간이면 충분하다고 언급하지만, 이는 보편적인 임대 법칙이 아니었습니다. 만료는 희소성을 회수했습니다. 클라이언트가 설치를 끝냈다는 것을 증명하지는 않았습니다.

장부는 일관되면서도 틀릴 수 있었다

RFC 1931의 가장 날카로운 설계 선택은 자신의 권한을 불신한 것입니다. 관리 데이터베이스는 주소가 가용하다고 말할 수 있지만 이미 실행 중인 기기가 그 주소를 사용하고 있을 수 있었습니다. 주소를 부여하기 전에 할당기는 네트워크를 확인하도록 권고되었고, 구현은 ARP와 ICMP 에코를 사용했습니다.

ARP의 원래 사양은 프로토콜-하드웨어 매핑을 요청 시에 배포합니다. 응답은 링크에서 보이는 어떤 참여자가 주소를 주장한다는 것을 보여줄 수 있습니다. 그 주장자의 소유자, 인가, 미래의 존재를 증명할 수는 없습니다. 이 탐색은 안전하지 않은 할당에 대한 반증일 뿐, 새로운 소유권 등록부가 아닙니다.

여기에 도식에서는 쉽게 합쳐지지만 실제 운영에서 혼동하기 비싼 세 층이 있습니다. 하드웨어 식별자는 어떤 링크 계층 값이 제시되었는지 말합니다. 주소 권한은 관리자와 할당기 상태가 현재 어떤 바인딩을 인정하는지 말합니다. 실시간 탐색은 이 순간 이 링크에서 무엇이 응답했는지 말합니다. 어느 하나만으로도 정당한 소유, 지속적 신원, 충돌 없는 운영을 증명할 수 없습니다.

이동은 같은 경계를 드러냈습니다. 다른 세그먼트에 도착한 기기를 인식하려면 두 권한이 같거나 서로 통신해야 했습니다. 또한 하드웨어 식별자의 범위가 그 세그먼트들 사이에서 충돌하지 않을 만큼 넓다고 가정해야 했습니다. 그래도 MAC과 같은 값은 기기 인터페이스를 이름으로 지칭할 뿐, 인증된 사람을 지칭하지 않았습니다.

문서는 서버들이 서로의 공지를 들을 수 있게 하고, 제한 모드에 들어가기 전에 조율되지 않은 것으로 보이는 응답자를 보고할 수 있게 했습니다. 그러나 두 서버가 누가 가짜인지 판정하는 프로토콜은 정의하지 않았습니다. 그 판단은 다른 곳, 보통 권한이나 관리를 통해 이루어져야 했습니다. 탐지는 거버넌스가 아니었습니다.

이후 프로토콜들은 다른 선택을 했다

DHCP와의 대조는 계보가 아니라 구조의 대조입니다.RFC 1541은 복수의 오퍼, 명시적 클라이언트 선택, 서버 식별자, 임대를 가진 BOOTP 확장을 기술했습니다. 그 후속인RFC 2131은 그 상태 기계를 다듬고, 클라이언트의 로컬 확인에서 주소가 사용 중임을 발견하면 오퍼를 거절할 수 있도록 허용했습니다. 이 문서들이 DRARP를 자신들의 원인으로 만들지는 않습니다. 제안, 선택, 확정, 수명, 충돌 근거를 분리하는 또 다른 방식을 보여줄 뿐입니다.

이후의 한 경계 사례는 한 좁은 범위에서 중앙화된 할당을 제거했습니다.RFC 3927은 호스트가 IPv4 링크-로컬 주소를 선택하고 탐색한 뒤 이를 주장하고 때로 방어할 수 있게 합니다. 그 주소는 라우팅 불가하며 하나의 링크에 국한됩니다. 이는 지속적이고 전역적으로 의미 있는 할당 권한의 대체물이 아닙니다.

RFC 5227은 ARP Probe와 Announcement로 IPv4 주소 충돌 탐지를 일반화했습니다. 그 근거는 여전히 로컬이며 시간적으로 한정됩니다. 동시 격리, 파티션, 악의적 응답자는 응답 부재가 무엇을 입증할 수 있는지 제한합니다. 실행 중인 현실이 장부 항목을 반증할 수는 있지만, 언제나 그 반대를 증명할 수는 없습니다.

실행 코드가 권한을 정직하게 유지했다

Lu Heng의Running-Code Primacy는 여기서 유용한 분석 렌즈를 제공합니다. 권한 데이터베이스는 사이트의 상징적 기록이었지만, 케이블 위의 패킷은 그것에 반박할 수 있었습니다. DRARP의 탐색은 관리를 폐지하지 않았습니다. 관리적 진실이 실행 가능한 할당이 되기 전에 운영 시험을 통과하도록 강제했습니다.

Minimum Initial Specification은 유용한 공통 규칙이 왜 작았는지를 설명해 줍니다. 응답자들은 합의해야 했고, 오류는 구분 가능해야 했고, 임시 상태는 그 의존성이 안정되기 전에 재활용되어서는 안 되었습니다. 구체적인 NIS 테이블, RPC 기계, 캐시 기간, 로컬 인가 관행은 구현 선택으로 남을 수 있었습니다.

이 분리는 또한현실의 층에 관한 사례입니다. 데이터베이스 행은 사람과 서버를 조율할 수 있습니다. 브로드캐스트 응답은 호스트를 구성할 수 있습니다. 실시간 탐색은 충돌을 드러낼 수 있습니다. 각각은 권력을 가지지만 같은 권력은 아닙니다. RFC 1931의 가치는 다섯 대의 응답 기기를 다섯 개의 권한이라 부르기를 거부했고, 하나의 일관된 데이터베이스를 현실 자체라 부르기를 거부한 데 있습니다.

출처

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — RFC 1931 current record
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Lu Heng — Running-Code Primacy
  10. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Lu Heng — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile