요약

  • ARIN의 현재 IRR 개요는 객체를 단순(simple) 클래스와 고급(advanced) 클래스로 나눕니다. 생성 또는 마이그레이션 경로가 객체를 ARIN Online, XML REST, RPSL REST 중 어느 방식으로 관리하는지 결정합니다.
  • 마이그레이션된 IRR 이메일 객체는 ARIN Online에서 조회하고 삭제할 수 있지만 편집은 RPSL REST 경로로만 가능합니다. Online에서 삭제 후 재생성하면 교정 작업이 새로운 객체 계보가 됩니다.
  • 현재 ARIN의 두 페이지는 Online에서 생성된 객체를 RPSL REST로 관리할 수 있는지에 대해 서로 다르게 설명합니다. 인증된 객체를 테스트하기 전까지 이 불일치는 문서 증거일 뿐이며 프로덕션 동작의 증명이 아닙니다.
  • 간결한 전환 영수증은 API 키, 직원 신원 또는 비공개 토폴로지를 노출하지 않으면서 사전 객체 해시, 클래스, 채널, 작업, 사후 객체 해시 및 대체 링크를 보존할 수 있습니다.

출처가 지워버리는 편집 버튼

ARIN의 인터넷 라우팅 레지스트리(IRR) 문서에서 가장 많은 것을 보여주는 항목은 실패 메시지가 아니라 권한 조합입니다. 조회 가능, 편집 불가, 삭제 가능. ARIN에 따르면 과거 이메일 기반 IRR 시스템에서 마이그레이션된 객체는 ARIN Online에서 조회하고 삭제할 수 있지만 그곳에서 수정할 수 없습니다. 웹 인터페이스로 관리하려는 권한 있는 운영자는 객체를 삭제한 뒤 다시 생성해야 합니다.ARIN IRR 사용자 가이드

이 절차는 어색한 인터페이스 우회처럼 보일 수 있습니다. 그러나 그 이상으로 중요한 의미를 갖습니다. 기존 객체는 ARIN이 고급(advanced)이라 부르는 클래스에 속합니다. 즉 RPSL REST를 통해 생성되었거나 IRR 이메일 마이그레이션으로 들어온 객체입니다. ARIN Online에서 다시 만든 대체 객체는 단순(simple) 클래스에 속합니다. 공개 라우팅 정책 속성을 동일하게 다시 입력할 수 있지만, 객체를 어떻게 변경할 수 있는지에 대한 레지스트리의 설명은 한 채널 클래스에서 다른 채널 클래스로 옮겨갑니다.

여기서 검토한 페이지 어디에도 운영자가 객체를 잃었다거나, 경로가 변경되었거나, ARIN이 그런 전환을 잘못 처리했다는 내용은 없습니다. 어떤 계정이나 객체도 테스트하지 않았습니다. 증거는 ARIN 자체가 공개하는 관제 모델입니다. 이 모델은 생성 이력을 미래의 권한의 일부로 만듭니다.

이것이 본질적으로 결함은 아닙니다. 마이그레이션이 레거시 기록이 더 신식으로 태어났다고 거짓으로 주장할 수는 없습니다. 인코딩별 검증 때문에 어떤 편집은 한 경로에서는 안전하고 다른 경로에서는 모호할 수 있습니다. ARIN은 마이그레이션된 객체가 새 시스템의 더 엄격한 검증을 통과했으며 인터페이스의 표시로 식별된다고 설명합니다. 출처를 유지하는 것은 신중한 선택일 수 있습니다. 편집적 질문은 더 좁습니다. 지원되는 해결책이 객체를 삭제 후 재생성하는 것일 때, 두 기록 사이의 연속성이 어디에서 명시적으로 드러나는가?

하나의 레지스트리, 두 개의 객체 클래스, 세 개의 관제면

ARIN의 현재 IRR 개요는 단순 객체와 고급 객체를 구분합니다. 단순 객체는 ARIN Online에서의 생성 또는 XML을 사용하는 REST 생성과 연관됩니다. 해당 표에서 이 객체들은 두 장소 모두에서 생성·조회·편집·삭제 권한을 갖고 RPSL REST 경로로는 권한이 없습니다. 고급 객체는 RPSL을 사용하는 REST를 통해 생성되거나 IRR 이메일에서 마이그레이션된 것입니다. 이 객체들은 RPSL REST로 전체 권한을 갖고, XML REST 권한은 없으며, ARIN Online에서는 조회·삭제 권한만 있습니다.ARIN IRR 개요

