요약

  • RFC 1900은 IP 주소를 변경할 권한과, 그 주소를 참조하는 모든 시스템을 찾아내고 갱신할 수 있는 능력을 분리했습니다. 공급자 집계로 인해 리넘버링이 필요할 수 있지만, 그 결과로 생기는 작업은 할당 기록을 훨씬 넘어 확장됩니다.
  • 도메인 이름은 이름-주소 결합을 사용 시점까지 미룸으로써 하드코딩된 주소의 수를 줄였습니다. 그러나 이는 캐시가 만료되고, 애플리케이션이 다시 조회하고, ACL이 갱신되고, 역방향 DNS가 따라가고, 다른 관리자가 의존 시스템을 갱신한다는 것을 증명하지는 않습니다.
  • 이후의 리넘버링 RFC들은 이 경고를 라우터, DNS, DHCP, 보안 연결, 관리 도구, 애플리케이션 API, 흩어진 설정에 이르는 재고 관리 문제로 만들었습니다. 따라서 완료는 새 프리픽스만이 아니라 결합된 운영 증거를 요구합니다.

변경 지시는 자신의 의존성을 볼 수 없었다

RFC 1900은 주소가 이동하는 평범한 이유로 시작합니다. 호스트가 서브넷을 옮길 수 있고, 과부하 걸린 서브넷은 분할될 수 있으며, 조직은 주소 계획을 재설계할 수 있습니다. 더 큰 영향을 미치는 사례는 공용 라우팅 시스템에서 나왔습니다. CIDR 집계를 통해 공급자는 수많은 고객 경로 대신 하나의 큰 블록을 광고할 수 있게 되었습니다. 고객이 그 공급자를 떠나면서 기존 집계의 더 구체적인 조각을 계속 광고하면, 더 넓은 인터넷에 라우팅 상태를 부과하게 됩니다. 리넘버링은 지역 작업을 글로벌 집계와 맞바꾸는 일입니다.

그러나 그 맞바꿈은 공급자에게 이동을 완료할 수 있는 명령을 주지 않습니다. 공급자는 새 프리픽스를 할당하고 기존 프리픽스의 전송을 중단할 수 있습니다. 고객은 인터페이스 주소와 경로를 바꿀 수 있습니다. 그러나 어느 쪽도, 수년 전 엔지니어가 기존 주소를 방화벽 규칙, 모니터링 대상, 프린터 프로필, 라이선스 파일 또는 파트너의 허용 목록에 입력했다는 사실을 자동으로 알지 못합니다.

이것이리넘버링이라는 단어 안에 숨어 있는 통제 표면입니다. 결정은 압축적이지만, 의존성 그래프는 그렇지 않습니다. 할당 기록은 어떤 번호를 사용할 수 있는지 말합니다. 경로는 프리픽스가 어디에 광고되는지 말합니다. 장치 설정은 한 시스템이 무엇을 할지 말합니다. 애플리케이션 결과는 특정 교환이 작동했는지 말합니다. 이 기록들은 서로 연관되어 있지만, 어느 것도 다른 것을 포함하지 않습니다.

RFC 1900은 당시의 절차를 비용이 많이 들고, 번거롭고, 오류가 발생하기 쉽다고 묘사했습니다. 또한 도구와 문서화된 경험이 희소하다고 밝혔습니다. 이는 단순히 미성숙한 소프트웨어에 대한 불만이 아니라 지식 문제를 지적했습니다. 운영자는 찾을 수 없는 참조를 갱신할 수 없고, 어떤 주소 권한 기관도 독립적인 시스템들이 만들어낸 참조의 완전한 색인을 보유하지 못합니다.

DNS는 결합을 옮겼을 뿐, 모든 믿는 이를 옮기지는 않았다

이 문서의 가장 오래 지속된 제안은 이름과 주소를 구분하는 것이었습니다. DNS 네임스페이스는 주소 공간과 독립적입니다. 이름은 보통 호스트의 기능이나 조직적 정체성을 따르고, 주소는 주소 및 라우팅 구조 안에서 인터페이스의 위치를 나타냅니다. 설정이 이름을 저장한다면, 해석은 실행 시점에 그 이름을 현재 주소에 결합할 수 있습니다. 그러면 매핑 변경은 모든 파일에 복사하는 대신 DNS에 집중될 수 있습니다.

