요약

  • RFC 1613은 X.25 가상 회선마다 별도의 TCP 연결을 요구했습니다. 담겨 있는 논리 채널 번호(Logical Channel Number)는 XOT에서 임의적이었으며, 서로 다른 스트림으로 들어오는 두 개의 동일 번호 통화를 구분할 수 없었습니다.
  • XOT 계층은 스트림 식별 정보를 X.25 엔진에 전달해야 했고, 엔진은 발신 로컬 인터페이스에 적합한 채널 번호를 선택했습니다. 따라서 회선 식별은 인터페이스 간 매핑이었으며, 하나의 헤더 필드가 가지는 이식 가능한 속성이 아니었습니다.
  • 명시적 흐름 제어 기능, 로컬 범위의 패킷 유형, 별도의 PVC 설정 교환도 같은 규율을 보여줍니다: 경계를 넘을 수 있는 상태만 보존하고, 다음 동작이 수행되는 지점에서 로컬 호환성을 검증하십시오.

두 통화, 하나의 보이는 번호

게이트웨이가 두 개의 X.25 통화를 수신하는 상황을 상상해 보십시오. 하나는 장치 A에서, 다른 하나는 장치 B에서 옵니다. 두 X.25 헤더는 동일한 논리 채널 번호를 표시합니다. 그 번호만으로 통화를 색인하는 구현은 충돌을 겪게 됩니다. 패킷을 잘못된 상태 머신에 연결하거나, 잘못된 통화를 클리어하거나, 서로 독립적인 두 대화를 하나로 보일 수 있습니다.

번호 자체는 잘못된 것이 아닙니다. 각 송신자는 자신의 인터페이스에서 그 번호를 올바르게 사용했을 수 있습니다. 오류는 수신 게이트웨이에서 발생하는데, 서로 다른 두 인터페이스의 로컬 값이 하나의 네임스페이스에 넣어졌기 때문입니다.

이것이RFC 1613,cisco Systems X.25 over TCP (XOT)에 나오는 구체적 예시입니다.RFC Editor 기록은 이 문서를 1994년 5월로 표기하며 Informational로 분류합니다. 상태 고지는 명확합니다. 이 메모는 인터넷 커뮤니티에 정보를 제공할 뿐 인터넷 표준을 규정하지 않습니다. 이는 보편적 의무나 배포 현황 조사가 아니라 하나의 방법을 문서화한 것입니다.

설계의 답도 마찬가지로 명확했습니다. X.25 가상 회선마다 별도의 TCP 연결을 사용해야 했습니다. X.25 헤더 안의 논리 채널 번호는 XOT 연결에서 아무 의미가 없었고 임의의 값을 가질 수 있었습니다. RFC의 장치 A와 B가 동일한 번호로 장치 C에 통화를 걸 때, C의 X.25 엔진은 패킷이 서로 다른 논리 XOT 인터페이스에서 왔음을 알아야 했습니다. LCN은 그 사실을 제공할 수 없었습니다. XOT 계층이 스트림 식별 정보를 X.25 계층에 전달해야 했습니다.

좁은 교훈은 “더 큰 키를 쓰라”는 것보다 강합니다. 로컬 식별자는 그것이 해석되는 인터페이스와 상태 머신으로부터 의미를 얻는다는 것입니다. 비트를 복사한다고 그 맥락이 함께 수출되지 않습니다.

스트림이 빠진 네임스페이스를 담았다

XOT는 X.25 가상 회선을 설정하기 전에 TCP 연결을 수립했습니다. TCP 포트 1998로의 연결을 요구했고, TCP SYN 안의 XOT 데이터를 금지했습니다. 현재의IANA 서비스명·포트번호 레지스트리는 1998번 TCP 및 UDP에x25-svc-port를 등재하고 있습니다. 이 레지스트리는 조정 기록이며, 개방된 서비스의 관측이 아닙니다. RFC 1613 자체는 TCP 위에서의 방법을 정의합니다.

가상 회선당 하나의 TCP 연결이라는 방식은 스트림을 조회 키의 일부로 만들었습니다. TCP 종단점과 연결 수명은 내부 LCN이 구분하지 못하는 트래픽을 분리했습니다. 그러나 스트림 자체는 인증된 고객, 승인된 통화, 완료된 애플리케이션 교환이 아니었습니다. 기술적 네임스페이스와 운반 상태를 제공했을 뿐입니다. 로컬 정책과 X.25 상태에는 여전히 해야 할 일이 남아 있었습니다.