이 명칭은 서열로 읽으면 오해를 낳을 수 있습니다. “고급”이 라우팅 주장이 더 정확하거나 더 널리 받아들여지거나 더 최신이라는 뜻이 아닙니다. “단순”이 그 아래 정책이 하찮다는 뜻도 아닙니다. 이들은 관제 클래스입니다. ARIN은 또한 이 구분이 데이터 조회 형식을 바꾸지 않는다고 설명합니다. 질의 출력은 RPSL입니다.

이 구분이 중요한 이유는 공개 객체와 쓰기 경로가 서로 다른 질문에 답하기 때문입니다.route객체는 어떤 ASN이 프리픽스를 시작한다고 진술할 수 있습니다.route6객체는 IPv6에 대해 같은 역할을 합니다.aut-num,as-set,route-set객체는 라우팅 정책의 다른 부분을 표현할 수 있습니다. 보이는 RPSL은 레지스트리 기록이 무엇을 주장하는지 소비자에게 알려줍니다. 유지보수자가 그 주장을 확립하기 위해 웹 폼, XML, RPSL 페이로드 중 무엇을 사용했는지는 알려주지 않습니다.

또한 BGP가 실제 무엇을 하는지 증명하지도 않습니다. RFC 2622는 IRR 객체에 사용되는 라우팅 정책 명세 언어를 정의합니다. 정책을 기록하기 위한 문법을 제공할 뿐 현재 경로 전파의 측정은 아닙니다. 객체가 잘 정의되어 있으면서 네트워크가 다른 것을 광고할 수 있고, 모든 레지스트리 소비자가 하나의 IRR 기록을 결정적으로 취급하지 않으면서 실제 광고가 존재할 수도 있습니다.RFC 2622

따라서 쓰기 채널은 출처와 인가의 영역에 속합니다. 이 정보는 어떤 사람이 레지스트리 주장을 변경할 수 있었는지, 어떤 검증기 아래에서, 어떤 인터페이스를 통해였는지 답하는 데 도움이 되기 때문에 가치가 있습니다. 그 관리 사실이 라우팅 진실로 부풀려질 때만 위험해집니다.

마이그레이션 경계를 방어해야 하는 이유

ARIN의 구현 노트는 이 구분을 실제 전환기에 위치시킵니다. 과거 이메일 시스템의 기록이 모두 같은 목적지로 들어간 것은 아닙니다. ARIN 관리 자원과 연관되어 검증된 기록은 ARIN의 권위 있는 IRR 환경으로 마이그레이션되었고, 다른 기록은 ARIN-NONAUTH에 놓였습니다. ARIN은 또한 조직이 웹 또는 REST 서비스를 사용하기 시작하면 과거 IRR 이메일 업데이트 경로가 영구적으로 비활성화된다고 설명합니다.ARIN IRR Online 구현 노트

일방향 전환은 합리적인 관제일 수 있습니다. 두 개의 쓰기 주체를 무기한 지원하면 어느 검증 규칙, 자격 증명, 마지막 쓰기 의미론이 객체를 지배하는지 모호해집니다. 현대적 작업 이후 이메일 경로를 닫으면 이러한 분열을 줄입니다. 마이그레이션 객체를 표시하는 것은 또한 바이트가 검증을 통과했다는 이유만으로 오래된 출처를 새 인터페이스로 세탁하는 것을 피합니다.

페이로드 언어를 분리해 두어야 할 운영적 이유도 있습니다. 구조화된 웹 또는 XML 폼은 유한한 필드와 관계 집합을 강제할 수 있습니다. RPSL은 객체 문법과 자유 형식 속성이 고유한 파싱 규칙을 갖는 도메인 언어입니다. ARIN이 웹 왕복이 모든 고급 RPSL 표현을 보존한다고 보장할 수 없다면, Online 편집을 거부하는 것이 조용히 단순화하는 것보다 안전합니다.

