요약

  • 외부 호환성 표는AFPUB-2019-V4-003-DRAFT02가 제안한 이전 인계에서 네 가지 서로 다른 실패를 발견했다: ARIN과 APNIC은 출처 준수 규칙에 이의를 제기했고, RIPE NCC는 수신 RIR 개시 순서에 이의를 제기했으며, LACNIC은 상호주의를 요구하지 않았음에도 두 불일치를 모두 확인했다.
  • 문서의 정확한 정체성을 확인하는 것이 필수적이다.AFPUB-2019-V4-003-DRAFT02는 2020년 8월 13일에 제출되었으며, 2021년 10월 8일은 별개의AFPUB-2020-GEN-006-DRAFT02계보에 속한다.
  • 초안 2는 제안되고 논의되고 평가되고 보관되었다. 조건부 대략적 합의 발표나 최종 검토(last call) 어느 것도 그것을 채택·비준·구현·운영 단계로 만들지 못했다.
  • AFRINIC은 자신이 책임지는 기록을 적법하게 인증하고 갱신하며, 호환되는 RIR과 조정하고 종속 시스템을 준비할 수 있었다. 그러나 다른 레지스트리의 규칙을 면제하거나 관리 재량을 호환성의 대체물로 삼을 수는 없었다.
  • 신뢰할 수 있는 대안은 버전이 명시된 양자 간 호환성 인증서였다. 누가 각 당사자를 인증하는지, 요청이 어디에서 시작되는지, 어느 정책 버전이 적용되는지, 모든 레지스트리 및 라우팅 보안 기록이 어떻게 원자적으로 바뀌는지를 명시하는 인증서다.

L3 — 정렬되지 않은 네 개의 수신 레일

초안 2 기록에서 가장 많은 것을 드러내는 산출물은 네 개의 다른 지역 인터넷 레지스트리에서 나온 답변 표다. AFRINIC의 제안은 자원이 서비스 지역으로 들어오고 나가는 경로를 설명했다. 그러나 제안된 경로가 이동의 나머지 절반을 완성해야 할 기관에 도달했을 때, 각 연결은 불일치를 드러냈다. 한 레지스트리의 페이지에 보이는 것처럼 보인 차선은 두 레지스트리 사이의 실행 가능한 차선이 아니었다.

ARIN의 응답은 출처에 관한 문장으로 향했다. 초안 2는 출처가 어느 RIR에 등록된 IPv4 자원의 현재 권리자여야 하며 수신 RIR의 정책을 준수해야 한다고 말했다. ARIN은 그 조건이 자사의 inter-RIR 정책과 양립할 수 없다고 보았다. APNIC도 같은 기본 결론에 도달했다. 그 평가는 해당 문구가 초안 2와 초안 3에 공통으로 존재한다고 밝히고 그 배치가 호환되지 않는다고 판단했으며, 특히 출처가 수신 레지스트리의 규칙을 준수하도록 요구한다는 점을 문제로 삼았다.

RIPE NCC는 다른 실패 지점을 확인했다. 5.7.5절은 이전 당사자에게 표준 템플릿과 공식 이전 합의를 사용해 요청을 수신 RIR로 보내라고 지시했다. 수신 RIR이 승인한 뒤 그 레지스트리가 이전 RIR, 출처 및 수신자에게 알리고 자원이 이전될 것이라는 내용이었다. 반면 RIPE NCC의 절차는 당시 자원이 등록되어 있던 RIR에서 시작했다. 따라서 RIPE NCC는 초안 2의 순서를 호환되지 않고 구현 불가능하다고 보았다. 이견은 이동을 허용하려는 목표 자체에 관한 것이 아니었다. 그것은 첫 번째 권위 있는 행위, 즉 출처 기록과 그 보유자를 검증할 수단이 다른 곳에 있을 때 어느 레지스트리가 요청을 받는가에 관한 것이었다.

