요약

  • Tomohiro Fujisaki는 2008년, 멀티 프리픽스 환경에서 IPv6 주소 선택에 관한 문제 진술과 요구사항을 공동 저술했습니다. 호스트가 선택한 소스 주소는 네트워크의 다른 지점에서 라우팅과 필터링과 충돌할 수 있습니다.
  • 이후 공동 저술한 RFC 7078은 주소 선택 정책을 배포하기 위한 DHCPv6 옵션을 정의합니다. 이는 사이트 관리자가 정책을 노드에 전달하는 방법을 제공하면서, 로컬 설정과 구현 동작 및 보안은 운영상 제약으로 남겨둡니다.
  • APNIC의 Fujisaki 할당 제안 기록은 별개의 경계를 보여줍니다. IPv6 어그리게이션 기준에 대한 한 건의 변경은 시행되었지만, 배포 수요에 연동한 더 큰 할당을 요구하는 제안은 합의에 이르지 못했습니다.

패킷은 잘못된 회신 주소를 달고 나갈 수 있습니다

장치에 유효한 IPv6 주소가 있고 네트워크에 경로가 있어도 연결은 실패할 수 있습니다. 한 가지 이유는 호스트가 선택한 소스 주소와 주변 네트워크가 전달할 수 있는 경로 사이의 불일치입니다.RFC 5220은 인그레스 필터링이 패킷을 폐기할 수 있는 방식, 회신이 사용 가능한 돌아가는 경로를 갖지 못하는 방식, 트래픽이 예상치 못한 비대칭 경로를 따를 수 있는 방식을 설명합니다. 응용 프로그램은 실패를 표시하지만, 그 원인은 호스트의 주소 테이블과 사이트 네트워크가 결합하는 방식에 있을 수 있습니다.

이것은 특정 장애 사건에 대한 보고가 아닙니다. Arifumi Matsumoto, Tomohiro Fujisaki, R. Hiromi, K. Kanayama가 2008년 7월 Informational RFC로 발표한 문제 진술입니다. 이 구분은 중요합니다. 이 문서는 한 부류의 운영 상황을 확립하고, 그러한 상황에서 기본 주소 선택 규칙이 사용하기 어려울 수 있는 이유를 설명합니다. 이 문서는 그 실패가 얼마나 자주 발생했는지, 어느 공급자가 이를 경험했는지, 이후의 메커니즘이 프로덕션에서 이를 해결했는지 보여주지 않습니다. 그 증거는 구조적입니다. 로컬에서 이루어진 구성 선택이 네트워크가 패킷을 수용할지 여부를 결정할 수 있습니다.

"주소 선택"이라는 표현은 사소한 알고리즘적 세부사항처럼 들릴 수 있습니다. 운영자에게 이는 여러 개의 그 자체로는 유효한 요소들이 조합되지 못하는 지점에 놓일 수 있습니다. 호스트는 여러 주소를 가질 수 있고, 라우터는 다음 홉을 가질 수 있으며, 공급자는 소스 프리픽스에 따라 트래픽을 필터링할 수 있습니다. 각 구성 요소는 자신의 규칙에 따라 동작하고 있을 수 있습니다. 호스트가 네트워크 경로에 대응하지 않는 주소를 선택하면, 이러한 로컬 규칙들이 결합하여 연결이 끊길 수 있습니다. 운영자는 응용 프로그램만, 라우터만, 또는 주소 계획만 보고 그 상황을 해결할 수 없습니다.

RFC 5220은 불일치가 발생할 수 있는 여러 방식을 목록화했습니다. 단일 호스트 인터페이스를 통해 연결된 여러 라우터, 인그레스 필터링, 한 방향으로는 도달 가능하지만 반대 방향으로는 불가능한 네트워크, unique-local 주소와 전역 라우팅 가능 주소의 결합 사용, 재번호화, 멀티캐스트 소스, 임시 주소, IPv4와 IPv6 목적지 사이의 상대적 선택을 고려했습니다. 이러한 사례들이 관련되어 있는 이유는, 호스트가 여러 그럴듯한 주소를 보유할 수 있고, 기본 정렬이 어떤 주소를 사용 가능하게 만들고 다른 주소를 열악한 선택으로 만드는 관리적 또는 라우팅 맥락을 반영하지 못할 수 있기 때문입니다.

