요약

  • RFC 3102는 사설 영역의 호스트가 자신의 스택 안에서 공인 주소, 또는 공유 주소와 포트 조합을 사용할 수 있게 하면서, 자원 풀·바인드·임대·정책은 경계 게이트웨이가 계속 보유하도록 했습니다.
  • 할당을 눈에 보이게 만든다고 모호성이 사라지는 것은 아니었습니다. 호스트는 이제 목적지가 로컬인지 아니면 공인 터널이 필요한지 스스로 판단해야 했고, RFC는 혼합 영역·다자 참여 애플리케이션에 대한 일반 해법을 기록하지 않았습니다.

호스트는 두 번째 공인 존재를 획득했다

전통적인 네트워크 주소 변환(NAT)은 경계에서 그 거래를 했습니다. 사설 호스트는 사설 주소 체계로 패킷을 만들고, 변환기가 나가는 길에 필드를 다시 쓰며 돌아오는 길에 그 변경을 되돌리려 했습니다. 호스트는 그 사실을 모른 채 있을 수 있었지만, 주소를 담거나 수정되지 않은 헤더에 의존하는 프로토콜들은 그 투명성의 비용을 그대로 드러냈습니다.

Realm Specific IP(RSIP)는 이 거래 자체를 옮겼습니다. 2001년 10월 RFC 3102로 발표된 이 아키텍처에서 호스트는 먼저 게이트웨이에 다른 주소 영역의 파라미터를 요청했습니다. 게이트웨이는 공인 주소 전체를 빌려줄 수도 있고, 공인 주소와 선별된 포트를 함께 빌려줄 수도 있었습니다. 호스트는 그 파라미터를 자신의 네트워킹 스택에 넣어 사용하고, 패킷을 터널로 게이트웨이까지 전달했습니다. 게이트웨이는 바깥 껍데기를 벗기고, 전송 과정에서 출발지가 다시 쓰이지 않은 공인 영역 패킷을 내보냈습니다.

이것은 단순히 다른 패킷 기법이 아니었습니다. 사설 호스트가 일시적으로 공인 경계 위에 존재를 갖게 된 것입니다. 호스트의 평소 사설 주소는 여전히 게이트웨이에 도달했고, 빌려온 공인 파라미터는 게이트웨이 너머에서 그 호스트를 대표했습니다. 패킷은 그 공인 출발지를 종단까지 가질 수 있었지만, 그 주소가 어느 풀에서 나왔는지는 여전히 게이트웨이가 통제했습니다.

이 구분은 두 가지 모드로 정식화되었습니다. RSA-IP는 하나의 공인 주소를 일정 기간 한 호스트에 고유하게 할당했습니다. RSAP-IP는 여러 호스트가 한 주소를 공유하되 각 호스트에 고유한 포트 집합을 주었습니다. 두 모드 모두 외부 파라미터를 호스트에게 보이게 했지만, 어느 쪽도 주소의 영구적 소유권을 넘겨주지는 않았습니다.

하나의 사실이 아니라 여러 기록이 생기는 부여

RFC 3103은 이 아이디어를 프로토콜로 만들었습니다. 호스트는 등록하고 클라이언트 ID를 받습니다. 자원을 요청하면 게이트웨이는 주소, 필요하다면 포트, 바인드 ID, 임대 구간, 터널 유형, 그리고 해당되는 흐름 정책을 응답으로 줍니다. 호스트는 연장을 요청하고, 상태를 조회하고, 인바운드 트래픽을 수신하도록 요청하고, 바인드를 해제하고, 등록을 해지할 수 있습니다.

이 메시지들은 투명 변환에서 흔히 하나의 장비 상태로 접히던 연쇄를 드러냈습니다. 등록은 게이트웨이가 클라이언트를 인식했음을 말합니다. 할당은 특정 자원이 특정 조건 아래 사용 가능함을 말합니다. 바인드는 그 자원을 호스트의 사설측 신원과 연결합니다. 임대는 부여를 시간으로 제한합니다. 흐름 정책은 그 자원을 사용할 수 있는 원격 주소나 포트를 제한합니다. 터널은 영역 경계를 넘어 패킷을 운반합니다.

