요약

  • RFC 1542는 BOOTP 릴레이가 한 클라이언트의 모든 요청을 동일한 목적지 또는 동일한 목적지 집합으로 보내도록 요구했습니다.
  • 이 규칙은 특정한 실패 양상을 겨냥했습니다. DHCP나 다른 BOOTP 변형이 여러 번의 교환에 의존할 때, 라운드 로빈 방식의 전달은 연이은 요청들을 여러 서버에 흩뿌릴 수 있었습니다.
  • 표준은 링크 계층 주소를 해시하는 것처럼 안정적인 클라이언트 기반 선택을 통해 부하 분산의 여지를 남겨 두었습니다.

반환 경로가 필요한 브로드캐스트

BOOTP는 자신의 IP 주소도, 부팅 정보를 제공할 서버도 모른 채 시작할 수 있는 기계를 위해 설계되었습니다. 1985년의 RFC 951은 주소 결정과 부트 파일 선택을 위한 초기 교환을 기술했습니다. 클라이언트는 자신의 로컬 네트워크에 브로드캐스트할 수 있었지만, 다른 네트워크에 있는 BOOTP 서버는 일반적인 IP 포워딩만으로는 도달할 수 없었습니다. 라우터는 보통 서브넷의 제한된 브로드캐스트를 서버 요청으로 전달하지 않기 때문입니다.

따라서 RFC 951은 협력하는 게이트웨이를 통해 게이트웨이를 넘는 부팅을 가능하게 했습니다. 이 포워딩 기능은 선택 사항이었고, 문서는 그것이 게이트웨이 안에 있거나 클라이언트 네트워크의 다른 포워딩 에이전트 안에 있어도 된다고 허용했습니다. 릴레이는 변경되지 않은 IP 패킷을 옮기는 것 이상을 했습니다. 즉 BOOTREQUEST를 처리하고, 필요할 때 BOOTP의giaddr필드를 채우고,hops를 증가시켰습니다. 이 주소는 서버가 자신의 응답을 클라이언트의 네트워크 쪽으로 되돌려 보낼 수 있는 방법을 제공했습니다. 원래 사양은 이 배열을 개략적으로 그렸지만, 릴레이 동작의 상당 부분을 열어 두었습니다.

1993년 10월까지, RFC 1532가 BOOTP를 명확히 하려 시도했습니다. 같은 달에 이어진 RFC 1542는 RFC 951을 갱신하고, 앞선 문서에 편집 오류가 유입되었기 때문에 RFC 1532를 폐기했습니다. 그 초록은 릴레이 에이전트 동작을 더 강한 사양이 필요한 영역 중 하나로 꼽습니다. 이 변화는 프로토콜 역사적으로 의미가 있습니다. 릴레이는 이제 편리한 전달 세부 사항이 아니라 클라이언트-서버 교환에 정의된 참여자로 다뤄졌습니다.

목적지 규칙

RFC 1542는 네트워크 관리자에게 로컬 제어 지점을 주었습니다. 릴레이는 BOOTREQUEST 포워딩을 켜거나 끌 수 있는 방법을 제공해야 했고, 릴레이 기능은 기본값으로 꺼져 있어야 했습니다. 켜져 있다면,hops값이 16을 넘는 요청을 거부해야 했고, 더 작은 설정 가능한 임계값이 권장되었습니다.giaddr이 0일 때 릴레이는 그것을 수신 인터페이스의 주소로 설정하고,hops를 증가시키고, 다른 BOOTP 필드를 그대로 보존해야 했습니다. 목적지 또는 목적지들은 설정 가능했으며, 릴레이는 해당 네트워크에 적합한 유니캐스트, 멀티캐스트 또는 브로드캐스트 배열을 사용할 수 있었습니다.

그다음 덜 눈에 띄는 불변 조건이 등장합니다. 특정 클라이언트로부터 릴레이된 모든 BOOTREQUEST는 동일한 목적지, 또는 동일한 목적지 집합을 사용해야 했습니다. 문서의 논의는 그 이유를 설명합니다. 목록에서 다음 서버로 각각의 새 요청을 보내는 라운드 로빈 부하 분산을 사용하던, 적어도 하나의 알려진 릴레이 구현이 언급됩니다. 그 결과 한 클라이언트의 연이은 요청들이 서로 다른 서버에 도달할 수 있었습니다.

