IPv6 전환 기술

이중 스택 구현 방식은 네트워크 장비와 호스트가 IPv4와 IPv6 프로토콜 스택을 동시에 운영하는 것을 핵심으로 한다. 이는 운영체제의 네트워크 계층에 두 개의 독립적인 프로토콜 스택이 존재함을 의미한다. 장비는 수신된 패킷의 IP 버전 헤더(IPv4는 0x45, IPv6는 0x60)를 확인하여 해당 프로토콜 스택으로 패킷을 전달한다. 호스트는 DNS 질의를 통해 대상의 AAAA 레코드(IPv6)와 A 레코드(IPv4)를 모두 조회하며, 일반적으로 Happy Eyeballs와 같은 알고리즘을 사용하여 응답이 빠른 주소를 우선적으로 사용한다.

구체적인 구현은 네트워크 계층부터 상위 계층까지 적용된다. 네트워크 인터페이스는 하나의 물리적 포트에 대해 IPv4 주소와 IPv6 주소를 모두 할당받는다. 라우팅 테이블도 IPv4용과 IPv6용으로 분리되어 구성되며, 각 프로토콜에 맞는 라우팅 프로토콜(예: OSPFv2/OSPFv3, BGP-4/BGP-4+)이 독립적으로 운영된다. 전송 계층(TCP/UDP)과 소켓 API는 이중 스택을 지원하도록 확장되어, 애플리케이션이 특정 IP 버전을 명시하거나 시스템이 자동으로 선택할 수 있게 한다.

주요 운영체제와 네트워크 장비는 이중 스택을 기본적으로 지원한다. 구현 시 고려사항은 다음과 같다.

이 방식은 네트워크 관리자가 두 프로토콜에 대한 별도의 구성, 모니터링, 보안 정책을 수립하고 유지관리해야 함을 의미한다. 두 스택이 완전히 독립적으로 동작하기 때문에, 한 스택의 문제가 다른 스택에 직접적인 영향을 미치지 않는다는 장점이 있다.

이중 스택 방식의 가장 큰 장점은 네트워크 내부와 외부에서 IPv4와 IPv6 트래픽을 모두 네이티브(native)로 처리할 수 있다는 점이다. 이는 두 프로토콜을 완전히 지원하는 환경을 제공하므로, 애플리케이션의 수정 없이도 두 주소 체계 모두에서 최적의 성능과 기능을 활용할 수 있다. 또한, 네트워크 관리자가 두 프로토콜을 독립적으로 구성하고 관리할 수 있어, 전환 과정에서 유연성을 확보할 수 있다.

그러나 이 방식은 상당한 운영 부담을 동반한다. 네트워크 장비, 서버, 클라이언트 등 모든 요소가 두 개의 독립적인 프로토콜 스택을 실행해야 하므로, 관리 복잡도가 증가하고 리소스(메모리, CPU, 구성 관리) 소모가 커진다. 특히, DNS 관리가 복잡해져 A 레코드(IPv4)와 AAAA 레코드(IPv6)를 모두 정확하게 운영해야 한다.

장기적인 관점에서, 이중 스택은 완전한 IPv6 단일 스택으로의 전환을 위한 중간 단계로 간주된다. 따라서 조직은 궁극적으로 IPv4 스택을 제거하는 또 다른 전환 계획을 수립해야 한다는 점이 숨겨진 과제이다. 이는 단순히 IPv6 주소를 추가하는 것 이상의 지속적인 관리 노력과 비용을 의미한다.

6to4 터널링은 IPv6 네트워크를 IPv4 인터넷 인프라를 통해 연결하기 위한 자동 터널링 메커니즘이다. IETF의 RFC 3056에 표준으로 정의되어 있으며, 공인 IPv4 주소를 사용하여 자동으로 IPv6 48비트 프리픽스를 생성하는 것이 특징이다. 이 기술은 전용 터널 브로커 서버 없이도 IPv6 네트워크 간 통신을 가능하게 하여 초기 IPv6 도입 단계에서 널리 사용되었다.

6to4는 IPv4 주소를 IPv6 주소에 임베딩하는 방식으로 작동한다. 사용자는 자신의 공인 IPv4 주소(예: 192.0.2.1)를 16진수로 변환(0xC0000201)하여 2002:C000:0201::/48과 같은 IPv6 프리픽스를 자동으로 얻게 된다. 이 프리픽스는 해당 IPv4 주소에 고유하게 할당된다. 이후, IPv6 패킷은 IPv4 패킷 안에 캡슐화되어 IPv4 네트워크를 통해 전송되며, 목적지 6to4 라우터에서 다시 IPv6 패킷으로 역캡슐화된다. 이 과정에서 모든 6to4 라우터는 특수 애니캐스트 주소인 192.88.99.1을 릴레이 라우터로 사용할 수 있다.

