카테고리: Layer3

Network Study – 6주차 : VPN(Virtual Private Network) 프로토콜

VPN(Virtual Private Network, 가상 사설망)은 본래 전용 회선(Leased-Line)을 사용하던 기업체들이 인터넷의 확산과 더불어 비용 절감을 꾀하기 위해 만들어낸 기술이다.
전용 회선을 임대하거나, 속도가 보장된 가상 회선을 임대하는 경우(MPLS)와 달리 VPN은 인터넷 망을 그대로 이용한다는 차이점이 있다. 이를 통해서 일반적인 인터넷 회선 사용료를 지불하는 것으로 본-지사간의 네트워크를 구성할 수 있었으나, 전용 회선 혹은 MPLS에서 보장하던 QoS등의 서비스를 제공받을 수 없게 되었다.

또한, 물리적 혹은 논리적으로 하나의 회선을 독점하였던 기존의 서비스와는 달리 인터넷 망을 사용하기에 외부로부터의 접근에 취약해진다는 문제가 있었다. 이를 해결하기 위해 모든 VPN 프로토콜들은 사용자를 인증하고 전송하는 모든 패킷을 암호화한다.
물론 사용하는 암호화 알고리즘과, VPN 터널 생성 방법은 프로토콜마다 다르다.

그리고 개발 목적이 본-지사간의 네트워크를 연결하는 것이었기에, 물리적으로 연결되어 직접 있지 않은 네트워크와 직접 통신할 수 있다는 특징을 가진다.

 

1. VPN 프로토콜의 종류

흔히 사용되는 VPN 프로토콜들은 다음과 같다.

– Internet Protocol Security(IPSec)
– Transport Layer Security(SSL/TLS)
– Datagram Transport Layer Security(DTLS)
– Point to Point Tunneling Protocol(PPTP)
– Secure Socket Tunneling Protocol(SSTP)
– Secure Socket Shell VPN(SSH-VPN)

이제 각 프로토콜의 알고리즘을 살펴 보자.

1-1. IPSec

IPSec은 AH(Authentication Header), ESP(Encapsulating Security Payload), IKE(Internet Key Exchange)로 구성되어 있다. AH는 인증 과정을, ESP는 페이로드의 암호화와 흐름 제어를 제공한다. 그리고 IKE는 키 매니지먼트를 제공한다.
IPSec은 고품질의 통합된 암호화 기반의 보안을 IPv4와 v6에 제공하기 위해 디자인되었고, 접근 제어, 비연결형 무결성(Connectionless Integrity), 데이터 출처 인증(Data Origin Authentication)과 재전송 공격의 차단, 암호화에 의한 기밀성, 제한적인 흐름 제어 무결성(Limited Flow Control Integrity)를 제공한다. 이러한 서비스들은 IP레이어에서 제공되며, IP 자신을 포함한 상위 프로토콜들에게 보호를 제공한다.

IPSec은 또한 최소한의 방화벽 기능을 포함한다. 이것은 IP 레이어에서의 접근 제어 측면에서 필수불가결한데, 만약 좀 더 정교한 방화벽 메커니즘을 제공할 수 있다면 그것을 사용하면 될 것이다(다만, IPSec 구현체에 의해 방화벽의 흐름 제어 기능이 강제되고, 트래픽 선택자(Traffic Selector)기능이 IKEv2에 의해 협상되지 않는다면 상호 운용성 측면에서 문제가 생길 것이다.)
IPSec 방화벽 기능은 강제 암호화된 인증과 무결성을 모든 IPSec 트래픽에게 제공할 수 있으며, 이것은 방화벽에 암호화에 의한 보호를 더하는 것 보다 나을 것이다.

IPSec이 성공적으로 적용되고 배포된 뒤, IPSec의 보호를 적용받지 않는 유저와 호스트, 그리고 다른 네트워크 구성요소들에게 영향을 미쳐서는 안 된다. AH와 ESP, 그리고 필요하다면 IKE는 독립적인 암호화 알고리즘으로 개발되었으며, 이것은 다른 구현 부분에 영향을 미치지 않고 적절한 암호화 알고리즘을 선택할 수 있도록 한다. 광역 인터넷에서의 상호 운용성을 만족하기 위하여, AH와 ESP에 쓰이는 기본 암호화 알고리즘이 RFC 4305에 정의되었다. 그리고 IKEv2를 위해 반드시 구현되어야 하는 암호화 알고리즘이 RFC 4307에 정의되었다. 이 알고리즘들은 암호화 기술의 발전에 따라 주기적으로 업데이트 될 수 있으며, 이러한 표준 암호화 알고리즘들을 분리함으로써 각 프로토콜들은 서로에게 영향을 미치지 않고 알고리즘을 갱신할 수 있다.

 

IPSec 보안 서비스는 IP레이어에서 Security Protocol, 암호화 알고리즘과 암호화 키를 선택할 수 있게 한다. IPSec은 (1) 호스트와 호스트 간의 경로를 보호하거나, (2) 보안 게이트웨이 사이의 연결을 보호하거나, (3) 보안 게이트웨이와 호스트 사이의 연결을 보호할 수 있다. 호스트 구현체들은 반드시 (1)(3)을 구현해야 하며, 보안 게이트웨이의 구현체는 3가지의 연결을 모두 구현해야 한다.
앞서 말했듯이 IPSec은 보안 기능을 제공하기 위해 AH, ESP 프로토콜을 사용하는데, 각각의 역할은 다음과 같다.

– AH(Authentication Header) : 무결성과 데이터 출처 인증을 제공한다. 옵션으로 재전송 공격을 차단하는 기능을 제공한다(수신자 단에서 구현한다)
– ESP(Encapsulating Security Payload) : AH의 기능과 더불어 기밀성을 제공한다. 무결성 없이 기밀성을 사용하는 것은 권장되지 않는다. 그리고 ESP의 기밀성이 활성화되면 제한된 트래픽 흐름 기밀성을 제공한다. 예를 들어 패킷 길이를 감추고, 효율적으로 더미 패킷을 생성하고 파기할 수 있다.

AH와 ESP 모두 접근 제어를 제공한다. 이것은 SPD(Security Policy Database)에 서술되어 있는 암호화 키의 분배와 프래픽 흐름 관리에 의해 강제된다.
두 프로토콜들은 모두 개별/통합적으로 제공될 수 있다. 하지만 대부분의 경우 ESP만을 사용하는 것으로 보안 요구사항이 충족될 것이다.
그리고 각 프로토콜들은 Transport Mode와 Tunnel Mode를 지원한다. Transport 모드의 경우 AH와 ESP는 다음 레이어의 프로토콜에 보안성을 제공한다. 그리고 Tunnel 모드에서는 IP 자신도 함께 보호한다.
이 두 모드의 차이점에 대해서는 추후 좀 더 자세히 다루겠다.

IPSec에서 제공하는 대부분의 보안 기능들이 암호화 키를 필요로 하기에, IPSec은 적절한 곳에 적절한 키를 입력해주는 매커니즘을 필요로 한다. IPSec은 수동과 자동 입력을 모두 지원하지만, 그 중 자동화된 공개키 기반의 키 관리 방법이 IKEv2로 정의되었으며, RFC 4306으로 배포되었다. 하지만 다른 자동 키 분배 메커니즘도 사용될 수 있을 것이다.

1-1.1. Security Associations

이 단락에서는 AH와 ESP를 포함한 IPv6, IPv4 구현체가 필요로 하는 IPSec fundamental에 대하여 다룬다. SA를 구성하기 위해 AH와 ESP가 사용되며, IKE의 주된 기능 또한 SA를 형성하고 유지하는 데 이용된다.
모든 AH와 ESP의 구현체는 SA의 개념을 만족해야 한다.
SA는 간단히 말해 보안 기능을 제공하고 트래픽을 옮기는 “연결”을 말한다. 보안 기능은 AH나 ESP를 사용함으로써 SA에 의해 제공되고, AH와 ESP의 보호가 동시에 적용되는 경우, 두 개의 SA가 형성되어 보호를 두 번 적용하는 것으로 동시에 사용된다. 일반적으로, 양방향 통신이 이루어질 때 한 쌍의 SA가 필요하다.

SA가 유니캐스트 트래픽 전달에 사용될 경우 SPI(Security Parameters Index)만으로 SA를 나타내기에 충분하다. 하지만 지역적인 문제로(SPI Collision?) IPSec 구현체들은 SA인증을 위해 SPI와 IPSec 프로토콜을 함께 사용해야 할 것이다. 만약 구현체가 멀티캐스트를 지원한다면, 그것은 멀티캐스트 SA를 지원하기 위해 de-multiplexing 알고리즘을 지원해야 한다.

많은 안전한 멀티캐스트 알고리즘들이 있지만, 그 중에서 RFC 3740에서 정의된 중앙 그룹 컨트롤러/일방적으로 할당된 GSA의 SPI를 가지는 키 서버 모델은 키 매니지먼트 서브시스템에 의해 협상될 수 없고, 그렇기에 GSA와 유니캐스트 SA가 동시에 같은 SPI를 사용할 수 있다. 멀티캐스트 지원 IPSec 구현체는 반드시 de-multiplex 인바운드 트래픽을 SPI 충돌이 발생하는 상황에서도 올바르게 전달하여야 한다.

 

여기서 IPSec에서 사용하는 데이터베이스의 개념을 짚고 가자.
IPSec은 크게 두 종류의 데이터베이스를 사용하는데, 하나는 SAD(Security Association Database), 다른 하나는 SPD(Security Policy Database)이다.

SAD는 SA의 집합체인데, IPSec이 적용되는 특정 Connection에 대하여 SA가 정의되고, 그것의 집합이 SAD가 된다. Incoming, Outgoing 트래픽에 따라 각각 정의된다.
SAD에는 다음과 같은 내용이 포함된다.

– AH Parameter : AH 사용시 이와 관련된 인증 알고리즘 및 관련 Key
– ESP Parameter : ESP 사용시 이와 관련된 인증 알고리즘 및 관련 Key
– Mode : Transport Mode / Tunnel Mode
– Destination IP Addr, IPSec Protocol (AH or ESP), SPI : SPI는 하나의 목적지에 대해 다수의 SA가 정의되어 있을 경우 사용하는 식별자(Index)이다.
– Lifetime : SA의 생존시간

SPD는 System Manager에 의해 정의되며, 어떠한 트래픽에 IPSec 서비스가 적용될지 정의한다. 참고로 IPSec의 동작에는 Discard, Protection, Passthrough가 있음을 미리 밝혀 둔다.
이러한 Policy의 적용은 다음과 같은 항목에 의하여 결정된다.

– Source / Destination Address
– Name : DNS 사용자 식별자 / FQDN
– Transport Layer Protocol : TCP or UDP
– Source / Destination Port

SPD는 조건에 맞는 SAD의 SA들을 지정하고, 트래픽이 IPSec 레이어를 통과할 때 정책을 적용한다.

다시 원점으로 돌아가, SAD의 각 엔트리는 반드시 Source/Destination IP Address를 표시해야 한다. 이것은 멀티캐스트의 경우 SPI가 중복될 수 있기 때문에, SPI가 중복될 경우 Destination IP Address로 목적지를 결정하기 위함이다.
이렇게 SA와 Source-Destination Address를 매칭하는 것은 들어오는 IPSec 트래픽과 SA를 매핑해야 한다는 것을 의미한다.

그리고 제한적인 QoS의 경우, DSCP(Differentiated Service Code Point) 비트가 같은 SA로 전송되고, 수신자가 재전송 방지 기능을 AH와 ESP에서 활성화해 놓았다면 그 결과 더 낮은 우선순위의 패킷이 Windowing 메커니즘에 의해 파기되게 된다.
그렇기 때문에 송신자는 반드시 트래픽을 다른 클래스로 보내고, 같은 셀렉터 값을 지정한 뒤 다른 SA를 할당해야 한다. 이 기능을 지원하기 위해 IPSec 구현체는 송신자와 수신자 사이에 다수의 SA를 만들고 유지할 수 있어야 한다.
이러한 병렬 SA를 통한 트래픽 분산은 송신자에 의해 지엽적으로 결정되며, IKE에 의한 교섭을 거치지 않는다. 수신자는 다른 SA들로 들어오는 트래픽을 편견 없이 처리해야 한다.

앞서 서술했듯이, Transport Mode와 Tunnel Mode. 두 종류의 SA가 정의된다. IKE가 한 쌍의 SA를 만들고, 처리의 단순화를 위해 한 쌍의 SA는 반드시 같은 모드여야만 한다.
Transport Mode SA는 주로 한 쌍의 호스트가 종단간 보안을 제공해야 할 경우 사용된다. Transport Mode가 Security Gateway간, Host-Security Gate간에서 사용될 경우 Transport Mode는 in-IP Tunneling이나 GRE(Generic Routing Encapsulation)을 사용할 것이다. 상황을 명확하게 하기 위해, Intermediate System에 의한 Transport Mode 사용은 인바운드의 Destination Address 아웃바운드의 Source Address가 Intermediate System에 속해있는 경우로 한한다. 그리고 Transport Mode의 경우 종단간 패킷 헤더에는 적용되지 않는다. 그러므로 이 모드의 IPSec은 신중히 적용되어야 할 것이다.

Tunnel Mode SA의 경우,  SA는 IP tunnel을 적용받는다. 접근 제어가 헤더와 트래픽에 모두 적용되며, 두 호스트는 반드시 서로에게 Tunnel SA를 만들어야 한다. 아래의 두 예외를 제외하고, Tunnel SA의 종단은 Security Gateway가 된다. 그러므로 두 Security Gateway 사이의 연결은 보통 Tunnel Mode SA이며, 그렇지 않은 두 종류의 예외는 다음과 같다.

–  트래픽이 Security Gateway를 지나갈 때 : 예를 들어 SNMP 프로토콜의 경우 Security Gateway가 호스트처럼 동작하고, Transport Mode가 허용된다. 이 경우 SA는 Security Gateway내의 호스트(매니지먼트) 기능에서 종단된다.
– 앞서 말했듯이 Security Gateway들은 경로 상의 IP 트래픽에게 보안을 제공하기 위하여 Transport Mode를 지원할 수 있다.

이러한 보안 서비스의 집합들은 SA 모드와 프로토콜의 선택에 달렸다.
예를 들어, AH와 ESP 둘 다 무결성과 인증 기능을 제공하지만, 적용 범위는 각각의 프로토콜마다 다르며, Transport/Tunnel 모드에 따라서도 다르다. 만약 IPv4옵션과 IPv6 확장 헤더의 무결성이 보장되어야 한다면, 옵션이 예키치 못하게 수정될 수 있는 AH 대신 ESP를 사용해야 할 것이다.
접근 제어를 쪼개보면, 가장 먼저 어떠한 셀렉터를 고르느냐에 따라 결정된다. 예를 들어, IKE와 Child에 따라서 다른 접근 제어 방법을 가진다.

일단 암호화에 사용되는 프로토콜이 결정되면, ESP SA는 양쪽 끝단에서 부분적인 트래픽 흐름 기밀성을 제공할 수 있다. 터널 모드를 사용하는 것은 내부 IP 헤더를 암호화하고, 트래픽의 발신지와 수신지를 감춘다. 거기에 ESP 페이로드의 패딩은 패킷 사이즈를 감추어 트래픽의 특정을 어렵게 만들 수도 있다.
IPSec 구현체들은 반드시 ESP SA가 암호화와 무결성 알고리즘을 사용하지 않고는 설정될 수 없도록 만들어야 한다.

 

1-1.2. AH(Authentication Header)

AH는 IP Extension Header로서, IP Packet에 대한 인증을 제공한다. 암호화를 수행하지 않기에 데이터그램의 기밀성은 보장하지 않으며, 앞서 말했듯이 IP 패킷 인증, 무결성 검증, 출발지 기반 인증과 재전송 공격의 방어를 제공할 수 있다.

IPSec Transport Mode와 Tunnel Mode에서의 패킷 구조를 나타낸 것이다. Transport Mode를 사용할 경우 IPv4 헤더의 뒤에 AH가 오고, Tunnel Mode를 사용할 경우 IPv4 헤더의 앞에 위치하여 IPv4 데이터그램을 캡슐화한다.

AH의 상세 구조를 나타낸 것이다. Payload Length는 IPv4 페이로드의 길이를, SPI는 앞서 설명한 SA 식별자를, Sequence Number는 AH Processing을 수행할 때마다 1씩 증가하며, 재전송 공격의 방어에 사용된다.
마지막으로 Authentication Data는 패킷 데이터 전체에 대한 해쉬 값으로, 변하기 쉬운(Mutable) 값들은 0으로 세팅하여 계산한다.

1-1.3. ESP(Encapsulating Security Payload)

ESP는 AH의 기능에 덧붙여 암호화를 제공한다. 때문에 대부분의 IPSec 연결들은 ESP를 사용하며, VPN에서 사용되는 것도 ESP이다.

ESP 또한 Transport Mode와 Tunnel Mode를 지원한다. AH와는 달리 ESP 헤더가 오고, ESP Auth Data가 마지막에 위치하는 것을 알 수 있다. 이는 ESP 헤더 ~ ESP Auth Data 사이의 페이로드만이 암호화 되기 때문이다.

ESP 패킷의 상세 구조이다. 페이로드 뒤에 패딩이 오고, 패딩을 포함하여 암호화를 하는 것에 주목하자. 패딩이 적용될 경우 원본 데이터그램의 길이를 유추하는 것이 불가능하기에 패킷 분석에 어려움을 더한다.
따라서 공격자로부터 더 안전한 프로토콜이 되겠다.

1-2. PPTP

PPTP는 인터넷의 초창기에 등장한 암호화 프로토콜로, Microsoft와 Ascend Communications, 3Com에 의하여 개발되었다.
PPTP의 프로토콜 명세는 1999년, RFC 2637로 배포되었으며, Microsoft Windows에 기본적으로 내장되어 있기에 가장 널리 쓰이는 VPN 프로토콜이 되었다.

하지만 RC4 해쉬 알고리즘이 Bias를 가진다는 것이 널리 알려져 있으며, 인증 프로토콜로 사용되었던 MS-CHAPv1이 56-Bit DES 암호화를 사용하기에 현대의 컴퓨팅 기술로는 비밀키를 손쉽게 추론할 수 있게 되어서 더 이상 안전하지 않은 프로토콜로 분류, IPSec, L2TP 등의 더 안전한 프로토콜을 사용할 것을 권고하고 있다.

 

PPTP는 터널 형성을 위해 PPP(Point-to-Point Protocol)과 GRE(Generic Routing Encapsulation)을 사용한다.
PPP가 Data-Link 계층에서 사용하기 위해 개발되었기에, PPP를 캡슐화하기 위해서 GRE가 사용되며, IP 패킷은 PPP로 캡슐화된 뒤 GRE로 다시 캡슐화된다. 따라서 아래와 같은 패킷 구조를 갖는다.

그리고 PPTP는 데이터 전송 채널과 제어 채널이 분리되어 있는데, 제어 채널은 TCP 연결을 사용하고, 캡슐화되지 않는다.

그리고 GRE-PPP만으로는 터널은 구성되지만 페이로드에 대한 암호화가 수행되지 않기에, 따로 MPPE(Microsoft Point-to-Point Encryption)을 이용하여 암호화를 수행한다.
MPPE는 RFC 3078로 출판되었으며, PPP Payload에 대한 암호화를 수행한다.

MPPE는 Keberos나 TLS 등의 방법으로 세션 키를 교환하고, 세션 키를 이용해 RC4 암호화를 수행함으로써 동작한다.

Network Study – 5주차 : OSPF의 설계와 표준화

 

OSPF 스터디의 마무리를 짓기 위하여 OSPF – Anatomy of an Internet Routing Protocol를 읽고 있다. 본래는 OSPF의 상세 동작을 공부하기 위하여 읽기 시작하였으나, 의외로 라우팅 프로토콜 -특히 OSPF- 의 역사에 대해 충실하게 서술하고 있었기에, 이번 주 주제를 이것으로 정하게 되었다.

1. Internet의 역사

모두가 잘 알다시피 인터넷은 ARPANET으로부터 시작되었다. ARPANET은 미 국방성에서 패킷 스위칭 네트워크를 테스트하기 위해서 구축한 일종의 실험 네트워크였으며, 차차 미군의 군사 네트워크 시스템을 대체하게 된다. 한편, 패킷 스위칭 기술이 일반에 공개된 후 1985년, NSF(National Science Foundation)에서 NSFNET을 구축한다. NSFNET은 LSI-11 기반의 라우터들과 56Kbps Leased-Line으로 구축되었으며, 곧 ARPANET을 대체하였다. 1987년 NSFNET은 IBM RT 베이스의 라우터와 T1 회선으로 업그레이드 된다. 1992년에는 회선 속도가 T3로 올라가며, 1995년에 폐기되었다.

NSFNET Backbone은 인터넷의 모태가 되었으며, 지금은 ISP들의 백본과 IX(Internet Exchange)들이 그 자리를 대신하고 있다.

2. OSPF의 개발

OSPF(Open Shortest Path First Protocol)은 인터넷의 표준 라우팅 프로토콜을 목표로 개발이 시작되었다. 1987년 OSPF Working Group이 IETF에서 구성되면서 시작된 개발은 1997년, OSPFv2가 발표되고, 2016년 현재에 이르기까지 계속 발전되어 오고 있다.
OSPF Working Group이 탄생하였던 1987년, OSPF 개발에 참여하였던 개발자들은 다음과 같은 몇 가지 목표를 두고 OSPF의 기본 디자인을 시작하였다.

