DBPIA-NURIMEDIA

Size: px

Start display at page:

Download "DBPIA-NURIMEDIA"

종현 빈
5 years ago
Views:

1 논문 B-08 한국통신학회논문지 07-1 Vol. 32 No. 1B Mobile IPv4/Mobile IPv6 통신을위한모바일헤더변환메커니즘 준회원김대선 *, 정회원홍충선 ** A Mobility Header Conversion Mechanism for Mobile IPv4 and Mobile IPv6 Communications Dae-Sun Kim* Associate Member, Choong-Seon Hong** Regular Member 요 약 IPv4/IPv6 통신서비스를위한변환기는호스트의변경없이 IPv6 호스트와 IPv4 호스트간의통신을지원해준다. 그러나호스트가모바일노드일경우삼각형라우팅문제가발생한다. Mobile IPv4 모바일노드가이동할경우홈에이전트와 IPv6의 CN(Correspondent Node) 에게반드시이동정보를보내주어야하지만현재 NAT-PT 는 IPv4와 IPv6의이동성헤더인모바일 IPv4/Mobile IPv6의헤더변환은지원해주지않기때문에삼각형라우팅문제가발생하여 Mobile IPv4와 Mobile IPv6간에비효율적인통신을일으킨다. 본논문에서는 Mobile IPv4와 Mobile IPv6 통신에서발생하는삼각형라우팅문제를해결하기위한모바일헤더변환메커니즘을제안하였다. Key Words : NAT-PT, IPv6, IPv4, Mobile IPv6, Mobile IPv4 ABSTRACT An interworking translator for IPv6 and IPv4 services can be defined as an intermediate component between a native IPv4 host and a native IPv6 host to enable direct communication between them without requiring any modifications to the hosts. But if the host is a mobile node, triangle routing problem occurs, since Mobile IPv4 allows mobile node to roam transparently in any network. In this situation, mobile node must notify transfer information to its own home agent and correspondent node in IPv6 network. But current NAT-PT does not permit mobility header translation. Therefore, NAT-PT does not support efficient communication between Mobile IPv4 and Mobile IPv6. In this paper, we propose a mobility header conversion mechanism to resolve the triangle routing problem between Mobile IPv4 and Mobile IPv6. Ⅰ. 서론 IPv4 [1] 의주소부족문제를해결하기위해 IPv6 [2] 가개발되었다. IPv6는무한의주소공간과 QoS (Quality of Service) 제공그리고이동성지원기능을가지고있어서차세대네트워크프로토콜로서 각광을받고있다. 따라서 IPv4에서 IPv6로대체하기위해서는 IPv6의도입시점부터상당기간 IPv4와공존해야하며그기간동안 IPv4와 IPv6 간통신방안이필요하다. 이에 IETF v6ops WG (IPv6 Operations Working Group) 에서는크게세가지 IPv4/IPv6 통신을위한메커니즘을제안하였다. 첫 This work was supported by MIC and ITRC Project.. * 경희대학교컴퓨터공학과박사과정 (dskim@khu.ac.kr), ** 경희대학교전자정보대학교수 (cshong@khu.ac.kr) 논문번호 :KICS , 접수일자 :2006 년 8 월 17 일최종논문접수일자 :2007 년 1 월 2 일 61

한국통신학회논문지 07-1 Vol. 32 No. 1B 번째는 IPv4 스택과 IPv6 스택을가지고있는이중스택 [3] 을제안하였고두번째는 IPv4와 IPv6간의터널을통한기법들 [4][5] 을제안하였다. 마지막으로 IPv4와 IPv6 프로토콜을변환할수있는변환기 [6] 를제안하였다.

본논문의구성은다음과같다. 2장에서는현재 IPv4와 IPv6 간의변환메커니즘들을소개한다. 3장에서는모바일네트워크환경에서의변환메커니즘의필요성에대하여기술하고본논문에서제안하는 Mobile IPv4 와 Mobile IPv6의 Mobility 헤더변환알고리즘을통해 Mobile IPv4 네트워크의모바일노드와 IPv6 네트워크의호스트간통신방안을설명한다.

