IPv6/IPv4 변환 기술 및 동향

박정수* 신명기* 김용운* 이승윤* 김용진**

본 고에서는 인터넷이 비약적으로 성장함에 따라, 심각하게 대두되고 있는 주소고갈 문제 등을 해결하기 위한 대안인 차세대 인터넷 프로토콜 IPv6 기반 네트워크로 진화하기 위한 전환 단계에서 필수적으로 요구되는 변환 기술에 대해 소개한다. ▧

I. 서 론

인터넷은 컴퓨터가 보편화됨에 따라 일상 생활에 깊이 파고들고 있고, 현재 급속하게 사용자와 호스트가 늘어나는 현실이다[1]. 이처럼 전세계적으로 기하급수적으로 늘어나는 인터넷 주소를 감안할 때, 32비트의 IPv4체계로는 계속적으로 늘고 있는 주소 요구를 충족시킬 수 없으며, 2013년경 IPv4 주소가 고갈될 것이라고 IETF(Internet Engineering Task Force)에서는 예측하고 있다[2]. 그러나, 현재의 무선인터넷 등의 새로운 서비스 분야의 성장추세로 보면 이보다도 더욱더 앞당겨질 것이다. 이와 같은 주소고갈 문제와 멀티캐스트, 보안 기술 등 새로운 기술을 접목시키는데 발생하는 IPv4의 구조상 어려움 등을 해결하기 위해 IPv6 프로토콜이 개발되었으며, 연동 및 시험을 목적으로 6Bone이라는 가상망을 Bob Fink등에 의해 1996년부터 구축하여 현재까지 운영되고 있다.

본 고에서는 IPv6 기본적인 특징과 기능에 대해서는 다루지 않고, 순수한 IPv6망으로 구축된 네트워크로 진화하기 위한 전환 단계에서 요구되는 변환 기술을 소개하고자 한다. 현재 인터넷의 IPv4 노드들을 한꺼번에 IPv6로 대치하는 것이 불가능한 환경 하에서, 변환 기술은 IPv4와 IPv6를 함께 사용하면서 점진적으로 IPv6 네트워크 환경으로 넘어가기 위해 필수적으로 요구된다고 하겠다. 이 변환 기술은 기술적인 측면에서 3가지로 분류할 수 있다[3, 4].

- 듀얼 호스트 기술

- 터널링 및 캡슐화 기술

- IPv4/IPv6 변환 기술

먼저, 듀얼 호스트 기술은 기본적으로 IPv4 네트워크 환경 하에서 IPv4와 IPv6를 함께 듀얼 스택 구조로 노드를 구현하는 것을 의미한다. 즉, IPv6 스택을 갖춘 노드에 IPv4 스택도 함께 갖추게끔 하여 기존 IPv4 노드들과의 통신뿐만 아니라, IPv4의 도움을 받아 IPv6 통신도 가능하게 하고자 하는 것이다. 이때, IPv4/IPv6 듀얼 스택 구조를 취하는 노드들은 정식 IPv4 주소를 사용하여 IPv4 노드와 통신하고, IPv4 주소를 그대로 포함한 IPv4-compatible IPv6 주소로 IPv6 노드와 통신을 하게 된다.

이와 같은 듀얼 호스트 기술은 정식 IPv4 주소를 사용해야 하므로, 주소고갈 문제를 해결하지 못하기 때문에 권장되는 방식은 아니지만, 다음 장에서 살펴볼 기술들을 위한 기본 기술이며 쉽게 구축할 수 있는 장점을 가지고 있다.

II. 터널링과 캡슐화 기술

터널링은IPv6로 통신이 가능한 두 지점간에 통신을 위해 IPv6 패킷을 IPv4 패킷 속에 포함시켜서 IPv4망상으로 전달한다. 여기서, 패킷의 데이터 영역에 포함시켜서 전송하는 것을 캡슐화라고 한다. 물론, IPv6 패킷에 IPv4 패킷을 실어서 보내는 경우도 터널링 기술이지만, 본 고에서는 전자의 경우에 대해서 주로 기술하고자 한다.

이와 같은 터널링 기술은 터널링의 종단 노드의 특성, 즉 듀얼 스택의 유무에 따라, 터널링 기법을 분류할 수 있다. 중간에 IPv4망으로 분리되어 있는 순수 IPv6망상의 호스트간에 통신의 경우, IPv6망의 경계 라우터에 듀얼 스택을 구축하는 것이 비용이나 시간 측면에서 유리하다고 할 수 있다. 그러므로, 호스트에서 라우터로는 캡슐화되지 않은 패킷들이 전송되고, 듀얼 스택을 갖춘 IPv6망의 경계 라우터간에 터널링 기법이 사용되고 있다. 이때, 발신 호스트에서 생성된 IPv6 패킷의 목적지 영역에는 해당 라우터의 주소를 명시하지 않고, 최종 목적지 호스트 주소를 포함한다. 그러므로, 최종 호스트가 포함된 IPv6망의 경계 라우터 주소를 알 수 없는 상태이다. 이를 해결하기 위해, 실제적인 통신이 일어나기 이전에 터널링 양 종단의 라우터 주소를 미리 알고 있어야 한다. 즉, 발신자 호스트는 최종 목적지 호스트로 패킷을 보내기 위해 자신이 속한 망의 어떤 듀얼 스택 경계 라우터로 보내야 할 지를 알아야 하며, 이를 수신한 라우터는 최종 목적지 호스트가 속한 IPv6망의 경계 라우터가 무엇인 지를 알고 있어야 터널링을 시작할 수 있다. 이와 같은 방식을 설정 터널링(configured tunneling)이라 한다.