– RIP의 대체 : 네트워크의 크기가 증가하면서, RIP 트래픽의 크기가 점증, 회선에 부하를 가하기 시작하였고, Count Infinity와 Late Convergence 등의 문제를 가지고 있었다. 당시 AS간의 프로토콜로 사용되던 EGP도 문제가 있었으나, OSPF의 개발자들은 RIP를 대체할 프로토콜을 개발하는 것이 EGP의 대체품을 개발하는 것보다 더 쉽고, RIP를 대체하는 편이 더 광범위하게 받아들여질 것으로 기대했기 때문이라 밝히고 있다.
– 라우팅 메트릭의 구체적인 서술 : RIP는 홉 카운트를 메트릭 값으로 사용하였고, 이것은 대역폭이 더 큰 링크를 사용하지 않게 되는 등의 부작용을 가져왔다.
– 계층화된 라우팅 : 수 천대에 이르는 라우터들을 포괄하는 네트워크를 위해서는 라우팅을 계층화하는 것이 필요하다고 여겨졌다. OSPF는 2계층의 라우팅 규칙을 가진다.
– 내부/외부 경로의 분리 : RIP를 사용하는 AS들은 신뢰 문제를 가지고 있었다. AS 운영자들은 내부 루트를 외부 루트보다 우선하고 싶어했지만, RIP는 이 두 종류의 루트를 구분하지 못하였다. OSPF는 내부 경로가 외부 경로를 덮어쓴다.
– 더 유연한 서브네팅 방법 : OSPF가 디자인되던 시기에 인터넷은 클래스 A, B, C에 따른 서브네팅을 수행하고 있었다. OSPF의 개발자들은 CIDR와 VLSM이 빠른 속도로 확산될 것이라 믿었고, OSPF는 VLSM을 지원하도록 만들어졌다.
– 보안 :  RIP는 누구나 라우팅 광고를 보낼 수 있고, 가짜 광고에 취약하게 된다. OSPF LSA는 Key를 통한 인증을 수행할 수 있으며, 인증된 라우터만이 OSPF 도메인에 참여할 수 있다.
– ToS 기반 라우팅: TCP/IP는 ToS 필드를 통해서 5가지의 클래스를 지원하였는데, 각 클래스별로 다른 경로를 선택할 수 있기를 바랬다.

OSPF는 ToS 기반 라우팅을 클래스 별로 다른 메트릭 값을 줌으로써 실현하였다. 하지만 IP에서 ToS의 지원은 옵션이었고, OSPF의 ToS 기반 라우팅 구현들이 많이 등장하였음에도 불구하고 ToS 기반 라우팅은 인터넷에 적용되지 않았다.
그 이유는 아마 달걀과 닭의 문제일 것이다. 라우터가 ToS 필드를 처리하지 않기에 호스트는 ToS 필드를 태그하지 않는다. 그리고 호스트가 ToS필드를 태그하지 않기에 라우터는 ToS 필드를 태그하지 않는다.

2-1. Link-State vs Distance Vector

RIP를 위시한 Distance Vector 프로토콜들이 인터넷에서 널리 사용되고 있었다. Distance Vector 프로토콜은 분산된 처리 모델을 적용하고 있는데, 그것은 각 라우터들이 자신의 이웃 라우터로부터 받은 정보를 가지고 라우팅 계산을 수행한다는 의미이다.
라우터는 현재 토폴로지의 정보를 이웃 라우터로부터 전달받고, 계산을 수행한 뒤 그 정보를 다시 다른 라우터에게 전파한다. 이 과정은 모든 라우터들이 최적 경로를 수립할때까지 계속된다.
Link-State 프로토콜은 대개 분산 데이터베이스 모델을 채택한 다익스트라 최단 거리 알고리즘을 사용한다. 각  라우터는 토폴로지 환경을 LSA(Link-State Advertisement)를 통해 알리고, 그것을 수신한 라우터는 LSA를 플러딩한다. 결국 토폴로지의 모든 라우터가 동일한 LSDB(Link-State Database)를 가지게 된다.
그리고 데이터베이스의 정보를 다익스트라 최단 거리 알고리즘으로 계산함으로써, 목적지까지의 최단 경로를 알아내게 된다.

RIP는 인터넷의 대형 AS에 적용하였을 경우 문제가 많았다. 느린 수렴 시간을 가졌고, 네트워크 대역폭을 많이 소비하였다. 그리고 절단된 경로를 제거하는 것이 느려 Counting to Infinity 문제를 발생시켰다.
BBN은 ARPANET의 라우팅 프로토콜에서 동일한 문제점을 발견하였고, 이러한 문제점을 해결하기 위하여 최초의 Link-State 라우팅 프로토콜을 개발하게 된다. 이 라우팅 프로토콜은 원래의 Distance Vector 라우팅 프로토콜을 성공적으로 대체하였으며, 이러한 성공을 본 OSPF 개발자들은 TCP/IP를 위한 Link-State 라우팅 프로토콜을 개발하고자 하였다.

Link-State 프로토콜이 많은 사람들에게 있어 매력적으로 보였음에도 불구하고 구체화-구현까지의 과정이 Distance Vector 프로토콜에 비해 더 복잡하였기 때문에 멀티벤더 Link-State 프로토콜은 존재하지 않는 상황이었다 -몇몇 사람들은 그것이 불가능한 일이라고 생각하였다-
사실, 이것은 OIGP(Open Interior Gateway Protocol ) 워킹 그룹이 OSPFIGP(Open Shortest Path First Interior Gateway Protocol)와 ODVP(Open Distance Vector Protocol) 워킹 그룹으로 나뉘어지기에 충분한 이유가 되었다.
비록 ODVP 워킹 그룹이 단명하기는 했지만, 이 두 그룹은 직접적인 경쟁관계에 놓이게 된다.
되돌아보면, 그 뒤로 Link-State 라우팅 프로토콜이 대세를 차지하게 된다. OSPF 외에도 OSI의 IS-IS나 노벨의 NetWare Link Service Protocol, IBM의 Advanced Peer-to-Peer Networking과 ATM의 Private Network-to-Network Interface가 만들어졌다.

한편, 연구자들은 Distance Vector 프로토콜의 단점을 보완하기 위하여 노력하였고, Cisco 독점의 IGRP와, RIPv2를 통하여 계속해서 사용되게 된다. 물론, BGP도 Distance Vector를 사용한다.

 

2-2. Link-State 알고리즘 기본

Link-State 알고리즘을 개발하기로 결정했을 때, OSPF의 개발자들은 이미 존재하는 기술에  대해서 조사하였다. BBN이 Link-State 프로토콜을 개척하였고, 최초의 Link-State 프로토콜은 1979년 5월에 ARPANET에 적용되었다.
ARPANET의 단순성(동일한 장비, 동일한 소프트웨어, Point to Point 시리얼 연결) 덕분에  라우팅 프로토콜의 적용 또한 (상대적으로) 간편하였다. 반면에, TCP/IP 라우팅 프로토콜과는 달리, ARPANET의 라우팅 프로토콜은 경로 결정 뿐만이 아닌, 네트워크의 혼잡 또한 감지할 수 있도록 설계되었다.

ARPANET의 Link-State 프로토콜은 Link-State 프로토콜이 가져야 할 기본적인 부분들을 모두 확립하였다. LSDB와 확산 알고리즘에 따른 LSA 전파, 그리고 최단 거리 경로 계산이 그렇다. Area 기반의 라우팅 또한 ARPANET에서 개발되었는데, 실제로 적용되지는 않았다.

반면, 개선이 필요한 부분도 있었는데, 새로 연결된 링크를 탐지하기 위해서는 LSDB의 갱신 주기가 빨라져야 했고, 네트워크가 확산되던 시기, ARPANET의 플러딩 알고리즘의 취약점이 전체 네트워크를 마비시키기도 하였다.

BBN에서는 ARPANET의 라우팅 프로토콜을 TCP/IP 라우팅 프로토콜로 포팅하기도 했지만, 이 프로토콜은 Ethernet 네트워크 상에서 시리얼 연결을 시뮬레이션하였기 때문에 인터넷에서 사용하기에는 너무 비효율적이었다.
OSPF의 개발이 진행되고 있을 때 ISO에서는 OSI 프로토콜 스택에 포함되는 IS-IS를 개발하였다.

그래서 혹자는 “IS-IS를 사용하면 되지 않을까요?”라며 묻기도 한다. 하지만 IS-IS를 그대로 사용하기에는 몇 가지 문제점이 있었다.
첫번째로, IS-IS는 Link Layer 바로 위에서 동작한다. 이것은 레이어별 동작 위치에 따른 장단점을 이야기 할 때 다루도록 하겠다. 그리고 IS-IS는 LSA의 단편화를 지원하지 않는다. 라우터는 자신의 모든 라우팅 데이터를 하나의 LSA에 실어서 보내야만 한다.
또한, 많은 TCP/IP 환경에서 라우터들은 외부  경로(External Route)를 가지고 있는데, 이러한 설계는 유용하지 않다. IS-IS는 에어리어 기반의 라우팅을 지원하지만, 에어리어 사이의 쇼트컷을 지원하지 않는다. 이것은 OSPF 개발자들이 인터넷을 위한 라우팅 프로토콜을 개발할 때 반드시 필요하다고 생각했던 것이다.
또한, IS-IS는 패킷 포맷에서 필드 정렬(Alignment)를 수행하지 않는다. 이것은 프로토콜을 구현하는 것을 좀 더 힘들게 만든다.[1](원문 : making life more difficult for protocol implementors)

이러한 기술적인 문제들 때문에, IS-IS와 같은 프로토콜을 수정하는 것 보다 새로운 프로토콜을 설계하는 것이 더 쉽다고 생각되었다. 그리고 비 기술적인 부분으로, Internet Society의 많은 사람들은 IETF가 OSPF 프로토콜을 전적으로 설계하는 것이 더 바람직하다고 생각했다.
ISO Committee의 지향점은 ISO 프로토콜 스택을 위한 프로토콜을 개발하는 것이다. 이것은 인터넷을 위한 프로토콜을 개발하는 것과는 다소간 달랐다.

Link-State vs Distance Vector 논쟁과 마찬가지로, 새로운 라우팅 프로토콜을 만드는 것은 1992년, OSPF가 인터넷의 권장 IGP(Recommended IGP)가 되기 전까지 논쟁거리가 되었다.

 

2-3. 캡슐화

TCP/IP 라우팅 프로토콜을 설계할 때, 3종류의 캡슐화 방법을 선택할 수 있다. 라우팅 프로토콜은 Link Layer 위에서 돌아가거나, IP 네트워크 레이어 위에서 돌아가거나, TCP나 UDP 위에서 돌아갈 수 있을 것이다.
Link Layer 위에서 구현하기 위해서는 몇 가지 문제가 따른다. 대부분의 링크 계층 프로토콜들은 단편화 및 재조립 기능을 제공하지 않으며, 이것을 직접 구현해야 한다. 그리고 하위의 많은 링크 레이어 프로토콜들을 지원하기 위한 액세스 포인트가 제공되어야 할 것이다.

IP 위에서 구현할 경우, IP가 제공하는 단편화와 재조립 기능을 사용할 수 있다. 그리고, IP는 어떠한 링크 계층 위에서도 동작할 수 있도록 설계되었기에, 하위 레벨의 구현에 대해 신경쓸 필요가 없다. 하지만 IP의 포워딩 경로를 결정하는 프로토콜의 정보가 IP를 통해서 전달되는 것이므로, 정보 전달 방법을 매우 세심하게 설계할 필요가 있다.

UDP를 사용할 경우 체크섬과 8-bit인 IP 프로토콜 번호보다 더 큰 16-bit UDP 포트 번호를 사용할 수 있다. 그리고 몇몇 시스템들은 IP에 직접 접근하는 것은 특권을 필요로 한다(UNIX의 경우 superuser 권한) TCP를 사용할 경우 여기에 더해 신뢰성 있는 통신이라는 추가적인 이점을 가진다. TCP를 사용하는 프로토콜에는 BGP가 있다.

 

OSPF를 설계하던 시점에서, Link-State 라우팅 프로토콜은 자체적으로 신뢰성 있는 통신과 플러딩 메커니즘을 구현하고 있었다. 그리고 IP를 사용하는 것에 시스템 특권이 필요하다는 것은 일종의 ‘보안 장벽’으로 여겨졌다. UDP를 사용하는 것은 매 패킷마다 8바이트의 오버헤드를 더하는 일이었고, 그것을 통해 얻을 수 있는 8bit의 추가 공간은 사실 불필요한 것이었다.
그리하여 OSPF는 IP 레이어 위에서 동작하게 되었으며, IANA로부터 프로토콜 번호 89번을 부여받는다.

그리고, 캡슐화와 관련하여 추가적인 이슈가 있었는데, Ethernet과 같은 브로드캐스트 서브넷에서 동작할 때의 문제였다. 라우팅 정보 전송에 IP 브로드캐스트를 사용하는 RIP는 OSPF를 사용하지 않는 모든 단말에게도 패킷을 보냈고, 이것은 불필요한 라우팅 트래픽을 만들었다. 당시 개발중이었던 IP 멀티캐스트가 이 문제의 해결책이 될 것으로 여겨졌지만, 멀티캐스트를 사용하는 시스템의 수가 너무 적다는 문제가 있었다. 당시 UNIX에서 멀티캐스트를 사용하려면 커널을 직접 빌드해야만 했다. 하지만 OSPF의 개발자들은 멀티캐스트가 더 나은 방법이라 확신했고, 멀티캐스트 기반으로 OSPF를 설계하였다.

 

2-4. LSA 단편화

Link-State 프로토콜을 사용하는 라우터들은 자신의 라우팅 정보를 LSA(Link-State Advertisement)를 통해 주변 라우터에게 알린다. 만약 라우터가 자신의 정보를 하나의 LSA로 보내야 한다면, LSA의 크기는 아주 커질 것이다. 예를 들어, 인터넷의 IP 라우터들은 수천개에 이르는 경로들을 광고해야 한다. 그렇기에 많은 Link-State 프로토콜들은 하나의 큰 LSA 대신 작은 다수의 LSA를 만드는 것을 택하였다. 이것을 “LSA 단편화”라고 한다.

OSPF의 경우, LSA를 꽤 크게 만들 수 있었다. OSPF는 IP의 단편화와 재조립 기능을 사용할 수 있었고, 최대 65000바이트까지의 크기를 가질 수 있었다. 하지만, IP 단편화는 일반적으로 기피의 대상이 되었고, 대부분의 Link MTU 값이 1500Byte였기에 LSA의 크기를 그것보다 더 줄이기 위해 노력하였다.

LSA를 만들 때, 패킷의 크기를 가능한 한 크게 만드는 것은 패킷 전체에서 LSA 헤더가 차지하는 비율을 줄일 수 있다. 즉, 패킷 오버헤드가 감소한다. 하지만 OSPF는 LSA의 크기를 최대한 줄이는 것을 택하였다. 다수의 LSA를 통하여 개별 경로를 광고하는 것은 LSDB의 크기를 더 키우겠지만, 전체 라우팅 패킷의 양을 최소화 할 수 있을 것으로 여겨졌다. OSPF 도메인에서 변동이 발생하면, 오로지 변경된 경로의 정보만이 다시 플러딩된다.

LSA의 크기를 작게 만들고, 구조를 고정시킴으로써 LSA를 만들고 해석하는 것을 쉽게 하였다. 이것은 프로토콜을 구현하는 사람들에게 중요한 일이었다.
OSPF는 의도적으로 정적인 구조를 가지도록 설계되었다. 프로토콜에 유연성을 부여하는 것은 구현을 더 어렵게 만들고, 더 긴 테스트 시간을 필요로 한다. 그리고 최악의 경우에는 그러한 유연성 덕분에 구현체에서 보안 취약점이 생길 수 있다.

 

2-5. 서로 다른 Link Layer 프로토콜 위의 공통 매커니즘

각기 다른 특징을 가지는 많은 수의 Link-Layer 프로토콜들이 인터넷에서 사용된다. 어떤 프로토콜은 2개의 라우터끼리 서로 연결되고, 다른 프로토콜은 수 많은 라우터들이 서로 연결된다. 그리고 Ethernet과 같은 멀티캐스트가 지원되는 프로토콜과 ATM과 같이 멀티캐스트가 지원되지 않는 프로토콜이 존재한다. 이러한 프로토콜들은 서로 다른 MTU 값을 가지기도 하였다. Link-State가 ARPANET에서 개발되었을 때는 Point-to-Point 시리얼 연결만 고려하면 되었지만, 인터넷에서 OSPF가 널리 사용되기 위해서는 모든 종류의 Link-Layer 프로토콜들을 지원해야만 했다.

이러한 프로토콜들을 지원하기 위해서 OSPF는 3종류로 네트워크를 구분하였다.

첫번째가 바로 Ethernet이 사용하는 BMA(Broadcast Multi Access) 네트워크로, 브로드캐스팅이 지원되는 다중 접속 네트워크를 의미한다.
BMA 네트워크의 경우 LSA를 플러딩하는 방법이 문제가 되었는데, 각 라우터가 LSA를 전부 플러딩하게 되면 n2-n/2개의 LSA가 발생하게 된다. 이것은 네트워크 부하를 증가시킬 것으로 예상되었고(물론 RIP보다는 낫다), OSPF의 개발자들은 네트워크를 논리적인 성(Star)형 망으로 보는 구성을 취하게 된다. BMA 네트워크에서 OSPF는 LSA를 생성하는 역할을 맡는 DR(Designated Router)를 선출하며, 다른 라우터들은 LSA를 전달하는 역할만을 맡는다.
n개의 연결을 갖는 네트워크에서 Point-to-Point 플러딩 알고리즘을 사용함으로써, OSPF는 플러딩 트래픽을 최소화할 수 있었다.

두번째로, 브로드캐스팅이 지원되지 않는 다중 접속 네트워크인 NBMA(Non-Broadcast Multi Access)의 경우 DR 선출과 플러딩 매커니즘은 동일하나, 이웃 라우터들을 동적으로 찾을 수 없다는 차이점이 있다. 브로드캐스팅(멀티캐스팅)이 지원되지 않기에 이웃 라우터는 수동으로 지정되어야 한다.

마지막으로 포인트 투 포인트 네트워크의 경우, 1:1로 연결되기에 DR과 BDR을 선출하지 않으며, Neighbor끼리 LSA를 주고받음으로써 LSDB를 형성한다.

 

2-6. Backup Designated Router

브로드캐스트와 NBMA 네트워크에서는 DR에 의존하여 OSPF가 작동하게 된다. 하지만 DR이 다운된다면 새로운 DR이 선출되기까지 포워딩 결정이 이루어지지 못한다는 문제가 있었다. 이런 문제를 회피하기 위하여 BDR(Backup Designated Router)을 선출하고, DR과 동일한 매커니즘으로 LSDB를 유지, DR이 다운될 시 그 역할을 물려받게 하였다.

한편, 서브넷에 새로운 라우터가 추가될 때마다 SPF 재계산을 수행하는 것은 비효율적인 일이었고, 새로 추가된 라우터는 네트워크에 DR이 이미 존재하면 DR에 종속되어서 동작하도록 설계되었다.

 

2-7. 외부 경로 태그

OSPF는 OSPF 도메인 외부로부터 경로를 얻을 수 있도록 설계되었다. 외부 경로는 다른 라우팅 프로토콜로부터 학습하거나, 관리자가 직접 Static으로 지정할 수 있다. OSPF 워킹 그룹의 멤버였던 Milo Medin에 의해 외부 경로의 LSA에 External Route Tag를 붙였고, 이것은 OSPF에서 사용되지 않고, OSPF 도메인을 건너서 전달될 때 추가적인 정보를 전달하는 용도였다. OSPF가 최초로 디자인되었을 때, 이 외부 경로 태그의 용도는 아직 정해지지 않았으나 수 년 뒤 그것이 아주 유용하다는 사실이 증명되었다.
첫번째로, 태그는 라우팅 정책을 적용하기 위하여 사용되었다. 인터넷에서 하나의 라우터는 수 천개의 외부 경로를 전달받고, 포워딩 경로를 결정하며, ABR의 경우 그것을 다시 전달할 지 결정해야 한다. 이러한 결정은 대개 수동으로 입력된 라우팅 필터 리스트를 검색함으로써 이루어지는데, 외부 경로 태그는 OSPF 도메인으로 들어오는 경로들을 그룹화함으로써 설정을 단순화할 수 있었다. 특히 이것은 BGP-OSPF 간의 경로 전달에 유용하였다.

 

2-8. 계층적 축약

커다란 OSPF 네트워크를 구축하기 위하여 OSPF 라우팅 도메인은 지역별로 쪼개질 수 있다. 이것을 ‘Area’라고 한다. 에어리어의 세부 정보는 다른 에어리어들에게 감춰지며, 경로 정보는 집약되어(aggregated) 에어리어 경계를 넘어 전달된다. 이를 통해 라우팅 테이블의 크기가 지나치게 커지는 것을 방지하고, 더 큰 규모의 OSPF 도메인을 구성할 수 있도록 한다. OSPF 도메인을 에어리어 규모로 나누는 것은 2단계 계층 라우팅 방법으로 간주될 수 있다.

이러한 Area 구성을 위하여 디자인 단계에서 몇 가지 결정들이 내려져야 했다. 첫번째로, 무엇이 에어리어 경계가 될 것인지 결정해야 했다. 라우터? 네트워크 세그먼트? 혹은 둘 다? 앞서 다루었듯이 인터넷은 이미 네트워크 세그먼트들을 단위로 하는 Autonomous System을 경계로 나뉘어졌다.  하지만 OSPF는 정 반대의 선택을 하였고, OSPF Area의 경계는 라우터가 되었다. 이것으로 각 네트워크 세그먼트는 단 하나의 에어리어에만 속할 수 있으며, 이것은 Area Boundary에서의 주소 축약을 쉽게 만들어줄 것으로 생각되었다.

두번째로, 다른 에어리어에 어떻게 정보를 전달할 것인지 결정해야 했다. 목표로 하였던 스케일링 규모를 달성하기 위하여 에어리어를 건너서 전달되는 정보의 양을 줄여야 했다. 이것은 Abstraction(축약)이라 불리었는데, Link-State 프로토콜에서의 축약은 어려운 문제였다. OSPF 개발자들은 OSPF Network LSA와 유사한 구조로 정보를 전달할 수 있을지 검토하였다. 하지만 이러한 방법의 축약(DR과 연결된 라우터들의 ID를 전달하는 것)은 메트릭 값을 왜곡시킬 위험성이 있었다(Network LSA는 Metric을 포함하지 않는다) 그래서 단순히 Area 내부의 서브넷 정보를 축약해서 Distance Vector 프로토콜처럼 전달하였다(Summary LSA)

