요약

  • RFC 3053은 요청을 인가하고 설정을 지시하는 사용자 대면 터널 브로커와, IPv6-over-IPv4 터널을 종단하고 트래픽을 운반하는 터널 서버를 분리했다.
  • 성공적인 등록, 할당, DNS 갱신 또는 설정 응답이 양쪽 엔드포인트가 호환되는 상태를 적용했음을, IPv4 언더레이가 캡슐화를 통과시켰음을, 어떤 애플리케이션이든 데이터를 주고받았음을 증명하지는 못했다.

2001년 1월, 고립된 호스트를 떠오르던 IPv6 인터넷에 연결하려면 네트워크 관리자가 손으로 구성된 터널을 만들어야 할 수 있었다. 사용자는 이미 IPv4 연결을 갖고 있었다. 없던 부분은 그 위를 가로지르는 IPv6 링크였다. 엔드포인트 주소, 프리픽스, 라우트, 터널 인터페이스, 그리고 흔히 DNS 레코드까지. 새 사용자마다 또 하나의 작은 설정 프로젝트가 생길 수 있었다.

RFC 3053은 그 프로젝트를 서비스로 전환할 것을 제안했다. 사용자는 IPv4로 접근 가능한 터널 브로커에 연락해 인증하고, IPv4 엔드포인트를 제공하고, IPv6를 활성화하는 데 필요한 매개변수를 받았다. 매력은 분명했다. 자동화가 손으로 편집하던 터널 요청 대기열을 대체할 수 있었다.

그러나 Informational로 공표된 이 문서는 새 프로토콜을 명시하지 않았다. 프레임워크를 기술했다. 그 가장 오래 지속된 기여는 아마도 친절한 접수 창구와, 그 약속을 실제로 이루어야 하는 기계와 네트워크를 분리한 방식일 것이다.

브로커는 제어 지점이었지, 반드시 패킷 경로는 아니었다

RFC 3053은 터널 브로커에 세 가지 중심 임무를 부여했다. 사용자가 서비스를 등록하고 활성화하는 지점이었다. 생성·수정·삭제를 관리했다. 그리고 하나 이상의 터널 서버에 네트워크 측 엔드포인트를 배분하고, 자신이 선택한 서버에 지시를 보냈다.

터널 서버의 역할은 달랐다. 인터넷에 연결된 듀얼스택 라우터였다. 브로커의 지시를 받으면 터널의 자기 쪽을 생성·변경·제거했다. 활성 터널의 사용 통계를 보고할 수도 있었다. IPv6-over-IPv4 데이터 경로는 클라이언트와 이 서버 사이를 흘렀고, 브로커가 계정 페이지를 소유했다는 이유만으로 브로커를 거치지 않았다.

이 분리는 규모 확장을 가능하게 했다. 하나의 관리 서비스가 여러 포워딩 장비에 작업을 배분할 수 있었다. 동시에 증거를 나누기도 했다. 브로커 데이터베이스의 한 행은 브로커가 의도를 기록했음을 증명했다. 성공한 관리 메시지는 지시가 전달되었음을 보여주었다. 서버 상태는 한쪽 엔드포인트가 구성되었음을 보여주었다. 그러나 그 영수증들만으로는 클라이언트의 호환 상태, 사용 가능한 IPv4 경로, 돌아오는 IPv6 패킷을 입증하지 못했다.

이 아키텍처는 이후의 많은 컨트롤 플레인 서비스를 연상시킨다. 가장 쉬운 인터페이스는 종종 실행 지점에서 여러 겹 떨어져 있다. 녹색 프로비저닝 페이지는 자기 트랜잭션에 대해서는 정확하면서 마지막 패킷에 대해서는 아무것도 모를 수 있다.

인가가 매개변수보다 앞섰다

클라이언트는 이미 IPv4 인터넷에 붙어 있는 듀얼스택 호스트나 라우터여야 했다. 클라이언트는 먼저 신원과 자격 증명을 제공해 브로커가 인증·인가하고 선택적으로 서비스 사용을 계량할 수 있게 했다. RFC 3053은 RADIUS 같은 기존 AAA 시설을 언급하며, 브로커를 IPv4를 통해 접속하는 IPv6 사용자를 위한 접근 제어 서버로 기술했다.

인가 후 클라이언트는 최소한 세 가지를 제공했다. 자신의 IPv4 터널 엔드포인트, DNS 등록용 이름, 그리고 독립 호스트인지 라우터인지였다. 브로커는 그다음 터널 서버를 선택하고, IPv6 할당을 정하고, 수명을 고정하고, DNS를 갱신할 수 있었고, 서버 엔드포인트를 구성하고 터널 매개변수와 이름을 클라이언트에 돌려보냈다.

각 동사에는 경계가 정해진 대상이 있었다. 인증은 계정이 서비스를 요청하도록 허용할지에 대한 결정을 지지했다. 제공된 IPv4 주소가 그 사용자의 것인지, 여전히 도달 가능한지, 캡슐화 트래픽을 통과시킬 수 있는지는 증명하지 못했다. 할당은 브로커 서비스 안의 IPv6 좌표를 예약했다. DNS 등록은 이름을 공표했다. 어느 쪽도 원격 호스트를 구성하지 않았다.