이 문서는 또한 문제 주위에 경계를 설정했습니다. 그 초점은 최종 사이트 네트워크와 비관리 호스트였습니다. 멀티호밍을 통한 이중화는 일반적으로 범위 밖으로 간주했습니다. 이 결정은 주소 동작을 하나씩 조정하기 어려운 호스트에 분석을 집중시켰습니다. 사용자는 사이트의 라우팅을 이해하지 못할 수 있고, 장치는 수동 구성이 어려운 위치에 있을 수 있으며, 관리자가 개별적으로 조정하기에는 장치가 너무 많을 수 있습니다. 과제는 단순히 더 나은 순위 규칙을 만드는 것이 아니었습니다. 라우터처럼 관리되지 않는 호스트에게 그 규칙을 관리 가능하게 만드는 것이었습니다.

이러한 프레임은 배포 질문을 가시화했습니다. 주소 정책 테이블은 수동으로 변경할 수 있었지만, 문제 진술은 수동 구성이 대규모 또는 비관리 집단에 대한 실현 가능한 일반적 해결책이 아니라고 말했습니다. 기본값은 유용하기에 충분할 만큼 자주 작동해야 하지만, 어떤 기본값도 모든 사이트에 맞을 것이라고 기대할 수는 없었습니다. 사이트는 여러 공급자, 로컬 전용 프리픽스, 전환 메커니즘 또는 서비스별 제약 조건을 가질 수 있습니다. 운영상의 질문은, 각 사용자에게 토폴로지를 이해하도록 요구하지 않고 호스트가 어떻게 맥락을 수신할 수 있는지였습니다.

전달 메커니즘 이전에 요구사항이 먼저

같은 달에 같은 네 명의 저자가 발표한RFC 5221은 문제를 해결한다고 주장하지 않았습니다. 이는 RFC 5220의 사례를 미래의 주소 선택 메커니즘이 충족해야 하는 요구사항으로 변환했습니다. 또한 Standards Track 프로토콜이 아닌 Informational입니다. 이 상태는 독자가 어떤 종류의 기록을 참조하고 있는지 알려줍니다. 필요 사항의 진술이며, 모든 구현 또는 네트워크가 이미 이를 충족한다는 약속이 아닙니다.

그 요구사항은 "관리자가 기본 설정을 지정하게 하라"가 충분하지 않았음을 보여줍니다. 유용한 메커니즘은 기본값이 실패하는 곳에서 호스트 동작을 변경하고, 호스트가 선택을 하기 전에 정보를 제공하고, 네트워크가 변경될 때 업데이트를 허용해야 했습니다. 노드별 및 응용 프로그램별 동작, 다중 인터페이스, 중앙 관리, 다음 홉 선택, 기존 선택 알고리즘과의 상호 운용성, 보안을 고려해야 했습니다. 타이밍과 사용성도 중요했습니다. 정책은 기술적으로 표현력이 있으면서도, 일반 사용자가 상세한 테이블을 유지하도록 강제하거나 연결 시작마다 눈에 띄는 지연을 부과한다면 운영상의 해결책으로서 실패할 수 있었습니다.

이러한 요구사항은 간과하기 쉬운 권한 경계를 드러냅니다. 네트워크 운영자는 경로, 접근 제약 및 사이트 정책을 이해합니다. 호스트는 패킷이 전송되는 순간 선택을 수행하는 주소, 인터페이스 및 응용 프로그램을 가집니다. 사용자 또는 장치 관리자는 네트워크가 통제하지 않는 로컬 설정을 가질 수 있습니다. 메커니즘은 한 주체가 다른 모든 주체의 장비를 구성할 수 있다고 가정하지 않으면서 이러한 경계를 넘어 유용한 정보를 전달해야 합니다.

저자들은 또한 보안을 사후에 떨어진 경고로 추가하는 것이 아니라 요구사항의 일부로 만들었습니다. 주소 선택 정보는 호스트가 선호하는 경로와 사용하는 소스 주소를 변경할 수 있습니다. 따라서 그러한 정보를 배포하는 메커니즘은 조작, 공개 및 충돌하는 구성의 결과를 고려해야 합니다. 2008년 메모는 이후의 DHCPv6 옵션을 규정하지 않았습니다. 가능한 해결책을 평가할 수 있는 기준을 설정했습니다.

문제 진술, 요구사항, 프로토콜 간의 구분은 Fujisaki의 작업에 대한 설명에 중요합니다. RFC 5220은 운영 사례를 명명합니다. RFC 5221은 메커니즘이 수행해야 할 내용을 규정합니다. 2014년에 발표된 RFC 7078은 정책을 공급하는 한 가지 수단을 정의합니다. 이들은 협업 문서이며, 이 순서는 어떤 한 명의 공동 저자가 전체 설계를 통제했거나 모든 요구사항이 선택된 메커니즘에 의해 충족되었다는 것을 증명하지 않습니다. 그것은 독자가 프로토콜 문제가 어떻게 설계 의무의 집합이 되고 그 다음 특정 옵션이 되었는지 따라갈 수 있게 해줍니다.