이러한 접근 방식을 취하면서도 Distance Vector 프로토콜의 문제점들을 피하기 위해서 OSPF는 모든 에어리어들은 Backbone Area라는 특별한 에어리어에 직접 연결되도록 강제했다. 에어리어 간 라우팅 정보는 반드시 Backbone Area를 거쳐서 전달되어야 하며, 단순한 Distance Vector 알고리즘으로 아무런 문제 없이 운용할 수 있게 되었다.
그리고 Backbone Area로의 물리적인 직접 연결이 힘든 경우를 위해, Backbone Area로의 논리적인 연결인 Virtual Links를 정의하였다.

 

3. OSPF 표준화

최초의 OSPF 프로토콜 명세가 1989년 8월 출판되었다. 대부분의 인터넷 프로토콜과 같이 OSPF도 버젼 넘버를 부여받았고, RFC 1131이 OSPFv1 프로토콜 문서가 되었다.
IETF의 모토가 “거친 합의, 작동하는 코드”였기 때문에 OSPF 설계가 종료되고, OSPF 워킹 그룹은 OSPF를 구현하여 실제로 동작한다는 것을 보여야 했다. 그리고 2개의 OSPFv1 구현체가 작성되었다. 하나는 Proteon의 라우터에서 동작하였고, 다른 하나는 메릴랜드 대학의 Rob Coltun에 의해 작성된 UNIX용 데몬이었다. 이 구현체의 소스코드를 아주 적은 값으로 입수할 수 있었기 때문에 널리 확산되었고, GATED 배포판에 포함되었다.

새로운 프로토콜의 구현체는 다양한 문제점을 숨기고 있었고, OSPFv1 또한 예외는 아니었다.
OSPF 라우터는 MaxAge가 지난 LSA를 폐기해야 하나, OSPFv1에서는 MaxAge가 초과된 LSA들이 라우팅 시스템을 돌아다니는 것이 확인되었다. 이 현상은 새로운 정보가 유입되는 것을 막을 수 있었고, 다음 버젼의 OSPF에서 이 문제가 해결되었음에도 MaxAge LSA를 폐기하는 문제는 많은 구현체에서 수 년간 남아 있었다.

다른 하나의 문제는 더 가상적인 것이었는데,  ARPANET의 Link-State 프로토콜은 라우팅 업데이트가 네트워크를 계속 순환하면서 전체 네트워크를 다운시켜 버리는 문제가 있었다. 이것은 ARPANET의 프로토콜이 LSA의 업데이트를 감지하기 위해서 사용한 Sequence Number에 기인하는데, Sequence Number의 공간이 충분히 크다고(패킷당 64Bit) 가정하였음에도 잘못 세트된 Sequence Number를 가진 패킷이 Wrap-around 되고, 또 Wrap-around 되었을 경우 Sequence Number를 업데이트 하기 위한 메커니즘의 결함으로, 특정한 Sequence Number를 가진 일련의 패킷들이 라우터로 들어오면, 무한히 정보를 업데이트하면서 네트워크를 마비시키는 문제였다. OSPFv1도 순환식 Sequence Number를 가지고 있었고, 이 문제를 해결하기 위하여 도입한 알고리즘의 결함이 발견되었기에, Linear한 Sequence Number를 가지도록 수정되어야 했다.

3-1. Sequence Number 문제

ARPANET은 원형의 Sequence Number를 가지고 있었다. 즉, 순환식 구조를 가지고 있었다. 그리고 Sequence Number는 한 시점에서 반원을 기준으로 유효하다고 판단되었는데(K1 < K2 < K1+n/2), 이 반원을 넘어가는 Sequence Number는 잘못된 것으로 판단되어 폐기되었다. 하지만, 만약 전체 공간을 1/3으로 나누는 일련의 Sequence Number들(K1<  K2<  K3)가 순차적으로 전송된다면, 각 LSA는 폐기되는 일 없이 네트워크를 순환하며 대역폭을 고갈시키고, 라우팅을 마비시키게 될 것이다. 실제로 ARPANET에서 이러한 문제가 발생하였고, OSPFv1에서는 Lolipop-Shaped Sequence Space를 도입하여 이것을 회피하였다. 최초 시작 값(S0)을 두고, 순환하게 되었을 때는 S1부터 시작하게 만든 알고리즘이었는데, 이 또한 S1~S3사이에서 문제가 발생할 경우 똑같은 취약점을 가지고 있었다.

그리하여 OSPFv2에서는 Linear Sequence Space를 도입하게 되는데, 32Bit의 Sequence Number 공간은 Signed 32-bit로 간주되고, 다음과 같은 순서로 동작한다.

1. 라우터는 최초의 Sequence Number(Initial Sequence Number, S0)를 0x80000001로 설정한다.
2. Sequence Number는 최대값(SMAX)인 0x7FFFFFFF까지 순차적으로 증가한다.
3. Sequence Number가 0x80000000이 되는 순간, Sequence Number는 S0으로 리셋된다.
4. 이 Sequence Number를 다른 라우터가 최신이라고 받아들이게 하기 위해 SMAX에 도달한 LSA를 MaxAge필드를 최대값으로 세트하여 플러딩, 폐기시킨다.

또한, OSPF는 체크섬을 통한 에러 감지와 홉을 지날때마다 LS Age 필드의 값을 증가시켜 MaxAge에 도달할 시 폐기함으로써 잘못된 LSA가 무한히 루핑하는 것을 막았다.

이러한 문제점을 해결하고 나서, OSPFv1는 몇 가지 최적화를 더했다. 이러한 문제점들은 널리 알려지지는 않았는데, 왜냐하면 OSPFv1이 인터넷에 적용되지 않았기 때문이다. 그리고 1991년 7월, OSPFv2가 RFC 1247로 출판된다.

3-2. 상호 운용성 테스트

다수의 독립된 구현체들이 서로 함께 동작하는 것은 좋은 프로토콜의 제작에 있어 필수적이다. 상호 운용성 테스트가 이루어지기 전까지는 프로토콜 명세 상의 모호함이 잘 드러나지 않는다. 구현자가 명세를 처음 읽고, 구현에 있어 모호한 점을 찾아내기란 쉬운 일이 아니기 때문이다. 그렇기에 종종 상호 운용성 테스트는 프로토콜의 구멍을 찾아내기도 한다. 특히, IETF의 라우팅 프로토콜 표준화 과정에서 상호운용성 검증은 필수적인데, TCP와 같이 호스트간의 운용성만 검증해야 하는 경우와는 달리, 라우팅 프로토콜은 네트워크 전체의 수 많은 라우터들과 협업해야만 하기 때문이다.

OSPF 프로토콜을 개발하는 동안 1990~1994년에 걸쳐 6번의 상호운용성 검증이 이루어졌다. 이 세션들에서 개발자들은 문제를 찾고, 버그를 고치고 경쟁자들의 어께 너머로 기술을 배우며 OSPF를 구현해나갔다.
테스트 토폴로지는 대개 작았지만, 3Com에서 열린 세션에서 인터넷(당시에는 BARBNet)연결을 통한 테스트를 진행하기도 했다.
OSPF의 bake-off는 이제 이루어지지 않지만, 벤더들이 자신들이 구현한 프로토콜들의 상호 운용성을 테스트하기 위한 장소는 여전히 존재한다.

테스트 중에 발견된 문제들은 주로 구현체의 문제였다. 테스트에 참가한 개발자들은 자신의 구현체를 빠른 속도로 탄탄하게 만들어갔으며, 테스트는 온갖 종류의 상황들을 만들어 냈다. 이들 중 몇몇은 프로토콜 명세와 충돌하기도 했는데, 주로 잘못된 프로토콜 패킷들이 발생하였다.
대부분의 문제들은 프로토콜 명세-특히 OSPF 패킷과 LSA 포맷-가 완성되지 않았기에 발생했다. 예를 들어, 최초의 테스트에서 디폴트 경로를 어떻게 나타낼 것인지에 대한 의견이 불일치하였다. OSPF에서 경로는 [네트워크, 마스크]쌍으로 표현되는데, OSPF 명세에서 네트워크만을 0.0.0.0으로 지정하였기에 한 구현체에서는 0.0.0.0과 0이 아닌 마스크를 디폴트 루트로 해석하고, 다른 구현체에서는 네트워크 마스크를 해석해서 디폴트 루트가 아니라고 생각하였다. (지금은 0.0.0.0 대역이 Reserved되어 있어 사용되지 않기에 이런 일이 발생하지 않는다)

테스트에서는 급격히 토폴로지가 변동하는 환경을 조성하기도 했는데, 라우터들이 주기적으로 리부트되고, 인터페이스가 살아났다 죽었다를 반복하는 등의 환경이었다. 이러한 환경은 OSPF 프로토콜 매커니즘에 부하를 가했고, 한 가지 예로 이웃 OSPF 라우터들이 서로의 OSPF Database를 동기화하는 과정 중에서 Sequence Number는 항상 증가할 것이라고 생각되었지만, Database Exchange 중에 LSA가 삭제되고 처음부터 다시 시작하는 경우가 발생하였다. 그래서 Database Exchange 메커니즘은 적절히 수정되어야 했다.

가끔은 OSPF가 디자인될 때 예상하지 못했던 상황이 발생하기도 했다. 한 경우, Virtual Link 설정이 OSPF 라우팅 계산을 실패하도록 만들었는데, 그 결과 OSPF 프로토콜 명세는 1994년, Virtual Links를 뜯어고치고서 재출판되었다.

 

3-3. 필드 테스트

상호운용성 테스트가 프로토콜 개발에 있어 많은 도움을 주긴 했지만, 여전히 실제 환경에서도 정상적으로 동작할지는 미지수였다. 그래서 상호운용성 테스트가 진행되던 도중 OSPF를 적용할 장소를 인터넷에서 찾기 시작했다.
처음은 OSPF의 개발자들이 OSPF를 사용하기 시작하였다. 그들은 자신들이 사용하는 네트워크에 OSPF를 적용하였고, 잘 동작할 때까지 테스트하였다. 그리고 OSPF 소프트웨어가 잘 동작한다는 확신이 들자 OSPF 개발자 외의 사람도 잘 사용할 수 있을지 테스트해볼 네트워크를 찾았다. NSF 지역 네트워크들이 적절한 대상으로 보였는데, 이 네트워크들은 당시 존재하던 TCP/IP 네트워크 중 가장 큰 네트워크였다. 그리하여 1990년, SURANet을 전환하려는 시도가 있었다.
OSPF로의 전환은 점진적으로 이루어지고, 라우터들은 RIP와 OSPF를 동시에 작동시킨 뒤, RIP 루트를 OSPF 루트로 전환할 계획이었다.

하지만 라우팅 테이블이 RIP를 사용하건, OSPF를 사용하건 간에 똑같아 보이는 문제와, 전환이 이루어지는 동안 전체 라우터를 텔넷과 SNMP만의 in-band management로 관리해야 하는 문제가 있었다. 이러한 이유로 몇 번의 시도 끝에 SURANet의 전환은 포기되었고, NASA Science Internet Network가 1990년 4월, RIP에서 OSPF로 전환되면서 OSPF가 최초로 인터넷에 적용된 사례가 되었다.

이러한 적용으로 OSPF는 몇 가지의 개선점을 발견하게 된다. 그 중 하나로, OSPF 라우터들이 불필요한 추가 Hop을 건너서 트래픽을 전달하는 경우가 있었다.
이것은 AS간 경계(OSPF Domain 경계)에서 발생했는데, AS 1의 Router A는 DMZ(현재는 Network Access Point라 불린다)에 연결되어 있고, AS 2의 Router C와 EGP로 정보를 교환한 뒤, “AS 2로 트래픽을 전달하고 싶으면 나에게로 보내”라고 말한다.
한편, 마찬가지로 DMZ에 직접 연결되어 있는 Router B도 AS 2로 트래픽을 전달하기 위해 Router C로 직접 전송하는 대신 Router A를 거치게 된다.
이 문제를 해결하기 위하여 OSPF에 Forwarding Address 개념이 도입되었다. 이제 라우터 A는 “AS 2로 트래픽을 전달하려면 Router C를 거쳐야 해”라고 말하게 되었다.

그리고 OSPF의 SPF Calculation을 수행하기에 충분하지 않은 CPU와 메모리를 가진 라우터들이 있었고, 이런 라우터들이 OSPF를 지원하기 위해 Stub Area라는 개념이 추가된다. Stub Area 내부의 라우터들은 외부 네트워크로의 트래픽 전달을 위해 ABR의 디폴트 루트만을 라우팅 테이블에 가지고 있는다. 이로써 라우팅 테이블의 크기를 줄이고, 연산 부하를 극단적으로 낮출 수 있었다.

또한, 실제 환경에서는 프로토콜 설계시 예상했던 것과 달리 IP 대역의 오버래핑이 발생하였다. OSPF는 Area 사이에서 IP 대역을 축약할 수 있는데, 최초에는 주소 대역의 오버래핑이 지원되지 않았다.
하지만, 하나의 IP 대역을 할당한 뒤 다른 Area에서 그 대역 중 일부를 재사용하는 것이 가능해야 했고, OSPF 명세는 이러한 설정을 지원하도록 수정되었다.

3-4. 표준이 되다

1992년부터 IETF는 인터넷의 공통 IGP를 선정하기 위한 작업에 들어간다. 사실상의 공통 IGP였던 RIP는 더 이상 적합해 보이지 않았다. 그리고 두 개의 공통 IGP 후보가 선정되었는데, 하나는 OSPF고, 다른 하나는 인터넷용으로 이식된 IS-IS(Integrated IS-IS)였다.
OSPF와 IS-IS가 둘 다 링크 상태 프로토콜이긴 하지만 둘 사이에는 기술적인 차이가 있었다. Integrated IS-IS가 기존 IS-IS의 개선판이기는 했지만, OSPF의 개발자들은 자신들이 IS-IS를 선택하지 않았던 원인들은 여전히 존재하며, OSPF가 더 좋은 선택이라고 생각했다. 물론, IS-IS의 개발자들은 IS-IS를 선호하는 자신들만의 기술적인 이유가 있었다.

한편, 기술적인 원인 외에도 IS-IS와 OSPF 사이의 논쟁은 계속되었는데, SNMP와 CIMP에서 시작되어, IPv6의 다양한 버전들에 이르기까지 이어져 온 IETF와 ISO 사이의 알력 다툼이 하나의 이유였다. OSPF 지지자들은 IETF에서 만들고, 변경할 수 있는 권리를 가진 OSPF가 인터넷 라우팅 프로토콜로 사용되는 것이 적합하다고 생각했다. 다른 한편으로 IS-IS 지지자들은 공통 IGP로의 선정이 OSI 프로토콜 수트가 인터넷에 적용될 기회라고 생각하였다.
그리고 다른 하나는 통합된 라우팅 프로토콜 그 자체에 관한 논쟁이었다. 두 개의 다른 프로토콜 집단이 있고, 두 종류의 프로토콜 집단을 지원하려 할 때 두 개의 라우팅 프로토콜 대신 하나의 통합된 라우팅 프로토콜을 가지는 편이 운용과 관리, 개발 면에서 훨씬 유리하지 않은가 하는 주장과, 충분한 수준의 유연성을 제공하기 위해서는 프로토콜이 두 종류로 분리되어야 한다는 주장이 서로 충돌하였다.

“거친 합의와 작동하는 코드”를 모토로 하는 IETF는 빠른 의사결정을 내릴 수 있도록 만들어지지 않았지만, 결국 OSPF를 공통 IGP 프로토콜로 선정한다. 하지만 그 시점에 대부분의 제조사들은 이미 OSPF를 적용하는 것을 선택한 후였다.

Network Study – 4주차 : TCP/IP

 

지난 주에는 패킷 교환망에서 패킷의 경로를 결정하는 방법인 라우팅 프로토콜에 대해 알아보았다.
그리고, 이번 주에는 TCP/IP 네트워크에서 핵심적인 역할을 하는 TCP와 IP에 대해 알아보자

1. IP(Internet Protocol)의 역사

IP는 본래, TCP/IP Protocol Suite에 속한 하나의 프로토콜이다. 이것은 IAB(Internet Architecture Board)에 의해 관리되는 IANA(Internet Assigned Number Authority), IRTF(Internet Research Task Force), IETF(Internet Engineering Task Force)에서 관리된다.
이들 중 하나인 IETF에서 TCP/IP 표준인 RFC(Request for Comments)를 배포한다. 단, 모든 RFC가 표준인 것은 아니다. IAB의 검토를 거친 RFC만이 인터넷 스텐다드로써 등재되고, 전체 네트워크에서 지켜야 할 표준으로 지정된다.
그러므로, 대부분의 RFC들은 실험적인 적용이나 단순 권고를 담고 있다.

TCP/IP에 대해 다루기 전에 먼저 TCP/IP의 역사를 알아보자.

– 1970년, ARPANET 호스트들이 TCP의 전신인 NCP(Network Control Protocol)을 사용하여 운영되기 시작한다.
– 1972년, Telnet 프로토콜이 만들어진다. Telnet은 서로 다른 시스템 터미널을 에뮬레이션 하기 위해 사용되었다. 1970년대 초, 이 시스템들은 서로 다른 종류의 메인프레임들로 이루어져 있었다.
– 1973년, FTP(File Transfer Protocol)이 사용된다. FTP는 서로 다른 시스템 사이에서 파일을 전송하기 위해 사용되었다.
– 1974년, TCP(Transmission Control Protocol)이 구체화된다. TCP는 NCP를 대체하였으며, 더 개선된 신뢰성 있는 통신을 제공하였다.
– 1981년, IP(Internet Protocol)이 구체화된다. IP는 단대단 전송에서 어드레싱과 라우팅을 제공하였다.
– 1982년, DCA(Defense Communications Agency)와 ARPA는 TCP와 IP를 합쳐 TCP/IP Protocol Suite를 만든다.
– 1983년, ARPANET이 NCP에서 TCP/IP로 이전한다.
– 1984년, DNS(Domain Name System)가 제안된다. DNS는 도메인 이름을 IP 주소로 바꾸어 주었다.
– 1995년, ISP(Internet Service Provider)들이 인터넷을 개인과 기업들에게 제공하기 시작한다.
– 1996년, HTTP(Hypertext Transfer Protocol)이 제안된다. WWW(World Wide Web)이 HTTP를 사용한다.
– 1996년, 최초의 IPv6 표준이 발표된다.

이상이 간략하게 살펴본 TCP/IP의 역사이다. 본래 TCP/IP는 TCP와 하나였으며, 네트워크 계층이 구체화되면서 TCP와 IP로 분리되게 되었다.
2017년 현재 IP에서 이슈가 되는 부분은 IPv6로의 전환과 4 to 6, 6 to 4의 터널링이며, 추후 IPv6를 다룰 때 더 자세히 알아보도록 하겠다.

2. TCP/IP Protocol Suite

IP를 다루다 보면 필연적으로 상위 계층의 프로토콜들이 따라온다. IP만으로는 인터넷을 운영하는 것이 불가능하기 때문이다.
이 중 특히 ARP와 ICMP에 대한 의존도가 특히 높다고 할 수 있으리라. 이 프로토콜들에 대해 이야기하기 전에, 먼저 TCP/IP Protocol Suite를 훑어보자.

TCP/IP Protocol Suite는 다음과 같은 구조로 이루어져 있다.

이를  OSI Layer와 비교해보면 L1~2가 Network Layer로, L3가 Internet Layer로, L4가 Transport Layer로. 그리고 L5~7이 Application Layer와 대응되는 것을 알 수 있다.
이렇듯, TCP/IP Protocol Suite는 ISO에서 제정한 OSI 7계층과는 다른 구조를 가지고 있음을 알 수 있다.
이것은 OSI Layer가 프로토콜에 대한 표준안을 제시하는 것이 아닌, 프로토콜의 발전을 위하여 각 계층에서 수행하는 일들을 체계적으로 나눠 놓은 것에 불과하기 때문이며, 실제로 프로토콜을 설계할 때는 더 세부적으로 구분된 OSI 7계층을 참조하여 개발이 이루어지고 있다.

또한, 특기할 점으로는 IP(v4)와 같은 Internet Layer에 속한 ARP와 IGMP, ICMP가 있는데, 목적지까지의 전달이라는 핵심 목표를 수행하는 것은 IP이지만, IP가 좀 더 효율적으로 동작하도록 도와주는 프로토콜들이 이들 프로토콜이 되겠다. 특히 ARP는 2계층과의 연동을 담당하는 프로토콜로써, ARP 없이 IP 단독으로는 사실상 데이터 전송이 불가능하다.

IGMP를 제외한 각 프로토콜에 대해서는 이미 별도의 문서로 다루었기에, 이 글에서는 간단하게 프로토콜의 역할 정도만 소개하고 넘어가고자 한다.

2-1. ARP(Address Resolution Protocol)

ARP는 IP 네트워크에서 IP주소를 물리적 주소(PHY Address)로 대응시키기 위해 사용하는 프로토콜이다.
L3 프로토콜 주소인 IP 주소를 이용해 최종 목적지까지 라우팅 되어 온 패킷은 하부 시스템에 전달되기 위하여 L2 프로토콜 주소(e.g. MAC Address)를 필요로 하게 된다. 이 때 사용되는 프로토콜이 바로 ARP이다.

ARP의 상세 동작과 RARP, gARP 등을 알고 싶다면, CCNA Study – ARP Protocol을 참조하자.

2-2. ICMP(Internet Control Message Protocol)

ICMP는 오류 보고와 흐름 제어 기능이 없는 IP를 보조하기 위하여 만들어진 프로토콜이다.
현대 인터넷에서는 오류 보고와 흐름 제어의 역할이 L4로 넘어갔기에 이 일은 TCP가 수행하지만, 실제로 TCP에서 흐름 제어 기능을 수행할 때, TCP는 ICMP를 이용하여 오류 제어와 흐름 제어를 수행한다.
이렇듯, ICMP는 현대 인터넷이 트래픽 폭증으로 인하여 다운되지 않고 운영될 수 있게 하는 역할의 한 축을 담당하고 있다.

ICMP의 상세 동작은 CCNA Study – ICMP를 참조하자.

2-3. IGMP(Internet Group Management Protocol)

