NetWorkers

Frame-relay의 own interface ping. (자핑)

넷엔지니어 — Sun, 24 Feb 2008 08:59:54 GMT

Frame-relay에서 자기 인터페이스로 핑('자핑'이라고도 한다)을 쏘면, 응답을 받을 수 없다 ?!
( 프레임릴레이 )

Ethernet (이더넷) 은 어떤가?

핑을 쏘자마자 거의 동시에 답변을 받을 수 있다.
그러나 Ethernet에서는 실제로 ICMP가 encapsulation되서 NIC 외부로 나가는 것이 아니다.
이게 무슨 말인지 알아보자.

Ethernet 은, Broadcast 환경을 지원한다.
모르는게 있으면 '모두 다 들어봐'는 브로드케스트를 날릴 수 있음을 의미한다.
(ex. ARP)
이때 다른 장비들과의 충돌을 감지할 수 있게 Loopback이 존재한다.

자신이 내보내는 데이터를 그대로 복사해두고, input 데이터를 비교해서 방금 자신이 내보낸
Data에 어떤 변경이 있는지 확인함으로써 충돌이 있었는지 감지하는 것이다.

Ethernet 에서 핑을 쏘면 바로 이 Loop를 통해 핑을 받게 된다.
Ethernet 에 있어서 자핑은 연결된 Link의 안전성을 판가름 하는 기준이 아니라,
장비 내부에서 Ethernet 인터페이스가 이상이 없는지만 체크해 줄 뿐이다.

ping data를 어떤 값으로 정해줘도, 40byte짜리 000000000000000~~~~ 값이 Loop를 통해
검증될 뿐이다.

그렇다면, Frame-relay는 왜 안되는 것인가 ?!

Ethernet 환경에서 주로 자기(own) 인터페이스의 응답을 받는 것이 익숙해져서,
Serial. 그것도 Frame-relay에서 응답을 받지 못하는 것이 의아할 지도 모른다.

Frame-relay는 NBMA 환경이다.
NB, 즉, Non-Broadcast 이다.
자신이 모른다고 해서 '다들어 봐'라고 다른 장비들을 부를 수 없다는 것이다.

그런데 MA, Multiple Access이다.
하나의 링크를 통해 여러 장비와 통신이 가능하다.
또 하나의 특징이 있다면, 매핑이 필요하다는 것이다.
(이에 대한 자세한 내용은 생략하도록 한다.)

핑을 쏘기 위해서 프레임 릴레이는 자신의 Frame-relay Mapping 정보를 찾아보게 되는데,
이때 자신의 인터페이스 ip가 맵핑되어 있지않다면 encapsulation failed 가 일어나게 된다.

Frame-relay는 무조건 맵핑 정보가 필요하기 때문에, 자기 인터페이스라고 하더라도,
맵핑 정보가 없다면 핑이 안된다.

왜 그럴까?

MA 환경을 지원하기 때문에, 하나의 링크에서 다수의 장비와 통신이 가능하다.
서브인터페이스를 만들 수도 있다.
당연히 unicast하게 통신하는 것은 보장된다.
하지만, NB(Non-Broadcast) 이기 때문에 자신이 모르는 네트워크를 호출할 수 있는 방법이 없다.
'명백한' 매핑정보가 없으면, 절대 보낼 수 없는 것이다.

아래와 같은 네트워크가 있다고 하자.

라우터1 Serial1/1                               라우터2 Serial1/1
(1.1.1.1) ---------------------------- (1.1.1.2)

R1의 DLCI는 102, R2의 DLCI는 201 이다.
서로를 맵핑 시켜주기 위해 R1과 R2에는 다음과 같이 매핑이 되어 있을 것이다.

R1 : frame-relay map ip 1.1.1.2 102   -> 1.1.1.2로 가려면 DLCI 값 102를 달고나가라.
R2 : frame-relay map ip 1.1.1.1 201   -> 1.1.1.1로 가려면 DLCI 값 201를 달고나가라.

서로 반대편 라우터에게 핑을 쏘면 당연히 ICMP reply (핑의 응답) 를 받을 수 있다.
ex. R1 에서 R2로 핑.

R1#p 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!

그러나 자핑은 안될 것이다.

R1#p 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....

