요약

  • RFC 1473는 PPP 위의 IP 제어 프로토콜을 위해 구성 테이블과 운영 테이블을 각각 마련했습니다. 관리자가 open을 기록하는 것은 IPCP 상태 머신에 이벤트를 주입하는 것일 뿐, 실제로 Opened에 도달한다는 보장이 아닙니다.
  • 압축 기호는 다음 링크 재시작 시점에 비로소 효력이 발생합니다. 협상이 완료되기 전에는 테이블이 반환하는 압축 방식과 슬롯 값이 명확히 "미정의" 구간에 놓이며, 협상이 완료된 뒤에도 이 값들은 매개변수를 설명할 뿐 IP 패킷이 도착했다는 영수증이 아닙니다.

1993년 6월에 발표된RFC 1473은 매우 짧습니다. PPP 관리를 모든 것을 담는 대시보드로 만들지 않고, IP Network Control Protocol에 대해 장애 및 구성 관리에 꼭 필요한 소수의 객체만 남겼습니다. 디버깅 전용 항목은 제외되었고, 다른 곳에서 도출할 수 있는 값은 반복하지 않았습니다.

이러한 절제는 인터페이스가 흔히 지워버리는 시간 차를 규격 안에 그대로 기록했습니다. 원하는 상태, 이미 협상된 상태, 그리고 회선에서 실제로 흐르는 트래픽은 같은 것이 아닙니다.

open은 입력이지 결론이 아니다

구성 테이블의 pppIpConfigAdminStatus는 "즉시 도달하기를 희망하는" 상태를 나타냅니다. open을 기록하면 IPCP 유한 상태 머신에 관리 Open 이벤트가 주입되고, close를 기록하면 Close 이벤트가 주입됩니다.

"이벤트 주입"은 "열기 성공"보다 훨씬 정확한 표현입니다. 에이전트가 기록을 수락했다는 것은 요청이 관리 인터페이스에 들어갔음만 증명합니다. 상태 머신은 그 다음에 하위 링크, 상대 측 응답, 옵션 수용 가능 여부, 타임아웃을 처리해야 합니다. HTTP나 SNMP의 성공 응답이 프로토콜이나 상대 측을 대신해 결정을 내려 주지는 않습니다.

이후의RFC 1661도 이 구분을 그대로 유지합니다. 각 네트워크 계층 프로토콜은 자신만의 NCP로 구성되며, 독립적으로 Opened 또는 Closed 상태에 있을 수 있습니다. 같은 PPP 링크에서 IPCP가 실패했다고 해서 다른 NCP도 실패한 것은 아닙니다.

새 값은 먼저 대기 구간으로 들어간다

또 하나의 쓰기 가능 객체인 pppIpConfigCompression은 이 측이 다음에 협상하려는 방식을 지정합니다. 압축 없음, 또는 Van Jacobson TCP/IP 헤더 압축입니다. RFC 1473는 이 값이 현재 세션을 즉시 바꾼다고 말하지 않고, 변경 사항은 링크의 다음 재시작 시점에 효력을 갖는다고 명시합니다.

따라서 기록 이후의 새 값은 미래의 기호일 뿐입니다. 그것이 운영 사실로 바뀌었음을 증명하려면 최소한 네 장의 영수증이 필요합니다. 에이전트가 실제로 값을 저장했는지, 어느 재시작이 발생했는지, 그 재시작 이후의 IPCP 교환이 무엇을 제안했는지, 최종 상태가 무엇인지입니다.

RFC 1332는 그 바탕이 되는 IPCP 협상을 정의합니다. IP-Compression-Protocol은 기본적으로 압축을 사용하지 않으며, 양방향 압축은 양쪽이 각각 수신 능력을 요청해야 합니다. 한쪽이 압축 패킷을 받을 의사가 있다고 해서 반대 방향도 같은 결과를 얻은 것은 아닙니다.

미정의는 "다소 오래된 것일 수 있음"이 아니다

