네트워크 인프라 이해하기 · 제5부 · 사내망을 지사·클라우드·인터넷과 연결하기

전 세계 공인 IP 주소는 누가 겹치지 않게 나눠 줄까

IANA에서 사용자까지 이어지는 등록 체계와 실제 인터넷 도달성의 분리

공인 IP는 한 조직이 임의로 골라 쓰는 번호가 아닙니다. IANA에서 RIR과 ISP를 거쳐 최종 조직으로 이어지는 등록·위임 절차와 인터넷에 Prefix를 알리는 라우팅 절차가 함께 맞아야 실제로 통신할 수 있습니다. 이 글에서는 주소의 등록 주체, Origin AS와 서비스 운영 주체를 서로 다른 자료에서 확인하고 판단하는 순서를 설명합니다.

전 세계에서 겹치지 않을 공인 IP는 IANA와 RIR이 어떤 순서로 나눌까↑

IANA는 IPv4·IPv6 주소와 AS Number 같은 인터넷 번호 자원의 전역 Registry를 관리합니다. 일반 사용자나 기업에 주소를 직접 판매하는 기관이 아니라, 글로벌 정책에 따라 큰 주소 Pool을 지역 인터넷 Registry에 배분하고 특수 목적 주소를 기록합니다.

RIR은 AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC 다섯 곳입니다. 각 RIR은 담당 지역의 정책에 따라 조직에 인터넷 번호 자원을 배분하고 등록 정보를 관리합니다. APNIC 지역의 일부 국가에서는 NIR이 이 업무를 맡기도 합니다. NIR은 모든 국가나 조직이 반드시 거치는 단계가 아니므로, 실제 신청·등록 경로는 해당 지역의 정책으로 확인해야 합니다.

이 계층은 주소의 사용 책임과 등록 관계를 나누는 관리 체계입니다. IANA는 큰 주소 공간과 특수 목적 범위를 기록하고, RIR은 지역 정책에 따라 조직의 요청을 심사합니다. ISP가 고객에게 더 작은 주소 블록을 제공할 때도 상위 기관의 등록과 정책을 따릅니다. 등록 기록에는 누가 주소를 관리하는지와 문제가 생겼을 때 연락할 곳이 남습니다.

주소를 조사할 때는 먼저 Special-Purpose Registry를 확인해야 합니다. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24처럼 문서 예시에 예약된 범위를 실제 Public 서비스 주소로 오해하면 Registry와 Route 해석이 어긋납니다. 실제 주소라면 IANA의 RDAP Bootstrap을 통해 담당 RIR을 찾고, 그 RIR의 최신 Registration Record를 조회합니다. 검색 사이트의 복제 정보보다 공식 Registry를 출발점으로 삼는 이유입니다.

이 구조의 목적은 전 세계에서 같은 공인 주소가 임의로 중복 사용되지 않도록 자원과 책임 연락처를 기록하는 데 있습니다. Registry 정보는 라우터의 전달 테이블이 아니며, 등록 기관이 서비스 운영자와 항상 같다는 보장도 없습니다. 개인정보 보호나 재할당 정책에 따라 공개되는 연락처의 수준도 Registry별로 다를 수 있습니다.

이 절의 근거 IANA Number Resources · IANA Number-related Registries · IETF RFC 7020 · APNIC National Internet Registries

공인 IP를 배정받았는데도 인터넷에서 그 주소로 찾아오지 못할 수 있다↑

주소 자원 위임은 그 Prefix를 사용할 행정적 근거를 만듭니다. 인터넷에서의 Reachability는 ISP 또는 조직이 BGP로 Prefix를 광고하고 다른 네트워크가 그 Route를 받아들일 때 생깁니다.

Provider Aggregate 안에서 ISP가 대신 광고할 수도 있고, 독립 주소와 AS Number를 가진 조직이 여러 ISP에 직접 광고할 수도 있습니다. Prefix Filter, 최대 길이, RPKI Origin Validation과 사업자 정책이 광고 수용에 영향을 줍니다.

