요약

  • RFC 1924는 IPv6 주소의 128비트 전체를 하나의 정수로 나타내고 이를 85진법 20자로 인코딩했습니다. 가역성은 값을 보존했지만 식별성, 색인화, 도구 호환성은 확보하지 못했습니다.
  • 9개의 인쇄 가능 문자는 인용부호, 목록, 문장, CIDR, URL, 괄호, 이스케이프에 쓸 수 있도록 의도적으로 알파벳에서 제외되었습니다. 외부 문법은 과제의 일부였습니다.
  • 이후 문서들은 콜론과 16진수 그룹을 유지하고, URI에 대괄호를 도입했으며, 정규화된 출력을 권고했습니다. 표기의 일치는 검증을 쉽게 하지만 할당, 경로, 도달성, 신원, 전달을 증명하지는 않습니다.

같은 비트, 다른 흔적

운영자가 요청서에서 주소를 받아 로그 검색에 넣습니다. 응답은 비어 있습니다. 기록은 존재하지만 시스템이 같은 128비트를 Base85로 출력한 것입니다. 디코더는 동일성을 확인할 수 있지만 일반 텍스트 색인은 표면을 비교합니다. 정확한 직렬화가 공통의 증거가 되지 못했습니다.

RFC 1924는 1996년 4월 1일 Informational 범주로 발표되었으며 인터넷 표준을 확립하지 않았습니다. 주소를 하나의 부호 없는 정수로 간주하고 85개의 인쇄 가능 ASCII 문자로 된 알파벳으로 기록하자는 제안이었습니다. 예시에서1080:0:0:0:8:800:200C:417A는4)+k&C#VzJ4br>0wv%Yp로 바뀌었습니다. 결과는 항상 20자리를 차지하고 선행 0을 보존했습니다.

변환에 손실은 없습니다. 그러나 가역성은 올바른 프로그램이 수를 복원한다는 것만을 약속합니다. 사람이 문자열을 인식하는지, URI 파서가 분리하는지, 표가 변형을 정리하는지, 로그가 보존하는지, 모든 중간 노드에 디코더가 존재하는지는 규정하지 않습니다.

85진법은 최소 임계값이었다

IPv6 공간에는 (2^{128})개의 값이 있습니다. 84진법의 20자리는 부족하지만 85진법은 충분합니다: (84^{20} < 2^{128} \leq 85^{20}). 94와 95진법조차 여전히 20자리가 필요합니다. 따라서 길이를 늘리지 않고 9개의 인쇄 가능 문자를 외부 문법 환경에 남겨둘 수 있었습니다.

고정 폭은 유용합니다. 필드 크기를 미리 알 수 있고, 선행 0이 사라지지 않으며, 0 그룹 압축 변형이 없습니다. 필드 경계가 이미 정해져 있고 모든 측이 형식을 디코딩할 수 있다면 표기는 컴팩트하고 명확합니다.

그러나 예외 목록은 주소가 고립되는 일이 얼마나 드문지 보여줍니다. 알파벳에서 양쪽 인용부호, 쉼표, 마침표, 슬래시, 콜론, 대괄호 두 개, 역슬래시가 제거되었습니다. 인용, 나열, 문장 끝, CIDR 접미사, URL, 리터럴 경계, 이스케이프에 필요한 문자들입니다. 내부의 밀도는 외부 언어가 경계를 잃지 않는 능력에 의존했습니다.

인식 가능한 형태는 정규형이 아니었다

초기 IPv6 아키텍처는 콜론으로 구분된 여덟 개의 16비트 16진수 그룹을 정의했습니다. 선행 0을 생략하고, 0 그룹 연속을::로 한 번 압축하며, IPv4의 10진수 꼬리를 사용할 수 있었습니다. 콜론과 그룹이 인식 가능한 실루엣을 유지하는 동안 하나의 주소에 여러 유효한 표기가 생겼습니다.