운영 테이블은 pppIpOperStatus와 함께 로컬에서 원격으로, 원격에서 로컬로의 두 방향에 대한 압축 프로토콜과 Max-Slot-Id를 제공합니다. RFC 1473는 이어서 제한을 둡니다. 이 옵션 매개변수들은 PPP 옵션 협상이 완료되고 IPCP가 Opened에 도달한 뒤에만 사용 가능합니다.

그 이전에는 내용이 미정의이며, 실제로 무엇을 반환할지는 구현이 결정합니다.

이것은 흔한 "데이터가 오래되었을 수 있음"과 다릅니다. 오래된 값이라도 적어도 과거의 어떤 상태를 기술했었습니다. 미정의 값은 그런 의미조차 짊어지지 않습니다. 0, 기본값, 잔존값 또는 구현자가 고른 어떤 자리표시자든 될 수 있습니다. 형식 검사가 완벽히 통과하더라도, 이 값을 협상 증거로 격상시킬 수는 없습니다.

Opened에 들어간 뒤에도 방향을 유지해야 합니다. local-to-remote는 이 측이 전송할 때 사용하는 방식을, remote-to-local은 반대 방향을 기술합니다. VJ 압축을 사용하지 않는다면 슬롯 값은 0이어야 하고, 상태가 아직 Opened가 아니라면 0 자체가 "압축 없음으로 협상됐다"는 증명이 되지 않습니다.

Opened는 여전히 한 개의 패킷이 아니다

RFC 1332는 PPP가 네트워크 계층 프로토콜 단계에 들어가고 IPCP가 Opened에 도달해야 IP 패킷이 통신할 수 있다고 규정합니다.RFC 1661은 해당 NCP가 Opened되지 않은 상태에서 수신한 네트워크 계층 패킷은 반드시 폐기해야 한다고 규정합니다.

따라서 Opened는 중요한 관문이지만, 여전히 상태 머신의 사실일 뿐입니다. 어떤 패킷이 전송되었는지, 카운터가 증가했는지, 압축 헤더가 올바르게 복원되는지, 라우트가 존재하는지, 그리고 애플리케이션 계층의 응답이 있는지는 밝히지 않습니다.

RFC 1144는 저속 직렬 링크에서 TCP/IP 헤더 압축의 가치를 설명합니다. 이 능력을 협상할 수 있다는 것이 어떤 패킷이든 압축에 적합하다는 뜻이 아니고, 압축 패킷이 나타났다는 것이 상대 측이 올바르게 재구성했다는 뜻이 아니며, 올바르게 재구성되었다는 것이 업무가 결과를 얻었다는 뜻도 아닙니다.

관리 뷰는 이 경계를 유지해야 한다

RFC 1473는 쓰기 가능한 구성을 별도의 테이블에 두어 서로 다른 관리 뷰로 분류하기 쉽게 만들었습니다. 보안 논의는 PPP 구성과 제어 자체에 위험이 있음을 상기시키며, 읽기 전용 구현, 보호된 뷰 또는 접근 차단으로 권한을 강화할 수 있습니다. 함께 묶인RFC 1471은 LCP를,RFC 1472는 인증 구성을 다룹니다. 이 문서군은 모든 것을 설명하는 녹색 표시등이 존재하는 것처럼 가장하지 않습니다.

신뢰할 수 있는 변경 기록은 이어져야 합니다. 누가 압축 변경을 제안했는지, 에이전트가 어느 세대의 구성을 저장했는지, 그것이 어느 재시작에 해당하는지, 양 방향이 각각 무엇을 제안하고 수락했는지, IPCP가 언제 Opened에 들어가고 나갔는지, 그 이후 어떤 패킷·오류·애플리케이션 영수증이 있었는지입니다.

마지막 숫자 하나만 남기면, 재시작을 기다리는 기호가 이미 온라인에 적용된 것처럼 보이고, 미정의 읽기 값이 이미 측정된 것처럼 보이며, Opened가 트래픽이 이미 전달된 것처럼 보입니다.

RFC 1473가 남긴 관리 상식은 이렇습니다. 시스템은 이미 성립한 사실을 표시할 뿐 아니라, 사실이 아직 성립하지 않은 구간도 명확히 표시해야 합니다.

출처