그림 1과같이 IPv4 네트워크와 IPv6네트워크간에는 Translator [6] 를사용하여통신을하고 IPv6 네트워크사이에 IPv4 네트워크가존재할경우두 IPv6 네트워크는 Tunneling [4][5] 을통하여통신을할수있다. 그리고 IPv4 네트워크와이중스택을지원하는네트워크와는 IPv4로, IPv6 네트워크와는 IPv6 로통신을할수있다.

2 한국통신학회논문지 07-1 Vol. 32 No. 1B 번째는 IPv4 스택과 IPv6 스택을가지고있는이중스택 [3] 을제안하였고두번째는 IPv4와 IPv6간의터널을통한기법들 [4][5] 을제안하였다. 마지막으로 IPv4와 IPv6 프로토콜을변환할수있는변환기 [6] 를제안하였다. 이와같이유선네트워크환경에서 IPv4와 IPv6 간통신을하기위해여러가지메커니즘들이제안되었고일부메커니즘들은인터넷표준이되었다. 하지만위와같은메커니즘들은모바일네트워크환경을고려하지않은메커니즘들이다. 따라서모바일환경을지원하는 Mobile IPv4 [1] 와 Mobile IPv6 [7][9][12][13][14] 간의효율적인통신을지원할수있는메커니즘들이필요하다. 본논문의구성은다음과같다. 2장에서는현재 IPv4와 IPv6 간의변환메커니즘들을소개한다. 3장에서는모바일네트워크환경에서의변환메커니즘의필요성에대하여기술하고본논문에서제안하는 Mobile IPv4 와 Mobile IPv6의 Mobility 헤더변환알고리즘을통해 Mobile IPv4 네트워크의모바일노드와 IPv6 네트워크의호스트간통신방안을설명한다. 4장에서는실험결과를보여주고마지막 5장에서는결론및향후연구계획으로마무리한다. Ⅱ. 관련연구 IPv6 도입으로인해네트워크의형태는그림 1과같은중간단계를상단기간유지할것으로예상된다. 그림 1과같이 IPv4 네트워크와 IPv6네트워크간에는 Translator [6] 를사용하여통신을하고 IPv6 네트워크사이에 IPv4 네트워크가존재할경우두 IPv6 네트워크는 Tunneling [4][5] 을통하여통신을할수있다. 그리고 IPv4 네트워크와이중스택을지원하는네트워크와는 IPv4로, IPv6 네트워크와는 IPv6 로통신을할수있다. 따라서 IPv4와 IPv6의변환메커니즘은크게다음과같이분류할수있다. 1 Dual Stack 2 Tunneling 3 Translator 2.1 Dual Stack Dual Stack [2] 은단말이 IPv4 프로토콜과 IPv6 프로토콜을가지고통신하는기법이다. 따라서 IPv4와는 IPv4 프로토콜을사용하여통신을하고, IPv6와는 IPv6 프로토콜을사용하여통신을한다. Dual Stack의구조는그림 2와같다. 그림 2. Dual Stack 의구조 2.2 Tunneling Tunneling에는크게두가지기법으로분류할수있다 Automatic Tunneling [4] 이기법은 IPv6 네트워크에있는 Dual Stack 호스트가 IPv4 네트워크를통과하여다른 IPv6 네트워크에있는 Dual Stack 호스트와통신할때사용한다. 통신을하고자하는호스트는발신지와목적지주소를 IPv6 compatible 주소타입으로구성하여 IPv6 패킷을만들어 IPv6와 IPv4 경계에있는라우터에게보낸다. 라우터는 IPv6 패킷의발신지와목적지의주소중 IPv4 주소를뽑아내어 IPv4 패킷을만들어터널링하는기법이다. 그림 1. IPv6 도입시예상되는네트워크구조 그림 3. Automatic Tunneling 62

논문 / Mobile IPv4/Mobile IPv6 통신을위한모바일헤더변환메커니즘 2.2.2 Configured Tunneling [5] 이기법은 IPv6 네트워크에있는 IPv6 호스트가 IPv4 네트워크를통과하여다른 IPv6 네트워크에있는 IPv6 호스트와통신할때사용한다.

