요약

  • RFC 3147은 혼합 관리 네트워크에서 빠져 있던 방향을 제시했습니다. IPv4 또는 IPv6를 GRE로 감싸고, 그 GRE를 CLNP의 사용자 데이터로 실어, 새로 IP로 관리되는 요소들이 기존에 설치된 CLNS 내부망을 건너 여전히 도달 가능하도록 했습니다.
  • 제안된 N-SEL 값 47은 수신 CLNS 종단에서 GRE를 식별했고, GRE Protocol Type은 내부 프로토콜을 식별했습니다. 어느 식별자도 관리 대상 장치로의 전달이나 관리 작업의 성공을 증명하지 못했습니다.
  • 이 설계는 마이그레이션을 의존성 문제로 드러냈습니다. 도달 가능성, 패킷 크기 동작, 보안, 장치 결과가 독립적으로 검증되기 전까지는 구(舊) 네트워크가 의도된 대체물의 트래픽을 실어 나르야 할 수 있습니다.

대체 네트워크는 아직 경로가 아니었다

2001년 무렵 SONET과 SDH 장비를 둘러싼 관리 네트워크에는 그 자체의 역사가 쌓여 있었습니다. Bellcore GR-253-CORE와 ITU-T G.784가 이 역할에서 CLNS를 요구해 왔습니다. RFC 3147이 서술한 결과는 실험실의 궁금한 사례가 아니라 거대한 기존 관리 환경이었습니다. 새로운 네트워크 요소들은 IP를 쓰기 시작했지만, 관리 스테이션과 그 요소들 사이의 기판은 종단이 바뀌었다고 해서 함께 바뀌지 않았습니다.

그렇게 서로 거울상인 두 개의 섬이 만들어졌습니다. 한쪽에서는 CLNS로 관리되던 낡은 요소가 새로운 IP 네트워크 뒤에 놓여 있었고, CLNP PDU를 IP 위에 GRE로 실으면 그 간극을 메꿀 수 있었습니다. 반대쪽에서는 새로 IP로 관리되는 요소가 기존 CLNS 네트워크 너머에 놓여 있었습니다. 첫 번째 터널 방향은 두 번째 문제를 해결할 수 없었습니다. 이제 통과해야 할 패킷은 IP였고, 이를 전달할 수 있는 내부망은 CLNS였습니다.

RFC 3147은 이 역방향 브리지를 문서화했습니다. IPv4 또는 IPv6 패킷이 GRE에 들어갑니다. 완전한 GRE 패킷이 CLNP Data Type PDU의 사용자 데이터가 됩니다. CLNP가 그 PDU를 기존 CLNS 네트워크를 건너 터널 종단까지 전달하고, 터널 종단은 CLNP와 GRE 계층을 벗겨 내부 패킷을 IP로 관리되는 요소 쪽으로 내보냅니다.

이 메커니즘은 CLNS 내부망을 IP 네트워크로 바꾸지 않았습니다. 모든 SONET·SDH 요소에 새 관리 프로토콜을 가르치지도 않았습니다. 터널 종단들 사이에 유한한 경로를 만들었을 뿐입니다. 이 구분이 정직한 마이그레이션 기록의 출발점입니다.

하나의 패킷이 세 가지 다른 주장을 실었다

중첩된 패킷은 세 개의 분리된 결정을 담았습니다. 내부 IP 헤더는 IP 대화를 이름 붙였습니다. GRE 헤더는 내부 바이트가 어떤 네트워크 계층 프로토콜인지 말했습니다. CLNP 헤더는 실제로 통과된 CLNS 도메인의 주소와 전달 동작을 공급했습니다.

이 계층들을 한데 뭉치면 매력적이지만 거짓인 문장이 만들어집니다. 터널 종단에 도착한 CLNP PDU는 CLNS가 운반 패킷을 그 지점까지 전달했다는 것만 증명합니다. 유효한 GRE Protocol Type은 종단이 페이로드를 어떻게 해석해야 하는지 보여줄 뿐입니다. 역캡슐화된 IPv6 패킷은 종단이 그 바이트를 내보냈다는 것만 증명합니다. 그 어느 것 하나만으로 특정 네트워크 요소가 명령을 받아들였다거나, 응답을 돌려보냈다거나, 구성을 변경했다는 증명은 되지 않습니다.

식별자들은 똑같이 분리된 채로 있어야 합니다. 발신·수신 NSAP는 CLNS 종단을 식별합니다. IP 주소는 IP 계층의 인터페이스나 목적지를 식별합니다. 관리되는 요소의 운영상 정체성은 인벤토리, 물리적 배치, 인증서 또는 다른 명명 체계에 뿌리내릴 수 있습니다. 어느 하나를 나머지의 영구 별칭으로 다루면, 마이그레이션이 실제 증거보다 더 완성된 것처럼 보이게 됩니다.