IGMP는 IP 네트워크에서 라우터가 멀티캐스트 그룹을 판단할 때 사용하는 프로토콜이다.
IGMP의 동작을 다루기 위해선 먼저 멀티캐스트에 대해 알아볼 필요가 있다. 멀티캐스트란 Unicast/Broadcast로 구성되어 있던 IP 네트워크에서 일대 다수(One to many) 혹은 다수 대 다수(Many to many) 통신을 지원하기 위해서 개발되었다.
멀티캐스트를 지원하기 위하여 IP 대역의 일부(클래스 D/224.0.0.0 ~ 239.255.255.255)를 멀티캐스트 대역으로 할당하였으며, 특히 이 중에서 224.0.0.0/24 대역은 로컬 멀티캐스트 대역으로 지정되어 있다.

IGMP는 최초 RFC 1112를 통해 표준화되었으며, IGMPv3가 Proposed Standard로써 제안되었다.
여기서는 Internet Standard인 RFC 1112를 기반으로 IGMP의 동작을 알아본다.

IPv4 Protocol Suite은 이 정도로 해두고, IPv4의 핵심 역할인 고유 주소 할당과 경로 결정은 라우팅을 다루면서 충분히 설명하였다고 생각한다.
그렇기에 이 글에서는 이전에 미처 다루지 못하였던 IPv4 패킷의 구조 정도만을 짚고 넘어가고자 한다.

(1) Version : IPv4를 나타내기에 4의 값을 가진다.
(2) Header Length : 헤더의 크기를 워드(4Byte)단위로 나타낸다.
(3) ToS or DiffServ : 본래 IP 패킷의 응용에 따라 적절한 경로를 선택하기 위해 도입되었던 ToS 필드는 그 저조한 사용률 덕에 DiffServ 필드로 대체되었다. ‘최저 비용’, ‘처리량 최대’, ‘지연 최소’ 등의 상당히 모호하고 변동성이 심한 플래그를 담고 있던 ToS와는 달리, DiffServ는 ‘패킷의 클래스별 QoS’라는 정량화된 목표를 나타낸다. 이 클래스는 ECN 2비트를 제외하고 6비트를 사용, 최대 64개로 분류될 수 있으며, 네트워크 서비스 주체가 커스터마이징 할 수 있다.
(4) Total Length : 전체 패킷의 길이를 1바이트 단위로 나타낸다.
(5) Identifier : IP 패킷에 할당되는 고유 값. 패킷이 생성될 때 설정되며, 단편화된 패킷의 경우 같은 값을 갖는다. 이것은 루핑 때문에 발생한 패킷을 IP레벨에서 네트워크로부터 제거할 수 있다는 것을 의미한다. TCP의 Sequence Number와 유사.
(6) Flags : Fragment Flags. 첫 비트는 0, 두번째 비트는 DF(Don’t Fragment) 플래그로 1로 세트될 시 단편화 불가. 세번째 비트는 More Fragment로 단편화된 패킷이 뒤에 더 있을 경우 1로 세트된다.
(7) Fragment Offset : 해당 패킷이 단편화된 데이터그램에서 어느 부분에 해당하는지 알려주는 값이다.
(8) Time to Live(TTL) : 한 홉(Hop)을 건널 때마다 1씩 감소하여, 0이 되면 폐기된다. TTL 만료로 패킷을 폐기한 라우터는 해당 패킷의 발신지를 향하여 ICMP 11 – Time Exceeded를 전송한다.
(9) Protocol : IP 상위의 프로토콜을 알려주는 SAP.
(10) Header Checksum : 헤더 전체를 대상으로 CRC-16을 수행한다.
(11) Source Address : 출발지 IP 주소
(12) Destination Address : 목적지 IP 주소
(13) Options : IPv4에서 실험용으로 사용되었던 옵션들이 다수 존재. IANA에 등록되지 않은 옵션도 직접 정의하여 사용할 수 있으나, 실제 네트워크에서는 거의 사용되지 않는다.
(14) Padding : 패킷이 32Bit(4Byte)의 배수로 만들어지지 않을 경우, 효율적인 데이터 처리를 위하여 4바이트 배수로 맞추기 위한 필드. 더미값이 들어간다.

3. IPv6 (Internet Protocol Version 6)

지난 30여년간 IPv4가 보여주었던 여러 한계점들과 문제를 해결하기 위한 대안으로써 1998년, IPv6(RFC2460)가 제안되었다.
IPv6는 IPv4의 고갈된 주소 공간을 훨씬 큰 크기로 확장하고, 주소의 파편화로 복잡화된 라우팅 테이블을 최적화 하는 것, 프로토콜 헤더의 간략화, 추후 인터넷의 변화를 유연하게 수용할 수 있는 옵션과 확장들의 개선,  우선순위에 따른 흐름 제어와 QoS등을 목표로 하여 디자인되었다.

또한 흔히들 IPv4 대비 강화된 보안성을 추가적인 장점으로 들고 있지만, 아직 IPv6와 인접 프로토콜들은 표준화가 진행중이기 때문에 오히려 IPv4 시스템에서 발생하지 않는 보안 취약점이 추가로 발견될 수 있다는 점을 염두에 두어야 할 것이다.

IPv6에서 극명히 드러나는 IPv4와의 차이점은 바로 헤더이다. IPv6는 IPv4헤더를 간략화하고, 공통 헤더와 옵션 헤더를 나누어 전체 헤더 크기를 감소시키며 확장성을 확보하였다.

(1) IPv6 Basic Header

IPv6의 가장 기본이 되는 헤더이다. IPv4의 그것과 비교하여 확연히 간략화된 모습을 확인할 수 있다.

(1) Version : IPv6이기에 6의 값을 갖는다.
(2) Traffic Class : IPv4의 ToS와 유사한 역할. 아직 표준이 확정되지 않았기에 명확한 정의는 이루어지지 않음.
(3) Flow Label : IP 프로토콜은 비연결적인 프로토콜로 설계되었으나, IPv4의 사례에서 주로 연결 지향적 프로토콜로 사용하는 경향을 확인할 수 있었다. IPv4에 대하여 연결 지향적인 프로토콜 기능을 제공해주는 기술로 MPLS가 제안되었으며, IPv6에서는 MPLS가 담당하던 부분이 IP 프로토콜에 포함되었다. Flow Label은 같은 특성을 가지는 패킷의 ‘흐름’을 나타낼 수 있으며, 이를 통해 응용별 서비스를 제공할 수 있다. 이를테면 실시간 비디오 응용의 경우 처리에 필요한 자원을 미리 예약해둘 수 있으며, 이를 위해 RTP(Real Time Protocol)과 RSVP(Resource Preservation Protocol)이 사용된다.
(4) Payload Length : 헤더를 제외한 나머지의 크기를 바이트 단위로 나타낸다. 확장 헤더는 페이로드의 일부로 간주된다.
(5) Hop Limit : IPv4의 TTL과 동일.
(6) Next Header : IPv6 공통 헤더의 다음에 위치할 헤더의 종류를 나타내는 8bit 선택자. 상위 레벨 프로토콜이나 IPv6 Extension Header를 나타낼  수 있다.
(7) Source Address : 출발지 주소
(8) Destination Address : 목적지 주소

IPv4와 비교하면 다음과 같은 차이가 있다.

– 헤더 길이 필드의 제거 : 헤더의 길이가 고정되어 있기 때문에 제거되었다.
– 서비스 유형 필드의 제거 : ToS/DiffServ는 Flow Label로 대체되었다.
– Total Length 필드의 제거 : Payload Length 필드로 대체된다.
– 단편화 관련 필드의 제거 : 단편화 확장 헤더에서 제공된다.
– 프로토콜 필드의 제거 : Next Header 필드로 대체되었다.
– 옵션 필드의 제거 : 확장 헤더를 통하여 제공된다.
– 헤더 Checksum 제거 : 상위 계층에서 제공되기에 삭제되었다.

(2) IPv6 Extension Header

IPv6에서는 헤더 부분이 네트워크에서 차지하는 대역폭을 줄이고, 확장성을 도모하기 위하여 Extension Header(이하 확장 헤더)를 도입하였다. IPv4와는 달리 용도와 페이로드의 종류에 따라 확장 헤더를 사용할 수 있으며, 각각의 확장 헤더는 독립적이고, 동시에 중첩 가능하다.

RFC2460에서 정의된 확장 헤더는 다음과 같다.

– Hop by Hop Options
– Routing (Type 0)
– Fragment
– Destination Options
– Authentication (RFC2402)
– Encrypted Security Payload

확장 헤더는 IPv6의 표준화가 진행됨에 따라 더 늘어날 수 있으며, 임의의 확장 헤더를 정의하는 것 또한 허용된다.

(2-1) Hop-By-Hop Option Header

이 옵션 헤더는 발신자가 데이터그램이 통과하는 모든 라우터에 정보를 전달할 필요가 있을 경우 사용한다.
현재는 3가지 옵션(Pad1, PadN, Jumbo Payload)가 정의되어 있으며, 각 옵션에 대한 자세한 설명은 다음 절에서 다루겠다.

– Pad1 Option : Pad1 옵션은 어떤 옵션이 특정한 위치에서 시작될 필요가 있을 때 사용된다. 만약 지정 위치에서 1바이트가 부족하다면, 정렬(Alignment)을 위해 Pad1이 추가된다. Pad1은 1바이트의 크기를 가지며,  값은 0이다.
– PadN Option : 특정 옵션이 N Byte가 모자라다면 PadN이 사용된다. PadN의 첫번째 바이트(옵션 코드)는 1, 두번째 바이트(옵션 길이)는 패딩의 크기, 나머지 바이트들은 옵션 길이만큼의 크기를 가지며 0의 값을 갖는다.
– Jumbo Payload Option : IPv6에서는 데이터그램의 최대 크기가 65,535바이트로 증가하였다. 하지만 어떠한 이유로 이것보다 더 큰 페이로드가 요구된다면 점보 페이로드 옵션을 사용할 수 있다. 점보 페이로드 옵션은 ‘정렬 제한’을 갖는다. 즉, 옵션 헤더의 시작으로부터 (4n+2)바이트의 위치에서 시작해야 한다.

(2-2) Source Routing

IPv6의 Source Routing 옵션은 IPv4의 느슨한 라우팅 옵션과 엄격한 라우팅 옵션을 결합한 것이다.
Address Left 필드는 목적지까지 도달하기 위한 홉 수를 나타내며, Strict/Loose Mask를 통하여 느슨한/엄격한 라우팅 옵션을 선택한다.

IPv4의 그것과 마찬가지로, 엄격한 라우팅 옵션은 이 패킷이 반드시 정해진 순서의 라우터를 통과하여 전송되야 함을 의미하고, 느슨한 라우팅 옵션의 경우에는 각 라우터 사이에 다른 라우터들이 들어갈 수 있다.

(2-3) Fragment

IPv6에서는 IPv4헤더에 포함되어 있던 단편화 옵션이 별도의 확장 헤더로 분리되었다. 단, IPv6에서는 오로지 발신자만이 단편화를 수행할 수 있기에 반드시 최대 MTU 값을 찾아내는 일이 선행되어야 한다. 이것은 MTU 탐색 기법(Path MTU Discovery Technique)을 통해 이루어지며, 다음과 같은 순서로 수행된다.

IPv6에서의 MTU 탐색 기법은 RFC 1981으로 표준화 작업이 진행중이다.

1. 발신지 호스트는 큰 사이즈의 데이터그램을 전송한다
2. 라우팅 경로 상에 있는 장비가 자신의 MTU 값보다 더 큰 데이터그램을 수신하면 Packet too big 메시지를 발신지로 돌려보낸다.
3. 발신지 호스트는 Packet too big 메시지에 들어 있는 MTU 값으로 재전송을 수행한다.

이렇게 보면 참 단순한 방법이지만, 여기에는 몇가지 문제가 있다.
먼저, 1회의 Packet too big  메시지만으로 Path MTU를 결정할 수 없다. 최초로 에러를 발생시킨 라우터의 다음 홉에 있는 라우터가 가진 MTU 값이 더 작을 수도 있다.
그리고 Path MTU값이 하나의 값으로 고정되게 된다면, 토폴로지 변동에 따라서 증가할 수 있는 MTU 값을 효율적으로 사용하지 못한다.

첫번째 문제는 ICMP Error 메시지가 도착하지 않을 때까지 MTU를 감소시키는 것으로 대응할 수 있다. 하지만 두번째 문제의 경우는 좀 더 복잡하다.

RFC 1981은 호스트는 Path MTU값을 좀 더 높게 ‘추정할 수 있다’고 명시한다. 하지만 이것 또한 전송하려는 데이터의 크기가 PMTU보다 커서 MTU를 확장할 필요가 있을 경우에 한한다. 그리고 이러한 시도는 Packet too big 메시지를 수신한 뒤 5분 이내에는 이루어질 수 없다.

이것을 통해 알 수 있는 것은 현재 IPv6의 표준화에 참여하고 있는 사람들은 Path MTU를 최적화하는 것 보다, 이로 인해서 발생할 수 있는 회선의 부하를 좀 더 중시한다는 점이다.
그리고 당연하지만 Path MTU 값은 IPv6의 최소 패킷 길이보다 작을 수 없다.

또 하나 쟁점이 되는 부분은 ‘어느 레이어에서 PMTU 탐색을 진행할까?’ 라는 것이다.
PMTU 탐색을 전송 레이어에서 수행하는 것은 내부 구현적 측면에서 유리하지만, 전송 프로토콜마다 알고리즘을  새로 구현해야 하며 이것은 다른 프로토콜간의 MTU 공유를 방해한다.
이러한 이유로 IP 계층에서 PMTU Discovery를 구현하게 되었고, ‘IP 레이어에서 PMTU 정보를 저장하고, ICMP가 Packet too big 메시지를 처리하는’ 식으로 구현이 이뤄졌다.

(2-4) Destination Option

기본적으로 Hop-by-Hop Option과 동일하며, 발신자가 오직 목적지 호스트에게만 정보를 전달하고 싶을 때 사용한다. 현재까지는 Pad1과 PadN만이 정의되어 있다.

(2-5) Authentication

인증 확장 헤더는 두 가지의 목적을 갖는다. 메시지 송신자를 검증하는 것과, 데이터의 무결성을 검증하는 것이다.
Security Parameter Index에서 인증 방법을 전달하며, Authentication Data가 따라온다.

(2-6) Encrypted Security Payload

IPv6에서 제공하는 도청 방지 및 비밀 보장을 위한 확장이다. 터널 모드와 전송 모드로 구현되며, 대표적인 응용으로는 IPSec이 있다.

 

(3) IPv6의 주소 공간과 할당

IPv6가 만들어진 가장 큰 이유인 IPv4의 주소 고갈 문제, 이것을 해결하기 위하여 IPv6는 주소 공간의 크기를 128비트로 확장하였다.
IPv4 대비 4배의 길이를 가지는 이 주소값은 IPv4와는 다른 구분 방법, 분배 방법 및 읽는 방법이 필요하였다.

먼저, IPv6은 IPv4와 같은 점 10진법 표기법으로 나타낼 수 있다. 하지만 이것은 IPv4 대비 4배의 길이를 가지게 되므로, 잘 쓰이지 않는다.
두번째 방법이 흔히 사용되는 16진수 콜론 표기법으로, 10진법 표기 대비 길이를 절반으로 줄일 수 있었다.
이것만으로는 가독성이 떨어졌으므로, 이 16진수 표기를 축약하는 방법이 또 제공되는데, 하나의 콜론에서 앞에 위치하는 0들을 하나의 0으로 표현하는 방법과 0으로 이루어진 콜론의 연속을 제거하고 ::으로 표기하는 방법(Zero Compression)이 있다. 특히 제로 압축은 하나의 IPv6 주소에서 두 번 이상 사용시 정확한 해석이 불가능하기에 한번만 사용될 수 있음에 주의해야 할 것이다.

IPv6은 주소 공간의 구분을 위한 CIDR를 지원하며, IPv4와 같은 해석 방법을 갖는다.

IPv6 주소 공간은 현재 Global Unicast, Unique Local Unicast, Link-Scoped Unicast, Multicast 주소와 특수 목적용 주소가 할당되어 있으며, 7/8가량의 공간이 미래 사용을 위해 예약된 채로 남아있다.
이들 주소 중에서 특히 자주 사용되는 Global Unicast, Unique Local Unicast, Multicast의 주소 영역은 다음과 같다.

– Global Unicast : 2000::/3
– Unique Local Unicast : FC00::/7
– Multicast : FF00::/8

 

(4) ICMPv6

 

(5) RTP/RSVP

 

(6) MLD

Network Study – 2주차 : 라우팅

 

지난 주에는 Ethernet은 OSI 7계층 중 두번째인 Data-Link 계층이며, 근거리 통신을 위한 기술이라는 것을 알아보았다.
하지만 Ethernet만으로는 인터넷을 구축할 수 없다. LAN과 LAN을 통합하고, WAN들을 서로 연결하는 범 지구적인 네트워크를 구축하기 위해서는 좀 더 큰 범위의 네트워크를 다룰 수 있는 표준이 필요하다.
그리고 이것을 구현하는 스택이 바로 Layer3, Network Layer이다.

1. Network Layer와 프로토콜

OSI 모델에서 Network Layer가 맡는 역할은 다음과 같다.

– 네트워크 사이의 연결 확립
– 네트워크 호스트에 대한 고유한 주소 발급
– 메시지 전송

이제, 이 역할들에 대해 좀 더 자세히 알아보도록 하자.

1-1. 네트워크 세그먼트 사이의 연결 확립

  Layer2 프로토콜인 이더넷을 다룰 때, 우리는 이더넷이 근거리 통신을 위한 프로토콜이라는 것을 배웠다.
이더넷 단독으로는 하나의 세그먼트에서의 통신만이 가능할 뿐, 세그먼트 사이의 통신은 지원하지 않는다. 이더넷 표준에는 세그먼트를 구분하는 방법과 해당 세그먼트로의 경로를 결정하는 방법이 정의되어 있지 않기 때문이다.
컴퓨터 네트워크가 확산되면서, IP(Internet Protocol), IPX(Internet Protocol Exchange)등의 프로토콜들이 등장하였고, 이 프로토콜들은 네트워크 세그먼트를 구분하는 방법을 제공한다.

또한, 통신 경로를 결정하는 방법으로 라우팅 프로토콜(Routing Protocol)이 제안되었다.

그럼 먼저, 네트워크의 구분 방법을 살펴보도록 하자.
IP가 만들어졌을 때에는 클래스(Class)를 통해 네트워크 세그먼트를 구분하였다.

예를 들자면,

– Class A: 0.0.0.0 ~ 127.255.255.255 / 128개의 네트워크, 네트워크당 16,777,216개의 호스트
– Class B: 128.0.0.0 ~ 191.255.255.255 / 16,384개의 네트워크, 네트워크당 65,536개의 호스트
– Class C: 192.0.0.0 ~ 223.255.255.255 / 2,097,152개의 네트워크, 네트워크당 256개의 호스트
– Class D(멀티캐스트): 224.0.0.0 ~ 239.255.255.255
– Class E(예약된 주소): 240.0.0.0 ~ 255.255.255.255

로 구분을 하였다. 각 클래스들은 IP 주소의 제일 앞 4비트를 통해 구분되며, 클래스가 내려갈수록 네트워크 비트가 8비트씩 증가하도록 약속되었다.

이것을 그림으로 나타내면 다음과 같다.

네트워크 비트에서 빨간색으로 표현된 부분이 바로 클래스를 구분하는 식별자이다.
Class A는 0(2), Class B는 10(2), Class C는 110(2), Class D는 1110(2), Class E는 1111(2)이 된다.

네트워크 비트가 달라지면, 해당 주소들은 ‘다른 네트워크’로 취급되며, 상호간의 통신을 위해서는 라우팅을 거쳐야 한다.
만약 이렇게 네트워크를 구분하지 않는다면, 컴퓨터 시스템은 어떤 호스트가 자신과와 같은 네트워크에 속해 있고, 추가적인 경로 설정 없이도 통신이 가능한지 알 수 없게 될 것이다.

이렇게 클래스를 통하여 세그먼트를 구분하는 네트워크를 클래스풀 네트워크(Classful Network)라 하며, 인터넷의 초창기에 이용되었다.
그리고 이러한 클래스풀 네트워크 사이의 통신 경로를 결정하기 위한 프로토콜로써 Classful Routing Protocol을 사용하게 된다.

하지만, 클래스풀 네트워크는 곧 문제에 봉착하게 되는데, 이 문제는 조금 뒤에 다루도록 하겠다.

1-2. Classful 라우팅 프로토콜(RIP)

  RIP(Routing Information Protocol)은 거리 벡터 알고리즘(Distance-Vector Algorithm)을 사용하는 라우팅 프로토콜로써, BSD 4.2에 라우팅 데몬으로 포함되면서 유명해졌다.
RIPv1은 Classful Routing을 수행하며, 일정 시간(30초)마다 모든 라우팅 정보를 교환하는 것(255.255.255.255/ 로컬 브로드캐스트 주소 사용), 그리고 전달 거리가 최대 15홉으로 제한되는 등의 이유로 현재는 거의 사용되지 않는다.
RIPv2는 VLSM(Variable Length Subnet Mask)를 지원하며 Classless Routing을 수행한다는 차이점이 있다. 현재의 최신 버젼은 IPv6를 지원하는 RIPIng이며, RIP의 버젼 별 상세는 조금 뒤에 다루겠다.

RIPv1은 Ethernet 상위의 프로토콜에 대한 경로 결정을 위하여 Xerox에서 개발한 프로토콜로, RFC 1058을 통해 표준화가 완료되었다.
RIP의 동작 방식은 다음과 같다. RIP가 활성화된 인터페이스는 30초마다 Broadcast Address(255.255.255.255)로 Request Message를 내보내고, Request를 수신한 다른 라우터가 Response Message를 내보낸다. 이 때, Response Message에는 라우팅 테이블 정보가 들어간다.

