식별자/위치자 분리

식별자/위치자 분리(ID/Locator Separation: LIS)는 인터넷 BGP(Border Gateway Protocol) 라우팅 테이블 폭발 문제를 진단하고 해법을 찾기 위해 IAB(Internet Architecture Board)가 2006년에 주최한 Routing and Addressing Workshop의 결과로 제안된 일련의 인터넷 프로토콜군을 말한다. 그 워크숍 진단의 내용은 다음과 같이 요약할 수 있다:

• 라우팅 테이블 폭발은 PI(Provider-Independent: 사설) 주소가 DFZ(Default-Free Zone: AS(Autonomous System) 간 Inter-domain routing zone)으로 노출되기 때문이다.

• 그 원인은 인터넷이 멀티호밍(multi-homing: 한 사이트(AS)가 복수의 인터넷사업자에 연결되는 일(예를 들어 충남대는 KT와 SKT 양쪽으로부터 인터넷 서비스를 받는 것))이 잘 안되기 때문

• 멀티호밍이 잘 안되는 원인 IP 주소가 단말기의 식별자(identifier: ID) 및 위치자(Locator)의 두 가지 역할을 동시에 혼용해 사용하기 때문이다.

• 같은 원인으로 인터넷의 이동성이 제대로 제공되지 않고 있다. (사실 이동성은 기술적으로 멀티호밍과 동일한 문제로 볼 수도 있다; 사업자(호밍) 변경은 느린 이동성, 멀티호밍은 소프트핸드오버로 볼 수 있다. 다만, 이 비유가 모든 경우에 적용되는 것은 아니다.)

• 따라서 식별자와 위치자를 분리하는 새로운 주소체계가 필요하다.

사실 이미 2000년 전후에 인터넷 이동성 취약의 원인이 바로 같은 IP 주소의 이중성이라는 것이 인식이 되어 이른바 HIP(Host-Identify Protocol)라는 것이 개발된 바도 있는데, 2006년에는 같은 근본적 원인을 라우팅 그룹이 뒤늦게 다시 지적하고 나선 것이다.

HIP는 기존의 IP 주소는 그대로 라우팅 위치자로 사용하되, 새로이 호스트 식별자를 도입하는 한편 그를 인식하고 처리할 계층을 IP와 TCP/UDP 층 사이에 끼어 넣는 것을 골자로 한다. 이렇게 하면 호스트 소프트웨어가 바뀌되 기존의 라우팅 체계는 아무런 변화없이 그대로 존속할 수 있다. 물론 HIP도 LIS의 한 해결책으로 분류될 수 있지만, 여기에서는 2000년 후반 이후에 제안된 LISP와 INLP에 대해서 좀 더 알아본다.

LISP(Locator/ID Separation Protocol)

LISP에서는 기존의 라우터의 일부를 이른바 LISP 라우터로 바꾸고 이 LISP 라우터들은 라우팅 위치자(RLOC, Routing Locator)를 이용해 기존의 글로벌 인터넷 속에서 터널링하는 것이 요점이다. RLOC는 통상의 라우팅첨자(Routing prefix: IPv4의 CIDR prefix 또는 IPv6의 network prefix)이다. 따라서 LISP는 기존의 인터넷과 공존이 가능하며 이로 인해 점진적인 확장이 가능하다. LISP 라우터는 한 부속망(subnet)의 디폴트라우터(default router)일 수도 있고, 한 AS의 경계라우터(border router)일 수도 있고, 인터넷사업자의 엣지라우터(edge router)일 수도 있는 등 그 적용 범위는 점진적이며 다양하다.

반면, 주어진 LISP 라우터가 관장하는 영역 곧 사이트(site) 안에 있는 단말들은 단말식별자(Endpoint ID: EID)를 갖는다. LISP에서 사실 단말들은 LISP 라우터의 존재를 전혀 알지 못하고 기존의 인터넷 동작을 그대로 유지하며, 따라서 사이트 내의 단말 IP 주소는 기존과 같이 TCP/UDP 동작에 필요한 단말식별자겸 사이트 내에서의 라우팅 위치자의 이중적 역할을 계속한다. 곧, 사이트 안에서의 단말기와 라우터는 기존 인터넷에서와 그 모든 동작이 동일하다.

