요약

  • APNIC-127은 현재 최소 IPv4 위임을/24, 103/8에서 받을 수 있는 총량의 최대를/23으로 규정한다. 초기 LIR 심사는/24의 즉시 수요를 요구한 뒤, 1년 안에 최소/23을 사용한다는 상세 계획을 요구한다.
  • APNIC 62에서 논의 중인 Prop-169는 고정된/23을 “심사 대상 위임”으로 대체한다. 공개된 범위는 수요 평가, 보전 원칙과 현행 한도를 유지하며, 새로운 권리를 만들지 않고, 더 넓은 위임·이전·대기자 명단 문제를 다시 열지도 않는다.
  • 이 수리는 하나의 문구로 뭉개질 수 있는 세 가지 값에 이름을 붙여야 한다. 요청된 프리픽스, 평가된 프리픽스, 최종 위임된 프리픽스. 보호된 버전 기록이 이를 묶어줄 수 있으며, 고객 계획을 공개하거나 레지스트리가 신청자의 네트워크를 설계하게 하지 않아도 된다.

1비트의 모순

CIDR 표기는 그 정치를 숨길 만큼 절약적으로 보인다. 프리픽스 길이에 1을 더하면 주소 블록은 절반이 된다./23은 512개 IPv4 주소를 담는다./24는 256개다. 산술은 초등적이다. 그것이 판단 규칙 안에서 차지하는 자리는 아니다.

현행APNIC 인터넷 번호 자원 정책은 두 값을 같은 초기 LIR 심사에 넣는다. 6.1조는/24를 최소 위임으로,/23을 계정 보유자가 103/8에서 받을 수 있는 총량의 최대로 정한다. 6.2.1조는 이어서 LIR이 업스트림 제공자로부터/24를 이미 사용했거나 그 즉시 수요를 입증하고, 이전 자원에 대해 정책을 준수했으며, 1년 안에 최소/23을 사용한다는 상세 계획을 입증하도록 요구한다.

따라서 이 규칙은 네트워크에 256개 주소의 즉시 수요와 최소 512개 주소의 미래 사용을 동시에 증명하게 할 수 있다. 평가 대상 위임이/23이라면 이는 일관성 있을 수 있다. 요청이/24를 다룬다면 어색하다. 계획이 획득하는 블록을 넘어선 성장을 서술할 수 있지만, 정책은 그것이 무엇을 검증하는지 명시해야 한다. 그렇지 않으면 신청자는 두 번째 수치가 권리인지, 예측인지, 장벽인지, 상속된 문구인지 알 수 없다.

일반 텍스트APNIC-127 식별 문서는 그 스냅샷을 확정한다. 스스로를 2025년 2월 20일자 버전 015, 활성 문서로 밝히며, 같은/24최소,/23최대,/231년 계획을 반복한다. Prop-169는 아직 그 안에 들어 있지 않다.

이 상태 구분이 중요하다. 제안은 규칙을 바꾸지 않고도 결함을 지적할 수 있다. 명확한 설명은 구현이 되지 않으면서 구현을 준비할 수 있다.

좁은 수리가 올바른 첫걸음이다

prop-169의 공개 메일링 리스트 사본은 수술적 변경을 서술한다. 최소/23에 대한 계획을 요구하는 대신, 그 조항은 1년 안에 심사 대상 IPv4 위임의 사용에 대한 상세 계획을 APNIC-127의 적용 가능한 위임 한도 내에서 요구하게 된다.

이는 더 나은 문장이다. 여러 가능한 수치를 아우르도록 만들어진 문장에서 고정된 수치를 제거한다. 1년의 지평을 보존한다. 모든 초기 LIR이 최대치를 받아야 한다고 가장하지 않는다.

그러나 여전히 제안이다. 버전 1은 2026년 7월 13일 정책 SIG 리스트에 올라왔으며, APNIC 62 Open Policy Meeting에서 논의 예정이다. 회의 논의, 합의, 이후 의견 접수, 승인, 편집 텍스트, 운영적 사용은 여전히 별개의 사건이다.

보관된 제안은 절제되어 있다. 여전히 고정/23을 언급하는 평가 노트, 가이던스, 신청자 대상 자료의 갱신을 예상한다. 수요 평가, 보전 원칙, 현행 한도를 보존하며, 새로운 권리를 만들지 않고, 더 넓은 위임·이전·대기자 명단 문제는 다시 열지 않는다고 명시한다.