30초 마다 토폴로지를 공유하며, 링크 다운 등의 장애가 발생하였을 때 추가적으로 메시지를 내보내는 기능이 존재하지 않기 때문에, RIP는 매우 느린 수렴 시간을 갖는다. 이 때문에 잘못된 토폴로지 정보가 네트워크를 계속해서 순환하며 링크를 마비시킬 가능성이 있다. 이를 해결하기 위해 홉 카운트(Hop Count)를 두고, 15에서 라우터를 하나 거칠때마다 1씩 감소시키며, 0이 된 메시지는 폐기한다.
때문에 RIP는 최대 16개의 라우터만을 통과할 수 있다는 제약을 가지며, 규모가 큰 네트워크에서는 사용할 수 없다.

또한, 거리 벡터 알고리즘에 가중치가 존재하지 않기에, RIP는 홉 수가 작은 경로만을 최선의 경로라고 판단한다. 이에 따라 대역폭이 더 넓고, 지연시간이 더 짧지만, 홉 수가 더 큰 링크가 이용되지 않을 가능성이 있다.

이러한 문제점 때문에, RIP가 간편한 설정, 직관적인 전달 경로라는 장점을 가지고 있음에도 실제 네트워크에서는 사용되지 않는다. 대부분의 AS들은 IGP(Interior Gateway Protocol)로 OSPF를 사용한다.

1997년에 RIPv1을 개선한 RIPv2가 제안되었다. RIPv2는 RFC 2453으로 표준화되었으며, VLSM, MD5 인증 지원, 메시지 전송을 위해 멀티캐스트 주소(224.0.0.9) 사용 등의 기능이 추가되었다.

1-3. 라우팅 프로토콜

  앞 문단에서는 Classful 라우팅 프로토콜인 RIP를 다루었다. 그런데 라우팅 프로토콜이란 무엇이며, 어떤 역할을 하는 것일까? 더 깊이 들어가기 전에 이것을 먼저 알아보도록 하자.

인터넷이 확산되기 전에는 Static Routing이 주류를 이루고 있었다. 네트워크 자체가 크지 않았을 뿐더러, 변동 또한 적었기 때문이었다. 하지만 인터넷의 크기가 점점 커지면서, 경로 수정을 위해 사람이 일일히 개입해야 하는 Static Routing 대신 Dynamic Routing이 주류를 이루게 되었다. 그리고 이 Dynamic Routing을 수행하는 프로토콜이 바로 라우팅 프로토콜이다.

라우팅 프로토콜은 크게 두 종류가 존재한다. AS(Autonomous System)내부의 라우팅을 위한 IGP(Interior Gateway Protocol)과, AS간의 라우팅을 위한 EGP(Exterior Gateway Protocol)가 바로 그것이다.
우리가 흔히 접하는 RIP, EIGRP, OSPF, IS-IS등의 프로토콜은 모두 IGP이며, 현재 인터넷에서 사용되는 EGP는 BGP가 유일하다.

간단히 말하자면, 우리가 흔히 생각하는 회사의 내부 네트워크에 사용되는 프로토콜이 IGP이며, 이 내부 시스템이 Gateway를 통해서 인터넷에 노출되면, 인터넷 상에서의 라우팅을 위해 사용되는 프로토콜이 EGP이다.
그렇기 때문에, BGP는 대규모 인터넷 사업자나 ISP에서 사용하게 되며, BGP의 잘못된 설정은 인터넷 전체에 영향을 미칠 가능성이 있다. 이 때문에 시스코에서는 소규모 AS의 경우 BGP 대신 Static Routing을 적용할 것을 권장한다.

1-4. Classful Routing과 Classless Routing, 그리고 Subnet Mask

  라우팅에 대해 이야기하다 보니 IP의 일부를 다룰 필요가 생겼다. 앞서, 라우팅 프로토콜은 네트워크 세그먼트간의 통신 경로를 결정하기 위해 사용되는 프로토콜이라고 했다. 그리고 Classful Network에 대해 이야기하였다.
물론, Classful Network에도 서브넷 마스크는 있었다. 하지만, 이는 컴퓨터에서 빠르게 IP 주소의 계층을 확인하기 위해 만들어진 것이었지(AND 연산), 다른 추가적인 기능을 가진 것은 아니었다. 그래서 RIPv1은 Subnet Mask를 주고받지 않는다. IP의 범위만 봐도 이미 다 정해져 있기 때문이다!

하지만 Classful Network에는 아주 치명적인 문제가 있었으니, IP 주소의 비효율적인 할당이 바로 그것이다. 인터넷의 초창기에는 클래스 단위의 할당이 그리 문제되지 않았다. 하지만 곧 이것은 큰 문제가 되었는데, 예를 들어 A 클래스의 IP 대역을 할당받은 기업은 16,777,216개의 고유 주소를 갖게 된다. 하지만 대체 어떤 기업이나 조직이 이만한 수의 호스트를 갖는다는 말인가? 클래스 단위의 IP 주소 할당은 곧 IP 주소를 완전히 고갈시켜버릴 것으로 예측되었고, 이 문제를 해결하기 위해 CIDR(Classless Inter-Domain Routing)이 제안된다.

그리고, CIDR의 근간을 이루는 부분이 바로 VLSM(Variable Length Subnet Mask)이다. Classful Network에서는 서브넷 마스크의 길이가 고정되어 있었다. 하지만, CIDR을 도입하게 되면 서브넷 마스크를 가변적으로 설정할 수 있게 된다!
이를테면, 10.0.0.0/8 네트워크를 256개의 10.0.0.0/16 네트워크로 쪼갤 수 있는 것이다. 이로써 훨씬 효율적인 IP 주소의 할당이 가능해졌고, 이렇게 호스트/네트워크 비트를 알려주기 위한 수단으로 서브넷 마스크가 사용되게 되었다.

이제, 서브넷 마스크의 계산 방법을 한번 살펴보자.

CIDR을 이용하여 네트워크의 범위를 결정하는 방법은 아주 단순하다. IP 주소와, 해당 주소의 서브넷 마스크를 서로 AND 연산하기만 하면, 해당 주소의 네트워크 ID가 나온다. 그리고 네트워크 ID가 같은 주소는 같은 네트워크에 속한 것이다.
사실, 앞서 적었었던 192.168.0.0/24, 10.0.0.0/8과 같은 표기법은 CIDR에서 서브넷 마스크를 쉽게 표기하기 위해 만들어진 방법으로, CIDR Notation이라 한다.

이것을 좀 더 보기 쉽게 그림으로 나타내면 다음과 같다.

 이렇듯, CIDR을 사용하게 되면 네트워크 세그먼트를 식별하기 위한 Network ID라는 특별한 주소가 하나 필요하다. 이 IP 주소는 해당 네트워크를 대표하는 주소로써, 호스트에 할당되는 IP 주소는 Network ID 다음 주소부터가 된다.
또한, 한 가지 더 재미있는 부분은 CIDR에서는 직접 브로드캐스트 주소 또한 달라진다는 점이다. 이는 로컬 브로드캐스트 주소의 정의가 호스트 비트를 전부 1로 채우는 것임을 생각해보면 자명하다.

그리고 CIDR는 라우팅을 수행하는 것에 있어 부가적인 이점을 제공하는데, 여러개의 작은 네트워크로 가는 경로를 하나의 네트워크 경로로 축약할 수 있다는 점이다. 이를 Routing Prefix Summarization이라 한다.
이러한 축약은 대형 백본 라우터가 가지고 있는 라우팅 테이블의 크기를 줄여주지만, 이와 동시에 Longest Prefix Match라는 문제도 함께 불러온다.
현대의 라우터는 Longest Prefix Match를 wire-speed로 수행하기 위하여 TCAM을 사용하지만, 이것은 동시에 TCAM에 입력된 서브넷 마스크가 미리 정렬되어 있어야 한다는 것을 의미한다.

TCAM에 쓰기 작업을 하는 것은 (상대적으로) 긴 시간을 소비하기에, 라우팅 테이블을 갱신하는 횟수를 최대한 줄이기 위한 많은 알고리즘들이 있으며, 지금도 개발되고 있다.

1-5. Longest Prefix Match

  CIDR을 사용하는 네트워크 라우터에서 경로 판단을 위해 사용하는 알고리즘인 Longest Prefix Match에 대하여 자세히 알아 보자.

Longest Prefix Match란, 어떤 호스트로 가는 경로를 결정할 때, 가장 긴 Prefix를 가진 네트워크로 패킷을 전송한다는 것을 의미한다.
앞서 말했듯이, CIDR를 사용하는 라우터는 경로가 같은 작은 서브넷 여러 개를 묶어서 하나의 네트워크로 축약(Summarization)한다.

하지만, 궁극적으로 패킷이 전달되어야 할 네트워크는 하나이며, IP 주소를 할당받는 구성에 따라 자신과 목표 서브넷이 직접 연결되고, 축약된 나머지 네트워크들은 다음 라우터로 포워딩해야 할 수 있다.

예를 들어, 이런 구조의 네트워크가 있다고 하자.

이렇게 네트워크가 구성될 경우, R1은 172.16.0.0/24로 축약된 라우팅 경로를 R2에게 전달하고, R2의 라우팅 테이블에는 172.16.0.0/24는 R1에 연결되어 있다고 기록된다.
한편, R2의 라우팅 테이블에는 172.16.128.0./26이 자신과 직접 연결되어 있다는 정보도 함께 존재한다.

이런 상황에서 R2로부터 172.16.128.1로 가는 IP 패킷은 어디로 전달되어야 하는가?
Longest Prefix Match를 적용하면 172.16.128.1은 172.16.0.0/24보다 172.16.128.0/26에서 더 길게 매칭되므로, 패킷은 172.16.128.0/26으로 전달된다.

2. 라우팅 프로토콜 상세

2-1. 디스턴스 벡터(Distance-Vector) 라우팅 프로토콜

  디스턴스 벡터란, 라우팅 경로를 결정하는 것에 있어 목적지 네트워크까지의 메트릭(Metric)을 사용하는 것을 말한다. 메트릭이란 최적 경로 선택 기준을 말하며, 메트릭을 산정하는 방법은 프로토콜마다 다르다.
디스턴스 벡터를 사용하는 대표적인 프로토콜로는 RIP, EIGRP, BGP가 있다.
이 프로토콜들은 자신이 알고 있는 네트워크로의 메트릭 값을 인접 라우터에게 광고(Advertisement)한다. 디스턴스 벡터 프로토콜들은 전체 네트워크의 상태를 알지 못하며, 그저 목적지 네트워크로의 메트릭 값만을 안다.

또한, 디스턴스 벡터 프로토콜은 스플릿 호라이즌을 가진다. 스플릿 호라이즌이란, ‘라우팅 정보를 수신한 인터페이스로는 다시 그 정보를 광고하지 않는다’는 규칙으로, 디스턴스 벡터 프로토콜에서 발생할 수 있는 라우팅 루프를 방지하는 역할을 한다.
라우팅 루프란, 잘못 광고된 메시지 때문에 전달 경로가 계속 변경되는 것을 말하며, 다음과 같은 경우를 생각할 수 있다.
1. R1이 R2에게 자신이 10.1.0.0/24 네트워크와 연결되어 있다고 광고한다.
2. R2는 R1과 R3에게 이 정보를 전파한다.
3. R1과 R3는 R2가 10.1.0.0/24와 연결되어 있다고 생각한다.

이러한 상황을 막기 위하여 라우터들은 자신이 메시지를 수신한 인터페이스로 광고하지 않지만, 특정한 경우에는 이러한 스플릿 호라이즌 룰을 깰 필요가 있다. 이 부분은 추후 다시 살펴보도록 하자.

또한, 디스턴스 벡터 프로토콜 중 EIGRP와 BGP는 네트워크의 자동 축약을 지원한다. 즉, 앞서 Routing Prefix Summarization에서 설명했던 것처럼 작은 서브네트워크들을 주 네트워크 경계에서 자동으로 축약해서 전달하는 기능을 가지고 있다.

2-2. 링크 상태(Link-State) 라우팅 프로토콜

  링크 상태 라우팅 프로토콜은 목적지까지의 경로를 결정하는 것에 있어, 전체 네트워크 토폴로지를 가지고 계산을 수행한다. 각 라우터들이 자신과 접속된 네트워크와 인접 라우터 정보를 네트워크 전체에 공유함으로써 모든 라우터가 전체 네트워크 토폴로지를 알 수 있다. 따라서, 단순히 메트릭에 따라 경로를 결정하는 디스턴스 벡터 라우팅 프로토콜에 비해 더 정확한 경로를 알 수 있지만, 네트워크에 속한 라우터가 늘어남에 따른 메시지의 증가와 장애 발생시 수렴까지 걸리는 시간이 상대적으로 길다는 약점을 가지고 있다.
대표적인 링크 상태 프로토콜로는 OSPF와 IS-IS가 있다.

2-3. 라우팅 네트워크의 종류

  라우터가 연결된 L2 네트워크의 종류에 따라 라우팅 정보를 전달하는 방법이 달라지거나 제약될 수 있다.
이를테면, 브로드캐스트가 지원되지 않는 경우가 있을 것이다. 이런 유형의 네트워크를 NBMA(Non-Broadcast Multi Access)네트워크라 하며, 대표적으로 Frame Relay, ATM 네트워크가 있다. Frame Relay와 ATM은 가상 회로(Virtual Circuit)을 통하여 다중 접속을 구현하는데, 해당 장비와 연결된 물리적 인터페이스가 하나이더라도 내부적으로는 가상의 인터페이스를 만들어서 전송한다. 이 경우, 논리적으로는 이전의 회선 교환망과 같이 출발지와 목적지가 하나의 회선으로 연결된 것 처럼 보이게 된다는 장점이 있다.
때문에, NBMA 네트워크에서 브로드캐스팅으로 라우팅 정보를 전달해야 한다면, 라우터는 패킷을 복제해서 각 가상 회선별로 하나씩 보낼 것이다. 그렇기에 라우팅 정보를 광고해야 할 장비가 많다면 그 자체로 회선 대역폭을  소비할 수 있으니 주의가 필요하다.

다음으로 포인트 투 포인트(Point-to-Point) 네트워크가 있다. 하나의 인터페이스에 연결되는 상대 장비가 하나인 네트워크를 말하며, HDLC, PPP 등의 프로토콜이 있다. 포인트 투 포인트 네트워크에서는 접속된 상대방이 하나이기 때문에 어떠한 방법으로 라우팅 광고를 보내도 상관이 없다. 실제로 라우팅 프로토콜들은 이러한 경우 멀티캐스트나 브로드캐스트 주소로 라우팅 메시지를 광고하는 경우가 많다.

2-4. RIP(Routing Information Protocol) 상세 동작

  RIP가 동작하는 방식은 Classful Network를 다룰 때 이미 설명하였다.
여기서는 기본적인 동작 외에, 추가적으로 다룰 동작들을 설명하도록 하겠다.

RIPv2에서 VLSM지원이 추가되면서 축약 기능이 추가되었다. 물론, RIPv1은 이러한 기능을 지원하지 않으며, RIPv1과 v2를 혼용하는 환경에서는 둘 다 동일한 서브넷 마스크를 사용하거나 auto-summarization 기능을 꺼야 한다.
Cisco 라우터에서 자동 축약은 auto-summary가 활성화되어 있을 때 작동하며, 주 네트워크 경계(Major Network Boundary)를 기준으로 축약이 일어난다. 주 네트워크 경계란, Classful 네트워크에서의 네트워크 경계를 말한다.
그리고, RIPv2는 수동 축약을 지원하는데, 다른 주 네트워크 경계에 포함된 경로는 축약할 수 없다. 즉, 1.1.0.0/24와 1.1.0.8/24를 1.1.0.0/21로 축약할 수 있지만, 1.0.0.0/8과 2.0.0.0/8을 1.0.0.0/7로 축약할 수는 없다.

2-5. EIGRP(Enhanced Interior Gateway Routing Protocol)

  EIGRP는 Cisco에서 개발한 프로토콜로, OSPF와 더불어 현업에서 가장 많이 사용되는 프로토콜이다.
OSPF 대비 EIGRP가 가지는 장점으로는 Enequal Cost 부하 분산(메트릭 값의 차이에 따른 불균등한 부하 분산 적용)을 지원한다는 것과, 상대적으로 설정이 단순하다는 것이 있으나, Cisco 라우터에서만 사용 가능한 비표준 프로토콜이라는 치명적인 단점과, 대규모 네트워크에서의 SIA(Stuck In Active)문제가 있다.

EIGRP는 다음과 같은 순서로 라우팅 경로를 결정한다.

1. 네이버(Neighbor)구성, 네이버 테이블 생성
2. 라우팅 정보 교환, 토폴로지 테이블 생성
3. 라우팅 경로 계산과 라우팅 테이블 저장

이를 위해 EIGRP는 헬로, 업데이트, 라우팅 정보요청, 응답 및 수신확인 패킷을 사용한다.

1. 헬로(Hello) 패킷
헬로 패킷은 EIGRP가 네이버 정보를 구성하고 유지하기 위하여 사용된다. 또한, 헬로 패킷은 멀티캐스트 주소인 224.0.0.10으로 전송된다.
헬로 패킷의 구조는 다음과 같다.

먼저 EIGRP 패킷의 구조를 설명하겠다.
EIGRP 패킷은 헤더와 TLV(Type-Length-Value)로 구성된다. 먼저, 헤더의 구조는 다음과 같다

(1) Version : EIGRP 프로토콜의 버젼을 나타내며, 현재는 2이다.
(2) Opcode : EIGRP 패킷의 종류를 나타내며, Hello는 0x05이다.
(3) Checksum : EIGRP 패킷 전체의 체크섬 값이다.
(4) Flags : 1로 설정 시, 네이버 관계를 맺을 때 인접 라우터의 엔트리가 포함되어 있음을 알린다.
(5)/(6) Sequence / Acknowledge Number : RTP(Reliable Transport Protocol) 사용 시, 신뢰성있는 EIGRP 통신을 위해 사용된다.

헤더의 뒤에 TLV 쌍이 온다. Type과 Length는 각각 16비트의 값을 가지며, Length는 전체 TLV의 길이를 바이트 단위로 나타낸다.
따라서, 만약 Value의 길이를 알고 싶다면 Length의 값에 -4를 취하면 된다.
TLV는 EIGRP 패킷의 종류에 따라 유동적이며, 지금은 Hello 패킷을 기준으로 설명하도록 하겠다.

(1)~(5) K1~5 : EIGRP 메트릭 상수인 K1~5의 값이다.
(6) Reserved : 현재 사용되지 않는 값이다.
(7) Hold Time : EIGRP 라우터는 인접 라우터에게서 일정 시간동안 헬로 패킷을 받지 못하면 문제가 발생한 것으로 보고 네이버 관계를 해제하는데, 이 때의 시간값이다.

Hello 패킷에서 중요한 부분은 EIGRP Parameter의 Hold Time과, 헤더의 Autonomous System Number이다.
EIGRP는 Hello를 수행하면서 AS 정보와 홀드 주기를 알게 된다.

2. Update 패킷
EIGRP Update는 라우팅 정보를 전송할 때 사용된다. 네트워크의 종류에 따라 224.0.0.10 / 유니캐스트로 전송된다.
Update 패킷의 구조는 다음과 같다. (헤더 생략)

IPv4의 IP Internal Route TLV이다.
Update 패킷은 일련의 Internal Route TLV들을 포함하고 있으며, 필드의 정보는 다음과 같다.

(1) Next Hop : Destination 네트워크로 가는 다음 홉 라우터의 정보를 말한다
(2) Delay : 목적지 네트워크까지의 지연 시간의 합을 나타낸다. EIGRP에서는 라우터를 거칠 때마다 Delay가 증가한다.
(3) Bandwidth : 해당 네트워크까지의 최소 인터페이스 대역폭을 나타낸다
(4) MTU : 해당 네트워크까지의 MTU값이다. 자신의 MTU값이 더 작다면 이 필드를 재기록해서 다른 라우터들에게 광고한다.
(5) Hop Count : 해당 네트워크까지의 홉 수를 나타낸다. EIGRP의 기본 최대 홉 수는 100이며, 최대 255까지 설정할 수 있다.
(6) Reliability : 해당 링크의 신뢰성을 말한다. 메트릭 값을 결정할 때 사용되며, 현재는 잘 이용하지 않는다.
(7) Load : 해당 링크의 부하를 말한다. 마찬가지로 잘 이용되지 않는다.
(8) Prefix Length : CIDR Rrefix 길이를 나타낸다.
(9) Destination : 목적지 주소값이다.

IPv4의 IP External Route TLV이다.

Internal Route TLV에서 추가된 부분만 언급하자면,

(1) Originating Router : 해당 네트워크의 정보를 EIGRP AS에 재분배한 라우터의 Router ID 혹은 IP Address를 말한다.
(2) Originating AS Number : Originating Router의 AS 번호를 말한다.
(3) Arbitrary Tag : 라우트 맵(Route-Map)에 의해 지정된 태그 정보를 가진다.
(4) External Protocol Metric : 해당 프로토콜의 메트릭 값을 말한다.
(5) External Protocol ID : 재분배된 프로토콜의 구분자이다. 0x01은 IGRP, 0x02는 EIGRP, 0x03은 정적 루트, 0x04는 RIP, 0x05는 Hello 프로토콜, 0x06은 OSPF, 0x07은 IS-IS, 0x09는 BGP, 0x0A는 IDRP, 0x0B는 직접 연결된 링크이다.
(6) Flags : 0x01인 경우 해당 경로가 재분배된 경로임을 뜻한다. 0x02인 경우, 이 재분배된 경로가 디폴트 루트임을 뜻한다.

이렇듯, EIGRP는 Hello와 Update값에 포함된 정보로 해당 네트워크의 메트릭 값을 결정하게 된다.
EIGRP에서 메트릭 값을 결정하는 식은 다음과 같은데,


일반적으로 K1, K3를 1로 설정하고 나머지를 0으로 두기 때문에, 실질적으로는 Bandwidth값과 Delay 값으로 메트릭을 결정하게 된다.
Reliability와 Load를 사용하지 않는 것은, 이 두 가지 패러매터가 빈번하게 변동되기 때문에 라우팅 경로가 계속 변동하면서 네트워크 전체가 불안정해 질 수 있기 때문이다.
그렇기에 자주 사용되지 않으며, 특수한 경우 metric weights 명령어를 사용하여 설정할 수 있다.
metric weights 명령어는 6개의 인자를 받으며, 첫번째 수는 TOS 값으로 항상 0, 나머지는 K1~5 상수값이다.

