요약

  • RFC 1887은 IPv6 집계를 비용 배분 문제로 다루었다. 모든 멀티호밍 설계는 실제 비용을 사이트, 공급자, 라우터 사이에서 다른 곳으로 옮길 뿐이었다.
  • RFC 2073은 주소 안에 레지스트리, 공급자, 구독자 필드를 명명했고, RFC 2374는 그 계층 구조를 개정했으며, RFC 3587은 TLA/NLA 대체 구조를 historic으로 만들면서 계층적 프리픽스는 운영 도구로 남겼다.
  • 이 일련의 흐름은 하나의 데이터베이스 행에서 흔히 뭉뚱그려지는 세 가지를 구분한다. 패킷이 사용하는 주소, 그 주소를 할당한 기관, 그리고 경로를 경제적으로 만드는 토폴로지.

첫 설계는 다른 라우터에서 시작되었다

1995년 12월,RFC 1887은 훨씬 커진 인터넷도 여전히 라우팅할 수 있도록 IPv6 주소를 어떻게 할당해야 하는지를 물었다. 이 문서의 관심 단위는 개별 호스트가 아니었다. 라우터가 저장하고 교환하고 다시 계산해야 하는 도달 가능성 정보의 양이었다.

이 문서는 원하는 축소를 "라우팅 데이터 추상화"라고 불렀다. 많은 사이트가 어떤 공급자의 더 큰 블록 아래에서 연속된 주소를 받는다면, 그 공급자는 고객 목록 대신 프리픽스 하나를 광고할 수 있었다. 그 절약은 주로 사이트 밖에서 쌓였다. 먼 공급자들이 더 적은 수의 경로를 보게 되는 것이다. 따라서 주소 계층 구조는 장식적 문법이 아니었다. 분산된 운영 비용을 억제하는 수단이었다.

이 논리는RFC 1518과RFC 1519에 기록된 클래스리스 전환을 물려받았다. 임의 길이 프리픽스 덕분에 라우팅이 옛 주소 클래스 대신 토폴로지를 따를 수 있었다. 그러나 클래스리스 포워딩 알고리즘이 할당을 중립적으로 만들지는 않았다. 여전히 누군가는 어떤 주소가 연속적인지, 어떤 예외를 광고할지, 그 예외가 얼마나 멀리 전파될지 결정해야 했다.

RFC 1887은 이 긴장을 직접 명명했다. 효율성과 분산된 통제 사이의 대립이다. 주소 행정은 분산될 수 있지만, 집계는 할당이 실제 연결성을 따를 때 가장 잘 작동한다. 행정 경계와 네트워크 토폴로지는 항상 일치하지 않았다. 설계 문제는 자유와 질서 중 하나를 한 번 고르는 것이 아니었다. 두 것이 어긋날 때 그 비용이 어디에 놓이는지를 찾는 문제였다.

멀티호밍은 청구서를 드러냈다

이 문서의 가장 밝혀주는 절은 여러 트랜짓 라우팅 도메인에 연결된 사이트를 위한 네 가지 접근법을 제시했다.

사이트는 공급자와 무관하게 프리픽스 하나를 독립적으로 얻을 수 있었다. 그러면 하나의 내부 넘버링 플랜이 유지되고 조직은 안정적인 집계 단위를 갖는다. 대가는 다른 네트워크에 나타났다. 전 세계 공급자들이 잠재적으로 그 사이트를 위해 별도의 경로를 유지해야 하는 것이다.

대신 사이트는 연결마다 다른 공급자 유래 프리픽스를 취할 수도 있었다. 각 공급자는 자기 고객을 집계할 수 있고, 트래픽은 목적지 근처에서 들어올 수 있었다. 그러나 백업 도달 가능성은 더 이상 자동으로 오지 않았다. 연결 하나가 끊기면 그 공급자에서 유래한 주소가 고립될 수 있고, 외부 연결의 변경은 내부 주소 변경을 강제할 수 있었다.

세 번째 선택지는 하나의 공급자 유래 프리픽스를 기본으로 두고 더 구체적인 도달 가능성을 선택적으로 공개하는 것이었다. 네 번째는 특정 공급자들의 겹치는 고객을 위한 공유 프리픽스를 상상했다. 어느 쪽도 정책을 제거하지 못했다. 다만 추가 상태가 어디에 살아야 하고 누가 조율해야 하는지를 제약할 뿐이었다.

