요약

  • 범위가 제한된 IPv6 주소 값은 서로 다른 존에서 다시 나타날 수 있다. 따라서 멀티홈 노드는 별도의 로컬 존 인덱스를 제공하며, 이는 흔히 인터페이스 이름으로 선택되고, 어떤 패킷도 회선을 넘기 전에 이 맥락을 소비한다.
  • RFC 6874는 2013년 URI 문법 안에 ZoneID를 넣으려 시도했다. RFC 9844는 2025년에 그 접근을 폐기하고, 대신 사용자 인터페이스가 존 정보를 수집·검증·로컬 매핑하되 그것을 휴대 가능한 주소나 HTTP 신원으로 만들지 않도록 요구했다.

잘못된 것을 보존한 복사본

한 운영자가fe80::1%eth0로 장치를 진단하고 그 값을 티켓에 복사해 동료에게 테스트 재현을 부탁한다. 두 번째 호스트에서도 주소 파서는 여전히fe80::1을 인식한다. 접미사는 다른 인터페이스를 가리킬 수 있고, 해석에 실패할 수도 있으며, 첫 테스트와 무관한 네트워크를 선택할 수도 있다.

복사는 문법은 보존했지만 관할권은 버렸다. 첫 번째 기계가eth0을 해석할 권한을 가졌던 이유는 그 기계가 인터페이스 테이블을 소유했기 때문이다. 두 번째 기계는 운영자가 의미한 물리적 또는 가상 링크가 무엇인지에 대한 휴대 가능한 증명을 전달받지 못했다.

이는 링크 로컬 주소 지정의 결함이 아니다.RFC 4291은 링크 로컬 유니캐스트를 단일 링크에서의 사용으로 정의한다. 라우터는 링크 로컬 출발지 또는 목적지 주소를 가진 패킷을 다른 링크로 전달해서는 안 된다. 서로 분리된 두 링크는 각각fe80::1이라 불리는 노드를 포함할 수 있으며, 어느 값도 전역 고유성을 주장하지 않는다.

모호성은 두 링크에 모두 붙어 있는 노드에서 발생한다. 128비트 주소는 어느 쪽도 구분하지 못한다. 애플리케이션에게 결여된 것은 IPv6 주소의 또 다른 부분이 아니라, 이 주소의 이번 사용이 어디에 속하는지에 대한 로컬 서술이다.

스코프는 크기였고, 존은 하나의 실例였다

2005년 3월에 발표된RFC 4007은 이 문제를 다룰 수 있게 해주는 어휘를 제공했다. 스코프는 위상적 영역의 크기를 서술한다. 존은 그 스코프를 가진 영역의 하나의 특정 실例다.

따라서 링크 로컬은 스코프다. 유지보수 이더넷과 격리된 서비스 어댑터는 서로 다른 두 개의 링크 로컬 존이다. 두 용어를 혼동하면 주소가 도달할 수 있는 범위라는 공유된 아키텍처적 속성과, 지금 어느 연결 영역을 의미하는가라는 노드의 임시적 지식을 하나로 무너뜨리게 된다.

같은 스코프의 여러 존에 붙은 노드는 자기 자신의 존 인덱스를 부여한다. 인덱스는 노드의 선택을 구분해야 하지만 철저히 로컬이다. 같은 링크의 반대편 끝은 다른 번호를 부여할 수 있다. 두 커널이 인터페이스 테이블을 조율하도록 요구하는 프로토콜은 없다.

RFC 4007은 텍스트 형식<address>%<zone_id>를 권고했다. 구현체는 음수가 아닌 십진수 식별자를 받아들여야 하고, 인터페이스 이름 같은 구현 정의 문자열을 받아들일 수도 있다. 주소가 스코프를 제공하므로%뒤의 텍스트는 그 스코프의 존들 중 하나를 선택하는 것만으로 충분하다.

이 형식은 문법만큼 중요한 경계도 함께 운반한다. 존 식별자는 전역 주소에서는 무의미하며 루프백과 함께 사용해서는 안 된다. 결합된 텍스트는 노드 내부에서의 사용을 위한 것이다. 이를 해석하는 모든 노드가 그 의미론에 동의한 경우가 아니라면 회선상으로 전송해서는 안 된다.

그러므로 이 주석은 IPv6에 덧붙여진 작은 전역 네임스페이스가 아니다. 그것은 하나의 호스트가 내린 결정 맥락의 압축된 표현이다.

소켓 API에 내장된 보관 사슬

기본 IPv6 소켓 인터페이스는 이미 주소와 로컬 선택자를 별도로 표현했다. 2003년 2월에 발표된RFC 3493은 주소를 위한sin6_addr필드와 32비트sin6_scope_id필드를 가진sockaddr_in6를 정의한다.

애플리케이션은 둘 모두를 자기 로컬 커널에 넘긴다. 스코프 식별자는 128비트를 확장하지 않고 IPv6 패킷 필드가 되지도 않는다. 그것은 로컬 라우팅 선택을 안내한 뒤 멈춘다.

