요약

  • RFC 4193은 의사 난수 기반 40비트 Global ID를 사용해 독립적으로 생성된 IPv6 Unique Local Address 접두어가 서로 다를 가능성을 매우 높게 만든다. 이는 할당하거나, 등록하거나, 인증하지 않는다.
  • “글로벌”은 의도된 고유성 범위를 뜻할 뿐, 공개 접근 가능성을 의미하지 않는다. ULA 경로는 한 사이트 내부 또는 명시적인 사이트 간 합의 안에 속하며, 신중한 라우팅·DNS·경계 정책이 필요하다.
  • 따라서 합병이나 VPN 연결은 확률을 실사(due diligence)의 출발점으로 다뤄야 한다. 모든 접두어를 비교하고, 경로와 네이밍 범위를 기록하고, 보안 통제를 독립적으로 유지하며, 재번호화 또는 롤백의 조건을 정의해야 한다.

두 회사가 곧 네트워크를 연결하려 한다. 각 팀은 자사의 내부 IPv6 공간이 고유하다고 말한다. 한쪽은 레지스트리 발급 서한을 내놓고, 다른 쪽은fd로 시작하는 설정 파일의 한 줄을 내놓는다. 접두어는 서로 다르고, 터널이 열리며, 프로젝트 관리자는 주소 중복을 해결됨으로 표시한다.

그 기록 중 배정 수령증이 될 수 있었던 것은 단 하나다.fd접두어는 애초에 수령증이 평소에는 필요 없도록 설계되었다.

2005년 10월 Robert Hinden과 Brian Haberman이 발표한 RFC 4193의 우아한 거래가 바로 이것이다. ULA(Unique Local Address, 고유 로컬 주소)는 특수한 운영 경계를 가진 평범한 IPv6 유니캐스트 공간이다. 그 형식은FC00::/7을 차지하며, 1비트L플래그, 40비트 Global ID, 16비트 Subnet ID, 그리고 일반적인 64비트 Interface ID를 포함한다. RFC 4193은 로컬 할당 주소에 대해L=1을 정의하며, 이는 현재 명시된 로컬 구성을FD00::/8아래에 둔다.

결정적인 단어는 “로컬(locally)”이다. 운영자는 레지스트리에 묻거나 다른 모든 운영자와 조율하지 않고도 40비트 값을 생성할 수 있다. RFC는 순차적이거나 익숙한 값이 아니라 의사 난수 선택을 요구한다. 제안된 절차는 시간과 시스템 고유 식별자를 결합하고, 그 결과를 SHA-1로 해시한 뒤 하위 40비트를 남긴다.

이것은 축소판 공개키 의식(ceremony)이 아니다. 그 절차에서 SHA-1은 운영자를 인증하거나, 소유권을 부여하거나, 주소를 비밀로 만들지 않는다. 그것은 독립적인 선택들을 넓은 공간에 흩뿌리는 방법일 뿐이다.

확률 표가 이 메커니즘이 얻어주는 것을 설명한다. RFC 4193은 독립적으로 생성된 두 Global ID를 비교할 때 충돌 확률을 약1.81 × 10^-12로 추정한다. ID가 10,000개일 때 추정치는 약4.54 × 10^-5로 올라간다. 이는 모델로 계산된 확률이며, 배포된 네트워크의 측정값이 아니다. 이 수치들은 우연한 중복을 매우 희박하게 만들지만, 불가능하게 만들지는 않는다.

이 구분은 필드 이름이 Global ID이기 때문에 놓치기 쉽다. 여기서 “글로벌”은 독립적으로 운영되는 사이트들에 걸친 고유성에 대한 기대를 뜻한다. 경로가 전 세계적으로 도달 가능하거나, 집약 가능하거나, 디폴트 프리 존에 등장할 자격이 있다는 뜻이 아니다. 현재 IANA IPv6 특수 목적 주소 레지스트리는 이 구분을 명시적으로 만든다.fc00::/7은 출발지 또는 목적지로 사용될 수 있고 포워딩될 수 있지만, 전 세계적으로 도달 가능하지는 않다. IANA는 또한 레지스트리에 등재되었다는 사실 자체가 어떤 특정 맥락에서의 라우팅 가능성을 보장하지 않는다고 경고한다.

라우터가 강제해야 하는 범위

