요약

  • 2024년 5월에 제출된 ARIN 제안 2024.8은 여전히 Open 상태로 표시되어 있습니다. 제출자는 AS-SET 레코드를 ARIN의 인증 레지스트리로 옮기는 과정에서 IRRremarks에 약 1,024자의 제한이 있는 것으로 보인다고 보고했습니다.
  • 요청은remarks: Level3 members:가 출처 자격이 부여된 멤버를 담고 표준 RPSLmembers필드보다 우선하는 Lumen 관례를 설명합니다.
  • Lumen 자체 가이드는 동일한 AS-SET이 자사 필터 생성기와 다른 소비자에 의해 서로 다르게 해석될 수 있다고 밝힙니다. 이는 파서의 정체와 출력이 통제 기록의 일부가 됨을 의미합니다.
  • 필드를 확장하면 번거로운 AS-SET 연쇄 우회를 제거할 수 있습니다. 그러나 사적 문법을 이식 가능하게 만들거나 어떤 필터가 라우터에 도달했는지 증명하지는 못합니다.
  • ARIN은 자신이 통제하는 필드 변경 및 검증 경계를 공개해야 하고, Lumen은 자신이 통제하는 파서 프로필과 생성된 셋 증거를 재현 가능하게 만들어야 합니다.

분석

두 가지 의미를 품은 작은 티켓

이 문제의 첫 버전은 제품 백로그에 깔끔하게 들어맞습니다. Dale Carder의 2024년 5월 9일 제안에 따르면, 서드파티 비권위 레지스트리에서 ARIN으로 AS-SET 레코드를 옮기려는 시도가remarks에 약 1,024자 상한이 존재하는 것으로 보이는 장애를 만났습니다. 제안된 해법은 익숙합니다. 상한을 올리거나, 속성 반복을 허용하거나, 둘 다 허용하는 것입니다.

우회 방법은 덜 깔끔했습니다. 제출자는 셋을 더 작은 AS-SET의 연쇄로 쪼개야 했다고 말합니다. 이는 이름, 재귀, 그리고 업데이트가 불완전해질 수 있는 지점을 늘립니다. ARIN은 이 개선이 자사 인증 IRR로의 마이그레이션에 도움이 될 것이라고 인정하고 다른 IRR 작업과 함께 요청을 검토하겠다고 밝혔습니다. 2년 넘게 지난 지금, 현재 제안 색인은 여전히 2024.8을 Open으로 표시합니다.

이것은 공개 상태이지 ARIN 내부 작업에 대한 판정이 아닙니다. 제안에는 약속된 전달 일자가 없으며, 이 검토에서는 인증 객체를 실제로 테스트해 보고된 제한이 운영 환경에 남아 있는지 확인하지 않았습니다. 그럼에도 티켓이 유용한 이유는, 그 계기가 된 사례가 글자 수만으로는 해결되지 않는 문제를 가리키기 때문입니다.

추가 텍스트는 단순한 주석이 아닙니다. 실행 가능한 정책 입력일 수 있습니다.

remarks가 멤버십 필드를 압도할 때

RFC 2622는 속성들에 서로 다른 역할을 부여합니다. AS-SET에서members는 AS 번호나 다른 AS-SET 이름을 나열합니다.mbrs-by-ref는 메인테이너 기반의 간접적인 진입 경로를 제공합니다.remarks는 자유 형식의 설명이나 명확화입니다. 일반적인 RPSL 객체를 읽는 사람은 멤버십 필드가 누가 속하는지 답한다고 합리적으로 기대할 수 있습니다.

Lumen은 자사 필터 생성기에 대해 다른 규칙을 문서화합니다. AS-SET이Level3 members:또는Level3 mbrsby-ref:로 시작하는 remarks를 포함하면, 표시된 줄이 일반 멤버십 속성보다 우선합니다. 이 사적 형식은 참조된 각 객체에 레지스트리 출처를 붙일 수 있습니다. Lumen은 이것이 자사가 지원하는 레지스트리 간 확장용 일반 문법의 한계를 해결한다고 설명합니다.