이 방어 논리는 비례하는 해결책이 무엇인지 바꿉니다. 답이 반드시 “모든 객체 옆에 편집 버튼을 놓아라”는 아닙니다. 원본 객체를 충실히 표현할 수 없는 편집면은 거짓 편의입니다. 더 나은 질문은 운영자가 채널을 사용할 수 없는 이유를 볼 수 있고, 정규화된 사전 이미지를 내보내고, 지원되는 전환을 알고서 선택하며, 후속 기록을 대체 대상과 연결하는 증거를 유지할 수 있는가입니다.

삭제 후 재생성은 하나의 전환이다

삭제는 편집과 다른 실패 형태를 갖습니다. 편집은 하나의 지속 신원 아래 하나의 정규화된 객체 해시에서 다른 해시로의 전환으로 서술되는 경우가 많습니다. 삭제 후 재생성에는 기존 객체가 부재하는 구간, 새로운 검증 트랜잭션, 후속 객체가 수용되지 않거나 모든 하류 소비자가 동시에 관찰하지 못할 가능성이 들어갑니다.

이 자료는 그런 구간이 라우팅 또는 필터링 사건을 일으켰다는 것을 보여주지 않습니다. 이 워크플로우에 대한 시간 분포, 객체 수, NRTM 시리얼 동작은 공개되지 않습니다. 그 사실들은 미지로 남아 있어야 합니다. 그러나 관제의 차이는 피해가 측정되기 전에도 존재합니다. 운영자는 연속성을 한 쌍의 작업으로 교체하라는 요청을 받습니다.

보이는 속성을 수동으로 복사하면 작은 변화는 의도적일 수도, 우연일 수도, 검증기가 요구한 것일 수도 있습니다. 객체 키가 재사용되면 독자는 생성 클래스가 바뀌었는데도 같은 레지스트리 객체처럼 보이는 것을 볼 수 있습니다. 키가 바뀌면 소비자는 새 기록이 기존 기록을 대체하려는 것임을 이해할 다른 방법이 필요합니다. 폼의 스크린샷은 지속 가능한 답이 아닙니다. 하류 시스템이 열람할 수 없는 지원 티켓도 마찬가지입니다.

ARIN의 REST 가이드는 지원되는 IRR 객체 유형에 대해 GET, POST, PUT, DELETE 메서드를 문서화합니다. PUT은 수정 작업이고 DELETE는 객체를 제거합니다. 이 가이드는 객체 권한에 따라 RPSL과 XML을 받아들입니다. 최종 공개 RPSL이 익숙해 보이더라도 수정과 대체의 차이가 프로토콜 수준에서 명시적입니다.ARIN IRR RESTful API

전환 영수증이 반드시 감시 기록이 될 필요는 없습니다. 비공개 내용 대신 공개 객체 키와 해시를 사용하고, 개인 이름 대신 행위자 클래스를 식별하며, API 키를 아예 생략할 수 있습니다. 중요한 사실은 작업 전 클래스, 생성 출처 클래스, 권한 매트릭스 버전, 정규화된 사전 이미지 해시, 작업, 인가된 채널과 인코딩, 결과, 작업 후 클래스와 해시이며, 삭제 후 재생성이 일어났다면 대체 링크입니다. ARIN이 정확히 제공할 수 있다면 공개 관찰 또는 NRTM 시리얼을 추가할 수 있습니다. 정정과 철회는 기존 내용을 덮어쓰지 않고 체인을 확장해야 합니다.

그런 영수증은 설명된 관제 경로 아래에서 레지스트리 작업이 일어났다는 것만 증명합니다. 모든 IRR 미러가 이를 받았다거나, 필터 작성자가 이를 소비했다거나, BGP가 이를 따랐다거나, 트래픽이 계속 도달했다는 것은 증명하지 않습니다. 그 한계를 영수증 안에 유지하는 것 자체가 신뢰성의 일부입니다.

두 개의 현재 페이지가 하나의 권한을 미해결로 남긴다

ARIN의 공개 기록에는 추측으로 해결되어서는 안 되는 문서 충돌이 있습니다. 현재 개요 매트릭스는 단순 객체에 RPSL REST 권한이 없다고 말합니다. 2025년 1월 17일까지의 업데이트를 나열하는 구현 노트 페이지는 ARIN Online에서 생성된 객체를 RPSL 또는 XML 중 하나를 사용하는 REST로 조회, 업데이트, 삭제할 수 있다고 말합니다.

