Mobile IPv6 표준화 및 기술 동향
유준석* 나재훈** 손승원***
향후 IT 환경은 정보단말이나 정보가전을 포함한 대부분의
기기들이 네트워크로 서로 연결되고 All-IP 기반의 유무선이 통합된 형태의 네트워킹 환경이 될 것으로
예상되고 있다. 이러한 추세에 따라서 IPv4에서 IPv6로의 전환은 필수적인 것으로 받아들여지고 있으며, Mobile
IPv6(MIPv6)는 이러한 All-IP 기반의 차세대 유무선 통합망 구축을 위한 핵심기술로서 IPv6의 도입이 가속화되고 있는 최근 들어서 더욱 주목받고 있는 기술 분야이다. 본 고에서는 Mobile IPv6에 대한 전반적인 표준화 및 기술, 그리고 관련 보안 기술 동향에 대해서 살펴보고자 한다. ▧
I. 서 론
인터넷 주소의 고갈 문제로 인하여 IETF 주도로 표준화가
이루어지고 있는 IPv6는 충분한 인터넷 주소공간의 제공뿐 아니라
IPsec의 필수 사용으로 인하여 향상된 보안기능을 제공할 수 있다는 특성을 가진다. 이
외에도 자동구성(Auto-Configuration) 및 이동성(Mobility)을
고려한 설계로 인하여 IPv4에 비하여 효율적인 네트워킹 환경을 구성할 수 있다는 특성을 지닌다[1]. 현재까지 IPv6 관련한 기본규격 및 여러가지 부가적인 기술들은 10여년의 표준화 작업을 통하여 대부분 마무리 단계에 들어선 상태이다. 하지만 Mobile IPv6를 포함하여 IPv6를 기반으로 하는 몇몇 기술은
아직까지 표준화가 이루어지지 못하고 있다. Mobile IPv6에서의 표준화 지연은 여러가지 문제에
기인하고 있지만 보안문제의 미결이 가장 큰 걸림돌로 작용하고 있는 것으로 보인다. 최근 IETF에서도 표준화 지연의 문제를 인식하고 기존 Mobileip 작업반을
몇 개의 작업반으로 세분화하여 표준화 작업에 박차를 가하고 있다[2].
우리나라의 정보통신부는 2006년경부터 현 인터넷주소(IPv4)가 고갈될 것이라는 예측을 하고 있으며, IPv6의 보급과
확산을 촉진하고자 다각적인 노력을 경주하고 있다[3]. 이러한 취지에 따라서 정보통신부는 2001년도부터 IPv6 도입을 위한 계획을 수립하여 시행하고 있으며, 2003년 9월부터 IPv6의
도입을 더욱 활성화하기 위하여 ‘IPv6 보급 촉진 계획’을 새로이 수립하여 추진 중에 있다. 본 계획에서는 2010년 이후에는 All-IPv6 기반의 유무선 통합망이 구축되어
사용될 것으로 예상하고 있으며, 이러한 통합망에서의 이동인터넷 서비스 도입을 위해 Mobile IPv6에 대한 세부 개발계획을 세워 추진하고 있다[3]. (그림 1)은 2007년까지 구축을 계획하고 있는 유무선 통합 IPv6망의 구성 예상도이다.
본 고에서는 IPv6와
Mobile IPv6의 도입 및 기술개발 현황과 Mobile IPv6의 보안 관련 동향에
대해서 살펴보도록 한다.
II. Mobile IPv6 동향
Mobile IPv6 기술에 대한 일반적인 내용은
주간기술동향 1021호 등에서 다룬 바 있으므로 본 절에서는 최근의 표준화 동향 및 관련 기술 동향에
대해서만 기술하도록 한다.
1. Mobile IPv6의
표준화 동향
Mobile IPv6는 IETF에서 제안되어 Internet Area 내의 Mobileip 작업반에서 모든 관련 표준화 작업이 진행되어 왔다. 현재 Mobile IPv6의 기본규격안인 “Mobility support in IPv6”는
draft-ietf-mobileip-ipv6-24 버전까지 진행되어 있는 상태이며, Mobile
IPv6의 보안사항과 관련된 “Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents”는 draft-ietf-mobileip-mipv6-ha-ipsec-06 버전까지 진행되고 있다. 그러나 2003년 3월에
열린 제56차 IETF 회의에서는 Mobile IPv6에 대한 표준화 작업을 보다 효율적이고 신속하게 진행할 수 있도록 향후 방향을 논의하기 위한 NSIIM(Next Steps In IP Mobility) BoF (Birds of Feather) 회의가 개최되었고
이 회의에서의 합의에 따라서 현재는 기본규격안 개발 작업을 주요 업무로 할 mip6 작업반과 시그널링
오버헤드의 절감과 및 효과적인 핸드오프에 대한 개발을 수행 할 mipshop 작업반으로 나뉘어 Mobile IPv6에 대한 표준화 작업을 진행하고 있다[2]. <표 1>은 세분화된 작업반에 대한 내용이다.
참고적으로 Mobile IPv4와 관련해서는 기본규격(RFC 3344)이 안정화 단계에 들어섰으며, NSIIM BoF의
결과에 따라 mip4 작업반이 구성되었다. Mip4 작업반에서 Mobile IPv4의 deployment 과정에서 발생하는 단점
및 문제점들을 보완하고 AAA 환경과의 연동 등에 관련된 작업을 수행하게 된다[4].
2. 국내외 기술 동향
가. IPv6
Mobile IPv6의 기반이 되는 IPv6는 1990년대 중반에 개발되기 시작하여, 1990년대 후반부터 세계 각국에서는 6Bone을 통한 실험망이
구축되기 시작하였다. 2000년에 들어서면서는 리눅스나 윈도우를 포함한 대부분의 운영체제에 IPv6가 탑재되기 시작하였고, 시스코, 쥬니퍼, 노텔, 히타치, IIJ 등의 업체들을 중심으로 IPv6 지원 네트워크 장비가 본격적으로
출시되기 시작하여 현재는 다수의 장비업체에서 IPv6를 지원하고 있다.
최근 들어서는 ISP(Internet Service Provider) 사업자들에 의한 IPv6 상용망 구축과 민간 차원에서의 IPv6 응용 기술 개발 노력이
활성화되고 있는 추세이다.
우선 IPv6와 관련하여 가장 활발한 활동을 하고 있는
대표적인 국가는 일본이다. 일본은 1998년부터 IPv6 실험망을 구축하기 시작하여 현재 미국보다 많은 47개의 IPv6 주소를 할당받아 운영중에 있으며, WIDE, KAME, TAHI 등
다수의 IPv6 관련 프로젝트를 통하여 기본 기술개발 및 망의 연동 시험 등을 진행하고 있다. 특히, IPv6 장비 개발 및 채택에 대한 세금우대 등을 통해 IPv6 도입을 위한 강력한 정책을 시행함으로써 민간업체들의 기술개발 및
IPv6 도입을 촉진하고 있다[2,3].
미국의 경우 1997년부터 차세대 인터넷 프로젝트를 수행하여 1998년부터는 vBSN이라는
IPv6망을 운영하고 있으며, IPv6 도입을 활성화하기 위하여 2008년까지 국방전산망을 IPv6망으로 전환하는 계획을 추진 중이다. 또한 마이크로소프트사는 2001년 후반부터 Windows XP에 IPv6를 탑재하여 출시하고 있으며, Windows Server 2003과 Windows CE 4.1 버전부터 IPv6 프로토콜 스택을 제공하고 있다[5]. 이 외에도 SUN, HP 등의 서버 및 소프트웨어 업체를 비롯하여 시스코, 쥬니퍼
등의 네트워크 장비업체에서 IPv6를 탑재한 제품을 출시하고 있다.
중국은 2000년부터 연구교육망인 CERNET이라는 IPv6 테스트망을 구축하여 관련 연구를 시작하였다. 2002년에는 6TNET(IPv6 Telecom Trial Network)을
구축하여 상용화를 목적으로 기술개발을 본격화 하고 있다. 2003년에는 민간주도의 China IPv6 Council을 설립하여 IPv6 보급 촉진을
위해 노력하고 있다. 또한 중국은 미국 주도의 인터넷 환경에서 독립하기 위하여 독자 표준인 IPv9의 개발을 별도로 추진하고 있는 것으로 알려지고 있다[3].
국내의 경우는 정부 주도로 한국전자통신연구원 및 한국전산원 등에서
IPv6망 구축, IPv6기반기술 개발 및 표준화 등의 사업을 진행하고 있다. 한국전자통신연구원의 경우 1998년에 6Bone으로부터 최상위 주소를 할당받아 국내 최초의 실험망인 6Bone-KR을
구축하여 운영 중이며, IPv4/IPv6 주소 변환기술 등을 개발하였다. 특히, IPv4/IPv6 변환기술과 관련하여 두 건의 기술이 IETF에서 RFC로 채택되는 성과를 올린바 있다[6]. 2003년부터는 IPv6 서비스기술개발에 초점을 맞추어 사업이
진행되고 있다[2,6].
한국전산원은 2000년부터 추진된 ‘차세대인터넷기반구축사업’의 추진을 통하여 6NGIX(Next
Generation Internet eXchange)라는 IPv6 교환노드를 구축하였으며, 6KANet(IPv6 Korea Advanced Network)이라는 국내 최초의 상용망을 구축하여 공공기관과
연구기관을 대상으로 서비스 중이다. 또한 최근에는 ‘차세대인터넷응용구축사업’을 통하여 각 부문에서의
IPv6 기반 응용 및 서비스 연구개발을 촉진시키고자 노력하고 있다[2,7].
민간에서는 하나로 통신, SK 텔레콤, KT 등에서 시범망 구축을 추진하고 있으며, IPv6 기반의 서비스
기술개발을 위해 여러 업체 및 기관에서 다양한 연구를 수행하고 있다. 아이투소프트는 IETF에서 국제표준으로 채택된 BIA(Bump In the API) 기술을
상용화하였고, 현재 IPv6에서 VoIP 구현을 위한 기술을 건국대와 함께 개발 중이다[3]. 아이엠넷피아는
하나로통신, 광운대와 함께 Mobile IPv6를 활용한
핸드오프 지원기술을 개발중에 있으며, IPv6 기반의 웹 카메라,
P2P에 적용할 수 있는 솔루션 등도 개발중이다[3]. 또한 신라이엔지는 IPv6를 지원하는 웹하드를 개발하였다. 이 외에도 에스넷시스템, 모다정보통신, 포씨소프트, 위즈정보기술
등에서도 IPv6 기반의 다양한 응용 제품 및 IPv6 변환
솔루션을 개발하고 있으며, 삼성과 LG에서는 IPv6용 라우터를 개발중이다[8].
나. Mobile IPv6
앞절에서 간략히 살펴 본 바와 같이 세계 각국에서 IPv6 도입을
위한 기본 인프라의 구축 작업이 어느 정도 성과를 보이면서 향후 연구개발의 초점은 응용 및 서비스 기술에 맞추어질 것으로 예상된다.
이와 관련해서 현재 Mobile IPv6 관련 표준화가
아직 완료된 상태는 아니지만 세계 각국의 주요 기업이나 연구소를 중심으로 Mobile IPv6를 구현하는
프로젝트가 진행중이며, 일부 기업에서는 이미 상용화 제품에 탑재하여 출시하고 있다.
Mobile IPv6를 구현하는 대표적인 프로젝트는
헬싱키 대학에서 진행하고 있는 MIPL이다. MIPL은 리눅스상에서 Mobile IPv6를 구현하고 있으며, 현재 리눅스 커널 2.4.22에 기반하여 draft-ietf-mobileip-ipv6-24를
구현한 버전 1.0까지 릴리스되어 있다[9]. 일본의 KAME는 히타치, 후지쓰,
NEC, 도시바 등의 6개 업체가 주축이 되어 2000년부터
진행된 프로젝트로써 다양한 BSD에 IPsec 및 Mobility 등을 지원하는 IPv6 프로토콜을 탑재하는 것을 목표로
하고 있다. 현재 대응노드 관련 코드는 완료되었고 이동노드와 홈 에이전트에 대한 구현은 표준화 작업이
완료될 때까지 미루어진 상태이다[10]. 이 외에도 마이크로소프트, 노키아, 에릭슨 등 다수의 기업에서 Mobile IPv6 관련 연구가 수행중이며, <표 2>는
Mobile IPv6 구현 및 연구개발과 관련된 프로젝트들 중 일부 내용이다.
우리나라의 경우 ‘IPv6 보급 촉진 계획’에서 Mobile IPv6 관련
서비스 제공을 위한 세부 연구계획을 수립하고 응용 서비스 개발에 박차를 가하고 있으나 아직까지 국내의
Mobile IPv6 기술은 산업체나 학계에서 대부분 초기단계의 연구가 진행되고 있는 것으로 파악된다. 특히 삼성전자의 디지털 미디어 연구소에서는
Mobile/Digital/Home Appliance 간의 네트워킹에 필요한 소프트웨어 및 하드웨어 솔루션을 확보하기 위한 연구를
수행하고 있다. 이러한 연구의 일환으로 삼성전자는 임베디드 리눅스에 기반한 자사의 모바일 단말에 탑재할 Mobile IPv6를 개발하고 있으며, IPv6, Mobile IPv6,
IPsec, TCP/UDP를 탑재한 하드웨어 칩을 개발중이다[11].
III. Mobile IPv6 관련 보안기술
Mobile IP에서의 보안 취약성에 대한 내용은
주간기술동향 1050호에 상술되어 있으므로, 본 고에서는
개괄적인 내용과 관련 동향만을 살펴보도록 한다.
1. Mobile IPv6 보안기술
개요
Mobile IPv6는 IPv6에 기반하여 단말에 이동성을 제공하기 위해 새롭게 정의된 프로토콜로써 이동성은 단말의 이동전 주소인 홈주소(Home Address)와 이동후에 새롭게 설정된 임시주소(Care-of
Address)의 처리에 의해 이루어진다. 특히, 상위계층
프로토콜에 대해 투명성을 제공하기 위해 홈 주소와 임시주소를 바인딩하여 서로 연계시키는 구조로 설계되어 있다.
Mobile IPv6에서 이러한 바인딩 관련 정보는 네트워크의 효율성과 안전성에 매우 중대한 영향을 끼친다. 바인딩 정보에 대한 보안 메커니즘이 없다면 공격자는 쉽게 IPv6 패킷의
목적지를 변경할 수 있으며, 따라서 바인딩 관련 정보에 대한 악의적 사용은 심각한 보안 문제를 야기시킬
수도 있다. 결국, 이러한 문제점을 극복하고 보다 효율적이고
안전한 주소 생성 및 바인딩 처리를 위해 홈 에이전트, 이동노드, 대응노드
사이에는 여러 가지 보안 메커니즘이 사용되어야 한다.
2. Mobile IPv6 보안
메커니즘 및 동향
Mobile IPv6에 존재하는 여러 가지 보안
취약점을 해결하기 위해서 현재 draft-ietf-mobileip- ipv6-24 버전에서는 이동노드와
홈 에이전트 사이에 IPsec을 사용하고 이동노드와 대응노드 사이에서
RR(Return Routability) 프로토콜의 사용을 명시하고 있다[4]. 이 외에도 Mobile IPv6를 AAA(Authentication,
Authorization and Accounting) 인프라와 연계하여 도메인간의 로밍을 지원하고 보안성을 향상시키려는 논의도 진행되고
있다.
(그림 2)는 현재 Mobile IPv6에서 사용이 고려되고 있는 보안 메커니즘을 도식화하여 보여주고 있다.
가. IPsec
현재 Mobile IPv6에서는 이동성으로 발생하는 문제점을
극복하기 위해 홈 에이전트와 이동노드 사이의 보안 프로토콜로써 IPsec을 사용하고 있다. IPsec은 이동단말과 홈 도메인의 홈 에이전트 사이에 설정된 보안연계를 통하여 메시지를 인증할 수 있다. 이러한 메시지는 바인딩 갱신(Bing Update) 및 바인딩 응답(Binding Acknowledgement) 메시지, RR 관련 메시지(HoTI, HoT), 프리픽스 정보를 포함한다. 현재 보안연계 설정은
수동설정을 필수로 하고 IKE와 같은 자동설정은 선택으로 지원하도록 하고 있다.
나. RR(Return
Routability)
RR 프로토콜은 이동노드와 대응노드 사이에서 바인딩 갱신 및 바인딩
응답 메시지를 인증하기 위해서 사용되는 보안연계를 생성한다. 현재
draft-ietf-mobileip-ipv6-24 버전에서 RR의 사용을 명시하고 있으나
좀 더 향상된 보안을 위해서 RR을 대체할 수 있는 새로운 프로토콜이 필요하다는 의견도 제기되고 있다. 향후 기본규격을 제정하는 데에 있어서 주요 이슈가 될 것으로 예상된다.
다. AAA
IPsec만을 사용하는 경우 이동단말과
홈 도메인의 홈 에이전트간에 보안연계를 설정하고 메시지를 인증할 수 있지만 이동단말이 로밍을 하는 경우, 즉
방문망에서 이동 서비스를 받고자 하는 경우에 이동단말은 방문망에서 네트워크에 접속할 수 있는 권한을 인증 받아야 한다. 그러나 IPsec에서는 ISP 도메인 A에 등록된 이동단말이 다른 도메인 B로 이동했을 때, 이동한 망에서는 이동단말이 정말로 도메인 A에 등록된 단말인지를
판단할 수 없다. 이러한 경우에는 ISP 사이에 서로 인증, 권한검증 및 과금 등의 정보를 교환할 수 있는 방법이 있어야 하며, 그러한
문제의 해결 방법으로 논의되고 있는 것이 AAA 인프라를 활용하는 것이다. IETF의 AAA 작업반 및
Mobileip 작업반 등에서 관련 작업을 수행 중이지만 아직까지는 Mobile IPv4에
대한 내용이 주를 이루고 있고 Mobile IPv6와 AAA 인프라와의
연동에 관한 논의는 몇몇 draft가 발표되기도 하였으나 미비한 수준이다.
<표 3>은 지금까지 제안되었던 Mobile IPv6와 AAA 인프라의 연동에 대한 기고서들이다.
위 기고서의 세부 내용은 조금씩 상이하지만 Mobile IPv6와 AAA를 연동시키는 과정에서 기존 Mobile IPv6의 일부 기능이 AAA 작업 수행중에 함께 처리되도록 함으로써 Mobile IPv6의
성능과 보안상의 문제를 해결하고자 한다는 점에서 동일한 맥락을 가지고 있다. 즉, AAA 처리를 위해 기본으로 교환되는 메시지에 Mobile IPv6의
특정 기능 수행을 위한 메시지를 포함시키겠다는 것으로 BU/BA 메시지와 SA설정을 위한 메시지가 이에 속한다.
3. 국내외 연구 동향
현재까지 Mobile IPv6의 보안 문제만을 연구개발하는
별도의 프로젝트는 없으나 IETF의 관련 작업반 내에서는 활발한 논의가 이루어지는 것으로 보인다. 다만 기존 IPv6 구현 프로젝트나 주요 기업들에서 Mobile IPv6의 기본규격안을 개발하는 과정에서 규격안에서 명시하고 있는 보안 기능들을 구현하는 수준 정도에서
연구가 이루어지고 있다.
대표적인 예로 일본의 몇몇 지원자들이 주축이 된
USAGI(UniverSAl playGround for Ipv6) 프로젝트는 리눅스 커널에 우수한
IPv6 프로토콜 스택을 구현한다는 목표로 시작되어 초기에는 기존 리눅스 소스 트리에 개발 코드를 추가하였다. 하지만 기존 리눅스의 IPv6 코드에 버그나 미구현 기능들이 많다는
것을 이유로 현재는 KAME 코드를 기반으로 기능을 추가하고 있으며,
KAME 외에도 WIDE, TAHI 프로젝트와 긴밀한 협조하에 진행되고 있다. 2003년 8월까지 MIPL과 FreeS/Wan에 기반하여 IPsec이 지원되는 Mobile IPv6의 코드를 구현하였다. 그러나 관리상의 어려움
등을 이유로 현재는 커널에서 삭제된 상태이며, 향후에 Mobile
IPv6와 IPsec을 추가한 새 코드를 발표할 계획이다[12].
IV. 결 론
Mobile IPv6는 향후 IPv6 기반의 유무선 통합망 환경에서 필수적인 기술이지만 보안상의 문제 등으로 아직까지 기본규격 제정에 있어서
난항을 겪고 있다. IETF에서도 이러한 문제를 인식하고 기본규격 제정을 위해 좀 더 박차를 가하고
있으므로 조만간 결과물이 나올 수 있을 것으로 보이며, 이에 따라서 향후 Mobile IPv6를 비롯하여 IPv6를 기반으로 하는 다양한 응용
및 서비스 기술 개발은 더욱 급물살을 탈 것으로 예상된다.
<참 고 문 헌>
[1] 차세대 인터넷 프로토콜
IPv6, IPv6 포럼 코리아, 다성출판사
[2] 한국정보통신기술협회,
http://www.tta.or.kr
[3] 정보통신부,
http://www.mic.go.kr
[4] IETF, http://www.ietf.org
[5] 마이크로소프트,
http://research.microsoft.com/msripv6
[6] 한국전자통신연구원,
http://www.etri.re.kr
[7] 한국전산원,
http://www.nca.or.kr
[8] 전자신문,
http://www.etnews.co.kr
[9] MIPL, http://www.mipl.mediapoli.com/
[10] KAME,
http://www.kame.net
[11] Mobile IPv6 over
IEEE 802.1b WLAN, 삼성전자 세미나 자료
[12] USAGI,
http://www.linux-ipv6.org
IPv6 over MPLS 기술 개발 동향
김승진* 최준균** 이계선*** 류호용***** 양선희*****
인터넷
사용자가 증가하면서 IPv6를 도입하기 위한 노력이 진행 중에 있으며,
다른 한편으로 차세대 NGN으로 MPLS의 도입을
하고자 하는 움직임이 나타나고 있다. 이에 따라, 기업 및
학교 연구소에서 IPv6 over MPLS 에 대하여 많은 연구가 이루어지고 있다. 본 논문에서는 도입 가능한 IPv6 over MPLS 시나리오를
살펴보고, 현재까지의 표준화 동향에 대하여 간단하게 정리한 다음, 마지막으로
현재 실현 가능한 MPLS 6PE 시나리오에 대하여 자세히 설명하고,
이 시나리오에 대한 시험 내용인 AYAME 프로젝트에 관하여 살펴보고자 한다. ▧
I. 머리말
최근에
인터넷 사용자가 급격하게 증가하여 보다 많은 인터넷 주소를 필요로 하게 되었을 뿐만 아니라 보안 및
QoS(Quality of Service) 등과 같은 보다 나은 서비스의 필요성이 증가하고 있다. 이에
따라 유럽과 미국, 일본에서는 기존의 IPv4(Internet
Protocol version 4) 인터넷 망을 IPv6(Internet Protocol
version 6) 기반의 차세대 인터넷 망으로 도입하기 위한 움직임을 나타나고 있으며, 이에
따른 응용을 위한 노력이 진행되고 있다.
한편, 차세대 NGN(Next Generation Network)으로 MPLS(Multiprotocol Label Switching) 기반의 망을 도입을 하기 위한 움직임이 나타나고
있는데, 이는 MPLS가 라우팅과 패킷 포워딩을 분리하기
때문에 링크 계층의 스위칭 기술을 이용하여 기존의 계층3 라우팅에 비해 빠른 패킷 전달을 제공하기 때문이다. 또한, MPLS는 계층 3와
독립적으로 수행되므로 다양한 계층 3 프로토콜 및 계층 2 미디어를
지원한다. 이에 따라, IPv6 망과 MPLS 망의 연동을 위한 연구가 중요한 이슈로 진행되고 있다.
본
논문에서는 IPv6 over MPLS의 도입 방안에 대하여 살펴보고,
이에 따른 표준화 동향과 연구 개발 동향에 대하여 살펴보도록 하겠다. 또한, IPv6 over MPLS의 도입 방안중에서 가장 가까운 미래에 실현 가능한 시나리오인, IPv4/MPLS의 백본망을 중심으로 여러 개의 IPv6 액세스
망이 구축되었을 때 이들 망의 효율적인 연동을 위한 방안에 대하여 자세히 살펴보고자 한다.
II. IPv6 over MPLS 도입 방안 분석
MPLS 및 IPv6 기술이
차세대인터넷 진화를 위한 핵심 기술로 부각됨에 IPv6 over MPLS 도입 시나리오에 대해서도 초기
연구가 진행되고 있는데, 시스코와 일본의 AYAME 프로젝트
등이 선행연구를 주도하고 있다.
IPv6 기술과
MPLS 기술은 두 기술이 다 기존 인터넷망의 진화를 전제로 하므로 어떻게 단계별로 효율적으로 진화해 나갈 것인가가 관건이 된다. 시스코에서는 가입자 장비, 사업자망 장비에 영향을 최소화하면서, IPv6 및 MPLS 기술의 단계별 확산에 따라 점진적으로 진화가
가능하도록 4가지 시나리오를 설정하고 있다.
첫번째
시나리오는 CE 기반의 IPv6 터널링 시나리오로서, 백본망은 IPv4 기반의 기존
MPLS 망을 사용하고, 가입자 장비에서 IPv6 터널을
구성해 주는 방안이다. 두번째 시나리오는 MPLS L2 가상회선상의 IPv6 연결 시나리오로서, 백본망에서는 MPLS 기반의 L2 가상회선을 구성하고, 이 가상회선을 통해 IPv6 아일랜드들을 연결하는 방안이다. 세 번째 시나리오는 IPv6/ MPLS 완전 통합 시나리오로서 모든
가입자 장비 및 망장비들이 IPv6 기반으로 동작하고, MPLS도 IPv6 기반으로 확장되어 동작하는 방안이다. 마지막으로 6PE over MPLS 시나리오는 백본망은 IPv4 기반 MPLS 망이고, 가입자측은
IPv6 도메인인데, 이들간을 연결하는 PE에서 IPv4/v6 이중 프로토콜을 지원하되, IPv6에 대한 경로정보를 MP-BGP를 통해 전달해주는 방안이다.
백본망에의
두 기술의 도입 시기를 고려하면 MPLS 기술이 먼저 도입되고,
IPv6 기술은 가입자측에서부터 도입되어 백본망에 도입되기까지는 MPLS 보다 더 많은
시간을 필요로 할 것으로 예측된다. 따라서 4가지 시나리오의
단계별 도입 과정은 6PE over MPLS를 거쳐서,
IPv6/MPLS 완전 통합 단계로 진화 발전될 가능성이 클 것이다. 그리고 초기 연구
단계에서는 MPLS 백본망과 무관하게 가입자측에서 IPv6가
지원되는 나머지 두 시나리오가 시험적으로 적용될 수 있을 것이다.
1. CE 기반의 IPv6 터널링 시나리오
CE(Customer Edge) 기반 IPv6 터널링 시나리오는 백본망은 IPv4 기반의 기존 MPLS 망이고, CE 라우터들에서
IPv6 터널을 구성해 주는 시나리오이다. 이 방안은 백본망 MPLS의 구조와 동작에 영향을 주지 않고, PE 및 P 라우터의 구성에도 변화가 없이 IPv6 over MPLS 네트워크를
구현하는 방법이다. (그림 1)에서 보듯이 망장비들은 IPv4 장비들이며, CE 라우터 들에서 IPv4/v6 이중 스택을 지원하여, IPv6 터널을 구성해 주게
된다. MPLS는 IPv6와 관련이 없이 IPv4 기반으로 구성 운영된다.
따라서 기존의 망을 그대로
사용할 수 있으므로, 추가적으로 많은 비용과 시간을 들이지 않고도 구현이 가능하다는 장점을 가지나, CE 라우터들이 진화되어야 한다. IPv6 도입 초기에 IPv6 사이트들이 아주 제한적으로 도입되는 초기 단계에 고려할 수 있는 시나리오이다.
2. MPLS 기반
가상회선을 이용한 IPv6 도메인 간 연결 시나리오
백본망에서는 MPLS 기반의 L2 가상회선을 구성하고, 이 가상회선을 통해 IPv6 아일랜드들이 연결되는 시나리오이다. (그림 2)에서 보듯이 백본망은
MPLS 기반의 L2(ATM, 프레임 릴레이 혹은 이더넷 등) 가상회선망으로 동작하고, IPv6 도메인들은 이 가상회선 상에서 IPv6 기반으로 동작하며, 백본망은 IPv6를 transparent하게 전달해 준다.
따라서 이 시나리오 역시 IPv4 기반의MPLS의 구조와 동작에 IPv6가 영향을 주지 않으므로 MPLS 기반 망에 IPv6 도메인을 용이하게 수용할 수 있는 시나리오이다. 그러나 모든 IPv6 도메인간에 가상회선을 지원해야 하며, 기존의 L2 환경을 갖춘 IPv6 가입자에 대해 초기에 제한적으로 적용할
수 있을 것으로 보인다.
3. IPv6 기반 MPLS 시나리오(Native MPLS Support of IPv6)
이
시나리오는 백본망이 IPv6 라우터로 진화하고, MPLS도 IPv6 기반으로 확장되어 두 기술이 완전히 통합된 시나리오이다. (그림 3)에서 보듯이 방안은 백본망 장비는 IPv6 라우팅과 LDP 프로토콜을 이용하여서 IPv6 over MPLS 네트워크를
구현한다.
이
시나리오는 가입자 장비뿐만 아니라 망장비들도 IPv6프로토콜을 인식할 수 있도록 업그레이드 되어야 하므로, IPv6 프로토콜이 망에 보편적으로 도입되는 IPv6 성숙기에 적용
가능한 장기 시나리오이다.
4. MPLS 6PE 시나리오(6PE over MPLS)
MPLS 6PE 시나리오는
PE 장비에서 MPLS 망 외부의 IPv6 도메인에
대한 라우팅과 이들에 대한 MPLS 레이블 서비스를 지원하도록 하는 시나리오로서, BGP4 기반의 MPLS-VPN의 구조와 거의 동일하다. (그림 4)에서 보듯이 백본망은 IPv4
기반의 MPLS 망으로 동작하되, 6PE 장비들은 MP-BGP(Multi-Protocol Border Gateway Protocol) 확장 프로토콜을 이용하여, IPv6 루트 정보 및 이에 대한 MPLS 레이블 정보를 상호 교환하는
구조이다. 이를 위해 6PE는 IPv4/IPv6의 이중 스택을 지원하면서 MP-iBGP 피어링을
맺고, IPv6에 대한 경로 및 레이블 정보를 교환하는데, 이때 IPv6 Prefix에 대한 도달성 정보 교환을 위해서 IPv4 mapped
IPv6 주소를 사용한다.
이
시나리오는 IPv6 기술의 도입 단계에 적용될 수 있는 가장 현실적인 시나리오로서 많은 실험이 이루어지고
있다.
III. 표준화
동향
IPv6 over MPLS와 관련된 표준화 동향으로, IETF에 제안되었던 기고서들에 대한 내용을 살펴보고자 한다. IPv6
over MPLS에 관한 기고서는 Sub IP Area의
MPLS WG와 Internet Area의 IPv6
WG, 그리고 Operations and Management Area 의 ngtrans(지금은 v6ops으로 바뀜) WG 에서 진행되었다. 현재는
MPLS, IPv6 WG에서 표준화가 진행되고 있으나, 2002년도 이후에는 잠시 주춤한
상태이다. 대표적으로 세가지를 살펴보면 다음과 같다.
“Connecting IPv6 Islands across IPv4 Clouds with BGP” <draft-ietf-ngtrans-bgp-tunnel-04.txt> 기고서는 IPv6 아일랜드 사이에 IPv4
도메인이 존재하는 경우에, BGP를 이용하여 IPv6 도달성
정보를 교환하는 내용을 포함하여, 어떻게 IPv6 아일랜드간에
상호 연결되는 가에 대한 설명을 하고 있다. 한편, “IPv6 Traffic Engineering Tunnel” <draft-ishii-ipv6-te-tunnel-00.txt> 기고서는 RSVP-TE에 의해 만들어진
IPv4 MPLS LSP를 통해서 IPv6 트래픽을 전송하는 방법을 설명하고 있다. 마지막으로, “MPLS label stack encapsulation in IPv6” <draft-ramankutty-mpls-label-encaps-ipv6-00.txt> 기고서는 IPv6 기반의 네트워크에서
MPLS 레이블을 인캡슐레이션하는 방법을 나타내고 있다. 즉, 모든 네트워크가 IPv6로 바뀌었을 때의 MPLS 도입에 관한 내용을 담고 있다. 다음에서 각각에 대하여 자세히
살펴보도록 한다.
1. J. De Clercq, et al., “Connecting IPv6 Islands across IPv4 Clouds with BGP,” <draft-ietf-ngtrans-bgp-tunnel-04.txt>, Jan. 2002
IPv4 도메인을 사이에 두고 IPv6 아일랜드간의 상호연결을 하기 위해서는 아래와 같은 순서가 필요하다.
(1) 각각 IPv6
아일랜드에 듀얼 스택 MP-BGP-speaking 에지(DS-BGP)
라우터가 적어도 하나가 필요하며, 이 라우터들 사이에서
IPv6 도달성 정보의 교환이 이루어져야 한다.
(1.a) 여기에서,
DS-BGP 라우터들은 MP-BGP를 통해서 정보의 교환이 이루어진다.
(1.b) 이렇게 함으로써, Egress DS-BGP 라우터는 자신이 BGP Next Hop임을
알린다.
(2) Ingress DS-BGP 라우터부터 Egress DS-BGP 라우터까지 IPv6 패킷을 터널링한다: Ingress DS-BGP 라우터는 패킷의 목적지 IPv6 주소를
위해, IPv4 도메인 상의 IPv6 패킷을 단계 (1.b)에서의 BGP Next Hop인 Egress DS-BGP 라우터로 터널링한다.
이
때, BGP를 이용하여 IPv4 도메인을 가로질러 IPv6 아일랜드가 연결되기 위해서는 “MP-BGP over IPv4” approach와 “MP-BGP over IPv6” approach의 두 가지 접근방법이 있다.
“MP-BGP over IPv4” approach에서, MP-BGP 라우팅 정보를 보고 터널의 IPv4 종단점을 자동적으로 결정하기 위해서, IPv4-mapped IPv6주소는
패킷을 포워딩해야 하는 DS-BGP라우터를 인정한다. 이것이 Public IPv6 인터넷을 접속하는데 사용된다면 특별한 보안 메커니즘이 없는 터널이 사용된다. “MP-BGP over IPv4” approach 는 “Tunneling over IPv4/GRE tunnel”과 “Tunneling over MPLS LSPs”의 두 가지가
있다.
우선, “Tunneling over IPv4/GRE tunnel”를 살펴보면, Ingress DS-BGP 라우터는 예상된 터널링 헤더의 목적지 주소로써
BGP next hop의 IPv4 주소를 사용한다. 그것은
예상된 터널링 헤더의 근원지 주소로써 그것의 IPv4 주소중 하나를 사용한다.
다음으로
“Tunneling over MPLS LSPs”는, IPv4 백본망이 MPLS를 지원할 때, MPLS LSPs 는 터널링 기술에 의해서 사용되어 지고, 이 LSPs는 LDP나 RSVP같은
존재하는 기술을 사용하여 설정될 수 있다는 것이다. MPLS LSPs 가 “MP-BGP over IPv4” approach 와 함께 사용될 때, Ingress DS-BGP 라우터는 IPv4 헤더를 예상하지 않고 IPv6 헤더의 레이블을 부과한다. 그 레이블은 Ingress DS-BGP 라우터의 시작되는 LSP와 Egress DS-BGP 라우터의 끝부분의 LSP에 관련하여 부과된다. “MP-BGP over IPv4” approach는 싱글 레이블과 함께 사용될 뿐만 아니라 세컨드 레이블과도 함께 사용된다.
한편, “MP-BGP over IPv6” approach 는 IPv4 도메인상에서 IPv6 패킷을
운반하기 위하여 ngtrans 터널 메커니즘을 따른다. 터널의
종단을 결정하기 위하여, DS-BGP 라우터는 Egress
DS-BGP 라우터의 IPv6 주소상에서 적절한
ngtrans 터널 메커니즘을 적용한다. 그리하여,
BGP Next Hop이 사용된 ngtrans 메커니즘과 모순이 없을 때, Egress DS-BGP 라우터의 IPv6 주소는 MP-BGP에 광고하게 된다.
2. H. Ishii, et al., “IPv6 Traffic
Engineering Tunnel”, <draft-ishii-ipv6-te-tunnel-00.txt>, Nov. 2001
현재 RSVP-TE에 의해 만들어진 많은 네트워크들이 있다. 다음은 노드들간에 MPLS 도메인이 존재할 때, IPv6 트래픽이 전송될 IPv4 MPLS LSP를 설정하는 메커니즘에 대한 설명이다.
(1) IPv4 MPLS LSP들이 RSVP-TE를 사용하여서 IPv4 제어 플레인에 설정된다. IPv4 주소는 각각의 Provider Edge(PE) 라우터를
지정하기 위해서 사용된다. 따라서, RSVP-TE의 명확한
라우트 객체가 사용될 때, IPv4 주소도 사용된다.
(2) IPv4와 IPv6 는 RSVP-TE를 이용하여 설정된 IPv4 MPLS LSP를 따라서
전송된다. PE 라우터에서, 사용자는 IPv4와 IPv6 트래픽을 전달하기 위해 사용되는 LSP를 명확하게 설정한다. IPv4 MPLS LSP는 단지 IPv6를 위해 설정된다. LSP는 단방향 경로이므로 양쪽 방향으로 IP 버전을 설정하는 것이 요구된다.
(3) 라우팅 프로토콜은 설정된 IPv4 MPLS LSP 위에서 동작한다. 이렇게 함으로써, PE 라우터는 Provider(P) 라우터에 직접적으로 라우팅 정보를
교환할 수 있다. P 라우터는 IPv6 라우팅 정보에 대한
내용을 알고 있을 필요가 없다. 이 방법을 사용하여, IPv4
MPLS LSP가 끊어졌을 때, PE 라우터는 도달성의 손실을 검출하고, 라우팅 정보를 갱신할 수 있다.
한편, (2)에서 설명된 것과 같이 IPv4 MPLS LSP 위에서 전달되는 IP 버전을 분류함으로써, IPv4와 IPv6의 트래픽을 관리, 제어를 할 수 있다. 이 방법을 이용하여, IPv4와
IPv6의 트래픽은 다른 IPv4 MPLS LSP에 분리될 수도 있고, 하나의 IPv4 MPLS LSP에 같이 존재할 수도 있다.
3. S. Radhakrishnan, et al., “MPLS label stack encapsulation in IPv6”, <draft-ramankutty-mpls-label-encaps-ipv6-00.txt>, Jun.
2001
IPv6 Destination Option 또는 Flow-field 는 MPLS 레이블을 인캡슐레이션 하는데 사용된다. Egress 라우터와 Ingress 라우터에서 LDP는 어떤 레이블이 사용될 지를 동의하고, 이 레이블은 IPv6 Flow Label에 인캡슐레이션 된다. 현재, LDP 피어를 찾기 위한 두 개의 메커니즘이 있는데, 직접적으로
연결되어 있는 LDP 피어를 찾는데 사용되는 Basic
Discovery가 있고, 직접적으로 연결되어 있지 않은
LDP 피어를 찾는데 사용되는 Extended Discovery가 있다. 이 메커니즘은 Egress 라우터와 Ingress 라우터에서 동작하고 있는 LDP 피어간의 관계를 설정하는
데 사용된다.
LDP 메시지에 있는 새로운 옵션은 IPv6 Destination Option 이나 Flow-Field에
인캡슐레이션된 확장된 레이블을 운반하는데 도입된다. Egress 라우터의 LDP에 의해서 레이블이 Ingress 라우터의 LDP에 분배되면, 그때
Egress 라우터는 패킷에 레이블을 붙인다. Ingress 라우터는 IPv6 패킷의 Destination Option이나 Flow-Field를 보고 포워딩을 판단한다.
IV. 연구 개발
동향
앞에서
설명했던 IPv6 over MPLS 도입을 위한 4가지 방안중에서, 현재 기존망을 그대로 사용하면서 도입이 가능한 MPLS 6PE 시나리오에
관하여 기업과 학교에서 각각 연구가 진행되고 있다. 따라서, MPLS
6PE 시나리오에 대하여 좀 더 자세히 설명하고, MPLS 6PE 시나리오의 접근방안에
대한 시험을 진행중인 AYAME 프로젝트의 내용과 진행 상황에 대하여 살펴보고자 한다.
1. MPLS 6PE 시나리오의
개요
MPLS 6PE 시나리오에서
IPv6 패킷들은 IPv4 트래픽을 위하여 설정된 LSP들을
통하여 IPv4의 라우팅 및 시그널링 메커니즘에 의해서 MPLS 네트워크를
통과한다. 이 시나리오는 앞장에서 살펴보았던 “Connecting IPv6 Islands across IPv4 Clouds with BGP” 기고서에서,
J. De Clercq, et al에 의해 처음으로 “Tunneling over MPLS
LSPs”로 제안되었다.
다음은 MPLS 6PE 시나리오 (그림
5)에서 라우팅 정보가 교환되는 방법과 IPv6 패킷들이
MPLS 네트워크를 통과하는 방법에 대한 과정을 설명하였다.
1. LSP는 IPv4 라우팅
및 시그널링 메커니즘에 의한 MPLS 네트워크를 통해서 에지 LSR 사이에
설정된다.
2. 라우팅 정보는
BGP에 의해서 교환된다. BGP 세션은 IPv4를
사용하는 에지 LSR들 사이에서 LSP를 통해 설정되고, IPv6 라우팅 정보는 이 BGP 세션에서 MP-BGP를 사용하여 전달된다.
3. 광고 라우터의
IPv4-mapped IPv6 주소는 라우트 정보의 BGP NEXT_HOP attribute에서
사용되어 질 것이다.
4. LSR이
NEXT_HOP attribute에서 IPv4-mapped IPv6 주소를 가진 IPv6 라우트를 받았을 때, LSR은 실제 next-hop을 살펴보기 위해서 IPv4 IGP 라우트 테이블을
사용한다. MPLS 네트워크를 지나는 각 라우트의 next-hop은
마지막으로 IPv4 라우팅과 시그널링에 의해서 설정된 LSP를
가리키게 된다.
이러한
방법으로 IPv6 패킷들은 MPLS 백본망에 IGP나 MPLS 시그널을 확장시키지 않고, MPLS 네트워크를 통과할 수 있다.
2. MPLS 6PE 시나리오의
구현
AYAME 프로젝트에서는
MPLS 연구 플랫폼 AYAME의 구현을 진행하고 있는데,
여기에서 6PE의 지원을 구현하기 위해서 기존의
AYAME를 수정하였으며, 그 내용은 다음과 같다.
1. 라우팅 메커니즘에서 IPv4-mapped IPv6 주소의 지원: Zebra 라우팅 소프트웨어는 IPv4-mapped IPv6 주소를 지원하기 위하여 수정되었고, zebrad는 BGP NEXT_HOP으로부터 실제 next-hop을 lookup하도록 확장되었다.
2. IPv6 를 위한
Ingress 지원: IPv6 프로토콜 스택은 들어오는 IPv6
패킷을 위한 적절한 LSP를 인식하는 패킷 분류기를 확장하였다.
3. IPv6 를 위한
Egress 지원: 레이블 스위칭 엔진은 egress
LSR에서 IPv6 패킷을 네트워크층으로 되돌려 놓도록 확장하였다.
3. MPLS 6PE 시나리오의
시험
AYAME 프로젝트에서6PE
테크닉의 가능성과 수행의 안정성을 확인하기 위한 목적으로 MPLS-IX 구조의 시험 네트워크를
구성하고 운영하였다. 6PE-enabled AYAME LSR들은 이 네트워크의 에지 LSR들에 첨가되었다.
가.
MPLS-IX
MPLS-IX는 MPLS 기술을
기초로 한 Internet exchange 구조이다. 그리고, 이것은 MPLS 네트워크에서 많은 가능한 애플리케이션중의 하나이다.
일반적인 MPLS 네트워크은 에지 LSR에 연결된 사용자들이 있는 하나의 네트워크내에
둘러싸여 있는 MPLS 도메인으로 만들어진다. 이와 반대로, MPLS-IX 구조를 가진 MPLS 도메인은 여러 네트워크의 양끝을
연결한다. 즉, IX-provider는 코아 LSR들만을 제공하고, LSP들은
MPLS-IX이내에 IGP 라우팅과 MPLS 시그널링을
가진 IX-customer 사이트에 위치한 에지 LSR들
사이에서 설정된다. IX-customer들은 eBGP를 사용하는
라우트 정보를 교환하기 위하여 이 LSP들을 사용한다((그림 6) 참조). MPLS-IX의 특징은 다음과 같다.
• IX-provider에서 코아 LSR들은 MPLS-IX 바깥의 라우트 정보를 필요로 하지 않는다.
• LSR들 사이의 데이터 링크층 기술에 대한 제한이 없다.
나. 시험 내용
MPLS-IX 구조를 기반으로 한 MPLS 테스트베드 네트워크를 구성하고, MPLS-IX의 IX-customer로서 JAIST 1과 HTnet 2의 IPv6 네트워크를 연결하였다. 이 구성에서, 6PE 모델의
IPv6 라우팅 정보와 트래픽을 교환하기 위해서 MPLS 네트워크의 에지 LSR로서 AYAME LSR를 두었다((그림 7) 참조).
IPv6 기능들은 이 네트워크의 코아 LSR들에서는 전혀 동작이 되지 않는다. 다시 말해서, 만약 6PE 기능에 의한 MPLS
네트워크를 통한 전송 경로가 설정되지 않는다면, JAIST와 Htnet 사이의 IPv6 도달성을 얻을 수가 없다.
이
구성에서 JAIST와 Htnet 사이의 IPv6 도달성을 증명하였다. 이것은 어느 정도까지는 6PE 구현이 올바르다는 것을 나타낸다.
(그림 8)는 JAIST쪽의 AYAME LSR의 라우팅 테이블을 나타낸다. LSP는 각 편의 AYAME LSR들 사이에 설정이 된다(line 5-6). BGP에 의해서 교환된 IPv4 라우트 엔트리는, 라우트의 next-hop이
HTnet(211.120.192.1)에서 LSR과 LSP를
지나는 포워딩을 지시하는 것을 나타낸다.
IPv6 라우트 엔트리
(line 17-19)에서, 라우트의 next-hop은 IPv4-mapped IPv6 주소를 가지는 HT-net (::ffff:211.120.192.1)에
있는 LSR을 가리키는 것에 주의해야 한다. IPv4-mapped
IPv6 주소는 6PE 동작의 시험에 있어서 중요하다. 루트의
실제 next-hop을 살펴볼 때, IPv4-mapped IPv6 주소로부터
얻은 IPv4 주소는 (211.120.192.1)를 사용한다. 이것은 IPv4 라우트 엔트리
(line 5-6)와 같을 것이다. 이러한 과정에 의해서,
프리픽스 2001:308::/48의 트래픽은 JAIST와 Htnet의 에지LSR들 사이의
LSP를 통해서 MPLS 네트워크를 지나갈 것이다.
이
시험에서 사용된 JAIST의 IPv6 네트워크는 프로덕션
네트워크이다. 이 네트워크에 사용자들이 있으므로, 6PE LSP를
통한 유용한 트래픽의 연속적인 흐름이 있다. AYAME 프로젝트에서는 이 시험을 증명하고, 오랜 기간의 운영을 통한 경험적 사실을 얻기 위하여 이 테스트베드를 지금까지 계속적으로 운영하고 있다.
V. 맺는 말
본
고에서는 IPv6 over MPLS에 대한 기술 개발 동향으로, 4가지
도입 시나리오에 관하여 비교 분석하고, IETF 의 표준화 동향을 고찰하였다.
가장
가까운 미래에 IPv6 네트워크는 인터넷 중심망에 도입되지 않고, 액세스망들에서만
도입될 것으로 예상된다. 따라서, IPv4/MPLS 백본망을
중심으로 IPv6 액세스망이 여러 개 구축되어 제공될 때, 이들
망의 효율적인 연동에 대한 시나리오인 MPLS 6PE에 대하여 자세히 살펴보았다. 또한, MPLS 6PE 시나리오에 대한 연구를 진행하고 있는 AYAME 프로젝트의 내용에 대하여 살펴보았다.
<참 고 문 헌>
[1] J. De Clercq, et al., “Connecting IPv6 Islands across IPv4 Clouds with BGP,” <draft-ietf-ngtrans-bgp-tunnel-04.txt>, Jan. 2002
[2] H. Ishii, et al., “IPv6 Traffic Engineering Tunnel,” <draft-ishii-ipv6-te-tunnel-00.txt>, Nov. 2001
[3] S. Radhakrishnan, et al., “MPLS label stack encapsulation in IPv6,” <draft-ramankutty-mpls-label-encaps-ipv6-00.txt>, June
2001
[4] Yojiro UO, et al., “AYAME: A Design and Implementation of the CoS-Capable MPLS Layer
for BSD Network Stack,” INET2000, Internet
Society, July 2000
[5] Satoshi Uda, et al., “IPv6 support on MPLS networks: Experiences with 6PE approach,” 2003 Symposium on Applications and the Internet Workshops
(SAINT'03 Workshops) Jan. 2003, Orlando,
Florida, pp.27-31.
[6] http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6_c/sa_mpls6.pdf,
Cisco IOS IPv6 Technical Documents, “Implementing
IPv6 over MPLS”
[7] http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/ipv6_sol/ipv6dswp.pdf,
Cisco IOS IPv6 Deployment Documentation, “IPv6 Deployment Strategies”
[8] http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/iosip_an.pdf,
Cisco IOS IPv6 Applications Notes, “Cisco IOS IPv6
Provider Edge Router (6PE) over MPLS,” Oct. 2002.
IPv6 MIB 동향 분석
이상도* 신명기** 김형준***
기존의 IPv4 인터넷 망을 IPv6 기반의 차세대 인터넷 망으로 전환하기 위한 연구들이 IETF를
중심으로 활발하게 진행되고 있다. 또한, IPv6 상에서
네트워크 관리를 위한 MIB(Management Information Base)의 연구들이 기존의 MIB-II 에 IPv6 MIB을 추가하는 형태로 진행 중이다. 본 고에서는 IPv6 기반의 네트워크 장치들을 관리하기 위한 MIB에 표준화 진행
상황과 이를 지원하는 장비들을 소개하고자 한다. ▧
I. 서 론
IPv4의 주소 고갈 문제로 인하여 IPv6를 테스트 하기 위한 망들이 여러 네트워크 환경을 대상으로 시험적으로 도입되고 있다. 일본의 NTT 도코모를 비롯한 여러 ISP 업체들에서는 IPv6 상용 서비스를 이미 시작하였으며, 앞으로 점점 많은 사용자들이 IPv6망을 이용할 것으로 예상하고
있다. 현재 IPv6 망에서의 네트워크 관리를 위한 사용
제품들이 아직 시장에 많이 나오지 않았지만, IPv4 환경에서의 망 관리 SNMP(Simple Network Management Protocol) 프로토콜과 MIB(Management Information Basement)을 IPv6 상에서
적용하기 위한 연구들은 계속 진행되고 있었다. 1998년에 처음으로
MIB-II에서 IPv4 와 IPv6를 관리하기
위한 표준화 문서가 발표되었으며, 현재까지 관련 표준화 작업이 계속 진행 중이다. 지난 수년간 네트워크의 급속한 성장과 다양한 이질적인 시스템의 등장으로 네트워크를 통합적으로 관리하기가 어려워졌다. 그러므로, 네트워크 관리자들은 다양한 네트워크 환경에서 포괄적으로
관리할 수 있는 네트워크 프레임워크를 점점 요구하게 되었다. 이러한 요구로 인하여 IETF(Internet Engineering Task Force)는 인터넷 기반의 네트워크 장비를 관리하기
위한 표준으로 비교적 단순한 프로토콜인 SNMP를 채택하게 되었다. 즉, 네트워크 관리를 위한 기본적인 프레임워크는 네트워크를 관리 정보를 담고 있는
MIB과 관리 정보를 얻기 위한 프로토콜(SNMP)로 구성되어 있다. 비교적 많은 벤더들이 SNMP를 지원하는 네트워크 장비들을 출시하면서 SNMP 프로토콜과 MIB은 네트워크 관리를 위한 가장 중요한 요소로써
인식되기 시작하였다. 기존의 IPv4 환경에서의 대부분의
네트워크 장비들이 MIB 과 SNMP를 지원하고 있기 때문에 IPv6 환경이 점차 도입되고 있는 이 시점에서 IPv6 환경에서의
네트워크 장비를 관리 할 수 있도록 새로운 IPv6 주소를 기능을 지원하는 SNMP 프로토콜의 수정 및 MIB의 변경이 요구되고 있다.
그러므로, 본 고에서는
IPv6 환경에서의 네트워크 관리를 위한 MIB의 수정 과정과 IPv6 상에서 MIB 표준화 동향 및 현재 진행 상황 등에 대해서
전체적으로 고찰하고자 한다. 이를 위해 I장 서론에 이어 II 장 본론에서는 MIB의 기본 정의 및 확장된 기본 기능들을 살펴보고, III 장에서는 현재까지 진행된 IPv6 MIB의 동향에 대해서
기술한다. 그리고 VI장에서는 IPv6 MIB의 동향과 지원 현황에 관하여 기술하고 V장에서 결론을
맺는다.
II. MIB 의 정의
및 기능
1. MIB 개요
MIB은 SNMP 프로토콜에
의해 운영되는 데이터에 대한 몇 가지 표준을 정의하고 있다. 이 표준들은 네트워크상에서 장비들이 가지고
있는 데이터들을 정의하고, 이 값들에 의해 어떠한 동작이 허용될지를 정의한다. 이 데이터들은 트리 형식으로 구성되어 있으며, 각 변수 값에 도달하기
위한 유일한 경로를 제공한다. 각각의 객체들은 시스템에서 사용되고 있는 네트워크 자원에 관련된 정보를
객체에 저장하며, 저장된 관리 정보들은 원격지에서 모니터링 되거나, 수정될
수 있다. 이러한 관리 객체로 구성된 트리 구조를 MIB이라
부르고, 각각의 MIB에 관한 구조는 여러 RFC들에 의해서 문서화되어 있다. 현재 TCP/IP 기반의 네트워크 환경에서 표준으로 가장 널리 사용되는 MIB은 MIB-II 이며, RFC 1213 문서에 정의되어 있다. MIB-II에서 관리하는 객체를 살펴보면 <표1>과 같이 크게 8가지 범주로 구분해서 네트워크 관련 데이터를
관리하고 있다.
대부분의 네트워크 장비들이 MIB-II를 지원하며 이를
이용하여 노드의 시스템 상태 정보 및 트래픽 정보 등을 SNMP 프로토콜을 이용하여 손쉽게 얻을 수
있다.
2. SNMP 개요
SNMP는 네트워크 디바이스(라우터, 스위치, 호스트
등등)간에 관리 정보들의 교환을 가능하게 하는 응용 레벨의 프로토콜이다. 네트워크의 폭발적인 성장과 다양한 시스템들의 등장으로 이를 포괄적으로 관리할 수 있는 프레임워크가 요구되면서 IETF에서는 SNMP 라는 프로토콜을 표준으로 채택하였다. 이를 이용하여 네트워크 관리자들은 TCP/IP를 기반으로 하는 네트워크상의
장치들의 상태 및 성능 정보(트래픽, 인터페이스 사용률) 등을 얻을 수 있으며, NMS (Network Management
System)에서 수집된 네트워크 성능 데이터를 종합적으로 분석하여 네트워크 상의 문제점을 파악할 수 있는 기능을 제공할 수 있게
되었다. 현재 SNMPv1, SNMPv2, SNMPv3 세
가지 버전이 구현되었고, SNMPv2 가 가장 널리 사용되고 있다.
SNMP 는 인터넷 프로토콜에 큰 영향을 받지 않는 프로토콜이다. 그러므로, IPv6 환경에서도 크게 변경될 내용은 없을 것으로 예상된다. 2002년 5월에는 오픈 소스 프로젝트인 net-snmp에서 최초로 IPv6 환경에서 SNMP를 지원하는 net-snmp-5.0.3 버전을 발표하였다. 1995년 IPv6 스펙이 발표된 이후 상당히 늦게 구현된 것으로 생각되지만, 기존의 IPv6 네트워크 환경은 IPv4 라우터 기반에 듀얼 스택 형태로 IPv6 네트워크를 지원하기 때문에 주로 IPv4 주소를 이용한 SNMP만을 이용하였다.
III. MIB 의 발전
과정
1. TC 표준화
과정
TC(Textual Convention)의 변화 과정은 (그림1)과 같다.
1996년에 표준화된 RFC1902을 살펴보면, IP address를 표현하기 위한 데이터
타입에 관한 정의를 볼 수 있다. 즉, ASN.1(Abstract
Syntax Notation number One) 형태로 Ip Address가 OCTET STRING(SIZE(4))으로 표현되어 있다. 이것은 4 byte(32bit)의 IPv4 address를 담기 위한 데이터
타입이다. IPv6에 관한 논의가 IETF를 중심으로 활발하게
진행되면서, 네트워크 장비를 지원하기 위한 MIB을 추가하기
위해서 IPv6 데이터 타입을 정의하기 위한 논의가 점차 진행되었다.
그러므로, 1998년에 128bit의 새로운
주소 타입인 IPv6를 저장하기 위한 표준화가 이루어져 RFC2465로
정의된 TC(Textual Conventions)에서는 IPv6 주소를
위한 OCTET STRING(SIZE(16)) 타입이 정의되었다.
128bit 주소를 저장하기 위한 데이터 타입을 새롭게 정의한 것이다. 그러나, IETF에서는 IPv4와 IPv6
관리 객체를 서로 다른 테이블에서 관리하던 방식을 한 테이블에서 지원하는 형태의 통합된 형태의 “Unified TC”를 정의하기로 결정하였다. 이러한 결과로 2000년에 RFC
2851로 다시 수정 되었다. 변경된 RFC 2851에서는 IP address를 {inetAddressType, inetAddress} 형식으로
구성하였다. 첫 번째 인자 inetAddressType은
정수형으로써 unknown(0),
ipv4(1), ipv6(2), dns(16) 등의 네 가지 타입의 값을 가진다. 예를
들면 정수 값이 “1”로 설정되면 뒤에 따라오는 주소
타입이 IPv4 주소인 것을 의미한다. 두 번째 인자 inetAddress는 주소를 저장하기 위한 OCTET
STRING(SIZE(0......255))로 구성되어 있다. 이러한 구조로 인하여 확장된
형태의 주소를 다양하게 지원할 수 있게 되었다. 2002년 5월에 scoped IPv4, IPv6 주소에 관련된 TC(Textual
Conventions) 정의가 RFC 3291에 새롭게 정의되어 있다. 또한, IPv6 의 여러 가지 특징적인 변수들(inetAddressPrefixLength, InetPortNumber,
InetAutonomousSystemNumber)에 관한 정의도 함께 포함하고 있다.
2. MIB 의
표준화 과정
MIB-I(RFC 1158)은 1990년대에 TCP/IP 기반의
32bit의 IP 주소를 가지고 있는 네트워크 장치들의 관리를 위하여 처음으로 정의되었다. 1991년도 RFC 1213으로 수정 보완 되었으며, MIB-II에서 기본적으로 관리하는 객체 정보는 system(1),
interface(2), at(3), ip(4), icmp(5), tcp(6), udp(7) 등이다.
1992년도에는 IP Forwarding Table MIB(RFC1354)과 MIB-II 의 그룹으로 분리되었다. 1996년도에 CIDR(Classless Inter Domain Router)을 지원하기 위한 IP Forwarding Table MIB(RFC2096)과 SMIv2 환경에서의 IP, TCP, UDP를 지원하기 위한 RFC2011, RFC2012,
RFC2013 등으로 수정되었다. 1998년도
Textual Convention에서 IPv6 주소를 지원하기 위한 데이터 타입이 정의되면서, MIB-II는 IPv6상에서의 TCP(RFC
2452), UDP(RFC2454), ICMPv6 (RFC2455), IPv6(RFC2466) 등을 관리하기 위한 새로운 MIB가 추가되었다. 통합된 형태의 “unified TC”가 정의되면서 예전의 RFC들이
draft-ietf-ipngwg-rfc2011-update-00.txt,
draft-ietf-ipngwg-rfc2012-update-00.txt,
draft-ietf-ipngwg-rfc2096-update-00.txt들이 현재 표준화 진행 중에 있다.
가. 1996년
RFC 2011, RFC 2012, RFC 2013 는 ipv4 환경에서 3가지 객체
ip, tcp, udp에 관한 네트워크 통계 정보를 저장하기 위한 객체가 정의되었다.
나. 1998년
(그림3)과 같이 IPv6 관련된 네트워크 관련 정보를 저장하기 위한 ipv6 MIB가
새롭게 추가되었으며 IPv6 트래픽 정보를 저장하기 위해서 기존의
tcp(6) 객체 아래에 ipv6TcpConnTable과
udp(7)의 객체 아래에 ipv6UdpTable이 새롭게 추가되어 기존의 IPv4 네트워크 정보 이외의 IPv6 관련 정보들도 저장할 수 있게
되었다.
또한, MIB-II에
ipv6에 관한 정보들을 저장할 수 있도록 기존의 MIB-II에 ipv6 관련 정보를 저장하기 위한 새로운 형태의 MIB 테이블이
추가되었다. 새로 정의된 MIB의 이름과 관련 RFC 들은 <표 2>와
같다.
새로 확장된 MIB들은
(그림 3)에서 볼 수 있듯이 ipv6MIB(55),
ipv6IcmpMIB(56)은 MIB-II 아래 새롭게 생성된 테이블이며, ipv6TcpMIB(16), ipv6UdpMIB(6)은 기존의 tcp(6),
udp(7) MIB에 IPv6 관련 트래 픽 정보들을 담기 위해서 확장된 형식으로 추가된
테이블이다. 새롭게 생성된 테이블 중 ipv6MIB을 살펴보면, 총 6개의 객체로 구성되어 있다.
객체의 자세한 내용은 다음과 같다.
(1) ipv6IfTable
IPv6를 지원하는 인터페이스에 대한
일반적인 정보(인터페이스 정보, MTU, 상태, 물리적 주소 등)들을 저장하고 있다.
(2) ipv6IfStatsTable
이 테이블은 IPv6를 지원하는 인터페이스를 통한 트래픽의
통계 정보(패킷 수)를 저장하고 있다.
(3) ipv6AddrPrefixTable
IPv6 Prefix 정보를 저장하고 Prefix 부가적인 정보(Onlink, Autonomous,
Preferred Time, Valid Life Time)들도 함께 저장하고 있다.
(4) ipv6AddrTable
IPv6 주소에 관련된 정보(IPv6 주소, Prefix Length, IPv6 주소 타입, IPv6 상태 등)들을 저장하고 있다.
(5) ipv6RouteTable
IPv6 라우팅 테이블에 관련된 정보가
저장되는 테이블로써ipv6RouteDest, ipv6RouteNextHop을 이용하여 라우팅 경로를
알 수 있다.
(6) ipv6NetToMediaTable
IPv6의 네트워크 주소와 물리적인
주소를 매핑한 정보를 저장하고 있다.
하지만, 이러한 접근 방식은 IPv4 관련 데이터를 잘못된 테이블에 저장할 수 있는 위험성을 가지고 있다.
예를 들면, TCP 테이블의 tcpConnTable 은 IPv4 와 관련된 데이터를 저장하는데 ipv6TcpConnTable 에
잘못 저장하거나 반대의 경우도 발생할 수 있는 단점을 가지고 있다.
다. 2000 년:
현재 진행되고 있는 MIB 표준화
과정을 살펴보면 하나의 통합된 형태의 <Unified MIB>이 현재 Internet-Draft 상태로 표준화가 진행 중이다.
통합된 접근 방식이란 기존의 네트워크 관련 정보 등을 ipv4
MIB과 ipv6 MIB로 나눠서 관리 유지하던 방식을 하나의 통합된 형태의 MIB으로 관리 정보를 저장 하는 것을 말한다. 기존의 ipAddrTable과 ipv6AddrTable은 ipAddressTable로 하나로 통합 되었으며 ipNetTomediaTable
과 ipv6NetTomediaTable은
inetNetToMediaTable로 통합되었다. <표3>은 합쳐진 MIB 정보를 나타낸 것이다.
또 다른 특징으로 특정한 IPv6 관련 정보를 관리하기
위한 테이블이 추가되었다. 그 중 ipv6InterfaceTable과 ipv6ScopedIdTable들이 대표적이다.
ipv6InterfaceTable은 하나의 인터페이스에 여러 개의 IPv6 주소들이 할당된
경우 IPv6 주소들에 관한 정보들을 다루기 위해서 만들어 졌으며,
ipv6ScopedIdTable은 IPv6 주소 범위를 관리하기 위한 정보를 유지하는 테이블로
추가되었다.
IV. IPv6 MIB 지원 동향
IPv6에 관련된 MIB들을 처음으로 구현한 곳은 오픈 소스 그룹에서 진행 중인 net-SNMP
이다. 2002년 5월에 발표된 net-snmp-5.0.3에서는 IPv4/6 호스트 라우터에서의 IPv6 MIB을 지원할 수 있도록 구현되었다. IPv6 환경이 완전하게
자리 잡히지 않은 환경에서도 <표4>과 같이 여러
업체들이 자신의 라우터에 여러 IPv6 MIB 중 전부 혹은 일부만을 구현하였다. <표 4>는 지원 가능한 MIB을 회사별 표로 나타낸 것이다. <표 4>의 모든 내용은 표준화가 이미 완료된 MIB만을 대상으로
비교한 것이다.
시스코 라우터는 IPv6 MIB을 지원하기 위해서 Cisco IOS Software Releases 12.0.S 이후부터
draft-ietf-ipngwg-rfc2011-update-00.txt,
draft-ietf-ipngwg-rfc2096-update-00.txt을 기준으로
CISCO-IETF-IP-MIB에 IPv6 MIB & ICMPv6 MIB 정보들을
시스코 enterprise MIB에 실험적으로 제공하고 있다. 그
외에 LORIA에서는 FreeBSD4.5 버전에 net-snmp 패키지를 이용하여 표준화가 진행중인 “Unified MIB” 형태의 MIB을 구현하였다.
V. 결 론
기존의 IPv4 인터넷 망을 IPv6 기반의 차세대 인터넷 망으로 전환하기 위한 연구들이 IETF를
중심으로 활발하게 진행되고 있다. 이에 본 고에서는 IPv6를
기반으로 하는 네트워크 장치들을 관리하기 위한 MIB 의 표준화 상황 및 발전 과정에 대해서 살펴보았다. 이를 토대로 IPv6 환경에서의
NMS(Network Management System)에 관한 선행 연구들이 활발하게 진행될 수 있을 것으로 생각한다.
<참 고 문 헌>
[1] Isabelle ASTIC, Oliver FESTOR, “Current Status of IPv6 Management,” Technical Report RT-0271, Dec. 2002.
[2] Mongi Abdelmoula, Neha Jha et al.,
Implementation of IP-MIB modules for IPv4 and IPv6 protocol, Technical Report
RT-0271, A02-R-186, INRIA, Oct. 2002.
[3] F.Baker. IP forwarding table, RFC 1354,
July 1992.
[4] F.Baker, IP forwarding Table. RFC 2096,
Jan. 1997.
[5] M. Daniele, B.Harberman et al., Textual
conventions for Internet Network Address, RFC 2851, June 2000.
[6] M. Daniele, B.Harberman et al., Textual
conventions for Internet Network Address, RFC 3291, June 2002.
[7] B. Fenner, B. Haberman, McCoghrie K et
al., Management Information Base for the User datagram Protocol(UDP),
draft-ietf-ipngwg-RFC2013-update-01.txt, 2001.
[8] B. Fenner, B. Haberman, McCoghrie K et
al., Management Information Base for the Transmission Control Protocol(TCP),
draft-ietf-ipngwg-RFC2012-update-01.txt, 2001.
[9] B. Fenner, B. Haberman, J. Schoenwaelder
et al., IP Forwarding Table MIB, draft-ietf-ipngwg-RFC2096-update-00.txt, 2001.
[10] B. Fenner, B.
Haberman, J. Schoenwaelder et al., Management Information Base for the Internet
Protocol(IP), draft-ietf-ipngwg-RFC2011-update-00.txt, 2001.
[11] R. Hinden and S. Onishi, Management Information Base for IP Version 6:
Textual Conventions and General Group,Dec. 1998,RFC 2465.
[12] K. McCloghrie.
Management Information Base for the Internet Protocol(IP), RFC 2011, Nov. 1996.
[13] K. McCloghrie.
Management Information Base for the Transmission Control Protocol(TCP), , RFC
2012 Nov. 1996.
[14] K. McCloghrie.
Management Information Base for the User Datagram Protocol(UDP), RFC 2013, Nov.
1996.
[15] K. McCloghrie.,D.
Perkins, and J. Schonenwaelder, Textual conventions for SMIv2, RFC 2578, Apr.
1999.
[16] K. McCloghrie.
and M.T. Rose. Management information base for the network management of tcp/ip
based internets- mib-II, RFC1213, Mar. 1991.
[17] M.T. Rose and K.
McCloghrie. Concise mib definitions, RFC 1212, Mar. 1991.
