# IPv6는 NAT가 없다고 해서 보안에 취약하지 않다 > Clean Markdown view of GeekNews topic #26021. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26021](https://news.hada.io/topic?id=26021) - GeekNews Markdown: [https://news.hada.io/topic/26021.md](https://news.hada.io/topic/26021.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-22T05:33:21+09:00 - Updated: 2026-01-22T05:33:21+09:00 - Original source: [johnmaguire.me](https://www.johnmaguire.me/blog/ipv6-is-not-insecure-because-it-lacks-nat/) - Points: 4 - Comments: 1 ## Topic Body - IPv4가 NAT를 기본적으로 사용하기 때문에 더 안전하다는 주장은 **보안과 주소 변환의 혼동**에서 비롯됨 - **NAT(Network Address Translation)** 은 보안 기능이 아니라 **IPv4 주소 부족을 해결하기 위한 주소 절약 메커니즘**임 - NAT의 동작은 포트 매핑을 기반으로 여러 장치가 하나의 공인 IP를 공유하도록 하는 것에 불과함 - 실제로 외부 트래픽을 차단하는 역할은 NAT가 아니라 **상태 기반 방화벽(stateful firewall)** 이 수행함 - IPv6 환경에서도 기본적으로 **방화벽이 비인가 트래픽을 차단**하므로, NAT의 부재가 보안 약화를 의미하지 않음 --- ### NAT와 보안의 혼동 - IPv4가 NAT를 사용하기 때문에 더 안전하다는 주장은 **잘못된 인식**임 - NAT는 보안 기능이 아니라 **주소 절약(address conservation)** 을 위한 기술임 - IPv6에서도 NAT를 사용할 수 있지만, 그것이 보안을 강화하지는 않음 - NAT는 내부 네트워크의 여러 장치가 **하나의 공인 IP 주소를 공유**하도록 함 - 패킷의 목적지 포트를 기반으로 **목적지 IP를 재작성(rewrite)** 하여 라우팅 수행 - 네트워크 관리자가 설정한 **포트 매핑(port mapping)** 또는 **포트 포워딩(port forwarding)** 규칙에 따라 동작 ### NAT의 실제 동작 방식 - NAT 환경에서 외부에서 들어오는 트래픽은 **예상치 못한 목적지 포트**를 가진 경우 내부 장치로 전달되지 않음 - 이러한 트래픽은 공인 IP를 가진 장치에 머무르며, 내부 네트워크로 라우팅되지 않음 - 이로 인해 NAT가 외부 접근을 차단하는 것처럼 보이지만, 이는 **부수적인 결과**일 뿐 보안 설계 목적이 아님 ### 방화벽의 역할 - NAT가 제공한다고 오해되는 보안 효과는 사실상 **상태 기반 방화벽(stateful firewall)** 에서 비롯됨 - 대부분의 현대 라우터는 NAT 여부와 관계없이 **기본적으로 인바운드 트래픽을 차단**하는 방화벽 정책을 포함 - 방화벽은 패킷을 재작성하거나 라우팅하기 전에 **예상치 못한 목적지 트래픽을 폐기(drop)** 함 - 예시로 **UniFi 라우터**의 기본 IPv6 방화벽 규칙은 다음과 같음 - Established/Related 트래픽 허용 (아웃바운드 응답 트래픽) - Invalid 트래픽 차단 - 그 외 모든 트래픽 차단 ### IPv6 환경에서의 보안 - IPv6 네트워크에서도 **기본 방화벽 규칙이 비인가 인바운드 트래픽을 차단**함 - NAT를 사용하지 않아도 동일한 수준의 보호가 적용됨 - 외부에서 IPv6 장치로 **비요청 트래픽을 허용하려면 명시적으로 방화벽 규칙을 추가**해야 함 - 이는 NAT 사용 여부와 무관하게 동일하게 적용됨 ### 결론 - IPv6가 NAT를 사용하지 않는다는 이유로 **보안이 약화된다는 주장은 근거 없음** - 실제 보안은 NAT가 아닌 **방화벽 정책과 트래픽 제어 규칙**에 의해 결정됨 - IPv6 환경에서도 적절한 방화벽 설정을 통해 **기본 거부(default-deny)** 보안 전략을 유지할 수 있음 ## Comments ### Comment 49651 - Author: neo - Created: 2026-01-22T05:33:21+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46696303) - 토론에 참여하기 전에 [RFC 4787의 섹션 5](https://datatracker.ietf.org/doc/html/rfc4787#section-5)를 살펴보길 권함 NAT는 **방화벽이 아님**에도 불구하고 트래픽을 필터링하며, 그로 인해 일정 수준의 **보안 기능**을 제공함 현실에서는 NAT가 단순 주소 변환을 넘어 발전해왔으며, IPv6가 NAT를 사용하지 않아도 방화벽으로 동일한 필터링을 구현할 수 있음 - RFC 4787은 실제 구현과는 다름. 대부분의 SOHO 라우터는 Linux 기반이므로, **netfilter 기반 NAT**의 동작을 논의하는 게 현실적임 Linux netfilter는 NAT와 방화벽을 모두 구현하며, `nat` 테이블의 DNAT/SNAT 규칙은 NAT, `filter` 테이블의 REJECT/DROP 규칙은 방화벽 역할을 함 NAT 규칙만 적용된 경우에는 기존 연결에 속하지 않은 트래픽도 그대로 통과시킴 - RFC 4787의 해당 섹션은 **아웃바운드 연결**에 대한 설명임 NAT가 외부로 나가는 연결을 만들 때 상태 테이블을 생성하고, 그에 대응하는 인바운드 패킷을 허용하는 과정을 다룸 즉, 이 문서의 “filtering”은 비요청 인바운드 연결을 의미하지 않음 - IPv6가 NAT가 없어도 덜 안전한 건 아니지만, **기본 설정(defaults)** 이 중요함 IPv6도 IPv4만큼 안전할 수 있지만, 설정에 따라 달라짐 - 30년 IT 경력상 NAT 환경은 **게으른 설계**를 유도함 시스템과 애플리케이션 엔지니어들이 문제를 전체적으로 이해하지 않고, NAT와 경계 방화벽에 의존하는 것은 나쁜 보안 습관임 - RFC가 항상 절대적인 기준은 아님 특히 실제 구현과 멀어질수록 **RFC의 신뢰성**은 떨어짐 - 미국의 모바일 네트워크에서는 NAT 없이도 IPv6 주소를 사용함 예를 들어 T-Mobile은 **464XLAT**로 IPv4를 IPv6 위에 터널링함 이는 NAT 없이도 대규모로 상태 기반 방화벽이 운영될 수 있음을 보여줌 - 핀란드의 Elisa 네트워크에서는 IPv6 인바운드 TCP 연결이 잘 작동함 Termux와 netcat으로 테스트했으며, IPv4는 CGNAT 뒤에 있지만 IPv6는 직접 연결 가능했음 - “스마트폰이 서버로 동작하지 못하게 하는 이유”가 궁금함 - 개인 기기에서 데이터를 직접 제공할 수 있어야 한다는 건 **자연스러운 권리**라고 생각함 네트워크 용량이 부족하다면 그걸 해결해야 함 IPv6이 보편화되면 사람들은 직접 통신하는 것이 당연해질 것임 - 핫스팟을 사용할 때 클라이언트 PC가 **같은 IPv6 주소**를 받는지 궁금함 - 모바일 기기는 **샌드박스 환경**으로 제한되어 있음 - 네트워크 엔지니어로서 처음 배운 것은 NAT와 보안의 관계였음 IPv4의 **사설 주소(192.168.0.1)** 는 외부에서 접근하기 어렵지만, IPv6의 **글로벌 주소**는 장치 정보를 노출시킬 수 있음 IPv6에는 **Prefix Translation** 같은 대안이 있어, NAT의 장점을 일부 유지하면서도 투명한 접근이 가능함 - IPv4의 사설 주소와 IPv6의 글로벌 주소를 비교하는 건 불공정함 둘 다 내부 혹은 외부 주소로 맞춰야 공정한 비교가 가능함 CGNAT 환경에서는 인바운드 연결이 불가능하므로 IPv6에서도 동일한 방식으로 제한할 수 있음 - 내부 주소가 유출돼도 실제 공격 지점은 **인터넷 경계 방화벽**임 NAT66으로 프리픽스를 숨길 수 있지만, 실질적 보안 이점은 크지 않음 - 192.168.0.1은 너무 쉽게 접근 가능했음 (농담 섞인 말투) - **NAT66**은 “필요악”이지만, 특정 상황에서는 최선의 선택일 수 있음 - 많은 해커들이 NAT와 방화벽의 차이를 혼동함 NAT는 보안을 위한 것이 아니며, **보안은 방화벽이 제공**함 - NAT와 방화벽의 차이를 이해하지만, 현실에서는 둘이 함께 동작함 NAT는 **네임스페이싱**, 방화벽은 **정책 기반 보안**임 네임스페이싱 자체도 공격자가 리소스를 “이름조차 모르게” 만드는 강력한 보안 속성임 IPv6 방화벽은 한 줄의 잘못된 규칙으로 전 세계에 노출될 수 있음 - NAT는 외부 접근을 차단하므로 **실질적인 보안 효과**가 있음 방화벽 없이도 NAT만으로 내부 자원을 보호할 수 있음 NAT는 가정용 네트워크의 공격 표면을 라우터 하나로 줄여줌 - NAT는 대부분의 사용자가 원하는 동작을 **기본값으로 제공**함 반면 방화벽은 기본 설정이 다를 수 있어 오히려 IPv6가 일반 사용자에게는 보안 후퇴로 느껴짐 - 소비자용 NAT는 사실상 **기본 차단 방화벽**과 동일한 동작을 함 UPnP가 NAT의 보안을 깨뜨린다고 주장하는 건, PCP가 방화벽을 깨뜨린다고 말하는 것과 같음 - 대칭 NAT나 CGNAT은 방화벽이 아니지만, 현실적으로는 비슷한 효과를 냄 - NAT의 기본 차단 특성이 IPv4 보안의 장점이라는 주장에 대해 IPv6의 기본 차단 규칙이 동일한 보안 수준을 제공하므로, **구조적 보안 차이**는 없음 - “내재적 보안”이라는 개념은 의미가 없음 IPv4 NAT와 IPv6 기본 차단 규칙은 동일한 불변 조건을 유지함 둘 다 잘못된 설정 시 동일하게 취약해질 수 있음 - NAT가 있다고 방심했다가 **IPv6 방화벽 미설정**으로 SBC가 해킹당한 경험이 있음 NAT가 아닌 IPv6 설정 오류가 원인이었음 - IPv6 주소 공간이 너무 커서 전체 스캔은 불가능한데, 공격자가 어떻게 주소를 알아냈는지 궁금함 - 꽤 **당황스러운 실수**였음 - NAT도 보안 문제를 일으킴 **리플렉션 공격**이나 주소-엔드포인트 분리로 인한 추적 어려움이 생김 과거 AOL이 소수의 egress 주소를 공유해 일부 사용자 차단이 어려웠던 사례가 있음 - [RFC 1631](https://www.rfc-editor.org/rfc/rfc1631.html)에 따르면 NAT는 “보안 제공 옵션을 줄인다”고 명시되어 있음 하지만 시간이 지나면서 NAT가 **보안 신앙(cargo cult)** 처럼 여겨지게 되었음 - ISP와 라우터 설정에 따라 NAT의 효과가 달라짐 NAT는 의도된 보안 기능은 아니지만, **부수적 보안 효과**를 제공함 IPv6에서는 각 장치가 직접 주소를 받으면 기본 차단 방화벽이 필요함 - 대부분의 라우터는 IPv6에서도 기본 차단을 적용하지만, **UPnP** 같은 자동 포트 포워딩 기능이 이를 무력화할 수 있음 [UPnP 명세 링크](https://openconnectivity.org/developer/specifications/upnp-resources/upnp/) - IPv6에서도 인바운드 차단은 IPv4와 동일하게 작동함 - NAT를 꺼도 동일하게 접근 불가능하다면, NAT 자체가 아니라 **라우팅 설정**이 원인일 수 있음 - IPv6 NAT를 사용하는 경우는 드물며, fc00::/7 주소를 NAT하는 건 특이한 사례임 - ISP가 단 하나의 IPv6 주소만 제공하는 건 **비정상적 구성**임. 최소 /56은 제공해야 함 - NAT가 보안의 근거라고 주장하는 사람은 네트워크를 잘 모른다는 말에 - “그건 과한 일반화”라며, NAT가 보안이 될 수는 없지만 완전히 무시할 것도 아님 - 자신이 IPv6 전문가라며, 2008년부터 IPv6 운영 경험이 있다고 밝힘 당시 **프라이버시 주소 누적 문제**로 SIP 서버가 실패했던 사례를 공유함 관련 토론은 [Reddit VOIP 스레드](https://www.reddit.com/r/VOIP/comments/131ex1x/ipv6_sip_trunks/)에서도 여전히 유효함 - NAT가 인바운드 트래픽을 드롭하지 않는다는 주장에 대해 NAT는 단순히 주소 변환만 수행하며, **패킷을 드롭하지 않음** - 하지만 라우터 설정에 따라 egress 인터페이스에서 들어오는 트래픽을 **명시적으로 차단**하는 경우가 많음 - NAT가 패킷을 드롭하지 않더라도, 목적지 IP가 라우터 자신이라면 결국 **라우팅되지 않음** 이 피드백을 반영해 글을 수정했다고 함