좁은 문구 변경도 판단 궤적이 기억해야 할 것을 바꿀 수 있다. 레지스트리는 같은 프리픽스를 같은 종류의 행에 저장하면서도, 그것을 선택하는 데 쓰인 분모와 근거는 달라질 수 있다. 그 차이는 요청·심사 기록에 있지, 반드시 공개 위임 객체에 있는 것은 아니다.

중립적인NOG Alliance 제안 트래커는 prop-169를 “APNIC 62에서 논의 예정”으로 표시한다. 이는 미래의 회의 상태이지 결과가 아니다. 제안 자체의/24예는 문구 문제를 설명하며, 명시된 범위는 더 넓은 IPv4 정책을 이 수리 밖에 둔다.

이 글은 그 주제들을 몰래 끌어들이지 않는다. 문제는 더 작다. 대체 문구가 다른 심사자가 재구성할 수 있는 결과를 남기는가.

변수에는 지시 대상이 필요하다

“심사 대상 위임”은 정관사를 담고 있어 정밀해 보인다. 그러나 문법의 한정성은 거래의 동일성이 아니다.

주소 요청에는 최소 세 개의 수치가 존재할 수 있다. 요청된 프리픽스는 신청자가 제출하는 것이다. 평가된 프리픽스는 심사자가 1년 계획을 판단할 때 쓰는 분모다. 위임된 프리픽스는 APNIC 또는 NIR이 최종적으로 레지스트리에 넣는 것이다. 정상적인 요청은 같은/24를 세 단계 모두에서 담을 수 있다. 그래서 필드를 합쳐도 된다는 것은 아니다. 기록이same-as-requested라고 명시해 평범한 경로를 저렴하게 만들어야 한다는 근거다.

값이 달라지면 이 구분이 본질이 된다. 신청자가/23을 요청했는데 심사자가/24에 대한 근거를 찾을 수 있다. 질문 이후 신청자가 요청을 수정할 수 있다. 총 보유량 한도가 최종 양을 제한할 수 있다. 이 글은 이러한 전환이 현재 실무에서 일어난다고 말하지 않는다. 제안된 공개 문장이 이들을 배제하지도 명명하지도 않는다고 말한다.

근처에 네 번째 숫자가 있지만, 또 다른 거래 값은 아니다. 잔여 권리는 계산이다. 적용 가능한 최대치에서 현재 관련 보유량을 뺀 값. 요청을 제약할 수 있지만, 신청자의 요청이나 심사자의 사실적 결론과 혼동되어서는 안 된다.

현행 정책은 인접 경로에서 더 명시적인 문법을 이미 보여준다. 6.2.2조는 멀티호밍 신청자가 요청 주소의 25% 즉시 사용과 50% 1년 사용을 입증하도록 한다. 이는 다른 자격 범주이며 다르게 유지되어야 한다. 그럼에도 APNIC-127이 떠다니는 객체가 아니라 명명된 수량에 검증을 묶을 수 있음을 증명한다.

prop-169에 대한 올바른 질문은 그 백분율을 복제해야 하는가가 아니다. 그래선 안 된다. “심사 대상”이 그만큼 명확하게 묶일 수 있는가가 문제다.

정책의 세 시간 지평이 묶음을 더 중요하게 만든다

5.2.1조에는 1년 예측만 담겨 있지 않다. 위임 요청에 즉시 수요, 1년, 2년에 대한 문서화된 추정치를 담도록 요구한다. 일반 지침으로 25% 즉시, 1년 내 50%를 제시한다. 최종 사용자가 2년 수요를 확신 있게 추정할 수 없을 때, 정책은 APNIC 또는 NIR이 1년 수요에 충분한 위임만 하도록 허용한다.

여기에 두 번째 구분 집합이 도입된다. 예측 지평, 근거 신뢰도, 결정 수량. 2년 예측은 불확실해도 즉시 요구가 거짓이 되지 않는다. 1년 수량이 최종 위임이 되어도 2년 수치가 깨진 약속이 되지 않는다. 심사자는 신청자의 아키텍처를 채택하지 않고 예측을 검증할 수 있다.

공개 규칙이 더 내구적이 되려면 어느 지평이 어느 수량을 결정했는지 기록해야 한다. 그렇지 않으면 “심사 대상 위임”은 제출 시점의 요청 블록, 즉시 사용 검토 후 선택된 블록, 또는 2년 예측을 할인한 후 선택된 블록을 의미할 수 있다.

후속 위임 정책이 유용한 절차적 단서를 준다. 7조는 결정이 검증된 과거 사용, 문서화된 계획과 준수에 의존하고 최대 1년까지의 추정 수요를 충족할 수 있다고 한다. APNIC 또는 NIR이 더 짧은 기간을 선택하면 기간과 그 이유를 LIR에 알려야 한다. 그것이 올바른 직관이다. 변수 결과가 좁아지는 곳에서는 변수의 이름을 붙이고 선택을 설명하라.