정책이 DHCPv6 교환에 들어옵니다

RFC 7078, "Distributing Address Selection Policy Using DHCPv6"는 Arifumi Matsumoto, Tomohiro Fujisaki, Tim Chown가 저술했습니다. 이전 두 메모와 달리 Standards Track 문서입니다. 사이트 관리자가 정책 테이블과 관련 매개변수를 노드에 배포할 수 있도록 DHCPv6 서버가 제공할 수 있는 주소 선택 옵션을 정의합니다. 이 옵션은RFC 6724에서 설명한 기본 주소 선택 매개변수와 테이블을 재정의할 수 있습니다.

이 메커니즘은 호스트의 선택 로직을 원격 명령으로 대체하지 않습니다. 노드가 처리하는 정책 정보를 공급합니다. RFC 7078은 이 옵션을 노드가 어떻게 동작해야 하는지에 대한 힌트라고 부르고, 노드의 관리자가 수신된 정책이 처리되는 방식을 제어할 수 있다고 말합니다. 그 다음, 문제 해결을 단순화하고 운영 비용을 줄이기 위해 균일한 처리 방법을 권장합니다. 이 텍스트는 두 가지 생각을 함께 유지합니다. 사이트는 중앙에서 기본 설정을 표현할 수 있지만, 호스트는 구현 및 구성 경계로 남아 있습니다.

그 경계는 필드에서 볼 수 있습니다. 이 옵션은 행으로 구성된 정책 테이블을 전달합니다. 각 행은 주소 선택 알고리즘에서 사용되는 레이블과 우선순위 값을 프리픽스와 연결합니다. 또한 이 옵션은 자동 행 추가 및 개인정보 기본 설정과 관련된 플래그를 정의합니다. 이들은 일반적인 "IPv6 켜기" 또는 "IPv6 끄기" 제어가 아닙니다. 구현이 유지해야 하는 특정 선택 프로세스에 대한 입력이며, 그 범위와 의미를 가집니다.

관리자에게 이는 모든 장치의 테이블을 편집하는 작업을 장치가 이미 사용하는 서비스를 통해 공통 정책을 배포하는 것으로 전환시킵니다. 이익은 가독성과 반복 가능성입니다. 사이트는 정책을 한 번 정의하고 클라이언트가 DHCPv6를 통해 수신하도록 할 수 있습니다. 그러나 이 표준은 여전히 모든 클라이언트가 옵션을 지원하도록 만들 수 없고, 메시지가 모든 인터페이스에 도달한다는 것을 보장할 수 없으며, 선택된 소스가 실제 전달 및 필터링 구성과 일치한다는 것을 보장할 수 없습니다. 배포는 제어 경로이지, 데이터 플레인 동작 성공의 증명이 아닙니다.

텍스트는 또한 정책 테이블이 의미론적으로 섬세하다는 것을 인식합니다. 행을 추가하거나 제거하면 테이블 전체의 의미가 변경될 수 있습니다. 관리자는 자동 행을 추가할지 여부, 임시 주소를 선호할지 여부, 그리고 로컬 설정이 배포된 정보와 어떻게 상호작용하는지 결정해야 할 수 있습니다. 하나 더의 구성 필드처럼 보이는 값이 많은 흐름에 대한 주소 정렬을 변경할 수 있습니다. 운영 부담은 이동합니다. 더 적은 장치만 수동 편집이 필요할 수 있지만, 사이트 전체 정책을 소유하는 사람은 테이블, 클라이언트 동작 및 네트워크 경로가 어떻게 상호작용하는지 이해해야 합니다.

RFC 7078의 정책 부재에 대한 자체 설명 역시 중요합니다. 배포된 선택 정책을 수신하지 않는 네트워크 인터페이스가 그 관리자가 이 문제를 무시했다는 것을 반드시 나타내는 것은 아닙니다. 기본 정책이 의도되었을 수 있습니다. 이 경우 호스트는 기본 주소 선택 정책을 사용해야 합니다. 이는 빈 옵션이 보편적인 실패로 취급되는 것을 방지합니다. 부재는 선택일 수 있지만, 배포 및 호스트의 다른 구성 맥락에서만 해석 가능합니다.

