요약

  • PPP Configure-Ack은 제안을 개선하거나 재배열하거나 재해석할 수 없었습니다. 최신 Configure-Request를 그대로 반복해야 했고, 수용이 추론이 아니라 바이트 수준의 증거가 되었습니다.
  • 링크 제어 프로토콜(LCP)의 합의는 쌍방이었습니다. 각 단말은 주로 자신의 수신 방향에 대해 협상했으며,Opened상태가 되려면 Ack를 보내고 받는 것이 모두 필요했습니다. Nak는 다른 값을 제안했고, Reject는 나열된 옵션에 대한 협상을 종결했습니다.

숫자 하나를 바꾼 수용은 수용이 아니었다

한 단말이 명시된 최대 수신 단위(MRU)보다 크지 않은 프레임을 받고 싶다고 요청한다고 상상해 보십시오. 상대는 아이디어는 좋다고 여기지만 Configure-Ack에 약간 다른 크기를 적어 넣습니다. 사람 눈에는 합리적인 타협처럼 보일 수 있습니다. PPP에게는 유효하지 않은 응답입니다.

RFC 1661은 유효한 Configure-Ack이 최신 요청의 Identifier를 복사하고 옵션들을 수정 없이 같은 순서로 재현할 것을 요구합니다. 모든 옵션은 이미 인식 가능하고 수용 가능해야 합니다. 수신자는 수용할 수 있지만, 수용하면서 편집할 수는 없습니다.

이 엄격함은 분산 상태 문제를 해결했습니다. Ack가 개선 사항을 담을 수 있었다면 송신자는 응답이 자신의 요청을 수용한 것인지, 대체한 것인지, 우연히 제3의 구성을 기술한 것인지 판단해야 했을 것입니다. 패킷 손실과 교차 메시지는 그 추측을 더 어렵게 만듭니다. 대신 정확한 반복은 양쪽에 하나의 좁은 검증 기준을 줍니다. 이 바이트가 수용된 제안이라는 것입니다.

Identifier는 응답을 하나의 시도에 묶습니다. 옵션 내용이 바뀌고 앞선 요청에 유효한 응답이 있은 뒤에는 바뀌며, 재전송은 같은 값을 재사용할 수 있습니다. 이 숫자는 상대를 인증하지 않습니다. 구성에 관한 한 대화가 다른 대화로 오인되는 것을 막을 뿐입니다.

대안 제안에는 다른 동사가 필요했다

PPP는 모든 불일치를 거부로 몰지 않았습니다. Configure-Nak는 이해되고 협상 가능하지만 수용할 수 없는 값을 담은 옵션을 위해 존재합니다. Nak는 수용 불가능한 옵션들을 나열하고 그 값을 자신이 수용할 수 있는 값으로 바꿔 제시할 수 있으며, 요청자가 생략한 자신에게 필요한 옵션을 요구할 수도 있습니다.

이 응답은 편집된 Ack가 아닙니다. 회선상의 미완료 요청을 바꾸지 않고 제안된 값을 유효하게 만들지도 않습니다. 요청자는 새 Configure-Request를 보낼지 결정해야 합니다. 새로운 내용에는 새 Identifier가 부여되어 정확히 수용될 수 있는 새로운 제안이 만들어집니다.

Configure-Reject는 더 단단한 경계를 표현합니다. 옵션이 인식되지 않거나 로컬 정책상 협상 대상이 아닐 때 적용됩니다. 거부된 옵션은 선호하는 대체물로 다시 쓰이지 않고 요청에서 그대로 복사됩니다. 다음 시도에서 요청자는 그 옵션을 제거해야 합니다.

이 구분은 권위를 담습니다. Nak는 “이 질문을 이해하며 다른 범위라면 동의할 수 있다”고 말합니다. Reject는 “이 단말이 협상할 질문이 아니다”라고 말합니다. 제안할 대체 값이 없는 불리언 옵션은 Reject를 사용합니다. 어떤 응답도 상대가 로컬 정책을 몰래 바꾸도록 허락하지 않습니다.

하나의 회선 안에 두 개의 협상이 있었다

“링크를 협상한다”는 표현은 단수처럼 들립니다. LCP는 이를 양방향으로 만들었습니다. 옵션이 달리 규정하지 않는 한, 옵션은 반 이중(half-duplex) 방식으로 적용되며, 일반적으로 Configure-Request 송신자 기준의 수신 방향에 적용됩니다. 단말 A는 B로부터의 트래픽을 어떻게 받을 준비가 되어 있는지 제안합니다. 단말 B는 반대 방향 트래픽에 관해 자신의 요청을 보냅니다.