RFC 1887의 요약은 어느 한 옵션보다 더 오래 간직할 가치가 있다. 어떤 해법도 멀티호밍 조직과 트랜짓 도메인, 그 조직에 연결되지 않은 도메인까지 포함하여 서로 다른 실제, 즉 명시적으로 재정적인 비용을 부과한다는 것이다. 공급자들은 비로컬 프리픽스를 수용하고 전파하기 위한 정책을 필요로 하게 된다. 그 정책은 비용을 반영하게 된다.

바로 이 지점에서 주소 할당은 사무적인 선물이 아니게 된다. 안정적인 독립 프리픽스는 한 기업의 리넘버링 프로젝트를 면제해 주는 동시에, 글로벌 라우팅 시스템이 예외 하나를 짊어지게 만든다. 공급자 유래 프리픽스는 집계를 보존하는 대신 고객의 출구 비용을 높인다. 둘 다 기술적으로는 온전하다. 둘 다 공짜는 아니다.

다섯 비트가 레지스트리에 보이는 자리를 만들었다

1997년 1월,RFC 2073은 이 아키텍처를 공급자 기반 형식이라는 제안으로 만들었다. 3비트 형식 프리픽스 뒤에 5비트 Registry ID, 가변 길이 Provider ID, Subscriber ID, 그리고 64비트 구독자 내부 부분이 이어졌다.

명명된 필드들은 할당 형식 안에 기관적 연쇄를 보이게 만들었다. IANA가 주 레지스트리였고 블록을 위임할 수 있었다. 이 문서는 다지역 IANA 풀, RIPE NCC, INTERNIC, APNIC의 식별자를 나열했다. 레지스트리는 공급자·구독자 공간을 어떻게 나눌지 결정하고, 공급자는 구독자 ID를 구조화하며, 구독자는 자기 로컬 부분을 통제하게 된다.

그러나 문서에는 중요한 한계도 있었다. 이 형식이 다른 유니캐스트 형식을 배제하지 않는다는 점, 포워딩은 여전히 최장 프리픽스 매치에 기반하며 라우터가 Registry ID나 Provider ID를 명령으로 해석하지 않는다는 점, 일부 구독자는 레지스트리에서 직접 공간을 받아 연결된 공급자와 독립할 수 있다는 점이 그것이다.

그 필드가 명명한 것은 할당 상의 위치였다. 그것은 계약, 현재 연결성, 라우팅 출처, 실질 소유권, 성공적인 전달을 증명하지 않았다. "공급자"라는 단어가 어느 한 기관에게 그 모든 계층에 대한 영구 권한을 준 것도 아니었다.

레지스트리 필드는 18개월을 버텼다

1998년 7월에 발행된RFC 2374는 RFC 2073을 폐기했다. 주요 변경 사항 중 하나는 레지스트리 비트의 제거였다. 경로 집계에 필요하지 않다는 이유였다. 새 형식은 Top-Level Aggregation, Next-Level Aggregation, Site-Level Aggregation 식별자 뒤에 64비트 인터페이스 식별자를 두었다.

그 개정은 계층 구조를 버린 것이 아니었다. 계층이 무엇을 대표한다고 주장하는지를 바꾼 것이다. 공용 토폴로지는 공급자와 교점(exchange)을 통해 조직될 수 있고, 사이트 토폴로지는 로컬로 남는다. 교점 기반 할당은 장거리 공급자로부터의 독립과 각 공급자에게 별도 프리픽스를 받지 않고도 멀티호밍을 이루는 길로 제시되었다. 그러나 공급자 선택과 이식성을 위한 메커니즘은 명시적으로 범위 밖이었다.

이 구분이 중요하다. 다이어그램은 이식성을 위한 자리를 예약할 수 있지만, 인증, 이전 규칙, 장애 처리, 이전을 완수해야 하는 당사자까지 제공하지는 않는다. 아키텍처적 가능성은 운영상의 결과가 아니다.

2003년 8월,RFC 3587은 RFC 2374와 TLA/NLA 구조를 historic으로 만들었다. 지역 인터넷 레지스트리(RIR)가 정의한 조율된 할당 정책이 고정된 체계를 대체했고, 그 배포 단계에서 TLA/NLA가 기술적으로 최선일 수 없으며 정책은 계속 진화할 것이라고 밝혔다.

남은 것은 더 단순했다. 글로벌 라우팅 프리픽스, 서브넷 ID, 인터페이스 ID. 글로벌 프리픽스는 일반적으로 RIR과 ISP 아래에서 계층적으로 유지되고, 사이트 관리자가 서브넷 필드를 구조화하게 된다. 집계는 살아남았다. 표준 문서는 더 이상 모든 외부 계층에 영구적인 이름을 부여하지 않게 되었다.

리넘버링은 가능했지만 공짜는 아니었다