옵션의 범위는 다중 인터페이스 노드에서도 중요합니다. 주소 선택 동작은 중요한 측면에서 노드 전역적입니다. 이는 아웃바운드 인터페이스가 목적지 주소 이후에 선택될 수 있기 때문입니다. RFC는 인터페이스별로 다른 주소 선택 정책을 단순히 저장하는 것이 모든 사례를 해결하지 못하는 이유를 설명합니다. 주소 결정은 인터페이스 결정보다 먼저 이루어지거나 그와 상호작용할 수 있습니다. 사이트는 각 인터페이스가 격리된 정책 도메인으로 동작한다고 가정하지 않고, 어떤 정보가 노드 전체에 적용되는지 추론해야 합니다.

이 명세는 주소 선택 테이블을 경로로 만들지 않습니다. 프리픽스를 광고하거나, 경로를 설치하거나, 인그레스 필터를 구성하거나, 다음 홉을 확보하거나, 네트워크의 응답을 검증하지 않습니다. 소스 주소 정책을 배포한 운영자는 여전히 라우팅과 필터링 상태가 해당 정책이 암시하는 경로를 지원하는지 확인해야 합니다. 호스트가 잘 구성된 테이블을 전달받아도, 주변 네트워크가 결과 패킷을 전달할 수 없다면 통신에 실패할 수 있습니다.

정책을 회선에 올리는 데 따르는 보안 비용

DHCPv6 메시지가 주소 선택 정책을 전달할 수 있게 되면, 그 메시지의 신뢰성이 운영 문제의 일부가 됩니다. RFC 7078은 로그 DHCPv6 서버가 가짜 정책을 보낼 수 있다고 경고합니다. 이를 수락하는 클라이언트는 상류에서 필터링되는 주소를 선택하거나, 추가 네트워크 요금을 초래하거나, 트래픽을 공격자에게 보낼 수 있습니다. RFC는 IPsec, Secure Neighbor Discovery 및 DHCP 인증과 같은 신뢰할 수 있는 채널을 명명하고, L2 DHCP 스누핑을 일반적으로 사용되는 완화책으로 언급합니다.

이 경고는 중앙 배포가 항상 로컬 구성보다 안전하다는 단순한 이야기를 복잡하게 만듭니다. 중앙 배포는 일관성 없는 수동 설정을 줄일 수 있지만, 악의적이거나 잘못 구성된 서버를 많은 클라이언트의 정책 소스로 만들 수도 있습니다. 운영상의 질문은 단순히 옵션이 존재하는지가 아닙니다. 어느 서버가 이를 보낼 수 있고, 어느 클라이언트가 이를 수락하며, 관리자가 변경을 어떻게 검토하는지, 그리고 네트워크가 트래픽을 사용 불가능하거나 안전하지 않은 경로로 보내는 정책을 감지할 방법이 있는지입니다.

RFC에 설명된 위협은 구체적입니다. 그것은 주소 선택 정책과 가짜 옵션의 가능한 경로 또는 소스 결과에 관한 것입니다. 이는 DHCPv6 정책이 본질적으로 안전하지 않다거나, 실제 공격이 발생했다거나, 메모에 명명된 완화책이 보편적으로 배포되어 있다는 주장으로 확대되어서는 안 됩니다. 이 소스는 위협 모델과 완화책을 제공합니다. 측정된 인시던트 발생률이나 클라이언트 네트워크의 운영 감사를 제공하지 않습니다.

서버 신뢰 이상의 실질적인 제약이 있습니다. RFC 7078은 많은 규칙을 가진 테이블이 DHCPv6 메시지를 크게 만들 수 있다고 관찰하고, 관리자에게 결과 메시지를 전달하는 로컬 인프라의 능력을 고려하라고 경고합니다. 수천 개의 규칙을 인코딩할 수 있는 이론적 옵션은 모든 클라이언트, 서버 및 릴레이가 안정적으로 전송할 수 있는 메시지와 동일하지 않습니다. 조각화 지원을 가정할 수 없습니다. 관리자는 정책을 실제 사용 중인 경로와 장비에 충분히 컴팩트하게 유지해야 합니다.

그러므로 이 표준은 하나 이상의 성공 조건을 가집니다. 서버는 의도된 정책을 배포해야 합니다. 클라이언트는 이를 이해하고 처리해야 합니다. 로컬 구성은 예상치 못한 충돌을 만들지 말아야 합니다. 메시지는 네트워크를 살아남아야 합니다. 그리고 결과적으로 선택된 주소는 패킷이 취할 경로에 적합해야 합니다. 관측 계획은 각 단계를 구분해야 합니다. 옵션이 전송되었다는 것만을 보고하는 대시보드는 클라이언트가 그것을 적용했거나 트래픽이 성공했다는 것을 입증할 수 없습니다.

같은 배포 질문이 레지스트리 경계에도 나타납니다