debug ip packet을 하면 다음과 같은 에러메시지를 볼 수 있다.
*Feb 24 17:34:37.547: IP: s=1.1.1.1 (local), d=1.1.1.1 (Serial1/1), len 100, sending
*Feb 24 17:34:37.551: IP: s=1.1.1.1 (local), d=1.1.1.1 (Serial1/1), len 100, encapsulation failed

(재미있는 메시지이다. source와 destination이 동일하다.)
그보다 주목할 것은 encapsulation failed이다.

1.1.1.1로 가는 DLCI를 찾지 못했기 때문에 패킷을 encapsulation하지 못했다고 투정부리는 것이다.
자, 그럼 넣어주자.

R1 : frame-relay map ip 1.1.1.1 102   -> 1.1.1.1로 가려면 DLCI 값 102를 달고나가라.

이제 핑해보자.
*Feb 24 17:39:23.967: IP: tableid=0, s=1.1.1.1 (local), d=1.1.1.1 (Serial1/1), routed via RIB
라는 디버그 메시지와 함께 반가운 마침표를 볼 수 있다.

Serial1/1을 통해 패킷을 전송했다는 것이다.
어떻게 된 것일까.

1. 첫번째 단계

R1은 자신의 Frame-relay Mapping 테이블을 보고, 1.1.1.1을 뒤져보니, Serial1/1을 통해
DLCI 102 를 달고 나가라는 것을 확인했다.
그래서 ICMP request 패킷을 Frame-relay로 잘 encapsulation해서 Serial1/1로 내보낸다.

2. 두번째 단계

R2는 R1으로부터 패킷을 받았다.
사람이 보기엔 source와 destination이 동일한 우스꽝스러운 패킷이지만,
라우터는 destination만 보기 때문에 전혀 문제가 없다.

R2는 자신의 Frame-relay Mapping 테이블을 뒤져서
1.1.1.1 가기 위해 Serial1/1을 통해 DLCI 201을 달고 나가라는 것을 확인했다.
그래서 ICMP request 패킷을 Frame-relay로 잘 encapsulation해서 Serial1/1로 내보낸다.

3. 세번째 단계

R1은 방금 R2가 보낸 패킷을 보니, 자기 Interface 주소를 향한 ICMP request 였다.
그래서 여기에 대한 응답을 보내려고 한다.
request에 대한 reply는 당연히 보낸 라우터, 즉, 소스에게 보내줘야 한다.
ICMP request의 source 주소를 보니 1.1.1.1이다. - _-;;

R1은 source와 destination 주소를 바꾼다.
사실, 사람의 눈에는 둘다 같은 주소 (1.1.1.1)이라 전혀 바뀐게 없어보이지만,
이는 명백히 바뀐 주소이다.

이제 다시 1.1.1.1로 ICMP reply를 보낼 차례이다.
우습게도 다시 자신의 Frame-relay Mapping 테이블을 보니
Serial1/1을 통해 DLCI 102 를 달고 나가라는 것을 보고 R2에게 ICMP reply를 보낸다.

4. 네번째 단계

R2는 R1이 보낸 패킷의 destination이 1.1.1.1이다.
DLCI 201을 붙여 Serial1/1을 통해 전송해준다.

간략하게 정리해보자.
R1 ----------------------------------------------------------------- R2

ⓐ R1에서 source: 1.1.1.1 destination: 1.1.1.1로 ICMP request.
    매핑 테이블을 뒤져서 Serial1/1로 전송.

ⓑ R2에서 ICMP request를 받고, destination: 1.1.1.1임을 확인하고 R1에게 보내줌.

ⓒ R1에서 ICMP reply 받고, source와 destination을 바꿔서 source 주소 였던 1.1.1.1로 ICMP reply.
    매핑 테이블을 뒤져보니 Serial1/1로 보내야 함. 전송.

ⓓ R2에서 R1이 보낸 ICMP reply를 받고, destination: 1.1.1.1임을 확인하고 R1에게 보내줌.

이렇게 오가는 동안 응답시간은 2배로 늘어날 수 밖에 없다.
확인은 독자 여러분이 직접 ^^

출처 : http://networkers.egloos.com/1453581

Editing Keys and Functions

넷엔지니어 — Thu, 31 Jan 2008 14:25:14 GMT

