요약

  • RFC 887은 호스트가 제공자 주소를 모를 때Who-Provides?를 브로드캐스트할 수 있게 했지만, 침묵은 여전히 명시적 부정 응답과 구별되는 것이었다.
  • 지정된 수신자에게 보내는Do-You-Provide?는 응답이 의무였고, 제3의 호스트에 대해 전해지는 정보는 대개 직접 확인이 필요한 힌트에 불과했다.
  • 프로토콜은 자원을 길이로 구분된 디멀티플렉싱 경로로 명명했기 때문에, UDP나 포트를 지원한다고 해서 그 위의 모든 특화 서비스가 자동으로 포함되지는 않았다.

방금 시작된 기계가 게이트웨이가 필요하다는 것은 알지만 게이트웨이 주소는 모른다고 상상해 보라. 정적 목록은 불확실성을 설정 파일로 옮길 뿐 첫 부팅을 해결해 준다. 1983년 12월에 발표된RFC 887은 다른 방법을 제안했다. 네트워크에 제공자를 물어보는 것이다.

이 아이디어는 한 문장으로 요약될 만큼 단순해 보인다. 그러나 문서는 거기서 멈추지 않았다. 개방형 탐색, 지정 확인, 타인을 대신하여 전달되는 지식을 위해 각각 별도의 메시지를 설계했다. 바로 이 분리가 오래 남은 교훈이다. 후보를 찾는 것과 주장을 확인하는 것은 같은 작업이 아니다.

자원은 디멀티플렉서를 통과하는 경로였다

RLP는 친숙한 서비스 라벨로 시작하지 않았다. 자원 이름은 그것에 도달하는 데 쓰이는 가장 낮은 인터넷 프로토콜의 번호로 시작하고, 명시적 길이와 자원 고유 식별자가 뒤따랐다. 식별자는 연속된 계층을 디멀티플렉스하는 데 쓰이는 '자연스러운' 수량을 따랐다.

UDP 도메인 네임 서버의 경우 예시는 프로토콜 17 다음에 포트 53이었다. 더 특화된 서비스는 포트 위에 또 하나의 구성요소를 덧붙일 수 있었다. 형식에는IDLength가 포함되어 있어, 호스트가 이해하지 못하는 자원 지정자를 다음 지정자의 경계를 잃지 않고 건너뛸 수 있었다.

일치 판정은 구성요소별로 진행되었다. 하위 구성요소가 지원되지 않으면 그 호스트는 해당 자원을 제공하지 않는 것이었다. 요청된 이름이 호스트의 검사가 성공한 지점에서 정확히 끝나면 제공하는 것이었다. 호스트가 이해하는 범위의 끝에 도달한 뒤에도 구성요소가 남아 있다면, 하위 프로토콜에 대한 지원만으로는 부족했다.

이 규칙은 넓은 주장이 좁은 주장을 조용히 삼켜버리는 것을 막았다. “나는 TFTP를 제공한다”가 “나는 TFTP 위의 이 크래시 덤프 특화 서비스를 제공한다”를 의미하지는 않았다. 포트 도달 가능성, 애플리케이션 계열, 애플리케이션 기능은 별개로 남아 있었다.

브로드캐스트 질문은 긍정적으로 말할 자만 초대했다

Who-Provides?가 개방형 질문이었다. 평소에는 로컬 IP 네트워크에 브로드캐스트되었다. 요청된 자원 중 하나 이상을 제공하는 수신자는 그 자원들을 담은I-Provide응답을 보냈다. 일치하는 것이 없는 수신자는 아무 말도 하지 않을 수 있었다.

따라서 침묵은 경제적이지만 모호했다. 제공자가 없다는 뜻일 수도, 요청이 유실되었다는 뜻일 수도, 응답이 유실되었다는 뜻일 수도, RLP를 구현하지 않은 호스트라는 뜻일 수도, 답하기를 선택하지 않은 기계라는 뜻일 수도 있었다.RFC 919는 이후 IP 브로드캐스트가 신뢰할 수 없고 순서가 보장되지 않으며 중복될 수 있다고 설명했다. 또한 모든 브로드캐스트는 그것을 수신하는 모든 호스트에게 약간의 처리 부담을 지운다는 점도 강조했다.

RLP의 개방형 질의는 구성된 주소를 공유된 주의로 교환했다. 제공자를 모를 때 바로 그때 유용했지만, 말이 없다는 사실만으로 네트워크 전체의 부정적 사실을 만들어낼 수는 없었다.

빈 지정 응답은 또 다른 종류의 '아니오'였다

Do-You-Provide?는 이름이 지정된 한 호스트에게 묻는 질문이었다. 브로드캐스트 형태와 달리, 호스트가 나열된 자원을 하나도 제공하지 않더라도 응답해야 했다. 빈I-Provide목록은 그 호스트와 그 요청에 대한 명시적 부정 확인이었다.

RFC 887은 이 메시지의 브로드캐스트를 금지했다. 모든 수신자가 아무것도 가지고 있지 않을 때조차 답해야 한다면, 질문 하나가 응답 폭풍을 일으킬 것이다. 프로토콜은 응답 의미를 청중의 크기에 맞췄다. 다수에게는 긍정 전용 응답, 한 수신자에게는 의무적 긍정·부정 응답이었다.

