요약

  • RFC 1474는 브리지 미디어 상태를 PPP 링크와 MAC 유형으로 색인했습니다. 로컬accept값은 로컬 브리지가 수신하여 적절히 처리할 내용을 기술했고, 원격accept값은 로컬 브리지가 피어에 대해 믿고 있는 바만을 기술했습니다.
  • RFC 1220은 이 신뢰를 운영적으로 애매하게 만들었습니다. 침묵은 알 수 없는 유형이 폐기될 수 있음에도 지원이 있는 것처럼 보이는 기본값이 될 수 있었고, 거부는 폐기하겠다고 밝힌 수신 쪽으로 트래픽이 계속 전달될 수 있는 상황을 남길 수 있었습니다.

1993년 6월에 발표된RFC 1474는 PPP가 전달하는 브리지 네트워크 제어 프로토콜의 관리 객체를 정의했습니다. 이 문서는 브리지된 프레임의 전체 이야기를 말하려 하지 않았습니다. 브리지 NCP가 열려 있는지, 어떤 옵션이 협상되었는지, 로컬 구성이 무엇을 요청하는지, 각 측이 처리할 준비가 된 것으로 보이는 MAC 미디어 유형은 무엇인지라는 간결한 제어 표면을 노출했습니다.

이 설계에서 가장 작은 단어가 가장 큰 경고를 담고 있었습니다. MIB는 원격 측에 대해accept를 보고할 수 있었지만, 그 설명은 “원격 브리지가 수락한다”고 말하지 않았습니다. 로컬 브리지가 그렇게믿고 있다고 말했습니다.

두 개의 accept 셀은 서로 다른 주장을 했다

미디어 상태 표는ifIndex와pppBridgeMediaMacType으로 색인되었습니다. 따라서 각 행은 하나의 PPP 링크와 하나의 미디어 유형에 속했습니다. 이더넷 계열 트래픽, 토큰 링 트래픽 및 기타 MAC 형식이 하나의 만능 “브리징 작동” 지표로 압축되지 않았습니다.

로컬 열에 대해 RFC 1474는 직접적인 기능 언어를 사용했습니다.pppBridgeMediaLocalStatus가accept이면 해당 유형의 패킷이 수신되어 적절히 처리됩니다.dont-accept이면 수신된 해당 유형의 패킷은 적절히 처리되지 않습니다.

원격 열은 의도적으로 더 약했습니다.pppBridgeMediaRemoteStatus는 로컬 PPP 브리징 개체가 원격 개체가 해당 링크에서 해당 유형의 패킷을 수락할 것이라고 믿는지를 기록했습니다. 값은 피어에 관한 것이지만, 결론의 관찰자이자 소유자는 여전히 로컬이었습니다.

이 비대칭은 지나친 세련이 아닙니다. 로컬 구현은 자신의 구성된 기능을 알 수 있습니다. 반면 피어는 메시지, 기본값, 협상에서 유지된 상태를 통해 알게 됩니다. 한 상태는 보고 시스템의 동작에 대한 주장이고, 다른 상태는 타인의 동작에 대한 모델입니다.

침묵은 지식보다 넓어 보일 수 있었다

표 뒤의 프로토콜은RFC 1220에서 왔습니다. 그 MAC 유형 선택 옵션은 노드가 수신하고 서비스할 준비가 된 트래픽 종류를 알릴 수 있게 했습니다. 여러 유형은 Configure-Request에서 여러 옵션을 필요로 했습니다.

기본값은 외견상 기대보다 관대했습니다. 시스템이 지원하는 MAC 유형을 알리지 않으면 모든 유형을 지원하는 것으로 가정될 수 있었습니다. 그러나 RFC 1220은 바로 이어서, 시스템이 이해하지 못하는 유형은 폐기할 것이라고 덧붙였습니다.

계층을 분리해 두면 이것은 모순이 아닙니다. 기본값은 더 좁은 알림이 없는 경우 발신자가 어떻게 진행해야 하는지를 알려주었습니다. 수신자 내부에 디코딩 능력을 만들어 낸 것은 아니었습니다. 로컬 표는 다음 알 수 없는 프레임이 여전히 폐기 대상인 상태에서 프로토콜 기본값으로부터 사용 가능한 원격 신뢰를 합리적으로 도출할 수 있었습니다.

명시적인 알림은 그림을 좁혔습니다. 지정되지 않은 유형은 폐기됩니다. 그러나 거부조차도 깨끗한 안전 신호는 아니었습니다. RFC 1220은 MAC 유형 알림의 거부를, 수신 시스템이 폐기하겠다고 밝혔음에도 해당 유형의 트래픽이 링크 위로 계속 전달될 수 있는 상황으로 기술했습니다.