3 논문 / Mobile IPv4/Mobile IPv6 통신을위한모바일헤더변환메커니즘 Configured Tunneling [5] 이기법은 IPv6 네트워크에있는 IPv6 호스트가 IPv4 네트워크를통과하여다른 IPv6 네트워크에있는 IPv6 호스트와통신할때사용한다. 통신을하고자하는호스트는 IPv6 패킷을만들어 IPv6와 IPv4 경계에존재하는라우터에게보내면라우터는 IPv4망을통과하기위하여 IPv4 패킷을만들고 IPv6 패킷은캡슐링하여 IPv4망을통과하는기법이다. 동작과정은다음과같다. 1 IPv6 호스트가 IPv4 호스트의주소를알기위해서 query 메시지를보낸다. 2 IPv4 호스트의 naming을관리하는 DNS4 서버는 query 메시지에서목적지호스트의 IPv4 주소를응답메시지에포함하여전달한다. 3 IPv6 호스트는 IPv6 패킷을만들어 NAT-PT 로보낸다. 이때목적지주소는 IPv4-mapped 주소를사용한다. ( 예 ) 2001::ffff: 패킷을받은 NAT-PT는 IPv6 패킷의목적지주소에서하위 32bit 필드의 IPv4 주소를뽑아서 IPv4 패킷을만든다. 이때 NAT-PT의 address-pool에서 source address를임의의 IPv4주소로할당하고 mapping table에 IPv6 source address 와할당한 IPv4 address를 mapping해서기록해둔다. 그림 4. Configured Tunneling 2.3 Translator 이기법은 IPv4 호스트와 IPv6 호스트간통신을위한기법이다. IPv4 호스트에서 IPv6 호스트로의통신에서는 IPv4 패킷을경계라우터가 IPv6 패킷으로변환하고 IPv6 호스트에서 IPv4 호스트로의통신에서는경계라우터가 IPv6 패킷을 IPv4로변환하여통신을가능하게만드는기법이다. 헤더변환은그림 6과같이 SIIT알고리즘 [8] 을사용하여변환하고각연결마다임시로할당할 IP 주소는경계라우터의 address pool [6] 에서할당한다. Translator의 NAT-PT (Network Address Translation - Protocol Translation) [6] 의구조는그림 5와같다. 그림 5. NAT-PT의구조 Version HELN TOS Total Length(16) (4) (4) (8) Fragment Identification(16) Flags(3) Offset(13) Version Class Flow Label(20) (4) (8) TTL(8) Protocol(8) Header Checksum(16) Next Hop Payload length(16) Source IP Address(32) Header(8) Limit(8) Destination IP Address(32) Source Address(128) PREFIX::IPv4 Source Address Destination Address(128) Address mapping to IPv4 Destination Address 그림 6. SIIT 알고리즘 (RFC 2765) 알고리즘은다음과같다 Version field: 6 삽입 Class field: IPv4 ToS 필드값복사 Flow Label field: IPv4와관련된필드없으므로 0을삽입 Payload field: IPv4 헤더의 Total length 필드값복사 Next Header field: IPv4 헤더의 Protocol 필드값복사 Hop Limit field: IPv4 헤더의 TTL 필드값복사 Source Address field: IPv4-compatible 주소타입삽입 Destination Address field: NAT-PT의 mapp- 63

한국통신학회논문지 07-1 Vol. 32 No. 1B ing 테이블에있는 IPv6 호스트의주소값삽입 IPv6 헤더를 IPv4 헤더로변환하는알고리즘은위의 IPv4 헤더를 IPv6 헤더로변환하는알고리즘의역과정이다. Ⅲ.

무선단말이이동할경우새로운 IP를부여받고통신하고자하는단말에게이동한위치를통보를해주어야한다.

따라서본논문에서는다양한모바일환경중에서 Mobile IPv4 네트워크의모바일노드와 IPv6 네트워크의호스트간통신방안을제안하였다.

하지만그림 8에서볼수있듯이모바일노드가외부망으로이동시 Registration request [10][11] 메시지를 IPv6 네트워크에있는호스트에게보내지만 IPv6 호스트는 Registration request메시지에포함된정보를알수가없다.