위의 방식의 호스트들은 주로 순수한 IPv6 주소를 사용하지만, 듀얼 스택 구조를 가진 호스트는 IPv4 주소를 그대로 내포한 IPv4-compatible IPv6 주소를 이용한다. 이때 경계 라우터들은 호스트 IPv4-compatible IPv6 주소로부터 쉽게 IPv4 주소를 얻을 수 있고, 반대로 IPv4 주소에서 쉽게 IPv4-compatible IPv6 주소를 구성할 수 있다. 그러므로, 사전에 설정 과정이 필요하지 않기 때문에 자동 터널링(automatic tunneling)이라 한다[5~7].

요약하면, 터널링 기법은 라우터간 또는 호스트간에 터널을 설정하는 경우로 분류할 수 있다. 라우터간의 경우는 다시 설정 터널링과 자동 터널링으로 구분한다. 이 자동 터널링을 적용한 방식이 6to4나 DSTM(Dual Stack Transition Mechanism) 방식이다. 이때, 6to4 방식은 자동 터널링을 가능하도록 특별한 주소 형식을 가진 순수 IPv6 호스트를 이용하고, DSTM 방식은 이를 지원하는 특별한 서버들과 듀얼 스택 호스트를 이용한다. 호스트간의 터널링은 주로 자동 터널링을 이용하며, 6over4나 Tunnel Broker 방식이 있다. 이 두 가지 방식은 모두 듀얼 스택 호스트여야만 한다. <표 1>은 일반적인 듀얼 스택을 가진 호스트와 호스트간의 자동 터널링과 라우터간의 설정 터널링의 차이를 나타낸다.

1. 6over4

직접적으로 IPv6 라우터와 물리적인 연결을 가지지 않고 격리된 IPv6 호스트간에 IPv4 멀티캐스트 망을 하나의 가상 로컬 링크처럼 사용해서 통신하고자 하는 요구사항이 발생했다. 이 요구사항을 만족시키기 위한 개발된 6over4 기법은 라우터에서 이용되는 메시지들에 발신지/목적지 링크 주소 옵션 영역에 관련 정보를 명시해서 IPv4 멀티캐스트를 이용해서 공지하게 된다. 자세한 처리 과정을 살펴보면 다음과 같다. 먼저, IPv4 멀티캐스트 연결은 이미 설정되어 있으며, IPv6 호스트와 라우터는 듀얼 스택을 가진다.

- 라우터는 멀티캐스트용 IPv4 주소를 발신지/목적지 링크 계층 주소 옵션 영역에 실어서 알린다.

- IPv4/IPv6 호스트는 IPv6 패킷을 생성한다. 먼저, 자신의 IPv4 주소와 site-local IPv6 prefix를 이용해 발신지 IPv6 주소를 자동 설정하고(예, FE80::IPv4addressOfSource) 라우터에서 받은 주소를 이용해서 멀티캐스트용 목적지 주소를 설정한다(예, FF80::IPv4 addressofTarget).

- 이렇게 생성된 IPv6 패킷은 IPv4에 캡슐화되어 IPv4망으로 멀티캐스트된다. 이때, 사용되는 멀티캐스트 주소 영역은 239.192.0.0/16이며, 마지막 두 바이트는 IPv6 멀티캐스트 주소의 마지막 두 바이트 값으로 채워진다. 또한, 이 주소 영역은 이 기능을 위해서만 사용되도록 IANA에서 정의해야 한다.

또한, IPv4 멀티캐스망을 통해 전달되는 IPv6 NDP(Neighbor Discovery Protocol)의 NS (Neighbor Solicitation)과 NA(Neighbor Advertisement) 메시지를 통해 획득된 IPv6 호스트의 유니케스트 주소를 통해서도 통신이 가능하게 된다. 이 기법은 자동 설정을 이용하므로 비교적 간단하게 적용할 수 있으나, 듀얼 스택 호스트 기법의 기본 문제점을 그대로 가지고 있다. 현재, 기법은 표준화된 상태이지만 널리 사용되고 있지는 않다[8].

2. 6to4

