요약

  • RFC 9812는 IETF 예약 IPv6 공간의 향후 비일상적 사용에 대해IESG Approval을IETF Review로 대체한다. 이는 향후 결정을 누가 검토해야 하는지, 그리고 그 결정이 어떤 공개 산출물을 요구하는지를 바꾼다.
  • 이 RFC의 직접적인 IANA 조치는 등록 절차 갱신이다. 프리픽스를 선택하거나, 목적을 승인하거나, RIR에 공간을 위임하거나, 경로를 승인하거나, 배포를 입증하지 않는다.
  • 예약에서 사용으로 이어지는 접수증에는 상시 정책, 이후 요청, IETF 결정, 정확한 레지스트리 변경, 위임 및 운영 관찰을 분리해 기록해야 한다. 이는 Daniel Kade의 편집 제안이며 RFC 필드가 아니다.

레지스트리 행은 오독하기 쉽다. IPv6 공간의 상당 부분이 'IETF에 의해 예약됨'으로 표시되어 있고, 이 레지스트리는 이제 해당 절차로 RFC 9812를 인용한다. 이 두 사실을 'IETF Review'라는 표현과 나란히 두면, 느슨한 서술이 마치 IETF가 방금 또 다른 주소 블록을 공개한 것처럼 들리게 할 수 있다.

그러나 그렇지 않다.

RFC 9812는 향후 결정이 통과해야 하는 관문에 관한 짧은 Best Current Practice 문서이다. 그 직접적 효과는 IPv6 Address Space 레지스트리에 표시된 등록 절차를 대체하는 것이다. 이전 라벨인IESG Approval은 인터넷 엔지니어링 운영 그룹(IESG)이 반드시 RFC를 요구하지 않고도 사안별로 할당을 승인할 수 있게 했다. 새 라벨인IETF Review는 IETF 스트림 RFC, IETF Last Call, 그리고 문서가 IETF 합의를 반영한다는 IESG 결론을 요구한다. 기록과 검토 표면이 더 크기 때문에 절차가 더 엄격하다.

그렇다고 관문 반대편의 대상이 실재하는 것은 아니다. RFC 9812는 어떤 정확한 프리픽스도 요청하지 않는다. 의도된 사용을 선택하지 않는다. 새로운 목적을 위한 하류 레지스트리 항목을 생성하지 않는다. 지역 인터넷 레지스트리(RIR)에 주소를 위임하지 않는다. 어떤 네트워크도 경로를 시작하지 않는다. 이 RFC는 미래 행위의 조건을 강화할 뿐, 그 행위를 수행하지 않는다.

예약 상태와 활성 풀은 다른 상태이다

RFC 9812는 이름공간의 구조에서 시작한다.2000::/3은 현재 지정된 글로벌 유니캐스트 범위로, IANA 할당이 글로벌 유니캐스트 레지스트리에 기록된다. 최상위 공간의 상당 부분은 현재 125비트 유니캐스트 공간이 불충분하거나 부적합해지는 경우에 대비해 가능한 미래 사용을 위해 'IETF에 의해 예약됨'으로 유지된다.

예약은 처분(disposition)이지 예측이 아니다. 이는 모든 하위 범위에서 미사용이라는 뜻도, 요청 시 사용 가능하다는 뜻도, 운영자의 소유라는 뜻도, RIR에 위임되었다는 뜻도, 라우터가 수용했다는 뜻도, 공개가 약속되었다는 뜻도 아니다. 활성 IANA 표 자체에도 단서가 붙어 있다. 여러 최상위 예약 범위에는 부분적 특수 목적 할당이나 과거 사용이 포함되어 있다. 이 라벨은 독자에게 내일의 주소 계획이 무엇일지가 아니라, 처분을 변경할 권한이 어디에 있는지를 알려준다.

이 구분이 중요한 이유는 규모가 과장을 부르기 때문이다. RFC 9812는 전체 주소 공간의 약 8분의 7을 예약으로 기술한다. 큰 분모는 절차적 변경을 자원 사건처럼 들리게 할 수 있다. 그러나 더 강한 관문 뒤에 놓인 수량은 관문을 강화하는 행위 자체로 인해 이동하지 않았다.

IESG Approval과IETF Review는 동의어가 아니다

