요약

  • BOOTP는 디스크 없는 클라이언트가 일반적인 IP 연결성을 갖기 전에 자신의 IP 주소와 서버, 부트 파일 이름을 요청할 수 있게 했다. 파일은 별도의 전송 방식, 일반적으로 TFTP를 통해 가져왔다.
  • 이 응답은 두 번째 부트스트랩 문제를 드러냈다. 주소가 없는 클라이언트는 ARP에 응답할 수 없었다. RFC 951은 서버 측의 임시 ARP 항목이나 브로드캐스트 응답을 설명했고, 이후의 BOOTP 릴레이 규칙은 요청을 서브넷 너머로 전달했다.

전원을 켤 때 디스크 없는 워크스테이션은 아직 네트워크를 구성할 운영체제를 갖고 있지 않았다. PROM은 요청을 보낼 수 있었지만, 어떤 주소를 사용하고 어떤 파일을 불러올지 네트워크가 알려 주어야 했다. 그다음에야 해당 파일을 요청할 수 있었다. 이 순서는 순환적으로 보이는 의존성에서 시작했다. 기계가 네트워크 계층의 신원을 갖기 전에 어떻게 네트워크 계층의 응답을 받을 수 있는가?

Bill Croft와 John Gilmore는 1985년 9월 RFC 951에서 이 문제를 설명했다. BOOTP는 파일 전송 프로토콜이 아니었다. BOOTP는 첫 단계인 주소 결정과 부트 파일 선택을 담당했다. 클라이언트의 PROM은 주소, 서버, 파일 이름을 요청할 수 있었고, 응답을 받은 뒤 두 번째 단계—일반적으로 TFTP—가 파일을 메모리로 가져올 수 있었다. 이 문서는 사람이 없는 무인 전원 투입에서도 이 순서가 실행될 수 있다고 제안했다. 그것은 설계를 설명한 것이지, 얼마나 많은 기계가 이를 사용했는지 조사한 것은 아니다. (RFC 951, §§2, 7.5.)

요청에는 아직 알지 못하는 IP 주소가 필요하지 않았다. 클라이언트와 서버가 이미 지정되어 있지 않은 경우, 클라이언트는 출발지 주소 0에서255.255.255.255로 IP/UDP 패킷을 보낼 수 있었다. 이는 로컬 케이블상의 브로드캐스트였다. 요청은 또한 클라이언트의 하드웨어 유형과 주소, 트랜잭션 식별자를 실었다. 서버는 그 하드웨어 주소를 자체 데이터베이스의 IP 주소와 대조하고, 결과를 응답의yiaddr필드에 넣고, 정규화된 부트 파일 경로를 선택할 수 있었다.unix같은 일반적인 요청은 해당 클라이언트에 맞춘 파일로 해석될 수 있었다. BOOTP는 이 로컬 서버 기록을 시작 경로의 일부로 만들었다. (RFC 951, §§2–3, 7.1, 7.3, 9.)

첫 응답에는 그 자체의 닭이 먼저인가 달걀이 먼저인가 하는 문제가 있었다. 서버는 보통 IP 목적지의 링크 계층 주소를 알아내기 위해 ARP가 필요하다. 그러나 이 클라이언트는 아직 자신의 IP 주소를 몰랐고 서버의 ARP 요청에 응답할 수 없었다. RFC 951은 이 간극을 우회하는 두 가지 방법을 제시했다. 적절한 커널이나 드라이버 지원이 있는 시스템은 클라이언트의 하드웨어 주소와 제안된 IP 주소로 임시 ARP 캐시 항목을 만들고 타임아웃을 둘 수 있었다. RFC는 UNIX 4.2 BSD에 이 기능이 있었다고 구체적으로 언급했다. 그러한 연결 고리가 없으면 서버는 클라이언트의 인터페이스로 응답을 브로드캐스트할 수 있었다. 이 프로토콜은 우회 방법을 송신자의 로컬 네트워크 기능에 묶어 두었다. (RFC 951, §4.)