이 기술의 주요 장점은 별도의 구성 없이 자동 터널 설정이 가능하고, IPv4 주소를 활용해 IPv6 주소 공간을 즉시 제공한다는 점이다. 그러나 단점도 명확하다. 성능과 신뢰성이 공용 릴레이 라우터(192.88.99.1)에 의존하며, 해당 릴레이의 성능 저하나 중단 시 전체 연결에 영향을 미친다. 또한, NAT 환경 뒤에 있는 사설 IPv4 주소를 사용하는 호스트나 네트워크에서는 작동하지 않는다는 근본적인 한계가 있다. 이러한 단점과 보안 상의 고려사항으로 인해, 6to4 터널링은 점차 사용이 줄어들고 Teredo 터널링이나 이중 스택 같은 다른 전환 기술로 대체되는 추세이다.

Teredo 터널링은 IPv6 네트워크와 IPv4 네트워크 사이의 통신을 가능하게 하는 자동 터널링 기술 중 하나이다. 특히, IPv4 NAT 환경 뒤에 있는 호스트가 IPv6 인터넷에 연결할 수 있도록 설계되었다. 이 기술은 마이크로소프트에서 개발했으며, 이후 IETF에 의해 표준화되었다[3]. Teredo의 주요 목적은 IPv4 주소 고갈 문제를 해결하기 위한 IPv6의 전 세계적 배포가 완료될 때까지, NAT 뒤에 있는 최종 사용자 장치들도 IPv6 연결성을 확보할 수 있도록 하는 임시 전환 메커니즘을 제공하는 것이다.

Teredo는 UDP 포트 3544를 사용하여 IPv4 네트워크를 통해 IPv6 패킷을 캡슐화한다. 이 과정에는 Teredo 서버, Teredo 릴레이, Teredo 클라이언트라는 여러 구성 요소가 관여한다. Teredo 클라이언트는 자신의 공용 IPv4 주소와 NAT 유형을 확인하기 위해 Teredo 서버와 통신한다. 그 후, 다른 IPv6 네트워크(예: 네이티브 IPv6 호스트)와 통신하기 위해 Teredo 릴레이를 경유한다. 이 메커니즘은 복잡한 NAT 트래버설 문제를 해결하도록 설계되었다.

Teredo 터널링의 장단점은 다음과 같이 정리할 수 있다.

마이크로소프트 윈도우 운영 체제에서는 오랫동안 Teredo가 기본적으로 활성화되어 있었으나, IPv6의 보급이 확대되고 이중 스택 등의 더 나은 기술이 일반화되면서 그 중요성은 감소했다. 최신 윈도우 버전에서는 기본적으로 비활성화되어 있는 경우가 많다. Teredo는 IPv4에서 IPv6로의 장기적인 전환 과정에서 특정 환경의 연결성 격차를 메우는 과도기적 솔루션으로 평가된다.

ISATAP(Intra-Site Automatic Tunnel Addressing Protocol)는 IPv4 네트워크 인프라를 통해 IPv6 패킷을 자동으로 터널링하는 기술이다. 주로 기업 내부 네트워크나 캠퍼스 네트워크와 같은 단일 사이트 내에서 IPv6 호스트와 라우터를 연결하는 데 사용된다. ISATAP는 IPv6 주소를 구성하는 데 IPv4 주소를 인터페이스 식별자로 활용하여, 기존 IPv4 네트워크 상에서 논리적인 IPv6 링크를 생성한다.

ISATAP 호스트는 특별한 형식의 IPv6 주소를 사용한다. 이 주소의 64비트 접두사는 일반적으로 사이트 내 ISATAP 라우터로부터 얻으며, 나머지 64비트 인터페이스 식별자는 ::0:5efe: 뒤에 호스트의 IPv4 주소(16진수)를 붙여 구성한다[5]. 이렇게 생성된 주소를 통해 IPv4 네트워크가 가상의 IPv6 링크로 동작하게 된다.