RFC 8126은 두 정책을 정확히 정의한다. IESG Approval은 IESG가 RFC 없이 새 할당을 승인할 수 있게 하지만, 문서화를 요구하거나 커뮤니티에 자문할 수 있다. 이 메커니즘은 예외적으로 쓰이도록 설계되었다. 다른 정책을 제때 사용할 수 없거나 설득력 있는 이유가 존재하는 경우의 대안이다. 명시적으로, 사용할 수 있었던 공개 검토를 우회하는 지름길이 아니다.

IETF Review는 다른 체인을 요구한다. 할당은 워킹 그룹 문서 또는 AD 후견 문서로 IESG를 통해 진행되는 IETF 스트림 RFC에 문서화되어야 한다. IETF Last Call을 거치고, IETF 합의를 대표한다는 IESG 승인을 받아야 한다. RFC는 Standards Track일 필요가 없다. 이 마지막 경계는 의도된 것이다. 새 주소 범위를 여는 작업은 새 프로토콜 표준을 정의하지 않으면서도 공개적 IETF 검토를 필요로 할 수 있다.

따라서 RFC 9812는 권한의 최소 증명을 변경한다. 이 레지스트리 정책 하에서 미래 할당은 더 이상 IESG의 예외적 결정만으로 뒷받침될 수 없다. 내구성 있는 IETF 문서와 그것을 지탱하는 공개 절차가 필요하다. 강화되는 것은 결정의 출처(provenance)이지, 결정이 이미 일어났다는 증거가 아니다.

과거의 한 할당은 예시이지 본체가 아니다

RFC 9812는5f00::/16을 가리킨다. RFC 9602는 이 블록을 IPv6 Segment Identifier를 위한 Segment Routing용으로 할당하고 특수 목적 레지스트리에 추가했다. 해당 문서는 워킹 그룹과 더 강한 검토 경로를 통과했다. RFC 9812는 상당한 할당이 이미 IETF Review를 충족할 수 있음을 보이기 위해 이를 인용한다.

시간 순서는 흔한 오류를 막는다. RFC 9602는 2024년 10월에 발행되었다. RFC 9812는 2025년 10월에 뒤따랐다. 후자는5f00::/16을 할당하지 않았다. 새로운 상시 정책을 설명하면서 이전 사례를 인용했을 뿐이다. 이 예시가 모든 미래 요청이 SRv6 목적, 블록 크기 또는 레지스트리 목적지를 따라야 한다는 뜻도 아니다. 이후 각 요청은 자신의 자원, 의도된 사용, IANA 조치를 명명해야 한다.

따라서 거버넌스 서술은5f00::/16을 선례 증거로 표기해야 한다. 이는 RFC 9812가 산출한 새 할당도 아니고, 다음에 이동할 예약 블록에 대한 예측도 아니다.

정책 행은 실행 로그가 아니다

IANA 레지스트리는 여러 역할을 동시에 수행한다. 현재의 처분, 참조, 때로는 날짜, 그리고 미래 변경이 이루어질 수 있는 정책을 보여준다. 이 필드들은 서로 관련되지만 하나의 사건은 아니다.

RFC 9812의 IANA Considerations 절은 절차가IETF Review가 되도록 요청한다. IANA가 이 편집을 수행하면, 정책 행은 다음 해당 요청을 지배하는 승인 기준이 무엇인지를 입증한다. 요청이 대기 중임을 입증하지는 않는다. 이후 IETF 스트림 RFC가 프리픽스를 승인하면, 그 RFC가 승인된 지시를 입증한다. 변경된 레지스트리 행은 IANA가 지시를 실행했음을 입증한다. 이후 IANA에서 RIR로의 위임, 경로 광고, 관찰된 도달 가능성은 각각 자체 증거를 요구한다.

이 체인을 'IETF가 공간을 할당했다'로 압축하면 RFC 9812가 답하도록 설계된 질문, 즉 어떤 공개 검토가 변경을 정당화했는지가 파괴된다. 또한 잘못된 운영 확신을 만든다. 레지스트리 참조는 필터가 해당 범위를 수용하는지, 장비가 사용을 지원하는지, 경로가 일관되게 전파되는지, 애플리케이션이 동작하는지 보여줄 수 없다.

오래된 문서 상태 정정도 또 하나의 경고이다