클라이언트는 여전히 자기 쪽을 설치해야 했다. 브로커의 결정, 서버의 행동, 클라이언트의 행동이 모두 끝난 뒤에야 RFC는 터널이 올라가 작동한다고 기술했다. 그때조차 아키텍처에서의 "작동"은 설계상의 결과였지, 모든 구현물로부터의 패킷 트레이스가 아니었다.

스크립트는 루트를 빌려 설치를 쉽게 만들었다

프레임워크는 클라이언트 쪽을 마무리하는 간단한 방법도 고려했다. 브로커가 개인화된 활성화·비활성화 스크립트를 생성해 사용자가 실행하게 하는 것이다. 새 클라이언트 소프트웨어가 필요 없었다. 그러나 대량의 로컬 권한을 다운로드된 산출물에 넘겨주는 셈이었다.

터널 인터페이스를 바꾸려면 관리자 권한이 필요하다. RFC 3053은 사용자가 스크립트가 실행된 뒤 불법적이거나 위험한 작업을 수행했는지 검증하기 어려울 수 있음을 경고했다. 그 대안은 HTTPS를 통해 터널 매개변수를 실어 나르는 구조화된 MIME 타입을 신뢰할 수 있는 로컬 구성 요소가 해석하도록 하는 것이었다. 문서는 그 더 안전한 방향을 스케치하되 정의는 이후 작업에 남겨두었다.

이것은 단순한 사용자 인터페이스 선택이 아니었다. 스크립트는 지시, 실행 가능한 권한, 특정 운영체제 환경을 하나로 결합했다. 매개변수 객체는 요청된 상태를 그 상태를 적용하도록 허가된 로컬 코드로부터 분리했다. 둘 다 설정을 자동화할 수 있었지만 신뢰와 검토를 서로 다른 경계에 두었다.

같은 문제가 브로커 뒤편에도 있었다. 브로커-서버 관리에는 보호된 RSH 명령, secure SNMP 또는 다른 시스템이 쓰일 수 있었다. 브로커-DNS 갱신에는 Dynamic DNS Update나 보호된 명령이 쓰일 수 있었다. RFC 3053은 이들을 하나의 프로토콜로 묶지 않았다. 각 링크의 보안과 성공은 그 구현에 달려 있었다.

안정적인 IPv6 신원이 변하는 IPv4 바닥 위에 놓였다

이 설계는 IPv4 연결이 다이얼업이고 동적으로 주소를 받더라도 사용자에게 비교적 수명이 긴 IPv6 주소와 DNS 이름을 주는 것을 목표로 했다. 재접속 시 사용자는 브로커에 연락해 새 IPv4 엔드포인트로 터널을 다시 만들고 이전의 IPv6 할당을 재사용할 수 있었다.

유용한 분리였다. 상위 계층 주소와 이름은 하위 계층 접속 주소가 바뀌었다고 해서 바꿀 필요가 없었다. 그러나 연속성은 IPv6 문자열의 속성이 아니라 조율된 작업이 되었다. 브로커는 할당을 보존하고, 돌아온 사용자를 인식하고, 서버를 선택하고, 엔드포인트 상태를 교체하고, 영향을 받는 레코드를 갱신하고, 새 클라이언트 구성을 전달해야 했다. 언더레이는 여전히 새 주소에 도달해야 했다.

따라서 영속적인 IPv6 주소는 영속적인 경로가 아니었다. 레코드와 재구성으로 뒷받침되는 약속이었다. 브로커 기록은 남았는데 사용자가 재접속하지 않았다면, 저장된 할당은 도달 가능성이 아니라 역사를 증명했을 뿐이다.

수명은 청소 정책이었지, 생존 증명이 아니었다

활성 터널은 터널 서버의 메모리와 처리 시간을 소모했다. RFC 3053은 각 터널에 수명을 부여하고, 클라이언트가 연장을 요청하지 않으면 만료 시 삭제할 것을 권고했다. 방치된 상태를 한계 지었지만, 동적 다이얼업 서비스에는 잘 맞지 않았다. IPv4 세션이 끝난 뒤에도 터널이 기록된 채 오래 남을 수 있었다.

프레임워크는 트래픽 및 도달 가능성 통계, 비활성 삭제, 킵얼라이브를 고려했다. 이들은 브로커가 미사용 터널을 더 일찍 은퇴시키는 데 도움을 줄 수 있었다. 그래도 신중히 해석해야 했다. 침묵은 단절, 필터링, 유휴 사용자, 끊긴 반환 경로를 의미할 수 있었다. 카운터는 의도된 가입자가 여전히 그 엔드포인트에 있음을 증명하지 않고 바이트를 보여줄 뿐이었다. 킵얼라이브 영수증은 좁은 한 순간을 확립할 수 있었지, 지속적인 애플리케이션 전달은 아니었다.