순수 IPv4망에 연결된 IPv6 망상의 호스트들간에 최소한의 수동적인 설정만으로 통신을 가능케 하는 6to4 기법은 고유한 IPv4 주소를 바탕으로 IPv4-compatible IPv6 주소나 설정 터널링기법을 사용하지 않고 각 호스트 마다 고유한 IPv6 주소를 할당하는 메커니즘이다. 이 메커니즘이 적용되기 위해, 하나의 IPv6망마다 적어도 한 개 이상의 고유한 IPv4 주소를 가지고 있어야 하며, 6to4를 위한 DNS와 호스트에 특별한 송신 및 선택 규칙을 가져야 한다. DNS가 정식 IPv6 주소와 6to4 주소를 처리할 수 있어야 한다. 또한, DNS에서 전달된 여러 개의 목적지 주소 정보 중에 6to4 주소를 포함한 쿼리 응답을 받은 호스트는 발신자와 목적지 주소로 6to4 주소 형태를 선택해야 한다. 이를 주소 선택 알고리즘(address selection algorithm)이라 한다. 또한, 라우터는 듀얼 스택 구조, 송신과 디캡슐화 규칙, 여러 가지 라우팅 프로토콜을 지원해야 한다.

앞에서 설명된 것처럼, 6to4 사이트는 최소 하나의 고유한 IPv4 주소를 가지고 있어야 한다. 대체적으로, 이 IPv4 주소는 경계 라우터의 IPv4 주소일 것이다(이하, V4ADDR이라 함). 이 주소를 이용해서, 라우터는 6to4 주소 서비스에 사용될 prefix를 자신이 관리하는 사이트로 공지하게 된다. 이 때 prefix는 IANA에서 공식적으로 6to4를 위해 정의한 2002::/16 prefix에 자신의 IPv4 주소를 합친 2002:V4ADDR::/48을 이용한다. 이를 이용하면, IPv6 주소에서 경계 라우터의 IPv4 주소를 쉽게 추출해낼 수 있기 때문에 쉽게 구현이 가능하며, 널리 이용될 것으로 전망된다. 현재 이 기법은 표준화가 진행중이며, 마이크로소프트사 등에서 구현되고 있다. <표 2>는 앞에서 설명한 6over4와 6to4 방식의 비교이다[9].

 

3. DSTM(Dual Stack Transition Mechanism)

IPv6로의 초기 진화과정에서 대부분을 차지하고 있는 IPv4망과 통신을 위해 가장 큰 요구 사항은 IPv6 망 내에서도 IPv4 응용들을 사용할 수 있도록 해야 한다는 것이다. 새롭게 구축될 IPv6 노드들은 IPv4/IPv6 듀얼 스택 형태로 구성되어서 순수 IPv4 호스트들과도 통신이 가능해야 한다는 것에는 다른 방식 개발자들과 견해를 같이 하지만, 차별화된 DSTM 개발자들의 견해는 변환 메커니즘을 사용하기를 원하지 않는다는 것이다. 즉, 종단간의 통신에서 중간 노드에 변환 기능을 두지 않겠다는 것이다.

DSTM은 IPv4 스택을 가진 IPv6 노드들에게 임시로 글로벌 IPv4 주소를 할당하기 위해 필요한 메커니즘들의 집합이라 할 수 있다. 이를 위해 DSTM은 IPv6 호스트에서 IPv4 주소 요구가 있을 때만 IPv4 주소를 동적으로 할당하고, IPv6 호스트상의 IPv4 응용을 변경하지 않고 사용할 수 있어야 하며, IPv6 패킷에 IPv4 패킷을 캡슐화해서 실어 보내는 능동 터널링 방식을 제공해야 한다. 앞 절에서 언급한 기본적인 듀얼 스택 구조는 IPv4와 IPv6 주소를 동시에 가져야 하기 때문에 IPv4 주소 문제를 해결할 수 없는 단기 진화 전략이라 할 수 있지만, DSTM은 동적으로 IPv4 주소를 할당하므로 진보된 방식이라 할 수 있다. 이와 같은 DSTM은 기본적으로 AIIH (Assignment of IPv4 Global address to IPv6 Hosts) 서버, DNS 및 DTI(Dynamic Tunnel Interface) 기능을 지원해야 한다. 이와 같은 메커니즘을 포함한 망을 DSTM 도메인이라 부른다.

DSTM은 DNS 서버와 연계된 DHCPv6 서버를 가지고 있어야 한다. 이 서버를 AIIH 서버라 부르며, IPv6 호스트에 DHCPv6를 사용해서 글로벌 IPv4 주소를 할당할 수 있게 한다. 다시 말해, 특정 호스트의 IPv6 주소와 새롭게 할당된 IPv4 주소의 매핑 관계를 유지하는 서버라 할 수 있다. 또한, 모든 DSTM 도메인상의 IPv6 호스트들은 DTI라 불리는 IPv4 인터페이스를 가져야 한다. 이 인터페이스는 IPv4 패킷을 IPv6 패킷 내에 캡슐화하기 위해 사용되며, 캡슐화된 IPv6 패킷을 일반적인 IPv6 패킷으로부터 쉽게 구별할 수 있게 하기 위함이다.

일반적으로 DSTM 방식은 매우 복잡한 것으로 알려지고 있는데, IPv4 주소와 IPv6 주소를 동시에 확인할 수 있도록 DNS를 확장해야 하고, 아직까지 연구가 진행되고 있는 DNS의 동적 갱신(Dynamic Update)도 지원해야 한다. 또한, 목적지 IPv4 주소 쿼리에 대한 응답과 함께, 최종 목적지까지 제대로 도착할 수 있도록 중간 목적지 TEP(Tunnel End Point) 주소도 알려 줄 수 있어야 한다. 다음은 DSTM 모델이 기본적으로 고려해야 할 사항들이다[10, 11].