구성은 비교적 간단하며, 호스트가 ISATAP 라우터의 IPv4 주소만 알면 자동으로 터널 인터페이스를 구성하고 IPv6 주소를 할당받을 수 있다. 이는 수동 설정이 필요한 6to4 터널링과 달리, 대규모 내부 네트워크에서 IPv6를 점진적으로 도입하는 데 유리하다. 그러나 이 기술은 기본적으로 IPv4 네트워크 내부에서만 동작하도록 설계되었으며, 공용 IPv6 인터넷과의 직접적인 통신을 위해서는 ISATAP 라우터가 이중 스택 또는 다른 터널링 기술을 통해 외부와 연결되어야 한다.

NAT64는 IPv4 주소를 IPv6 주소로, 또는 그 반대로 변환하는 네트워크 주소 변환 기술이다. 특히, IPv6 네트워크에 위치한 클라이언트가 IPv4 인터넷의 서버(예: 웹사이트)에 접근할 수 있도록 하는 데 주로 사용된다. 이 기술은 상태 저장 변환 방식을 사용하여 IPv6 패킷과 IPv4 패킷 간의 매핑 정보를 유지하고 변환을 수행한다.

DNS64는 NAT64와 함께 동작하는 필수 보완 기술이다. DNS64 서버는 IPv6 전용 클라이언트의 도메인 이름 시스템 질의를 처리할 때, 만약 대상 도메인에 AAAA 레코드(IPv6 주소)만 존재하거나 전혀 존재하지 않으면, 해당 도메인의 A 레코드(IPv4 주소)를 조회한다. A 레코드에서 얻은 IPv4 주소를 사전에 정의된 특수 IPv6 프리픽스(일반적으로 64:ff9b::/96)와 결합하여 합성된 IPv6 주소를 생성하여 클라이언트에 응답한다[7]. 클라이언트는 이 합성 주소로 패킷을 전송하면, 네트워크 경로상의 NAT64 게이트웨이가 패킷을 가로채어 IPv4 주소로 변환하여 최종 목적지에 전달한다.

NAT64/DNS64 구축 방식은 주로 두 가지로 나뉜다.

이 기술의 주요 장점은 IPv6 네트워크를 우선적으로 구축하고 배포할 수 있게 하며, IPv4 인터넷 자원에 대한 접근성을 유지한다는 점이다. 따라서 IPv4 주소 고갈 문제를 우회하면서 점진적인 전환을 가능하게 한다. 그러나 단점으로는, 애플리케이션 계층에서 IPv4 주소를 임베드하는 일부 프로토케이션이나 IPsec과 같은 엔드투엔드 보안 프로토콜과의 호환성 문제가 발생할 수 있다. 또한, 모든 트래픽이 NAT64 게이트웨이를 경유해야 하므로 해당 장비의 성능과 가용성이 전체 네트워크 성능의 병목 지점이 될 위험이 있다.

SIIT(Stateless IP/ICMP Translation)는 상태를 유지하지 않는(Stateless) 방식의 IPv4와 IPv6 프로토콜 변환 기술이다. 이름 그대로 변환 과정에서 세션 상태나 매핑 테이블을 저장하지 않고, 패킷 헤더 변환 규칙에 따라 실시간으로 변환을 수행한다. 이 방식은 RFC 6145에 표준으로 정의되어 있으며, 주로 IPv6 네트워크에 위치한 호스트가 IPv4 인터넷의 서버와 통신할 때 사용된다.

SIIT의 핵심은 IPv6 주소 내에 IPv4 주소를 임베딩하는 특별한 주소 형식을 사용하는 것이다. 대표적으로 'IPv4-translatable IPv6 address'와 'IPv4-converted IPv6 address'가 있다. 전자는 IPv6 호스트에게 할당되며, 후자는 IPv4 호스트를 나타내는 IPv6 주소로 사용된다. 변환기는 이 두 주소 형식 간의 변환 규칙에 따라 IP 헤더와 ICMP 헤더를 실시간으로 변경한다. 예를 들어, IPv6 호스트에서 IPv4 서버로 가는 패킷은 목적지 IPv6 주소에서 IPv4 주소를 추출해 IPv4 헤더로 변환하고, 반대 방향의 패킷은 출발지 IPv4 주소를 특정 IPv6 프리픽스와 조합해 IPv6 헤더로 재구성한다.

이 방식은 상태를 유지하지 않아 변환기 장비의 부하가 적고 확장성이 우수하다는 장점이 있다. 또한, DNS 조작이 필요 없는 순수한 네트워크 계층 변환 기술이다. 그러나 단점도 명확한데, 양방향 통신을 위해 IPv6 호스트가 반드시 특별한 IPv6 주소(IPv4-translatable)를 가져야 하며, IPv4 주소 풀을 소모한다는 점이다. 또한, IPsec이나 FTP ALG 등 상위 계층 프로토콜에 내장된 IP 주소 정보를 처리하는 데 한계가 있을 수 있다.