두 제안은 교차할 수 있습니다. A는 자신의 요청에 대한 정확한 Ack를 받으면서도 B의 요청을 Ack, Nak 또는 Reject할지 아직 결정하는 중일 수 있습니다.RFC 1171은 이미 그 상태를Ack-Received로 명명했습니다. 즉 Ack가 도착했지만 단말이 아직 하나를 보내지는 않은 상태입니다. 수신한 동의가 반대 방향의 동의를 만들어내지는 않았습니다.

RFC 1331에 이르면 링크 수립 규칙이 명시적이 되었습니다. LCP가Opened에 도달하는 것은 Configure-Ack를 보내고 받은 뒤에만 가능합니다. 따라서 한 피어가 구성을 선언하고 물리적 연결을 일방적으로 열린 PPP 링크로 바꿀 수 없습니다. 각 측은 자신의 방향에 대해 무엇을 제안하고 상대의 것을 무엇을 수용할지 통제합니다.

이것은 겉보기 대칭이 아니었습니다. 수신 용량은 다를 수 있습니다. 한 쪽은 인증을 요구하고 다른 쪽은 그렇지 않을 수 있습니다. 압축 지원이나 비동기 제어 문자 처리가 일치하지 않을 수 있습니다. 요청을 분리하면 기계들이 동일하다고 가정하지 않고도 공통 링크가 존재할 수 있습니다.

기본값 덕분에 생략이 의미를 가졌다

Configure-Request는 단말의 전체 목록이 아니라 표준 기본값에서의 변경 사항을 담습니다. RFC 1661은 기본값을 갖는 옵션은 포함하지 말아야 한다고 말합니다. 옵션이 없으면 정의된 기본값이 적용됩니다.

이 선택은 공유 언어를 작게 유지했지만, 기본값을 증거의 일부로 만들었습니다. 명시적 옵션만 기록한 운영자는 실제 링크를 재구성할 수 없습니다. 협상된 상태는 수용된 요청에 적용 가능한 모든 기본값을 올바른 방향으로 해석해 더한 것입니다.

옵션들은 함께 평가됩니다. Ack는 정렬된 전체 목록을 한 번에 수용합니다. Nak는 수용 가능한 옵션을 걸러내고 분쟁 중인 것들을 보고합니다. Reject는 참여할 수 없는 옵션들을 보고합니다. 이를 통해 상호 교환이 피어가 자신이 갖춘 모든 기능을 수용하거나 모든 로컬 선호를 노출하도록 강요받지 않고서도 원자적 의미를 갖습니다.

제어 언어는 압축을 둘러싼 불일치를 견뎠다

협상은 이후 패킷들이 사용할 프레임 자체를 바꿉니다. 이는 부트스트래핑 함정을 낳습니다. 한 단말이 어떤 옵션이 효력을 가졌다고 믿고 필드를 압축하기 시작하는 동안 상대가 여전히 기본 프레임을 읽고 있다면, 불일치를 수습하는 데 필요한 패킷조차 읽을 수 없게 될 수 있습니다.

RFC 1548과 RFC 1661은 이 함정에서 빠져나오는 통로를 보존합니다. LCP 구성, 종료, Code-Reject 패킷은 어떤 구성 옵션도 활성화되지 않은 것처럼 전송됩니다. 주소, 제어, 프로토콜 필드 압축은 그 제어 패킷 집합에는 적용되지 않습니다.

안정적인 인코딩이 피어들의 합의를 증명하지는 않습니다. 불일치가 계속 보이는 언어를 보존할 뿐입니다. 데이터 평면의 효율은 제어 평면이 기본값으로 돌아갈 수 있는 인식 가능한 경로를 확보한 뒤에야 허용됩니다.

침묵과 무한한 흥정에도 한계가 있었다

PPP가 통과하도록 설계된 링크에서는 손실이 일상입니다. 따라서 Configure-Request는 재시작 타이머와 카운터를 사용합니다. RFC 1661은 Max-Configure를 구성 가능하게 요구하고, 상대가 응답 불능으로 간주되기 전에 10회 전송을 권고합니다.

