요약

  • DRAP은 워크스테이션별 DLSw 피어 구성을 하나의 서버와 하나의 중앙 DLSw 피어 연결 뒤에 다수의 경량 클라이언트를 두는 구조로 대체했다.
  • 서버는 MAC 주소를 할당하거나 캐시하고, 도달 가능성 프로브에 응답하며, 기능을 협상하고, 세션 식별자를 생성했으며 TCP가 일시 중단된 동안에도 회로를 유지할 수 있었다.
  • 이러한 운영 신호 중 어느 것도 개인의 신원, 인가, 진위가 확인된 출처, 종단 간 전달을 입증하지 못했다. RFC 2106은 인증을 규정하지 않았고 인터넷 표준이 아닌 정보성 문서였다.

하나의 백본 피어, 다수의 에지 클라이언트

RFC 2106에서 가장 시사적인 문장은 패킷 정의가 아니다. 패킷 정의에 앞서 나온 확장성 불만이다. 원격 워크스테이션은 Data Link Switching을 직접 실행할 수도 있었지만, 그렇게 하면 중앙 사이트를 향한 TCP 세션 수가 워크스테이션 수에 비례해 늘어났다. 사실상 스위치 간 프로토콜이 개별 엔드포인트까지 밀려 들어가고 있었던 것이다.

Data Link Switching Remote Access Protocol, 즉 DRAP은 이 토폴로지를 바꿨다. 워크스테이션은 인근 DRAP 서버의 클라이언트가 되었다. 모든 워크스테이션이 아니라 그 서버가 중앙 라우터를 향한 DLSw 피어 관계를 유지했다. 덕분에 다수의 에지 접속이 하나의 백본 방향 관계를 공유할 수 있었다. 복잡성이 사라진 것은 아니었다. 복잡성은 클라이언트를 대신해 상태를 축적하는 게이트웨이 안으로 옮겨갔다.

여기가 이 글의 경계다. RFC 1434는 전송을 공유하는 두 개의 로컬 LLC 링크를 다뤘고, RFC 2024는 DLSw 디렉터리·캐시·전송·회로 상태를 MIB를 통해 노출했다. RFC 2043은 두 PPP SNA 접속을 분리했고, RFC 2097은 NetBIOS 이름을 접속 절차에 투영했다. RFC 2106이 한 일은 달랐다. 라우터 측 서버를 원격 워크스테이션의 운영 기억 저장소이자 발화 권위로 만든 것이다.

가상 MAC은 라우팅 도구였다

PPP로 접속한 워크스테이션은 IP 주소는 있어도 LAN MAC 주소가 없을 수 있었다. DRAP은 서버가 가상 MAC을 할당하도록 허용했다. 클라이언트가 0이 아닌 주소를 제공하면 서버는 이미 사용 중인지 확인하고 캐시했다. 서버가 먼저 시작하는 세션의 경우, 클라이언트는 자신의 MAC과 IP를 사전 등록해 서버가 재접속 위치를 알도록 할 수 있었다.

이 메커니즘은 유용했지만, 익숙한 단어 '신원(identity)'이 암시하는 것보다 그 의미는 훨씬 좁았다. MAC은 프로토콜의 운영 모델 안에서 엔드포인트를 선택했을 뿐이다. 누가 워크스테이션을 통제하는지, 사용자가 애플리케이션에 접근할 자격이 있는지, 등록이 진짜 출처에서 왔는지를 확립하지 못했다. 서버의 캐시는 운영상의 주장 저장소였지, 신원 권위가 아니었다.

같은 원칙은 서버 선택에도 적용된다. 여러 서버 주소가 설정된 클라이언트는 모든 서버에 요청을 보내고 가장 먼저 응답한 서버를 사용할 수 있었다. 첫 응답은 생존 여부와 타이밍의 결과일 뿐, 응답자가 올바른 관리 권위라는 증명이 아니었다.

프로토콜 상태는 상태 전환의 증거였다

DRAP의 메시지 어휘는 운영자가 작은 신호에 얼마나 많은 의미를 실수로 부여할 수 있는지 보여주는 좋은 예이다.CAN_U_REACH는 서버가 대상에 도달할 수 있는지 물었고,I_CAN_REACH는 서버의 답을 보고했다.START_DL은 링크 스테이션을 요청했고,DL_STARTED는 서버가 이를 생성했다고 알렸다. 발신자·수신자 세션 식별자는 회로를 구분했다. 기능 교환은 클라이언트 MAC, NetBIOS 지원, SAP 목록, 클라이언트가 새 TCP 연결을 수신 대기할 수 있는지 등의 세부 사항을 확정했다.

각 메시지는 특정한 사실을 입증했다. 긍정적인 도달 가능성 응답은 서버가 경로를 주장할 의사가 있음을 보여줬고, 링크 시작 응답은 로컬 프로토콜 전환이 성공했음을 보여줬으며, 세션 식별자는 관계 내부의 상태에 이름을 붙였다. 그러나 어느 것도 애플리케이션 전달, 인가된 사용, 메시지를 생성한 당사자 이상의 출처를 입증하지 않았다.

전송 경계도 똑같이 미묘했다. RFC 2106은 클라이언트-서버 쌍마다 포트 1973에서 하나의 양방향 TCP 연결을 사용했다. close-peer 작업은 데이터 링크 회로를 그대로 둔 채 TCP 연결을 일시 중단할 수 있었다. 새 사용자 데이터가 나타나면 클라이언트는 기능 교환을 반복하지 않고 재접속할 수 있었다. 선택적 keepalive는 피어가 여전히 응답하는지 확인했고, 세 번의 응답 누락 후 권장 조치는 TCP와 회로를 모두 닫는 것이었다.

이 분리는 운영상 우아했다. 동시에 '연결됨'을 계층적 진술로 만들었다. TCP 소켓이 없어도 회로는 논리적으로 살아 있을 수 있었다. keepalive는 응답성을 입증할 수 있지만 트랜잭션이 의도된 애플리케이션에 도달했다는 증명은 아니었다. 프로토콜의 상태 기계는 이 구분에 대해 혼란스럽지 않았다. 이후의 독자들도 그래서는 안 된다.

배포로 얻는 합의가 아니라 정보성 스냅샷

RFC 2106은 1997년 2월에 정보성(Informational) 문서로 발행되었고, 인터넷 표준을 규정하는 문서가 아니라고 명시했다. 인증 메커니즘을 전혀 기술하지 않았고 보안 고려 사항(Security Considerations) 섹션도 없었다. 이 부재는 역사적으로, 그리고 문자 그대로 읽어야 한다. 이 문서는 신원 또는 인가 아키텍처가 아니라 원격 접속 적응과 그 상태 전환을 규정한 것이다.

같은 달 RFC 2114가 이를 대체하며, 체계의 이름을 Data Link Switching Client Access Protocol로 바꾸고 중앙 클라이언트/서버 개념은 유지한 채 탐색 옵션을 추가했다. 그 빠른 연속은 의미가 있다. 등록된 포트, 상호 운용 가능한 구현, RFC 번호는 시스템을 작동 가능하고 발견 가능하게 만들 수 있다. 그러나 그것만으로 지속적인 표준 합의를 입증하지는 못한다.

출처