TCP는 X.25 패킷 경계가 아닌 순서화된 옥텟 스트림을 제공했습니다. 역사적인RFC 793이 그 스트림 서비스를 기술합니다. RFC 1613은 4바이트 XOT 헤더, 즉 16비트 Version 뒤에 16비트 X.25 패킷 길이를 삽입했습니다. Version은 반드시 0이어야 했고, 다른 값이나 불법적인 패킷 길이는 TCP 연결 종료를 요구했습니다.

이 프레이밍은 필요한 맥락이지만, 이야기의 새로운 메커니즘은 아닙니다.RFC 1006은 이미 다른 4옥텟 헤더를 사용해 TCP 위에서 TPDU 레코드를 복원했으며, BTW는 그 경계를 별도로 다루었습니다. 여기서는 패킷이 완벽하게 프레이밍되더라도, 구현이 스트림/인터페이스 맥락을 버리면 잘못된 회선에 연결될 수 있다는 점이 핵심입니다.

발신 인터페이스가 자신의 번호를 썼다

XOT 구현이 TCP로부터 X.25 패킷을 받아 로컬 X.25 인터페이스로 전송할 때, RFC 1613은 발신 인터페이스에서 사용되는 논리 채널 번호를 설정하도록 요구했습니다. 이 규칙은 '필드=식별자' 사고에 대한 이례적으로 명확한 반박입니다. 의도된 가상 회선이 계속되는 동안 번호는 인계 지점에서 바뀔 수 있습니다.

그러므로 방어 가능한 수신 기록은 최소한 네 가지 사실을 결합해야 합니다. 프레이밍된 패킷을 어떤 TCP 연결이 전달했는지; 구현이 그 스트림에 어떤 논리 XOT 인터페이스를 할당했는지; 내부 헤더에 어떤 수신 LCN이 있었는지; 그리고 발신 인터페이스를 위해 어떤 로컬 LCN이 선택되었는지입니다. 내부 번호만 보존하는 로그는 정밀해 보이지만 모호합니다. TCP 종단점만 보존하는 로그는 로컬 X.25 할당을 놓칩니다. 녹색 “전달됨” 플래그는 다음 경계 이상으로 매핑도 결과도 증명하지 못합니다.

여기서 실행 코드가 중요합니다.Lu Heng의 Running-Code Primacy는 상징적 권위보다 로컬에서 검증 가능한 실행에 무게를 둡니다. 이 사례에서 주장은 좁고 검증 가능할 수 있습니다. 이 구현이, 이 시점에, 이 스트림과 논리 인터페이스에서 온 완전한 패킷을 이 발신 채널 상태로 매핑했다는 것입니다. RFC는 상호운용성 규칙을 제공합니다. 구성, 상태 전이, 패킷 관측이 개별 사례를 제공합니다.

기본값은 인터네트워크 경계에서 멈췄다

같은 경계가 통화 설정에도 나타납니다. 일반적인 X.25 네트워크는 기본 패킷 및 창 크기를 가질 수 있었습니다. RFC 1613의 저자들은 TCP/IP 네트워크로 연결되는 다양한 사이트가 하나의 공통 네트워크 기본값을 안전하게 가정할 수 없다고 판단했습니다. 따라서 모든 Call은 패킷 크기와 창 크기 기능을 명시적으로 진술해야 했습니다.

수신한 Call이 그중 하나를 생략했다면, 수용 여부는 로컬 사안으로 남았습니다. Call을 수용하는 구현은 유효 값을 Call Confirm에 넣어야 했습니다. 이것은 모호함이 아니라 책임의 분할이었습니다. 교환은 상호운용에 필요한 최소한의 사실을 전달했고, 로컬 시스템은 자신의 한계가 통화를 허용하는지를 결정했습니다.

흐름 제어는 종단 간일 수도, 로컬일 수도 있었습니다. 로컬 구현은 데이터 패킷을 조각내거나 결합하고 두 인터페이스에서 서로 다른 패킷 시퀀스 번호를 유지할 수 있었습니다. 모듈로-128과 모듈로-8의 혼용은 변환이 필요했으며, 모듈로-8 측에 비해 너무 큰 창은 축소하거나 연결을 거부해야 했습니다. TCP를 통해 전송된 RNR이 반대 방향으로 진행 중인 DATA를 멈추게 한다고 가정할 수 없었습니다.