Keys	Function
Tab	Completes a partial command name entry. When you enter a unique set of characters and press the Tab key, the system completes the command name. If you enter a set of characters that could indicate more than one command, the system beeps to indicate an error. Enter a question mark (?) immediately following the partial command (no space). The system provides a list of commands that begin with that string.
Delete or Backspace	Erases the character to the left of the cursor.
Return	At the command line, pressing the Return key performs the function of processing a command. At the "---More---" prompt on a terminal screen, pressing the Return key scrolls down a line.
Space Bar	Allows you to see more output on the terminal screen. Press the space bar when you see the line "---More---" on the screen to display the next screen.
Left Arrow¹	Moves the cursor one character to the left. When you enter a command that extends beyond a single line, you can press the Left Arrow key repeatedly to scroll back toward the system prompt and verify the beginning of the command entry.
Right Arrow1	Moves the cursor one character to the right.
Up Arrow1 or Ctrl-P	Recalls commands in the history buffer, beginning with the most recent command. Repeat the key sequence to recall successively older commands.
Down Arrow1 or Ctrl-N	Return to more recent commands in the history buffer after recalling commands with the Up Arrow or Ctrl-P. Repeat the key sequence to recall successively more recent commands.
Ctrl-A	Moves the cursor to the beginning of the line.
Ctrl-B	Moves the cursor back one character.
Ctrl-D	Deletes the character at the cursor.
Ctrl-E	Moves the cursor to the end of the command line.
Ctrl-F	Moves the cursor forward one character.
Ctrl-K	Deletes all characters from the cursor to the end of the command line.
Ctrl-L and Ctrl-R	Redisplays the system prompt and command line.
Ctrl-T	Transposes the character to the left of the cursor with the character located at the cursor.
Ctrl-U and Ctrl-X	Deletes all characters from the cursor back to the beginning of the command line.
Ctrl-V and Esc Q	Inserts a code to indicate to the system that the keystroke immediately following should be treated as a command entry, not as an editing key.
Ctrl-W	Deletes the word to the left of the cursor.
Ctrl-Y	Recalls the most recent entry in the delete buffer. The delete buffer contains the last ten items you have deleted or cut. Ctrl-Y can be used in conjunction with Esc Y.
Ctrl-Z	Ends configuration mode and returns you to the EXEC prompt.
Esc B	Moves the cursor back one word.
Esc C	Capitalizes the word from the cursor to the end of the word.
Esc D	Deletes from the cursor to the end of the word.
Esc F	Moves the cursor forward one word.
Esc L	Changes the word to lowercase at the cursor to the end of the word.
Esc U	Capitalizes from the cursor to the end of the word.
Esc Y	Recalls the next buffer entry. The buffer contains the last ten items you deleted. Press Ctrl-Y first to recall the most recent entry. Then press Esc Y up to nine times to recall the remaining entries in the buffer. If you bypass an entry, continue to press Esc Y to cycle back to it.

출처 : http://www.cisco.com/univercd/cc/td/doc/product/atm/ls1010s/11_1/cr/lscre.htm

RIB와 FIB

넷엔지니어 — Mon, 31 Dec 2007 13:20:23 GMT

RFC 1322의 2.1.1 Storage Overhead를 참조하면 다음과 같이 서술되어 있다.

The RIB contains the routing information that entities exchange via the inter-domain routing protocol.
the RIB is the input to the route computation.

RIB는 inter-domain 라우팅 프로토콜을 통해 교환하는 라우팅 정보 엔터티들을 포함하고 있다.
RIB는 경로 계산의 입력물이라고 할 수 있다.

The FIB contains the information that the entities use to forward the inter-domain traffic
the FIB is the output of the route computation.

반면 FIB는 inter-domain 트래픽을 포워드하는데 사용하는 엔터티 정보를 포함하고 있다.
FIB는 경로 계산의 출력물이라고 할 수 있다.

이는 다시 말해, BGP와 같은 inter-domain 프로토콜을 통하여 여러 개의 RIB들이 생성되고,
이 RIB들을 토대로 AD 값과 롱기스트 매치(longest match)등등을 적용하여 FIB를 산출해내는 것이다.

FIB에 대한 더 자세한 정보는 RFC 3222 를 참조하기 바란다.
http://www.faqs.org/rfcs/rfc3222.html