현행 공개 가이던스는 천장을 서술할 뿐 그 길을 서술하지 않는다

APNIC의포스트 소진 페이지는 회원에게 103/8의 총 최대가/23이며, 최대에 도달한 회원은 APNIC에서 더 받을 수 없고, 최대 미달인 기존 회원은 MyAPNIC에서 요청을 제출할 수 있다고 알린다./23이상이 필요한 네트워크는 이전으로 안내된다.

이해 가능한 공개 가이던스다. 천장이 무엇인지 어디서 시작하는지 답한다. 신청서의 비공개 필드, 직원이 근거를 평가하는 기준 크기, 부분 결과의 이유를 보여준다고 주장하지 않는다. 공개 천장과 보호된 결정 기록은 다른 역할을 한다.

희소성은 이 구분을 덜 중요하게 만드는 게 아니라 더 중요하게 만든다. 자유 풀 결정은 고객 계약을 노출할 필요가 없다. 재현 가능해야 한다. 더 작은 블록이 부여될 때, 내구적 기록은 권리 부족, 근거 부족, 잔여 보유량 산술, 신청자의 자발적 수정을 구분해야 한다. 이 이유들은 같은 의미가 아니며 같은 선례를 만들어서는 안 된다.

/23은 천장이 되었고,/24는 바닥에 남았다

두 크기 사이의 간격에는 문서화된 역사가 있다.JPNIC 인터넷 타임라인은 APNIC 47에서 prop-127 합의와 이후 정책 제정을 기록한다. JPNIC는 반납 재고에서의 최대/22할당을 종료하고 그 경로를/23에 맞췄다. 오늘날의/24최소를 제공하는 것은 이 역사 페이지가 아니라 보관된 현행 정책이다.

그 사건은 남아 있는 모든 문장 뒤의 주관적 의도를 설명하지 않는다. 그러나 현재의 요청이 허용된 두 크기 사이에 있을 수 있는 이유는 설명한다. 고정/23계획 조항은 최대치와 나란히 읽으면 자연스러워 보일 수 있다. 최소치가 여전히 사용 가능함에도.

이후 논쟁은 반대 방향으로 갔다.Prop-152는 당시 사용 가능한 풀의 소진 후 최대치를/24로 낮추고 이후 위임을 신규 계정 보유자로 제한하자는 제안이었다. 합의에 이르지 못하고 2024년 2월에 폐기되었다. 현행 정책이 아니다.

그 영향 평가에는 prop-169를 결정하지 않으면서도 유용한 설계 교훈이 담겨 있다. 사무국은 논의 중 바뀔 수 있는 실시간 재고 수치를 정책에 넣는 것을 경계했다. 안정적 정책은 변수와 그것을 공급하는 출처를 식별해야 한다. 그러나 변수는 그 숫자가 제거되었다고 해서 안정해지는 것이 아니다. 지시 대상과 버전도 고정되어야 한다.

최소한의 보호된 크기 결정 기록

이것이 40페이지짜리 신청 헌법이 될 필요는 없다. 공통 기록은 엄격하고 작을 수 있다. 민감한 근거는 보호된 채로 남을 수 있다. 공개 투영은 고객, 토폴로지, 계약을 노출하지 않으면서 유한한 사유 코드와 집계 경로를 보여줄 수 있다.