두 페이지 모두 캡처된 자료 집합에서 살아 있었습니다. 인증된 테스트라도 한 객체 유형, 한 계정 상태, 한 마이그레이션 이력만 다룬다면 오해를 낳을 수 있습니다. 신뢰할 수 있는 해결은 관련 클래스, 객체 유형, 작업, 채널, 인코딩을 명시하고 문서화된 버전 또는 시행일을 갖는 하나의 현재 권한 계약입니다. ARIN이 페이지를 정렬하거나 유효한 계정 아래에서 런타임 증거가 수집되기 전까지 이 글은 어느 진술이 프로덕션을 설명하는지 말할 수 없습니다.

역사적 기록은 이런 문서 이동이 왜 일어날 수 있는지 설명합니다. 2021년 2월 ARIN 블로그 게시물은 당시 도입 예정이던 REST 서비스와 그 한계를 설명했습니다. ARIN은 현재 그 게시물을 자사의 Vault에 두고 Vault 자료는 시대에 뒤떨어질 수 있다고 경고합니다. 이것은 유용한 연표이지 현재의 권한 표가 아닙니다.ARIN Vault: REST API 연표

바로 여기서 실제 동작하는 코드와 기관 산문을 분리해 두어야 합니다. 현재 표는 지원되는 관제에 대한 주장입니다. 실시간 응답은 한 사례에서의 관찰입니다. 역사적 공지는 과거 시점의 의도를 기록합니다. 어느 것도 다른 것을 조용히 대신해서는 안 됩니다.

좁은 권한을 위한 좁은 대장

ARIN은 권위 있는 서비스, 그 검증기, 기록을 관리할 수 있는 계정 역할을 통제합니다. 사용자 가이드에 따르면 Admin, Tech, Routing POC는 IRR 정보를 관리할 수 있고 Resource POC는 그렇지 못합니다. 이것은 객체 클래스와 별개의 인가 경계입니다. 행위자가 적격 역할을 갖고 있어도 객체의 생성 방식 때문에 채널 제한에 직면할 수 있습니다.

조직은 자격 증명, 인력 배정, 객체 전환 결정을 통제합니다. 소프트웨어 클라이언트는 RPSL을 얼마나 충실히 보존하고 오류를 어떻게 처리하는지 통제합니다. 하류 소비자는 IRR 데이터를 언제 가져오고 어느 정도의 무게를 둘지 결정합니다. 레지스트리는 앞부분을 감사 가능하게 만들 수 있지만 마지막 부분을 명령할 수 없습니다.

이 권한 분배는 라우팅 위에 새 게이트가 아니라 얇은 연속성 기록을 뒷받침합니다. 영수증은 조직이 계획된 전환이 일어났음을 증명하는 데, 지원 부서가 거부된 재생성과 낡은 소비자를 구별하는 데, 감사자가 클래스 변경이 의도적이었음을 확인하는 데 도움을 줄 수 있습니다. 그러나 경로의 정당성이나 운영자가 인터넷에서 말할 자격이 있는지를 결정해서는 안 됩니다.

여기서 검토한 공개 증거는 잘못된 객체도 영향받은 조직도 확립하지 않습니다. 확립하는 것은 더 미묘한 설계 사실입니다. ARIN의 IRR에서 객체가 시스템에 들어온 경로는 그 객체를 교정할 수 있는 경로에 계속 붙어 있을 수 있습니다. 그 계보를 보존하는 것은 책임 있는 일입니다. 그러나 명시적인 대체 링크 없이 운영자에게 인터페이스를 바꾸기 위해 그 계보를 지우도록 요구하는 것은 수선할 가치가 있는 이음새입니다.

출처

  1. ARIN: 인터넷 라우팅 레지스트리 개요
  2. ARIN: IRR 사용자 가이드
  3. ARIN: IRR Online 구현 노트
  4. ARIN: IRR RESTful API
  5. ARIN Vault: Take a REST — IRR로 오는 API
  6. RFC 2622: 라우팅 정책 명세 언어