조직이 2001:db8:1234::/48 같은 예시 Prefix를 배정받았다고 가정해도, 주변 라우터가 그 Prefix의 Next Hop을 알지 못하면 패킷은 도착하지 않습니다. 실제 환경에서 조직이 직접 경로를 광고하는 경우에는 ISP와 BGP 세션을 구성하고 Import·Export Filter를 통과한 Route가 인터넷에 전파되어야 합니다. 반대로 Route가 광고되어도 주소 사용 권한이 올바르다는 뜻은 아니므로 Registry와 라우팅은 서로를 보완하는 별도 증거입니다.

RPKI의 ROA는 어느 Origin AS가 해당 Prefix를 어느 최대 길이까지 광고할 수 있는지 밝힙니다. 이것도 Route를 자동 생성하지는 않으며 수신 네트워크가 Origin Validation 결과를 정책에 반영해야 합니다. Prefix가 보이지 않을 때는 등록 완료 여부, ISP의 송신 정책, 실제 BGP Advertisement, ROA의 Origin·Max Length를 순서대로 확인합니다. 주소 행정 문제와 경로 전파 문제를 분리하면 담당 기관과 수정 지점도 달라집니다.

실제 도달성을 확인할 때는 Route Collector나 ISP의 관측점에서 프리픽스, Origin AS, AS_PATH와 더 구체적인 경로가 있는지 봅니다. IRR Route Object는 운영자가 경로 광고 계획을 등록한 자료이고, RPKI ROA는 특정 AS가 어느 길이의 프리픽스까지 광고할 수 있는지 검증하는 자료입니다. 이 기록만으로 실제 경로 전파나 서비스 응답을 알 수는 없습니다. 등록·광고 권한·경로 전파·서비스 응답을 각각 확인해야 합니다.

이 절의 근거 IETF RFC 7020 · IETF RFC 6811 · IETF RFC 4271

IPv4 주소가 부족해지면서 Transfer·CGNAT·IPv6가 함께 등장했다↑

IANA의 신규 IPv4 여유 Pool은 고갈되었지만, 이것이 IPv4 주소가 모두 같은 날 사라졌다는 뜻은 아닙니다. RIR 정책에 따른 남은 Pool, 회수 주소, 대기 목록과 주소 이전이 지역별로 다르게 운영됩니다.

조직은 NAT와 주소 공유로 IPv4 수요를 줄일 수 있지만 포트와 상태 자원, 추적성 같은 제약을 떠안습니다. IPv6는 훨씬 큰 주소 공간을 제공하지만 Dual Stack, DNS, 보안 정책과 운영 체계를 함께 준비해야 실제 서비스가 전환됩니다.

IPv4 Transfer로 주소를 확보하면 Registry 변경, Route Filter, ROA, Reverse DNS와 Reputation 이력까지 함께 정비해야 합니다. 이전 주소가 과거 Spam이나 공격에 사용되었다면 서비스 제공자가 새 소유자의 트래픽을 여전히 제한할 수 있습니다. 주소를 구매했다는 계약만으로 즉시 깨끗한 Reachability가 생기는 것은 아닙니다. 운영 전 Registry와 라우팅, Security Reputation을 각각 검증해야 합니다.

CGNAT는 여러 가입자의 통신 흐름을 공인 주소와 포트로 다시 구분하므로 공인 주소 수요를 줄이지만 Inbound 연결, 포트 자원과 사용자 추적에 비용이 생깁니다. IPv6는 NAT를 없애는 한 줄짜리 대체가 아니라 Address Plan, 라우터 Advertisement 또는 DHCPv6, DNS AAAA, 방화벽 정책, Monitoring을 함께 배포하는 전환입니다. Dual Stack 기간에는 IPv4와 IPv6 중 어느 경로에서 문제가 생기는지 별도로 관찰해야 합니다.

IPv6는 훨씬 큰 주소 공간으로 End-to-End 주소 설계의 제약을 줄이지만, 도입 즉시 IPv4 의존성이 사라지는 것은 아닙니다. Dual Stack, NAT64/DNS64, Provider 지원과 보안 정책을 전환 기간에 함께 운영할 수 있습니다. 주소 전략은 단순 보유량이 아니라 애플리케이션의 IPv6 지원, 경로 광고, 관측 도구와 운영자 숙련도까지 포함해 단계적으로 정합니다.

이 절의 근거 IETF RFC 7020 · IETF RFC 6598 · IETF RFC 8200

용어사전↑