출처 : http://networkers.egloos.com/1216991

rfc 번역본

넷엔지니어 — Mon, 31 Dec 2007 10:44:48 GMT

아래 링크에서 20개 정도의 RFC 번역본을 찾을 수 있습니다.
번역이 매우 매끄럽지는 못한 편입니다.
http://ip.nida.or.kr/data/document_03.jsp#

IS-IS 와 OSPF, 그 역사

넷엔지니어 — Fri, 28 Dec 2007 11:47:14 GMT

오역 및 의역이 포함되어 있을 수 있습니다.

이 두 프로토콜의 개발은 동시에 진행되었고, 개발 그룹의 성과는 매우 비슷했다. 현실적인 두 프로토콜간 차이점이라면, 리소스의 사용과 커스터마이즈 능력 이슈가 다뤄진다.

이 프로토콜들의 장점(merit)에 관한 주요 쟁점은 서로의 역사로 선을 그을 수 있다. 다른 문화의 다른 그룹이 각각의 프로토콜을 개발했기 때문이다.

Digital Equipment Corporation(DEC) 이 DECnet Phase V를 위해 최초로 IS-IS를 개발하였다. 이것이 1982년에 OSI의 IGP가 되도록, American National Standards Institute(ANSI)에 의해 채택되었다. 그 당시엔 단지 CLNP만 지원할 수 있었다.

ISO 프로세스는 국제적인 표준 개발 프로세스이다. Christian Huitema의 책 Routing in the Internet에 따르면, ISO의 그룹들과 미국외 지역에선 TCP/IP를 그 기원 때문에, 받아들이려 하지 않았다. (TCP/IP는 미국방성 프로토콜이라고 불렸었다.)

ISO의 유명한 좌우명 "자유로운 합의와 실행 코드"에 비춰 봤을 때, IP의 발전은 무질서하고 불확실해 보였다. 반면에 초창기 인터넷 엔지니어 관점에서, ISO 프로세스는 느리고, 짜증을 돋궜으며, 독재적이었다.

1988년, U.S. National Science Foundation Network(NSFnet)이 창설되었다. 여기서 사용되던 IGP는 IS-IS의 초기 드래프트를 기반으로 했다. IP를 지원하기 위한 IS-IS extension이 1988년 개발되었다. 이때쯤해서 OSPF 개발이 (IETF에 의해) 시작되었고, IS-IS를 약간 기반으로 했다.

1989년에 OSPF 버젼 1(OSPF v1)이 발표되었고, IS-IS와 OSPF 지지자간에 논쟁이 계속되었다. Internet Engineer Task Force(IETF)에선, OSPF를 더 좋아했지만, 결국 둘 다 지지표명하기에 이른다. 그러나 IETF의 비공식적인 지지에 힘입어 OSPF가 가장 대중적인 프로토콜이 되었다.

1990년 중반에, 두가지 이유 때문에 대형 ISP들은 IS-IS를 IGP로 채택할 필요성을 느꼈다. 첫 번째는 IS-IS가 CLNS와 IP를 둘 다 지원해서, 두마리 토끼를 잡을 수 있기 때문이었고, 두 번째 이유는 그 당시 OSPF가 미완성 상태로 보였기 때문이다.

BSCI, Cisco
출처 : http://networkers.egloos.com/1202980

IPv6 주소 체계

넷엔지니어 — Sun, 09 Dec 2007 06:47:22 GMT

IPv6 Prefix           Allocation              Reference      Note
-----------           ----------              ---------      ----
0000::/8              Reserved by IETF        [RFC4291]      [1] [5]
0100::/8              Reserved by IETF        [RFC4291]
0200::/7              Reserved by IETF        [RFC4048]      [2]
0400::/6              Reserved by IETF        [RFC4291]
0800::/5              Reserved by IETF        [RFC4291]
1000::/4              Reserved by IETF        [RFC4291]
2000::/3              Global Unicast          [RFC4291]      [3]
4000::/3              Reserved by IETF        [RFC4291]
6000::/3              Reserved by IETF        [RFC4291]
8000::/3              Reserved by IETF        [RFC4291]
A000::/3              Reserved by IETF        [RFC4291]
C000::/3              Reserved by IETF        [RFC4291]
E000::/4              Reserved by IETF        [RFC4291]
F000::/5              Reserved by IETF        [RFC4291]
F800::/6              Reserved by IETF        [RFC4291]
FC00::/7              Unique Local Unicast    [RFC4193]
FE00::/9              Reserved by IETF        [RFC4291]
FE80::/10             Link Local Unicast      [RFC4291]
FEC0::/10             Reserved by IETF        [RFC3879]      [4]
FF00::/8              Multicast               [RFC4291]