이 유연성은 기계 비교를 해쳤습니다. 한 형태의 검색이 다른 형태를 놓치고, 표는 중복을 만들며, Whois, 스키마, 로그가 서로 모순되어 보였습니다. Base85는 전체 표면을 바꿈으로써 변형을 제거했습니다. 이후의 표준 경로는 표면을 유지하고 출력 변형을 제한했습니다.

URL과의 충돌은 지역적으로 해결되었습니다. IPv6의 콜론이 외부 문법과 겹쳐서 RFC 2732는 리터럴을 대괄호로 감쌌습니다. 그 문서는 최소한의 편집으로 편리하게 복사한다는 목표를 명시하고, Internet Explorer, Mozilla, Lynx의 IPv6 버전 구현을 언급했습니다. 이어서 RFC 3986은 대괄호IP-literal을 유지했습니다.

넓은 수용, 좁은 출력

RFC 4291은 유연한 16진수 형태를 남겨두었습니다. 이후 RFC 5952는 검색, 텍스트 파일, 표, Whois, 다이어그램, 로그, 감사, 검증에서 수많은 합법적 표기의 문제를 나열했습니다. 해결책은 책임을 나누었습니다. 파서는 RFC 4291의 모든 유효 형태를 받아들이고, 포매터는 정규형을 출력합니다.

출력에서는 선행 0이 제거되고, 소문자 16진수가 사용되며,::는 가장 긴 0 연속을 압축하고, 동률일 때는 첫 번째를 선택하며, 단일 0 그룹은 압축하지 않습니다. 이는 항상 생각할 수 있는 가장 짧은 문자열은 아닙니다. 대신 두 개의 독립 장치가 같은 보이는 흔적을 남길 가능성이 높아집니다.

이렇게 하면 구식 입력과의 호환성이 유지되고 새 기록의 비교 가능성이 향상됩니다. 대괄호는 URI의 외부 경계를, 정규화는 내부 형태를 담당합니다. 어느 조치도 다른 쪽의 과제를 대신 해결하지 않습니다.

증거의 여섯 단계

먼저 128비트가 있고, 그다음 인식된 값, 정규화된 표시, 실제로 보존된 문자열, 검색 결과, 관찰 가능한 네트워크 이벤트가 옵니다. 한 단계에서의 동일성이 다음 단계의 권한을 주지는 못합니다. 하나의 수로 디코딩되는 두 문자열은 표현의 동등성을 증명합니다. 같은 정규 출력은 포매터 간 합의를 확인합니다. 로그는 구성 요소가 문자열을 기록했다고 말합니다.

이 중 어느 것도 그 자체로 주소가 누구에게 할당되었는지, 경로 출처가 승인되었는지, 활성 경로가 존재하는지, 인터페이스가 도달 가능한지, 서비스가 인증되었는지, 패킷이 전달되었는지를 증명하지 않습니다. 정규화는 증거를 찾는 데 도움을 주지만 그 의미를 확장하지는 않습니다.

1차 문서는RFC 1884,RFC 1924,RFC 2732,RFC 3986,RFC 4291,RFC 5952입니다. 이들은 구현 목록이 아니라 사양입니다. Base85 구현의 부재를 증명하지 않으며, 후대 저자가 이를 공식적으로 배척했다는 사실도 기록하지 않습니다.

Running-Code Primacy는 실제 파서, 로그, 프로세스가 수용하고 보존하는지 검증하라는 이후의 독서 규율을 제시합니다.Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption은 작은 공통 계약이 왜 지역적 결정의 여지를 남기는지 이해하는 데 도움이 됩니다. 두 텍스트 모두 RFC 저자의 의도에 대한 증거가 아니라 후대의 분석입니다.

RFC 1924의 20자는 주소 전체를 담았습니다. 그 안에 이 주소를 어떻게 인식하고, 검색하고, 증거로 제시할지에 대한 합의는 담기지 않았습니다.