요약

  • 1992년 1월에 발표된 RFC 1293은 ARP에 Inverse Address Resolution Protocol 메시지를 추가하여, 하드웨어 주소에 준하는 식별자를 이미 알고 있는 스테이션이 그에 대응하는 프로토콜 주소를 요청할 수 있게 했다. 이를 유발한 사례는 이미 설정된 가상 회로의 프레임 릴레이 DLCI로, 반대편의 프로토콜 주소를 알 수 없는 상황이었다.
  • InARP 요청은 목표 하드웨어 주소가 이미 알려져 있으므로 브로드캐스트가 아닌 방향성(directed) 메시지다. 응답은 조건부다. 수신 스테이션은 답할 수도, 요청자의 매핑을 캐시할 수도, 답할 수 없거나 답하지 않으려는 요청을 무시할 수도 있다. 응답은 로컬 테이블 항목을 완성할 수 있지만, 학습된 정보는 나중에 노후화되거나 무효화될 수 있다.

RFC 1293에서 가장 유용한 문장은 패킷 필드 지시문이 아니다. 그것은 회로가 존재하면서도 스테이션이 필요로 하는 용도로는 사용할 수 없다는 상태에 대한 서술이다. 프레임 릴레이 시그널링은 새 가상 회로와 그 Data Link Connection Identifier를 알릴 수 있다. DLCI는 광역 네트워크를 통과하는 하나의 가상 연결을 식별하며, 프레임 릴레이에서 하드웨어 주소에 해당하는 것이다. 그러나 그 알림에는 반대편 스테이션의 프로토콜 주소가 포함되지 않는다. 스테이션은 경로 레이블을 학습했지만, 그 경로를 통해 프로토콜 계층에서 누구에게 주소 지정할 수 있는지는 배우지 못했다.

이것은 좁지만 결과를 낳는 상태다. 회로는 허구가 아니다. 식별자가 빠진 것도 아니다. 네트워크가 그것을 시그널링했을 수 있다. 그럼에도 피어의 프로토콜 주소에 대한 설정이나 발견 메커니즘이 없으면, RFC는 그 회로를 사용 불가능하다고 말한다. 이 단어가 중요하다. 회로가 존재하지 않거나, 위험하거나, 영구적으로 고장 나 있거나, 가치가 없다고 말하지 않는다. 주소 지정 체인에서 필요한 한 링크가 아직 사용 불가능하다고만 말한다. RFC 1293은 그 범위가 드러나는 유지되는 교환으로 그 링크를 채우도록 설계되었다.

가상 회로 알림은 피어의 이름을 담지 않았다

프레임 릴레이 사례에서 영구 가상 회로(PVC), 그리고 나중에는 교환 가상 회로(SVC)가 DLCI로 식별된다. 그 식별자는 스테이션에 프레임이 어떤 가상 연결을 사용할 수 있는지 알려 준다. 그러나 반대편과 IP 또는 다른 프로토콜 대화를 맺으려 할 때 다른 계층이 필요로 하는 프로토콜 주소는 담지 않는다. 이 간극은 “네트워크가 존재한다”와 “네트워크가 존재하지 않는다” 사이가 아니다. 하위 계층의 도달 가능성 핸들과 상대 스테이션의 상위 계층 이름 사이의 간극이다.

이 두 사실을 하나로 취급하면 당시의 설정이 실제보다 단순해 보였을 것이다. 스테이션은 새 연결에 대한 시그널을 받아 그 연결을 식별할 수 있으면서도, 반대편을 주소 지정할 정보는 전혀 갖지 못할 수 있다. DLCI로부터 프로토콜 주소를 정직하게 추론할 수는 없었고, RFC 1293도 그렇게 만들어 내는 것을 허용하지 않았다. 새 회로는 질문을 위한 경로였지, 질문의 답이 아니었다.