RFC 4193은 ULA 경로가 한 사이트 내부에 머물거나, 이를 교환하기로 명시적으로 합의한 사이트들 사이에 머물 것으로 기대한다. 인터넷 라우팅은 기본적으로 이 전체 범위를 무시해야 한다. 경계에서는 일반적으로 ULA 경로와 패킷을 양방향으로 필터링해야 한다. 두 조직이 의도적으로 연결하는 경우, 예외는 열린 클래스로서의FC00::/7이 아니라 해당 연결에 필요한 특정/48접두어—또는 더 구체적인 경로—를 명시해야 한다.

이 라우팅 규칙은 “사설 IPv6”라는 표현이 왜 불완전한지 보여준다. ULA는 자동으로 벽 앞에서 멈추지 않는다. 라우터는 이를 포워딩할 수 있다. VPN은 이를 실어 나를 수 있다. 부주의한 재배포 정책은 이를 유출할 수 있다. 수신 네트워크는 경로를 설치할 수 있다. 범위(scope)는 첫 바이트의 신비한 속성이 아니라, 필터와 토폴로지로 표현되는 운영적 결정이다.

DNS에도 같은 규율이 필요하다. RFC 4193은 ULA 주소가 고유성이 보장되지 않으므로 전역 DNS에 ULA AAAA 또는 PTR 레코드를 두지 말 것을 권한다. 이들에 대한 역방향 질의는 전역 DNS 인프라로 새어 나가서는 안 된다. 따라서 내부 권한 존, 스플릿 호라이즌 뷰, 리졸버 포워딩 규칙은 접두어 자체와 함께 합병 목록에 들어가야 한다.

주소 할당도 여전히 별개다. ULA/48이 서브넷을 채우지 않는다. 어떤 시스템이 그 주소를 사용하는지는 라우터 광고, DHCPv6, 수동 설정, 서브넷 계획, 이름 등록이 여전히 결정한다. RFC 5375는 ULA가 전역 라우팅되는 IPv6 주소와 공존할 수 있음을 언급한다. 이것이 IPv6를 네트워크 주소 변환(NAT) 뒤에 두어야 한다는 뜻은 아니다.

이 마지막 경계가 중요하다. 조직은 외부 서비스에는 전역 도달 가능 주소를, 안정적인 내부 참조에는 ULA를 사용할 수도 있고, 전역 주소화에 정책 통제를 더하는 편이 더 단순하다고 판단할 수도 있다. 어느 쪽을 선택하든 인증, 권한 부여, 방화벽, 서비스 수준 통제의 필요는 사라지지 않는다. RFC 4193은 명확하다. ULA는 고유한 보안을 제공하지 않는다. 주소 클래스는 식별 시스템이 아니다.

40비트가 수리한 것

선행 표준을 살펴보면 설계를 이해하는 데 도움이 된다. RFC 3879는 “사이트”가 안정적인 의미를 갖지 못했기 때문에 IPv6 사이트 로컬 주소를 폐기했다. 여러 지점을 둔 조직은 두 주소가 같은 사이트에 속하는지 신뢰 있게 판단할 수 없었다. 사이트 로컬 접두어는 유출될 수 있었고, 애플리케이션은 범위를 일관되게 선택할 수 없었으며, 다른 네트워크에 합류하는 네트워크에는 하나의 로컬 블록을 다른 블록과 구분하는 식별자가 없었다.

생성된 Global ID는 보편적 할당 기관을 만들지 않으면서 이 마지막 약점을 수리한다. 두 사이트는 독립적으로 자신을 번호 매길 수 있고, 나중에 그 접두어들이 거의 확실하게 다르다는 것을 발견할 수 있다. RFC 5375는 유출과 합병에 대한 이점을 강조한다. ULA는 네트워크 합류가 즉각적인 재번호화를 강제할 가능성을 줄일 수 있다.

줄인다는 것은 제거한다는 뜻이 아니다. RFC 4193은 전역 ULA 라우팅이 권고되지 않는 이유로, 고유성을 보장하는 권위가 없다는 점과 이 공간은 유용하게 집약될 수 없다는 점을 든다. 연결된 두 사이트가 같은 식별자를 공유한다면, 그들 사이의 통신은 실패하거나 잘못된 시스템에 도달할 수 있다. 충돌이 일어나기 어려웠다는 사실이 그 영향을 작게 만들지는 않는다.