가이드는 그 결과를 숨기지 않습니다. Lumen은 이 동작을 “셋 객체의 필터 생성기 의존적 해석”이라고 부릅니다. 예시 시나리오에서 표준 member 항목을 이해하는 소비자는 한 셋을 도출하고, Lumen은 특수 remarks가 존재하기 때문에 그 항목들을 무시하고 대체 텍스트로부터 자신의 셋을 도출합니다.

RADb의 현재 도움말 자료도 같은 관례를 기록합니다.Level3 members:remarks는 명명된 데이터베이스와 참조 객체를 가리킬 수 있습니다. 이는 희미한 사용자 보고서가 아니라, 기본 명세가 자유 텍스트라고 부르는 속성 안에 살아가는 문서화된 호환성 언어입니다.

호환성 언어가 곧 나쁜 것은 아닙니다. 분산된 IRR은 결코 하나의 완전히 일관된 데이터베이스가 되지 못했고, 운영자들은 출처, 미러, 확장 규칙을 선택해 왔습니다. Lumen은 ASN 3356을 보호하고 고객이 실제로 광고할 권한이 있는 것을 반영하는 필터를 만들어야 합니다. 가이드에 따르면 그 필터들은 IRR 정보로부터 생성되어 매일 갱신됩니다. 멤버별 출처 자격 부여는 소비자가 이름을 잘못된 레지스트리에서 풀어내는 것을 막을 수 있습니다.

문제는 우회가 존재한다는 것이 아닙니다. 문제는 그 권위를 오해하기 쉽다는 점입니다.

하나의 저장 객체, 둘 이상의 실효 셋

객체 메인테이너가 AS-SET을 작성합니다. ARIN이 객체를 인증, 검증, 공개합니다. 소비자가 자신의 IRR 출처를 선택하고 객체를 검색합니다. 그런 다음 파서가 표시된 remarks를 불활성 산문으로 볼지, 아니면members를 대체하는 지시로 볼지 결정합니다. 그 해석 이후에야 경로 객체가 모이고 필터 후보가 생성됩니다. 검토, 배포, 라우터 상태는 더 하류에 있습니다. BGP 전파와 패킷 전달은 더 아득히 아래에 있습니다.

이 연쇄를 하나로 뭉개면 정반대의 두 가지 오류가 생깁니다. 하나는 ARIN이 운영하지도 않는 사적 파서에 대한 책임을 ARIN에 돌리는 것이고, 다른 하나는 Lumen의 결과를 ARIN 객체의 피할 수 없는 독해로 취급하는 것입니다. 둘 다 정확하지 않습니다. ARIN은 수용된 레코드를 통제하고, Lumen은 자신의 해석 프로필을 통제하며, 고객은 각 시스템의 규칙 안에서 제출 의도를 통제합니다. 라우터의 최종 정책은 그 어느 하나의 기록으로부터도 추론할 수 없습니다.

필드 길이는 연쇄 중 단 하나의 이음선에만 영향을 줍니다. 더 큰 용량은 메인테이너가 여러 셋을 연쇄하는 대신 출처 자격이 부여된 호환성 목록을 한 객체에 유지하게 해 줄 수 있습니다. 이것은 실제 이점입니다. 그러나 표준 member 필드와 사적 remarks가 갈라지면, 더 큰 필드는 단지 더 큰 갈라짐을 허용할 뿐입니다. 메인테이너가 어느 소비자가 그것을 무시하는지 모른 채members를 편집하면, 눈에 보이는 수정은 그 소비자의 생성 셋을 바꾸지 못할 수 있습니다. 사적 파서가 바뀌면, 저장된 객체는 바이트 단위로 동일하게 남은 채 실효적 의미가 바뀔 수 있습니다.

