요약

  • RFC 9910은rdap-down을 직계 하위 탐색으로 정의하고,rdap-bottom은 요청 범위를 함께 커버하는 가장 구체적인 등록 객체를 찾는 관계로 정의합니다.
  • ARIN의 실제/21예시는 활성/22직접 할당과 행정적/8을 반환했으며,/8은 잔여 공간을 커버하지만/21의 하위는 아닙니다.

뒤집혀 보이는 결과

결과 집합은 계층 구조를 위반하는 듯한 모양으로 시작됩니다. ARIN의 RDAP 서비스에149.112.152.0/21의 bottom 객체를 요청하면 두 건의 등록이 반환됩니다. 하나는149.112.152.0/22로 표현되는 활성 직접 할당NET-149-112-152-0-1이고, 다른 하나는149.0.0.0/8로 표현되는 행정적 객체NET-149-0-0-0-0입니다.

/8은/21의 더 구체적인 하위일 수 없습니다. 그러나 서비스는 그렇게 주장하지 않습니다. 겉보기 모순은 "bottom"을 "이 노드 아래의 모든 리프"로 읽는 데서 옵니다. RFC 9910은 이 관계에 다른 과제를 부여합니다. 클라이언트가 제공한 값을 함께 커버하는 가장 구체적인 등록 객체를 찾는 것입니다.

/22는 요청된/21의 절반을 커버합니다. 나머지 주소에 대해 이 응답에서 이용 가능한 가장 구체적인 등록 객체는 더 넓은/8입니다. 따라서 bottom 집합에는 중복이 포함됩니다. 이 집합은 상호 배타적인 하위로 깔끔하게 분할하는 것이 아니라, 어떤 레지스트리 객체들이 쿼리 범위 전체를 설명하는지를 나타냅니다.

down은 bottom이 아니다

짝을 이루는 쿼리는 이 구분을 보여줍니다. 같은/21에 대한 ARIN의rdap-down검색은 직접/22할당만 반환합니다. 그 이유는rdap-down이 직계 하위 관계를 따르기 때문입니다. 즉, 제공된 범위 바로 아래의 다음 등록 객체를 요청합니다./8은 이에 해당하지 않습니다.

rdap-bottom은 커버리지 질문을 던집니다. 더 구체적인 객체가 요청을 완전히 커버하지 못하면, 잔여 주소에 대해 커버 객체가 집합에 남을 수 있습니다. RFC 9910은 bottom 객체들이 서로 분리될 필요는 없으며, 입력보다 덜 구체적인 객체까지 포함할 수 있다고 명시합니다. ARIN 문서도 같은 운영 규칙을 기술합니다. 발견된 bottom 객체가 요청 값을 커버하지 못하면 가장 구체적인 네트워크 객체도 함께 반환됩니다.

이 의미론은 유용합니다. 클라이언트는 트리를 재귀적으로 조립하지 않고도 범위 전반에 걸쳐 등록 계층이 어느 수준까지 세분화되었는지 확인할 수 있습니다. 그러나 이 편의는 표시 위험을 낳습니다. 대시보드가 모든 항목을 "서브할당"으로 표시하거나 응답을 평면적인 하위 블록 집합으로 렌더링하면, 커버 객체를 잘못된 관계로 만들어 버립니다.

응답이 실제로 담고 있는 것

반환된 항목은 스스로를ip network객체로 식별합니다. 여기에는 핸들, 시작·종료 주소, CIDR 표현, RIR 고유의 유형과 상태 값이 포함됩니다. 캡처된 응답에서/22는 상태가active인DIRECT ALLOCATION이었고,/8은 상태가administrative였습니다.

이 라벨들은 레지스트리 표면에 속합니다. 두 프리픽스가 BGP에서 광고되는지, 특정 네트워크에서 도달 가능한지, 트래픽을 운반하는지, Route Origin Authorization로 승인되었는지를 말하지 않습니다. 이 캡처에서 선택적인 ARIN origin-AS 배열은 비어 있었지만, 그 부재가 경로가 존재하지 않는다는 증거는 아닙니다. 그것은 어느 한 시점의 한 레지스트리 응답에서 한 필드의 상태일 뿐입니다.

RFC 9083은 IP 네트워크 객체를 등록 정보로 정의합니다. RFC 9082 역시 일반 IP 조회가 쿼리를 완전히 포함하는 가장 구체적인 등록 네트워크를 선택한다고 설명합니다. 어느 사양도 등록 기하 구조를 조용히 운영 라우팅 상태로 변환하지 않습니다.

관계를 함께 기록하라

방어 가능한 기록은 프리픽스 이상을 저장합니다. 요청된 정확한 관계, 입력 범위, 검색 시각, 핸들, 시작·종료 주소, CIDR, 유형, 각 결과의 상태를 보존합니다. 이 필드들이 온전하면/8은 이해 가능해집니다. 즉,/22가 설명하지 못하는 부분에 대한 커버 등록입니다.

같은 근거는 라우팅 수집기, IRR 라우트 객체, RPKI 검증, 내부 주소 관리 기록과 별도로 보관되어야 합니다. 각각은 서로 다른 질문에 답합니다. bottom 검색은 레지스트리 커버리지를 설명할 뿐, 어떤 경로가 보이는지, 누가 라우터를 바꿀 수 있는지, 누가 계정을 보유하는지, 어느 조직이 법적 소유권을 갖는지는 보여주지 않습니다.

이 작은 구분이 하류에 큰 영향을 미칩니다. 관계 이름이 한번 사라지면 정확한 응답이 발명된 위임 트리로 변할 수 있습니다. 가장 안전한 라벨은 가장 문자 그대로인 라벨입니다. 요청된 범위에 대해 이용 가능한 가장 하위의 등록 객체에 의한 커버리지입니다.

출처