4 한국통신학회논문지 07-1 Vol. 32 No. 1B ing 테이블에있는 IPv6 호스트의주소값삽입 IPv6 헤더를 IPv4 헤더로변환하는알고리즘은위의 IPv4 헤더를 IPv6 헤더로변환하는알고리즘의역과정이다. Ⅲ. 제안사항 위와같이유선환경에서 IPv4와 IPv6 변환메커니즘들이제안되어통신이가능하지만모바일네트워크환경에서는위와같은메커니즘들을적용할수없다. 그이유는모바일환경에서는유선환경과다르게단말들이이동하기때문이다. 무선단말이이동할경우새로운 IP를부여받고통신하고자하는단말에게이동한위치를통보를해주어야한다. 하지만 Mobile IPv4와 Mobile IPv6 간의변환메커니즘이없어단말이이동시다른 IP망에있는호스트에게이동에대한통보를할수없게되어효율적인통신을할수가없다. 따라서본논문에서는다양한모바일환경중에서 Mobile IPv4 네트워크의모바일노드와 IPv6 네트워크의호스트간통신방안을제안하였다. 그림 7에서모바일노드가자신의홈네트워크에있을경우 IPv6 네트워크에있는 IPv6 호스트들과의통신은 NAT-PT의헤더변환메커니즘을통해통신을할수있다. 하지만그림 8에서볼수있듯이모바일노드가외부망으로이동시 Registration request [10][11] 메시지를 IPv6 네트워크에있는호스트에게보내지만 IPv6 호스트는 Registration request메시지에포함된정보를알수가없다. 결과적으로 IPv6 호스트는모바일노드가이동해서새롭게부여받은 CoA(Care of Address) 를알수가없다. 따라서그림 9와같이삼각형라우팅문제를발생시킨다. 그림 9. 삼각형라우팅문제 위와같은삼각형라우팅문제를해결하기위해서는 NAT-PT에서 IPv4/IPv6 헤더변환뿐만아니라 Mobile IPv4/Mobile IPv6 헤더변환도반드시지원해야한다. 그림 7. Mobile IPv4 네트워크의모바일노드와 IPv6 네트워크의호스트간통신 3.1 Mobile IPv4/Mobile IPv6 Mobility 헤더 그림 10은 Mobile IPv4 헤더 [2] 와 Mobile IPv6 헤더 [3] 의포맷이다. 그림 8. 모바일노드의이동시등록과정문제 그림 10. Mobile IPv4 헤더와 Mobile IPv6 헤더 64

논문 / Mobile IPv4/Mobile IPv6 통신을위한모바일헤더변환메커니즘 Mobile IPv4의헤더는 8bits의 Type 필드,6bits 의플래그와 16bits의 lifetime 필드, 32bits의 Home address, Home Agent, Case-of-Address 그리고 64bits의 identification으로구성되어있다.

5 논문 / Mobile IPv4/Mobile IPv6 통신을위한모바일헤더변환메커니즘 Mobile IPv4의헤더는 8bits의 Type 필드,6bits 의플래그와 16bits의 lifetime 필드, 32bits의 Home address, Home Agent, Case-of-Address 그리고 64bits의 identification으로구성되어있다. 각필드의의미를살펴보면다음과같다. Type: 1(registration request를의미 ) S flag: Home Agent에서이전의바인딩정보를유지할것을요구 B flag: 홈네트워크로전송되는브로드캐스트패킷을 HA가 CoA로터널링해줄것을요구 D flag: Decapsulation M flag: Minimal encapsulation G flag: GRE encapsulation V flag: Van Hacobson header compression Home Address: 모바일호스트의고유주소 Home Agent: 모바일호스트의 Home Agent 주소 Care-of-Address: 외부망의로부터부여받은주소 Identification: 등록시 reply 공격을막기위한 64bits 숫자이와는다르게 Mobile IPv6 헤더는 8bits의 Payload proto 필드, 8bits의 header len 필드, 8bits 의 MH Type 필드, 16bits의 checksum 필드, 16bits 의 sequence number 필드, 4bits의플래그그리고 16bits의 lifetime 필드로구성되어있다. 각필드의의미를살펴보면다음과같다. Payload proto: IPv6의 next header 필드와동일한의미 (Mobility header: 59) header len: 헤더의길이 MH Type: Binding Update(5), Binding Acknowledgment(6) checksum: Mobility header에대한체크섬 sequence number: 모바일호스트가여러 CN에게보내는 Binding Update의구분값 A flag: Binding Update에대한 Acknowledgment 요구 H flag: Home Agent로의 Binding Update 전송 L flag: link-local address interface identifier와 home address가같음 K flag: Home Agent와모바일호스트간의 security association 요구이와같이 Mobile IPv4와 Mobile IPv6의헤더의위치및필드가전혀다르다. 따라서 IPv4 네트워크의모바일노드가 IPv6 네트워크의호스트들과통신을하기위해서는 NAT-PT에서사용하는 IPv4와 IPv6에서헤더변환알고리즘인 SIIT(Stateless IP/ ICMP Translation Algorithm)[5] 와같은 Mobility 헤더변환알고리즘이반드시필요하다. 3.2 Mobility 헤더변환알고리즘 Mobility 헤더변환은 Binding Update(Mobile IPv4에서는 Registration Request) 와 Binding Acknowledgment(Mobile IPv4에서는 Registration Reply) 변환이필요하다 Binding Update 변환알고리즘 IPv4 네트워크의무선단말은이동후자신의홈에이전트와 CN(Correspondent Node) 에게새로운 CoA(Care of Address) 를포함한 Registration Request 메시지를보내등록을해야한다. 하지만 Mobile IPv6에서사용하는등록메시지는 Binding Update 메시지이기때문에 Mobile IPv4 Registration request 메시지를 Mobile IPv6 Binding Update 메시지로변환해야만 IPv6 네트워크의호스트들은 IPv4 네트워크의모바일노드의이동위치를알수가있다. Mobile IPv4의 Registration Request를 Mobile IPv6 Binding Update 메시지로변환하는알고리즘은그림 11과같다. 그림 11. Binding Update 변환알고리즘 65