또한, EIGRP에 속한 모든 라우터들의 K 상수값이 일치하지 않으면 Neighbor 관계가 성립하지 않으므로 주의가 필요하다.

Query와 Reply 패킷 또한 동일한 Internal/External Routes TLV를 사용하며, 자세한 내용은 추후 다루겠다.

2.5.1. DUAL 알고리즘

  라우팅 정보 교환을 마쳤다면, 이제 토폴로지 테이블을 작성해야 한다. 이 때 사용되는 것이 바로 DUAL(Diffusing Update ALgorithm)이다.
토폴로지 테이블이란, DUAL에서 사용하는 인접 라우터에서 수신한 네트워크와 메트릭 값을 저장해 둔 데이터베이스를 말한다.
토폴로지 테이블에는 다음과 같은 값들이 저장된다.

1. RD(Reported Distance) : Next-hop 라우터에서 목적지 네트워크까지의 메트릭 값
2. FD(Feasible Distance) : 현재 라우터에서 목적지 네트워크까지의 최적 메트릭값
3. Successor : 최적 경로상에서의 Next-hop 라우터
4. Feasible Successor : Successor가 아닌 라우터 중에서 RD < FD를 만족하는 넥스트 홉 라우터

이제 이 라우터가 네이버로부터 Update 패킷을 수신하면 다음과 같이 DUAL 알고리즘이 동작한다.

1. 기존의 경로보다 더 좋은 메트릭을 가진 경로를 수신하였을 때 : 석세서를 그 경로를 전송한 라우터로 변경하고, 네이버에게 Update 전송
2. 기존보다 나쁜 경로를 석세서가 아닌 네이버로부터 수신하였을 때 : 해당 정보를 무시한다.
3. 기존보다 나쁜 경로를 석세서로부터 수신하였을 때 : 피저블 석세서를 선택하고 네이버에게 Update 전송.
3-1. 피저블 석세서가 존재하지 않을 때
해당 라우터는 네이버에게  쿼리(Query) 패킷을 전송한다. 이것을 확산(Diffusing)이라고 하며, 이를 통하여 전체 네트워크가 최적 경로를 다시 결정한다.
쿼리 패킷은 네트워크를 타고 전파되는데, 라우터가 해당 네트워크의 정보를 가지고 있지 않거나, 네이버가 없거나, 피저블 석세서가 존재하거나, 액티브(Active) 상태이면 그 라우터에서 쿼리 전송이 종료된다.
쿼리 패킷을 보내고 응답(Reply)을 받지 못한 상태를 액티브(Active), 쿼리 패킷을 전송하지 않은 상태를 패시브(Passive)라 한다.
쿼리를 전송한 라우터들은 자신이 쿼리를 전송한 네이버들의 리스트를 유지하면서, 해당 라우터들에게서 응답 패킷을 전부 수신한 뒤에야 패시브 상태로의 천이와 경로 계산이 가능해진다.
그리고 기본적으로 3분 이내에 응답을 수신하지 못하면 네이버 관계를 해제한다.

이로써 모든 네트워크 노드가 새로운 최적 경로를 갖게 되지만, 장애 유형에 따라 최적 경로가 계속 변동되고 링크가 절단되는 SIA(Stuck In Active) 문제가 발생할 수 있다.

2.5.2. EIGRP 네트워크 축약

  EIGRP 또한 RIP와 같이 주 경계 네트워크에서 자동 축약을 지원한다. 하지만 최근 버젼의 IOS에서는 EIGRP 자동 축약이 기본적으로 비활성화되어 있다.
자동 축약을 활성화, 비활성화 하려면 다음과 같은 명령어를 사용한다.

EIGRP는 자동 축약과 별개로 수동 축약을 지원한다. 이 때, 수동 축약 설정은 축약된 네트워크를 전송하고자 하는 인터페이스에서 설정한다.

EIGRP로 네트워크를 축약하여 광고할 경우, 라우터는 축약된 모든 네트워크가 다운되어야 축약된 네트워크의 광고를 중단한다.
이 때문에 디폴트 루트에 따른 라우팅 루프가 발생할 수 있는데, 이 문제를 미연에 방지하기 위하여 네트워크를 축약한 라우터의 라우팅 테이블에는 축약된 네트워크의 기본 게이트웨이가 null 0(블랙홀) 인터페이스로 잡히게 된다.
정상적으로 라우팅이 이루어질 때에는 Longest Prefix Match 룰에 의해 세부 경로로 라우팅이 이루어지지만, 만약 일부 네트워크가 다운된다면 네트워크를 축약한 라우터는 다른 라우터에서 들어오는 다운된 네트워크로 가는 패킷들을 블랙홀 인터페이스로 보내 폐기한다.

또한, EIGRP에서 축약된 네트워크의 메트릭 값은 세부 네트워크들의 메트릭 중 가장 낮은 값을 가진다.

2.5.3. EIGRP 네임드 모드

EIGRP를 AS번호와 같이 사용하는 것이 아닌, 이름을 이용해서 사용한다면, EIGRP는 네임드 모드로 작동한다. 네임드 모드에서는 EIGRP 와이드 메트릭 사용과 하나의 설정 모드에서 거의 모든 EIGRP 설정을 할 수 있다는 장점이 있다.
EIGRP 네임드 모드로 진입하려면 다음과 같은 명령어를 사용한다.
router eigrp testEIGRP

그리고 EIGRP 네임드 모드 사용시, 프로토콜 설정 모드와 인터페이스 설정 모드에서 설정해야 했던 항목들을 eigrp 설정 모드에서 조작할 수 있게 된다.

address-family의 인자로는 ipv4/ipv6를, 그 뒤에는 바로 AS를 지정하거나 unicast, VRF이름을 지정할 수 있다.
unicast 옵션 다음에는 다시 AS 번호나 VRF이름을 지정할 수 있다.

AS 설정 모드로 진입한 후에는 해당 AS의 네트워크 설정을 할 수 있다.

EIGRP 네임드 모드에서 사용할 수 있는 명령어는 다음과 같다.

– af-interface : EIGRP 인증, EIGRP 대역폭, BFD, 헬로 주기, 홀드 타임, passive-interface 기능, 스플릿 호라이즌, 네트워크 축약 설정
– eigrp : EIGRP 경로 태깅, EIGRP 네이버 로그 설정, EIGRP Router ID 확인, Stub 에어리어 설정
– maximum-prefix : EIGRP 네이버에게서 수신할 수 있는 최대 네트워크 수를 초과하였을 때의 동작
– metric : EIGRP 메트릭 패러메터와 RIB-Scale 설정
– neighbor : EIGRP 네이버 주소와 네이버에게서 수신할 수 있는 최대 네트워크 수 설정
– topology : 축약, 재분배, distance 설정, offset-list, 부하 분산 설정

2.5.4. EIGRP 와이드 메트릭

기존 EIGRP 메트릭이 10Gbps 이상의 인터페이스 대역폭을 제대로 계산하지 못하는 것과, 1Gbps 이상의 인터페이스 딜레이를 제대로 반영하지 못하는 문제를 해결하기 위하여 64bit 값을 사용하는 EIGRP 와이드 메트릭을 도입하였다.
와이드 메트릭의 복합 메트릭 계산 방법은 다음과 같다.

일반적으로 K1, K3 = 1이므로 복합 메트릭 값은 Throughput + Latency이다.
이 때 Throughput 값은 65536 * 107 / 가장 느린 인터페이스의 대역폭이다. 결과적으로 와이드 메트릭의 대역폭은 기존 EIGRP 메트릭의 값에 65536을 곱한 값이 된다.
또한, 인터페이스 딜레이 값의 단위가 밀리세컨드(ms)에서 피코세컨드(ps)로 조정되었으며 1Gbps 이상의 인터페이스 딜레이 값은 1013 / 인터페이스 대역폭으로 정의되었다.

그리고, 64비트 값을 가지는 와이드 메트릭 값은 RIB에 탑재되기 전에 32비트에 맞도록 크기를 조절해야 하는데, 이 때 이용되는 것이 rib-scale 명령어이다.
기본값은 128로 설정되어 있으며, 와이드 메트릭 값 / rib-scale 값이 RIB에 탑재되게 된다.

2-6. 라우팅 경로의 재분배

  복수의 라우팅 프로토콜이 운영되는 환경에서, 다른 방법으로 알게 된 정보를 라우팅 프로세스에 포함시키는 것이 ‘라우팅 경로 재분배’이다.
이 때, ‘다른 방법’은 직접 연결된 경로, 정적 경로, 다른 프로토콜의 경로 정보를 말한다. 직접 연결된 경로를 재분배하는 것이 상당히 의아할 수 있는데, network 명령어 대신 재분배를 이용하여 네트워크를 연산 과정에 포함하면 해당 인터페이스와 네이버 관계를 맺지 않기 때문에 네트워크의 보안을 강화할 수 있다. 이러한 특성으로 종단 단말과 연결된 스위치를 라우터와 연결할 때 주로 사용하는 방법이다.
또한, 루프백 인터페이스를 호스트 루트가 아닌 것으로 광고하기 위하여 사용되기도 한다.

경로 재분배를 사용할 때 주의해야 할 점으로는 한 라우터 내에서 하나의 프로토콜이 재분배받은 경로는 다른 프로토콜에게 다시 재분배 해 줄 수 없다는 것과 라우팅 프로토콜 간의 AD 값, 메트릭, 컨버전스 시간, 서브넷 정보 전송 여부 등이 다르기 때문에 네트워크를 불안정하게 만들거나 비최적 경로 라우팅이 일어날 수 있다는 점이다. 이것은 초기 메트릭(Seed Metric)값 조정, AD 조정 등의 방법으로 극복될 수 있다.

2-7. OSPF(Open Shortest Path First Protocol)

OSPF는 RFC2328을 통해 표준화된 Internet Standard 프로토콜이다. 시스코 독점이었던 EIGRP와 달리, OSPF는 인터넷에 연결되는 장비라면 반드시 지원해야 하는 프로토콜이며, 이 때문에 가장 널리 사용되는 IGP가 되었다.
OSPFv2는 기본적으로 IPv4를 지원하며, IPv6 확장인 OSPF for IPv6(RFC5340)이2008년 제안되었다.
OSPF의 특징으로는 링크 상태 프로토콜이라는 것과 에어리어 단위로 동작하는 프로토콜이라는 점이 있다.
OSPF에 대해 이야기 하기 전에, OSPF에서 사용하는 용어를 먼저 정리하고 들어가도록 하자.

– LSA(Link State Advertisement) : OSPF에서 라우팅 정보를 전달하기 위하여 사용하는 패킷
– Area : OSPF에서 경로 연산을 수행하는 단위 영역
– Area 0(Backbone Area) : OSPF Area들이 반드시 직접 연결되어야 하는 Area.
– Router ID : OSPF에서 라우터를 식별하는 고유 값. 기본값은 라우터의 루프백 인터페이스 IP이며, 루프백 인터페이스가 없을 경우 인터페이스에 할당된 IP중 가장 작은 값이다. 문제를 피하기 위해 대부분 수동으로 설정한다.
– Adjancent Neighbor : LSA를 주고받는 네이버, DR/BDR

2.7.1. OSPF 패킷

OSPF에서 Neighbor관계를 맺고 정보를 교환하는 과정을 다루기 위해서 먼저 OSPF 패킷 구조를 알아보도록 하자.

(1) OSPF 공통 헤더

(1) Version : OSPF 프로토콜의 버젼을 의미한다. 현재 OSPF 프로토콜의 버젼은 2이다.
(2) Type : OSPF 메시지 타입을 알린다. 0x01은 Hello, 0x02는 Database Description Packet, 0x03은 Link State Request Packet, 0x04는 Link State Update, 0x05는 Link State Acknowledgement 이다.
(3) Packet Length : OSPF 공통 헤더를 포함한 전체 메시지의 길이를 나타낸다.
(4) Router ID : 해당 메시지를 전송한 라우터의 OSPF ID를 말한다.
(5) Area ID : 이 메시지가 속한 OSPF Area ID를 말한다.
(6) Checksum : Authentication Data 필드를 제외한 나머지 패킷 전체에 대한 CRC-16 체크섬 값이다. 인증 데이터 필드를 제외하는 이유는 체크섬 또한 인증 프로세스의 일부로 간주되기 때문이다. 그리고 인증 방식으로 MD5를 사용할 경우 체크섬 필드는 사용되지 않고, 0으로 설정된다.
(7) Authentication Type : OSPF 인증 방식을 나타낸다. 0은 인증 없음, 1은 Plain Text 패스워드 인증, 2는 패스워드의 MD5 해쉬이다.
(8) Authentication Data : 인증 방식에 따라 다른 값을 갖는다. Plain-Text 인증의 경우, 64bit 길이의 패스워드가 오며, 이 때문에 최대 패스워드 길이는 8자로 제한된다. (검증 필요)
MD5 인증의 경우 Auth Crypt Key ID, Auth Crypt Data Length, Auth Crypt Sequence Number, Auth Crypt Data가 차례로 온다. MD5 해쉬의 길이가 128Bit이기에 Auth Crypt Data Length는 16(바이트), Auth Crypt Data는 128Bit의 값이 온다.

(2) OSPF Hello

(1) Network Mask : 해당 인터페이스에 할당된 서브넷 마스크를 나타낸다.
(2) Hello Interval : Hello 패킷을 보내는 주기를 초로 나타낸다. Neighbor을 맺기 위해서는 이 값이 동일해야 한다.
(3) Options : OSPF Option 필드이다. 왼쪽부터 DN, O, DC, L, N, MC, E, MT 플래그 값을 나타낸다.

(3-1) DN : MPLS Based L3 VPN(RFC2547)에서 OSPF를 사용할 경우 세트된다. 이 환경에서 발생할 수 있는 라우팅 루프를 방지하기 위하여, DN 플래그가 1인 Type 3,5,7 LSA를 받으면, 이 LSA는 OSPF 경로 계산에 사용되지 않는다.
(3-2) O : 라우터가 Type 9, 10, 11 Opaque LSA를 지원할 경우 세트된다.
(3-3) DC : 라우터가 OSPF over Demand Circuit을 지원할 경우 세트된다.
(3-4) L : OSPF 패킷이 Link-Logical Signalling(LLS) 데이터 블록을 가질 경우 세트된다. LLS는 Cisco사에서 제안한 OSPF 확장 프로토콜로, RFC5613에 정의되어 있다.
(3-5) N : Hello 패킷에서만 사용된다. 라우터가 Type 7 NSSA-External-LSA를 지원할 경우 세트된다. N비트가 세트된 라우터들 끼리 네이버를 맺는 것이 가능하며, E비트는 반드시 0으로 세트되어야 한다.
(3-6) P : NSSA-External-LSA 헤더에서 세트된다. 때문에, P와 N은 옵션 필드에서 같은 역할을 공유한다. P 플래그는 NSSA ARB가 Type-7 LSA를 Type-5 LSA로 변환할 수 있음을 알린다.
(3-7) MC : 라우터가 OSPF Multicast Extension(MOSPF)를 지원할 경우 세트된다.
(3-8) E : 라우터가 AS External LSA를 받아들일 수 있을 경우 세트된다. 따라서 모든 AS External LSA와 백본 에어리어, non-stub 에어리어에서 만들어진 메시지는 E플래그가 세트되어 있어야 한다. E플래그가 일치하지 않는 라우터 사이에서는 네이버 관계를 맺을 수 없다. (검증 필요)
(3-9) MT : 라우터가 Multitopology OSPF(MT-OSPF)를 지원할 경우 세트된다.

(4) Router Priority : OSPF에서의 우선순위를 나타낸다. 이 값이 클수록 우선적으로 Designated Router/Backup Designated Router에 선출된다. 기본값은 1이며, 0일 경우 Designated Router에 선출되지 않는다.
(5) Router Dead Interval : 라우터가 죽은 것으로 판단하기까지의 시간 값을 초로 나타낸다. Hello 패킷 수신시마다 리셋되며, 서로 일치하지 않을 경우 네이버 관계를 형성할 수 없다.
(6) Designated Router : Designated Router의 Router ID값을 나타낸다. 선출되지 않았을 경우 0.0.0.0이다.
(7) Backup Designated Router : Backup Designated Router의 Router ID 값이다. 상동.
(8) Active Neighbor : Active 상태인 Neighbor가 존재할 경우 해당 라우터의 Router ID 값을 나타낸다.

(3) OSPF LSA

OSPF에서 정보를 주고받기 위하여 사용되는 구조체인 LSA를 다룬다. 먼저, OSPFv2(RFC2328)에서 5종류의 LSA가 정의되었다. 그리고 몇 개의 확장이 더해져 현재는 11종류의 LSA가 존재한다.
LSA는 Hello를 제외한 다른 모든 OSPF 패킷에서 사용되며, DD와 LSA Request, LSA Ack는 LSA 헤더만을 사용한다.

0. OSPF LSA Header

OSPF LSA의 공통 부분인 헤더이다. LSA의 종류, 중복 방지 매커니즘 등을 담고 있다. 각 요소의 기능은 다음과 같다.

(1) LS Age : LSA가 생성되고 나서 지난 시간을 초 단위로 나타낸다. LSA Max Age 매커니즘과 LSA Refresh에 사용된다. Max Age의 길이는 1시간이며, LSA Refresh는 30분 단위로 일어난다.
(2) Options : OSPF Options 필드와 동일
(3) LSA Type을 지정. 현재 총 11종류의 LSA가 존재한다.

3-1. Router LSA
LSA Type은 0x01, 모든 라우터에서 생성되는, 자신의 인터페이스 상태를 나타내는 LSA이다. Area를 넘어갈 수 없다.
Router LSA는 인터페이스의 IP 주소를 가지고 있으며, Router LSA를 수신한 ‘모든’ 라우터들은 수신한 인터페이스를 제외한 다른 모든 (OSPF가 활성화된) 인터페이스로 LSA를 플러딩해야 한다.

3-2. Network LSA
LSA Type은 0x02, Broadcast/Non-Broadcast Multi Access 네트워크에서 DR에 의해 생성되는 LSA이다. DR과 연결된 라우터들의 Router ID를 갖는다.
Area 내부의 네트워크에 대한 정보를 가지고 있다.
Broadcast Netrowk에 속한 OSPF 라우터들은 Network LSA의 네트워크  정보와 Router LSA의 인터페이스 주소 정보를 기반으로 전달 경로를 찾는다.

3-3. ABR Summary LSA (Type 3)
LSA Type은 0x03, Area Border Router(ABR)에 의해 생성된다. Area 외부의 네트워크에 대한 정보를 Area 내부로 전파한다.

3-4. ASBR Summary  LSA (Type 4)
LSA Type은 0x04, ABR에 의해 생성되며, AS Boundary Router(ASBR)로 가는 경로와 Cost를 알린다.

3-5. AS-External-LSA
LSA Type은 0x05, ASBR에 의해 생성되며, OSPF 도메인 외부의 네트워크로 가는 경로를 OSPF 도메인 내부로 전파한다. 즉, 재분배된 경로를 전파한다.

3-6. Group Membership LSA
LSA Type은 0x06, MOSPF(Multicast Extensions to OSPF)에서 제안된 LSA로, RFC1584가 표준화 과정에서 폐기되었기에 사용하지 않는다.

3-7. NSSA External LSA
LSA Type은 0x07, OSPF NSSA Option(RFC1587, 현 RFC3101)에서 제안된 LSA로, NSSA(Not-so-stubby-Area)에 속한 라우터가 재분배받은 정보를 전파할 때 사용한다.
앞서 말했듯이, Type 7과 Type 5를 동시에 처리할 수는 없으므로, ABR중 하나가 Type7 to 5 Translator 기능을 수행하여 Non-stub Area로 외부 경로를 전파하게 된다.
RFC1587에 따르면 Type 5 LSA가 Type 7 LSA보다 우선적으로 LSDB에 탑재된다.

3-8. External-attribute-LSA / Link-Local Only LSA for OSPFv3
LSA Type은 0x08, BGP 정보를 AS내부에서 전달할 때 iBGP 대신 OSPF를 사용할 경우를 위해 만들어졌다. LSA Type 8 내부에 LSA Type 5를 여러 개 탑재하여 BGP Attribute 정보를 전달한다는 발상이었으나, 표준화가 중단되었기에 지금은 사용되지 않는다.
OSPFv3에서는 Link-Local Address와 해당 링크의 IPv6 주소 정보를 전달한다.

Type 9~11은 Opaque LSA로써, OSPF Opaque LSA Option을 다룰 때 같이 설명하겠다.

(4) Link State ID : LSA의 종류에 따라 다른 값을 갖는다.

4-1. Router LSA : LSA를 생성한 라우터의 Router ID 값
4-2. Network LSA : DR의 IP 인터페이스 주소 값
4-3. Summary LSA : 목적지 네트워크의 IP 주소
4-4. Summary LSA : LSA에 서술된 ASBR의 Router ID 값
4-5. AS-External-LSA : 목적지 네트워크의 IP 주소

여기서 알 수 있듯이, Router LSA의 경우 Link State ID와 Advertising Router 필드의 값은 동일하다.

(5) Advertising Router : LSA를 생성한 라우터의 Router ID 값
(6) LS Sequence Number : LSA를 식별할 수 있는 식별자. 낡거나, 중복된 LSA를 식별하기 위해 사용된다.
(7) LS Checksum : LS Age 필드를 제외한 LSA의 CRC-16 체크섬
(8)Length : LSA의 길이. 20Byte의 LSA Header를 포함한다.

(4) OSPF DD(Database Description) 패킷

OSPF Database Description 패킷은 Hello 종료 후 Adjacency가 시작될 때 교환된다. DD 패킷은 LSDB에 대한 간략한 정보(LSA Header들)을 가지고 있으며, Master-Slave를 선출하여 Ack을 수행한다.

DD 패킷의 구조는 다음과 같다. (OSPF 헤더 생략)