원문 : http://www.iana.org/assignments/ipv6-address-space

LG-노텔, 공공기관 네트워크 구축 사업 ‘호조’

넷엔지니어 — Mon, 10 Sep 2007 05:07:00 GMT

글로벌 통신장비 기업 LG-노텔(대표 이재령 www.LG-NORTEL.com)은 최근 국세청, 기상청 및 전남, 대전 지방경찰청 등에 자사 이더넷 라우팅 스위치 8600(ERS 8600) 등을 잇달아 공급하며 공공기관 네트워크 분야 시장을 선도해 나가고 있다.

공공기관을 중심으로 네트워크 고도화의 요구가 높아지고 있는 가운데 LG-노텔은 최근 전남지방 경찰청과 대전지방 경찰청 신청사에 종합전산망 및 외부망 백본, 워크그룹을 제공하는 차세대 네트워크 망을 잇달아 구축한 것.

뿐만 아니라 조만간 LG CNS와 함께 국세청 산하의 7개 지방청과 140여 세무서를 대상으로 고성능 최신 네트워크 장비를 도입하고, 안정성 확보를 위해 네트워크를 이중화하는 국세전산망 고도화 사업에 자사 네트워크 장비인 ERS 8600/5520/ES425 등을 납품 및 설치 운용될 예정이다. 기상청에도 자사 ERS 8600/5500 등을 통해 기상청 종합기상정보시스템 및 위성센터 자료시스템 구축을 위한 네트워크 시스템 구축을 완료할 예정이다.

이번 주요 공공기관의 네트워크 고도화 프로젝트의 중심을 이루는 LG-노텔의 ‘ERS 8600’은 최대 수백 메가비트(Mbps)를 지원하는 원활한 데이터 전송은 물론 핵심 애플리케이션의 안정적인 작동을 보장하는 네트워크 복원력, 데이터의 종류에 따라 이를 다르게 처리하는 인텔리전스 기능 등을 갖추고 있다.

이번 구축으로 국세청을 비롯 각 공공기관은 효율적인 운영으로 인한 비용 절감 및 고효율 장비 구축으로 인한 네트워크 안정화를 기대할 수 있게 됐다.

LG-노텔은 신뢰성과 안정성을 특히 중시해 까다로운 시장으로 손꼽히는 공공시장에서 이 같은 괄목할만한 성과의 원인을 그간 고객의 요구조건에 부합하는 솔루션을 지속적으로 제공하며 쌓인 경험과 신용이 인정받은 것으로 판단하고 있다.

LG-노텔 이재령 CEO는 “LG-노텔은 올해 하반기에도 공공기관을 중심으로 더욱 적극적이고 총체적인 마케팅을 펼쳐 추가적인 수주활동에 박차를 가할 것”이라며 “향후에도 LG-노텔의 강점인 신뢰성있고 안정감 있는 통합 솔루션을 바탕으로 고객들이 높은 생산성과 경쟁력을 확보할 수 있도록 도와주는 최고의 파트너가 될 것”이라고 밝혔다. <강석오 기자>

출처 : http://www.datanet.co.kr/news/read.html?cd=32505&N_cate1=0&N_cate2=7

한국쓰리콤, 프라임센터·테크노마트 네트워크 프로젝트 수주

넷엔지니어 — Mon, 10 Sep 2007 05:06:00 GMT

한국쓰리콤(대표 오재진 www.3com.co.kr)이 프라임그룹(회장 백종헌)의 전산실 및 그룹망 구축사업을 수주, 강변 프라임센터 및 테크노마트 건물 전체의 네트워크를 업그레이드하고 신규 건축 중인 신도림 테크노마트의 네트워크 망 구축을 위해 쓰리콤 네트워크 장비를 공급한다고 밝혔다.

