RFC 1277: 주소는 곧 경로가 아니었다

요약

RFC 1277은 OSI 네트워크 서비스를 사용할 수 없을 때 TCP/IP 또는 특정 X.25 네트워크를 통해 OSI 연결을 시도하는 데 필요한 정보를 인코딩했다.
그 전역 고유 주소 형식은 네트워크를 식별하고 전송 계층별 매개변수를 담을 수 있었다. 그러나 할당 자체가 주소가 실제로 라우팅되거나 서비스가 응답한다는 것을 보장하지는 않았다.

OSI의 디렉터리는 프레젠테이션 주소(Presentation Address)를 반환할 수 있었지만, 이 주소 모델은 OSI 서비스가 제공하는 네트워크 계층 주소를 전제로 했다. 이 전제는 모든 파일럿 환경에 맞지 않았다. OSI 애플리케이션은 인터넷, 사설 또는 공용 X.25, 그리고 고립된 네트워크 위에서 이미 동작하고 있었다. 모든 실험이 하나의 전역 OSI 네트워크를 기다리도록 요구했다면, 디렉터리는 사람들이 실제로 시험하던 환경에서 사용할 수 없는 것이 되었을 것이다.

RFC 1277은 연결 과정에서 한 좁은 단계를 다루었다. 애플리케이션이 프레젠테이션 주소를 조회하면, 클라이언트는 각 네트워크 주소를 추출하고 그것을 사용할 수 있는지와 어떻게 사용할지 판단하며, 선호 순서를 정하고 연결을 시도해야 했다. 이 메모는 바로 그 추출 단계에 집중했다. 디렉터리가 별도로 제공하지 않는 하위 계층 정보를 클라이언트가 추론할 수 있는 주소 인코딩을 정의했다. 연결 절차 전체, 경로 탐색, 또는 성공적인 애플리케이션 교환을 정의하지는 않았다.

이 구분이 중요했던 이유는 주소 하나가 여러 역할을 맡고 있었기 때문이다. 국제 X.25의 경우 X.121 형식 주소는 DTE를 식별할 수 있었고, 적절한 경우에는 공용 X.25 네트워크를 가로지르는 경로를 지원할 수 있었다. 그러나 할당 식별자는 본질적으로 위상적이지 않았다. 즉, 종단 시스템은 주소의 전역적으로 할당된 모든 부분이 경로를 서술한다고 가정할 수 없었다. RFC 1277은 IDP가 본질적으로 할당 메커니즘이며 원칙적으로 사용자가 여기서 라우팅을 추론할 수 없다고 명시한다. 특정 X.121 형식을 경로로 해석하라는 메모의 권고는 사용 중인 서비스와 형식에 따라 조건이 붙었고, 사설 수단이 더 나은 대안을 보여줄 수도 있었다.

RFC 1006이 정의한 OSI 전송 서비스를 운반하는 TCP/IP 네트워크의 경우, RFC 1277은 다른 인코딩을 사용했다. 네트워크별 부분은 12자리 IPv4 주소를 먼저 배치하고, 그 뒤에 선택적으로 5자리 포트와 5자리 전송 집합 값을 둔다. 후자는 16비트 플래그 워드로, 비트 값이 TCP와 UDP를 나타내며 값이 없거나 0이면 기본값인 TCP를 의미한다. RFC의 실제 예시는10.0.0.6, 포트9, UDP를 인코딩한다. 이것은 연결 시도를 위한 파싱 지침이지, 그 주소가 최신이거나 도달 가능하거나 수신 대기 중이거나 권한을 갖추었다는 증명이 아니다.

새 형식은 또한 진짜 OSI 네트워크 서비스가 사용하는 주소와 구별 가능해야 했다. RFC 1277은 자신의 형식에 Telex AFI를 선택했는데, 이는 더 큰 도메인별 부분을 남기고 다른 용도와 혼동될 가능성이 낮았기 때문이다. 짧은 접두사가 서브네트워크를 구분하고 나머지가 네트워크별 데이터를 담았다. 이 설계는 컴팩트하고 자기 서술적인 구조를 긴 10진수 표현과 맞바꿈을 했다. 메모는 이진 ASN.1 형식이 매력적이었지만 사용 가능한 주소 공간에 맞지 않았다고 언급한다.

이 트레이드오프는 시대를 초월한 주소 법칙이 아니라 과도기 공학 환경의 산물이었다. 메모의 역사적 노트는 이 접근이 구현되었고 THORN 및 ISODE/QUIPU 프로젝트에서 실현 가능성이 입증되었다고 말한다. 이는 그 프로젝트들에서 작동하는 제안이었다는 증거이지 광범위한 배포의 증명은 아니다. RFC 1278은 이후 프레젠테이션 주소에 대한 사람이 읽을 수 있는 문자열을 다루었는데, 내부 저장이 아니라 표시 목적으로 명시된 것이며, 이는 RFC 1277의 할당 및 하위 계층 인코딩과는 다른 계층이다. 또한 RFC 1237의 NSAP 지침은 OSI 비연결형 네트워크 서비스를 다루며, RFC 1277이 수용하려던 비-OSI 사례는 다루지 않는다.

RFC 1277의 지속적인 교훈은 "주소가 곧 연결 방법을 알려준다"는 것보다 좁다. 디렉터리 레코드는 클라이언트가 하위 계층 해석을 선택할 수 있을 만큼 충분한 구조를 담을 수 있다. 그래도 클라이언트는 살아 있는 경로, 호환되는 수신자, 성공적인 전송 교환, 그리고 애플리케이션 응답이 필요하다. 인코딩된 값을 이 네 가지 전부로 다루면 할당, 해석, 도달 가능성, 서비스를 메모가 한 번도 주장하지 않은 단일 주장으로 압축하는 것이 된다.

출처:RFC 1277;RFC 1006;RFC 1278;RFC 1237.