요약

  • 2018년 3월 14일 제출 후 3월 20일에 처음 게시된 Draft 1은 원수신자가 운영하는 링크에서 제3자에게 비영구적으로 공급되는 고유 주소 또는 고유/64를 면제했습니다. 5월 9일 AFRINIC-28은 합의가 아니라 "추가 논의 필요"라고 기록했습니다.
  • Draft 2—정확한 식별자는AFPUB-2018-V6-002-DRAFT02, 버전 2.0—는 8월 22일Under Discussion상태로 게시되었습니다. 이 개정은 할당 보유자가 관리·운영하는 네트워크 내에서 제3자 장비 주소 지정과 비영구적 제3자 주소 지정으로 허용되는 사용을 분할하면서, 금지 측에는 반영구적 연결성을 추가했습니다.
  • 따라서 이 개정은 양방향으로 움직였습니다. 계약자 장비를 인정하고 Draft 1의 주소 크기 및 점대점 제약을 제거했지만, 기간 언어는 강화했습니다. 등록 트리거, 집계 테스트, 라우팅 규칙, 연락처 규칙, 구제 수단 또는 항소는 추가하지 않았습니다.
  • 빠져 있던 질문은 운영자와 진실한 레지스트리가 실제로 답을 필요로 하는 것이었습니다: 독립적으로 통제되는 다운스트림 네트워크가 보유자, 책임 연락처, 라우팅 또는 보안 권한, 충돌 상태, 또는 공유 번호 자원 기록이 보여야 하는 다른 사실을 변경했는가?

L3 — 양방향으로 움직인 수정안

문서 기록은 압축해서는 안 되는 두 날짜로 시작합니다. Draft 1의 세부 정보 패널은 2018년 3월 14일 제출을 기록합니다. AFRINIC의 이후 개정 이력은 최초 드래프트가 3월 20일 자원 정책 토론 목록에 게시되었다고 기록합니다. 연속 게시된 드래프트 간 비교에서 3월 20일이 기준일이고, 3월 14일은 별개의 제출일로 남습니다. 이 제안은 "Clarification on IPv6 Sub-Assignments" 계열에 속했으며 통합 정책 매뉴얼의 6.8조 개정을 추구했습니다.

다카르에서 열린 5월 9일 AFRINIC-28에서 Draft 1은 해결되기보다 논의되었습니다. 공식 회의 요약은 실무적 직원 질문을 기록합니다: 제안이 설명하는 임시 사용은 WHOIS에 등록되어야 하는가? 저자 Jordi Palet Martinez는 그것들이 임시이며 등록이 필요하지 않다고 답했습니다. 공동 의장들의 기록된 결론은 "추가 논의 필요"였고, 제안은 다듬기 위해 되돌아갔습니다. 이 교환은 기록 보존 질문을 일찍 드러내기 때문에 중요합니다. 그러나 그 답을 조항으로 만들거나, 합의를 성립시키거나, 이후 각 수정의 동기를 증명하지는 않습니다.

Draft 2는 2018년 8월 22일 도착했습니다. 올바른 식별자는AFPUB-2018-V6-002-DRAFT02이며AFPUB-2018-V6-001-DRAFT02가 아닙니다. V6-001은 별개의 IPv6 Policy and References Update 계열에 속했습니다. AFRINIC은 새 문서를 버전 2.0, 저자 Martinez, 8월 22일 제출,Under Discussion으로 표시했습니다. 이후 제안 색인과 개정 이력이 날짜와 신원을 확인합니다. 이것들은 정확한 상태 경계입니다: 게시는 채택이 아니며, "Under Discussion"은 합의, 비준, 시행, 적용 또는 강제의 동의어가 아닙니다.

개정 이력은 간략한 설명만 제공합니다: 문제 정의문과 제안 문구가 명확성을 위해 갱신되었다고 합니다. 특정 변경을 요구한 참여자를 식별하지 않습니다. 수정안을 임대, 조각화, 집계 또는 등록에 귀속시키지 않습니다. 이해관계자 진영 간의 협상에 대한 날조된 이야기를 뒷받침할 수 없습니다. 따라서 Draft 2를 이해하는 신뢰할 수 있는 방법은 바뀐 단어들을 비교한 다음 그 단어들이 무엇을 분류할지 검증하는 것입니다.

Draft 1의 간결한 안전 항