따라서 이 표는 협상 환경을 요약한 것이지, 종단 간 보증이 아니었습니다.

이후 문서는 이 옵션을 참고용이라 불렀다

1994년에RFC 1638은 이전 브리징 사양을 대체하면서 메커니즘은 알아볼 수 있게 유지했습니다. 이 문서는 MAC-Support 협상을 강력히 권장하고, 알림이 지원되지 않는 유형을 멈추게 해 대역폭을 절약할 수 있다고 설명했으며, 이 옵션을 명시적으로 참고용(advisory)으로만 규정했습니다.

한 가지 경계도 강화했습니다. 시스템은 피어가 수신 의사를 알린 경우가 아니면 4보다 큰 번호의 MAC 유형을 전송해서는 안 됩니다. 이 규칙은 프로토콜 진화에 대한 유용한 근거입니다. 그러나 이것이 이전 상태 표를 과거의 패킷 트레이스로 바꾸지는 않으며, 어떤 이름이 알려진 구현이 어느 버전을 따랐는지도 증명하지 않습니다.

이 진화는 대신 설계상의 긴장을 드러냅니다. 기본값은 오래된 피어와의 상호운용을 유지했습니다. 알림은 효율을 높였습니다. 더 강한 규칙은 새로운 유형 코드를 보호했습니다. 어느 선택도 무엇이 관찰되었고 무엇이 추론되었는지를 정확히 말할 필요를 없애지는 못했습니다.

기능이 곧 전달은 아니었다

피어는 미디어 유형을 수락하면서도 특정 목적지에 대한 전달 정보가 없을 수 있습니다. 동시대의RFC 1493 브리지 MIB는 그 이후 단계의 문제를 별도로 모델링했습니다. 그 전달 데이터베이스는 특정 유니캐스트 MAC 주소와 그 주소에 대해 학습되거나 구성된 포트에 관한 정보를 담았습니다.

두 표는 서로 다른 질문에 답합니다. RFC 1474는 이 종류의 브리지된 프레임이 이 PPP 링크에서 지원되는지를 묻습니다. RFC 1493은 브리지가 이 주소에 대한 프레임을 어떻게 전파하거나 필터링할 수 있는지를 묻습니다. 어느 표도 목적지 호스트의 수신을 담지 않습니다.

정직한 근거 사슬은 로컬 구성, 그것이 적용된 링크 재시작, 브리지 NCP 교환, 원격 상태 신뢰의 근거, 실제로 전송된 프레임, 피어의 처리 결과, 전달 결정, 그 뒤에 오는 종단점 관찰까지 모두 보존해야 합니다.

RFC 1661은 또 하나의 경계를 제공했습니다. 네트워크 프로토콜의 패킷은 그 NCP가 Opened 상태에 이른 뒤에만 전달되며, 그 상태 이전에 수신된 패킷은 폐기됩니다. Opened는 필요한 프로토콜 상태였습니다. 그래도 특정 브리지된 프레임이 링크를 건넜다는 것을 증명하지는 않았습니다.

상태 표시는 증인을 밝혀야 한다

RFC 1474는 쓰기 가능한 구성과 운영 상태를 분리하고, PPP 관리가 보안 위험을 만들 수 있다고 경고했습니다. 보호된 뷰는 누가 객체를 읽거나 변경할 수 있는지를 제어할 수 있었습니다. 그 보호는 관리 표면을 지배했을 뿐, 값의 의미적 도달 범위를 강화하지는 않았습니다.

현대의 자동화에서 원격 기능 필드는 자신의 증인을 담아야 합니다. 협상된 알림, 기본값 가정, 캐시 세대, 활성 링크 식별자, 관찰 시각 같은 것들입니다. 이런 출처 정보 없는 초록색 표시는 시스템이 “내 피어 모델은 그렇다”를 “피어가 수신했다”로 바꾸도록 부추깁니다.

교훈은 PPP 브리징보다 크지만 불신보다는 좁습니다. 분산 시스템을 운영하려면 추론이 필요합니다. 잘못은 신뢰를 가진 것이 아닙니다. 그 신뢰를 직접 사실과 같은 시각적 문법에 담아 두고, 누가 믿었는지를 잊는 것이 잘못입니다.

RFC 1474는 잊지 않았습니다. 그 한계를 객체의 정의 안에 넣어 두었고, 모든 관리 스테이션은 그곳에서 그 한계를 지킬 수 있었습니다.

출처