한국쓰리콤이 수주한 이번 프로젝트는 기존 강변 프라임센터 및 테크노마트의 노후화된 네트워크 시스템 전체를 업그레이드하고, 신축 중인 신도림 테크노마트의 신규 네트워크를 구축하는 사업으로, 캐리어급 백본 스위치인 쓰리콤의 H3C 스위치 9512를 비롯 워크그룹 스위치인 H3C 스위치 5100 제품군 등이 대거 공급된다.

한국쓰리콤은 이번 프로젝트에 테라비트 스위치인 H3C 스위치 9512를 코어 장비로 공급함으로써 프라임그룹의 기존 10/100M급 네트워크를 기가비트 속도로 향상시키게 된다. 또 워크그룹 스위치를 모두 PoE(Power over Ethernet)를 지원하는 장비로 제공함으로써 향후 무선랜 및 IP텔레포니 구축이 용이한 네트워크를 구성할 계획이다.

프라임정보통신 김홍식 대표는 “프라임그룹은 쓰리콤 장비를 도입함으로써 향후 전체 네트워크의 성능 향상과 효율적인 업무 처리가 가능하게 됨은 물론 테크노마트 입주자들에게도 향상된 네트워크 서비스를 제공할 수 있게 됐다”고 말했다.

오재진 한국쓰리콤 사장은 “대형 엔터프라이즈 시장을 타깃으로 적극적인 영업에 주력해 온 쓰리콤이 H3C와의 통합 후 대기업 시장에서도 잇따라 가시적인 성과를 거두고 있다”며 “이번 프로젝트는 대기업 그룹망 전체를 쓰리콤의 기술로 구축 및 운영할 예정으로 향후 다른 대기업의 네트워크 파트너 선정에 있어 쓰리콤의 위상이 제고될 것으로 기대된다”고 말했다. <강석오 기자>

출처 : http://www.datanet.co.kr/news/read.html?cd=32503&N_cate1=0&N_cate2=7

[인터넷] 다국어 도메인(IDN) 표준 개정 논의 동향

넷엔지니어 — Mon, 10 Sep 2007 04:55:00 GMT

2002년 IETF의 다국어 도메인(IDN) 국제표준 확정 이후, 웹브라우저와 같은 응용프로그램의 다국어 도메인 비지원으로 인해 다국어 도메인 이용 활성화가 어려웠으나, 작년 다국어 도메인이 지원되는 인터넷 익스플로러 7.0이 출시됨에 따라 비영어권 국가의 다국어 도메인 이용이 크게 확산되고 있다.

ICANN(국제인터넷주소자원관리기관)에서도 비영어권 국가 인터넷 이용환경 개선을 위해 다국어최상위도메인(○○.한국 등)의 도입을 추진하고 있어 IETF도 이에 발맞추어 IDN 관련 국제표준의 제약 및 문제점들을 재검토하고 개정 작업을 진행 중이다. 본 고에서는 최근 진행 중인 다국어 도메인 관련 국제표준 개정 동향을 소개하고자 한다.

다국어 도메인(IDN) 개요 및 현 국제표준화 현황

다국어 도메인이란 도메인 이름의 영역에 영문이 아닌 한글과 같은 자국어를 사용한 도메인을 말한다. IETF에서는 2002년 영문 아스키(ASCII)만 인식 가능한 DNS 인프라스트럭처(infrastructure)의 구조적 변경이 어려움에 따라 응용프로그램에서 다국어 도메인을 영문자, 숫자, 하이픈(-)으로만 구성된 영문 퓨니코드(Punycode) 문자열로 변환 처리하는 방식을 선택하였다. 이같은 방식을 IDNA(Internationalizing Domain Names in Applications)라고 정하고 IETF 국제표준(RFC 3490)으로 채택하였다.

국내에서는 2003년 8월부터 한국인터넷진흥원에서 한글 도메인(한글.kr) 등록서비스를 제공 중이며, 일반최상위도메인(.com, .net, .org 등)도 다국어로 도메인 등록이 가능하다.(한글.com 등)

현 국제표준의 문제점

현재 IDN 관련 RFC들은 2002년 당시에 발표된 유니코드 3.2에 의존적으로 작성되었다는 근본적인 문제점을 갖고 있다. 이미 유니코드 컨소시엄에서 새로운 문자셋이 추가되고 변경된 유니코드 5.0을 2006년 발표하였지만, 현 IDNA 표준은 이를 지원하지 못하고 있는 상황이다.