- DSTM 도메인은 인트라넷 이내여야 한다.

- DSTM 도메인 내의 IPv6 노드는 순수 IPv4 노드나 IPv4 응용과 통신하기 위해 영속적으로 IPv4 주소를 유지하지 않으며, IPv4/IPv6 듀얼 스택 구조와 동적 터널링을 제공하는 DTI 인터페이스를 가져야 한다.

- 순수 IPv4망과의 연결을 위해, DSTM 도메인은 IPv4/IPv6 듀얼 스택 구조의 경계 라우터들을 여러 개 둘 수 있으며, 동적인 터널 연결 과정에서 IPv6 노드에 대한 IPv4 주소와 IPv6 주소를 유지하고 있어야 한다.

- IPv6 노드로부터 IPv4 주소 쿼리를 인지할 수 있도록 DNS의 확장이 요구된다.

- DHCP는 DHCPv6 클라이언트들에게 IPv4 주소를 제공할 수 있도록 확장되어야 한다.

- IPv6 노드들은 기본적으로 IPv6 라우팅을 이용하고, IPv4 라우팅 테이블은 최소로 유지될 수 있도록 해야 한다.

4. TB(Tunnel Broker)

IPv6 망 환경은 거의 대부분 기존 IPv4 인프라상에서 터널링 기법을 사용해서 이루어진다. 이와 같은 터널들은 대규모로 구조화되거나 유지되기 어렵다고 여겨졌지만, 6Bone 환경에서 여러 가지 시험들을 통해 대규모 사이트별 또는 ISP(Internet Service Provider)별로 터널링을 제공하면 가능하다고 이야기되고 있다. 그러나, 이 절차는 이미 IPv4 망과는 연결 수단을 가지고 있으면서 IPv6 망으로 접속하고자 원하는 고립된 종단 사용자들에게는 너무 복잡하다고 할 수 있다. 이를 해결하기 위해 TB 모델이 개발되었으며, 이를 통해 IPv6 호스트들이 쉽게 6Bone에 연결할 수 있고 안정적이고 고정된 IPv6 주소와 DNS 이름을 가질 수 있게 하고자 하는 것이다. 즉, 이미 IPv4 망으로 연결되어 있는 사용자들에게 IPv6 망으로의 연결을 제공하는 일종의 가상 IPv6 ISP라 할 수 있다. 앞으로 인터넷상에서 IPv6 기반 망들이 등장하기 시작하면, 많은 TB들이 생겨날 것이며, 사용자들은 IPv6 상의 서버들에 접속하기 위해 TB들의 제공 서비스 질에 따라 선택적으로 사용하게 될 것이다.

기본적인 TB모델은 듀얼 스택 노드, TB 및 TSs(Tunnel Servers)로 구성된다. 터널의 한쪽 종단을 이루는 듀얼 스택 노드는 실제적인 IPv6 서비스를 받고자 하는 사용자를 의미하며, 호스트이거나 라우터일 수 있다. 이때, 호스트는 단일 IPv6 주소를 획득하고, 라우터는 prefix를 할당받는다. 다른 한쪽 종단을 이루는 TS들은 글로벌 IPv4 인터넷에 연결되어 있으며, 모든 동적인 터널들의 사용 통계 정보를 유지하고 있다. TB는 양 터널 종단간을 이어주는 역할을 한다. 사용자 노드로부터 터널 생성 요청을 받아 사용자를 TB의 DB에 등록하고, 터널의 생성, 변경 및 종료를 위한 구조화 명령(Configuration Order)을 TS에게 전송한다. 이후, TB는 사용자에게 자신이 터널링을 통해 연결한 TS의 IPv6 주소와 사용자 자신의 IPv6 주소를 전달한다. 이와 같은 정보는 웹을 통해 제공되므로, 사용자들은 쉽게 처리할 수 있다. 망으로 직접적인 연결 기능을 수행하는 TS들과 정보를 공유하여 부하를 줄이고, TB 모델의 확장성을 이루기 위함이다. 다음은 TB 모델을 위해 기본적으로 제공되어야 하는 프로토콜들이다.

- 노드 → TB: HTTP(POST)

- 노드 ← TB: RSH, SNMP(Simple Network Management Protocol), DHCPv6extension, ad-hoc 프로토콜 등

- TB ↔ TS: RSH, SNMP(Simple Network Management Protocol), ad-hoc protocol 등

- TB ↔ DNS: DNS 동적 갱신 프로토콜