Draft 1은 구체적 단위와 임시 관계에서 출발했습니다. 원수신자가 운영하는 링크에서 사용될 때 제3자에게 비영구적으로 공급되는 고유 IPv6 주소, 심지어 고유/64는 하위 할당으로 간주되지 않을 것이었습니다. 제안은 인식 가능한 예를 제시했습니다: 게스트, 직원, 기기 또는 서버, 핫스팟, 점대점 링크, VPN. 이 목록은 엔지니어에게 의도된 안전 항을 읽기 쉽게 만들었습니다. 방문자의 휴대폰, 직원의 단말 또는 보유자의 링크에 연결된 서버가 사용하는 주소는 반드시 보유자가 자신의 할당 조각을 다른 네트워크에 이전했다는 의미가 아니었습니다.

단호한 반대편도 있었습니다. 영구 연결성 또는 브로드밴드 서비스는 제안된 하위 할당 금지 안에 남았습니다. Draft 1은 또한 점대점 링크에 대한 특이한 자격을 만들었습니다. 그런 링크의 주소 지정만 영구적일 수 있었고, 할당된 주소 지정은 실제 통신에 직접적 또는 간접적으로 사용될 수 없었습니다. 이 문구는 링크 주소 지정을 실질적 교환의 종단점으로 사용되는 주소와 구분하려 했지만, 일상적인 엔지니어링 패턴을 어려운 텍스트적 허구에 의존하게 만들었습니다. 주소는 통신을 지원하기 위해 존재합니다. 실제 통신에 사용되지 않을 때만 면제하는 규칙은 거짓 양성과 해석적 게임을 부릅니다.

Draft 1의 형태는 간단히 진술할 수 있습니다. 그 무게 중심은 원수신자가 여전히 운영하는 링크에서 비영구적 기간 동안 공급되는 고유 주소 또는/64였습니다. 그 예는 로컬 또는 부착된 사용을 비추었습니다. 그 금지는 영구 연결성과 브로드밴드에 집중했습니다. 그 점대점 조건은 비영구성 조건에 대한 좁은 예외로, 특수한 실제 통신 제한과 결합되어 있었습니다.

그 명확성은 불완전했습니다. "비영구적으로"는 명시된 기간이 없었습니다. "원수신자"와 "운영되는 링크"는 관리가 아웃소싱된 경우, 계약자가 어플라이언스를 설치·지원하는 경우, 여러 당사자가 인프라에 개입하는 경우 무엇이 일어나는지 정하지 않았습니다. 안전 항은 몇 가지 흔한 사례를 설명했지만 그것들을 안전하게 만드는 기저의 기록 조건을 진술하지 않았습니다. 5월 회의에서 WHOIS 질문이 자연스럽게 떠오른 것은 그래서입니다: 이 사례들이 임시이기 때문에 하위 할당 밖이라면, 레지스트리는 무엇이든 알아야 하는가?

Draft 2의 두 갈래 예외

Draft 2는 자신이 설명하는 문제와 제안하는 운용 경계 양쪽을 바꿨습니다. 그 문제 정의문은 최종 사용자가 자신의 공간에서 주소 지정이 필요한 장비를 갖춘 제3자를 고용하는 사례를 추가했습니다. 예는 운영적으로 구체적이었습니다: 카메라, 녹화 시스템, 방화벽, 라우터 또는 전용 VPN을 지원하는 장비. 이 추가는 현대 네트워크의 흔한 사실을 인정했습니다. 조직은 흔히 네트워크를 소유하거나 통제하면서 전문가가 그 안에 장비를 공급·설치·운영합니다. 제3자 장비의 존재 자체가 다운스트림 네트워크를 만들지는 않습니다.

제안 문구는 "and/or"로 결합된 두 갈래를 사용했습니다. 첫째는 점대점 링크 주소를 포함해 제3자 장비에 주소 공간을 공급하는 것이었습니다. 둘째는 제3자에게 주소 공간을 비영구적으로 공급하는 것이었습니다. 둘 다 주소가 할당 보유자가 관리·운영하는 네트워크에서 사용될 때 보호되었습니다. 영구 또는 반영구적 연결성, 브로드밴드 서비스 등은 하위 할당으로 분류되는 채 남았습니다.

각 치환은 중요합니다. "원수신자"는 "할당 보유자"가 되었습니다. 그 수신자의 "운영되는 링크"는 보유자의 "관리·운영되는 네트워크"가 되었습니다. 단일 주소 또는/64는 명시된 단위가 아니게 되었습니다. 게스트, 직원, 핫스팟, VPN과 같은 명칭은 운용 단락에서 사라졌습니다. 다만 주변 문제 정의문은 문맥의 대부분을 유지했습니다. 점대점 주소는 첫 갈래로 이동했고, Draft 1의 영구성과 실제 통신에 관한 특수 규칙은 사라졌습니다. 금지 측에서는 "영구" 곁에 "반영구적"이 삽입되었습니다.