RFC 3493은 인터페이스 이름과 인덱스 사이의 매핑도 정의한다.if_nametoindex()는 실행 중인 시스템에 이름 해석을 요청한다. 알 수 없는 이름은 실패한다. 이 함수는eth0을 위해 인터넷 레지스트리에 질의하지 않으며, 송신자의 이름이 무엇을 의미해야 하는지 목적지에게 묻지도 않는다.

이렇게 보관 사슬이 만들어진다. 사람이 읽는 UI는 이름을 수집할 수 있다. 애플리케이션은 그것을 현재 운영체제를 통해 매핑한다. 소켓은 그 결과 숫자를 프로세스–커널 경계 안에서 운반한다. IP 계층은 제한된 스코프를 적용한다. 원격 노드는 송신자의 인터페이스 어휘를 전혀 받지 못한다.

전달마다 주장할 수 있는 것은 줄어든다. 문자열을 받아들였다고 해서 그것이 매핑된다는 증명은 아니다. 인덱스로 매핑했다고 해서 인터페이스가 켜져 있다는 증명은 아니다. 송신이 성공했다고 해서 응답자가 인증된 것은 아니다. 결합된 텍스트를 스스로 증명하는 하나의 주소로 다루는 것은 바로 이 검증 지점들을 지워버린다.

표준 주소 텍스트는 접미사 앞에서 멈췄다

IPv6 주소는 여러 동등한 표기법을 허용한다. 2010년 8월에 발표된RFC 5952는 0 압축, 문자 대소문자, 그리고 리터럴 주소와 포트가 짝을 이룰 때의 대괄호에 대한 규칙으로 그 변동을 줄였다. 표준 텍스트는 로그, 검색, 구성, 비교에 도움이 된다.

나중에 RFC 9844는 중요한 단서를 달았다. RFC 5952는 RFC 4007의 존 확장을 다루지 않는다는 것이다. 주소 비트를 표준화하는 것은 호스트의 인터페이스 이름을 표준화할 수 없다. 숫자 인덱스조차도 내구성 있는 주소 재료가 아니라 로컬 상태로 남는다.

기본 존이 이 구분을 제거해 주지는 않는다. RFC 4007은 기본값을 권고하며 보통 0을 하나를 표현하는 데 쓴다.RFC 9844는 모든 운영체제가 쓸 수 있는 기본값을 제공하는 것은 아니며 리눅스를 그 예로 든다고 기록한다.

애플리케이션이 명시적 선택자 없이 성공했다면, 그것은 어떤 로컬 맥락이 그 작업을 완수했다는 것을 보여줄 뿐이다. 주소가 그 선택을 운반했다는 것을 보여주지는 않는다. 같은 호출을 다른 시스템에 이식하면 숨겨진 가정이 드러날 수 있다.

따라서 감사 기록은 주소, 제공된 존 텍스트, 해석된 인덱스, 실행 호스트, 시각을 보존해야 한다. 표준 주소만 저장하면 선택이 사라지고, 인덱스만 저장하면 운영자의 표현과 그 숫자가 유효했던 매핑이 사라진다.

지역 주석이 전역 문법에 들어가다

URI 문법은 이 경계를 시야 안으로 밀어넣었다. 2005년 1월에 발표된RFC 3986은 URI를 전역 범위를 가진 것으로 서술하되, URI와 연관된 동작이 최종 사용자의 맥락에 의존할 수 있음을 인정한다. 또한 URI는%를 퍼센트 인코딩의 도입부로 예약한다. 데이터로 쓰이는 리터럴 퍼센트 기호는%25로 표현된다.

RFC 6874는 2013년 2월에 이 형식들을 결합하려 시도했다. HTTP URI 안에서[fe80::a%25en1]같은 대괄호 리터럴을 제안했다.%25가 구분자 퍼센트 기호를 나타내고 그 뒤에 로컬 ZoneID가 붙는 형태였다.

그 사용 사례는 실용적이었다. 브라우저나 기타 URI 기반 도구는 여러 인터페이스 중 하나를 통해 링크 로컬 장치를 지정할 방법이 필요했다. 그러나 그 RFC 자체가 ZoneID는 발신 노드에서만 의미가 있으며 외부 HTTP 요청에 포함되기 전에 제거해야 한다고 밝혔다.

주석은 주소 표시줄에서 URI의 일부처럼 보였지만, URI가 네트워크 메시지를 지배하기 전에 그 일부가 되는 것을 멈추어야 했다. 이 긴장은 파싱을 넘어섰다. 접미사는 HTTP 오리진에 영향을 주어야 하는가? 히스토리나 북마크에 남아야 하는가? 프록시가 보아야 하는가? 어느 계층이%25를 디코딩해야 하는가, 그리고 또 하나의 디코딩 과정은 그것을 어떻게 바꾸는가?

퍼센트 인코딩이 근본적인 어려움은 아니었다. 송신자 네임스페이스 안의 임시 인수가 저장되고, 비교되고, 맥락 사이에서 운반되도록 만들어진 표현에 들어간 것이다. 다른 구분자를 썼어도 어떤 계층이 그 의미를 소유하는지는 결정하지 못했을 것이다.