기록에는 16개 필드가 있어야 한다.

  1. 요청 식별자와 타임스탬프.요청에 안정적 식별자, 제출 시각, 수정 또는 대체 제출에 대한 명시적 링크를 부여한다.
  2. 규칙 식별자.APNIC-127 버전, 정확한 조항, 발효일, 결정에 사용된 제안 파생 구현 버전을 기록한다.
  3. 결정 권한.APNIC 또는 관련 NIR, 심사자 역할, 위임 경로를 명시한다. 일반적인 시스템 이름 뒤에 권한을 숨기지 않는다.
  4. 신청자 등급과 자격 경로.초기 LIR, 멀티호밍, 핵심 인프라, IXP 또는 다른 승인 경로를 구분해 하나의 검증이 다른 경로에 몰래 빌려지지 않도록 한다.
  5. 현재 관련 보유량.103/8 보유량, 기타 관련 자원, 사용된 잔여 권리 계산, 각 입력의 정책 범위를 기록한다.
  6. 요청된 프리픽스.정확한 프리픽스 길이, 주소 수, 신청자 선언 수정본을 저장한다./23과 512는 하나의 값의 기계 검증 가능한 뷰여야 한다.
  7. 즉시 수요 기준선.수량과 운영 기능을 보호된 근거 참조에 묶는다. 하나의 선호된 네트워크 다이어그램을 규칙으로 만들지 않는다.
  8. 1년 계획 분모.예측이 평가되는 정확한 프리픽스와 주소 수를 명시한다. prop-169의 명사가 필요로 하는 필드다.
  9. 2년 예측 상태.제출됨, 확신 있게 추정 불가, 해당 없음으로 표시하고 그 처리를 뒷받침하는 조항을 기록한다.
  10. 근거 보관.문서 식별자, 해시, 접근 등급, 보존, 개인정보 처리, 정정을 고객 상세 공개 없이 유지한다.
  11. 평가된 프리픽스.정확한 수량, 그것이 결정 분모가 된 시점, 그것을 허용한 규칙을 기록한다.
  12. 차이 코드.평가가 요청과 다르면 관련 사실에 묶인 유한한 사유를 제시한다. 다르지 않으면same-as-requested를 기록한다.
  13. 질문·응답 이력.실질적 질문, 답변, 타임스탬프를 보존하고, 각 교환 후 어느 필드가 바뀌었는지 식별한다.
  14. 최종 위임 프리픽스.최종 수량을 레지스트리 사건, 프리픽스, 시각에 묶고 평가값과의 차이를 기록한다.
  15. 결과와 정정 경로.부여, 부분 부여, 거절, 철회, 보류를 구분한다. 사유, 검토·재고 경로, 정정을 함께 전달한다.
  16. 개인정보 안전 집계 투영.요청→평가→위임 경로 수, 처리 시간 구간, 차이 사유, 철회, 정정을 신청자 이름 없이 공개한다.

필드 목록은 사업 계획을 열린 인터넷에 올리자는 주장이 아니다. 해시는 민감한 근거를 공개로 만들지 않는다. 공개 개수에는 신청자 이름이 필요 없다. 사유 코드는 고객을 노출하지 않고remaining-entitlement-limit라고 말할 수 있다. 개인정보 보호와 재현 가능성은 대립하지 않는다.

장부 필드는 아키텍처 지시가 아니다

Minimum Initial Specification은 유용한 경계를 제공한다. 공통 계층은 공유 조정에 필요한 최소 사실에 대해 정확해야 한다. 이후의 운영 선택은 네트워크를 운영하는 사람들에게 남겨야 한다.

이 사례에서 요청 식별자, 규칙 버전, 수량, 권한, 레지스트리 전환은 공통 사실이다. 고객 구성, 라우터 벤더, 주소 계획, 변환 방식, 제품 설계, 상업적 시점은 아니다. APNIC이 희소한 자유 풀 자원을 발급하기 전에 수요를 검증한다면, 선호하는 근거 형식을 승인된 네트워크 설계로 바꾸지 않고 관련 근거를 검토할 수 있다.

이 경계는 양쪽을 모두 규율한다. 신청자는 “미래 성장”을 검증 불가능한 슬로건으로 만들 수 없다. 심사자는 “상세”를 무제한의 비공개 정보 요구로 만들 수 없다. 각 질문은 명명된 수량과 규칙에 연결되어야 한다. 각 결과는 같은 필드에 연결되어야 한다.

APNIC의정책 개발 절차는 개방성, 투명성, 바텀업 의사결정을 서술하고 제안 결과를 공개 기록으로 취급한다. 이 가치들은 절차를 통과하는 객체가 식별 가능하게 유지될 때만 작동한다. 변수 문구에 대한 합의는 그 변수가 이후 채워질 모든 미공개 방식에 대한 합의가 아니다.

공개 정책은 좁게 남을 수 있다. 구현 기록은 정확해야 한다.

출처

근거가 보여주지 않는 것

이 기록의 어떤 공개 출처도 APNIC 또는 NIR이 고정/23조항 때문에 특정 요청을 거절, 지연 또는 축소한 것을 보여주지 않는다. 어떤 출처도 요청·평가·최종 크기별로 요청을 집계하지 않는다. 어떤 출처도 현재의 내부 양식이나 심사자 노트를 노출하지 않는다. 따라서 이 글은 문구상 모호성을 지적하고 기록을 권고한다. 부정 행위 패턴을 보도하는 것이 아니다.

근거는 또한 APNIC 62를 예측하지 않는다. 이 스냅샷 시점에 회의는 아직 열리지 않았다. 새 버전은 수량을 더 단단히 묶거나, 현행 문구를 유지하거나, 제안의 범위를 바꿀 수 있다. 각각은 새로운 사실일 것이다.