Fujisaki의 공개 기록에는 IPv6 할당에 관한 정책 작업도 포함됩니다. 메커니즘은 DHCPv6와 다르지만, 체인의 다른 지점에서 관련된 배포 질문을 제기합니다. 호스트 수준의 테이블은 노드가 보유한 것 중에서 어떤 주소를 선택할지에 영향을 미칩니다. 할당 정책은 조직이 어떤 주소 공간을 받을 수 있고 네트워크에 사용할 수 있는 프리픽스를 어떻게 구조화할 수 있는지에 영향을 미칩니다. 이들은 동일한 결정이 아니며 하나의 기술적 주장으로 축소되어서는 안 됩니다. 그러나 이들은 IPv6를 운영할 수 있는 서로 다른 조건을 형성합니다.

APNIC의 제안 아카이브는 Fujisaki와 공동 저자가 관련된 IPv6 정책 제안의 순서를 기록합니다. 초기 제안 중 하나인prop-076은 Local Internet Registry에 후속 IPv6 할당을 어그리게이트하도록 요구할 것이었습니다. 저자들은 논의 후 이를 철회하고 초기 할당에서 어그리게이션 기준을 제거하는prop-082를 제출했습니다. 후자의 제안은 APNIC 29에서 합의에 도달했고, 최종 의견 수렴 기간과 Executive Council의 승인을 통과했으며, APNIC은 2010년 7월 5일에 시행된 것으로 기록합니다.

이 역사는 커뮤니티 토론 이후 정책 설계가 어떻게 변경되었는지 보여주기 때문에 유용합니다. prop-076과 prop-082는 제목만 다른 동일한 초안이 아니었습니다. 전자는 후속 할당에 대한 어그리게이션에 관한 것이었고, 후자는 초기 할당 정책에서 어그리게이션 기준을 제거했습니다. APNIC의 기록은 prop-082가 이전 토론의 피드백을 반영했다고 말합니다. 성공적인 결과는 Fujisaki 개인이 아닌 정책 프로세스와 그 공동 저자에게 속합니다. 이 기록은 이후에 할당을 받은 모든 네트워크에 대한 운영 효과를 확립하지 않습니다.

다음 해에 Fujisaki는prop-087, "IPv6 address allocation for deployment purposes"를 제출했습니다. 그 제안 텍스트는 RFC에서 설명한 배포 프로토콜을 사용하는 조직이 초기 배포 단계 동안 /32보다 큰 초기 IPv6 할당을 정당화할 수 있다고 주장했습니다. APNIC의 역사는 그 제안이 APNIC 30에서 발표되었고 합의에 도달하지 못했으며, 추가 논의를 위해 반납되었고 저자가 2011년 8월에 철회했다고 기록합니다. 그 결과는 텍스트만큼 구체적입니다. APNIC은 이 제안을 시행하지 않았습니다.

이 주제가 중요한 이유는 프로토콜 배포와 레지스트리 할당이 다른 규모에서 작동하기 때문입니다. 네트워크는 많은 서브넷을 사용하거나 고객 사이트에 구조화된 블록을 위임하는 배포 방법을 설계할 수 있습니다. 반대로 레지스트리의 할당 기준은 조직이 처음에 얼마나 많은 주소 공간을 받을 수 있는지, 그리고 더 많은 공간을 받기 위해 무엇을 입증해야 하는지를 결정합니다. 정책 제안은 기존 기준이 특정 기술 설계에 맞지 않는다고 주장할 수 있습니다. 그 설계가 RFC에 문서화되어 있다는 사실만으로 할당 규칙이 변경되어야 하는지 결정되지 않습니다. 그 결정은 여전히 RIR의 정책 프로세스를 통과합니다.

제안의 철회는 독자에게 Fujisaki가 왜 철회하기로 했는지를 알려주지 않습니다. APNIC의 역사는 저자의 개인적 추론이 아니라 절차적 결과를 기록합니다. 철회를 운영 문제가 해결되었다는 증거나 제안이 영구히 거부되었다는 증거로 설명하는 것은 옳지 않습니다. 이 제안의 이 버전이 채택되지 않았고 합의에 도달하지 못한 후 철회되었다는 것을 말할 뿐입니다. 정책을 제안하는 사람에 대한 프로필은 식별된 문제, 제안된 해결책, 그리고 실제로 시행되는 규칙 사이의 차이를 유지해야 합니다.

