요약

  • Prop-164-v005는 APNIC의 최소 IPv6 할당을/32에서/40으로 낮추고, 더 작은 니블 경계 할당을 도입하며, 반납·축소·예약 장치를 추가합니다.
  • Prop-170-v001은/32최소값을 유지하고, 신청자가 명시적으로 정렬을 요청했고 기존 필요성 검증이 그 요구를 인정한 경우에만 할당을 정렬합니다.
  • 사무국의 8월 18일 영향 평가는 두 안이 모두 합의에 도달하면 원문 수정이 필요하다고 말합니다. APNIC 62가 이들을 심판하기 전에 커뮤니티는164만,170만,둘 다,둘 다 아님이 실제로 무엇을 허용하는지 볼 수 있어야 합니다.

하나의 라벨이 지금 서로 다른 두 기준선을 지배하고 있다

NOG Alliance 정책 개요는 prop-164와 prop-170을 별도 항목으로 APNIC 62 논의 대상에 올려 두고 있습니다. 제목에 거의 동일한 문구가 들어가 있는 것보다 이 분리가 더 중요합니다.

Prop-164는 할당 규모의 가장 아래쪽에서 누가 무엇을 받을 수 있는지를 바꿉니다.현재 다섯 번째 버전은/32하한을/40으로 대체하고,/32,/36,/40같은 니블 경계 단계를 허용하며, 일부 기존 보유자가 잉여 공간을 반납하고 할당을 축소할 수 있는 경로를 도입합니다. 또한 희소 배치와 인접 예약을 설계에 명시해 작게 시작한 블록이 나중에 성장할 수 있도록 합니다.

Prop-170-v001은 그 하한을 그대로 둡니다. 이 제안은 이미 통상적인 필요성 평가를 통과한 요청에 적용됩니다. 신청자가 명시적으로 정렬을 요청하면, 그 결과로 나오는 할당은 4비트 경계로 반올림될 수 있습니다. 이 제안은 할당(assignment)에는 적용되지 않으며, 기존 보유자에게 원칙적으로 반납, 크기 조정, 리넘버링을 명령하지도 않습니다.

이는 같은 결과에 대한 두 가지 표현이 아닙니다. 한쪽은 허용되는 소형 할당의 범위를 넓히고 반납·예약 경로를 만듭니다. 다른 쪽은 기존 할당 절차에 조건부 크기 조정 단계를 추가합니다. 커뮤니티 구성원은 16진 표기 가독성에 대한 견해와 모순되지 않으면서 한쪽을 지지하고 다른 쪽에 반대할 수 있습니다.

역사가 이 구분을 더 쉽게 보여 줍니다.prop-164의 이전 원문 외부 아카이브는 문제를 불필요하게 큰 할당을 받는 것과 하위 하위 할당을 의도한 대로 표현할 수 없는 할당(assignment)을 받는 것 사이의 선택으로 제시했습니다.JPNIC 리뷰는 같은 할당 대 할당의 딜레마를 일본 독자를 위해 설명했습니다. 이후 제안은/36에서/40으로 이동하고 더 명시적인 성장 장치를 갖추었습니다. 결정 면은 버전 번호가 아니라 실질적으로 커진 것입니다.

8월 18일 경고는 편집적 각주가 아니다

8월 18일에 게시된 현재 영향 평가들은 각 제안에 서로 다른 구현 작업을 붙입니다.Prop-164의 평가는 약 9개월을 추정하며, 더 작은 할당, 축소 요청, 예약 처리를 위한 레지스트리 지원이 필요하다고 합니다. 기존 보유자가/36까지 축소할 수 있는지 아니면/40만 가능한지, 적합한 인접 공간이 없으면 어떻게 되는지, 명시적 예약이 기존 희소 배치에 무엇을 더하는지를 묻습니다.

Prop-170의 평가는 약 6개월을 추정합니다. 필요성 기반 체계를 유지하면서 조건부 정렬을 위한 안내와 평가 변경이 필요합니다. 평가는/32최소값이 유지되고, 할당(assignment)은 범위 밖이며, 기존 보유자는 통상 이동할 필요가 없다고 말합니다.

그런 다음 두 기록 모두 같은 경고를 덧붙입니다: “prop-164와 prop-170이 모두 합의에 도달하면 정책이 충돌하지 않도록 초안 수정이 필요할 것입니다.”

이 문장이 결정 문제를 만듭니다. 편집 작업은 커뮤니티 판단 이후에 번호, 용어, 상호 참조를 조정할 수 있습니다. 그러나 편집 작업이/32가 최소값으로 남는지, 보유자에게 새 반납 경로가 생기는지, 인접 공간을 예약해야 하는지, 신청자가 어느 평가 경로로 들어가는지를 정해서는 안 됩니다. 이것들은 이익, 비용, 운영 결과가 다른 정책 상태입니다.

이전 운영자 논의는 이미 소형 블록에 대한 포괄적 투표가 너무 적은 근거를 제공하는 이유를 보여 주었습니다.Mail Archive에 보존된 피드백은/32에서/36으로의 이동이 나중에/40에 대한 압력을 단순히 부활시키는 것 아닌지 물었고, 주장된 절약 효과에 의문을 제기했습니다.SANOG 정책 업데이트는 이전 버전에 대한 레지스트리 정확성 사례를 문서화했습니다. 이 입장들은 최소값 자체에 관한 것입니다. 이미 검증된 필요 이후에 이루어지는 prop-170의 조건부 정렬에 대한 자동적 근거로 취급될 수 없습니다.

네 가지 결과에는 네 개의 보이는 행이 필요하다

해결책은 9월 10일 Open Policy Meeting 전에 짧은 공개 매트릭스입니다.