여기서 RFC 3147은 잘 알려지지 않은 캡슐화 메모 이상의 의미를 갖습니다. 운영자가 혼합 네트워크에서 현실의 계층들을 어떻게 지킬 수 있는지 보여줍니다. 의도된 관리 행위가 한 계층입니다. IP 패킷은 또 다른 계층입니다. GRE는 봉투이고, CLNP는 운반자입니다. 관리 응용의 확인 응답은 그보다 더 뒤에 옵니다. 각각은 자기만의 영수증을 필요로 합니다.

십진수 47이 맞는 문을 열었다

CLNS는 NSAP의 마지막 옥텟인 N-selector(N-SEL)로 서로 다른 Network Service 사용자를 구분했습니다. 수신자에게는 “CLNP 사용자 데이터가 GRE로 시작한다”는 공통의 의미를 지닌 값이 필요했습니다. RFC 3147은 십진수 47, 즉 IP 프로토콜 번호 공간에서 GRE에 할당된 같은 숫자를 제안했습니다.

이 재사용은 경제적인 선택이지 마법이 아니었습니다. N-SEL 47은 CLNS 터널 종단에서 GRE 처리기를 골랐습니다. 최종 페이로드를 식별하지는 않았습니다. 그 역할은 GRE Protocol Type이 담당했으며, IPv4, IPv6 또는 지원되는 다른 네트워크 계층 프로토콜을 구분했습니다. 모든 N-SEL 47 트래픽을 “IPv4 관리”라고 이름 붙이는 모니터는 하나의 계층을 버린 것이며, 정당한 IPv6 트래픽을 잘못 분류할 수 있습니다.

“제안했다”는 표현도 중요합니다. 다벤더 운영에서는 두 종단이 하나의 N-SEL에 합의해야 했습니다. 십진수 47은 기억하기 쉬운 공유 관례를 제공했습니다. 어떤 RFC와 레지스트리에 그 값이 있다는 사실은, 모든 벤더가 이를 구현했다거나, 두 구현이 나머지 동작까지 합의했다거나, 이름이 알려진 어떤 운영자가 배치했다는 증거가 아니었습니다.

따라서 쓸모 있는 영수증은 주소 선택자와 프로토콜 필드를 모두 기록해야 합니다. 발신·수신 NSAP, 양쪽 N-SEL 값, GRE 플래그와 버전, GRE Protocol Type, 내부 주소, 페이로드 지문. “터널 up”이라는 표현은 어느 패킷에 대해 어느 문이 열렸는지 설명하기에는 너무 압축되어 있습니다.

작은 요청 하나가 큰 블랙홀을 숨길 수 있었다

캡슐화는 패킷 크기를 바꾸며, 구(舊) 내부망은 새 종단이 볼 수 없는 제한을 부과합니다. CLNP에는 Segmentation Permitted 플래그가 있습니다. RFC 3147은 이를 설정할 것을 권했습니다. 세그먼테이션이 허용되지 않은 상태에서 CLNP PDU가 내부 링크의 최대 크기를 넘으면, 네트워크가 그 PDU를 폐기할 수 있었습니다. IP 발신자는 그 실패에 관한 유용한 통보를 받지 못할 수 있습니다.

관리 트래픽에서 이런 실패는 특히 위험합니다. 짧은 질의나 ping은 통과하는데 더 큰 구성 전송은 실패할 수 있습니다. 운영자가 작은 패킷을 관찰한 뒤 경로를 승인하고, 큰 트랜잭션이 사라졌을 때는 장치나 응용을 탓할 수 있습니다. 도달 가능성은 크기, 오버헤드, 세그먼테이션 정책에 조건부였습니다.

터널 입구에서 IPv4 Path MTU Discovery가 또 하나의 결정을 추가했습니다. 지나치게 큰 내부 IPv4 패킷에 Don't Fragment가 설정되어 있지 않으면, 입구는 캡슐화 전에 분할할 수 있었습니다. DF가 설정되어 있으면 패킷을 폐기하고 적절한 ICMP fragmentation-needed 메시지를 돌려보내야 했습니다. 그 응답 자체도 발신자에게 도달하는 동작하는 경로를 필요로 했습니다.

그 결과 증거는 단순한 성공·실패보다 풍부합니다. 원래 길이, DF 상태, 추가된 GRE와 CLNP 오버헤드, CLNP 세그먼테이션 플래그, 제약 링크 크기, 분할 여부, ICMP 메시지 여부, 관찰 지점. 이 좌표들이 없으면 크기 의존적 터널 실패가 간헐적 장치 이상으로 위장할 수 있습니다.

캡슐화가 곧 보안이 되지는 않았다

RFC 3147은 자신의 보안 경계에 대해 분명했습니다. CLNS와 GRE는 이 용도에 어떤 보안도 제공하지 않습니다. 보호가 필요하면, GRE over CLNS로 들어가기 전에 다른 방법이 페이로드를 보호해야 합니다. 이 메모는 터널을 인증, 암호화 또는 권한 부여로 바꾸지 않았습니다.