공급자 기반 할당은 리넘버링을 연결 변경의 대가로 다루는 경우가 많다. IPv6는 그 대가를 줄이는 도구를 제공했다.RFC 4192는 DNS, 라우팅, 구성이 옮겨가는 동안 오래된 프리픽스와 새 프리픽스가 인터페이스 위에 공존하는 make-before-break 절차를 기술했다.

그 절차가 가치 있는 이유는 바로 리넘버링이 한 번의 편집이 아니라 연쇄이기 때문이다. 주소는 액세스 제어 목록, 모니터링 시스템, 애플리케이션 구성, 역방향 DNS, 필터, 문서 안에 박힐 수 있다. 2007년 IAB 워크숍 보고서인RFC 4984는 이러한 의존성 때문에 리넘버링이 어떤 사이트에게는 사실상 불가능할 만큼 어려워졌다고 기록했다.

같은 보고서는 반대편도 다시 진술했다. 공급자 독립 공간은 조직이 공급자 락을 피하는 데 도움이 되고 멀티호밍을 지원하지만, 집계되지 않는 항목을 추가하며 그 라우팅·처리 비용은 디폴트 프리 존 전체에 걸쳐 부담된다. 공급자 할당 공간은 한 공급자에서 집계되지만, 다른 공급자를 통한 광고는 디집계를 강제할 수 있다. 주소 공간이 더 늘어난다고 라우팅 상태 문제가 사라지지는 않았다.

IAB 보고서는 더 깊은 이중 역할을 설명했다. 하나의 IP 주소는 토폴로지를 따라가야 하는 로케이터이면서, 사용자가 안정적으로 유지되기를 원하는 식별자이기도 하다. 하나의 숫자가 모든 경우에 두 기능을 동시에 최적화할 수는 없다. RFC 1887은 이미 청구서를 보여주었고, RFC 4984는 그것이 계속 다시 돌아오는 이유를 설명했다.

깔끔했던/48조차 권고가 되었다가, 덜 깔끔한 권고가 되었다

RFC 3177은 일반적인 경우 최종 사이트에/48할당, 확인된 단일 서브넷에는/64, 확인된 단일 기기에는/128을 권고했다. 동시에 IETF가 사업상 질문에 대한 결정을 내리지 않는다는 입장을 유지하면서도, 기술적 위임 정책이 사업 관계에 큰 영향을 줄 수 있음을 인정했다.

10년 뒤RFC 6177은 그 일률적 권고를 폐기했다. 소수의 고정된 경계가 구현과 운영 관행에 하드코딩될 수 있다는 경고는 클래스풀 사고로의 회귀였다. 사이트가 계획된 용도에 충분한 공간을 받아야 한다는 원칙은 유지하되, 정확한 크기는 운영 판단에 맡겼다.

이것은 우유부단함이 아니었다. 아키텍처가 정밀성이 어디에 속하는지 배우는 과정이었다. 안정적인 포워딩 의미론과 넉넉한 로컬 경계는 표준화될 수 있었다. 반면 정확한 할당 계층, 기관적 라벨, 기본 사이트 크기는 배포가 증거를 공급하는 만큼 변할 여지가 필요했다.

주소가 실제로 증명할 수 있는 것

IPv6 프리픽스는 경로에서 목적지 범위를 식별할 수 있다. 할당 기록은 어느 기관이 언제 위임을 기록했는지를 진술할 수 있다. BGP 관측은 특정 관측 지점에서 어느 자율 시스템이 경로를 발행했는지 보여줄 수 있다. 공급자 계약은 상업적 관계를 입증할 수 있다. 패킷 트레이스는 경로를 보여주고, 애플리케이션 로그는 결과를 보여준다.

이 기록들은 서로 연결될 수 있다. 그러나 상호 교환 가능하지는 않다. 과거의 비트 필드에서 "공급자"를 읽어내 소유권의 증거로 다루는 것은 아키텍처·행정·운영을 한데 뭉개는 일이다. 레지스트리 항목을 현재 도달 가능성의 증거로 다루는 것은 같은 오류를 다른 방향으로 저지르는 것이다.

IPv6 초기 시퀀스는 더 나은 규율을 제시한다. 라우팅상의 이득은 측정 가능하게 유지하라. 기관은 자신이 실제로 수행하는 행위에 대해서만 책임지게 하라. 할당 정책은 개정 가능하게 유지하라. 그리고 이식성이나 복원력이 비용을 만들 때, 그 비용이 어디에 떨어지는지를 주소의 겉보기 영구성 안에 숨기는 대신 기록하라.

출처