Summary

  • Tore Anderson와 Jeroen Lauwers의 RIPE 제안 2023-04는 2024년 4월 15일 채택돼 IPv4 PA 할당에 AGGREGATED-BY-LIR 상태를 도입했다.
  • LIR은 용도와 연락처가 같은 연속 할당을 하나의 객체로 묶을 수 있다. 감사 때는 그 안의 개별 할당 건수를 제시해야 한다.

한쪽은 서류 산, 다른 쪽은 빈 폴더

RIPE 제안 2023-04가 기록한 2023년 8월의 숫자는 같은 데이터베이스의 두 얼굴이다. 주소 하나짜리 IPv4 PA /32 할당 기록이 546,402건 있었다. 동시에 10,052개 LIR이 가진 PA 상위 블록 19,221건에는 하위 할당 기록이 하나도 없었다. 나사 하나마다 영수증을 남기는 책상 옆에, 상자에 무엇이 들었는지 적지 않은 책상이 놓인 셈이다.

Tore Anderson와 Jeroen Lauwers는 운영자에게 기록을 더 많이 쓰라고 독촉하는 대신 기록의 모양을 바꿨다. LIR은 PA IPv4를 고객이나 자체 설비에 할당할 때 RIPE Database의 INETNUM 객체로 사용 범위를 남긴다. 동적 주소 풀처럼 작은 할당이 자주 바뀌고 목적과 담당자가 같으면, 객체마다 같은 연락처를 반복해서 관리해야 한다. 제안은 하위 객체를 거의 만들지 않는 LIR과 /32 객체를 대량으로 만드는 LIR을 모두 문제의 일부로 봤다.

채택된 RIPE-822는 연속된 IPv4 PA 할당의 목적과 연락처가 같을 때 하나의 AGGREGATED-BY-LIR 객체에 넣도록 허용한다. 공개 장부에는 주소 범위와 책임자가 남는다. LIR은 그 안의 개별 할당 건수를 파악하고 RIPE NCC의 감사에서 통계를 제시해야 한다. 표지는 얇아졌지만 속에 든 장수는 세어야 한다.

IPv6에 같은 이름의 상태가 있어도 세부 조건은 그대로 가져오지 않았다. IPv6는 추가 공간 계산에 assignment-size 속성을 쓰지만, IPv4 묶음 안의 할당 크기는 제각각일 수 있다. 그래서 그 속성은 선택 사항이다. 반대로 공통 용도와 연락처는 필수다. 이웃한 주소라고 해서 서로 다른 고객 용도를 마구 한 폴더에 넣을 수는 없다.

토론에서는 최종 이용자의 연락처가 보이지 않을 수 있다는 우려도 나왔다. 바깥 객체에 LIR 담당자만 적히면 특정 이용자에게 어떻게 닿을까? 제안 원문은 이 반론과 함께, 기존 정책에서도 일부 LIR 연락처를 이용한 할당이 규정에 맞는다는 RIPE NCC의 해석을 담았다. 연락처 요건 전체를 다시 쓰는 문제는 별도 논의로 남기고, 이번 변경은 반복 등록과 감사 가능한 숫자에 집중했다.

2024년 4월 15일 제안이 채택됐다. 2023년 숫자는 출발점의 모습이지 이후 이용률이 아니다. Anderson와 동료가 만든 세 번째 서랍은 공공 장부를 읽기 쉽게 하면서도, 실제 배분을 한 운영자가 안의 내용을 설명하게 한다.

원문 기록