또한, 2005년 다국어 도메인은 '동형 이의어 스푸핑 공격(Homograph Spoofing Attacks)'에 대한 취약점이 발견되었다. 예를 들어, 유니코드 코드 포인트가 U+0430인 키릴 문자(Cyrillic) 'a'는 유니코드 코드 포인트가 U+0061인 라틴어 소문자 'a'와 코드 포인트는 다르지만 모양이 동일하다. 이용자가 키릴 문자 다국어 도메인 'xn--pypal-4ve.com' 접속 시 웹브라우저 주소창에는 'pаypal.com'로 표시되어 이용자를 혼동시키고 해킹에 악용될 소지가 있는 것이다.

이에 대해 모질라 계열 웹브라우저는 주소창에서 다국어 도메인을 영문 퓨니코드 형태로 표시하는 임시적인 해결방법을 사용하고 있다. (예: 한글.com 입력 시 xn--bj0bj06e.com 형태로 변환하여 주소창에 표시) 그리고, 인터넷 익스플로러 7, 파이어폭스 2.0, 오페라 9.10 이상 버전에서는 주소가 의심스러운 경우 이용자에게 경고 메시지를 표시하게 된다.

국제표준 개정 추진 현황

기존 IDNA는 비허용 문자목록을 정해두고 다국어 도메인 입력 문자열 검사를 하였지만, 개정 IDNA에서는 허용 문자열 테이블을 만들고 이를 통해 입력 문자열의 처리여부를 검사하게 된다. 서로 혼동을 일으키지 않는 문자열만 허용하기 위해서이다.

문자열 테이블은 허용(always), 허용불가(never), 미정/추후 허용가능(maybe yes), 미정/추후 비허용 가능(maybe not) 4가지 종류로 분류되며, 기호, 구두점, 박스문자 등의 비언어 문자들을 제외한 오직 언어 문자만이 허용 대상이다. 이 테이블은 유니코드가 버전업 됨에 따라 필요 시 IDNA 입력 허용 문자열 목록은 계속 확장될 것이다.

다국어 도메인의 처리를 위해서는 미리 정의된 규칙에 따라 입력된 다국어 문자열의 공백 제거, 구두점 삭제, 대소문자 변환 등을 처리하는 텍스트 정규화(Text Normalization) 과정이 필요하다. 개정 IDNA는 문자를 호환성 등가(Compatibility Equivalence)로 분해 후, 규범적 등가(Canonical Equivalence)로 재구성하는 NFKC(Normalization Form Compatibility Composition) 방식 대신 문자를 규범적 등가로 분해/재구성하는 NFC(Normalization Form Canonical Composition) 방식을 사용하게 된다. (시각적으로 구별이 불가능하고 텍스트 비교 및 렌더링의 목적상 정확히 동일한 의미를 가지는 문자를 규범적 등가라고 하고, 동일한 문자나 문자 시퀀스의 대체 표현 문자를 호환성 등가라고 한다.)

규범적 등가의 예로는 ‘A’에 옹스트롬(Angstrom) 사인이 있는 ‘Å’가 있는데, ‘Å’(유니코드U+212B)와 라틴어 ‘Å’(유니코드 U+00C5)는 모양이 같고 코드 포인트가 다르지만 분해된 결과는 ‘A’와 ‘'’(U+030A)로 같으므로 규범적 등가이다. 호환성 등가의 예로는 숫자 ‘2’(유니코드 U+0032)와 상첨자 ‘²’(유니코드 U+00B2)가 있는데, ‘²’ 는 숫자 ‘2’의 다른 형태이긴 하지만 시각적으로 구별되고 의미도 다르기 때문에 규범적 등가에 해당되지 않는다. ‘2²’를 NFKC로 정규화하면 ‘²’가 호환성 등가인 ‘2’로 분해된 후 결합되어 ‘22’로 바뀔 수 있으나, NFC 방식 정규화는 규범적 등가를 사용하기 때문에 ‘2²’가 그대로 유지된다. 라틴어 단일 합자인 ‘ﬁ’의 경우에도 NFKC에서는 ‘f’와 ‘i’의 결합으로 표현될 수 있으나, NFC에서는 그렇지 못하다.