LACNIC은 상호주의 요구를 부과하지 않았으므로 그 응답은 특히 유용하다. 상호주의 요구가 없다고 해서 설계가 들어맞게 되지는 않았다. LACNIC은 여전히 출처가 다른 RIR의 정책을 준수하도록 요구하는 것은 거의 의미가 없다고 밝혔고, 제안된 수신 RIR 개시 방식이 다른 inter-RIR 배치와 맞지 않는다고 보았다. 다시 말해, 하나의 가능한 정책 장벽을 제거해도 운영 순서가 고쳐지지는 않았다. 레지스트리는 원칙적으로 개방적일 수 있으면서도 초안대로 인계를 수행할 수는 없었다.

그 네 답변은 명시적으로AFPUB-2019-V4-003-DRAFT02에 연결되어 있었다. 그것들은 모든 자원 이전에 대한 일반적 평결도, 이후의 모든 버전이 실패할 것이라는 판정도 아니었다. 호환성은 텍스트에 붙는다. 즉 시행 중인 조항, 이동 방향, 자원의 종류와 상태, 각 레지스트리의 현재 정책, 그리고 그 직원들이 실제로 사용하는 단계에 붙는다. 그 입력 중 하나라도 바뀌면 시험을 다시 실행해야 한다.

그 정밀성은 제안의 정체성에서 시작된다. 여기에서 검토한 초안 2는AFPUB-2019-V4-003-DRAFT02, 버전 2.0으로, AFRINIC의 통합 정책 매뉴얼 5.7절을 개정하기 위해 2020년 8월 13일에 제출된 자원 이전 정책이다. 한 계획 기록은 그 식별자를 2021년 10월 8일과 짝지었지만, 더 늦은 날짜는 별개의 제안인AFPUB-2020-GEN-006-DRAFT02에 속한다. 식별자와 날짜는 섞일 수 없다. 한 문서에 붙은 호환성 결론은 둘 다 번호 자원 이전을 다룬다는 이유만으로 다른 문서로 옮겨갈 수 없다.

같은 절제가 제도적 지위에도 적용된다. 초안 2는 제안되고 논의되고 평가되었으며 결국 보관되었다. 그것은 2020년 9월 17일 AFRINIC-32에서 발표되었다. 9월 21일 공동 의장 요약은 조건부 대략적 합의와 최종 검토를 발표하고, ARIN 관련 상호주의 우려를 식별하며, 개정을 요구했다. 그것들은 비공개 정책 개발 과정의 단계였다. 그것들은 단독으로 또는 함께 그 텍스트를 매뉴얼에 넣거나 이사회 비준을 확보하거나 구현된 이전 규칙을 만들어내지 못했다. 같은 날짜에 초안 3이 등장한 것은 텍스트가 여전히 움직이고 있었음을 확인해 준다. 이후 초안은 이후 초안으로 남고, 2021년에 제출된 별개 제안은 별개로 남는다. 그 다른 계보에서 세 번째 초안이 이후 비준되었다는 사실은 이 초안 2에 대한 빠진 구현 증거를 제공하지 않는다.

이 제안이 이동 가능하게 만들려던 것

초안 2는 실제 격차에서 출발했다. 기존 배치는 양방향 inter-RIR 메커니즘을 지원하지 않았다. 제안은 AFRINIC 지역 내 이전, 지역으로의 이전, 지역 밖으로의 이전을 모색했고, 문제 설명에서 IPv4 주소와 AS 번호를 언급했다. 그것은 영구적 지역 포획 체제보다 더 개방적인 상업적 표면을 제공했다. 기존의 12개월 대기 제약을 제거하고, 송신자와 수신자가 상호 합의에 도달한 경우 이전·할당·지정되는 수량에 상한을 두지 않을 것을 제안했으며, 현행 정책을 조건으로 했다.