응답이 도착하더라도 수렴하지 못할 수 있습니다. 명세는 별도의 Max-Failure 카운터를 권고하며 기본값은 5입니다. Ack 없이 Nak가 반복되면 상대가 요청한 옵션에 대한 추가 Nak는 Reject로 바뀌고, 수신자는 자신이 원하는 옵션을 더 이상 붙이지 않습니다.

이는 영원히 협상하지 않겠다는 주목할 만한 거부입니다. 제안은 새로운 제안으로 이어질 수 있을 때만 유용합니다. 반복되는 대안 제안이 수용 가능한 상태를 만들지 못하면, 하나의 미해결 선호가 링크를 무한히 붙잡게 두는 것보다 옵션 집합을 좁히는 편이 안전합니다.

타이머와 카운터는 악의, 비호환성, 물리적 고장을 증명하지 않습니다. 불확실한 증거가 상태 기계를 얼마나 오래 점유할 수 있는지에 대한 한계를 둘 뿐입니다. 소진된 카운터는 시도를 멈출 로컬에서 관찰 가능한 이유이지, 상대 단말에 대한 전역적 판정이 아닙니다.

링크 합의는 네트워크 준비 상태가 아니었다

네 가지 구성 코드는 1989년 11월RFC 1134에 등장해 RFC 1171, RFC 1331, RFC 1548, 그리고 1994년 7월의 최종 기본 표준까지 이어졌습니다. 진화하는 문서들은 계층적 절차도 명확히 했습니다.

먼저 하위 계층이 물리 경로가 사용 가능하다고 보고합니다. 그다음 LCP가 링크 독립적인 매개변수를 수립합니다. 인증 프로토콜이 협상되었다면 인증이 뒤따릭니다. 이후 네트워크 제어 프로토콜(NCP)이 IP 같은 각 네트워크 계층 프로토콜을 독립적으로 구성합니다. 관련 NCP가Opened에 도달한 뒤에만 그 네트워크 계층의 트래픽이 링크를 사용할 수 있습니다.

따라서 Configure-Ack은 녹색 상태등이 암시하는 것보다 훨씬 적은 것을 증명합니다. 신원, 성공한 인증, IP 주소 구성, 경로 가용성, 애플리케이션 도달성을 증명하지 않습니다. 응답한 단말이 하나의 정확한 LCP 제안을 수용 가능하다고 판단했다는 것만 증명합니다.

현재IANA PPP 레지스트리는 여전히 Configure-Request, Ack, Nak, Reject를 코드 1에서 4로 기록하고 옵션 네임스페이스를 관리합니다. 등록은 공통 어휘를 보존합니다. 현재 사용 현황 조사도, 모든 구현이 상태 기계를 올바르게 적용한다는 증거도 아닙니다.

얇은 합의가 서로 다른 기계의 상호운용을 가능하게 했다

PPP의 구성 교환은 “합의”를 모호하게 만들기를 거부함으로써 성공했습니다. 수용은 바이트 단위로 정확한 형태를 가졌습니다. 대안 제안과 거부는 서로 다른 형태를 가졌습니다. 방향은 별도의 상태를 가졌습니다. 시간과 반복에는 명시적 한계가 있었습니다. 이후 계층은 자신의 준비 상태를 스스로 증명해야 했습니다.

중앙 조정자가 보편적인 프레임 크기, 인증 방식, 압축 정책을 선택하지 않았습니다. 어느 단말도 상대에 대한 명령권을 얻지 않았습니다. 공유 표준은 양쪽 기계가 로컬에서 검증할 수 있는 소수의 진술을 부여하면서, 각 단말의 요구 사항은 그 단말 자신이 책임지도록 남겼습니다.

바로 이것이 작은 네 개의 패킷 코드 안에 숨어 있던 제도적 성과입니다. 상호운용은 한 기계의 승리를 필요로 하지 않았습니다. 모든 응답이 자신의 증거가 지탱할 수 있는 이상의 권위를 담지 않는 것을 필요로 했습니다.

출처와 한계

RFC 1134, RFC 1171, RFC 1331, RFC 1548, RFC 1661은 프로토콜의 공개된 진화, 패킷 문법, 방향 모델, 단계, 수렴 한계를 확립합니다. IANA 레지스트리는 현재 할당 현황을 확립합니다. 이 출처들은 현대 배포 점유율, 벤더 적합성, 통신사 관행, 성능 향상, 보편적인 운영 타임아웃을 확립하지 않습니다. 정확한 반복을 얇은 쌍방 권위로 해석하는 것은 메커니즘으로부터의 추론입니다.