두 UDP 포트 번호도 그 반환 경로를 위해 쓰였다. 요청은 BOOTP 서버 포트인 67로 갔고, 응답은 클라이언트 포트인 68로 갔다. RFC 951은 포트가 분리된 이유를 설명했다. 브로드캐스트 응답은 클라이언트 포트에서 수신 대기하지 않는 호스트의 커널에서 필터링될 수 있어, 무관한 BOOTP 서버 데몬을 깨워 스케줄링하는 일을 피할 수 있었다. 임의의 클라이언트 포트 역시 브로드캐스트가 다른 호스트의 수신자에게 관련 있는 것처럼 보이게 할 수 있었다. 이 세부 사항은 장식적인 프로토콜 장부가 아니었다. 그것은 한 클라이언트의 시작 응답이 다른 모든 이의 애플리케이션 이벤트가 되는 것을 막았다. (RFC 951, §3.)

로컬 케이블이 항상 부트 서버가 있는 곳은 아니었다. RFC 951은 게이트웨이를 넘는 부팅을 선택적이고 협력적인 것으로 만들었다. 게이트웨이나 다른 전달 에이전트가 브로드캐스트를 받아giaddr를 설정해 클라이언트 측 네트워크를 식별하고, 요청을 서버 쪽으로 넘길 수 있었다. 저자들은 루프가 생길 수 있으므로 요청을 모든 곳에 단순히 재브로드캐스트하는 것에 반대했다. 1993년 10월 RFC 1542는 이 경계를 더 엄격하게 만들었다. BOOTP 릴레이 에이전트는 데이터그램을 투명하게 전달하는 IP 라우터에 불과하지 않았다. 그것은 BOOTP 메시지를 최종 목적지로 받아 새로운 BOOTP 메시지를 생성할 수 있었다. 이 기능은 라우터나 클라이언트 서브넷에 연결된 별도 호스트에 있을 수 있었다. 릴레이는 자체 메시지 처리 규칙을 가진 구성된 역할이었다. (RFC 951, §8;RFC 1542, §§4–4.1.)

이 때문에 BOOTP를 “옛 DHCP”로 축소해서는 안 된다. RFC 2131은 나중에 DHCP를 BOOTP 메커니즘의 확장으로 설명하며, 기존 클라이언트와 서버가 상호 운용할 수 있도록 메시지 형식과 릴레이 동작을 유지했다. 또한 핵심 변화 하나를 명시했다. DHCP는 유한한 임대를 부여하고 클라이언트가 더 이상 주소를 필요로 하지 않을 때 주소를 재사용할 수 있었다. 반면 BOOTP의 1985년 모델은 서버 기록에서 클라이언트의 주소와 부트 파일 선택을 조회했다. DHCP도 수동 할당을 할 수 있었기 때문에 차이는 이후의 모든 주소가 임시가 되었다는 데 있지 않았다. 동적 할당이 프로토콜에 들어왔다는 데 있었다. (RFC 2131, §§1–2.)

BOOTP의 역사적 작업은 소박하지만 필요했다. 그것은 디스크 없는 기계를 자립적으로 만들지도, 사용자를 인증하지도, 운영체제 이미지를 스스로 옮기지도 않았다. 그것은 하드웨어 주소는 있지만 사용 가능한 IP 신원이 없는 기계가 자신의 시작에 필요한 다음 조각들을 어떻게 요청할 수 있는지, 서버가 그 조각들을 어떻게 선택할 수 있는지, 그리고 ARP가 정상적으로 작동하기 전에 응답이 어떻게 돌아올 수 있는지를 정의했다. 이 경우 인터넷 연결성은 로컬 브로드캐스트, 서버의 명시적 기록, 특별히 처리된 응답에서 시작되었다.

출처와 한계

RFC 951은 제안된 프로토콜이자 의도된 동작을 문서화한 것이지, 배포 현황을 조사한 것이 아니다. 4.2 BSD의 ARP 캐시 기능 하나에 대한 설명이 모든 구현이 그 기능을 갖추었다는 것을 증명하지는 않는다. RFC 1542는 이후의 릴레이 규칙을 기록한 것이지, 보편적인 준수를 뜻하지 않는다. BOOTP는 네트워크 매개변수와 파일 이름을 선택했다. 별도의 전송 프로토콜이 파일을 가져왔다. DHCP는 동적 임대를 추가했지만 수동 할당도 유지했다.