RFC 9812는 RFC 1881의 상태도 다룬다. 1995년 이 문서는 IETF Last Call을 거친 IAB/IESG 공동 발행물을 통해 IPv6 주소 공간 관리를 IANA에 위임했다. 이후 RFC 시리즈 체계에서는 IETF Stream에 속함에도 불구하고, RFC 색인에서는 Legacy로 표기되어 있었다.

이 정정은 작지만 시사적이다. 메타데이터 라벨은 실제로 문서를 산출한 절차에서 표류할 수 있다. 라벨을 고치는 것이 1995년 결정을 다시 실행하거나 그 이후의 모든 운영 할당을 바꾸지는 않는다. 이는 기록을 수선하여 이후 독자가 권한을 올바르게 귀속할 수 있게 한다.

동일한 규율이 새 정책에도 적용되어야 한다. 무엇이, 어떤 문서에 따라, 어느 레지스트리에서, 언제 변경되었는지를 기록하라. 절차적 라벨만으로 자원 행위를 추론하지 마라.

예약에서 사용까지의 접수증을 만들어라

유용한 증거 기록은 프리픽스가 이동하기 전에 시작된다. 여기서 제안하는예약-사용 접수증(reservation-to-use receipt)은 편집적 통제이며, RFC 9812의 필드도 IANA에 대한 지시도 아니다.

첫 번째 계층은 상시 상태를 기록한다. 정확한 레지스트리, 정확한 예약 범위, 적용 정책, 지배 참조 및 관찰 시점. 두 번째 계층은 이후 요청을 기록한다. 요청된 프리픽스, 목적, 요청 문서, 스트림, 후견인, 워킹 그룹 상태, 그리고 변경될 정확한 원본 및 대상 레지스트리.

결정 계층은 Last Call, 실질적 수정, 합의 결론, IESG 승인 및 최종 RFC를 보존한다. 실행 계층은 각 IANA 변경을 독립적으로 기록한다. 이전 행, 새 행, 참조, 날짜, 그리고 해당 조치가 공간을 생성, 이동, 분할 또는 재분류했는지 여부. RFC가 발행되었다는 이유만으로 하류 조치를 완료로 표시하지 않는다.

운영 계층은 다시 별도이다. 관련이 있는 경우, IANA에서 RIR로의 할당, RIR 기록, 경로 시작, 필터링 관찰 및 배포 주장을 자체 출처와 날짜에 연결한다. '알 수 없음'은 유효한 상태이다. '승인되었으나 아직 반영되지 않음', '등록되었으나 위임되지 않음', '광고되었으나 광범위하게 도달 불가'는 접수증의 실패가 아니라, 접수증이 보존하기 위해 존재하는 구분들이다.

그러면 최소한의 공개 진술을 정확하게 할 수 있다. 정책이 변경되었다. 요청이 검토에 들어갔다. 문서가 승인되었다. IANA가 행을 변경했다. 운영자가 사용을 시작했다. 각 동사는 자체 증거로만 닫힌다.

책임성은 행들 사이에 존재한다

RFC 9812는 이 변경이 직접적인 보안 영향은 없으며, 신중하게 검토된 할당 메커니즘이 운영적 주소 책임성에 필요하다고 말한다. 이 문장은 커뮤니티 검토가 모든 잘못된 결정을 막는다고 약속하지 않는다. 권한과 목적을 나중에 재구성할 수 없는 할당의 비용을 지적한다.

더 강한 절차는 미래 결정을 검사하기 쉽게 만든다. 결과를 과장할 유인을 제거하지는 않는다. 저자는 정책 진전을 배포 진전으로 제시하고 싶을 수 있다. 운영자는 할당을 더 넓은 인터넷이 수용할 것이라는 증명으로 취급할 수 있다. 기관은 실행을 보이지 않고 합의를 언급할 수 있다. 대시보드는 유효 날짜나 원본 결정 없이 레지스트리 상태를 보여줄 수 있다.

해독제는 희소나 풍부에 대한 또 하나의 슬로건이 아니다. 귀속 가능한 상태 변경의 체인이다. RFC 9812는 이 체인의 첫 상태, 즉 주요 결정을 내리는 규칙을 변경한다. 이후 모든 상태의 무결성은 여전히 획득되어야 한다.

출처