그 기록 중 어느 하나만으로 다음 단계가 증명되지는 않습니다. 할당 응답이 호스트가 경로를 설치했다는 증거는 아닙니다. 바인드가 터널이 동작 중이라는 증거도 아닙니다. 호스트에서 패킷이 나갔다는 사실이 게이트웨이가 그것을 수용했다는 증거는 아니고, 수용된 아웃바운드 패킷이 같은 바인드로 회신이 돌아왔다는 증거도 아닙니다. RSIP는 상태 머신을 관찰 가능하게 만들었지만, 조립된 경로를 입증하는 것은 오직 실행 중인 관측뿐이었습니다.

따라서 제어는 비대칭으로 남았습니다. 호스트가 주소나 포트를 제안할 수 있어도, 게이트웨이는 자원이 없거나 이미 사용 중이거나 정책상 금지된 이유로 거부할 수 있었습니다. 할당되지 않은 주소, 튜플, 원격 종단점 또는 터널을 사용한 패킷은 폐기되어야 했습니다. 호스트가 공인 출발지를 패킷에 쓰고, 게이트웨이가 그 사용이 살아 있는 부여에 속하는지 판단했습니다.

지역성은 호스트가 스스로 결정해야 하는 판단이 되었다

호스트의 인식은 한 부류의 숨은 재작성을 해결하는 동시에 다른 질문을 낳았습니다. 패킷은 어느 주소 영역을 사용해야 하는가? 사설 네트워크 안의 목적지는 직접 도달할 수 있을 수 있습니다. 공인 목적지는 RSIP 인터페이스와 터널을 요구합니다. 같은 호스트가 이제 선택을 위한 충분한 토폴로지 지식을 필요로 했습니다.

단일 서브넷이라면 마스크로 답할 수 있었습니다. 더 복잡한 사설 네트워크에서 RFC 3102는 게이트웨이가 사설 네트워크 목록을 유지하고 질의에 응답하도록 제안했습니다. 라우팅 정보가 RSIP 세션보다 빠르게 바뀌면 호스트는 모든 목적지마다 물어야 할 수도 있었습니다. 이 문서는 드물게도 솔직했습니다. 견고한 일반 해법이 어려웠고, 문제의 심각성도 알려지지 않았다고 적었습니다.

이 불확실성이 가장 문제가 된 것은 애플리케이션이 IP 주소를 전역 종단점 식별자로 다룰 때였습니다. 다자 참여 교환에서 한 참여자는 수신자가 사설 영역에 속하는지 공인 영역에 속하는지 알지 못한 채 주소를 다른 참여자에게 전달할 수 있었습니다. RSIP 호스트는 자신의 사설 주소를 공인 상대에게 광고할 수도, 로컬 피어를 공인 표현과 게이트웨이로 강제 통과시킬 수도 있었습니다. RFC 3102는 알려진 일반 해법이 없다고 명시했습니다.

문제는 단순한 구현 버그가 아니었습니다. 하나의 애플리케이션 대화가 하나의 주소를 토폴로지로서, 도달 가능성 힌트로서, 그리고 서로 다른 영역 관점을 지닌 참여자들 간의 식별자로 동시에 쓰려 했습니다. RSIP는 빌려온 파라미터를 명시적으로 만들 수 있었지만, 지역성을 보편화할 수는 없었습니다.

임대는 권한을 한정했지만 재사용을 복잡하게 만들었다

시간이 부여를 이해 가능하게 만들었습니다. 각 바인드는 임대를 담도록 되어 있었습니다. 호스트는 연장하거나 해제할 수 있고, 게이트웨이는 만료시키거나 할당을 반환할 수 있습니다. 이는 오래된 권한을 한정하고 희소한 주소와 포트가 풀로 돌아오게 했습니다.

