요약

  • RFC 2509에서 물려받은TCP_SPACE와NON_TCP_SPACE필드에서 0은 최대 컨텍스트 식별자였으므로, 여전히 하나의 컨텍스트(식별자 0)를 나타냈다.
  • RFC 3544의 3옥텟 서브옵션 3는 대신 TCP 또는 non-TCP 컨텍스트 수를 0으로 설정하여 기존 필드를 재정의하고 해당 트래픽 클래스를 비활성화할 수 있었다.

필드 이름이 개수처럼 들렸기 때문에 이 불일치는 놓치기 쉬웠다. 실제로는 개수가 아니었다.TCP_SPACE와NON_TCP_SPACE는 최대 컨텍스트 식별자, 즉 번호가 매겨진 공간에서 가장 큰 값을 인코딩했다. 그 최댓값이 0이라도 공간에는 여전히 CID 0이 포함되었다. 즉 컨텍스트 하나가 사용 가능한 상태로 남았다. 이는 최소 구성에 유용했지만, 이 필드들만으로는 "이 클래스는 전혀 압축하지 않음"을 표현할 방법이 없었다.

2003년 7월에 Proposed Standard로 발표된 RFC 3544는 이 레거시 의미를 다시 정의하지 않으면서 RFC 2509의 PPP 협상 옵션을 갱신했다. 서브옵션 3가 빠져 있던 구분을 제공했다. 타입은 3, 길이는 3옥텟이며, 1옥텟 파라미터가 비활성화할 컨텍스트 패밀리를 선택한다: 값 1은 TCP 컨텍스트 0개, 값 2는 non-TCP 컨텍스트 0개를 의미한다. 서브옵션은 대응하는TCP_SPACE또는NON_TCP_SPACE값을 재정의한다. 두 파라미터 값을 모두 포함하면 모든 패킷에 대해 압축이 비활성화된다.

이것은 0을 재해석한 것이 아니라 명시적인 재정의를 통한 호환성 복구였다. 구현은 기존 필드의 확립된 의미를 유지하면서 그 필드가 담을 수 없었던 답을 수신할 수 있었다. 이 제안이 중요한 이유는 정확히 말하면 그럴듯해 보이는 값이 이미 다른 유효한 의미로 점유되어 있었기 때문이다: 그 의미를 바꾸면 구형 피어들이 동일한 비트에 대해 서로 모순되는 해석을 하게 된다.

설정은 두 개의 NCP를 거쳐 전달된다

PPP는 Network Control Protocol을 사용해 링크 파라미터를 협상한다. RFC 3544는 IPv4의 IPCP와 IPv6의 IPV6CP에 동일한 압축 옵션 형식을 정의한다. 각 NCP는 외부 네트워크 헤더가 해당 버전인 패킷에 대한 파라미터를 설정한다. 따라서 "IPv4 압축 협상됨"과 "IPv6 압축 협상됨"은 하나의 범용 스위치가 아니라 별개의 제어 평면 결과다.

한 가지 더 고려할 점이 있다: NCP 파라미터 값은 독립적으로 협상되지만 IPv4와 IPv6는 컨텍스트 식별자 공간을 공유한다. 두 값이 다를 경우 압축 엔진은 공용 풀에서 할당해야 하며, 디컴프레서는 패킷을 해석하기 위해 컨텍스트 상태를 사용해야 한다. 반면 TCP와 non-TCP/UDP/RTP는 컨텍스트 공간을 공유하지 않는다. 이들은 프로토콜이 명시한 구현 제약일 뿐, 특정 피어가 이를 구성했거나 실제로 사용했다는 증거가 아니다.

RFC 3544는 또한 타입 2의 향상된 RTP 협상 서브옵션을 추가했으며, 이는 기존 RTP 서브옵션 1과 병용되는 것이 아니라 그를 대체하여 사용된다. 9개의 PPP 프로토콜 필드 값과 함께, 이 옵션들은 수신기에 프레임이 어떻게 분류되는지와 어떤 협상된 형식이 사용될 수 있는지를 알려준다. 프로토콜 필드가 디멀티플렉싱 표면이고, 서브옵션은 구성 의도다.

협상된 옵션이 보여주지 않는 것

이 RFC의 옵션은 협상이 성공한 뒤 명명된 프로토콜 식별자의 사용을 가능하게 한다. 하지만 그것은 어떤 구현이 실제로 압축된 프레임을 보냈는지, 반대편이 이를 디코딩했는지, 데이터그램이 전달되었는지, 패킷이 실제로 작아졌는지는 보여주지 않는다. 이들은 경로상의 서로 다른 지점에서의 서로 다른 관찰이다. 구성 교환은 합의된 파라미터 집합에 대한 증거이지 트래픽 영수증이 아니다.

문서는 인접한 한 가지 모호성에 대해 신중하다: RFC 1332는 옵션이 송신자의 능력을 기술하는지 수신자의 능력을 기술하는지 명시하지 않는다. RFC 3544는 기존 관행에 따라, Config-Req가 송신 피어의 디컴프레서를 기술한다고 가정한다고 말한다. 이 문장은 명시적인 가정이며 RFC 1332에 대한 새로운 규범적 명확화가 아니다. 이를 더 강한 주장으로 취급하면 명세서 자체의 단서를 지워버리게 된다.

데이터 경로에는 자체 조건이 있다. IPHC는 TCP와 RTP에 델타 인코딩을 사용하며, 델타 코딩된 패킷은 양쪽 끝의 컨텍스트에 의존한다. PPP 자체는 패킷을 재정렬하지 않으므로 재정렬 방지 장치는 기본적으로 비활성화되어 있다. 멀티클래스 Multilink PPP 또는 다른 재정렬 메커니즘이 사용될 경우, 동일한 압축 컨텍스트를 공유하는 패킷은 재정렬되어서는 안 된다. 형식을 협상하는 것만으로 이 전송 계층 제약이 사라지지 않는다.

역사적 교훈은 소박하다: 프로토콜 진화는 때때로 두 번째 신호를 필요로 하는데, 그 이유는 직관적으로 보이는 값이 이미 유효한 구 의미를 갖고 있기 때문이다. RFC 3544는 필드를 안정적으로 유지하고, 재정의를 추가했으며, 능력, 패킷 사용, 디코딩, 전달, 성능을 각각 별도로 검증해야 할 주장으로 남겨두었다.

출처