동작의 차이는 한 단말기가 주어진 LISP 사이트의 영역을 넘어 다른 LISP 사이트의 단말과 통신을 하려고 할 때에 생긴다(물론 두 단말기 중 어느 한쪽이라도 각자의 LISP 사이트에 속하지 않고 기존의 인터넷 인프라에 존재한다면 이후 모든 동작은 기존 인터넷 동작과 동일하다.).  단말기에서 발생된 패킷이 사이트를 벗어날 때에 해당 LISP 라우터(ITR, Ingress Tunnel Router)는 종착단말이 위치한 LISP 라우터(ETR, Egress Tunnel Router)의 RLOC를 찾아내어(EID-RLOC Mapper에 문의하든가 임시 저장한 캐시에서 찾아보든가 해서) 패킷에 {Source RLOC, Destination RLOC} 헤더를 덧붙인다. RLOC은 합법적인 라우팅첨자이므로 해당 패킷은 이후 정상적인 인터넷 라우팅을 통해 종착 LISP 라우터 ETR까지 도착하게 된다. ETR은 ITR과 반대의 동작으로 {Source RLOC, Destination RLOC}를 벗겨내고 {Source EID, Destination EID} 곧 {Source IP address, Destination IP address}만을 갖는 정상 IP 패킷을 사이트 안으로 던져 넣어 종착단말에 도착하게 한다.

ILNP(Identifier-Locator Network Protocol)

ILNP는 IPv6의 128비트 주소를 반으로 나누어 위 64비트를 위치자로 쓰고, 아래 64비트를 식별자로 쓰자는 제안이다. 위치자는 부속망 단위로 배정되며 식별자는 단말마다 배정된다. 이미 IPv6에서 윗 64비트는 네트워크첨자(network prefix), 아래 64비트는 인터페이스식별자로 쓰고 있는 것을 생각하면 어찌보면 새로울 것이 없는 제안으로 여겨질 수도 있다. 하지만 IPv6의 인터페이스식별자는 통상 LAN MAC 주소를 가져다 쓰는 등 그 유일성이 부속망 안에서만 보장된다. 반면 ILNP의 식별자는 글로벌 유일성이 보장되는 것을 전제로 한다. 곧, IPv6에서는 128비트의 글로벌 유일성이 보장되어야 하는 반면, ILNP에서는 위치자와 식별자의 각 64비트가 별도 독립적으로 글로벌 유일성을 가져야 한다. 결국, 2**128과 2x(2**64)의 차이라고 볼 수 있다.

이후 동작은 통상적인 LIS 방법이다. TCP/UDP 연결은 식별자로 이루어지고, IP 라우팅은 위치자로 이루어진다.

LISP와 ILNP의 비교 및 전망

LISP는 시스코의 작품이다. 시스코가 라우터 시장을 장악하고 있는 만큼 LISP는 이미 시제품이 생산되어 판매, 시험설치/운영이 되고 있다. 반면 ILNP는 LISP에 회의적인 그룹이 IRTF(Internet Research Task Force)의 RRG(Routing Research Group)에서의 지난 몇 년 동안의 작업으로 우여곡절 끝에 채택된 안이다. ILNP는 아직 시제품이 없으나 핵심 그룹들이 시제품 개발을 하고 있는 것으로 알려져 있다.

LISP의 장점은 호스트에 아무런 변화가 없다는 것이다. 다만, 새로운 라우터를 포설하는 것이 문제이다. 반면 ILNP는 엄밀히 말해 IPv6 또한 아니므로, 모든 호스트가 바뀌어야 한다. 이것은 ILNP의 큰 부담이라고 할 수 있다. 호스트가 바뀌기 쉬우냐 아니면 라우터를 바꾸는 일이 더 쉬우냐는 결론이 쉽지 않은 계속되는 커다란 논쟁 거리이다.