이 구분은 1992년의 특정 환경을 넘어 유용하다. 시스템은 다음 작업에 필요한 신원이나 주소를 배우기 전에, 첨부·채널·큐·터널·세션에 대한 식별자를 먼저 학습하는 경우가 흔하다. 그 식별자는 자신의 계층 안에서는 정확하면서도 다른 계층에서는 불충분할 수 있다. 이 계층들이 “피어가 알려졌다”로 압축되면, 운영자는 실제로 어느 진술이 참인지 말할 수 없게 된다. 링크가 알림되었는지, 직접 질의가 전송되었는지, 상대가 응답했는지, 로컬 매핑이 존재하는지, 이후 작업이 성공했는지.

InARP는 질문을 뒤집되 뒤집음을 대칭으로 취급하지 않았다

RFC 1293은 이 프로토콜을 Inverse Address Resolution이라 부르는데, 개시 스테이션이 하드웨어 주소로 시작하여 프로토콜 주소를 요청하기 때문이다. 완전히 별도의 봉투를 새로 만드는 대신 익숙한 ARP 형식을 확장했다. 연산 코드는 InARP 요청이8, InARP 응답이9다.

RFC는 겉보기에 적합해 보이지만 다른 질문에 답하는 인접 메커니즘에 대해 신중했다. Reverse ARP는 검토되었으나 기각되었는데, 그 응답은 요청을 받는 스테이션의 주소가 아니라 요청을 보낸 스테이션 자신의 프로토콜 주소를 알려 주기 때문이다. 프레임 릴레이 사례에서 배워야 했던 것은 전자가 아니라 후자였다. 프로토콜 이름의 “Reverse”가 역방향으로 보이는 모든 운영 질문을 서로 호환 가능하게 만들지는 않았다. 정보의 원하는 방향과, 그 정보가 반환되는 대상이 누구인지가 중요했다.

IP 전용 해법도 기각되었는데, 저자들은 여러 프로토콜에 대한 프로토콜 주소 해석을 원했기 때문이다. 이 문서를 IP 네트워킹으로 가는 역사적 단계로만 읽을 때 이 한계는 놓치기 쉽다. RFC 1293은 알려진 목적지 하드웨어 주소와 그에 대응하는 프로토콜 주소 사이 경계에서의 매핑 문제를 서술했다. 그 매핑을 IP 소유권 레지스트리, 라우팅 당국 또는 범용 신원 서비스로 정의하지는 않았다.

목표 하드웨어 주소를 아는 것은 불확실성이 아니라 브로드캐스트를 없앴다

보통의 ARP는 목적지 하드웨어 주소 없이 시작하기 때문에 요청을 브로드캐스트한다. InARP는 브로드캐스트하지 않는다. 목적지 하드웨어 주소가 이미 알려져 있기 때문이다. 요청자는 자신의 발신 하드웨어 및 프로토콜 주소를 요청에 넣고, 알려진 목표 하드웨어 주소를 포함하고, 목표 프로토콜 주소 필드를 0으로 채우고, 관련 네트워크에 맞게 패킷을 캡슐화하여 그 목표에 직접 전송한다.

이 패킷 구성은 지식의 유용한 분할을 기록한다. 요청자는 자신에 대해 아는 것과 하위 계층 목표에 대해 아는 것을 제공한다. 비어 있는 목표 프로토콜 주소 필드는 무엇을 배우려 하는지를 표현한다. 직접 전송 선택은 질문이 어디로 가는지 좁혀 줄 뿐, 어떤 답이 돌아올지를 확정하지 않는다. 이것은 프로토콜 주소의 어떤 소유자를 찾는 브로드캐스트 탐색도 아니고, 회로가 이미 사용 가능한 피어 관계를 운반한다는 선언도 아니다.

바로 이 때문에 직접성과 확실성을 혼동해서는 안 된다. RFC 1293이 설명하듯, 방향성 요청은 모의 브로드캐스트의 다중 복사 비용을 피할 수 있고 정적 설정보다 유연할 수 있다. 그러나 효율적인 발견은 여전히 발견이다. 이 프로토콜은 반대편 스테이션이 InARP를 지원하는지, 적절한 주소를 갖고 있는지, 현재 응답하도록 설정되어 있는지, 결과 매핑이 로컬 캐시 정책을 넘어 유효할 것인지를 증명하지 않는다.