위험은 부하 분산 그 자체가 아니었습니다. 교환이 여러 요청과 응답에 걸칠 수 있을 때, 패킷마다 독립적으로 라우팅 결정을 내리는 것이 위험이었습니다. RFC 1542는 이러한 배열이 여러 교환에 의존하는 DHCP, 아마도 다른 BOOTP 변형과 나쁘게 상호작용한다고 말합니다. 한 서버가 이른 요청을 보고 다른 서버가 다음 요청을 보게 되면, 클라이언트와 서버 측 상태가 더 이상 맞아떨어지지 않을 수 있습니다. 이 RFC는 프로토콜 위험을 지목할 뿐, 구체적 장애 사례를 문서화하지 않으며 그 구현이 얼마나 흔했는지도 말하지 않습니다.

제안된 대안은 시사적입니다. 릴레이는 클라이언트의 링크 계층 주소나 다른 신뢰할 수 있는 식별자를 해시하고, 그 결과로 목적지 또는 목적지 집합을 선택할 수 있었습니다. 이 결과는 클라이언트별 경로를 보존하면서 서로 다른 클라이언트들을 여러 서버에 흩어 놓을 수 있었습니다. 가장 단순한 옵션은 모든 요청을 하나의 고정된 목적지 집합으로 전달하는 것이었습니다. 두 경우 모두에서 부하 분산의 단위는 개별 BOOTREQUEST가 아니라 클라이언트가 되었습니다.

명확한 경계를 가진 좁은 규칙

이 요구사항은 서버가 가용할 것, 두 서버가 상태를 공유할 것, 클라이언트가 부팅을 끝낼 것을 약속하지 않았습니다. 그것은 오직 같은 클라이언트의 요청들에 걸친 릴레이의 목적지 선택만 제약했습니다. 또한 모든 클라이언트가 하나의 서버를 쓰도록 요구하지도 않았습니다. 설정된 집합이 각 클라이언트의 메시지를 받을 수 있고, 안정적인 매핑이 서로 다른 클라이언트들을 여러 목적지에 분산할 수 있었습니다.

이 규칙은 BOOTP의 더 넓은 설계에 부합했습니다. 릴레이는 네트워크 운영자가 설정했고, 그 목적지 집합은 일반적인 라우터 경로나 무관한 브로드캐스트 포워딩 설정에서 자동으로 추론되지 않았습니다. 표준은 일관된 교환에 필요한 동작을 정의하고, 릴레이를 켤지 어떻게 켤지는 운영자가 판단하도록 남겨 두었습니다. 프로토콜 문서가 공통 불변 조건을 정하면서도 로컬 배포 선택을 보존하는 작은 사례입니다.

역시 1993년 10월에 발행된 RFC 1534는 DHCP 메시지가 BOOTP에 기반한 형식을 쓰기 때문에 DHCP와 BOOTP 참여자가 상호 운용할 수 있는 방법을 기술했습니다. 1997년에 발행된 RFC 2131은 나중에 DHCP의 다단계 교환을 정리했습니다. 클라이언트가 서버를 탐색하고, 오퍼를 받고, 하나를 선택하고, 이후 요청을 보낼 수 있다는 것입니다. 이 후속 문서들은 교환 맥락을 읽을 수 있게 해 주지만, RFC 1542의 사례를 특정 운영 장애의 증거로 만들지는 않습니다.

RFC 편집자는 RFC 1542에 대해 하나의 검증된 정오표를 기록하고 있습니다. 그것은 §3.1.1의 BOOTREPLY/BOOTREQUEST 참조를 바로잡으며, §4.1.1의 릴레이 목적지 규칙과 별개인 브로드캐스트 플래그 구절에 관한 것입니다. RFC는 발행된 그대로 유지되고 정오표는 별도로 나열되므로, 이 교정은 편집적 맥락으로서 유용할 뿐 이 글에서 다루는 어피니티 요구사항을 바꾸지는 않습니다.

역사적 포인트는 이례적으로 구체적입니다. 선택이 그 클라이언트에 대해 안정적으로 유지된다면, 릴레이는 작업을 분산하면서도 클라이언트의 대화를 보존할 수 있습니다. 패킷 단위의 라운드 로빈은 그 성질을 깨뜨립니다. 신뢰할 수 있는 클라이언트 식별자를 해시하거나 고정된 목적지 집합으로 전달하면 그 성질이 보존됩니다. RFC 1542는 DHCP의 후속 사양이 다중 메시지 교환에 더 완전한 모양을 주기 전에, 이 경계를 명시했습니다.

출처