TS상의 동적 터널들은 메모리와 처리시간 측면에서 많은 자원을 소모한다. 그러므로, 적절한 터널 관리 메커니즘을 사용하여 휴지 상태인 터널들은 즉각적으로 제거될 수 있도록 해야 한다. 가장 간단한 방법으로, TB에 의해 생성된 IPv4 터널상의 각 IPv6 연결은 적절한 생명주기를 할당하고, 연장 요청이 없는 한 연결을 종료하도록 하는 것이다. 그러나, Dial-up 링크 방식처럼 단명하고 동적으로 IPv4 주소를 할당받는 사용자들에게는 적절한 방법이 아니다. 연결마다 각각 다른 IPv4 주소가 할당되므로, 매번 터널 구조화 과정을 수행해야 하기 때문이다. 다른 해결책으로 클라이언트와 TS간(또는 클라이언트와 TB간)에 일종의 Keep-alive 메커니즘을 사용하는 것이다. 그래서, 각 터널이 사용자가 터널을 종료하면 즉각적으로 정보를 해지할 수 있게 되는 것이다. 그러나, 이 방법도 클라이언트 소프트웨어를 갱신해야 하는 단점이 있음에 유의하자. 다음 <표 3>은 DSTM과 TB 방식을 비교한다[7, 12].

 

결론적으로, 여러 가지 방식들 중에서 6to4와 TB 방식이 계속적으로 연구 개발될 것이다. 6to4 방식은 망 차원에서 IPv4 망과 연결성을 가지면서 순수 IPv6 호스트로만 구성된 IPv6망을 구축하고자 하는 경우에 사용될 것이다. 단지 하나의 글로벌 IPv4 주소만을 필요로 한다는 것은 큰 장점이다. TB 방식은 웹 페이지를 이용하므로 사용자들이 쉽게 사용할 수 있다는 장점과 함께 IPv6 망 사업을 하고자 하는 사용자들에게는 적절한 접근 방법이라 생각된다.

III. IPv4/v6 변환 기술

일반적으로 터널링 기술들은 IPv4-IPv6 스택을 가진 호스트들간의 통신이며 터널을 통한 통신 과정이 숨겨지지 않고 그대로 드러나게 된다. 이와 반대로 IPv4/IPv6 변환 기술은 IPv4 전용 호스트와 IPv6 전용 호스간의 통신을 위한 기술이며 주소 및 헤더의 변환 과정이 감추어져 있게 된다. 기본적으로 변환 기술은 다음과 같은 기능이 요구된다.

- DNS 확장

- 변환기(Translator)

- Mapper

이 기능 중 변환기는 실제 IPv4 패킷와 IPv6 패킷간의 변환을 담당하는 부분이며, DNS 확장은 기존의 A 형식의 IPv4주소 외에 AAAA 형식의 IPv6 주소도 처리하고 이들간에 변환을 담당한다. 또한 Mapper는 IPv4 와 IPv6 주소의 연계를 담당하며, 이미 확보된 주소 pool에서 하나를 선택한다.

IPv4/IPv6 변환 기술은 (그림 1)과 같이 크게 세 가지 방식이 구분한다. 첫번째는 헤더 변환 방식으로, 현재 IETF NGtrans WG에서는 라우터상에NAT-PT(Network Address Translation-Protocol Translation) 및 SIIT(Stateless IP/ICMP Translation) 방식 개발을 중심으로 표준화가 진행중에 있다. 이 방식은 IP 계층에서 수행하기 때문에 빠르다는 장점을 가지고 있지만, IPv4와 IPv6의 패킷 분할(fragment) 정책의 차이와 ICMPv4와 ICMPv6 간의 상이함 등 해결해야 할 많은 문제들을 가지고 있다. 두번째는 수송계층 릴레이(transport relay) 방식으로, SOCKS 등이 여기에 속한다. 이 방식은 적용이 쉽다는 장점을 가지고 있지만, 접속별로 관리하기 때문에 TCP만 적용할 수 있으며 클라이언트 시스템도 갱신을 필요로 한다. 마지막으로, 응용 프락시 서버(proxy server) 방식은 주소 매핑 방식을 필요로 하지 않지만, 각 서비스별로 독립된 서버와 프로토콜을 사용해야 하는 단점이 있다. 이외에도 NAT-PT 기능을 호스트에 옮겨 놓은 방식인 BIS(Bump in the Stack) 등이 연구되고 있다. 현재, IETF에서 SIIT, NAT-PT 및 BIS 방식은 RFC 문서로 등록된 상태이다.

1. SIIT