6 한국통신학회논문지 07-1 Vol. 32 No. 1B 동작과정은아래의순서와같다. 동작과정은아래의순서와같다. 1 IPv4/IPv6 헤더변환 : SIIT 알고리즘을사용하여변환 2 Mobile IPv4/Mobile IPv6 헤더변환 payload proto: Mobility Header를의미하는 59 삽입 header len: 128bits 8bits = 16 삽입 MH Type: Binding Update 메시지를의미하는 5 삽입 reserved: 0 삽입 checksum: 계산후값삽입 sequence number: NAT-PT로부터할당받은값삽입 {AHLK}: 확인응답을요구하는 A bits만설정 lifetime: Mobile IPv4의 lifetime 값으로삽입위와반대로 Binding Update 메시지를 Registration Request 메시지로변환하는알고리즘은위의그림 11 알고리즘의역과정이다 Binding Acknowledgment 변환알고리즘 Mobile IPv6의 Binding Acknowledgment 메시지를 Mobile IPv4 Registration Reply 메시지로변환하는알고리즘은그림 12와같다. 1 IPv4/IPv6 헤더변환 : SIIT 알고리즘을사용하여변환 2 Mobile IPv4/Mobile IPv6 헤더변환 UDP destination port: Mobile Header를의미하는 434 삽입 Type: Registration Reply 메시지를의미하는 3 을삽입 Code: Registration accepted를의미하는 0을삽입 lifetime: Mobile IPv6의 lifetime 값으로삽입 Home address: BR에저장되어있던자신의 IPv4 주소삽입 Home Agent: BR의 IPv4 주소를삽입 Identification: BR로부터할당받은값삽입위와반대로 Registration Request 메시지를 Binding Acknowledgment 메시지로변환하는알고리즘은위의그림 12 알고리즘의역과정이다. 3.3 등록과정등록과정은그림 13과같다. 모바일노드가자신의홈망에서외부망으로이동시모바일호스트는새로운 CoA를획득하고 CoA 정보가포함된 Registration Request 메시지를보낸다. 이때 NAT-PT는받은메시지를 Binding Update 변환알고리즘을사용하여 Mobile IPv6 Binding Update 메시지를생성해서 CN에게보낸다. CN은이에대한응답으로 Binding Acknowledgment 메시지를보내고 NAT-PT는이메시지를 Binding Acknowledgment 변환알고리즘을사용하여 Mobile IPv4 Registration Reply 메시지를생성해서모바일노드에게보냄으로써등록과정을끝낸다. 제안알고리즘의동작과정을그림 13과같고, 상세동작시나리오는그림 14와같다. 그림 12. Binding Acknowledgment 변환알고리즘 그림 13. Mobile IPv4 노드와 IPv6 CN 간등록과정 66