이것들은 한 방향의 변경이 아닙니다. 새로운 반영구적 언어는 서비스 기간 경계를 강화합니다: 관계는 누군가 그것을 영구적이라 부르기를 거부한다고 해서 탈출할 수 없습니다. 관리·운영 네트워크 조건은 원수신자가 운영하는 링크에 대한 Draft 1의 참조보다 더 요구적으로 들릴 수도 있는데, Draft 2는 관리와 운영을 네트워크 규모에서 명시적으로 모두 불러내기 때문입니다. 그러나 다른 편집들은 안전한 쪽을 넓히거나 명확히 합니다. 제3자 장비는 자체 갈래를 받습니다. 계약자가 운영하는 카메라, 라우터, VPN 장비가 이제 명시된 문제의 일부입니다. 단일 주소 또는/64상한은 사라집니다. 영구 점대점 주소 지정이 실제 통신에 사용되어서는 안 된다는 기이한 요구도 사라집니다.

문법은 결과적인 불확실성을 더합니다. "제3자 장비 … 및/또는 제3자에게 주소 공간을 비영구적으로 공급"이라는 서열에서 부사는 명시적으로 두 번째 갈래에 적용됩니다. 텍스트는 첫 갈래를 같은 비영구성 한계 아래 명시적으로 두지 않습니다. 카메라나 방화벽은 장기 설치되어 있으면서 보유자 네트워크 내부의 장치로 남을 수 있습니다. Draft 2는 장치의 존재가 내구적이더라도 보유자가 계속 네트워크를 관리·운영하기 때문에 그 사용을 보호하는 것으로 합리적으로 읽힐 수 있습니다. 그것은 보편적 시간 한계보다 더 운영적인 구분입니다.

그러나 "and/or"는 완전한 이론을 제공하지 않습니다. 두 갈래가 모든 경우에 완전히 독립적인지 말하지 않습니다. 장치가 보유자 인프라 내부의 단순한 장치에서 독립적으로 통제되는 네트워크의 보이는 가장자리로 전환되는 시점도 정의하지 않습니다. 장비 소유는 결정적이지 않습니다. 제3자가 라우터를 소유하면서 할당 보유자가 구성, 라우팅, 보안, 접근을 결정할 수 있습니다. 반대로 보유자가 고객이 별개 다운스트림 네트워크의 일부로 통제하는 하드웨어를 소유할 수 있습니다. 물리적 박스는 증거입니다. 그것은 레지스트리가 궁극적으로 기록해야 할 상태가 아닙니다.

"링크"에서 "네트워크"로의 전환은 비슷한 긴장을 만듭니다. 현대 서비스가 많은 링크와 장치에 걸칠 수 있음을 합리적으로 인정합니다. 그러나 "할당 보유자가 관리·운영하는"은 혼합 관리 환경에 대해 정의되지 않습니다. 보안 계약자가 방화벽을 감시할 수 있습니다. 관리형 서비스 공급자가 구성을 배포할 수 있습니다. 건물 운영자가 케이블링을 통제하면서 임차인이 단말을 통제할 수 있습니다. 카메라 공급업체가 전용 VPN을 통해 자기 어플라이언스를 유지할 수 있습니다. Draft 2는 이러한 배열의 예를 제공하지만 얼마나 많은 외부 관리가 분류를 바꾸는지에 대한 테스트는 없습니다.

무엇이 사라지고, 무엇이 등장하지 않았는가

고유 주소 또는/64단위의 삭제는 지나가는 언급 이상을 받을 만합니다. Draft 1의 수치적 공식은 예외를 좁은 양에 묶었는데, 게스트 단말이나 점대점 링크에는 맞을 수 있지만 기술적으로 건전한 설계를 오분류할 수 있었습니다. IPv6 네트워크는 각 장치를 단일 주소 객체로 다루기보다 프리픽스를 흔히 사용합니다. 2017년 12월 Informational 문서로 발표된 RFC 8273은 공급자 관리 공유 접속 네트워크에서 호스트별 고유 IPv6 프리픽스를 설명합니다. Standards Track이 아니고, AFRINIC 정책이 아니며, 제도적 권위의 원천도 아닙니다. 그러나 엄격한 주소 또는/64어휘가 어떤 배치에는 부적합할 수 있는 이유를 보여줍니다. 그 단위를 제거하는 것은 하나의 할당 패턴을 로컬 사용의 법적 정의로 만들지 않는 길이었습니다.