인터넷이 고속 성장하고 있음에 따라, 이제는 IPv6 전용 호스트와 IPv4 전용 호스트간에 통신을 고려해야 한다. 여기서 IPv6 전용 호스트는 IPv4 모듈을 가지고 있다. 단지, IPv4 주소를 할당받지 않았을 뿐이다. IPv6 전용 호스트와 IPv4 전용 호스트가 통신을 하기 위해서는 여러 가지 기능이 요구된다. IPv6 노드와 IPv4 노드가 상호 동작하기 위한 알고리즘과 임시로 사용되는 IPv4 주소를 IPv6 노드에 할당하는 메커니즘이 필요하다. 또한, IPv6 노드에 할당된 IPv4 주소를 통한 라우팅 메커니즘이 요구된다. 물론, IPv4 주소를 DHCPv6 등의 프로토콜을 통한 DNS 서버에 등록하는 과정도 필요하다. 여기서, SIIT는 IPv6 노드와 IPv4 노드간의 통신을 위한 알고리즘들 중에 한가지 방식이며, 표준화가 완료되어 RFC 문서로 등록된 상태이다. 이 문서에는 IPv4와 IPv6 패킷 헤더간의 변환 규칙, IPv4와 IPv6 주소의 매핑 방식, ICMPv4와 ICMPv6간의 관계 등을 규정하고 있다. 다시 말해, SIIT는 프로토콜 변환 메커니즘이라 할 수 있으며, 특정 세션에 대한 상태 정보를 요구하지 않으면서 독립적인 IPv4와 IPv6 패킷을 서로 변환하는 것이다. 앞에서도 언급했지만, IPv6 노드는 임시적으로 IPv4 주소를 가져야 한다[13, 14].

2. NAT-PT

NAT-PT는 이름에서도 알 수 있는 것처럼 두 가지 기능으로 분류할 수 있다. 첫번째는, 세션이 초기화 될 때마다 동적으로 IPv6 노드에 IPv4를 할당하기 위한 주소 pool을 가지고 두 망간의 경계 라우터에 주로 위치하는 NAT 기능이다. 즉, 주소 매퍼(address mapper)로서 동작한다. 두 번째는, PT이며, 앞 절의 기술된 SIIT를 기반으로 주소 변환을 수행하기 위해 사용된다. 이때, 관련 정보들은 세션동안 유지하고 있어야 한다. 또한, 동적으로 주소를 할당하고 변환하기 위해서는 응용에 따라 추가적인 요구사항이 발생하는데, 이를 지원하기 위한 ALG(Application Level Gateway)를 사용해야 한다. 예로 DNS-ALG와 FTP-ALG 등이 있으며, DNS ALG는 AAAA와 A 형식의 변환 및 DNSv4와 DNSv6 간의 주소 정보 교환을 역할을 수행한다. 이와 같은 ALG는 응용 프락시와는 구별되는데, 응용 프락시와는 달리 추가적인 전용 프로토콜을 요구하지 않는다. (그림 2)는 NAT-PT의 기본 구조를 보여준다.

 

IPv6 노드에서 IPv4 노드로 패킷을 전송할 경우, NAT-PT의 기본적인 동작 과정을 살펴보자. 먼저, NAT-PT는 라우터상에 구현되고, IPv4 주소를 위한 prefix를 라우터의 NDP의 RA (Router Advertisement) 메시지를 통해 이미 분배되어 있다고 하자. 이 prefix는 IPv6 노드들에 임시로 할당되는 IPv4 주소를 쉽게 IPv6 주소 변환하기 위해 사용될 것이다. 이렇게 생성된 IPv6 주소를 IPv4-translated 주소라 부른다. 현재, IPv6 노드는 수신자뿐만 아니라 송신자인 자신의 IPv4 주소도 가지고 있지 않은 상황이다. 그러므로, DNS-ALG의 도움으로 IPv4 노드가 속한 DNS서버로부터 목적지 IPv4 주소를 획득하고, 송신용 IPv4 주소를 NAT-PT로부터 할당 받는다. 그 다음에, 라우터로부터 공지된 IPv4-translated 주소용 prefix로 주소를 구성하여, IPv6 패킷 형태로 전송한다. 그 다음으로 IPv6 도메인에서 IPv4 도메인으로 나아가기 위한 경계 라우터상에 구현된 NAT-PT에 도착한 패킷은 IPv4-translated IPv6 주소로부터 쉽게 IPv4 주소를 추출할 수 있으며, 이에 따라 IPv4 패킷을 구성하여 목적지 노드에게 IPv4 패킷 형태로 전송한다. 이때, IPv4 노드로부터의 응답을 처리하기 위해 관련 주소 정보들은 유지된다. 그 반대로, IPv4 노드에서 IPv6 노드로 패킷을 보내는 경우, IPv4 패킷의 목적지 주소는 IPv6 도메인 내의 DNS에 의해 NAT-PT로부터 할당받은 IPv4 주소를 사용하게 된다. (그림 3)에서는 앞에서 기술한 IPv6 노드에서 IPv4 노드로 패킷이 전송되는 과정을 예시한다. 여기서, PREFIX는 IPv4-translated 주소 구성용으로 사용되며, 203.255.255.0/24 영역이 주소 pool 이다.

 

이와 같은 NAT-PT 방식은 출구 라우터와 입구 라우터가 동일해야 하기 때문에 토폴로지에 제약사항이 있으며, 멀티캐스트, QoS, 보안 기능 등을 적용하기가 쉽지 않은 단점을 가지고 있다[15].

3.SOCKSv5