7 논문 / Mobile IPv4/Mobile IPv6 통신을위한모바일헤더변환메커니즘 모델을사용하였다. End-to-End delay는 Propagation delay, Queuing delay 그리고 Transmission delay의합이며 End-to-End delay를구하기위해 M/M/1 큐잉모델 [16] 에서정의한아래식을사용하였다. 수식 1, 수식 2, 수식 3, 수식 4에서사용한기호의의미는다음과같다. 그림 14. 제안알고리즘의동작과정동작과정은아래의순서와같다. 1 모바일노드가외부망으로이동 2 모바일노드는 FA(Foreign Agent) 로부터 Agent Advertisement 수신하고새로운 CoA를획득 3 모바일노드는 HA(Home Agent) 에게 Registration request를보내새로운 CoA를등록하고이에대한응답으로 Registration replay를수신 4 모바일노는 IPv6 네트워크의 CN에게새로운 CoA를포함한 Registration request를보냄 5 NAT-PT는모바일노드가보낸 Registration request 메시지를 Mobility 헤더변환알고리즘을이용하여 Mobile IPv6 메시지인 Binding Update 메시지로변환하여 CN에게전달 6 CN은모바일노드의새로운이동위치를확인후 Binding Acknowledge를모바일노드에게보냄 7 NAT-PT는 CN이보낸 Binding Acknowledge 메시지를 Mobility 헤더변환알고리즘을이용하여 Mobile IPv4 메시지인 Registration reply 메시지로변환하여모바일노드에게전달 Ⅳ. 실험및결과제안알고리즘의성능평가를위하여 M/M/1 큐잉 Service time(ts): 노드에들어온패킷을처리하는시간 Node utilization( ): 노드가일을하고있는비율이다. 예를들어 node utilization이 1인경우는서버가 100% 일을하고있다는의미로도착한패킷들은서버에서서비스를제공받을수없으며큐에서대기해야한다. Transmission time(tr): 노드에들어온패킷을처리하고전송하는시간 Propagation delay(pd): 전파지연시간 (1) (2) (3) (4) 수식 5와수식 6에서사용한기호의의미는다음과같다. TD: Total Delay DA_B: 노드 A에서노드 B까지의 Propagation Delay PDA: 노드 A에서의 Processing Delay n: 네트워크에서의라우터의수 HA_V4 IPv4 Network FA MN Packet IPv6 Network CN_V6 그림 15. SIIT 알고리즘만적용된네트워크에서의 Total Delay 67

8 한국통신학회논문지 07-1 Vol. 32 No. 1B (5) 그림 15는기존 NAT-PT가적용된네트워크에서의 Total Delay를보여준다. 기존 NAT-PT가적용된네트워크에서는모바일노드가이동시 IPv6의 CN은모바일노드의이동위치를알수가없으므로삼각형라우팅을통해통신을해야한다. HA_V4 MN IPv4 Network FA Packet IPv6 Network CN_V6 그림 16. 모바일헤더변환알고리즘이적용된네트워크에서의 Total Delay (6) 그림 16은본논문에서제안하는모바일헤더변환알고리즘이적용된네트워크에서의 Total Delay 를보여준다. SIIT 알고리즘뿐만아니라모바일헤더변환알고리즘을 NAT-PT가지원해줌으로써 IPv6 CN은모바일노드의이동위치를알수가있다. 따라서그림 15와같은삼각라우팅을발생하지않는다. 실험은 IPv4 네트워크에서홉수를증가시킬경우, IPv4 네트워크에혼잡이증가할경우그리고 IPv6 네트워크에혼잡이증가할경우로구분하여 End-to-End Delay를기존 NAT-PT가적용된네트워크와비교하였다. 실험매개변수와결과는아래와같다. Packet arrived rate Transmission time Propagation delay Time(sec)) packet/sec 0.3 sec 50,000m * ( 3 * 108m/s) End-to-End Delay hop count 그림 17. IPv4 네트워크홉수를증가한실험결과 Current Scheme Proposed Scheme 그림 17의실험결과는표 1의매개변수에서다른조건은동일하게두고 IPv4 네트워크의홉수를증가시키며 End-to-End Delay를측정한결과이다. 모바일노드가자신의홈네트워크에서점점멀어져도기존 NAT-PT가적용된네트워크보다더적은 End-to-End Delay를실험결과가보여준다. 표 2. IPv4 네트워크의혼잡증가를포함한매개변수 Parameter Simulation 2 IPv6 network IPv4 network Hop count 3 Packet length 1000 bits Service time 0.12 sec Increase value Packet arrived rate 0.5 packet/sec Increase value Transmission time 0.3 sec Increase value Propagation delay 50,000m * ( 3 * 108m/s) 표 1. IPv4 네트워크의홉수의증가를포함한매개변수 Parameter IPv6 network Simulation 1 IPv4 network Hop count 3 Increase value Packet length Service time 1000 bits 0.12 sec 그림 18. IPv4 네트워크의혼잡이증가한실험결과 68