과업을 버리지 않고 문법을 폐기하다

2025년 8월, RFC 9844는 RFC 6874를 완전히 폐기했다. 브라우저 구현자들은 URI 접근이 실행 불가능하다고 판단했다. RFC 9844는 또한 RFC 6874가 RFC 3986에 가한 수정을 되돌렸고, RFC 6874에 등록된 검증된 정오표 8552가 그 변경된 관계를 기록한다.

대체 문서는 세 번째 이스케이프 시퀀스를 발명하지 않았다. 의무를 옮겼다. 전역 유니캐스트가 아닌 주소를 받아들이는 사용자 인터페이스는 사용자가 존 식별자를 입력하거나 선택할 수 있게 해야 한다. 완전한%형식이 선호되며, 상황에 따라 별도 필드, 목록, 다른 구분자 또는 별도 매개변수를 쓸 수 있다.

UI는 주소와 존 식별자를 분리 유지하고, 후자를 로컬 인터페이스 인덱스로 매핑하며, 잘못된 식별자는 오류로 보고해야 한다. POSIXinet_pton()은 그것만으로는fe80::1%eth0을 변환할 수 없다. 프로그램은getaddrinfo()가 필요하거나, 입력을 나누어inet_pton()과if_nametoindex()를 결합해야 한다.

RFC 9844는 브라우저가 가져오는 URI의 의미론을 명시적으로 제외한다. 휴대 가능한 링크 로컬 HTTP 오리진을 만들지 않고, 접미사를 전송되는 신원으로 부활시키지도 않는다. 그것은 로컬 맥락이 필요한 소프트웨어에 그 맥락을 공급하는 능력을 표준화한다.

이것은 문법의 축소이자 책임 소재의 개선이었다. 사용자에게 물을 수 있는 UI가 입력을 소유한다. 인터페이스를 아는 운영체제가 매핑을 소유한다. 프로토콜은 다른 노드가 공유할 수 있는 의미만 운반한다.

입력 자유가 검증 의무를 낳았다

RFC 4007은 존 식별자에 보편적인 문자 셋이나 길이를 부여하지 않았다. 숫자가 아닌 문자열의 의미는 구현 정의로 남았다. 이 유연성은 운영체제 이름을 허용했지만, 애플리케이션이 안전을 위해 하나의 전역 문법에 의존하는 것을 막았다.

RFC 9844는 UI가 적절한 길이를 부과하고 NUL 같은 위험한 입력을 거절하도록 권고한다. RFC 4007에 등록된 보류 중인 정오표 8553은 누락된 문자·길이 제한을 지적하고 RFC 9844의 보안 조치를 가리킨다.

존 문자열은 폼, 셸, 구성 파일, URI 위젯, 로그 파이프라인, 시스템 API를 넘나들 수 있다. 계층들은 서로 다른 시점에 디코딩, 잘라내기, 정규화할 수 있다. 운영자에게 표시된 값이 궁극적으로 인터페이스 인덱스를 만드는 값과 다를 수 있다.

필드를 분리 유지하면 하나의 결합된 미니 언어를 이해하도록 요구받는 해석자의 수가 줄어든다. 애플리케이션은 주소 문법을 주소로 검증하고, 존을 로컬 규칙으로 검증하고, 해석된 인터페이스를 확인을 위해 제시하는 것과 비교할 수 있다.

그 결과물도 여전히 유한한 증거 가치를 갖는다.%eth0를 통한 성공적인 작업은 그 이름이 그 호스트에서 해석되었고 선택된 경로가 그 작업에 효과적이었다는 것을 보여준다. 그것은 원격 노드를 인증하지 않고, 주소의 소유권을 증명하지 않고, 전역 도달성을 보장하지 않으며, 인터페이스 이름을 휴대 가능하게 만들지도 않는다.

휴대 불가능한 부분으로 만든 완전한 기록

가장 유용한 운영 기록은 어디서든 작동하는 마법 문자열이 아니다. 그것은 범위가 명시된 사실들의 집합이다. IPv6 값, 입력된 로컬 식별자, 만들어진 인덱스, 그 지도를 소유한 호스트, 인터페이스 상태, 실행 시각.

이런 기록은 재현이 자동적이라고 가장하지 않으면서 재현을 지원한다. 두 번째 호스트는 자기 자신의 위상을 조사하고, 의도된 링크를 선택하고, 새로운 로컬 매핑을 만들 수 있다. 그렇게 못한다면 그 실패는 잘못된 경로를 조용히 재사용하는 대신 결여된 맥락을 드러낸다.

IPv6 존 식별자는 조율을 지나치게 많이 하기를 거부함으로써 조율 문제를 해결했다. 표준은 스코프, 존, API 필드, UI 의무를 정의했다. 개별 노드는 자기 인터페이스 네임스페이스를 유지했다. 패킷은 수신자가 해석할 수 없는 로컬 레이블을 얻지 않았다.

주소에 지역 주석이 필요했던 이유는 그 작업이 로컬 지식을 필요로 했기 때문이다. 그 주석은 자신의 한계를 인정하는 동안에만 신뢰할 수 있었다.

출처