따라서 SIIT는 주로 순수 IPv6 네트워크를 구축한 조직 내부에서 IPv4 인터넷 리소스에 대한 접근을 제공하는 'IPv6-Only' 네트워크 환경에서 활용된다. 이때 DNS64와 결합된 NAT64가 종종 최종 사용자 솔루션으로 채택되는 반면, SIIT는 보다 근본적인 프로토콜 변환 메커니즘으로서, 또는 클라우드 데이터센터와 같은 제어된 환경에서의 백엔드 변환 기술로 사용된다.

IPv6로의 전환은 네트워크의 규모와 복잡성에 따라 단계적으로 이루어지는 것이 일반적이다. 효과적인 전환을 위해서는 철저한 계획과 평가가 선행되어야 하며, 대부분의 조직은 점진적인 접근 방식을 채택한다. 일반적인 단계적 전환 계획은 다음과 같은 순서로 구성된다.

첫 단계는 준비 및 평가 단계이다. 이 단계에서는 기존 IPv4 네트워크 인벤토리를 정리하고, IPv6를 지원하는 애플리케이션, 서버, 네트워크 장비, 운영 체제를 식별한다. 또한, 인터넷 서비스 제공자(ISP)의 IPv6 지원 현황과 외부 DNS 서비스의 AAAA 레코드 지원 여부를 확인한다. 이 평가를 바탕으로 이중 스택, 터널링, 프로토콜 변환 등 어떤 전환 기술을 어느 부분에 적용할지 초기 전략을 수립한다.

다음은 실험 및 제한적 배포 단계이다. 먼저 개발 또는 테스트 네트워크와 같은 비중요 환경에서 IPv6를 활성화하고, 이중 스택 방식을 적용해 기본적인 연결성을 검증한다. 내부 애플리케이션과 서비스의 IPv6 호환성을 테스트한 후, 일부 공개 서비스(예: 회사 웹사이트, 이메일 서버)에 대해 IPv6 주소를 할당하고 외부에서의 접근성을 점진적으로 개방한다. 이 과정에서 NAT64/DNS64나 6to4 터널링과 같은 기술을 활용해 IPv4-IPv6 간 상호 운용성을 관리할 수 있다.

마지막으로 대규모 배포 및 완전 전환 단계로 진행한다. 핵심 네트워크 인프라와 대부분의 내부 서비스, 공개 서비스에 IPv6를 배포하고, 이중 스택을 주된 구성으로 운영한다. 지속적인 모니터링을 통해 성능과 안정성을 최적화한다. 궁극적으로는 대부분의 트래픽이 IPv6를 통해 처리되도록 한 후, IPv4 지원에 대한 의존도를 점차 낮추는 방향으로 나아간다. 일부 환경에서는 순수 IPv6 네트워크를 구축하고, 남은 IPv4 리소스 접근을 위해 제한된 프로토콜 변환 게이트웨이만 운영하는 최종 상태를 목표로 한다.

IPv6 전환 과정에서 이중 스택이나 터널링, 프로토콜 변환 기술을 도입할 때는 기존 IPv4 네트워크와의 호환성과 성능 영향을 철저히 평가해야 한다. 평가는 실험실 환경과 제한된 실제 네트워크에서의 시범 운영을 통해 이루어지며, 주요 애플리케이션의 정상 동작 여부와 지연 시간, 처리량, 패킷 손실률 등의 성능 지표를 측정한다.

성능 평가는 다양한 시나리오 하에서 진행된다. 예를 들어, NAT64를 통한 IPv6 단말과 IPv4 서버 간의 통신 지연, 터널링 오버헤드로 인한 처리량 감소, 혼합된 트래픽 환경에서의 라우터 CPU 및 메모리 사용률 등을 분석한다. 특히 실시간 통신이나 금융 거래와 같이 낮은 지연과 높은 신뢰성을 요구하는 서비스는 더욱 세심한 검증이 필요하다.

평가 결과는 전환 기술의 선택과 배포 범위를 결정하는 핵심 근거가 된다. 일부 기술은 특정 애플리케이션 프로토콜(예: FTP, SIP)과 호환성 문제를 일으키거나, MTU 탐색 실패로 인한 성능 저하를 초래할 수 있다. 따라서 평가는 일회성이 아닌, 네트워크 구성이나 트래픽 패턴이 변경될 때 지속적으로 수행되어야 한다.