그러나 이는 상태의 폐지가 아니라 결합의 감소입니다. DNS 운영자는 권위 있는 레코드를 통제합니다. 재귀 리졸버는 적용 가능한 수명이 끝날 때까지 캐시된 답을 통제합니다. 애플리케이션은 다시 조회할지 아니면 어제의 답을 유지할지 결정합니다. 역방향 DNS는 공급자에 속할 수 있습니다. 보안 제품은 그 결과를 자체적인 단계적 갱신이 필요한 ACL로 바꿀 수 있습니다. 파트너는 해석된 주소를 리넘버링 조직이 검사할 수 없는 시스템에 복사해 두었을 수 있습니다.

RFC 1900 자체도 이 경계를 유지했습니다. 동적으로 할당된 이름과 주소에는 신속한 동적 DNS 갱신이 필요했습니다. 인증된 갱신 작업은 아직 발전 중이었습니다. 주소 리터럴만 받아들이는 레거시 소프트웨어는 선언으로 이름 인식형이 될 수 없으므로, RFC는 그 주소가 담긴 파일을 이름 기반 소스에서 자동 생성할 것을 권고했습니다. 권위 있는 입력에는 이름이 담기고, 통제된 조회가 피할 수 없는 리터럴을 만들어냅니다.

IP에 묶인 라이선싱에 대한 반대 권고는 같은 문제를 상업적 형태로 드러냈습니다. 주소를 기계 정체성으로 취급하는 라이선스는 라우팅 좌표를 자물쇠로 바꿉니다. 주소 권한 기관은 좌표를 바꿀 수 있지만, 승인 규칙은 라이선서만 바꿀 수 있습니다. 기술적 리넘버링과 소프트웨어 계속 사용 허가는 별개의 거래가 되었습니다.

이후의 가이드들은 하나의 번호를 하나의 재고로 만들었다

다음 해에 발표된 RFC 2071은 그 작업을 눈에 보이게 만들었습니다. 리넘버링은 PC, 워크스테이션, 프린터, 파일 서버, 터미널 서버, 라우터에 영향을 미칠 수 있습니다. DNS 서버 설정, SNMP 관리 스테이션, 접근 제어 목록의 변경이 필요할 수도 있습니다. 공급자가 부여한 유예 기간 동안 기존 주소와 새 주소가 공존할 수 있지만, 공존 자체는 무엇이 놓쳤는지 알려주지 않습니다.

RFC 2072는 라우터 측면을 계획 학문으로 확장했습니다. 주소 구조는 기본 및 고정 경로, 내부 라우팅, BGP, 터널, 필터, 관리 시스템, 네임 서비스, 회계, 보안 통제에 이릅니다. 어떤 하나의 명령보다 그 폭이 더 중요합니다. 경로 정책 소유자, DNS 관리자, 애플리케이션 운영자가 각자 자신의 몫을 완료하더라도 서비스는 여전히 그들 사이의 경계에서 실패할 수 있습니다.

IPv6는 이후 더 깔끔한 중복 절차를 제공했습니다. RFC 4192는 새 프리픽스를 추가하고, 두 프리픽스가 함께 작동하도록 허용하고, 사용을 이동시킨 뒤 기존 프리픽스를 제거하는 절차를 다루었습니다. 이는 인터페이스 변경을 DNS와 조율했고 TTL을 사용해 전파를 관리했습니다. 그럼에도 이 RFC는 여전히 행정 도메인 간 자동화가 어려운 작업, 특히 DNS 설정과 역방향 존 신뢰를 발견했습니다. 가끔만 사용되는 장치가 기존 프리픽스가 사라진 후에야 드러날 수 있다고 경고했습니다.

중복 기간은 관찰 기간을 만들어 주기 때문에 유용합니다. 그러나 완전성의 증명은 아닙니다. 침묵하는 장치, 월 단위 작업 또는 외부 허용 목록은 두 프리픽스가 모두 작동하는 동안에는 자신의 의존성을 행사하지 않을 수 있습니다. 이후의 제거가 시험이지만, 실패를 통해서만 놓친 참조를 발견하는 것은 이전을 통제하는 것과 다릅니다.

14년 뒤, 제목에 한 단어가 더해졌다

RFC 5887의 제목은Renumbering Still Needs Work였습니다. 2010년까지 DHCP, IPv6 자동 구성, DNS 도구, 관리 관행이 발전했습니다. 그럼에도 남은 실패들은 RFC 1900의 원래 경계를 따라갔습니다.

강력한 자산 관리를 갖춘 사이트는 통제된 데이터베이스에서 DHCP 및 DNS 입력을 재생성할 수 있습니다. 약한 자산 관리를 가진 사이트는 손으로 편집하며 혼란을 견뎌야 합니다. 하나의 고정되고 수동으로 설정된 호스트만으로도 완전한 자동화가 무너질 수 있습니다. 임베디드 시스템은 주소를 읽기 전용 메모리, 심지어 물리적 스위치에 보관할 수도 있습니다.