이 절제는 운영적으로 중요합니다. 패킷이 세 개의 네트워크 계층에서 완벽한 형태를 갖추면서도 승인되지 않은 관리 명령일 수 있습니다. 수신 종단이 보낸 바이트 그대로를 역캡슐화하면서 관리 응용이 그것을 거부할 수도 있습니다. 반대로, 장치 정체성과 채널 보호가 독립적으로 확립되지 않으면 응용 확인 응답이 위조되거나 잘못 결합될 수 있습니다.

이후의 GRE 확장과 오늘날의 보안 도구는 배치를 풍부하게 할 수 있지만, 2001년 7월의 사양에 소급할 수는 없습니다. 역사적 분석은 어떤 메커니즘이 관찰되었는지를 말해야 하며, 지금 익숙하다는 이유만으로 낡은 봉투에 현대적 속성을 수여해서는 안 됩니다.

구(舊) 네트워크는 전환으로부터 영향력을 얻었다

모든 임시 브리지는 인센티브를 바꿉니다. CLNS 내부망 너머의 새 장비가 GRE over CLNS에 의존하게 되는 순간, 구 네트워크는 단순한 레거시 오버헤드가 아니었습니다. 새 장비의 도달 경로의 일부였습니다. 성급하게 제거하면 현대화의 증거로 제시된 바로 그 장치들을 고립시킬 수 있습니다.

이것은 과장 없는 수명 주기 락인입니다. CLNS가 영원히 은퇴할 수 없다는 뜻이 아닙니다. 은퇴에는 증명이 필요하다는 뜻입니다. 의존하는 모든 요소가 검증된 다른 경로를 확보했는지, 패킷 크기 동작이 알려졌는지, 보안 제어가 경로와 함께 이동했는지, 롤백이 가능한지, 그리고 터널 카운터뿐 아니라 관리 결과가 전환을 살아남았는지.

따라서 CLNS 라우팅과 NSAP 계획을 지배하는 주체가 전환 기간 동안 하나의 운영 표면을 통제했습니다. IP 종단을 지배하는 주체는 또 다른 표면을 통제했습니다. 장치 벤더는 관리 동작을 통제했습니다. 표준 문서는 그들 사이의 인터페이스를 상호운용 가능하게 만들 수 있었지만, 그들의 권한이나 인센티브를 합칠 수는 없었습니다.

그래서 마이그레이션 도표에는 프로토콜 구름만이 아니라 소유권과 증거의 경계선이 들어가야 합니다. N-SEL을 바꿀 수 있는 사람은 누구인가? 내부 폐기를 볼 수 있는 사람은 누구인가? 장치 상태를 검증할 수 있는 사람은 누구인가? 폴백 경로의 제거를 승인하는 사람은 누구인가? 브리지는 그 제도적 위상 안에서만 기술적으로 작동합니다.

공존이야말로 정직한 아키텍처였다

인터넷의 역사는 종종 대체의 이야기로 압축됩니다. 하나의 프로토콜이 이기고, 하나는 사라지고, 새 스택이 낡은 스택을 대체했다는 식입니다. RFC 3147은 두 방향 모두가 존재해야 했던 덜 우아한 시기를 보존했습니다. 레거시 CLNP는 IP를 건너 낡은 요소로 갈 수 있었고, IP는 CLNS를 건너 새 요소로 갈 수 있었습니다. 마이그레이션은 스위치가 아니라 서로를 건너는 한 쌍의 의존성이었습니다.

이것이 RFC의 협소함이 강점이었던 이유이기도 합니다. GRE가 어디에 놓이는지, CLNS 종단이 어떻게 이를 구분하는지, 패킷 크기를 어떻게 다뤄야 하는지를 규정했습니다. 관리 응용, 보편적 보안 체계, 운영자의 은퇴 계획, 상업적 판단을 명령하지 않았습니다. 최소한의 상호운용 가능한 접합은 이후의 결정을 현지에 남겨두었습니다.

동작하는 코드가 마이그레이션 이야기에 반론을 공급했습니다. 패킷이 모든 봉투를 통과했는데 장치 상태가 바뀌지 않았다면, 관리 작업은 실패한 것입니다. 작은 패킷은 되고 큰 패킷이 사라졌다면, 경로는 일반적으로 사용 가능한 것이 아닙니다. 낡은 CLNS 경로가 유일한 롤백 경로로 남아 있었다면, 대체는 돌이킬 수 없는 것이 아니었습니다. “IP 관리”, “현대화됨” 같은 레이블이 계획을 정리할 수는 있었지만, 그런 관찰들을 뒤엎을 수는 없었습니다.

RFC 3147은 이렇듯 소박하지만 오래가는 진실을 기록했습니다. 후계 아키텍처는 처음에는 자신이 대체하려는 아키텍처 안의 트래픽으로 나타난다는 것입니다. 터널은 운영자가 다음 경로를 만드는 동안 연속성을 보존할 수 있습니다. 그러나 그 건넘의 끝을 인증할 수는 없습니다.

출처