이후 APNIC 기록은 할당 크기 문제가 더 좁거나 다른 형태로 돌아왔음을 보여줍니다. 2014년에prop-111은 조직이 /29까지의 초기 할당을 요청할 수 있도록 제안했습니다. APNIC의 페이지는 4개의 제안 버전, APNIC 37에서의 합의 부재, 추가 논의, 그리고 APNIC 38에서의 다시 한 번 합의 부재를 기록하며, 이후 폐기되었습니다. 2015년에prop-112는 레거시 IPv6 보유자가 통상적인 사용률 기준이나 추가 문서 없이 주소 공간을 /29까지 확장할 수 있는 경로를 제안했습니다. APNIC은 APNIC 39에서 합의에 도달하지 못했고 폐기되었다고 기록합니다.

이러한 이후의 결과는 제안이 기술적으로 근거 없었다거나, 정책 프로세스가 불공정했다거나, 모든 참가자가 같은 이유로 아이디어에 반대했다는 것을 확립하지 않습니다. 그들은 APNIC이 기록한 합의 조건을 제안들이 충족하지 못했다는 것을 확립할 뿐입니다. prop-082와 함께 읽으면 혼합된 기록을 보여줍니다. 초기 할당 기준의 한 가지 조정은 시행되었지만, 할당 크기를 변경하라는 여러 후속 요청은 그렇지 않았습니다. 이는 모든 정책 작업을 승리 또는 실패로 묘사하는 것보다 더 유익한 설명입니다.

이 할당 제안들과 호스트 선택 RFC들 사이의 관계는 편집적 해석이며, Fujisaki에 대한 귀속이 아닙니다. 한쪽 끝에서 네트워크는 조직이 얼마나 많은 주소 공간을 보유할 수 있고 그 공간을 어떻게 할당할 수 있는지 협상합니다. 다른 끝에서 장치는 기본값과 정책에 따라 사용 가능한 주소 중에서 선택합니다. 레지스트리 결정은 호스트에게 어떤 소스를 사용할지 말할 수 없습니다. DHCPv6 옵션은 운영자가 보유하지 않은 프리픽스 공간을 만들 수 없습니다. 두 끝을 함께 보면 "IPv6 배포"가 하나의 기관에 의해 내려지는 하나의 결정이 아니라는 이유를 설명하는 데 도움이 됩니다.

협업 문서를 통해 만들어진 경력 기록

공개 기록은 Fujisaki의 작업에 대한 경계 있는 설명을 지지합니다. APNIC의2017 NRO Number Council 추천 페이지는 그를 NTT의 선임 연구 엔지니어이자 감독자로 설명하고, 1997년 이후 NTT Laboratories에서 IPv6 연구를 수행했다고 말하며, 일본의 IPv6 배포 및 주소 정책 조정에서의 역할을 나열합니다. 이 페이지는 2005년부터 2012년까지 Japan Open Policy Forum의 의장직과 2013년부터 시작된 IP 정책을 담당하는 JPNIC Board 역할을 기록합니다. 이 정보는 추천서에 나타나기 때문에, 그의 결과에 대한 독립적인 평가가 아닌 APNIC이 기록한 역할 이력으로 제시하는 것이 가장 적절합니다.

APNIC의Executive Council 회의록은 또 다른 기관 세부 사항을 더 확고한 근거 위에 놓습니다. 이사회는 만장일치로 Fujisaki를 2011년 NRO Number Council에 임명했고 2010년의 그의 봉사를 인정했습니다. 이것은 공식 임명 기록입니다. 그것은 그가 모든 정책에 어떻게 투표했는지 또는 별개의 RIR 커뮤니티에 대해 어떤 권한을 가졌는지를 확립하지 않습니다. 기술 또는 정책 기구의 회원 자격은 그 기구가 권한을 부여받은 결정들을 읽는 것을 대체하지 않습니다.

RFC들도 단일 개인 이야기에 저항합니다. RFC 5220과 RFC 5221은 4명의 저자를 나열합니다. RFC 7078은 3명을 나열합니다. APNIC의 제안 페이지는 Fujisaki를 prop-087과 prop-111/112의 저자로 식별하는 반면, prop-076/082는 그를 공동 저자 중 한 명으로 나열합니다. 귀속의 차이는 중요합니다. 표준 작업은 협업적이었고, 정책 제안은 한 명의 저자를 명명했을 수 있으며, 구현 또는 커뮤니티 채택은 다른 주체들을 포함했습니다. 이 문서들은 혼자 행동하는 사람이 아니라 여러 환경에 걸쳐 참여한 사람을 보여줍니다.