prop-164만의 경우, 매트릭스는 새 최소값, 허용되는 니블 단계, 기존 보유자 처리, 반납 조건, 예약 규칙, 인접 공간 대체 방안, 구현 기간을 명시해야 합니다. Prop-170의 조건부 정렬 기제는 조용히 등장해서는 안 됩니다.

prop-170만의 경우,/32가 최소값으로 남습니다. 매트릭스는 요청, 검증, 정렬 단계를 식별하고, 할당(assignment)이 범위 밖으로 남는지 확인하며, 인접 확장이 불가능할 때 무슨 일이 일어나는지 명시해야 합니다. Prop-164의/40진입 경로와 반납 기제는 따라오지 않습니다.

둘 다의 경우, 커뮤니티는 실제 결합 규칙을 필요로 합니다. 어느 제안이 겹치는 정의를 지배합니까?/40최소값이 별도의 평가 후 정렬 단계와 공존할 수 있습니까? 기존 보유자는/36으로,/40으로, 아니면 둘 중 어느 것으로든 축소할 수 있습니까? 인접 용량은 규칙에 따라, 운영 관행에 따라, 아니면 전혀 예약되지 않습니까? 예약된 범위를 사용할 수 없을 때 어떤 조항이 확장을 지배합니까? 나중 조정을 약속하는 주석은 대답이 아닙니다.

둘 다 아님의 경우, 현재 기준선이 유지됩니다. 이 결과도 명시적이어야 하는데, 합의 부재는 안내를 통해 공유된 아이디어를 구현할 허가가 아니기 때문입니다.

매트릭스는 회의장 의장에게 방위를 예측하도록 요구하지 않습니다. 회의장이 답할 수 있을 만큼 질문을 안정화합니다. APNIC 62 전에 합의된 결합 원문이 없다면, 두 합의 판단은 분리된 채 유지될 수 있고 실질적 조정은 다시 보이는 검토로 돌아올 수 있습니다.

프리픽스 미학으로는 제도적 권한이 정해지지 않는다

니블 경계는 유용합니다. 16진 표기에서 모든 자릿수는 4비트를 나타내므로, 4비트 경계는 프리픽스를 읽고, 나누고, 문서화하고, 감사하기 쉽게 만듭니다.RFC 6177은 또한 하나의 엔드 사이트 크기가 모든 네트워크에 맞다는 생각을 거부하고 더 신중한 크기 결정을 지지합니다.

그러나 유용한 기술적 속성이 그에 붙은 모든 거버넌스 질문에 대답하지는 않습니다. APNIC의 커뮤니티 절차는 제안이 합의에 도달하는지를 통제합니다. 의장은 공식 판정을 통제합니다. 편집자는 결과 원문을 준비할 수 있습니다. 사무국은 레지스트리 시스템과 절차에서의 구현을 통제합니다. 리소스 보유자는 할당을 어떻게 서브네팅하고, 문서화하고, 라우팅하고, 사용할지를 통제합니다. Whois와 RDAP는 위임 상태를 기록합니다. 그러나 모든 예약된 주소가 배치되었거나 모든 운영 계획이 성공했다는 증거는 아닙니다.

Lu Heng의Minimum Initial Specification은 여기서 유용한 규율을 제공합니다: 조정에 필요한 공통 규칙만 공유 계층에 두고, 이후 운영 선택은 그 선택을 하는 이들에게 귀속되도록 남겨 둔다. 이는 할당 정책을 금지하지 않습니다. 정책이 어떤 공유 상태를 바꾸고 어떤 선택이 운영 중인 네트워크에 남는지 정확히 말하도록 요구합니다.

따라서 두 제안은 어휘가 아니라 근거로 판단될 수 있습니다./40최소값이 새로운 반납·예약 장치를 정당화할 만큼 레지스트리 정확성을 개선합니까? 조건부 반올림이 필요성을 유지하면서 더 사용하기 쉬운 주소 계획을 만듭니까? 각 기제가 내부 배치 가정을 권리로 바꾸지 않고 구현될 수 있습니까? 이들은 별개의 질문입니다.

회의는 이름 붙일 수 있는 원문을 결정해야 한다

이 기사를 위해 검토한 어떤 자료도 두 제안 중 하나가 통과할 것이라고 확립하지 않습니다. 여섯 번째 버전, 수정안 또는 결합 초안이 9월 10일 전에 도착할 수 있습니다. 구현 추정치는 바뀔 수 있습니다. 아직 논의 중인 정책 원문에서 실제 신청자 결과나 라우팅 효과를 추론할 수 없습니다.

확인된 점은 더 좁습니다. APNIC 자체의 현재 평가들이 가능한 충돌을 식별하지만, 그 해결을 활성 조건—두 제안 모두에 대한 합의—이 충족된 뒤로 미룹니다. 이 순서는 회의 전에 개선될 수 있습니다.

네 개의 행을 게시하십시오. 모든 실질적 조항을 그 조항을 승인하는 제안 또는 결합 원문에 붙이십시오. 결과가 다른 곳에는 별개의 판단을 요구하십시오. 둘 다 지지를 받았지만 결합이 커뮤니티 구성원이 보지 못한 새로운 최소값, 반납 권리, 예약 의무 또는 범위 규칙을 도입한다면, 결합 버전을 게시하고 구두점이 아니라 하나의 제안으로 검토하십시오.

APNIC 62는 깔끔한 16진 계획과 책임 있는 절차 중 하나를 고를 필요가 없습니다. 둘 다 가질 수 있습니다. 첫 단계는 하나의 단어—니블—가 두 정책을 대신 서는 것을 멈추는 것입니다.

출처