그래서 “더 많은 문자 지원”은 완전한 수용 테스트가 아닙니다. 진짜 테스트는 지원되는 각 해석기가 무엇을 산출하는지 묻습니다.

영수증은 해석에서 시작해야 한다

적정한 기록이 라우터 구성, 고객 계약 또는 내부 토폴로지를 공개할 필요는 없습니다. 공개 객체 키, 권위 출처, 관측된 객체의 정준 해시 또는 일련값에서 시작할 수 있습니다. 파서 프로필과 버전, 사적 규칙을 활성화한 마커, 그 마커에 부여된 우선순위를 명시해야 합니다.

다음 필드들이 유용합니다. 수용된 출처 자격 토큰, 사유 분류와 함께 기각된 토큰, 표준 확장이 산출한 정규화된 멤버 셋, 호환성 프로필이 산출한 멤버 셋, 그리고 추가·삭제·미해결 참조의 경계가 정해진 목록과 다이제스트. 타임스탬프, 입력 출처 스냅샷, 생성 상태는 이후의 재현을 가능하게 합니다. “생성됨”은 “검토됨”, “배포됨”, “라우터에서 관측됨”과 별개로 유지되어야 합니다.

ARIN의 몫은 더 좁습니다. 상한을 바꾸거나remarks를 반복 가능하게 만든다면, 처분 문서는 영향을 받는 객체 클래스와 인터페이스를 밝히고 기존 값이 어떻 처리되는지 설명하며, 자유 텍스트의 수용이 모든 외부 해석을 검증하지는 않는다는 점을 분명히 진술해야 합니다. 요청을 구현하지 않기로 한다면 같은 페이지에 그 결정과 마이그레이션 대안을 기록해야 합니다. 무기한 열린 라벨은 운영자가 대기, 설계, 거부를 구분할 수 없게 만듭니다.

Lumen의 몫은 호환성 프로필을 테스트 가능하게 유지하는 것입니다. 2023년 4월 가이드는 문서화된 규칙에 대한 강력한 증거이지만, 모든 고객을 위한 현재의 필터 영수증은 아닙니다. 버전이 부여된 파서 선언과 표준 확장을 Lumen 고유 확장과 비교하는 수단은 관례를 유지보수 창 이전에 운영자가 검증할 수 있는 무언가로 바꿔줍니다.

출처가 확립하지 못하는 것

여기서 주장되는 테스트된 경로는 없습니다. 이 기록은 어떤 프리픽스가 기각, 유출, 또는 잘못 수용되었음을 보여주지 않습니다. 장애, 보안 사고, 피해를 입은 고객, 심지어 현재 얼마나 많은 객체가 이 마커를 사용하는지도 보여주지 않습니다. 겉보기 1,024자 상한은 제출자의 진술에서 온 것이며, 2026년에 재현되지 않았습니다. Open 상태는 ARIN이 페이지 뒤에서 아무것도 하지 않았음을 증명하지 않습니다.

2023년 가이드 역시 오늘날 모든 Lumen 고객, 파서 인스턴스, 라우터가 문서화된 동작을 그대로 따른다는 것을 증명하지 않습니다. 그것이 증명하는 것은 더 좁지만 충분합니다. Lumen이 해석을 소비자 의존적으로 만드는 우선순위 규칙을 공개적으로 기술했다는 것입니다. remarks 확장을 단순한 사용자 인터페이스 개선이라 부를 때 주의를 요구하기에 충분합니다.

가장 안전한 결론은 가장 실용적인 결론이기도 합니다. 운영자가 여전히 필요로 하는 한 호환성 경로를 유지하되, 이름과 버전, 출력, 마이그레이션 상태를 부여하십시오. 표준 독해와 사적 독해를 비교 가능하게 만드십시오. 그러면 더 큰 필드는 두 통제 시스템이 불일치하기에 더 큰 장소가 아니라 구현 가능한 개선이 됩니다.

출처