수신자는 답할 수도, 캐시할 수도, 무시할 수도 있었다

InARP 요청을 받으면, 스테이션은 ARP 요청을 받을 때처럼 요청자의 프로토콜 주소/하드웨어 주소 매핑을 ARP 캐시에 넣을 수 있다. 수신한 InARP 요청이 자신에게 향한 것이라고 가정하고, 요청의 발신 주소들을 응답의 목표 주소로 사용하여 응답을 구성할 수도 있다. “할 수 있다(may)”는 단어가 여전히 중요하다. 스테이션이 답할 수 없거나 답하지 않으려는 경우, RFC 1293은 그 요청을 무시한다고 말한다.

따라서 침묵은 요청자가 성공 상태를 발명할 권한이 아니라, 상호작용 안에서 정의된 가능성이다. 이 RFC는 적절한 응답이 없는 상황에 긍정적 응답을 제공하지 않는다. 전송된 요청은 보이지만 응답이 없는 추적은 요청이 시도되었음을 보일 수 있다. 이 문서만으로는 답이 없는 이유를 식별할 수 없다. 원격 스테이션이 불가능했거나, 원하지 않았거나, 다르게 설정되었거나, 사용 불가였거나, 호환되지 않았거나, 이 메모의 범위 밖의 조건에 놓여 있었을 수 있다. 이 프로토콜은 답의 부재를 거짓 신원 주장으로 대체하지 않고 그대로 보존한다.

요청자가 실제로 InARP 응답을 받으면, ARP 테이블 항목을 완성하고 제공된 주소 정보를 사용할 수 있다. 그것은 유용한 로컬 운영 사실이지만, 좁은 문법을 갖는다. 요청자가 주소 정보를 담은 응답을 받았고 그것을 테이블에 넣을 수 있다는 말일 뿐이다. 보편적이거나 영구적이거나 독립적으로 인증된 바인딩을 확립하지는 않는다. RFC 1293은 InARP를 통해 학습된 정보는 특정 상황에서 노후화되거나 무효화될 수 있다고 명시적으로 적는다.

로컬 테이블 항목은 내구성 있는 권위 기록이 아니었다

노후화와 무효화는 단순한 유지보수 세부사항 이상이다. 이들은 학습된 매핑이 조용히 시대를 초월하는 신원이 되는 것을 막는다. 캐시는 스테이션이 한동안 유지하기로 선택한 기록이지, 토폴로지·원격 호스트·그 승인·이후 전송된 트래픽의 최종 성공에 대한 불변의 단정이 아니다.

이 구분은 증거를 순서로 기록하면 더 명확해진다. 첫째, 알림 또는 로컬 설정이 회로와 DLCI를 식별한다. 둘째, 로컬 스테이션이 방향성 InARP 요청을 만든다. 셋째, 수신 스테이션이 응답하거나 응답하지 않는다. 넷째, 요청자가 테이블 항목을 만들거나 완성할 수 있다. 다섯째, 그 로컬 정책이 항목을 노후화하거나 무효화할 수 있다. 이후 데이터 평면 교환은 자체적인 목적지·경로·권한·시점·결과를 갖는 여섯 번째 기록이 된다. RFC 1293은 다섯 가지 중 일부를 규정하며, 여섯 번째를 매핑의 존재로 압축하지 않는다.

이것이 InARP 응답을 보안 결론으로 보고해서는 안 되는 이유이기도 하다. 이 RFC의 Security Considerations 절은 보안 문제가 다루어지지 않는다고 말한다. 이 메모는 인증, 무결성, 승인 또는 특정 공격에 대한 보호를 확립하지 않는다. 성공적인 매핑 교환과 안전한 이웃 관계는 서로 다른 증거를 필요로 하는 서로 다른 주장이다.

다중 주소 호스트는 답을 요청자에게 조건부로 만들었다

다중 주소 호스트 규칙은 이 문서에서 가장 알려 주는 안전장치 중 하나다. 단일 인터페이스에 여러 프로토콜 주소를 가진 스테이션은 그중 아무 주소나 반환할 수 없다. 먼저 요청자의 프로토콜 주소를 고려하고, 요청자의 네트워크에 대응하는 주소로 응답해야 한다. IP 예시에서, 요청된 서브넷에 IP 주소가 없다면 응답하지 말아야 한다.

