요약

  • RFC 801은 각 호스트 조직이 직접 구현해야 하는 마이그레이션의 종료 시점을 1983년 1월 1일로 정했으며, 그 사이 이중 프로토콜 릴레이가 선별된 서비스를 연결했다.
  • 1985년 회고록은 전환 날짜를 확인하면서도, 메일 릴레이 의존성, 호스트 테이블 문제, 이후의 서비스 호스트 성능 작업을 기록하고 있다.

분석

“플래그 데이(flag day)”라는 표현은 하나의 통합된 소프트웨어 업데이트처럼 들린다. 그러나 Arpanet의 NCP에서 TCP로의 마이그레이션은 여러 독립 운영 주체에 부과된 마감 시한에 가까웠다. 1981년 11월, RFC 801은 각 호스트 조직에게 자체 시스템에 IP/TCP와 주요 서비스인 텔넷(Telnet), 파일 전송, 메일을 구현하도록 요청했다. 작업은 1982년 1월까지 시작되어야 했고, NCP에서의 완전한 전환은 1983년 1월 1일을 목표로 했다.

전환 계획은 시스템들이 동시에 옮겨가지 않을 것을 전제했다. 일부 호스트는 TCP를 사용하는 반면 다른 호스트는 여전히 네트워크 제어 프로토콜(NCP)을 사용할 수 있었다. 그래서 RFC 801은 두 환경을 모두 구동하며 텔넷, FTP 또는 메일을 사이에서 전달할 수 있는 릴레이 호스트를 마련했다. 경계를 넘어 파일을 전송하는 사용자는 릴레이에 로그인해 NCP 호스트에서 파일을 가져온 뒤, TCP를 통해 이를 받아볼 수 있었다. 호환성은 추상적 약속이 아니라 운영 중인 서비스였다.

메일은 더 일찍 자체 계획을 거쳤다. 1980년 10월의 RFC 773은 구형·신형 메일 시스템 간 전달을 탐구하면서, 포워더를 어떻게 지정하고 호스트명 및 기능 정보를 어떻게 배포할지 등 미해결 질문들을 나열했다. 이는 단순한 패킷 형식 변경의 문제가 아니었다. 이름이 해석되어야 했고, 사용자에게 다른 메일박스로 가는 경로가 필요했으며, 서비스 운영자는 작동하는 브리지를 계속 유지해야 했다.

RFC 801의 일정은 1982년 7월까지 대부분의 호스트가 TCP를 사용하고, 11월까지 NCP 전용 마지막 호스트가 전환을 완료하며, NCP와 릴레이가 제거되는 1983년 1월에 “완전한 인터넷 서비스”가 뒤따를 것으로 예측했다. 이러한 이정표는 계획서 속 목표였다. 이후의 기록이 실행 증거를 제공한다. 1985년에 발표된 RFC 942는 수년간의 병행 사용과 TCP 전용 호스트를 추가한 마지막 6개월의 준비 기간을 거쳐 1983년 1월 1일 Arpanet이 전환(cutover)을 수행했다고 언급한다.

회고록은 깔끔한 결말을 흐리게 만든다. 사용자 기기들이 전환을 시작하기 전에 터미널 접속 제어기와 서비스 호스트가 이중 프로토콜 지원이 필요했다. 릴레이는 모든 트래픽의 일반 경로가 아니라 주로 메일에 유용한 것으로 드러났다. 네트워크 정보 센터(Network Information Center)는 새 프로토콜에 대비하지 못했고, 이는 호스트명 테이블 배포에 차질을 빚었다. 그리고 새 시스템이 지속적인 사용자 부하에 직면하자, 서비스 호스트는 성능 분석과 매개변수 조정이 필요했다.

그러므로 이 전환은 한 수준에서는 성공했다. NCP 서비스가 예정대로 종료되었고 Arpanet은 TCP/IP로 전환했다. 그러나 이는 모든 지원 기능이 부하 하에서 검증되었거나 모든 사용자가 원활한 하루를 경험했다는 주장은 아니었다. 같은 시기인 1983년 1월에 발표된 RFC 820은 이 변경이 다른 프로토콜들도 수반했다고 언급했다. “인터넷”은 프로토콜 스위트, 그 애플리케이션, 그리고 이를 운영하는 책임자들을 통해 도래했다.

출처