시스코가 라우터 개선 방법인 LISP를 들고 나온 것은 너무나 당연한 일이다. 바로 라우터 회사이기 때문이다. 결국 시스코는 LISP로서 또다른 시장을 창출하려는 의도가 있음이 분명하다. 과연 LISP 라우터의 도입으로 주장하는 투자 효과를 얼마나 거둘 수 있는지는 두고 볼 일이다. 일부 포설된 LISP라우터를 IPv4 망 위에서의 IPv6 망 터널링으로 사용하는 변형적 현상도 목격된다.

LISP는 멀티호밍은 그런대로 해결하고 있지만 단말의 신속 이동성에는 별무대책이다. 통상의 Mobile IPv4나 Mobile IPv6에 의존한다. 따라서 이동성 면에서는 획기적인 개선이 있었다고 하기 어렵다.

ILNP에서는 단말이 수시로 자신의 위치자를 갱신하며 상대방에게 직접 알리므로 Mobile IP에 비해 이동성이 크게 개선된다고 할 수 있다. 다만 그 성능은 {식별자, 위치자} 변환서버의 성능에 좌우될 것이다. 이 변환 서버의 문제는 LISP에도 존재한다. 다만, LISP에서는 라우터가 변환서버와 동작하는 반면, ILNP에서는 호스트가 직접 변환서버와 연동한다. 두 방식 모두 변환 서버의 성능에 전체 시스템 동작이 크게 영향을 받으며 해결해야 할 커다란 다른 혹 하나씩을 만들어낸 셈이다. 결코 간단하지 않은 문제이다. 어쩌면 두 시스템 모두 실패로 몰아갈 아킬레스근이 될 수도 있다.

ILNP는 IPv6 인프라에 다분히 의존적이다. 다만 거의 모든 호스트가 이미 IPv6-ready 상태이고 ILNP 위치자+식별자 포맷과 IPv6 주소 포맷이 동일하게 보일 정도로 유사하여 간단한 패칭 작업으로 모든 IPv6 호스트를 ILNP 호스트로 바꿀 수 있다는 주장이다. IPv4 위에서도 동작하는 방법이 있긴 하지만 IPv4 Option 필드를 써야 하는 어려움이 있다. 한편, LISP는 덧붙여지는 RLOC으로 패킷이 커지므로(IPv6 망을 통과할 때는 2x128비트, IPv4 망을 통과할 때는 2x32비트) 실질적 MPDU(maximum Packet data unit:  최대패킷길이)가 작아지는 단점 등이 있다.

HIP, LISP, ILNP 등 지금까지 나온 LIS 해결책 중 어느 것도 아직 광범위한 지지는 못 받고 있고 그 어느 것도 전세계적인 확산으로 이어진다고 장담할 수 없다. DFZ 라우팅 테이블 폭발이 진정 국면에 들어섰다는 보고도 있고 해서, LIS 도입이 필수불가결한 일인지에 대해서도 의문을 갖는 사람들이 적지 않다. 다만, 거의 모든 미래인터넷 구조 제안에서 LIS는 너무나도 당연한 명제인 것으로 설파되고 있기 때문에 LIS가 언젠가는 오고야 말 것이라는 주장도 유효하다. 한편, LIS 주장 논리의 맹점을 지적하며 LIS에 기반하지 않은 다른 네트워크 구조를 제안하는 그룹들도 있어 앞으로 인터넷이 어느 방향으로 진화할 지 아직은 미지수이다.

[참고문헌]

1. D. Farinacci et al., http://tools.ietf.org/html/draft-ietf-lisp-23

2. RJ Atkinson et al., http://tools.ietf.org/html/draft-irtf-rrg-ilnp-arch-03