요약

  • ACSP 제안 2026.3은 ARIN의 중복 ROA 예시가maxLength /24를 가진/16을 지나치게 넓게 서술했다고 보고하고, 명시적 경계, 즉 동일 Origin AS에 대해/16부터/24까지는 거부하고/25부터/32까지는 여전히 생성 가능하다는 규칙을 제안했다.
  • ARIN은 이 제안을 완료로 종결했지만, 현재 FAQ는 검증 가능한 그 구간을 “기존 ROA에 포함되는 모든 프리픽스”라는 표현으로 대체했다. 이 문구 자체로는 주소 포함과maxLength를 통한 권한 부여를 구분하지 못한다.
  • 작고 버전 관리되는 의미론적 테스트 영수증이 있으면 코드, 자격 증명 또는 고객 데이터를 노출하지 않고도 웹, REST, OT&E 동작을 증명할 수 있다.

빠른 종결에는 그럴 만한 이유가 있다

이 이야기를 쉽게 쓴다면 문서 실패로 시작할 것이다. 더 공정한 버전은 대응으로 시작한다. 2026년 1월 13일 Chris Woodfield는 겉보기에 단순한 질문, 즉 고객이 중복된 Route Origin Authorization을 생성할 수 있는가를 실제로 테스트한 뒤ACSP 제안 2026.3을 제출했다.

이 보고는 보기 드물게 유용했다. 분쟁이 된 문구를 그대로 재현하고, 관찰된 경계를 서술하고, 대체 문안을 제공하며, 운영상의 가치를 설명했다. ARIN은 2월 18일 혼란을 해소하기 위해 FAQ를 갱신했다고 답한 뒤 제안을 완료로 종결했다. 공공기관이 구체적인 불만을 접수받아 약 5주 만에 행동한 것이다. 이는 행정적 각주가 아니라 건강한 피드백 루프다.

권한 등가 레코드를 거부할 만한 합리적인 제품적 이유도 있다. ARIN의 호스팅 ROA는 이제 자동 갱신된다. 오래된 권한이 만료에 가까워지는 동안 그것을 유지하기 위해 두 번째로 겹치는 객체를 만들 필요는 더 이상 없다. 중복 객체가 줄어들면 인터페이스가 깔끔해지고, 유지보수 실수가 줄어들며, 어떤 레코드를 변경하거나 제거해야 하는지에 대한 모호성도 줄어든다. 도움말 페이지가 그 선택을 설명할 때마다 표준 문서 전체를 재현할 필요는 없다.

따라서 문제는 ARIN이 이 제안을 받아들였어야 했는지, 아니면 RPKI 객체 형식이 요구하는 수준보다 더 엄격한 접수 규칙을 둘 수 있는지가 아니다. ARIN은 실제로 제안을 받아들였고, 그런 규칙을 운영할 수도 있다. 문제는 보고된 모호성이 실제로 해소되었다는 것을 보여주는 공개 증거가 무엇인가이다.

제안된 수정안에는 자체 테스트가 들어 있었다

제안에서 언급된 기존 예시는/16과maxLength /24를 담은 ROA로 시작했다. 그 문구는 같은 Origin AS를 사용하는 그/16내부의 어떤 프리픽스에 대한 다른 ROA도 생성이 막힌다고 서술했다. 제출자는 실제 테스트 결과가 이와 정확히 일치하지 않는다고 밝혔다.

구분은 수치적이었다. 동일한 Origin AS의 경우, 마스크가/16부터/24까지인 제안 프리픽스는 기존 권한이 이미 그것을 허용하므로 거부된다고 보고되었다./24보다 더 세분화된 프리픽스, IPv4 기준/25부터/32까지는 기존maxLength가 부여한 권한 범위 밖이므로 여전히 생성 가능하다고 보고되었다. 제안된 대체 문안은 느슨한 “겹치는(overlapping)” 대신 “중복(redundant)”이라는 표현을 쓰며 경계의 양쪽 절반을 모두 유지했다.

이 반례는 중요한 역할을 했다. 독자가/16내부에 기하적으로 포함된 모든 서브넷을 동일한 것으로 취급하지 않도록 막았다. 또한 주장을 재현 가능하게 만들었다. 동일한 Origin AS로/24양쪽에 하나씩 프리픽스를 시도하고 결과를 비교하면 된다.

