요약

  • Opened 상태의 LCP 링크가 모든 PPP 프로토콜 값을 지원한다는 의미는 아니었습니다. 알 수 없는 값은 LCP 코드 8 Protocol-Reject로 처리해야 했습니다.
  • 응답에는 2옥텟의 Rejected-Protocol과 유발 패킷의 정보 중 MRU로 제한된 일부가 담겨, 전체 프레임을 재현한다고 주장하지 않으면서 거부 범위를 특정할 수 있었습니다.
  • 일반 NCP의 거부는 정상 운영 범위 내의 RXJ+ 사건이 될 수 있었습니다. LCP 자체의 거부는 RXJ-였습니다. 장애를 포함하는 데 필요한 공유 제어 언어 자체가 거부되었기 때문입니다.

링크가 합의된 이후에 시작된 불일치

PPP는 점대점 링크를 한 종류의 네트워크 패킷만 위한 통로로 정의하지 않았습니다. 1989년에 발표된RFC 1134는 여러 네트워크 계층 프로토콜의 데이터그램을 같은 종류의 링크로 전송하는 방안을 제안했습니다. Link Control Protocol이 공통 운반체를 확립하고 관리했습니다. 일련의 Network Control Protocol이 그 위에 놓이는 개별 네트워크 계층 용도를 구성했습니다.

이 분리 덕분에 부분적 모순이 가능해졌습니다. 두 피어가 LCP를 열어 둔 상태에서 한쪽이 상대방이 구현하지 않은 PPP Protocol 필드 값을 보낼 수 있었습니다. 수신자는 PPP 프레임을 충분히 이해해 타입을 찾아냈습니다. 그 타입에 대한 처리기만 없었던 것입니다.

초기 사양은 이 조건을 전체 링크 실패로 축소하지 않았습니다. LCP가 Open이면 수신자는 코드 8의 Protocol-Reject를 담은 LCP 패킷을 보내 수신한 프로토콜을 식별해야 했습니다. 멀티플렉스된 한 점유자가 입장을 거부당했을 뿐, 공통 링크에는 여전히 그 이유를 보고할 언어가 있었습니다.

1992년RFC 1331은 이 구분을 더 명확히 했습니다. 지원되는 프로토콜이 도착했지만 해당 NCP가 Opened가 아니면 조용히 폐기되었습니다. 반면 알 수 없는 Protocol 값은 LCP가 Opened인 동안 Protocol-Reject를 요구했습니다. 첫 번째는 단계의 문제, 두 번째는 능력의 문제였습니다.

따라서 침묵은 별로 증명하지 못했습니다. LCP가 Opened가 아니거나, NCP가 Opened가 아니거나, 패킷이 손실되었거나, 구현이 규격에 부합하지 않을 수 있었습니다. 가시적 거부도 더 좁은 증거였습니다. 그 자체로 물리적 단절, 인증 실패 또는 모든 네트워크 계층 서비스의 상실을 증명하지 않았습니다. 확립된 LCP 문맥 안에서의 타입이 지정된 비호환성만을 증명했습니다.

코드 8은 같은 크기 계약 아래에서 증거를 돌려보냈다

RFC 1661의 성숙한 패킷은 코드 8로 시작합니다. Identifier는 보내는 각 Protocol-Reject마다 달라져야 합니다. Rejected-Protocol은 정확히 2옥텟을 차지하며 거부된 패킷의 PPP Protocol 필드를 담습니다.

Rejected-Information은 그 패킷의 Information 필드로 시작합니다. 데이터 링크 계층 헤더와 프레임 검사 시퀀스는 제외됩니다. 또한 피어가 확립한 최대 수신 단위(MRU)를 지키도록 잘려야 했습니다. 오류 보고라고 해서 수신자가 협상한 한도를 넘을 권한을 얻지는 못했습니다.

그 결과는 자극을 식별할 만큼의 문맥을 돌려보내는 것이었지 완전한 포렌식 복제본이 아니었습니다. 링크 계층 필드는 정의상 없었고 정보는 MRU 경계에서 끝날 수 있었습니다. Identifier는 영구 사건 번호도 보편적 상관 토큰도 아니었습니다. Protocol-Reject는 유형화되고 제한된 증거를 제공했습니다. 이 프로토콜 값이 거부되었고, 그 정보 중 이만큼이 제어 응답에 들어갔다는 것입니다.

RFC 1548은 1993년에 이 메커니즘을 유지했고, RFC 1661은 1994년에 이를 안정화했습니다. 이 연속성은 제한된 부정적 증거가 PPP 성숙 아키텍처의 일부였음을 보여줍니다. 그러나 모든 제품이 이 동작을 올바르게 구현했다는 뜻은 아닙니다.