명시적 부정에도 경계가 있었다. 그것은 다른 누군가가 그 자원을 제공하지 않는다는 것, 그 호스트가 나중에도 영원히 제공하지 않으리라는 것, 다른 특화 서비스가 실패하리라는 것을 증명하지 않았다. 브로드캐스트 침묵이 닫을 수 있는 것보다 좁은 불확실성만 닫았다.

똑똑한 호스트는 보증 없이 가리킬 수 있었다

두 개의 추가 질의,Who-Anywhere-Provides?와Does-Anyone-Provide?는 알려진 '스마트' 호스트가 다른 기계들을 대신하여 답할 수 있게 했다. 이는 브로드캐스트가 없는 네트워크에서 도움이 되었고, 게이트웨이나 디렉터리와 같은 호스트가 다른 곳에서 얻은 지식을 중계할 수 있게 했다.

응답은They-Provide라고 불렸다. RFC 887은 그 권위에 대해 이례적으로 명확했다. 질의자는 간접 정보를 무비판적으로 믿을 필요가 없다. 진행하기 전에 보통 지명된 주소에 직접Do-You-Provide?를 보내야 한다.

도메인 네임 서버의 예제는 이 규칙을 하나의 순서로 바꿔 보여준다. 스마트 호스트가 먼저 로컬 전용 범위 안에서 빈 답을 준다. 범위가 넓어진 뒤에 호스트 S를 지명한다. S에 대한 직접 질의는 빈 부정을 돌려준다. 클라이언트는 S를 제외하고 다시 물으며, 호스트 T가 지명되고 UDP 포트 53을 직접 확인한다.

이 순서에서 S가 아니오라고 말할 때 스마트 호스트가 반드시 거짓을 말하고 있어야 할 필요는 없다. 그 지식은 단순히 오래되었을 수 있다. 프로토콜은 누가 어떤 주장을 했는지를 보존하므로, 간접 디렉터리와 살아 있는 엔드포인트가 하나의 관측 시점을 공유한다고 가장하지 않고도 탐색을 갱신할 수 있다.

범위와 상관관계는 정체성이 되지 않았다

Local-Only플래그는 응답 주소를 질의자의 IP 네트워크로 제한하고, 멀티홈드 응답자에게 적절한 로컬 소스 주소를 쓰라고 알려주었다. 범위는 질문의 일부였으며, 나중에 덧씌우는 외양 필터가 아니었다.

16비트 Message-ID는 응답을 요청과 짝지는 데 도움이 되었다. 그러나 응답자를 인증하거나, 서비스 사용을 허가하거나, 위조된 답을 막지는 않았다. UDP는 포트, 길이, 체크섬을 제공했고, 체크섬은 암호학적 정체성 증명이 아니었다. RFC 887은 수신된 어떤 주장도 권한으로 바꿔주는 신뢰 체계를 정의하지 않았다.

I-Provide응답은 애플리케이션 효과에 이르지도 않았다. 응답 호스트가 명명된 자원을 주장한다는 것을 말할 뿐이었다. 이후 거래가 성공할 것이라든가, 관련 명세의 모든 부분이 구현되어 있다든가, 질의자가 그것을 사용할 자격이 있다는 것을 증명하지 않았다.

이후의 탐색 체계는 경계를 옮겼다

이후의 표준들은 직접적인 계보의 증명이 아니라 비교 대상으로 제공된다.RFC 2608은 서비스 위치 프로토콜 질의를 서비스 유형과 속성에 관한 것으로 만들고, 사용자 에이전트·서비스 에이전트·디렉터리 에이전트를 구별하며, 행정적 범위를 도입했다. 또한 서비스 URL과 속성에 대한 인증을 정의하면서 기밀성은 프로토콜의 범위 밖이라고 밝혔다.

RFC 6762는 종래의 유니캐스트 DNS 서버 없이 로컬 링크에 DNS와 유사한 동작을 가져왔다.RFC 6763은 DNS 레코드를 사용해 서비스 유형과 도메인으로 명명된 서비스 인스턴스를 탐색했다. 이들 설계는 어휘, 캐시, 제어 표면을 바꾸었다. 그러나 오래된 증거 문제를 사라지게 하지는 않았다. 레코드, 광고, 응답은 여전히 발행자와 범위와 시각을 가진다.

할당된 번호는 운영상 주장보다 오래 살아남았다

RFC 887은 UDP 포트 39를 할당했다. 현재IANA 서비스 이름 및 전송 프로토콜 포트 번호 레지스트리는 TCP와 UDP의 포트 39에rlp를 기록하고 있다. 그 행은 내구성 있는 행정적 사실이지, 배포 현황 조사가 아니다.

RFC 6335는 더 큰 규칙을 밝힌다. 할당된 서비스 이름이나 포트는 보증이 아니며, 그 포트의 트래픽이 할당된 서비스에 속할 필요는 없다. 레지스트리는 누가 수신 대기 중인지를 더 이상 알려주지 않게 된 뒤에도 조율 기능을 보존할 수 있다.

출처와 한계

이 글은 RFC 887, RFC 919, RFC 2608, RFC 6762, RFC 6763, RFC 6335 및 IANA 서비스 이름 레지스트리를 사용한다. 이들 문서는 프로토콜 설계와 레지스트리 상태를 확정한다. 그러나 RLP가 얼마나 널리 배포되었는지, 이후 탐색 프로토콜로 이어지는 직접적 계보가 있는지, 현재 제품 동작이나 특정 서비스의 가용성을 확정하지는 않는다.