SOCKS 서버는 원래 방화벽용으로 구현되었지만, IPv4/IPv6 변환을 위한 확장 기능을 추가함으로써 변환 기능을 제공할 수 있게 되었다. 이를 통해, IPv6 응용 자체에 대한 수정과 NAT-PT처럼 ALG의 도움없이 IPv4 응용과 통신이 가능하다. 다만, IPv6 노드는 SOCKS 기능을 지원하기 위해 socket API를 수정해야 한다. 그러므로, SOCKS 변환 방식은 IPv6주소와 IPv4 매핑 역할을 수행하는 IPv6 호스트 SOCKS 라이버러리와 실제적인 변환 기능을 담당하는 변환 서버로 구성된다. SOCKS 라이버러리는 호스트상의 응용 계층과 소켓 계층 사이에 존재하는 구현 계층이라 할 수 있으며, 기존의 socket API와 동일한 형태를 가지지만 내부적으로 다른 기능을 수행한다. 변환 서버는 IPv4/IPv6 노드상에 구현되며, 기존의 소켓 계층 위에 존재하는 하나의 응용 프로그램이라 할 수 있다. 이 SOCKS 변환 방식은 다음과 같은 특징들을 가진다.

- IPv4 통신 방식과 기존의 통신 망 인프라에서 제공되는 편의성들은 유지해야 한다. 예를 들어, DNS의 변경을 요구하지 않는다. 이는 호스트의 SOCKS 라이버러리 계층에서 모든 응용별로 다른 매핑 테이블을 통해 제공된다.

- IPv4 통신을 위해 설계된 사용자 응용들이 변경없이 사용될 수 있어야 한다.

- IPv4와 IPv6 간의 전환 기능을 제공함과 동시에 확장성을 제공해야 한다.

- IPsec과 같은 IPv6의 새로운 특징을 쉽게 적용활 수 있어야 한다.

- 기존 OS나 네트워크 장치에 종속적이지 않다.

- TCP 뿐만 아니라, UDP의 릴레이도 가능하며, 다중 릴레이도 쉽게 적용할 수 있다.

- 기본적으로 SOCKS 라이버러리를 가진 호스트와 SOCKS 서버로 구성되며, SOCKS 호스트와 서버간에는 SOCKS 연결이 설정되며, SOCKS 서버가 최종적인 목적지 IPv4 호스트로 소켓 연결을 설정한다.

이 SOCKS 변환 방식의 동작을 살펴보면, 먼저 SOCKS 호스트와 서버간에는 SOCKS 연결이 설정되며, 이 연결을 통해 최종 목적지의 FQDN(Fully Qualified Domain Name) 형태의 이름을 알려주게 된다. FQDN 이름을 수신한 SOCKS 서버는 이 이름으로 DNS 서버에게 쿼리를 전송하고, 목적지 주소를 획득하게 된다. 이에 따라 SOCKS 서버는 최종적인 목적지 IPv4 호스트로 소켓 연결을 설정하게 되는 것이다. 이SOCKS 변환 방식에서 IPv6 주소만을 사용하는 IPv6 응용과 IPv4 주소만 가진 IPv4 응용이 서로를 어떻게 인지할 것인가 있다. 다음의 (그림 4)에서는 SOCKS 변환 기술에서의 주소 변환 방법이다. SOCKS 라이버러리는 가짜 IP를 응용에게 알려 주고, 실제 IP는 SOCKS 서버가 DNS와 통신을 통해 알게 되는 과정이다[16].

 

4. BIS(Bump-In-the Stack)

지금까지 개발된 수많은 IPv4 응용을 IPv6 환경에서도 수정없이 사용하고자 하는 시도에서 BIS 변환 기술은 개발되기 시작했다. BIS 모듈은 TCP/IP 모듈과 네트워크 드라이브 모듈 사이에 위치하며, 데이터를 가로채서 IPv4 또는 IPv6 패킷으로 변환하는 역할을 수행한다. 기본적으로 IPv6 호스트는 듀얼 스택 구조를 가져야 하며, 호스트 내부적으로만 사용되는 IPv4 주소 pool을 가져야 한다. 이 경우, IPv6 호스트상의 IPv4 응용들은 자신이 통신하고자 하는 상대자의 정확한 이름만 알고 있으면, 상대가 IPv6 노드인지, IPv4 노드인지에 대해 알아야 할 필요가 없다. 이 BIS를 이루는 구성 요소들은 (그림 5)과 같으며, 크게 3가지 기능으로 구분된다.

 

첫번째로 살펴볼 구성 요소는 NAT-PT의 DNS-ALG와 유사한 기능을 수행하는 확장된 Name Resolver이다. 기본적으로 IPv4 응용이 gethostbyname( )과 같은 함수를 호출하면 Resolver가 동작하게 되며, 이에 대한 응답으로 IPv4 주소를 돌려주면 된다. 그러나, 통신 상대가 IPv6 노드일 수도 있으므로, AAAA 형식으로 DNS 쿼리하는 기능을 Resolver는 포함해야 한다. 이 경우, 수신 IPv6 주소 대신에 IPv4 응용에게 돌려 줄 IPv4 주소를 할당받기 위해, Resolver는 Address Mapper를 호출하게 된다. 두번째 구성요소는 Address Mapper이다. 호스트 시스템 내에서만 통용되는 IPv4 주소 pool을 할당하는 역할을 수행하며, 매핑된 IPv4와 IPv6 관계 정보를 유지한다. 세번째 구성 요소는 Translator이며, IPv4 응용으로부터 수신한 IPv4 패킷을 SIIT에 정의된 규칙에 따라 IPv6 패킷으로 변환하여 망으로 전달하는 기능을 수행한다.