현재 RPKI FAQ는 이 수리의 일부를 유지하고 있다. 자동 갱신이 중복 ROA의 필요성을 없앴다는 점과 ROA가 더 이상 겹칠 수 없다는 점은 서술하고 있다. 그 예시는 기존/16과maxLength /24가 동일한 Origin AS와 “기존 ROA에 포함되는 모든 프리픽스”를 가진 다른 ROA 생성을 막는다고 말한다. 빠진 것은 구간이다. 이 페이지는 더 이상/16부터/24가 차단 사례이고/25부터/32가 제안된 반례라는 점을 말하지 않는다.

이 비교가 실제 시스템이 잘못 동작한다는 증거가 되지는 않는다. 1월의 기술은 제출자가 보고한 테스트이지 새로 수행한 인증된 실험이 아니다. ARIN에는 의도한 규칙을 정확히 포착하는 내부 테스트가 있을 수 있다. “포함되는”이 “이미 권한 부여된”의 평이한 말로 쓰였을 수도 있다. 다만 공개 문서는 외부 운용자가 이를 판별할 수 있게 해주는 부분을 보존하지 않을 뿐이다.

“포함(covered)”과 “일치(matched)”는 서로 바꿔 쓸 수 없다

RPKI에는 이미 인접 개념에 대한 정밀한 어휘가 있기 때문에 이 문구는 더 중요해진다.RFC 6811은 경로 프리픽스가 Validated ROA Payload에 의해Covered되는 경우를, VRP 프리픽스가 그와 동일하거나 더 포괄적이고 관련 주소 비트가 일치하는 경우로 정의한다. 이 커버리지 테스트에maxLength는 포함되지 않는다. 경로가Matched되려면 커버되고, 프리픽스 길이가 VRP 최대 길이를 초과하지 않으며, Origin ASN이 VRP ASN과 동일해야 한다.

FAQ는 “covered”를 대문자로 쓰거나 RFC 정의를 적용한다고 선언하지 않는다. 그럴 의도가 아닐 수도 있다. 그러나 RPKI 문서를 읽는 운용자는 주소 커버리지와 권한 등가 커버리지가 같은 의미라고 안전하게 가정할 수 없다.

제안의 예시를 보라./16안에 속한/25는/16VRP에 의해 주소상으로는 커버된다. 그러나 최대 길이가/24인/16은, Origin ASN이 같더라도 그/25를 매치하지 않는다. 생략된/25반례가 “covered”라는 단어보다 더 많은 정보를 담는 이유가 바로 여기에 있다.

RFC 6482는 객체 수준의 관점을 제공한다. 이 RFC는maxLength를 명명된 AS가 광고하도록 권한 부여된 가장 긴 프리픽스로 정의한다.maxLength가 없으면 정확한 프리픽스만 권한 부여된다. 또한 유효한 ROA는 다른 항목에 포함되는 주소 프리픽스를 포함할 수 있고, 심지어 동일한 프리픽스 항목도 포함할 수 있지만, 권한상 열위인 중복은 이득이 없으므로 권장되지 않는다고 말한다.

이것이 ARIN에게 호스팅 서비스가 인코딩할 수 있는 모든 구성을 수용하라고 요구하지는 않는다. 프로토콜 유효성, 라우팅 의미, 제품 접수는 서로 다른 세 계층이다. ARIN은 더 깔끔한 부분집합을 유지할 수 있다. 다만 그것이 객체 문법의 자명한 성질이 아니라 제품 규칙이기 때문에, 그 경계는 제품 규칙으로서 명시되고 테스트되어야 한다.

세 개의 공개 표면이 모두 조건술어에 미치지 못한다

현재 ROA 가이드는 ROA가 Origin AS, 프리픽스, 최대 길이로 구성된다고 말한다. 또한 중복 및 겹침 ROA는 더 이상 허용되지 않는다고 서술한 뒤 독자를 FAQ로 보낸다. 이 가이드 자체에는 경계 매트릭스가 없다.

