요약

  • 10월 29일 공개된 개인 Internet-Draft는 Internet Routing Registry 데이터를 위한 RDAP 경로 여섯 개를 제안한다. 그중 세 SET 유형과 라우팅 정책 필드는 구현 의무가 아니다.
  • RIPE NCC의 현재 /help 응답에는 irr0가 없다. Whois를 대체하려면 서버마다 실제로 제공하는 객체와 누락 항목을 먼저 확인해야 한다.

출구 표지판에는 작은 별표가 붙었다

RIPE 93에서 한 네트워크 운영자는 RIR의 라우팅 레지스트리 객체 지원이 Whois를 정리하기 전에 기다리는 마지막 기능이라고 말했다. 이제 그 기능을 제안하는 문서가 나왔다. 다만 출구 표지판 아래 별표는 여전히 남아 있다. 문서에 적힌 일부 객체 유형은 서버가 구현하지 않아도 된다.

IETF Datatracker는 10월 29일 draft-aggarwal-regext-rdap-irr-00을 공개했다. 네 명의 저자 가운데 RIPE NCC의 Mahesh Aggarwal과 ARIN의 Jasdip Singh가 포함돼 있다. 초안의 목표는 Internet Routing Registry(IRR) 데이터를 HTTPS 기반의 구조화된 JSON으로 RDAP에서 조회하게 하는 것이다. 클라이언트가 서로 다른 조회 수단을 오가는 대신 공통된 응답 형식을 쓰자는 제안이다.

초안은 여섯 경로 식별자를 나열한다. irr0_route, irr0_routeSet, irr0_autnumSet, irr0_rtrSet, irr0_peeringSet, irr0_filterSet이다. route 조회는 prefix와 origin ASN을 키로 사용한다. autnum 응답에는 import와 export 정책을 순서대로 담을 수 있고, 다중 프로토콜 형식 및 import-via, export-via도 포함한다.

그 다음 문단에서 선택권은 서버 쪽으로 넘어간다. peering-set, rtr-set, filter-set 지원은 구현자가 선택한다. autnum 응답의 irr0_policies 항목도 선택 사항이다. 클라이언트가 새 RDAP 용어를 이해해도, 현장의 필터가 매일 참조하는 객체 유형이 서버에서 빠질 수 있다. 문서에 경로 여섯 개가 있다고 서비스 여섯 개가 운영되는 것은 아니다.

이 차이는 JSON 문법의 문제가 아니다. ARIN은 자체 IRR 데이터베이스가 공개 Whois 정보와 분리돼 있다고 설명한다. 자원 보유자가 RPSL 객체를 제출하고, 다른 IRR이 라우팅 판단에 사용할 수 있도록 가져간다. ARIN은 Near Real-Time Monitoring(NRTM), 파일 다운로드, 43번 포트 Whois를 조회 방법으로 안내한다. ARIN은 자사 NRTM 흐름의 일부 객체를 “authorized”라고 부르며, 자원 등록과 객체 관리 조직을 조건으로 설명한다. 이 표현은 ARIN이 설명한 자사 데이터 흐름에 한정된다.

현재 RIPE Database 문서는 RDAP 유형으로 autnum, domain, ip, entity 네 가지를 열거한다. 직접 확인한 /help 응답에는 다른 확장들이 표시돼 있지만 irr0는 없다. 이 결과는 확인 시점의 RIPE NCC 엔드포인트에 대한 관찰이다. ARIN이나 다른 레지스트리 서버의 상태는 각각 따로 조회해야 한다. 적어도 RIPE에서는 초안과 실제 서비스 사이의 간격을 확인할 수 있다.

문서의 지위도 분명하다. Datatracker는 이를 개인 Internet-Draft로 분류한다. IETF의 승인을 받은 문서가 아니며 IETF 표준화 과정에서 공식 지위를 갖지 않는다. IESG 상태는 I-D Exists다. 다음 증거는 그림이 아니라 실제 엔드포인트의 응답에서 나와야 한다.

JSON은 이전 작업의 절반이다

공통 응답 형식은 파서 수를 줄이고 반복 조회를 단순하게 만들 수 있다. 하지만 데이터의 뜻까지 바꾸지는 않는다. IRR의 route 객체는 등록된 라우팅 정책을 기록한다. 현재 BGP에서 prefix가 광고되는지, 다른 네트워크가 이를 수용하는지를 증명하지 않는다. 변환 과정에서 SET 구성원이나 정책 순서가 사라지면 응답은 유효한 JSON이어도 운영 도구는 중요한 정보를 잃는다.

초안은 확장을 지원하는 서버가 rdapConformance와 도움말 응답에 irr0를 표시하도록 한다. 클라이언트는 이 선언을 읽을 수 있지만, 선언만으로 모든 객체 유형을 검증할 수는 없다. 운영자는 실제로 사용하는 유형을 하나씩 조회하고 같은 서버의 RPSL 결과와 비교해야 한다. SET 구성원, 순서가 있는 정책, entity 참조, 생성·변경 이벤트가 그대로 보존되는지 확인해야 한다.

개인정보 절은 이런 조회가 레지스트리에 등록된 사람에게 영향을 줄 수 있다고 적고, 서버 운영자에게 적용되는 개인정보 제약을 고려하라고 요청한다. 읽기 인터페이스가 통일돼도 공개할 연락처의 범위까지 자동으로 정해지지는 않는다.

Whois 종료를 판단하려면 서버별 구현 기록이 필요하다. irr0를 광고하는지, 어떤 객체가 응답하는지, 선택 필드가 어떻게 처리되는지, RPSL과 어떤 차이가 있는지를 남겨야 한다. 재현 가능한 비교가 끝날 때까지 기존 조회 경로도 운영에 포함된다. 일반 route 하나가 잘 응답했다고 기존 경로를 닫으면, 창고 문을 열어 본 뒤 안의 모든 물건도 옮겨졌다고 선언하는 셈이다.

RIPE 93의 운영자는 동료들에게 매일 쓰는 객체가 포함됐는지 살펴보자고 제안했다. 거기서 시작하면 된다. “RDAP가 있다”는 통신 방식에 대한 답이다. Whois를 접는 결정에는 필요한 레코드가 손실 없이 도착한다는 증거가 필요하다.

출처