운용 단락에서 명칭 예의 소실은 더 모호합니다. 예는 독자를 돕지만 우연한 전열 목록으로 굳어질 수 있습니다. "게스트", "직원", "핫스팟", "VPN"을 제거하면 규칙이 더 일반적일 수 있습니다. 동시에 더 많은 무게를 "제3자 장비", "제3자", "관리·운영"이라는 추상 용어로 옮깁니다. 문제 정의문은 문맥을 유지하지만, 조항을 적용하는 운영자는 직원 단말이나 핫스팟이 여전히 보호 측에 있다는 직접적 확신을 덜 받습니다. 결과는 라벨이 아니라 구조에 달려 있습니다: 주소는 보유자가 관리·운영하는 네트워크에서 사용되어야 합니다.

Draft 2의 점대점 링크 처리는 더 명확한 수리입니다. 그 주소들을 제3자 장비 주소 지정 안에 포함시키고, 실제 통신에 사용되지 않을 때만 영구적일 수 있다는 규칙을 폐기합니다. 새 문구는 더 이상 엔지니어에게 그런 억지 방식으로 주소 지정 기능과 통신을 구분하라고 요구하지 않습니다. 그러나 삭제는 또한 첫 갈래 문법에 더 많은 일을 남깁니다. 점대점 주소가 제3자 장비를 연결한다면, 네트워크가 보유자가 관리·운영하는 한 첫 갈래가 명시적 비영구성 조건 없이 그것들을 보호하는 것으로 보입니다.

"반영구적"의 추가는 다른 형태의 회피성을 공격합니다. 내구적 고객 서비스는 짧은 계약의 연속으로 쓰이거나 명목상 종료일을 가질 수 있습니다. 영구성만 결정적이라면 관계의 라벨이 경계를 이길 수 있습니다. "반영구적"은 실질이 중요해야 함을 신호합니다. 그러나 Draft 2는 연결성을 반영구적으로 만드는 기간, 갱신 횟수, 통제 조건 또는 기술적 특성을 제공하지 않습니다. 한 달, 1년, 무기한 갱신되는 일상적 배열은 분류되지 않습니다. 그 단어는 수명이 긴 계약자 어플라이언스와 내구적인 다운스트림 연결성 제품을 구분하지도 않습니다. 실제로 전자는 수년 되어 보호될 수 있고, 후자는 계약상 짧고 금지될 수 있습니다.

가장 중요한 것은 두 드래프트 모두 추가하지 않은 것입니다. 임시 사용이 언제 WHOIS 또는 다른 데이터베이스에 들어가야 하는지 말하는 조항이 없습니다. 책임 연락처, 독립 통제 또는 라우팅 권한에 기반한 트리거가 없습니다. 집계 테스트가 없고 라우팅 투명성 유지 지침이 없습니다. 관련 기간의 정의가 없습니다. 부정확한 기록에 대한 구제 수단이 없고 분류에 대한 항소가 없습니다. Draft 2는 어휘의 일부를 개선·강화했지만 5월에 공개적으로 제기된 기록 보존 질문에 답하지 않았습니다.

AFRINIC의 광범위한 정책 매뉴얼은 집계를 IPv6 정책 목표로 다루고 다른 곳에 등록 의무를 담고 있습니다. 그 문맥은 기록 정확성과 라우팅 구조가 진실한 레지스트리 관심사였음을 확립합니다. Draft 2 자체가 등록 또는 집계 보호 장치를 만들었다고 간주하여 수정안에 수입될 수는 없습니다. 이후 Draft 3 문구나 이후 시행 이력을 8월 22일로 소급할 수도 없습니다. 여기서의 사건은Under Discussion으로 표시된 버전 2.0 제안의 게시입니다. 여기서 검토된 기록의 어떤 것도 Draft 2 합의, 비준, 시행, 강제 결정, 거부, 장애, 라우팅 효과 또는 측정된 비용을 증명하지 않습니다.

정확한 수정안은 따라서 규율 있는 결론을 낳습니다. Draft 2는 계약자 장치를 보이게 하고, 추상을 링크에서 보유자 관리 네트워크로 확장하며, 보호 영역을 두 문법 갈래로 분할하고, 수치 상한을 제거하고, 어색한 점대점 제한을 폐기했습니다. 또한 금지 측에 반영구적 연결성을 추가했습니다. 그것을 단순히 축소라 부르면 편집의 절반을 지웁니다. 자유화라 부르면 나머지 절반을 지웁니다. 그것은 부착된 사용을 다운스트림 서비스와 구분하려는 혼합된 시도였고, 그 구분을 정당하고 일관되게 관리 가능하게 만들 수 있는 사실 기반 트리거가 여전히 빠져 있었습니다.