RPKI RESTful API 가이드는 페이로드 구조에 대해서는 명확하다. 통합 트랜잭션은 ROA를 생성, 수정, 삭제할 수 있으며 ASPA 변경과 원자적으로 결합해 모든 작업이 함께 성공하거나 함께 실패하도록 할 수 있다. 각 제안 리소스는startAddress,cidrLength,maxLength를 담을 수 있다. 실패한 호출은 ARIN의 일반 오류 문서로 안내된다. 고정된 이 페이지에는 중복 또는 겹침 조건술어가 서술되어 있지 않다.

이 누락은 혼합 트랜잭션에서 가장 문제가 된다. 클라이언트가 하나의 원자적 요청에서 오래된 ROA를 삭제하고 대체본을 생성한다고 하자. 중복성은 트랜잭션 이전 상태, 트랜잭션 이후 의도된 상태, 아니면 순서가 정해진 중간 상태 중 어느 것을 기준으로 평가되는가? 올바른 구현은 하나의 일관된 모델을 선택할 것이다. 특히 트랜잭션 전체가 함께 실패할 수 있는 상황에서 자동화 작성자는 어떤 모델인지 알아야 한다.

Operational Test and Evaluation 환경은 이를 알아내기에 자연스러운 장소다. ARIN에 따르면 OT&E는 운영 환경과 동일한 기능 세트를 갖추고, 테스트 ROA 생성을 허용하며, API 클라이언트가 라이브 구성을 변경하기 전에 RPKI 트랜잭션 페이로드를 검증할 수 있게 한다. 운영 환경과 분리되어 매월 스냅샷으로 갱신되며, 이메일은 지원되지 않고 환경은 상시 인력 모니터링을 받지 않는다.

OT&E는 유용하지만, 거기서 수행된 실험은 내구성 있는 명세가 아니다. 월별 갱신은 시작 상태를 바꿀 수 있다. 향후 서비스 릴리스는 동작을 바꿀 수 있다. 두 운용자가 다른 프리픽스를 선택하면 다른 결과를 받을 수 있다. 테스트가 제도적 증거가 되려면 테스트된 튜플, 기대 결과, 환경 버전, 날짜가 보존되어야 한다.

빠져 있는 것은 의미론적 테스트 영수증이다

ARIN이 증거 사슬을 완성하기 위해 소스 코드를 공개할 필요는 없다. 필요한 것은 제안, 문서 개정, 그리고 주장되는 동작을 연결하는 작은 영수증이다.

영수증은 종결 번호, 문서 개정판, 서비스 규칙 버전, 시행일을 식별해야 한다. 각 테스트 행은 채널(웹, REST 또는 OT&E), 기존 Origin AS와 프리픽스 및maxLength, 제안된 Origin AS와 프리픽스 길이, 기대되는 수용 또는 거부 결과, 안정적인 사유 코드를 명시해야 한다. 환경 빌드와 테스트 날짜를 기록하고, 이후의 정정 또는 대체 규칙을 연결해야 한다.

다섯 행이면 경계의 대부분이 드러난다. 첫째, 동일 프리픽스와 동일 AS. 둘째, 길이가maxLength이내인 더 세분화된 프리픽스. 셋째,maxLength를 넘는 더 세분화된 프리픽스. 넷째, 동일한 주소 튜플에 대해 다른 Origin AS, FAQ 자체가 AS 관계를 유의미하게 만들기 때문이다. 다섯째, 기존 권한을 제거하고 대체 권한을 추가하는 혼합 원자적 트랜잭션.

그 결과는 실제 조직, 운영 API 키 또는 고객 경로를 드러낼 필요가 없다. 문서용 프리픽스와 예약된 ASN이면 충분하다. 이것이 FAQ 자체를 길게 만들도록 강제하지도 않는다. 도움말 답변은 간결하게 유지하면서, 프리플라이트 로직을 작성하는 사람들을 위해 기계 판독 가능한 매트릭스로 연결하면 된다.

이런 영수증은 또한 중요한 구분을 보존한다. “문서가 바뀌었다”는 편집상의 사실이다. “서비스가 이 튜플들을 수용하고 거부한다”는 동작상의 사실이다. “이 종결이 요청된 명확화를 전달했다”는 두 가지를 결합하는 책임성 주장이다. 한 문장이 이 세 가지를 모두 짊어져야 할 필요는 없다.