그 구분은 영향에 대해 합리적으로 말할 수 있는 내용을 변경합니다. 발표된 RFC는 안정적이고 검토 가능한 명세를 제공합니다. Standards Track RFC는 Internet Standard로서의 발표를 위한 IETF 프로세스를 통과했지만, RFC 자체는 얼마나 많은 시스템이 이를 구현하는지 측정하지 않습니다. Informational 메모는 강제적인 동작을 만들지 않으면서 문제와 요구사항을 설명할 수 있습니다. APNIC 제안은 시행되거나, 철회되거나, 폐기될 수 있지만, 상태 레이블은 이후 운영자가 정책을 얼마나 사용했는지를 드러내지 않습니다. 각 기록에는 고유한 증거 범위가 있습니다.

이 작업은 지름길을 거부하는 지점에서 가장 흥미롭습니다. 2008년 문서들은 새로운 알고리즘만으로 주소 선택이 라우팅과 조화될 수 있다고 주장하지 않았습니다. 그들은 사례와 요구사항을 열거했습니다. 2014년 RFC는 배포 메커니즘을 명세하면서 로컬 구성을 유지하고 공격 경로를 논의했습니다. APNIC 제안들은 할당 기준에 대한 주장을 제기했고, 그 다음 그들의 기록된 결과는 갈라졌습니다. 종합하면, 이 기록은 호스트의 정책 테이블에서 레지스트리의 할당 규칙까지 결정을 추적하며, 표준과 정책 커뮤니티가 문제의 서로 다른 부분을 결정합니다.

이것을 문제에서 해결책으로의 승리적 전환으로 제시할 필요는 없습니다. 소스는 주소 선택 실패가 사라졌다는 것을 보여주지 않습니다. RFC 7078에 대한 배포 수를 제공하지 않고, prop-082가 운영자 네트워크에 미친 효과를 측정하지 않습니다. 그 이야기는 이러한 부재를 가시적으로 남길 때 더 유용합니다. 독자는 어떤 메커니즘이 정의되었고, 어떤 제안이 채택되었으며, 어떤 질문이 증거 밖에 남아 있는지 볼 수 있습니다.

정책과 작동하는 경로 사이의 경계

공급자에게, 전송된 정책과 패킷을 전달하는 경로 사이의 구분은 실질적입니다. 테이블은 노드에게 한 프리픽스가 다른 프리픽스보다 우선해야 한다고 말할 수 있습니다. 그것은 상류가 그 프리픽스의 트래픽을 수용한다는 것을 보장할 수 없습니다. 할당은 고객 주소 계획을 위한 공간을 제공할 수 있습니다. 그것은 장치가 네트워크가 라우팅할 수 있는 주소를 선택한다는 것을 보장할 수 없습니다. 표준 문서는 구현에게 공통 형식을 제공할 수 있습니다. 그것은 모든 클라이언트가 기능을 갖추고 있거나 모든 관리자가 안전하게 배포했다는 것을 인증할 수 없습니다.

여기서 실행 중인 시스템 관점이 유용합니다. 평가는 실제 경로를 통해 패킷을 따라가야 합니다. 어떤 주소가 구성되어 있는지, 노드가 어떤 정책을 수신했는지, 어떤 로컬 규칙이 이를 재정의했는지, 어떤 소스 주소가 선택되었는지, 어떤 인터페이스와 다음 홉이 이를 전달했는지, 상류가 이를 수용했는지. 같은 규율이 할당에도 적용됩니다. 어떤 프리픽스가 할당되었는지, 어떤 로컬 계획이 그것으로부터 구축되었는지, 어떤 경로가 시작되었는지, 어떤 트래픽이 실제로 경로를 사용했는지. RFC와 정책 기록은 이 체인의 부분을 정의합니다. 그 어느 것도 완전한 운영 추적이 아닙니다.

따라서 측정 경계는 명시적이어야 합니다. RFC 저술은 명세 참여의 증거입니다. RFC의 상태는 발표 범주의 증거입니다. APNIC의 역사는 각 제안에 대해 기록된 결정의 증거입니다. 공개 역할 페이지는 그것이 기록하는 역할의 증거입니다. 그 어느 기록도 트래픽 측정, 구현 인구 조사, 고객 설문 또는 전후 성능 연구가 아닙니다. 사실에 기반한 프로필은 기관 활동을 배포 통계로 만들어서는 안 됩니다.

그 절제는 기술적 증거를 권한으로부터 구분하는 데도 도움이 됩니다. DHCPv6로 전달된 정책 테이블은 표준의 처리 규칙에 따라 호스트가 수락할 수 있지만, 호스트 관리자의 로컬 설정은 여전히 관련이 있습니다. 제안은 APNIC의 프로세스에서 합의를 받고 구현 경로에 들어갈 수 있지만, 그 결과는 그 포럼 내의 정책 메커니즘에 적용됩니다. 그것이 모든 네트워크에 대한 일반적 권한을 그 방에 부여하는 것은 아닙니다. 반대로, 로컬 호스트 제어의 존재가 레지스트리 할당 기준을 무관하게 만들지는 않습니다. 메커니즘은 서로 다른 레이어에서 작동하며 서로 다른 주체를 구속합니다.