애플리케이션은 더 덜 보이는 상태 계층을 더했습니다. RFC 5887은 257개의 Standards-Track 또는 Experimental 애플리케이션 프로토콜 RFC 중 34개에서 명시적인 주소 의존성을 발견한 검토를 인용했습니다. 그 수치는 검토된 사양을 기술할 뿐 모든 소프트웨어를 말하지 않습니다. 더 어려운 점은 사양 검토만으로는 구현체가 주소를 무기한 캐시하는지, 사전 저장소에 기록하는지, 라이선스·URL·쿠키·프록시 설정을 그 주소에 결합하는지 알 수 없다는 것입니다.

도메인 이름을 사용하는 것조차, 애플리케이션이 시작 시 한 번만 조회하고 DNS 수명을 결코 존중하지 않는다면 불충분합니다. 소켓 인터페이스는 유효 기간 없이 프로그램이 하위 계층 주소를 받아 조작하도록 유도합니다. 어떤 애플리케이션은 재시도, 반복 조회, 대체 사용을 올바르게 수행하고, 어떤 것은 그렇지 않습니다. 보안은 치료를 의도적으로 복잡하게 만들 수 있습니다. DNS 피닝은 브라우저 공격에 저항하기 위해 주소 변경을 제한하며, 보호적 이유로 낡은 결합을 유지합니다.

RFC 6879는 FQDN, 서비스 검색, 매개변수화된 설정, 체계적인 DNS 절차를 권고했습니다. RFC 7010은 자동화를 프리픽스 관리, 주소 구성, 주소 관련 항목 갱신, 이벤트 조율로 나누었습니다. 그럼에도 모든 하위 시스템과 외부 데이터베이스를 갱신할 수 있는 단일 창구 메커니즘은 여전히 없었습니다. 이 RFC는 로그 수집기가 기존 주소에서 새 주소로의 매핑을 받지 않으면 새 소스 주소를 새 장치로 취급할 수 있다고 언급했습니다. 주소는 또 다른 시스템에서 우연히 만들어진 식별자가 되었습니다.

완료된 리넘버링은 결합된 주장이다

할당 결정은 새 좌표를 사용할 수 있다는 것을 증명합니다. 인터페이스와 라우팅 기록은 특정 시스템이 그 좌표를 사용할 수 있음을 증명합니다. DNS 증거는 지정된 정방향 또는 역방향 매핑이 변경되었음을 증명합니다. 설정 증거는 알려진 참조가 대체되었음을 증명합니다. 애플리케이션 테스트는 선택된 시점의 선택된 거래를 증명합니다. 외부 확인은 명명된 상대방이 자신의 통제를 갱신했음을 증명합니다. 철회 관찰은 기존 경로나 주소가 더 이상 의도된 경로에 사용되지 않음을 증명합니다.

어떤 단일 영수증도 이 집합이 완전하다는 것을 증명하지 못합니다. 실용적 기준은 소유자, 타임스탬프, 부정적 증거를 갖춘 재고입니다. 즉, 통제된 저장소를 검색하여 남은 리터럴이 없음을 확인하고, 정당화된 관찰 기간 동안 기존 주소를 사용하는 필수 트래픽이 없음을 텔레메트리로 확인하고, 독립적인 경로에서 테스트하고, 평소 침묵하는 시스템을 명시적으로 다루는 것입니다.

이는 기존 주소를 영구적으로 만드는 것이 아닙니다. 또한 이탈 비용이 공급자 의존적 프리픽스를 이를 계속 유지할 무조건적 권리로 바꾸지도 않습니다. 이는 이동을 요구할 권한과 그것을 실행할 능력이 서로 다른 주체에게 속한다는 뜻입니다. 회복탄력적인 시스템은 공급자 변경, 합병 또는 토폴로지 결정이 이 분열을 비상사태로 바꾸기 전에 그 분열을 드러냅니다.

RFC 1900의 지속된 통찰은 이름이 좋고 번호가 나쁘다는 것이 아니었습니다. 좌표가 소프트웨어, 정책, 기억이 조용히 그것을 정체성으로 승격시킬 때 위험해진다는 것이었습니다. 번호를 바꾸는 것은 행정적 행위입니다. 그 번호를 믿는 모든 것을 찾아내는 것이야말로 리넘버링을 엔지니어링으로 만듭니다.

출처