리스크는 낭비되는 용량보다 더 날카로웠다. 다이얼업 사용자가 터널을 해체하지 않고 끊긴다면, 서버는 옛 IPv4 주소를 향해 IPv6 트래픽을 계속 보낼 수 있었다. 그 주소는 이미 ISP가 다른 가입자에게 할당했을 수 있었다. 낡은 매핑은 그래서 기밀성 실패로 이어질 수 있었다.

브로커에는 만료 달력보다 더 많은 것이 필요했다. 누가 그 엔드포인트를 점유하는지에 대한 현재의 권한이 필요했다.

NAT는 언더레이의 거부권을 드러냈다

RFC 3053은 냉정한 한계를 명시했다. 사용자가 NAT 장비 뒤에서 사설 IPv4 주소를 갖고 있다면 이 메커니즘이 작동하지 않을 수 있다. 브로커는 양식을 접수하고, 계정을 인증하고, IPv6 공간을 할당할 수 있었지만 언더레이는 여전히 터널을 거부할 수 있었다.

이 문제는 엔드포인트를 명명하는 것과 그것에 도달하는 것의 차이를 보여주었다. 사설 주소는 사용자의 네트워크 안에서는 의미가 있지만 공용 터널 서버가 사용할 원격 좌표로는 그렇지 않을 수 있었다. 중간 장비가 요구된 대로 프로토콜 41을 통과시키지 않을 수도 있었다. 브로커의 컨트롤 플레인 확신이나 DNS 상태는 그 포워딩 사실을 바꾸지 못했다.

이후의 터널링 및 설정 메커니즘들은 다른 환경을 다루고 더 많은 협상을 자동화했다. 이들을 RFC 3053에 소급해 투영해서는 안 된다. 언더레이 제약을 식별한 프레임워크가 그것으로써 그 제약을 해결한 것은 아니었다.

접근 제어는 운반되는 대화를 보호하지 않았다

RFC는 세 가지 관리 상호작용—클라이언트-브로커, 브로커-터널 서버, 브로커-DNS—모두 보호되도록 요구했다. HTTPS, 일반 자격 증명, AAA, secure SNMP, IPsec으로 보호된 관리 등이 구현 가능성이었다.

이 보호들은 서비스 제어를 지켰다. 구성된 터널 안의 IPv6 패킷을 자동으로 지키지는 않았다. 인증은 계정이 브로커에 행동을 요청할 수 있는지에 답했다. 모든 애플리케이션 패킷을 암호화하지 않았고, 모든 IPv6 피어를 인증하지 않았고, 서비스를 통해 도달하는 모든 경로를 인가하지도 않았다.

이 구분이 중요한 이유는 같은 시스템이 여러 권한을 노출하기 때문이다. 사용자는 터널을 요청하도록 인가될 수 있었다. 브로커는 서버를 구성하도록 인가될 수 있었다. 브로커는 별개로 DNS 존을 갱신하도록 인가될 수도 있었다. 서버는 자신의 라우트에 따라 패킷을 포워딩할 수 있었다. 이 권한들 중 어느 것도 다른 모든 권한을 상속하지 않았다.

RFC 3053은 또한 프로비저닝 계층에 대한 서비스 거부 공격을 예견했다. 악의적 사용자가 많은 터널을 요청해 터널 서버 자원을 고갈시킬 수 있었다. 사용자별 한도가 제안된 방어 중 하나였다. 자동화는 운영자의 노동을 줄이면서 요청 인터페이스 자체를 자원 통제 표면으로 만들었다.

구성된 터널은 여전히 영수증의 사슬이었다

이후의 표준들은 더 많은 세부 사항을 제공했다. RFC 4213은 구성된 터널링 동작을 명시했다. RFC 4891은 IPsec으로 구성된 터널을 보호하는 방법을 다루었다. RFC 5572는 구체적인 터널 셋업 프로토콜을 정의했다. RFC 7059는 터널 계열들과 그 운영상 절충점을 비교했다. 이 문서들은 설계 공간을 밝혀주지만, RFC 3053 배포가 이후의 모든 기능을 갖추었다는 증명은 아니다.

역사적 교훈은 더 좁다. 브로커는 터널 프로비저닝을 읽기 쉽고 반복 가능하게 만들었다. 그러나 관련된 사람과 기계를 하나로 합치지는 않았다. 계정 등록, 인가, 주소 할당, DNS 공표, 서버 구성, 클라이언트 구성, IPv4 통과, IPv6 라우팅, 역방향 도달 가능성, 애플리케이션 성공은 여전히 별개의 상태 전이였다.

접수 창구는 터널을 명령할 수 있었다. 다른 기계가 그것을 운반해야 했다. 패킷은 어느 쪽도 미리 발행할 수 없는 영수증이었다.

출처

Lu Heng은 RFC 3053이나 관련 표준을 저술하거나 보증하지 않았다. 그의 에세이는 이 글에서 공개된 분석적 렌즈로 사용되었다.