이 지점에서 Haberman의 기여는 운영 교훈으로 가장 유용하다. 이 RFC는 Hinden과 공동 저술이며 더 넓은 기술 커뮤니티를 인정한다. 이를 단독 발명가 서사로 바꿔서는 안 된다. Haberman의 이후 공개 이력—IETF에서의 오랜 참여, 초기 IPv6 라우터 작업, 그리고 2026년 8월 기준 Internet Society 이사회 의장—은 이러한 경계를 지켜야 하는 기관들과 운영 중인 시스템을 둘러싼 경력을 보여준다. 기술적 주장에 대한 권위는 여전히 표준 자체에 있다.

합병이 실제로 필요로 하는 수령증

두 네트워크가 합류할 때, 어느 팀도 ULA에 중앙 서류가 없다는 이유로 거부해서는 안 된다. 그렇다고 접두어가 무작위처럼 보인다는 이유만으로 받아들여서도 안 된다. 빠져 있는 수령증은 운영적인 것이며, 만들어낼 수 있다.

첫째, 양쪽의 정확한 활성 및 예약/48접두어를 목록화하라. 실험 네트워크, 클라우드 가상 네트워크, 휴면 VPN 파트너, 재해 복구 환경, 애플리케이션 설정에 박힌 주소 블록까지 포함하라. 값을 직접 비교하라. RFC의 확률은 점검 전의 신뢰를 뒷받침한다. 양쪽 목록이 확보된 이후에는 점검을 대체할 수 없다.

둘째, 각 접두어가 어떻게 생성되었고 누가 관리하는지 기록하라. 생성 시각, 방법, 시스템 식별자 클래스, 책임 운영자는 나중에 중복이나 복제를 진단하기 쉽게 만든다. 기록은 민감한 기기 식별자를 노출할 필요는 없지만, 진짜 독립 생성과 자회사에 복제된 템플릿을 구분할 수 있어야 한다.

셋째, 경로 수용을 명시적으로 만들어라. 상호연결 이름, 허용 접두어, 넥스트 홉, 임포트·익스포트 필터, 모니터링 담당자, 롤백 조치를 명명하라. 경계가FC00::/7의 나머지를 거부하는지, ULA 경로가 인터넷 피어에 도달하지 않는지 테스트하라.

넷째, 네이밍과 주소 선택을 목록화하라. 권한 내부 존, 역방향 존, 스플릿 뷰, 리졸버 경로, 전역 주소보다 ULA를 선호하는 애플리케이션을 식별하라. 접두어 충돌은 하나의 실패 모드일 뿐이다. 중복된 내부 이름이나 도달 불가능한 선호 주소는 모든 Global ID가 다르더라도 서비스를 깨뜨릴 수 있다.

다섯째, 보안 근거는 별도의 열에 두어라. 어느 서비스가 호출자를 인증하는가? 어느 방화벽 규칙이 흐름을 허용하는가? 어느 경로 출처가 신뢰되는가? 어느 로그가 악용을 식별할 수 있는가? “그것은 ULA다”라는 말은 이 질문들에 아무것도 답하지 않는다.

마지막으로, 전환(cutover) 전에 출구 조건을 문서화하라. 발견된 충돌은 한쪽의 재번호화를 요구할 수 있다. 예기치 않은 전역 광고는 즉각적인 경로 철회를 요구할 수 있다. DNS 유출은 리졸버 경로의 격리를 요구할 수 있다. 리터럴 주소가 박힌 애플리케이션은 수리될 때까지 네트워크를 분리해 둘 수 있다. 낮은 확률은 결단력 있는 롤백과 양립한다.

Lu Heng의 Running-Code Primacy는 이 방법을 날카롭게 만든다. 선언된 접두어와 다이어그램은 행정적 근거일 뿐이며, 패킷 경로, 경로 테이블, 리졸버 동작, 애플리케이션 테스트만이 시스템이 실제로 무엇을 하는지 보여준다. Minimum Initial Specification는 조율 규칙을 더한다. 각 운영자가 로컬 설계를 유지하면서 상호연결을 되돌릴 수 있게 해주는 최소한의 공유 기록을 요구하라.

40비트 Global ID가 가치 있는 이유는 정확히 모든 내부 네트워크를 중앙 집중화하려 하지 않기 때문이다. 그것은 자율적 선택들이 매우 높은 확률로 공존하게 만든다. 운영자의 몫은 “매우 높음”을 확률 열에 유지하는 것이고, 확률이 결코 제공하려 하지 않았던 라우팅, 네이밍, 보안, 출구 통제를 구축하는 것이다.

출처