요약

  • RFC 2452는tcpActiveOpens를 포함한 대부분의 TCP 관리 객체가, 연결을 IPv4가 운반하든 IPv6가 운반하든 그에 독립적으로 유지되도록 했다.
  • 관리 노드에서 네 개의 엔드포인트 값만으로는 항상 하나의 연결 행을 식별할 수 없었기 때문에, 별도의 IPv6 테이블은ipv6TcpConnIfIndex를 추가했다.

카운터 하나에는 두 번째 이름이 필요하지 않았다

IPv6 전환은 깔끔하지만 오해를 부를 수 있는 분할을 만들 수도 있었다. IPv4용 TCP 카운터 집합, IPv6용 집합, 그리고 서로 다른 전송 계층을 묘사하는 것처럼 보이는 두 대시보드 말이다. RFC 2452는 더 좁은 입장을 취했다. 1998년 12월에 표준 트랙 문서로 발표된 이 문서는 기존 TCP 관리 정보 기반(MIB)의 대부분 객체가 TCP 아래의 IP 버전에 의존하지 않는다고 명시했다. 특히tcpActiveOpens를 지목하며, 이 카운터는 패킷이 IPv4로 운반되든 IPv6로 운반되든 TCP 연결이 CLOSED에서 SYN-SENT로 직접 전이하는 것을 측정한다고 했다.

이는 모든 장비가 내부 카운터를 어떻게 구현했는지에 대한 보고가 아니라, 관리 계약에 대한 주장이었다. 이 RFC는 공유된 숫자가 운영자에게 어떤 주소 패밀리, 연결, 인터페이스, 프로세스 또는 사용자가 증가를 일으켰는지 알려줄 수 있다고 말하지 않았다. 이벤트 자체가 하나의 의미를 유지하므로, 카운터를 복제하면 객체가 스스로 제공하지 않는 패밀리 라벨이 추가될 뿐이라는 것이다.

연결 테이블은 달랐다

RFC 2012의 TCP 테이블은 주소를 SMIv2의IpAddress, 즉 4옥텟 값으로 저장했다. 이 표현은 IPv6 엔드포인트를 담을 수 없었다. 그래서 RFC 2452는 엔드포인트가 IPv6인 연결을 위한 두 번째 테이블을 정의하고, IPv4 연결은 기존 테이블에 남겨두었다. 모든 IP 버전을 위한 단일 대체 테이블도 고려되었지만, RFC 2012와 IPv4 전용 구현 모두에 변경을 요구하게 된다. 별도 테이블은 호환성을 위한 가교였고, 병렬 테이블이 최종 모델이라는 주장이 아니었다. 이후의 갱신이 그 객체들을 흡수할 것으로 예상되었기 때문에, RFC는 자신의 모듈 식별자를 실험용 MIB 하위 트리에 두었다.

IPv6 행에는 익숙한 네 개의 엔드포인트 값이 있었다. 로컬 주소와 포트, 원격 주소와 포트이다. 그러나 하나의 관리 노드에서 IPv6 주소, 특히 링크 로컬 주소는 인터페이스마다 고유하다는 보장이 없었다. 따라서 네 값은 서로 다른 두 개의 스코프 상황을 묘사할 수 있었다. RFC 2452는ipv6TcpConnIfIndex를 이 테이블의 다섯 번째 인덱스로 추가했다. 이는 TCP 패킷의 다섯 번째 필드도, 전송 계층 연결 튜플의 변경도 아니었다. 이 특정 관리 행의 키를 완성한 것이다.

인덱스에는 조건부 의미가 있었다. 원격 주소가 링크 로컬이고 로컬 주소가 아니라면, 그것은 해당 원격 엔드포인트와 같은 링크에 있는 로컬 인터페이스를 식별했다. 그 외의 경우에는 로컬 IPv6 주소와 연관된 인터페이스를 식별했다. 0이 아닌 값은 대응하는 IPv6 인터페이스 인덱스와 같은 인터페이스를 가리켜야 하며, 연결 수명 동안 일정해야 했다.

0은 수수께끼 같은 인터페이스가 아니라 경계였다

RFC는 관련 인터페이스를 결정할 수 없을 때 인터페이스 값이 0이 될 수 있도록 허용했으며,::0같은 와일드카드 로컬 주소가 가능한 경우였다. 0은 불확실성을 유효한 인터페이스 정체로 바꾸지 않았다. 관리 시스템이 알지 못하는 것을 보존했다. 이 구분은 테이블이 근거로 사용될 때 중요하다. 네 개의 엔드포인트 값은 알고 있지만 인터페이스가 불명확한 행은, 고유한 경로나 상대방의 정체, 주소 소유, 애플리케이션 성공을 증명하지 못한다.

행 자체는 임시적이었다. RFC 2452는 각 항목을 현재 연결 정보로 기술하며, TCP가 CLOSED에 진입할 때 또는 그 직후에 존재가 끝난다고 했다. 따라서 MIB 키는 시간적으로 한정된 관찰이었다. 관리자가 살아 있는 행을 참조하는 데 도움이 될 수 있지만, 사람이나 프로세스, 서비스를 위한 내구성 있는 정체는 아니었다.

테이블은deleteTCB(12)를 포함하는 쓰기 가능한 연결 상태 객체를 상속했다. 이는 해당 호스트 측 연결을 종료할 수 있지만, 그 개입 이야기는 RFC 2012와 그 공개된 역사의 몫이다. 여기서는 정밀한 관찰 표면이 민감할 수도 있음을 상기하는 데 그친다. 다섯 번째 인덱스 자체는 쓰기를 승인하지 않으며, 상대방이나 애플리케이션이 무엇을 경험했는지도 증명하지 않는다.

종점을 가진 가교

다음 세대의 MIB는 답의 형태를 바꾸었다. 2005년에 발표된 RFC 4022는 RFC 2012와 RFC 2452를 모두 폐기하고, IP 버전에 독립적인 TCP-MIB를 정의했다. 그것은 IPv6 전용 테이블과 다섯 번째 인덱스를 그대로 보존하는 대신 일반적인 주소 규약을 사용했다. RFC 4001은 존 수식 형태를 포함하는InetAddressType과InetAddress쌍을 제공했고, RFC 4007은 IPv6 스코프와 존을 기술했다. 2017년에는 RFC 8096이 별도로 RFC 2452를 Historic으로 재분류하고, MIB 저장소 유지 관리를 위해 그 구형 모듈을 명시적으로 폐기 형태로 보존했다.

이는 서로 다른 두 가지 수명 주기 사실이다. 통합된 기술적 후속 문서가 먼저 도착했고, 그 후 나중 문서가 IPv6 전용 모듈을 폐기하고 RFC를 Historic으로 표시했다. 어느 단계도 특정 구현이 얼마나 널리 배포되었는지는 증명하지 않는다. 두 단계를 합치면 신중한 전환을 보여준다. 여전히 맞는 의미론은 재사용하고, 새 주소를 표현할 수 없는 부분은 분리하며, 패밀리 중립 모델이 준비되면 임시 분할을 교체한다.

출처