근거에 대한 함의가 중요합니다. “TCP는 신뢰할 수 있다”는 말로 X.25 창 협상, 패킷 번호 변환, 수신자 준비 상태, 애플리케이션 완료가 정해지지 않습니다. 각각은 서로 다른 계층이 소유한 서로 다른 상태입니다.

어떤 패킷 의미는 이동할 수 있고, 다른 것은 멈춰야 했다

RFC 1613은 Interrupt와 Reset의 종단 간 성격을 유지했으므로, 해당 패킷과 그 확인 응답은 TCP 연결을 넘어갔습니다. Restart, DTE Reject, Diagnostic, Registration 패킷은 로컬 DTE/DCE 인터페이스에서만 의미를 가졌습니다. 이들은 XOT를 넘어서는 안 되었으며, TCP로부터 수신되면 조용히 폐기되었습니다.

캡슐화가 모든 내부 제어 메시지를 이식 가능하게 만들지는 않았습니다. 구현은 어떤 의미가 새 경계를 넘어 살아남는지에 대한 분류 규칙이 필요했습니다. “X.25를 투명하게 터널링한다”는 일반적 약속보다 이 구분이 운영적으로 더 가치 있습니다. 투명성은 조건부였습니다.

영구 가상 회선(PVC)은 이 한계를 더욱 명확히 했습니다. X.25 PVC는 보통 네트워크 사업자가 프로비저닝했기 때문에 존재하며, 이를 동적으로 협상할 Call과 Clear 패킷이 없었습니다. 따라서 XOT는 TCP 수립 직후 비표준 PVC 설정 교환이 필요했습니다. 이 메시지는 응답자가 양쪽 구성이 일치하는지 검사할 수 있도록 인터페이스 이름, 로컬 LCN, 흐름 제어 값을 담았습니다.

상태 공간은 누락되거나 다운된 인터페이스, 비-X.25 인터페이스, 존재하지 않는 PVC, 구성 불일치, 호환되지 않는 흐름 제어, 설정 프로토콜 오류를 구분했습니다. 성공 상태 0 뒤에는 각 로컬 인터페이스에서 Reset이 이어졌습니다. TCP 종료는 XOT PVC를 깨뜨렸습니다. 동시 설정이 두 개의 TCP 연결을 만들면 양쪽으로 트래픽을 보낼 수 없었고, 구현은 하나를 선택하거나 무작위 간격 후 재시도해야 했습니다.

이 상태들은 운영적으로 유용하지만, 어느 것도 사회적 신원이나 비즈니스 결과가 아닙니다. “연결됨”은 한 구현의 설정 머신에서의 상태일 뿐입니다. 계약상 사용자를 식별하지도, 안전한 구성을 증명하지도, 유용한 데이터가 도착했음을 보여주지도 않습니다.

근거 경계

RFC 1613의 보안 절은 보안 문제가 논의되지 않는다고 말합니다. 침묵은 보증이 아닙니다. 이 출처들은 피어 인증, 암호화, 승인, 노출 정책, 주입 및 오바인딩에 대한 저항성을 확립하지 않습니다. 포트 번호, 유효한 Version, 합법적인 길이, 일치하는 LCN, 성공적인 PVC 상태를 그런 속성으로 승격시킬 수 없습니다.

이 보고서를 위해 XOT 구현, Cisco 릴리스, 사업자 네트워크, 캡처된 세션은 어떤 것도 테스트되지 않았습니다. 기존 구현이 종단 간 흐름 제어를 사용했다는 1994년의 진술은 메모 안의 당시 주장이며 현재의 지원 매트릭스가 아닙니다. IANA 등재 행은 수신 대기 중인 서비스를 증명하지 않습니다. 이 RFC는 현재의 배포, 보급률, 사고 이력, 애플리케이션 완료, 현대 오버레이와의 직계 관계를 확립하지 않습니다.

확립된 결론은 의도적으로 더 작습니다. 필드는 유효하면서도 운영자가 관심을 가지는 대상을 식별할 만큼의 범위를 갖지 못할 수 있습니다. RFC 1613은 공통 와이어 규칙을 좁게 유지하고, 스트림 식별 정보를 구현 접합부를 넘어 전달하며, 각 로컬 인터페이스가 실제로 준수할 수 있는 번호를 할당하도록 했습니다. 회선이 살아남은 것은 시스템이 필드가 담을 수 없는 경계를 보존했기 때문입니다.

출처