전환 기법 비교
| 기법 | 핵심 아이디어 | 누가 운영하나 | 근거 |
|---|---|---|---|
| 듀얼 스택 | IPv4와 IPv6를 모두 완전 지원 | 호스트·라우터 | RFC 4213 |
| 설정형 터널 | IPv4 종단 주소를 설정으로 지정, IPv4 헤더의 프로토콜 번호 41로 IPv6를 캡슐화 | 양 끝 관리자 | RFC 4213 |
| 6to4 | 사이트의 IPv4 주소를 2002::/16 뒤에 넣어 /48을 자동 생성 | 사이트 자체 | RFC 3056 (애니캐스트 방식은 RFC 7526으로 폐기) |
| 6rd | 6to4와 같은 방식에 통신사 자신의 IPv6 접두사 사용 | 통신사 | RFC 5969 |
| Teredo | IPv4 NAT 뒤의 호스트를 위해 IPv6를 UDP로 캡슐화 | 호스트와 Teredo 서버 | RFC 4380 |
| NAT64 + DNS64 | IPv6 전용 클라이언트가 IPv4 서버에 접속하도록 변환 | 망 운영자 | RFC 6146, 6147 |
방식별로 조금 더 들여다보기
6to4와 6rd: 주소 안에 IPv4 주소를 심는다
RFC 3056에 따르면 6to4는 사이트의 32비트 IPv4 주소를 2002 뒤에 이어 붙여 /48 접두사를 만듭니다. 예를 들어 192.0.2.1이라면 2002:c000:201::/48이 되며, 이 값은 node로 검산했습니다. 이 문서는 6to4를 영구 해법이 아닌 "임시 방편(interim mechanism)"으로 소개합니다. 6rd(RFC 5969)는 같은 틀을 쓰되 2002::/16 대신 통신사가 직접 정한 접두사를 쓰므로, 통신사가 자기 망을 관리하는 환경에서만 쓰도록 규정합니다.
Teredo: NAT 뒤에서도 돌아가도록 UDP로 감싼다
RFC 4380은 하나 이상의 IPv4 NAT 뒤에 있는 노드가 IPv6 연결을 얻게 하는 것이 목적이라고 밝히고, NAT를 잘 통과하는 UDP 패킷의 페이로드로 IPv6 패킷을 나릅니다. 전용 접두사는 2001::/32이고 서버는 UDP 3544번 포트를 씁니다. NAT를 통과해야 한다는 필요 때문에 구조가 복잡해졌다는 점이, 이후 전환의 중심이 터널이 아니라 듀얼 스택과 변환으로 옮겨 간 배경의 하나로 볼 수 있습니다(이 해석은 필자의 정리입니다).
NAT64와 DNS64: IPv6 전용 망에서 IPv4 서버로
RFC 6146의 상태 유지형 NAT64는 IPv6 전용 클라이언트가 IPv4 서버와 TCP, UDP, ICMP로 통신하게 하며, 별도 상태가 없다면 세션을 먼저 여는 쪽은 IPv6 쪽이어야 합니다. DNS64(RFC 6147)는 IPv4 주소만 있는 이름에 대해 A 레코드로부터 합성한 AAAA 레코드를 돌려줍니다. 합성 시 쓰는 잘 알려진 접두사 64:ff9b::/96에 IPv4 주소를 이어 붙이면 192.0.2.1은 64:ff9b::c000:201이 됩니다. DNS64는 응답을 바꾸는 장치이므로 DNSSEC 검증과 부딪힐 수 있다는 점도 RFC가 직접 언급합니다.
실제로 있었던 일과 가상 시나리오
사례 1. 6to4 애니캐스트의 폐기 권고(2015)
IETF는 2015년 5월 BCP 196으로 지정된 RFC 7526을 발표해, RFC 3068의 6to4 애니캐스트 방식(IPv4 애니캐스트 주소 192.88.99.1)이 더 이상 쓸모 있는 서비스가 아니라고 선언했습니다. 이 문서는 RFC 3068을 폐지해 Historic으로 옮기도록 요청하고 6to4 제공자 관리형 터널(RFC 6732)도 함께 폐기하며, 192.88.99.0/24는 향후 IETF 표준화 과정 없이 다른 용도로 재배정하지 못하게 합니다. 반면 2002::/16 접두사와 RFC 3056의 기본 6to4 유니캐스트 방식은 폐기하지 않았습니다. 새 구현은 애니캐스트 6to4를 넣지 않아야 하고, 넣더라도 기본값은 비활성이어야 합니다. 배울 점은 "과도기 기술은 과도기 이후 정리된다"는 것, 그리고 폐기 범위가 기술 전체가 아니라 특정 방식에 한정될 수 있다는 점입니다.
사례 2. 듀얼 스택에서 느려지지 않게 하는 Happy Eyeballs
듀얼 스택 환경에서는 한 이름에 IPv4와 IPv6 주소가 함께 있을 수 있고, 한쪽 경로가 고장 났을 때 사용자가 오래 기다리는 문제가 생깁니다. RFC 8305(Happy Eyeballs 버전 2)는 여러 연결을 병렬로 시도하면 더 빨리 연결할 가능성이 있다는 점을 바탕으로, A 응답을 받은 뒤 AAAA 응답을 기다리는 해결 지연(Resolution Delay)으로 50밀리초, 연결 시도 사이의 기본 지연으로 250밀리초를 권장 값으로 제시합니다. 이 덕분에 대부분의 사용자는 어느 쪽 프로토콜로 접속했는지 의식하지 못합니다.
가상 시나리오. IPv6 전용 모바일 망에서 IPv4 전용 사이트에 접속 (실제 사건이 아님)
가상의 통신사가 IPv6 전용 망에 NAT64와 DNS64를 운영한다고 합시다. 휴대폰이 IPv4 주소만 가진 사이트 이름(서버 192.0.2.1)을 조회하면 DNS64가 64:ff9b::c000:201 같은 합성 주소를 돌려주고, 휴대폰은 이 IPv6 주소로 패킷을 보냅니다. NAT64 장비가 이를 IPv4 192.0.2.1로 변환해 전달하고 응답을 되돌립니다. 반대로 이 사이트가 IPv6 주소를 직접 가지고 있다면 변환 없이 접속합니다.
집에서 해 볼 점검 목록
- 운영체제의 네트워크 정보에서 IPv6 주소가 있는지 확인하고, 있다면 2로 시작하는 글로벌 주소인지 fe80::만 있는지 봅니다. fe80::만 있다면 외부 IPv6 연결은 없는 상태입니다.
- 특정 사이트에서만 느리거나 끊기면 공유기의 IPv6 사용을 껐다 켜 보고 증상이 바뀌는지 비교합니다.
- 사설 서버를 운영한다면 A 레코드뿐 아니라 AAAA 레코드와 방화벽 규칙이 IPv6에도 있는지 점검합니다. IPv6 규칙이 비어 있으면 열려 있을 수도, 막혀 있을 수도 있어 직접 확인해야 합니다.
흔한 오해와 정정
- 오해: 6to4가 폐기되어 2002:로 시작하는 주소는 쓸 수 없다. 실제: RFC 7526은 애니캐스트 방식을 폐기했고 2002::/16 접두사는 폐기하지 않는다고 명시합니다.
- 오해: NAT64를 쓰면 IPv4 쪽에서 IPv6 호스트로 자유롭게 먼저 접속할 수 있다. 실제: RFC 6146은 기존 매핑이나 정적 설정이 없으면 IPv6 쪽이 먼저 시작해야 한다고 설명합니다.
- 오해: 터널링이 가장 좋은 전환 방법이다. 실제: RFC 4213이 다루는 두 방식은 듀얼 스택과 설정형 터널이며, 터널은 경로 사정으로 성능·관리 부담이 생길 수 있어 필요할 때 쓰는 보조 수단입니다.
- 오해: IPv6를 켜면 IPv4가 꺼진다. 실제: 듀얼 스택에서는 두 프로토콜이 나란히 동작합니다.
한계와 더 알아볼 점
이 글은 RFC로 확인되는 기법의 원리를 다루며, IPv6 보급률 같은 시점에 따라 달라지는 통계는 일부러 싣지 않았습니다. 최신 보급률은 Google IPv6 통계처럼 갱신되는 공개 자료에서 확인 시점과 함께 보시기 바랍니다. 464XLAT, DS-Lite 같은 그 밖의 기법과 각 기법이 오늘날 실제로 얼마나 쓰이는지는 이 글의 범위를 벗어납니다. 또한 Teredo 등 개별 기법의 현재 지원 상태는 운영체제와 제조사 문서를 확인하세요.
자주 묻는 질문
내 인터넷이 IPv6를 쓰고 있는지 어떻게 알 수 있나요?
다양한 온라인 IPv6 테스트 사이트에 접속하면 현재 연결이 IPv4로 되고 있는지, IPv6로 되고 있는지 확인할 수 있습니다. 다만 대부분의 듀얼스택 환경에서는 특별한 조치 없이도 상황에 맞게 자동으로 전환되어 동작합니다.
IPv6로 완전히 전환되면 IPv4는 아예 못 쓰게 되나요?
당장 그렇게 되지는 않습니다. 오래된 장비와 서비스가 여전히 IPv4를 사용하고 있어, 상당 기간은 듀얼스택처럼 두 방식이 함께 쓰이는 과도기가 이어질 것으로 예상됩니다.
NAT64와 일반 NAT(IPv4 공유기)는 어떻게 다른가요?
공유기의 NAT는 IPv4 사설 주소를 공인 주소로 바꾸는 IPv4끼리의 변환입니다. NAT64는 IPv6 패킷을 IPv4 패킷으로 바꿔 서로 다른 프로토콜 사이를 이어 준다는 점이 다릅니다.
듀얼 스택이면 보안 설정도 두 번 해야 하나요?
두 프로토콜은 별개로 동작하므로 방화벽 규칙도 IPv4와 IPv6에 각각 있는지 확인하는 것이 안전합니다. 한쪽만 설정하면 다른 쪽 경로가 의도치 않게 열려 있을 수 있습니다.
DNS64는 모든 사이트에서 문제없이 동작하나요?
그렇지 않습니다. DNSSEC로 검증하는 클라이언트는 합성된 응답을 위조로 판단할 수 있고, IPv4 주소를 직접 입력하는 애플리케이션은 DNS64를 거치지 않아 영향을 받을 수 있습니다. 이런 이유로 환경에 따라 추가 조치가 필요합니다.