Summary

  • IETF 초안 제10판은 NAT64 공통 프리픽스로 사설 및 공유 IPv4 주소를 표현하도록 제안한다. 2026년 11월 23일까지 IESG 최종 의견 수렴이 진행된다.
  • 관리되지 않는 단말 쪽 CLAT는 이런 패킷을 기본적으로 변환하고, 관리형 PLAT에는 변환을 끄는 설정을 요구한다. 기존 차단 기본값은 소프트웨어 갱신 때 유지하라고 권고한다.
  • 프리픽스 하나로 외부와 내부 IPv4 목적지를 처리할 수 있지만, 내부 서비스의 접근 권한은 라우트와 방화벽 규칙으로 직접 결정해야 한다.

회사 안의 서버가 안전한 이유를 물었을 때 “방화벽이 막는다”는 답이 늘 맞는 것은 아니다. RFC 6052는 64:ff9b::/96에 비전역 IPv4 주소를 넣어 만든 목적지로 향하는 패킷을 변환기가 버리도록 한다. 접근 권한을 누가 승인했는지 기록이 없어도, 이 규칙 자체가 출입구를 닫아 두었다. IETF가 검토하는 새 초안은 그 잠금장치를 풀고 운영자가 직접 문을 관리하게 한다.

오래된 금지에는 이유가 있었다. RFC 1918의 사설 주소는 서로 다른 조직이 똑같이 쓸 수 있다. 지사 A와 지사 B의 10.0.0.1은 숫자만 같은 별개 장비다. IPv6 주소 앞에 공통 프리픽스를 붙여도 어느 지사를 뜻하는지는 정해지지 않는다. 그러나 모든 사설 목적지를 버리면, IPv6 전용 단말이 꼭 필요한 내부 IPv4 서비스에도 갈 수 없다. RFC 6598의 공유 주소 공간도 비슷한 운영 문제에 들어온다.

프리픽스 두 개의 함정

공용 IPv4에는 공통 프리픽스, 내부 IPv4에는 네트워크 고유 프리픽스를 쓰자는 설계는 보기 좋다. DNS64가 답을 합성하는 경우에는 서버가 목적지에 따라 선택할 수 있다. 그러나 애플리케이션이 숫자로 된 IPv4 주소를 직접 사용하고 단말의 CLAT가 IPv6 목적지를 합성하면 DNS64는 그 선택 과정에 없다.

초안에 따르면 RFC 7050의 발견 방식과 RFC 8781의 라우터 광고는 사용 가능한 프리픽스를 알려 줄 뿐, IPv4 주소 범위별로 어느 프리픽스를 써야 하는지 알려 주지 않는다. 단말이 두 개를 배우면 공개 주소 하나에도 두 개의 IPv6 목적지를 만들 수 있다. 보안 정책과 장애 기록은 두 경로를 따라가야 한다. RFC 8215의 로컬 프리픽스를 곁들여도 이 선택표가 저절로 생기지 않는다.

그래서 제10판은 RFC 6052의 문장을 정면으로 고친다. 공통 프리픽스로 비전역 IPv4 주소를 표현해도 된다. 관리되지 않는 CLAT는 기본적으로 변환한다. 관리형 PLAT는 별도로 막지 않는 한 변환하며, 차단할 수 있는 설정을 제공해야 한다. 표준이 일괄 거부하던 결정을 각 네트워크 운영자가 내리게 되는 것이다.

버전 업그레이드가 접근 권한까지 올려서는 안 된다

초안의 보안 부분은 일부 관리자가 기존의 강제 폐기를 내부망 방어선으로 쓰고 있다고 지적한다. 그래서 이미 그 방식으로 동작하는 관리형 PLAT는 업그레이드만으로 기본 차단을 바꾸지 말라고 권고한다. 내부 서비스에 접근을 허용하려면 관리자가 의도적으로 설정을 고르고, ACL이나 방화벽으로 출발지와 목적지, 서비스 포트를 제한해야 한다. 라우팅 역시 올바른 사설망으로 향해야 한다.

합병한 회사가 서로 다른 사업부에서 같은 10.0.0.1을 쓸 수 있다. 주소 변환에 성공한 패킷도 잘못된 사업부에 도착하면 사고다. 변환기는 패킷 형식을 바꾸지, 해당 번호의 소유권이나 사용자의 업무 권한을 판정하지 않는다. 기술적으로 연결된다는 사실과 조직이 허가했다는 사실은 별개의 증거다.

현재 CLAT 구현도 한 가지로 움직이지 않는다. 초안은 옛 규칙대로 사설 목적지를 버리는 구현과 이미 변환하는 구현을 모두 언급하지만, 각 집단의 규모를 제시하지 않는다. 운영자가 확인할 것은 자신의 목록이다. 어떤 단말이 주소를 직접 합성하는가, 어느 변환기가 패킷을 버리는가, 사설 번호는 어느 라우팅 영역에서 어떤 서비스를 가리키는가. 이 질문에 답하지 못하면 편리한 프리픽스 하나가 엉뚱한 문을 여는 만능 열쇠가 된다.

제10판은 아직 의견 수렴 중인 초안이다. 현재 공표된 규칙은 RFC 6052에 남아 있다. 다만 선택의 방향은 선명하다. 표준이 대신 해 주던 거부를 없애려면, 운영 조직은 허용과 거부의 근거를 자신의 규칙과 기록으로 남겨야 한다.

IETF 초안 · RFC 6052 · RFC 1918 · RFC 6598