BIS 변환 기술은 NIC(Network Interface Card)에 의존적이기 때문에, 일본 히타치 등에서 NE2000과 3Com 계열의 일부에서만 개발되고 있다. 이와 같은 단점을 극복하기 위해, BIS 개념을 그대로 TCP/IP 상위에서 구현하고자 하는 BIA(Bump-In-the-API) 기술이 연구되고 있다[17].

지금까지 대표적인 IPv4/IPv6 변환 기술에 대해 살펴보았다. <표 4>에서 나타낸 특징들을 서로 비교해 보고, 사용 환경에 따라 적절한 방식을 선택해야 할 것이다.

 

IV. 결 론

IPv4 망에서 IPv6 망으로 전환하기 위해서는 오랜 시일이 소요될 것이며, 예상하지 못한 여러 가지 환경들이 발행할 것이다. 이와 같은 모든 환경에 적합한 변환 기술은 존재하지 않을 것이며, 상황에 따라 적절한 방식을 선택하는 것이 중요하다고 하겠다. 먼저, 국내의 적절한 IPv4에서 IPv6로의 진화 방향과 전략을 수립하고, 예상되는 전환 시나리오를 작성해야 할 것이며, 이에 따라 적합한 변환 기술을 적용하는 것이 중요하다고 하겠다. 앞으로 변환 기술을 제공하는 ISP 사업자 또는 변환기를 구현하고자 하는 연구자는 기본적으로 6to4, TB, NAT-PT 및 BIS 등의 기술력을 함께 갖추고 있어야 할 것이다. 그래야만, 다양한 사용자의 요구사항에 따라 적절하게 대처할 수 있을 것이다. 또한 여러 기술을 접목해서 가능한 상태 정보를 유지하지 않는 방법도 개발되어야 한다.

이제, IPv4로는 해결할 수 없는 치명적인 문제로 인해 IPv6로의 진화는 대세이며, IPv4/ IPv6 변환 기술과 함께 IPv6의 장점을 살린 효과적인 응용들을 개발해야 할 시점이다.

<참 고 문 헌>

[1]    S. Deering and R. Hinden, “Internet Protocol, Version 6(IPv6) Specification”, RFC2460, 1998. 12.

[2]    R. Hinden and S. Deering, “IP Version 6 Addressing Architecture”, RFC2373, 1998. 7.

[3]    박정수외 4명, “차세대 인터넷 프로토콜(Internet Protocol Version 6) 기술 소개”, 한국전자통신연구원, 주간기술동향 통권 965호, 2000. 9. 27.

[4]    K. Yamamoto and M. Sumikawa, “Categorizing Translators between IPv4 and IPv6”, draft-ietf-ngtrans-translator-01.txt, 1999. 1.

[5]    T. Larder, “Transition Scenarios and Solutions”, draft-ietf-ngtrans-trans-scenes-00.txt, 1999. 4.

[6]    W. Biemlt, M. Kaat and etc., “A Guide to the Introduction of IPv6 in the IPv4 world”, 1999. 10.

[7]    R. Gilligan and E. Nordmark, “Transition Mechanisms for IPv6 Hosts and Routers”, draft-ietf-ngtrans-mech-04.txt, 1999. 5.

[8]    B. Carpenter and C. Jung, “Transmissioin of IPv6 over IPv4 Domains without Explicit Tunnels”, RFC2529, 1999. 3.

[9]    B. Carpenter and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels”, draft-ietf-ngtrans-6to4-03.txt, 1999. 10.

[10]  J. Bound, “Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH)”, draft-ietf-ngtrans-assgn-IPv4-addrs-01.txt, 1999. 1.

[11]  J. Bound and L. Toutain, “Dual Stack Transition Mechanism(DSTM)”, draft-ietf-ngtrans-dstm-00.txt, 2000. 4.

[12]  A. Durand, P. Fasano and etc, “IPv6 Tunnels Broker”, draft-ietf-ngtrans-broker-02.txt, 1999.10.

[13]  E. Nordmark, “Stateless IP/ICMP Translation Algorithm(SIIT)”, RFC2765, 2000. 2.

[14]  A. Conta and S. Deering, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6(IPv6) Specification”, draft-ietf-ipngwg-icmp-v3-00.txt, 1999. 7.

[15]  G. Tsirtsis and P. Srisuresh, “Network Address Translation-Protocol Translation(NAT-PT)”, RFC2766, 2000. 2.

[16]  H. Kitamur, A. Jinzaki and S. Kobayashi, “A SOCKS-based IPv6/IPv4 Gateway Mechanism”, draft-ietf-ngtrans-socks-gateway-02.txt, 1999. 7.

[17]  K. Tsuchiya, H. Higuchi and Y. Atarashi, “Dual Stack Hosts using the Bump-In-the-Stack Technique(BIS)”, RFC2767, 2000. 2.