보내는 쪽이 멈출 의무를 물려받았다

Protocol-Reject를 받으면 RFC 1661은 구현체가 가능한 한 조기에 해당 프로토콜의 패킷 전송을 멈추도록 요구합니다. 이 표현은 이미 큐나 링크에 들어간 작업을 위한 여지를 남깁니다. 명시적 능력 거부를 무기한 재시도의 초대로 바꾸지는 않습니다.

NCP 계열은 그 범위를 구체화합니다.RFC 1332는 PPP 위에서 IP를 확립·구성하기 위한 IPCP를 정의하고,RFC 5072는 IPv6CP를 정의합니다. 이들은 별개의 제어 프로토콜의 예시이며, 특정 관찰된 링크에서 어느 쪽이 활성이었다는 증거가 아닙니다.

한 NCP가 거부되면 LCP가 Opened로 남아 있다는 이유만으로 그 네트워크 계층 서비스를 이용 가능하다고 볼 수 없었습니다. 다른 프로토콜은 별도로 지원되고 올바르게 구성된 경우에만 계속될 수 있었습니다. 포함은 다른 서비스의 가능성을 보전했을 뿐, 대안을 만들어 내지는 않았습니다.

Protocol-Reject는 LCP Opened 상태에서만 보낼 수 있었습니다. 다른 LCP 상태에서 수신된 Protocol-Reject는 조용히 폐기해야 했습니다. 상태 규칙은 권한 경계였습니다. 거부는 양쪽이 메시지를 의미 있게 만드는 제어 문맥을 공유한 뒤에야 피어를 지시할 수 있었습니다.

같은 거부가 두 심각도 계층을 넘었다

RFC 1331은 허용된 거부를 RXJ+로 분류했습니다. NCP의 Protocol-Reject가 그 명시적 예였습니다. 이 사건은 정상 운영 범위 안에 속했습니다. 구현체가 문제의 패킷 타입을 멈추되 LCP는 종료할 필요가 없었습니다.

RXJ-는 재앙적이었습니다. LCP 자체의 Protocol-Reject는 연결을 종료시키는 복구 불가능한 오류였습니다. 코드 8 패킷의 형태는 바뀌지 않았습니다. 바뀐 것은 대상의 계층이었습니다.

NCP는 LCP가 그 제거를 설명할 수 있게 남아 있는 동안 제거될 수 있었습니다. 만약 피어가 지원하지 않는다고 주장한 프로토콜이 LCP 자신이라면, 양 끝점은 더 이상 링크를 구성·시험·닫는 데 쓰이는 언어를 공유하지 않게 됩니다. 장애를 국소화하던 메커니즘이 그 자체로 장애가 된 것입니다.

이 때문에 “링크가 계속 열려 있었다”는 의도적으로 좁은 결과입니다. 거부된 NCP에 의존하는 응용은 LCP가 Opened로 남아 있는 동안에도 완전한 서비스 불가를 겪을 수 있었습니다. 운반체의 연속성과 서비스의 연속성은 서로 다른 측정이었고, 프로토콜은 이 둘을 같게 하겠다고 약속한 적이 없습니다.

레지스트리는 숫자를 해독했을 뿐 배포된 능력을 증명하지 않는다

현재IANA PPP Numbers 레지스트리는 LCP 코드 8을 Protocol-Reject로 나열하고 PPP Protocol 필드의 할당을 기록합니다. 이는 숫자에 대한 권위 있는 이름을 제공합니다. 그러나 어떤 기기가 할당된 프로토콜을 구현하는지, 어떤 NCP가 Opened에 도달했는지, 트래픽이 실제로 운반되는지, 현존하는 네트워크가 이 기능을 여전히 사용하는지는 증명하지 않습니다.

RFC 3818은 PPP 이름 공간의 할당 정책을 IETF 합의 절차로 개정했습니다. 이는 확장 가능한 프로토콜 계열에 대한 거버넌스를 보여줄 뿐, 배포를 증명하지 않습니다. 운영상의 주장에는 레지스트리 해독, 구성, 상태, 패킷 증거 그리고 거부 이후의 행동이 필요합니다.

따라서 Protocol-Reject의 역사는 소박한 형태의 정직함에 달려 있습니다. 피어는 전체 링크가 사라졌다고 가장하지 않고, 자신이 무엇을 모르는지 정확히 말할 수 있었습니다. 그 진술은 타입이 지정되고, 협상된 수신 한도로 제한되며, 올바른 LCP 상태로 한정되고, 어느 계층이 거부되었는지에 따라 해석되었기 때문에 안전했습니다.

출처