(1) Interface MTU : DD를 전송하는 인터페이스의 최대 MTU값을 나타낸다. Virtual link에서는 0으로 세트된다.
(2) Options : Hello의 Options과 동일.
(3) Flags : DD 패킷에서 사용되는 플래그로, 첫 5비트는 0, 나머지 3비트가 플래그로 사용된다.

(3-1) I-Bit : Init Bit. 첫 DD 패킷인 경우 1로 세트된다.
(3-2) M-Bit : More Bit. DD 패킷이 뒤에 더 온다는 것을 알린다.
(3-3) MS-Bit : Master/Slave Bit. 라우터가 Master일 경우 1로 세트된다. Router ID가 높은 쪽이 Master가 된다.

(4) DD Sequence Number : DD Sequence에서 패킷을 구분하기 위해 사용된다. 순차적으로 증가하며, Master만이 Sequence Number를 증가시킬 수 있다. Master가 DD를 보내면, Slave가 그 응답으로써 같은 Sequence Number를 가진 DD를 보낸다. 그리고 Master는 Sequence Number를 1 증가시킨다. Database를 완전히 전달할 때 까지 이것을 반복한다. (Q: Master는 아직 줄 게 남았는데, Slave는 줄 게 없을 경우? / Slave는 줄 게 남았는데, Master는 줄 게 없을 경우?)
(5) LSA Header : LSDB를 구성하는 LSA들의 헤더 정보이다. 이를 통해 라우터는 자신이 가지고 있는 LSA와 가지고 있지 않은 LSA를 구분한다.

(5) Link State Update 패킷

(6) Link State Acknowledgement 패킷

2.7.2. OSPF Stub Area / OSPF Not-so-stubby Area

OSPF에서는 외부 네트워크 경로의 전파를 차단하여 LSDB의 크기와 라우팅 테이블의 변동을 줄일 수 있는 Stub Area라는 기능을 지원한다.
Stub Area에서는 ABR을 통해 AS 외부로 가는 경로가 모두 디폴트 루트로 광고되며, Stub Area 내부 라우터들의 라우팅 테이블과 SPF 연산량을 줄여준다. 하지만 백본 라우터의 라우팅 테이블 크기를 줄여주지는 못한다는 한계점을 가지고 있다.
Type 4, 5 LSA가 지원되지 않으며, (Optional) 다른 Area의 정보를 담은 Type-3 LSA가 내부로 전달될 수 있다. Cisco 독점 사양으로 Type-3 LSA도 차단하는 Totally Stubby Area가 있다. 이 경우에는 OSPF 도메인 내의 경로라도 디폴트 루트를 통한 라우팅이 이루어지게 된다.
Stub Area와 NSSA의 차이점은 Area 내부에 ASBR이 존재할 수 있는지의 여부인데, Stub Area의 내부에는 ASBR이 존재할 수 없지만, NSSA의 내부에는 ASBR이 존재할 수 있다. (Type 5 LSA Support)
그런데, NSSA는 ASBR Summary LSA (Type 4)를 지원하지 않는다. 즉, 외부 경로를 OSPF 도메인 내부로 전파하지 않는다. 대신, NSSA의 ASBR은 Type-7 LSA를 통하여 외부 네트워크로 가는 디폴트 루트를 AS 내부에 광고하며, 이것이 NSSA 외부로 전파될 때는 ABR에서 Type 5 to Type 7 Translation을 수행하여 경로를 전파하게 된다.

2.7.3. Link-Logical-Signalling Extension

RFC5613에서 제안된 OSPF 확장 프로토콜로, 새로운 기능을 추가할 때 마다 새로운 LSA를 정의하는 것 대신, LSA를 좀 더 유연하게 확장하기 위하여 만들어졌다.
EIGRP와 마찬가지로 TLV 데이터 블록을 사용하여 확장성을 추가하는 것을 골지로 하며, 하위 호환성을 중시한다. 이를 위하여 OSPF Length Field의 값은 LLS Data Block을 포함하지 않으며, LLS Data Block의 길이는 IP Packet Length로부터 도출된다.
LLS Data Block은 OSPF Hello, DD(Database Description) 패킷에 더해질 수 있으며, 다른 패킷에 포함되어서는 안된다. Hello 패킷에 동적으로 LLS Data를 추가할 수 있지만, 전달이 보장되지 않는다. 하지만 DD에 포함된 LLS Data는 Adjacency 과정의 일부로 간주됨으로써, 전달이 보장된다.

LLS 데이터 블록의 구조는 다음과 같다.

이 때, TLV 값은 다음과 같은 값들이 올 수 있다.

(1) Extended Options and Flags

(2) Ctyptographic Authentication TLV (OSPFv2 Only)

(3) Private TLVs
LLS 타입 값 중 32768-65536는 사설 사용을 위해 예약되었다. 1-32767까지는 IANA에서 관리하지만, 나머지 LLS 타입 값은 임의의 추가적인 확장을 위해 사용될 수 있다.
단, Value 필드의 첫 4바이트는 Private Enterprise Code 값으로, 한 네트워크에 다수 벤더의 장비들이 존재할 경우 발생할 수 있는 충돌을 예방한다.

2.7.4. OSPF Opaque LSA Option

RFC5250에서 제안된 LSA 확장 프로토콜이다. LLS와 마찬가지로 미래의 OSPF 확장에 대비하기 위하여 만들어졌으며, LSA를 통해 직간접적으로 데이터를 전파할 경우 사용할 수 있다고 되어 있다.
Link-Local Opaque LSA, Area-Local Opaque LSA, Domain-Wide Opaque LSA로 이루어져 있으며, 각각 네트워크 내부, 에어리어 내부, AS 외부로 정보를 전파하기 위하여 사용된다.

Opaque LSA의 패킷 구조는 다음과 같다.

2.7.5. OSPF DR/BDR 선출 방법

기본적으로 OSPF는 모든 Neighbor들이 서로 LSA를 교환하지 않는다. Point-to-Point와 Point to Multi-Access 네트워크에서는 DR, BDR을 선출하지 않고 Neighbor간 LSA를  교환하지만, Broadcast/NBMA(Non-Broadcast Multi Access)네트워크에서는 DR과 BDR을 선출하여, DR이 Network LSA를 생성, Adjancent Neighbor에게 토폴로지 정보를 전파한다. 이를 통해 불필요한 LSA 트래픽을 줄일 수 있다.

이제, OSPF에서 DR과 BDR을 선출하는 방법을 알아보자.

1. OSPF가 활성화된 인터페이스로 Hello를 내보낸 뒤 상대방의 Hello를 기다린다.
2. Neighbor 관계를 형성하고, DR/BDR이 선출되지 않은 상태인 것을 확인한 뒤 아직 Hello를 보내지 않은 라우터를 OSPF Dead Interval 동안 기다린다.
3. 모든 라우터들이 온라인이라고 판단, Election Process를 시작한다.
4. 먼저, 자신의 Neighbor과 자신을 포함한 목록에서 Priority가 가장 높은 라우터를 BDR로 선출한다. 만약 Priority가 같다면 Router ID가 높은 쪽이 BDR이 된다.
5. BDR이 된 라우터가 네트워크에 Active DR이 없다는 것을 확인, 본인을 DR로 선출하고, 그 다음 순위의 라우터를 BDR로 선출한다.
5-1. 만약 BDR이 될 라우터가 없다면 새로운 라우터의 접속을 기다린다. 새로운 라우터가 접속되면, BDR이 없는 것을 확인하고 본인을 BDR로 선출한다.
6. 한번 DR과 BDR이 선출된 후로는 DR과 BDR은 다운되지 않는 이상 변동하지 않는다. 이것은 토폴로지 변경이 일어날 때마다 DR/BDR 선출이 이루어지는 것을 방지하기 위함이다.

DR이 다운되면 BDR이 DR을 대체하고 BDR Election을 시작한다. BDR이 다운되면 DR을 제외한 라우터들이 BDR Election을 시작한다.

2.7.6. LSDB 생성, Link-State 알고리즘에 따른 최적 경로 선택 방법

OSPF는 다음과 같은 순서로 LSDB(Link-State Database)를 생성하고, 최단 경로 계산을 수행한다.

2.7.6-1. OSPF 상태 천이

OSPF Neighbor 관계 형성부터, LSDB를 생성하기까지 몇 가지 단계를 거친다.

1. Init
라우터가 자신의 이웃으로부터 Hello 패킷을 받았지만, 이 패킷에 자신의 Router ID가 포함되어 있지 않을 경우 천이한다. Neighbor 관계를 수립하기 위하여 Hello 패킷을 보낸 이웃의 Router ID를 포함한 Hello 패킷을 보낸다.

2. 2-Way
서로 Hello를 주고 받아 쌍방향 통신이 수립된 상태를 말한다. 네이버 관계가 수립되고, Adjacency를 수립할 지의 여부를 결정한다. Broadcast/NBMA 네트워크에서는 DR과 BDR만이 Full State로 천이되는 것을 허용하며, 다른 라우터들은 Adjacency를 수립하지 않기에 2-Way에 머몰러 있게 된다. 거꾸로 말하자면 Point to Point Network와 Point to Multipoint Network의 경우에는 Exchange-Loading이 종료된 후 Full State로 천이하게 된다.

3. Exstart
DR과 BDR이 선출되고, Adjacency를 수립한다. DD 패킷을 교환하기 위하여 Master/Slave와 DD Sequence Number를 결정한다.

4. Exchange
DD 패킷을 교환하고, 자신에게 있는 정보가 더 오래되었거나, 자신이 가지고 있지 않은 정보를 Link State Request List에 기록해 둔다. Exchange가 종료되고 Link State Request List에 요청할 정보가 없으면 바로 Full State로 천이한다.

5. Loading
실질적인 링크 정보를 교환한다. Link State Request List를 참조, Request/Update 패킷으로 자신의 LSDB를 업데이트 한다. 모든 Update 패킷은 Acknowledgement 패킷을 통한 응답 확인이 이루어져야 한다.

6. Full
모든 라우터들이 같은 상태 정보를 공유하고 있다. 이 단계에서 일정 시간(OSPF SPF Throttling) 대기한 후 SPF 연산을 수행한다.OSPF Throttling은 뒤에서 자세히 다루도록 하겠다.

이러한 OSPF Status는 Neighbor 관계를 맺은 라우터마다 독립적으로 이루어지는 일이다. 모든 네이버가 Full Status일 필요도 없고, 네이버마다 다른 상태로 천이될 수도 있음을 알아두어야 하겠다.

LSDB의 최신화가 완료되고, OSPF는 목적지까지의 최단 경로 계산을 수행한다. 그리고 이 때 사용되는 알고리즘이 바로 다익스트라(Dijkstra) 알고리즘이다.
다익스트라 알고리즘에 대한 설명은 이 문서의 범위를 벗어나므로, 링크의 문서로 대체하겠다.
LSDB의 라우터-네트워크-인터페이스 정보와 코스트 정보를 이용해서 목적지로의 최적 경로를 계산하게 된다.

(Q: OSPF Update를 통한 네트워크 다운 전파. 구체적으로 어떤 과정을 거치는가? Packet Capture 필요)

SPF 재연산은 토폴로지 변동시마다 이루어지는 것이 원칙이나, 잦은 토폴로지 변동이 발생할 때 매번 재연산을 수행하는 것은 부하가 많이 걸리는 일이다. 그렇기에 Throttling Timer를 두어 토폴로지 변동을 누적한 뒤 재연산을 수행하도록 한다.
이것의 구현은 벤더별로 조금씩 차이가 나는데, Cisco와 Juniper를 기준으로 살펴보도록 하자.

1. OSPF Throttling – Cisco의 경우
Cisco의 SPF Interval은 Exponential하게 증가한다. spf-interval 명령어를 통해 Max Interval, Init Wait, Increase 값을 설정한다.
각각 SPF 재연산 사이의 최대 간격, 첫 번째 트리거와 재연산 사이의 간격, 첫 번째 재연산과 두 번째 재연산 사이의 증가 시간을 의미한다.
그리고 SPF 재연산 사이의 간격은 트리거 될 때마다 2배씩 증가한다. 물론 Max Interval이 경과하는 경우에도 재연산을 수행한다.

2. OSPF Throttling – Juniper의 경우
Juniper는 spf-delay 명령어를 통해 SPF 간격을 설정한다. 단, 첫 3번의 SPF에 한해서 적용된다.
만약 3번의 SPF 재연산 이후에도 다시 토폴로지 변동이 발생하면, Juniper 장비는 5초간 대기한 뒤 SPF 재연산을 수행한다.
이 방법을 통해 대부분의 링크 장애는 빠르게 Convergence 하고, 적은 수의 노드 장애는 LSA들을 한번에 모아서 재연산을 수행할 수 있다.

이러한 OSPF Throttling Interval이 서로 불일치할 경우에는 라우터마다 SPF 재연산을 수행하는 시간이 달라, 라우팅 루프가 발생할 수 있다는 것에 주의해야 한다.

2.7.7. OSPF Passive Interface 동작

2.7.8. ECMP(Equal-Cost Multi Path) 동작

2.7.9. OSPF for IPv6(OSPFv3) 상세

2.7.10. OSPF Virtual Link

VXLAN(Virtual eXtensible Local Area Network) – 1

최근 데이터센터에서 멀티 테넌트 환경을 지원하기 위해 각광받고 있는 VXLAN을 RFC를 바탕으로 이해해 보자.

RFC7348에서는 VXLAN을 ‘가상화된 L2 네트워크를 오버레이로 L3네트워크 상에서 구현하는 프레임워크’라 정의하고 있다. 그리고 RFC7348은 Informational 카테고리에 등록되어 있다.

 

1. 개요

IDC에서 서버 가상화가 확산되고, 하나의 서버가 많은 VM들을 가지게 되면서 Ethernet Switch가 가지는 MAC Address Table도 급격히 커지게 되었다. 또한 Extended VLAN의 최대 갯수가 4096개인 것에 비해 멀티 테넌트 환경에서 수천개, 혹은 그 이상의 VLAN을 요구하게 됨에 따라, 잠재적으로 중복된 VLAN ID가 발생할 가능성이 생겼다. 그리고 가상화된 L2 네트워크를 전체 데이터센터에 적용하게 되면, 기존에 사용되던 STP 같은 루프 방지 알고리즘은 많은 비활성화 된 링크를 만들어낸다. 이런 상황을 피하기 위해서 Equal-Cost Multipath(ECMP)를 도입한다 하더라도, VM간 통신에는 여전히 기존의 L2 모델을 남겨둘 수 밖에 없다.

이러한 문제점들을 해결하기 위하여 오버레이 네트워크가 제안되었다. 오버레이 네트워크란, 각각의 VM들이 만들어내는 MAC 트래픽을 논리적인 ‘터널’을 통해 캡슐화하여 전달하는 것을 의미한다. 그리고 VXLAN은 오버레이 네트워크를 실현하기 위한 프레임워크이다.

 

2. 가상화 환경에서의 제약 사항

2-1. STP(Spanning Tree Protocol)과 VLAN 범위의 제약

현재, L2 네트워크는 루프 회피를 위하여 IEEE 802.1D STP를 사용하고 있다. STP는 중복되는 링크를 블록하는 것으로 루프 방지를 구현한다. 때문에 데이터센터는 실제로 사용할 수 있는 것보다 더 많은 물리적 링크를 가져야 하고, 다중 경로를 통해 얻을 수 있는 복원성도 사라진다. 이를 해결하기 위한 최근의 시도로 TRILL(RFC6325)과 SPB(802.7ag)가 있지만, 멀티패스틑 구현할 수 있도록 도와주거나, STP의 문제들 중 일부를 덮어둘(surmount) 뿐이다. STP의 제약은 서버와 랙을 하나의 Layer 3 네트워크로 구성하는 것으로 해결될 수 있다. 하지만 이것 또한 VM 사이의 통신을 위한 L2 모델과 호환되지 않는다.

L2 데이터 센터의 특징은 Broadcast isolation을 위해 VLAN을 사용한다는 점이다. 12bit의 VLAN ID는 최대 4096개의 VLAN을 제공할 수 있으며, 기존의 데이터센터들에서는 4096개보다 더 적은 VLAN을 사용했기에 문제가 없었다. 하지만 서버 가상화의 도입으로 고객들에게 독립된 환경(Tenant)를 제공하는 것이 중요해졌고, 한 서버에 수많은 VM들이 올라감에 따라 VLAN ID는 급속도로 고갈되었다.

 

2-2. 멀티 테넌트 환경

클라우드 컴퓨팅은 om-demand한 동적 프로비저닝을 요구한다. 대부분의 클라우드 컴퓨팅은 Private Cloud이며, 서비스 제공자는 하나의 물리적 인프라 위에서 각 고객들에게 독립된 환경을 제공해주어야 한다. 테넌트를 이용한 네트워크 트래픽 분리는 L2, L3네트워크에서 적용될 수 있다. L2 네트워크에서는 이것을 위해 VLAN이 자주 사용된다. 클라우드 서비스 제공자는 많은 수의 테넌트를 제공해야 하며, 각 테넌트당 하나의 VLAN ID가 할당되어야 하는 환경에서 4096개의 VLAN ID 제한은 적합하지 않다. 게다가 하나의 테넌트가 여러개의 VLAN을 요구할 수도 있는데(Ex. 부서간 네트워크 분리) 이는 상황을 더욱 악화시킨다. 관련된 다른 문제로 cross-pod 확장이 있다. pod이란 연관된 네트워크와 스토리지로 구성된 하나 또는 그 이상의 랙을 말한다. 테넌트는 그것이 더 많은 서버와 VM을 필요로 할 때 다른 Pod으로 확장될 수 있어야 한다. 특히, 인접 Pod의 자원 활용율이 낮다면 더욱 그렇다. 이러한 환경에서는 “확장된” L2 환경이 필요하다.

L3 네트워크 또한 멀티테넌시 환경에 대한 포괄적인 해결책은 아니다. 두 테넌트가 자신들의 네트워크에서 동일한 L3 주소를 사용할 수 있으려면, 클라우드 서비스 제공자가 고립된 네트워크 환경을 제공해 주어야 한다.

 

2-3. ToR Switch의 부적절한 테이블 크기

지금의 가상화된 환경에서는 ToR(Top of Rack)스위치의 MAC Address Table의 크기가 증가되어야 한다. 서버의 링크당 하나의 MAC Address를 학습해야 했던 이전과는 달리, 스위치는 이제 VM에 붙은 링크 수만큼의 MAC Address를 학습해야 한다. 데이터센터는 여러대의 랙으로 이루어져 있고, 다른 랙에 있는 VM과 통신하기 위하여 MAC을 학습해야 한다. 때문에 가상화되지 않은 환경에 비해 큰 테이블 크기를 요구한다.

스위치는 테이블이 다 찼을 시, 학습을 중단하고 학습되지 않은 패킷들을 모든 포트로 플러딩한다.

 

3. VXLAN

VXLAN은 L3 네트워크 위에 가상의 L2 네트워크를 오버레이하는 기술이다. 오버레이된 네트워크들을 VXLAN segment라고 하며 각각의 segment에 포함된 VM끼리만 통신이 가능하다. 각 VXLAN segment는 24비트의 식별자(VXLAN Network Identifier)를 가지며, 최대 1600만개 이상의 VXLAN 세그먼트가 만들어질 수 있다. VXLAN Netrowk Identifier(이하 VNI)는 내부의 캡슐화된 이더넷 프레임이 어떤 VM으로부터 나왔는지 특정하며, 때문에 세그먼트들 사이의 MAC을 오버래핑 하더라도, 트래픽이 세그먼트들을 ‘통과하는’일은 일어나지 않는다. 이러한 캡슐화 때문에 VXLAN은 L3 네트워크에서 L2 네트워크를 구성하는 터널링 기술로 불리기도 한다. 이 터널이 stateless 하기 때문에 각각의 프레임들은 일정한 규칙에 따라 캡슐화될 필요가 있다.

이 터널의 종단(VXLAN Tunnel End Point, 혹은 VTEP)은 VM을 서비스하고 있는 서버나 하이퍼바이저에 위치한다. 여기서, 물리적인 네트워크 장비나 서버 또한 사용될 수 있음을 기억하자.

그럼 이제 VXLAN이 터널을 어떻게 구성하는지 알아보자.

 

1. VXLAN이 적용된 VM은 VXLAN을 인지하지 못한다. 이 VM은 다른 VM과 통신하기 위하여 일반적인 MAC 프레임을 전송한다.

2. 물리 호스트 위의 VTEP는 프레임을 수신하고, 해당 VM이 속한 VNI를 찾는다. 그리고 목적지 MAC이 같은 세그먼트에 속하는 VM이라면, 원격 VTEP의 MAC을 매핑한다. 이 시점에서의 패킷 구조는 IP-MAC 헤더-원본 L2 프레임이다.

3. L3 네트워크를 타고 전송된 프레임이 원격 VTEP에 도착한다. 원격 VTEP는 VNI를 검증하고 목적지 VM이 해당 VNI에 속해있는지 확인한 뒤, 프레임의 캡슐화를 풀고, VM에 전달한다.

 

RFC7348은 VTEP의 구현과 프레임을 최종적으로 전달할 때의 구현에 대해선 정의하고 있지 않다. 따라서 이러한 부분에서 벤더간 호환성 문제가 발생할 수 있을 것으로 보인다.

CCNA Study – ICMP

 

1. Introduction

ICMP(Internet Control Message Protocol)은 TCP/IP Suite에서 IP에 문제가 생겼을 때, IP 자신은 오류를 보고하고, 연결을 제어할 수 있는 기능이 없기 때문에, 이를 보조하기 위하여 만들어진 프로토콜이다.

ICMP는 RFC 792에서 처음으로 정의되었으며, 관련된 다른 RFC로는 RFC 1122, RFC 1812가 있다. 현재는 IPv6에 대응하는 ICMPv6가 나왔기 때문에 이전의 ICMP는 ICMPv4로 불리게 되었다.

ICMP는 IP 의 상위에서 캡슐화(Encapsulation)되어 동작하기 때문에 기본적으로 IP에 대해 의존적이지만, 실질적으로 IP가 잘 동작하려면 ICMP의 보조가 반드시 필요하기에 이 둘은 상호 보완적인 관계라고 볼 수 있다.

 