초안이 모든 점검을 포기한 것은 아니다. 수신 이전의 경우 AFRINIC은 필요성 기반 평가를 유지하고 당시 시행 중인 정책에 따라 수신자의 IPv4 필요성을 승인할 것이었다. 송신 이전의 경우 텍스트는 이전이 수신 RIR의 정책을 따라야 한다고 밝혔다. 수신자는 송신자와 이전 합의에 도달한 어떤 당사자도 될 수 있었다. 이전된 IPv4 레거시 자원은 더 이상 레거시 자원으로 취급되지 않게 될 것이었다. 이 조항들은 이동성, 자격 심사, 레지스트리 지위의 명시적 변경을 결합하려는 시도를 보여준다.

그러나 조항들은 그 결정들이 의존하는 사실을 누가 확립할 수 있는지를 정하지 않았다. AFRINIC 직원은 출처가 아무 관계도 없는 수신 RIR의 정책을 왜 준수해야 하는지 물었다. 그들은 또한 출처가 출처 기록을 보유한 레지스트리가 아니라 수신 RIR에 직접 신청하면 출처 보유자 검증을 완료할 수 없다고 말했다. 그것은 나중에 상대 응답에서 드러나는 것과 같은 구조적 단절이다. 수신 RIR은 의도된 수신자를 평가할 능력이 있을 수 있지만, 그렇다고 해서 출처의 통제를 확립하는 데 필요한 기록, 관계 또는 인증 수단을 얻는 것은 아니다.

직원 평가는 추가적인 불확실성을 발견했다. 제안된 표준 템플릿이 전 세계적으로 수용되는지 물었다. 분쟁 중인 자원에 대한 지침이 없다고 보았고 반복 할당 남용을 경고했다. 수신자 조항 5.7.4.1과 5.7.4.2 사이의 충돌을 확인했다. 넓은 문구는 이전 합의가 있는 어떤 당사자도 허용했지만, AFRINIC 지역 수신자에 대한 직원의 해석은 AFRINIC 회원 자격과 필요성 평가를 요구했다. 평가는 또한 ASN이 문제 요약에는 등장하지만 실제 IPv4 조항에는 등장하지 않는다고 지적했다. 그 초안 작성 격차는 목적 진술만으로는 다른 자원 클래스에 대한 실행 가능한 규칙을 제공하지 않는다는 점에서 중요했다.

각 쟁점은 단순한 문장이 아니라 인계에 닿는다. 분쟁 중인 프리픽스는 분쟁을 보존할 합의된 방법 없이 등록 상태를 안전하게 바꿀 수 없다. 정의되지 않은 템플릿이 모든 상대가 요구하는 증거를 담는다고 가정할 수 없다. 수신자 자격에 관한 충돌은 직원에게 안정적인 결정 규칙을 남기지 않는다. ASN을 실제 조항 없이 언급하는 것은 동일한 점검, 상태, 종속 기록이 적용되는지에 대한 답을 미해결로 남긴다. 무제한 수량도 어느 정확한 객체가 이동 중이며 각 순간 어느 원장이 권위 있는지 알아야 할 필요를 없애지 않는다.

정책 문장 뒤의 기계장치

AFRINIC의 직원 평가는 운영 표면을 유난히 드러냈다. inter-RIR 이전은 MyAFRINIC 이전 도구, 역방향 DNS, RPKI 경로 출처 승인, 이전 로그, 티켓 시스템의 변경을 잠재적으로 요구할 수 있었다. 직원은 프로세스 검토, 호환 정책을 가진 RIR과의 조정, 더 많은 회원 서비스 역량, 소프트웨어 엔지니어링 작업을 예상했다. 따라서 자원이 ‘이전될 것’이라고 말하는 텍스트는 일련의 연결된 행위를 압축한다.