그 결과 이 증거는 사생활에 대한 전기가 아니라 Fujisaki에 대한 신중한 프로필을 제공합니다. 그것은 기술적 실패 부류, 설계 요구사항의 집합, 정책 배포의 표준화된 수단, 그리고 배포를 지원하는 할당 규칙에 관한 여러 제안을 기록한 문서를 통해 연구원이자 정책 참가자를 따라갑니다. 가장 구체적인 결과는 혼합되어 있습니다. prop-082는 시행되었고, prop-087은 합의에 실패한 후 철회되었으며, prop 111과 112는 유사한 기록된 결과 후 폐기되었습니다. RFC 7078은 표준화된 배포 옵션을 제공하면서 여러 운영 질문을 관리자와 구현에 남겨둡니다.

그 혼합이 핵심입니다. 호스트가 선택하는 주소는 그 프리픽스를 할당한 레지스트리만으로 결정되지 않으며, 할당 정책은 호스트의 패킷 수준 결정을 통제하지 않습니다. Fujisaki의 기록은 IPv6 운영이 두 규모에서 모두 지원되어야 하기 때문에 양쪽에 걸쳐 있습니다. 이 문서들은 어느 한 규모가 다른 규모를 명령할 수 있다고 주장하지 않으면서 그 연결을 가시화합니다.

기록이 해결하지 않는 것

RFC들은 멀티 프리픽스 실패가 얼마나 흔했는지, 얼마나 많은 클라이언트 운영체제가 RFC 7078을 구현했는지, 운영자가 그 옵션에 얼마나 자주 의존했는지 알려주지 않습니다. APNIC의 제안 이력은 회의록이나 제안 텍스트가 명시하지 않는 한, 개별 참가자가 각 변경을 왜 지지하거나 반대했는지 보여주지 않습니다. 추천 페이지는 Fujisaki의 역할에 대한 독립적인 성과 측정을 제공하지 않습니다. 이러한 한계는 문서화된 작업을 지우지 않습니다. 그것은 기사가 어디서 멈춰야 하는지를 정의합니다.

가장 명확한 발견은 IPv6 성공에 관한 일반화된 주장보다 더 좁고 더 강력합니다. Fujisaki는 주소 선택 문제 진술에서 요구사항을 거쳐 DHCPv6 정책 배포 표준에 이르는 진행에 명명된 공동 저자였습니다. 그는 또한 한 건의 어그리게이션 변경이 시행에 도달했고 이후 할당 크기 제안들이 합의에 실패했음을 보여주는 APNIC 정책 기록에 나타납니다. 각 결과는 공식 기록에서 직접 읽을 수 있습니다. 그들 사이의 연결은 배포 제약을 이해하는 방법이지, 하나의 정책이 측정된 네트워크 결과를 일으켰다는 증거가 아닙니다.

운영자에게 이는 판결 대신 구체적인 질문을 남깁니다. 클라이언트 장치가 의도된 정책을 수신합니까? 관리자가 기본값과 누락된 옵션을 구별할 수 있습니까? 테이블이 현재 라우팅 및 인그레스 필터링과 일치합니까? DHCPv6 서비스가 신뢰되고 모니터링됩니까? 릴레이와 클라이언트가 옵션을 안정적으로 전송할 수 있습니까? 자원 정책 레이어에서, 공급자가 실제 주소 계획에 맞는 블록을 정당화할 수 있고, 기준이 일관되게 적용될 만큼 충분히 명확합니까? 표준과 할당 이력은 운영자에게 어디를 봐야 하는지 말해줍니다. 시스템이 어떻게 동작하는지는 그들 자신의 네트워크 증거가 답해야 합니다.

따라서 Fujisaki의 기여는 명세뿐 아니라 한계를 통해서도 읽는 것이 가장 좋습니다. 호스트는 레지스트리가 프로그램할 수 있는 빈 엔드포인트가 아니었습니다. 레지스트리는 호스트 선택 엔진이 아니었습니다. 각 레이어는 서로 다른 제어 표면, 서로 다른 프로세스, 서로 다른 성공의 시험을 가졌습니다. 공개 기록은 표준화에서 시행, 철회, 폐기에 이르는 결과 범위를 가지고 그 경계를 넘어 작업한 참가자를 보여줍니다.