전송 계층 상태는 이 행정적 시계를 그렇게 깔끔하게 따르지 않았습니다. TCP는 닫힌 튜플을TIME_WAIT로 남겨둘 수 있습니다. 호스트가 주소·포트 쌍을 돌려놓았는데 게이트웨이가 즉시 그것을 다른 이에게 빌려주면, 이전 연결의 패킷이나 충돌 보호가 새 부여와 겹칠 수 있습니다. 따라서 임대 종료가 곧바로 즉각적이고 무위험한 재사용을 의미하지는 않았습니다.

장애도 같은 분리를 드러냈습니다. 호스트가 재부팅한 후에도 게이트웨이는 호스트가 잊어버린 바인드를 기억할 수 있습니다. 게이트웨이가 재부팅한 후에도 호스트는 게이트웨이가 더 이상 인식하지 않는 파라미터를 계속 들고 있을 수 있습니다. RFC 3103은 관계를 재구축하기 위한 등록과 오류 교환을 기술했지만, 어느 쪽의 기억이 전부라는 것은 프로토콜이 주장할 수 없는 일이었습니다.

쓸모 있는 근거는 양쪽 시간축을 모두 보존합니다. 클라이언트 ID, 바인드 ID, 부여된 튜플, 임대 시작과 만료, 연장, 해제 또는 반환 이벤트, 호스트 재부팅, 게이트웨이 재부팅, 조율 이후 수용된 첫 패킷까지입니다. 만료된 임대와 잊힌 바인드와 늦게 도착한 패킷은 같은 주소를 가리키더라도 서로 다른 이벤트입니다.

주소 공유는 위치와 신원을 분리했다

RSA-IP는 임대 기간 동안 한 호스트가 주소 전체를 쥐고 있기 때문에, 임시 DHCP 주소와 마찬가지 방식으로 동적 DNS와 상호작용할 수 있었습니다. RSAP-IP는 더 어려웠습니다. 서로 다른 호스트가 서로 다른 포트를 제어하는데도 여러 정규화된 도메인 이름이 하나의 주소로 해석될 수 있었습니다. 공인 피어는 한 주소의 서비스들이 하나의 논리적 호스트에 속한다고 합리적으로 가정할 수 있었습니다. RFC는 공유 주소 RSIP와 동적 DNS의 결합은 신중하게, 아니면 아예 하지 말라고 경고했습니다.

IPsec은 신원 문제를 더 선명하게 만들었습니다. RFC 3104는 하나의 공인 주소 뒤에서 여러 RSIP 클라이언트가 RSIP를 이해하지 못하는 피어 쪽으로 IKE와 IPsec 세션을 시작할 수 있도록 했습니다. 겉으로 보이는 출발지 주소로는 실제 피어를 식별할 수 없습니다. 대신 IKE 클라이언트 식별자가 그 역할을 담당해야 했습니다.

반환 트래픽도 더 풍부한 키를 필요로 했습니다. IKE 응답은 목적지 포트, 개시자 쿠키, 목적지 주소로 분리할 수 있었습니다. AH 또는 ESP 패킷은 프로토콜, SPI(Security Parameters Index), 목적지 주소를 사용했습니다. SPI는 클라이언트 공간과 게이트웨이 공간 양쪽에서 고유해야 했습니다. 공유 주소는 여전히 위치 지정자(locator)로서 쓸모가 있었지만, 주체(principal)로서는 더 이상 충분하지 않았습니다.

이 확장에도 한계가 있었습니다. 클라이언트 개시 세션에 초점을 맞추고, IPsec 구현과의 조율을 요구했으며, bump-in-the-stack 방식 설계는 그대로 동작하지 않는다고 경고했습니다. 종단 간 패킷 헤더는 게이트웨이를 살아서 통과했지만, 애플리케이션과 보안 동작은 여전히 명시적 조율에 의존했습니다.

발견은 제어 지점을 선택했을 뿐 권한을 부여하지 않았다

호스트는 RSIP 서버를 찾기 전까지 임대를 요청할 수 없었습니다. RFC 3105는 그 단계에 Service Location Protocol(SLP)을 사용했습니다. 게이트웨이는service:rsipURL, 역량, 수명, 그리고 선택적으로 부하 정보를 광고했습니다. Directory Agent나 멀티캐스트 발견이 후보를 돌려주었습니다. 스코프는 특정 클라이언트를 특정 영역으로 유도할 수 있었고, 클라이언트는 접속 수가 더 적게 보고되는 서버를 선호할 수 있었습니다.