9 논문 / Mobile IPv4/Mobile IPv6 통신을위한모바일헤더변환메커니즘 그림 18의실험결과는표 2의매개변수에서다른조건은동일하게두고 IPv4 네트워크의혼잡을증가시키며 End-to-End Delay를측정한결과이다. IPv4 네트워크에혼잡이점점더증가해도기존 NAT-PT가적용된네트워크보다더적은 End-to-End Delay를실험결과가보여준다. 표 3. IPv6 네트워크의혼잡증가를포함한매개변수 Parameter IPv6 network Simulation 3 Hop count 3 Packet length Service time Packet arrived rate Transmission time Propagation delay Increase value Increase value Increase value 1000 bits IPv4 network 0.12 sec 0.5 packet/sec 0.3 sec 50,000m * ( 3 * 108m/s) 그림 19. IPv6 네트워크의혼잡이증가한실험결과 그림 19의실험결과는표 3의매개변수에서다른조건은동일하게두고 IPv6 네트워크의혼잡을증가시키며 End-to-End Delay를측정한결과이다. IPv6 네트워크에혼잡이점점더증가해도기존 NAT-PT가적용된네트워크보다더적은 End-to-End Delay를실험결과가보여준다. 위의세가지실험에서볼수있듯이모바일노드가홈네트워크로부터멀어져도, IPv4 네트워크에혼잡이증가해도그리고 IPv6 네트워크에혼잡이증가해도기존 NAT-PT가적용된네트워크보다더적은 End-to-End Delay를보여주었다. 그이유는기존 NAT-PT가적용된네트워크는 IPv4/IPv6 헤더변환만지원하여 IPv6 네트워크의호스트가 IPv4 네트워크의모바일노드의이동위치를알수 가없으므로삼각형라우팅을통해통신하기때문이다. 이와는다르게본논문에서제안하는모바일헤더변환알고리즘이적용된네트워크에서는 IPv6 네트워크의호스트들이 IPv4 네트워크의모바일노드의이동위치를알수가있으므로삼각형라우팅문제가발생하지않는다. 따라서기존기법보다더적은 End-to-End Delay를실험결과들을통해확인할수있었다. Ⅴ. 결론 본논문에서는 IPv4와 IPv6 간의변환기법에대하여살펴보았고무선네트워크환경에서모바일노드의이동성으로인해발생되는문제점을기술하였다. Mobile IPv4를사용하는모바일노드와 IPv6 네트워크에있는호스트간의통신을하기위해서는 NAT-PT에서 IPv4/IPv6 헤더변환뿐만아니라 Mobile IPv4/Mobile IPv6 간의헤더변환도지원해야하지만기존 NAT-PT에서는 Mobile IPv4/ Mobile IPv6 간헤더변환을지원해주지않는다. 따라서 IPv4 네트워크에있는 Home Agent가터널링을통해외부망에있는모바일호스트로패킷을전달해줘야한다. 하지만이때삼각형라우팅문제가발생하고비효율적인라우팅이발생하게된다. 따라서본논문에서는삼각형라우팅문제를해결하기위해 Mobile IPv4와 Mobile IPv6의변환알고리즘을고안하여모바일노드와 CN과의경로최적화를이룰수있는방안을제안하였다. 향후과제로는여러가지네트워크상황에서의 Mobile IPv4와 Mobile IPv6 간의변환메커니즘들을정의하고구현을통한검증이필요하다. 참고문헌 [ 1 ] C. perkins, Et al., IP Mobility Support for IPv4, RFC 3220, January 2002 [ 2 ] Deering, S. and R. Hinden., Internet Protocol, Version 6 (IPv6)Specification, RFC 2460, December [ 3 ] K. Tsuchiya, H. Higuchi, Y. Atarashi., Dual Stack Hosts using the Bump-In-the-Stack Technique (BIS)., RFC 2767, February [ 4 ] C. Huitema, R. Austein, S. Satapati, R. van der Pol., Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks., September