레지스트리 기록은 하나의 일관된 상태에서 다른 상태로 이동해야 한다. 출처 통제는 인증되어야 한다. 수신자 자격과 적용 가능한 필요성 시험은 관련 규칙과 관계를 가진 기관에 의해 결정되어야 한다. 두 RIR은 양쪽 모두 승인으로 인식하는 메시지를 필요로 한다. 등록 정보는 두 레지스트리가 모두 권위 있는 것처럼 보이거나 둘 다 아닌 순간을 만들지 않고 변경되어야 한다. 역방향 DNS 위임과 RPKI 상태는 의도된 보유자를 따라야 한다. 공개 이전 이력과 내부 티켓은 무슨 일이 왜 일어났는지 보존해야 한다. 종속 변경 하나가 실패하면 조직은 인정을 중복시키거나 자원을 고립시키지 않는 롤백 상태를 필요로 한다.

이 때문에 네 개의 답변을 AFRINIC 경영진에게 예외를 만들라는 초대로 읽는 것은 타당하지 않다. 관리자는 AFRINIC의 적법한 운영 범위 안에서 업무를 지시할 수 있다. 경영진은 AFRINIC이 보유한 기록이 검증되었는지, AFRINIC 시스템이 준비되었는지, 직원이 상대와 합의된 증거를 교환하는지 보장할 수 있다. 그러나 ARIN이 ARIN 정책이 인정하지 않는 출처 조건을 받아들이게 하거나, RIPE NCC가 절차의 잘못된 끝에서 사건을 시작하게 하거나, 주장만으로 출처와 수신 레지스트리 사이에 인증 관계를 만들 수는 없다.

실질적 노출은 기록이 완료된 손실을 입증하지 못하더라도 운영자에게 떨어진다. NRS의 이전 관행 설명은 레지스트리 계정, 승인, 회원 자격 상태, 문서화, 해당 RIR에서 적용되는 정책의 중요성을 강조한다. LARUS는 인프라 운영자의 관점을 추가한다. 거버넌스 결정은 네트워크가 의존하는 기록과 종속성을 통해 조용히 연속성과 거래 계획에 영향을 줄 수 있다. 여기에 신중히 적용하면 그 관점들은 모호한 인계가 왜 실사, 지연, 연속성 위험을 만드는지 보여준다. 그것들은 초안 2가 장애, 거절된 거래, 가격 손실 또는 특정 고객 피해를 초래했다고 입증하지는 않는다. 이용 가능한 기록은 설계 비호환성과 구현에 필요했을 작업을 입증할 뿐, 실제 운영 사고를 입증하지 않는다.

공정한 해석과 그 한계

가장 강한 선의의 설명은 조건 따지기 없이 진술될 가치가 있다. 작성자들은 실제 경제적·운영적 문제를 보았다. IPv4 희소성은 자원을 지역 시스템 사이로 이동할 수 있는 능력의 가치를 높였다. AFRINIC은 지역 내 경로는 있었지만 제안이 모색한 양방향 inter-RIR 경로는 없었다. 초안 2는 수신 자원에 대한 필요성 검토와 송신 이전에 대한 정책 준수를 유지하면서 수량과 대기 제약을 완화하려 했다. 그것은 언어와 절차가 동일하지 않은 다섯 기관에 걸쳐 요청, 합의, 승인, 통지 순서를 설명하려 했다. 상대 답변에는 시간이 걸리며, 초안 작성 오류가 장악, 악의 또는 제도적 권한 확대 계획을 입증하지는 않는다.

그 설명은 제안이 시도할 가치가 있었던 이유를 설명한다. 그러나 맞지 않는 인터페이스를 작동하는 인터페이스로 바꾸지는 않는다. 다른 레지스트리가 절차를 열 때 멈추는 이동성 약속은 아직 이동성이 아니다. 답은 이동을 포기하는 것도, 관리자가 불일치를 우회해 승인하게 하는 것도 아니었다. 정확한 버전을 고정하고, 각 상대에게 각 방향을 시험하도록 요청하고, 양쪽이 동일한 권위 있는 변경을 실행할 수 있을 때까지 인계를 수정하는 것이었다. 호환성은 빠져 있던 엔지니어링 속성이었다.