2. ICMP 패킷의 구조

ICMP 패킷은 다음과 같은 구조를 가진다.

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 1. Type (1 Byte): ICMP 메시지의 타입을 지정하는 필드로, 자세한 내용은 나중에 다루겠다.

2. Code (1 Byte): ICMP 메시지 타입에 따른 하위 타입을 지정하는 필드로, 이것 또한 뒤에 다루겠다.

3. Checksum (2 Byte): ICMP 헤더의 무결성을 검증하기 위해 사용된다.

4. Data (N Byte): ICMP 메시지의 실제 데이터로, 길이는 타입과 코드에 따라 달라진다.

2-1. ICMP Type

ICMP 메시지의 타입(Type)에는 다음과 같은 것들이 있다.

All Rights Reserved IANA
All Rights Reserved IANA[1]
 

이 중에서 Deprecated된 타입을 제외한 Type 0, 3, 4, 5, 8, 9, 10, 11, 12에 대해 알아보자.

 

Type 0: Echo Reply 메시지를 나타낸다. Echo Reply는 Echo에 대한 응답으로, Identifier와 Sequence Number를 포함한다. RFC 792에 따르면 Identifier는 세션 구별을 위한 포트 넘버와 같은 것들이 들어가고, Sequence Number는 TCP의 그것과 동일하다.

 

Type 3: 목적지 도달 불가 메시지를 나타낸다. 이 메시지는 1바이트의 코드(Code) 값을 갖는데 이는 다음과 같다.

Typ3-Code

이 중에서 Code 0은 목적지 네트워크에 도달할 수 없음을 알리고(주로 라우팅 테이블 불일치), Code 1은 목적지 네트워크에는 도달했으나, 목적지 호스트에는 도달할 수 없었음을 말한다.

그리고 Code 4는 주로 링크 상의 최대 MTU를 찾는 용도로 사용된다.

 

Type 4: 발신지 억제 메시지를 나타낸다. IP는 데이터 전송 속도를 제어하는 흐름 제어 기능을 갖지 않고 있기 때문에(Best Effort) 라우터가 자신이 처리 가능한 용량을 넘어서는 패킷을 받는 경우(e.g Ingress Buffer Overflow) 나머지 패킷들을 폐기시켜야 하고, 패킷을 폐기할 때 그 패킷을 송신한 호스트에게 Source Quench 메시지를 전송한다.

그러나 폐기되는 모든 패킷에 대해 전송되는 메시지의 특성 상 이 메시지를 수신하더라도 호스트는 자신이 혼잡을 유발하고 있다고 단정지을 수 없다.

 

Type 5: 재지정 메시지를 나타낸다. 목적지로 데이터를 전송하는 경로 상에 있는 라우터가 해당 목적지로 가는 더 나은 경로가 있음을 알리기 위해 사용된다.

Type 5에는 2가지의 코드(Code)가 있는데, 이는 다음과 같다.

Typ5-code

Code 0: 네트워크 재지정. 해당 목적지 네트워크로 가는 모든 패킷의 경로를 재지정할 것을 권고한다.

Code 1: 호스트 재지정. 해당 목적지 호스트로 가는 패킷의 경로를 재지정할 것을 권고한다.

 

Type 8: Echo 메시지를 나타낸다. 이 메시지를 수신한 호스트는 발신자 주소를 목적지로 하여 Echo Reply 메시지를 전송한다.

Type 9, 10: IRDP (ICMP Router Discovery Protocol)에서 사용하는 메시지이다. 이것은 RFC 1256에서 정의되었으며, Type 9는 RS (Router Solicitation) 메시지, Type 10은 RA (Router Advertisement) 메시지이다.

각각의 패킷 구조는 다음과 같다.

RA Message

RA_Msg

RS Message

RS_Msg
All Rights Reserved ktworld.co.kr

이 때 IRDP 메시지는 Multicast 주소(224.0.0.1)로 전송되거나, Broadcast 주소를 사용한다. (Cisco는 기본적으로 Broadcast)

IRDP를 사용하는 라우터는 자신이 네트워크에 연결되었을 때 RS를 전송하고, 주기적으로 RA를 전송한다. 또한 RA는 RS에 대한 응답으로써 전송될 수도 있다.

 

Type 11: 시간 초과 메시지를 나타낸다. 이 메시지는 두 가지 경우에 전송되는데, 하나는 IP 패킷의 TTL이 0이 되었을 때이며, 다른 하나는 단편화 재조합 타이머(Fragment Reassembly Timer)가 만료되었을 경우이다.

여기서 재조합 타이머는 단편화되어 전송되는 패킷 중 일부가 전송 중 손실될 경우, 목적지 호스트가 손실된 패킷의 도착을 영구히 기다리는 상황을 막기 위해 타이머 만료 시간까지 전체 패킷이 도착하지 못했다면 버퍼에서 단편화된 패킷 조각들을 전부 폐기하고, 재전송을 위해 시간 초과 메시지를 보내기 위해 사용된다.

Code 0은 TTL 값의 만료, Code 1은 단편화 재조합 타이머 만료를 나타낸다.

 

Type 12: Parameter Problem. 이 메시지는 IP 데이터그램의 구조에 문제가 있어, 그 패킷을 폐기할 때 전송된다. 또한, Parameter Problem 메시지는 다른 ICMP 메시지에 해당되지 않는 모든 오류에 대해서도 전송되어야 한다.[2]

이 메시지가 가질 수 있는 Code는 다음과 같다.

Typ12-Code-1

Code 0: IP 데이터그램의 구조에 문제가 있음을 나타냄.

Code 1: 필요한 옵션이 정의되지 않음. 미 국방성에서 사용하는 특별한 보안 옵션과 이용됨[3]

Code 2: IP 데이터그램의 Header Length나 Total Packet Length값이 올바르지 않음.

 


각주

 

[1] IANA – ICMP Type Numbers

[2]  RFC 1122 Section 3.2.2.5 – “The ICMP Parameter Problem message is sent to the source host for any problem not specifically covered by another ICMP message.”

[3] RFC 1122  Section 3.2.2.5– “NOTE: This variant is currently in use in the military community for a missing security option.

 

 

CCNA Study – ARP Protocol

 


 

목차

1. Introduction

2. ARP 동작 예시

3. ARP의 변형

3-1. Reverse ARP (RARP)

3-2. Inverse ARP (InARP)

3-3. DHCP ARP

3-4. Gratuitous ARP (gARP)

3-5. ARP Probe

3-5.1. ARP Probe의 동작

3-6. UnARP


 

1. Introduction

Ethernet에서 물리 계층 주소(MAC)을 얻어낼 때 사용하는 프로토콜인 ARP에 대해 RFC를 참조하여 알아본다.

ARP는 1982년, RFC 826에 처음으로 정의되었다. 여기서 ARP의 목적은 ‘프로토콜 주소를 로컬 네트워크 주소로 변환하는 방법을 제공하는 것’이라고 밝히고 있다. 즉, 기본적으로 Ethernet을 위해 개발된 프로토콜이긴 하지만, 경우에 따라서 다른 프로토콜 위에서 동작할 수 있으며, 실제로 X.25, HDLC, FDDI, 802.11, ATM 등에서도 ARP를 사용하고 있다. ARP는  STD 37이라는 이름의 인터넷 프로토콜로 승인되었고, RFC 1122에서의 ‘잘못된 ARP Entry에 대한 처리’에 대한 모호함을 보완하였다. (The ARP specification [LINK:2] suggests but does not require a timeout mechanism to invalidate cache entries when hosts change their Ethernet addresses.)[1]

그러면 다시 RFC 826으로 돌아가 ARP가 어떻게 동작하는지 알아보자.
RFC 826에서는 ARP 헤더를 다음과 같이 정의하고 있다.

1. Hardware Address (16bit) – 로컬 네트워크에서 사용하는 하드웨어 타입을 규정한다.

2. Protocol Address (16bit) – 하드웨어 타입 필드를 보완하며, 3계층 프로토콜의 종류를 규정한다. Ethernet의 경우 Ether-type 필드의 값과 동일하다.

3. Hardware Address Length (8bit) – 뒤에 올 하드웨어 주소의 길이를 바이트 단위로 지정한다. 예를 들어 Ethernet은 48bit이므로 6의 값을 갖는다.

4. Protocol Address Length (8bit) – 이 메시지에 포함된 3계층 프로토콜의 주소 길이를 바이트 단위로 지정한다. 예를 들어 IPv4는 4의 값을 갖는다.

5. Opcode (16bit) – 이 ARP 패킷의 목적을 밝힌다. Opcode의 값은 좀 더 뒤에서 다루겠다.

6. Sender Hardware Address (n Byte) – 앞서 말한 길이의 송신자 하드웨어 주소가 온다.

7. Sender Protocol Address – (m Byte) – 앞서 말한 길이의 송신자 프로토콜 주소가 온다.

8. Target Hardware Address – (n Byte) – 앞서 말한 길이의 수신자 하드웨어 주소가 온다. 당연히 ‘알고 있을 경우’에 한하여 기록된다.

9. Target Protocol Address (m Byte) – 앞서 말한 길이의 수신자 프로토콜 주소가 온다.

이것을 그림으로 나타내면 다음과 같다.

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

2. ARP 동작 예시

Host A가 Host B에게 ARP Request를 보내는 시나리오를 이용하여 일반적인 ARP의 동작을 알아본다.

1. Host A는 이더넷 프레임에 사용할 목적지 MAC 주소를 결정하기 위해 자신의 ARP 캐시 테이블을 확인한다.

2. 캐시 테이블에 MAC 주소가 없다면 Host B의 MAC을 얻기 위해 ARP Request를 Dst-MAC-Addr을 FF:FF:FF:FF:FF:FF로 설정하여 브로드캐스팅한다.

3-1. 동일한 네트워크 세그먼트 상의 시스템들은 모두 이 ARP 패킷을 수신하고, 자신의 Protocol Address와 패킷의 TPA를 비교, 같지 않으면 폐기한다.

3-2. 만약 패킷의 TPA와 자신의 Protocol Address가 일치한다면, 자신의 Protocol Address를 기록한 ARP Reply 패킷을 Request를 보낸 시스템에 유니캐스트로 전송한다.

4. ARP Reply를 수신한 Host A는 자신의 ARP 캐시 테이블에 그 정보를 기록한다.

5. ARP Request에는 응답 만료 시간(Timeout)이 존재하지 않기 때문에, 응답을 수신하지 못하더라도 상관없다. 물론 이 경우에는 호스트와의 통신이 이루어지지 않는다.

 

 

3. ARP의 변형

Ethernet이 확산되고, 증가하는 여러 요구들에 대응하기 위해 ARP의 변형들이 사용되게 되었다.

대표적으로 Reverse ARP, Inverse ARP, Gratuitous ARP 등이 존재하는데, 이것들을 다루기 전에 먼저 ARP Packet의 Operation Code를 살펴볼 필요가 있다.

 

from IANA Reference
from IANA Reference [2]

여기서 Opcode 1, 2번은 일반적인 ARP 요청과, 변형 ARP 중 gARP, DHCP ARP, ARP Probe 등에 사용되는 Request/Reply이고, 이 글에서는 이에 더하여 Reverse ARP(3,4번) Inverse ARP(8, 9번)을 다루겠다.

 

 

3-1. Reverse ARP (RARP)

IPv4를 사용하는 장비가 자신의 하드웨어 주소는 알고 있지만, 자신에게 할당된 IPv4 주소는 모를 때 사용한다.

과거에 저장 매체가 없는 단말들(터미널)이 라우팅이 필요하지 않은 LAN 통신을 위해 주로 사용했지만, 디폴트 게이트웨이, DNS 서버 주소, 서브넷 마스크 등을 알 수 없기 때문에 지금은 DHCP와 BOOTP로 대체되었다.

 

Reverse ARP의 동작 과정은 다음과 같다.

1. 부팅된 터미널 장비가 Sender MAC-Addr와 Target MAC-Addr을 자신의 하드웨어 주소로 채운 RARP Request 패킷을 브로드캐스팅한다. 이 때 Sender IP-Addr과 Target IP-Addr은 전부 0.0.0.0이다.

2. RARP 서버가 이것을 수신하고, Target Protocol Address를 터미널 장비에 할당된 IP로 넣은 RARP Reply 패킷을 L2 Unicast 한다.

3. 터미널이 RARP Reply를 수신하고, 자신의 IP를 설정한다. Calssful Network를 기반으로 한 LAN 통신만이 가능하다.

RARP에 대한 자세한 설명은 RFC 903[3]에 기술되어 있다.

 

 

3-2. Inverse ARP (InARP)

Inverse ARP는 Frame-Relay와 ATM과 같이 여러 물리 계층 장비가 연결되어 WAN 네트워크를 구성하고 있지만, 하나의 논리적인 회선을 구성하여 통신을 하는 네트워크에서 쓰인다.

Frame Relay 망에서 Inverse ARP는 네트워크 장비가 자신과 연결된 VC 단말의 정보를 얻는 데 사용되며, 이를 위해서는 당연히 L2 설정이 제대로 되어 있어야 한다.

L2 통신에 필요한 DLCI를 동적으로 할당하고, 링크의 상태를 확인하는 프로토콜로 LMI가 있는데, 이것은 추후 Frame Relay를 살펴볼 때 알아볼 것이다.

 

그럼 간단한 Frame Relay 망을 예시로 InARP가 어떻게 동작하는지 알아보자.

 

InARP

 

1. Router A는 자신에게 할당된 DLCI 10, 20이 어디에 연결되어 있는지를 알고 싶어한다.

2. Router A는 SHA를 DLCI 10, SPA를 ipA로 하여 InARP Request를 전송한다.

3. Router A의 InARP Request를 수신한 Router B는 자신의 InARP 캐시에 Router A의 DLCI와 IP를 기록하고, SHA에 DLCI 40, SPA에 ipB를 기록한 InARP Reply를 전송한다.

4. Router B의 InARP Reply를 수신한 Router A는  자신의 InARP 캐시에 RouterB의 DLCI와 IP를 기록한다.

5. 이제 L3 통신을 위한 모든 정보가 갖추어졌으므로 통신이 이루어질 수 있다.

 

Inverse ARP의 구현에 대한 자세한 정보는 RFC 2390[4]을 참조하자.

 

3-3. DHCP ARP

DHCP를 이용한 IPv4 자동 할당은 편리하지만, 자칫 IPv4 주소의 충돌이라는 문제를 발생시킬 우려가 있다.

이 문제를 미연에 방지하기 위해 DHCP ARP가 RFC 2131[5]을 통해 정의되었다.

 

DHCP ARP는 다음과 같이 구성된다.

 

Dst-MAC: FF-FF-FF-FF-FF-FF

Src-MAC: Client-MAC

Opcode: 1 (Request)

Src-Har-Addr: Client-MAC

Src-Pro-Addr: 0.0.0.0

Target-Har-Addr: 00-00-00-00-00-00

Target-Pro-Addr: Assigned-IP-Addr

 

여기서 출발지 프로토콜 주소가 0.0.0.0인 것은 이 ARP Request를 수신한 장비들이 자신의 ARP Cache Entry를 갱신하지 않도록 하기 위해서이며 (When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender’s hardware address, and 0 as the sender’s IP address, to avoid confusing ARP caches in other hosts on the same subnet.[6]) 이 요청에 대한 ARP Reply를 수신하지 못한다면 클라이언트는 할당받은 IP 주소를 사용할 것이다.

RFC 2131은 또한 ‘IP 주소의 갱신을 다른 시스템에게 보고하기 위해 ARP Reply를 브로드캐스팅하여 다른 시스템이 오래된 ARP Entry를 갱신하도록 해야 한다’ ( The client SHOULD broadcast an ARP reply to announce the client’s new IP address and clear any outdated ARP cache entries in hosts on the client’s subnet.[7])고 규정하고 있으나, 대부분의 시스템에서는 Gratuitous ARP라 불리는 ARP Request를 이용해 이 기능을 구현하고 있다.

 

3-4. Gratuitous ARP (gARP)

Gratuitous ARP (이하 gARP)는 자신의 IP나 MAC이 변동되어, 같은 서브넷 내의 다른 장비들의 ARP Cache Entry를 갱신할 필요가 있을 때 사용된다.

예를 들어 DHCP로부터 새로운 IP를 할당받았거나, VRRP에서 Active Router를 변경할 때, 클라이언트에서 2개의 NIC를 이용하여 고가용성(HA) 구성을 하였을 경우 등이 있다.

 

gARP 패킷은 다음과 같이 구성된다.

 

Dst-MAC: FF-FF-FF-FF-FF-FF

Src-MAC: Client-MAC

Opcode: 1 (Request)

Src-Har-Addr: Client-MAC

Src-Pro-Addr: Client-IP-Addr

Target-Har-Addr: 00-00-00-00-00-00

Target-Pro-Addr: Client-IP-Addr

 

DHCP ARP 와는 다르게 출발지 프로토콜 주소 필드가 자신의 IP 주소로 설정되었다는 것을 알 수 있다.

gARP는 앞서 말했듯이 오래된 ARP 캐시 엔트리의 갱신이 목적이기 때문에 ARP Reply가 돌아오는 것을 기대하지 않지만, 만약 Reply가 돌아온다면 IP 주소가 충돌한다는 것을 의미하게 되므로 적절한 대처가 요구된다.

 

3-5. ARP Probe

ARP Probe는 IPv4 주소의 충돌을 감지하기 위한 수단으로써, RFC 5227[8]에 정의되어 있다.

ARP Probe는 기본적으로 DHCP ARP와 동일한 구성을 가지는데, 이것은 ARP Probe가 DHCP ARP를 참조했기 때문이다. (The DHCP specification [RFC2131] briefly mentions the role of ARP in detecting misconfiguration, as illustrated in the following three excerpts from RFC 2131: [9])

RFC 5227에서는 DHCP ARP를 확장하여, ‘IPv4를 할당받는 모든 경우에 ARP Request를 전송하도록'(Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means)[10]) 규정하고 있으며

RFC 2131의 모호함을 (the DHCP specification does not give any guidance to implementers[11]) 해결하였다.

 

3-5.1. ARP Probe의 동작

ARP Probe는 크게 Probing – Announcing – Conflict Detection and Address Defense의 순으로 이루어진다.

먼저, Probing은 DHCP ARP의 패킷 구성을 따르되, IP 할당 이후 0~1초 사이의 랜덤한 시간을 대기한 뒤 3개의 Probing Packet을 전송한다. 이 Probing Packet의 사이에는 1~2초 사이의 임의의 시간 간격을 준다.

마지막 Proving Packet을 전송하고 2초가 지난 뒤에도 ‘Sender IP Address’가 할당받은 IP인 ARP Packet(Request/Reply)이 도착하지 않으면, 클라이언트는 이 IP를 사용해도 된다고 판단, ARP Announcement 패킷-gARP와 동일-을 전송하고, 마지막 단계인 Conflict Detection and Address Defense로 천이한다.

 

Conflict Detection and Address Defense 단계에서 호스트는 Sender IP Address가 자신이 할당받은 IP이면서 Sender Hardware Address가 자신이 아닌 ARP 패킷이 들어오는지를 계속 확인한다.

만약 그러한 패킷이 발견되면, 호스트는 다음 3가지 중 하나의 동작을 취한다.

 

A. 즉시 그 IP 주소의 사용을 포기한 뒤, 설정 Agent(e.g. DHCP Server)에게 오류를 보고한다.

B. 현재 열려있는 TCP 세션이 있어서 IP를 포기할 수 없고, 10초가 지나도 다른 문제가 되는 ARP 패킷이 들어오지 않는다면 그 IP를 계속 사용하도록 결정할 수 있다. 그리고 ARP Announcement 패킷을 한번 더 전송한다. 만약 추가로 문제가 되는 ARP 패킷이 들어오면 호스트는 즉시 그 IP를 폐기하고, 오류를 Agnet에게 보고한다.

C. 만약 이 클라이언트가 네트워크에서 매우 중요한 시스템(e.g. Default Gateway)이어서 IP를 무슨 일이 있어도 포기할 수 없다면, 이 IP를 계속 사용하도록 결정할 수 있다. 이 경우 클라이언트는 Sender-MAC-Addr와 같은 정보를 로그에 기록하고, 네트워크 관리자에게 문제를 알려야 한다. 10초가 지나도 문제가 되는 ARP 패킷이 추가로 유입되지 않으면, 호스트는 ARP Announcement를 1회 전송하고 이 IP를 계속 사용할 수 있다. 만약 10초 이내에 다시 문제가 되는 ARP 패킷이 유입되면, 호스트는 IP  Defense loop를 방지하기 위해 ARP Announcement를 전송해서는 안 된다.

 

 

3-6. UnARP

UnARP는 Proxy ARP 환경에서의 ARP Cache Invaild 문제를 해결하기 위해 RFC 1868[12]을 통해 제시되었고, 현재 실험 프로토콜(Experimental Protocol)로 지정되어 있다.

RFC 1868은 현재 사용되는 timeout을 통한 ARP Entry 제거 방식 대신 클라이언트가 네트워크로부터 접속을 종료할 때, 그것을 명시적으로 ARP를 통해 알리는 것을 골지로 하며, 실험 프로토콜의 특성상 이것을 준수하는 장비는 잘 없다.

 


각주

[1] https://tools.ietf.org/html/rfc1122#page-22

[2] http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-1

[3] https://tools.ietf.org/rfc/rfc903.txt

[4] https://tools.ietf.org/html/rfc2390

[5] https://tools.ietf.org/html/rfc2131

[6] RFC 2131 – Section 4.4.1 : https://tools.ietf.org/html/rfc2131#section-4.4

[7] RFC 2131 – Section 4.4.1 : https://tools.ietf.org/html/rfc2131#section-4.4

[8] https://tools.ietf.org/html/rfc5227

[9] RFC 5227 – Section 1 (Introduction) : https://tools.ietf.org/html/rfc5227#section-1

[10] RFC 5227 – Section 2.1 : https://tools.ietf.org/html/rfc5227#section-2.1

[11] RFC 5227 – Section 1 : https://tools.ietf.org/html/rfc5227#section-1

[12] https://tools.ietf.org/html/rfc1868