한국통신학회논문지 07-1 Vol. 32 No. 1B [ 5 ] D. Black., Differentiated Services and Tunnels., RFC 2983, October 2000. [ 6 ] G.Tsirtsis, et al.

10 한국통신학회논문지 07-1 Vol. 32 No. 1B [ 5 ] D. Black., Differentiated Services and Tunnels., RFC 2983, October [ 6 ] G.Tsirtsis, et al., Network Address Translation - Protocol Translation (NAT-PT), RFC 2766,February [ 7 ] C. Perkins et al., Mobility Support in IPv6, RFC 3775, June [ 8 ] E. Nordmark., Stateless IP/ICMP Translation Algorithm (SIIT)., RFC 2765, February [ 9 ] I.Vivaldi, M. H. Habeabi, B. M. Ali, and V. Prakash., Fast Handover Algorithm for Hierarchical Mobile IPv6 Macro-Mobility Management, In the Proceedings of The Asia-Pacific Conference on Communications, 3(270): , September [ 10 ] Z. G. Kan, J. Ma, J. Luo, and J. P. Hu., Mobile IPv6 and Some Issues for QoS, Internet Society, [ 11 ] T. Kato, R. Takechi, and H. Ono., A Study on Mobile IPv6 Based Mobility Management Architecture, Fujitsu Sci. Tech., 37(l):65-71, June [ 12 ] R. Koodli., Fast Handovers for Mobile IPv6, Technical report, Mobile IP Working Group, October [ 13 ] B. L. Ong and S. Hassan., Mobile IPv6 Architectures and the QoS Issue on Handover Delay, In the Proceedings of National Seminar 2002, University Teknologi Mara, November [14] H. Soliman, C. Castelluccia, K. E. Malki, and L. Bellier., Hiearchical Mobile IPv6 Mobility Management (HMIPv6), RFC 4140, Network Working Group, August [ 15 ] S. Zeadally and D. Mavatoor., Mobile IPv6 Support For Highly Mobile Hosts, In the Proceedings of IASTED International Conference, pages , September [ 16 ] Gunter Bolch et al., Queueing networks and Markov chains, Wiley-Interscience, 김대선 (Dae Sun Kim) 준회원 2002년 2월경희대학교전자계산공학과졸업 ( 학사 ) 2004년 2월경희대학교컴퓨터공학과졸업 ( 석사 ) 2004년3월~ 현재경희대학컴퓨터공학과박사과정 < 관심분야 > Mobile IP6, IPv6, NEMO, Sensor Networks 홍충선 (Choong Seon Hong) 정회원한국통신학회논문지제31권제10B호참조 70

[ 네트워크 1] 3 주차 1 차시. IPv4 주소클래스 3 주차 1 차시 IPv4 주소클래스 학습목표 1. IP 헤더필드의구성을파악하고요약하여설명할수있다. 2. Subnet ID 및 Subnet Mask 를설명할수있고, 각클래스의사용가능한호스트수와사설 IP 주소및네트

[ 네트워크 1] 3 주차 1 차시. IPv4 주소클래스 3 주차 1 차시 IPv4 주소클래스 학습목표 1. IP 헤더필드의구성을파악하고요약하여설명할수있다. 2. Subnet ID 및 Subnet Mask 를설명할수있고, 각클래스의사용가능한호스트수와사설 IP 주소및네트 3 주차 1 차시 IPv4 주소클래스 학습목표 1. IP 헤더필드의구성을파악하고요약하여설명할수있다. 2. Subnet ID 및 Subnet Mask 를설명할수있고, 각클래스의사용가능한호스트수와사설 IP 주소및네트워크주소와 브로드캐스트주소를설명할수있다. 학습내용 1 : IP 헤더필드구성 1. Network Layer Fields 2. IP 헤더필드의구성 1)