그 기록들은 선택의 입력이었습니다. SLP 스코프는 명시적으로 접근 제어가 아니었습니다. 서비스 광고는 서버가 무엇을 제공한다고 주장하는지 보여줄 뿐, 클라이언트가 자원을 받을 자격이 있다는 것을 보여주지 않았습니다. 부하 값은 선택 이전에 낡을 수 있었고, 선택된 게이트웨이가 계속 가장 덜 부하된 상태임을 보장하지 않았습니다. 발견, 권한 부여, 할당, 성공적인 전달은 모두 분리되어 있었습니다.

이 계층화가 제어 면을 완성했습니다. 관리자는 호스트가 어떤 게이트웨이를 찾는지에 영향을 주었습니다. 게이트웨이는 어떤 자원을 부여할지 결정했습니다. 호스트는 유효한 부여를 어떻게 사용할지, 어떤 목적지가 로컬처럼 보이는지를 결정했습니다. 원격 피어는 받은 주소와 식별자를 어떻게 해석할지 결정했습니다. 패킷 관측은 그 연쇄가 실제로 동작하는지를 판단했습니다.

이 실험의 가치는 그 비용을 드러냈다는 데 있다

RFC 3102는 RSIP를 일종의 NAT 보완재로 기술했지, 주소 부족의 장기 해법으로 기술하지 않았습니다. 시리즈 전체는 Experimental로 남았습니다. IESG 노트는 호스트와 게이트웨이의 상당한 수정, 변동 포트(floating ports)로 피해를 입는 애플리케이션, 운영상 복잡성을 경고했습니다. 선택된 출처는 RSIP의 광범위한 배포를 보여주는 센서스나 RSIP가 일반 NAT를 대체했다는 증거를 제공하지 않습니다.

그렇다고 이 일화가 실패한 각주가 되는 것은 아닙니다. RSIP는 투명 변환이 감추던 것을 드러냈습니다. 주소 공유는 패킷 재작성 문제이기 전에 할당과 상태 분배의 문제입니다. 공인 파라미터를 호스트 쪽으로 옮기는 것은 부여를 눈에 보이게 했지만, 그 가시성은 등록·임대·정책·발견·장애 복구·지역성을 위한 프로토콜을 요구했습니다.

가장 깊은 역사적 교훈은 주소의 한계입니다. 빌려온 공인 주소는 한 영역 안에서 패킷의 존재를 식별할 수 있었습니다. 그것만으로 하나의 영구적 호스트를 식별하거나, 권한을 증명하거나, 올바른 로컬 경로를 고르거나, IPsec 피어를 인증하거나, 전달을 입증할 수는 없었습니다. 게이트웨이가 주소를 빌려주었습니다. 그 주소를 쓸모 있게 만드는 연쇄는 인터넷의 나머지 부분이 여전히 조립하고, 관찰해야 하는 것입니다.

출처

  1. https://www.rfc-editor.org/rfc/rfc3102.html
  2. https://www.rfc-editor.org/info/rfc3102
  3. https://datatracker.ietf.org/doc/rfc3102/
  4. https://www.rfc-editor.org/rfc/rfc3103.html
  5. https://www.rfc-editor.org/info/rfc3103
  6. https://datatracker.ietf.org/doc/rfc3103/
  7. https://www.rfc-editor.org/rfc/rfc3104.html
  8. https://www.rfc-editor.org/info/rfc3104
  9. https://datatracker.ietf.org/doc/rfc3104/
  10. https://www.rfc-editor.org/rfc/rfc3105.html
  11. https://www.rfc-editor.org/info/rfc3105
  12. https://www.rfc-editor.org/rfc/rfc1631.html
  13. https://www.rfc-editor.org/rfc/rfc2663.html
  14. https://www.rfc-editor.org/rfc/rfc2993.html
  15. https://www.rfc-editor.org/rfc/rfc3022.html