위와 같은 정규화 방식 변경으로 인해 기존 IDNA에서 등록이 허용되었던 일부 다국어 문자열이 개정 IDNA에서는 허용되지 않는 경우가 발생할 우려가 있다.

향후 표준화 추진계획 및 결언

유니코드 컨소시엄에서는 새로운 언어를 표현하기 위한 문자셋을 계속 유니코드에 추가할 예정이다. 2003년도 유니코드 3.2에 의존적인 IDN 관련 국제표준들은 현 유니코드 5.0뿐만 아니라 향후 유니코드 버전까지도 고려하며 계속적인 논의가 필요하다. 즉, 유니코드 버전에 관계없이 적용 가능한 IDNA의 개발이 필요할 때이다. 이를 위해 IETF에서는 현재 'xn--' 형태의 다국어 도메인 구별 접두사(prefix)를 다른 접두사로 변경하여 새로운 유니코드 버전을 수용하는 것까지도 고려하고 있다.

2007년 9월 ITU-T Study Group 17에서는 각국 정부 다국어 도메인 전문가들이 모여 다국어 도메인 관련 표준 개정안의 이슈 사항을 논의할 예정이며, 차기 IETF 회의는 2007년 12월 캐나다 벤쿠버에서 개최되고 IDNA 개정안에 대한 비영어권 국가의 의견수렴 및 허용 문자열 목록에 대한 논의가 계속 될 예정이다.

다국어 도메인의 응용프로그램 레벨에서의 처리를 다루는 IDNA RFC 개정은 향후 다국어최상위도메인 및 다국어 전자우편주소 국제표준화에까지 광범위한 영향을 미치게 되므로, 한글 도메인 주소의 올바른 표현 및 확장을 위해 IETF, 유니코드 컨소시엄과의 긴밀한 협조와 논의가 중요시 되는 시점이다.

포스데이타, 와이브로 단말 공급 나선다

넷엔지니어 — Fri, 07 Sep 2007 04:57:00 GMT

와이브로 핵심기술을 기반으로 기지국, 제어국 등 시스템 장비를 개발·공급하고 있는 포스데이타가 KT와 협력해 USB형 단말을 시장에 공급한다.

포스데이타(대표 유병창)는 최근 경기도 분당 본사에서 KT와 와이브로 단말 사업 상호 협력을 위한 협정을 체결했다. 이번 협력을 통해 포스데이타는 서비스 사업자인 KT와 와이브로 단말기 기획, 유통망 공유 등 공동 마케팅을 추진, 단말기를 국내시장에 본격 공급할 수 있는 기반을 마련하고 본격적인 시장 공급에 나설 계획이다.

포스데이타는 CJ홈쇼핑과도 와이브로 단말기 공급을 위한 마케팅 협약을 체결했다. 이에 따라 포스데이타는 CJ홈쇼핑이 운영하는 온라인 유통채널을 활용, 자사의 와이브로 단말기를 시장에 공급할 수 있게 됐다.

포스데이타는 이번에 선보이는 USB 동글 이외에도 미니카드, CF카드, 게임용 특화단말 등 다양한 형태의 제품을 올 연말쯤 출시할 계획이고, 이들 제품들은 국내는 물론 기지국 등 시스템 장비의 공급을 추진하고 있는 해외시장에도 공급될 예정이다.

특히 자회사 ‘포스브로(POSBRO)’를 통해 개발하고 있는 게임용 특화 단말기는 이동중에도 온라인상에서 게임, 동영상 등을 비롯한 각종 서비스를 즐길 수 있는 복합 멀티미디어 제품으로 벌써부터 국내외 시장에서 많은 관심을 받고 있다.

포스데이타 신준일 상무는 “KT와 이번 단말사업 협력을 계기로 현재 추진 중인 기지국·제어국 장비 등의 영역뿐 아니라 단말까지 포함하는 와이브로 전분야에 걸쳐 토탈 솔루션 체제를 갖추게 돼 글로벌 시장에서 경쟁력을 더욱 높일 수 있게 됐다”고 설명했다.<김나연 기자>

출처 : http://www.datanet.co.kr/news/read.html?cd=32459&N_cate1=0&N_cate2=7