따라서 응답은 단순히 응답자의 속성이 아니다. 특정 요청과 응답자 설정 사이의 관계에 좌우된다. 같은 스테이션이 여러 주소를 갖고 있으면서 이 요청자에게는 적절한 답이 없을 수 있다. 다중 주소 호스트는 인터페이스에 정의된 각 주소에 대해 InARP 요청을 보낼 수 있고, 수신 측은 자신의 설정에 따라 그 요청들 가운데 일부에만 답하거나 하나도 답하지 않을 수 있다.

이 규칙은 매력적이지만 거짓인 축약—“반대편에 주소가 있다”—을 막는다. 사용 가능한 질문은 더 구체적이다. 이 응답 스테이션은 이 요청에 대해, 이 요청자의 네트워크에 적절한 주소를 갖고 있는가? 이 차이는 해석 메시지가 문자열이 아니라 문맥을 연결한다는 점을 일깨운다. 가능한 주소의 목록만으로는 어느 것이 특정 로컬 테이블 항목에 들어가야 하는지 결정되지 않는다.

프로토콜은 설정을 넘어서지 않고 설정 주위에 경계를 그었다

RFC 1293은 InARP를 메시지의 여러 복사본으로 브로드캐스트를 흉내 내는 것보다 효율적이고, 정적 설정에 의존하는 것보다 유연하다고 제시한다. 어느 비교도 설정이 사라진다는 뜻은 아니다. 동기 부여 자체가, 새로운 설정이나 반대편 프로토콜 주소를 발견하는 메커니즘 없이는 새로 알림된 회로를 그 쪽을 주소 지정하는 데 사용할 수 없다고 말한다. InARP는 그 전제가 충족되는 곳에서 그 메커니즘이다. 다른 곳의 설정이 불필요하다는 증거도, 모든 시그널된 회로가 응답을 낳을 것이라는 증거도 아니다.

경계는 실용적이다. 네트워크는 가상 연결을 드러낼 수 있다. 로컬 스테이션은 InARP 요청을 작성할 수 있다. 원격 스테이션에는 결정 표면이 있다. 적절한 주소를 골라 응답하거나, 무시하거나. 요청자는 자신의 캐시 정책에 따라 매핑을 유지할 수 있다. 운영자는 회로 프로비저닝, 프로토콜 설정, 주소 할당, 경로 정책, 지원, 그리고 이후의 모든 서비스 검증에 대한 책임을 유지한다. 이 RFC는 이 책임들 사이에 메시지 교환을 하나 추가할 뿐, 그것들을 흡수하지 않는다.

출처와 증거의 한계

이 기사는RFC 1293 —Inverse Address Resolution Protocol을 사용한다. 이 출처는 1992년 1월의 standards-track 지위, DLCI/PVC 동기, 빠진 피어 프로토콜 주소, 이 목적을 위한 RARP 및 IP 전용 메커니즘의 기각, InARP 요청·응답 연산 코드, 비브로드캐스트 방향성 요청 구성, 조건부 응답 또는 침묵, 캐시 완성, 노후화 또는 무효화, 다중 주소 선택, 그리고 보안 문제가 다루어지지 않는다는 진술을 뒷받침한다.

이 출처는 특정 프레임 릴레이 회로가 존재했거나 현재 존재한다는 주장, 원격 스테이션이 설정되어 있었거나 도달 가능했거나 응답할 의사나 능력이 있었다는 주장, 응답이 올바르거나 승인되었거나 안전했다는 주장, ARP 항목이 유지되었다는 주장, IP 경로나 패킷 전송이 성공했다는 주장, 또는 사용자나 조직이 서비스 결과를 얻었다는 주장을 뒷받침하지 않는다. 알려진 DLCI가 사용 가능한 이웃 판정이 아니라 경계가 있는 조정 사실이라는 해석은 이 메커니즘들에 대한 편집자 독해이지, 기록된 배치 관찰이 아니다.