요약

  • 10월 28일의 개인 Internet-Draft는 RTR에 여섯 종류의 새 PDU를 제안한다. 라우터는 이벤트 통지, 주기적 갱신 또는 두 방식 모두를 구독할 수 있다.
  • 이벤트용 Push Notify는 구독 ID, 변경 종류, 일련번호만 전한다. 변경된 RPKI 객체를 실어 나르는 절차는 Periodic Update 쪽에 있다.

긴급 ROA 변경을 다루는 운영자에게는 시계가 두 개다. 캐시가 변경을 알아차린 시각과 라우터가 새 검증 상태를 받아들인 시각이다. 새 RTR 푸시 초안은 보안 사건 때 초 단위 전파를 내세운다. 하지만 서둘러 보내는 것은 경보이고, 내용물을 담은 배송에는 별도 시간표가 붙는다.

기존 RFC 8210도 캐시가 요청을 기다리지 않고 Serial Notify를 보낼 수 있게 한다. 라우터는 이를 받으면 갱신 타이머가 끝나기 전에 Serial Query나 Reset Query를 즉시 보낼 수 있다. 현행 8210bis 초안 역시 이 구조를 유지한다. 캐시가 먼저 알리고, 라우터가 조회를 결정하며, 응답이 추가·철회된 기록을 가져온다. 기존 방식을 단순히 ‘풀’이라고 부르면 캐시의 첫 동작이 사라져 보인다.

새 제안은 최초 동기화 뒤 구독을 설정한다. 라우터는 이벤트 알림과 주기적 전송을 각각 선택하고 구독을 해지할 수도 있다. IANA에 요청한 새 PDU 유형은 여섯 개다. 캐시는 가입자별 상태를 관리해야 한다. 그 대가가 있는지는 알림 발송 속도보다 실제 수용 시간으로 따져야 한다.

이벤트용 Push Notify 도표에는 구독 ID, 통지 유형, 일련번호가 있다. 본문은 ROA, ASPA, 라우터 키의 변화를 예로 들지만 패킷 자체에는 그 객체를 넣는 칸이 없다. 알림 다음에 변경 데이터를 어떻게 넘길지도 설명하지 않는다. 경보가 먼저 도착해도 라우터의 검증 표가 저절로 갱신되지는 않는다. 이전 Serial Notify도 이미 즉시 조회를 촉발할 수 있었다.

데이터는 Periodic Update가 가져온다. 합의한 간격에 Cache Response, 데이터 PDU들, End of Data를 보내는 방식이다. 캐시는 라우터가 보유한다고 생각하는 일련번호를 적는다. 라우터의 실제 번호와 다르면 데이터를 처리해서는 안 된다. 수신자의 상태를 확인하는 이 규칙 때문에 ‘캐시가 보냈다’는 시점에서 속도 측정을 끝낼 수 없다.

IETF Datatracker에는 Standards Track을 목표로 한 개인 초안으로 올라 있으며 상태는 I-D Exists다. 재현 가능한 지연 비교나 배포 시험은 없다. 다음 판에서 이벤트 뒤 데이터 전달 순서와 측정 조건을 제시하면 속도 주장을 시험할 수 있다. 지금 정의된 것은 새 경보와 주기 배송이다.