요약

  • RFC 1220은 LAN 트래픽이 PPP 링크를 통과하기 전에 브리지 네트워크 제어 프로토콜(Bridge Network Control Protocol)이 열려야 한다고 요구했습니다. Open은 프로토콜의 선행 조건이었지, 확장 LAN을 통해 전달된 프레임의 영수증이 아니었습니다.
  • 이 RFC는 하나의 "링크 업(link up)" 표시가 가릴 수 있는 여러 조건을 분리했습니다: 충분한 MRU, 병렬 링크에서의 필수 순서 보장, 지원되는 MAC 타입, 방향성 압축, 권고적 LAN ID, 스패닝 트리 처리, LAN FCS 처리.
  • 같은 패킷이 두 개의 서로 다른 무결성 기록을 가졌습니다. PPP CRC는 점대점 프레임의 전송을 보호했고, 선택적 LAN FCS는 발신 LAN 프레임을 대표했습니다. 한 계층에서의 성공이 다른 계층에서의 성공을 입증하지 않았습니다.

Open은 출발선이었다

RFC 1220,Point-to-Point Protocol Extensions for Bridging은 1991년 4월 F. Baker가 편집한 문서로 나왔습니다.RFC Editor 기록과IETF Datatracker는 이를 IETF 스트림의 Proposed Standard로 분류하고RFC 1638로 대체되어 폐기되었음을 표시합니다. 이 기록들은 문서의 신원과 상태를 확립합니다. 브리지가 어느 쪽 사양이든 구현했다는 사실은 보여주지 않습니다.

문제는 하나 이상의 직렬 링크를 통해 원격 브리지 사이에서 LAN 프레임을 전달하면서, 선정된 측면에서는 여전히 하나의 확장 LAN처럼 동작하게 만드는 것이었습니다. RFC 1220은RFC 1171에서 기술한 PPP 라인 규율 위에 세워졌습니다. 이 문서는 장치들이 어떤 형태로든 PPP 사용에 합의했고 원격 브리징에 링크를 쓸 의향이 있을 수 있다고 가정했습니다. 이는 모델의 입력이었지, 특정 장치 쌍에 대해 관찰된 사실이 아니었습니다.

브리지 네트워크 제어 프로토콜(BNCP)은 눈에 보이는 관문을 제공했습니다. LCP가 네트워크 계층 프로토콜 구성 단계에 도달하기 전에는 시작할 수 없었습니다. LAN 트래픽 역시 BNCP가 연결을 열기 전에는 교환될 수 없었습니다. 이 순서는 브리지 종단을 구성하려는 프로토콜을 앞질러 브리지된 프레임이 나가는 것을 막았습니다.

그러나 Open이란 RFC의 제어 상태가 다음 트래픽 계층을 허용했다는 뜻이었습니다. 어떤 프레임이 나중에 통과했는지, 어느 인터페이스가 전달했는지, 대상 LAN이 그 프레임을 내보냈는지, 애플리케이션이 유용한 데이터를 받았는지는 말해주지 않았습니다. 상태 기계의 전이와 종단 간 결과는 1991년에도 서로 다른 장부에 속했습니다.

침묵은 좁은 의미만을 담았다

투명 브리징(transparent bridging)에 대해 RFC 1220은 특이한 프로토콜 가정을 했습니다. 이웃이 IEEE 802.1 BPDU를 수신하면서 PPP Protocol-Reject로 응답하지 않으면, 해당 링크에서 투명 브리징이 허용된 것으로 간주되었습니다. 따라서 거부의 부재는 이 프로토콜 모델 안에서 정의된 의미를 가졌습니다.

그것이 무제한 승인이 되지는 않았습니다. 이 신호는 운영자를 식별하지 않고, 일치하는 인간의 결정을 증명하지 않고, 스패닝 트리 루트를 인증하지 않으며, 일반 LAN 프레임이 전달될 것임을 보여주지 않았습니다. 유일한 정책도 아니었습니다. 네트워크 관리자는 링크를 별개의 스패닝 트리 도메인으로 나눌 수 있었지만, 양쪽 끝 모두 BPDU를 교환하지 않도록 구성되어야 했습니다. 이 모드의 브리지는 예상 밖의 이웃 BPDU를 조용히 폐기했습니다.

결국 같은 관찰된 침묵이 서로 다른 상태 뒤에 있을 수 있었습니다: RFC 기본 가정에 따른 수용, 의도적인 BPDU 억제, 일방향 장애, 혹은 역방향 트래픽을 만드는 토폴로지 이벤트가 단지 없었던 것일 수도 있었습니다. RFC 1220은 일반적인 스패닝 트리 트래픽이 대체로 단방향이므로 매직 넘버 루프 감지와 링크 품질 모니터링을 강력히 권고했습니다. 조용한 역방향 경로는 건강한 역방향 경로의 증거가 아니었습니다.

기능 명세에는 기본값과 비대칭이 있었다

BNCP 옵션은 MAC 타입, tinygram 압축, LAN 식별, 토큰 링 링/브리지 식별자를 다뤘습니다. 각 옵션은 하나의 질문을 좁혔지만, 어떤 것도 모든 하류 질문에 답하지 않았습니다.

브리지는 자신이 수신하고 처리할 준비가 된 MAC 타입을 알릴 수 있었습니다. 집합을 알렸다면 생략된 타입은 폐기되어야 했습니다. 아무것도 알리지 않았다면 피어는 폭넓은 지원을 가정할 수 있었지만, 수신자는 이해하지 못하는 타입은 여전히 폐기했습니다. 더 날카롭게도, MAC 타입 광고의 거부는 수신자가 이미 폐기하겠다고 표시했음에도 송신자가 그 트래픽을 계속 전달하는 결과를 남길 수 있었습니다. 협상 기록은 따라서 손실을 막지 못한 채 불일치만을 문서화할 수 있었습니다.

Tinygram 압축은 방향성이 있었습니다. 한 종단은 압축 해제에 동의하는 반면 다른 쪽은 그렇지 않을 수 있었습니다; 협상이 없으면 압축도 없었습니다. "압축 사용"은 양방향이 따로 기록되지 않는 한 링크 전체의 대칭 속성이 아니었습니다.

LAN 식별은 권고적이며 기본적으로 비활성이었습니다. 활성 값은 레이블된 LAN이 피어 너머에 존재할 수 있고 피어가 이를 처리할 준비가 되어 있음을 의미했습니다. 비활성이면 레이블된 트래픽은 그 지점에서 폐기되었습니다. 이 필드는 커뮤니티 경계를 기술했지만, 패킷만으로 선택된 LAN ID가 의도된 조직 그룹과 일치하는지, 송출 인터페이스가 이를 올바르게 강제하는지 증명하지 못했습니다.

프레임은 유효하면서도 여전히 부적합할 수 있었다

RFC 1220은 협상된 최대 수신 단위(MRU)가 지원되는 MAC 타입에 충분히 커야 한다고 명시적으로 경고했습니다. 브리지 형식은 조각화와 재조립을 제공하지 않았습니다. 이더넷조차 PPP의 기본 1,500옥텟 MRU를 초과할 수 있었습니다. 제어 프로토콜은 성공적으로 열리면서도 나중의 합법적인 LAN 프레임이 선택된 링크 상태에는 단순히 너무 클 수 있었습니다.

병렬 점대점 링크는 또 다른 경계를 만들었습니다. 송신자는 브리지된 프로토콜이 원래 순서를 요구하는지 결정해야 했습니다. 요구한다면 하나의 대화가 하나의 링크에 머물러야 했습니다; 송신자가 근거가 없다면 순서가 중요하다고 가정해야 했습니다. 집계 용량이 늘어난다고 LAN 의미론이 자동으로 보존되지 않았습니다.

체크섬 필드는 이 계층적 구분을 구체적으로 만듭니다. PPP 프레임의 CRC는 점대점 링크를 통한 운송을 보호했습니다. 선택적으로 내장된 LAN FCS는 발신국이 계산했거나 계산된 것으로 보이는 체크섬이었습니다. RFC 1220은 둘을 별개이며 서로 무관하다고 불렀습니다. 수신자는 LAN FCS가 없는 PPP 프레임을 수용할 수 있었습니다; 하류 브리지가 LAN 송출 시 새 FCS를 생성할 수 있었습니다. 링크 무결성, 원래 LAN 프레임의 보존, 성공적인 전달은 세 가지 서로 다른 주장이었습니다.

형식은 가능성을 기록했지, 사건을 기록하지 않았다

RFC 1220은 내장 FCS, LAN ID, 압축된 제로 패딩, 후행 라인 패딩을 위한 플래그도 정의했습니다. MAC 타입 필드는 뒤따르는 바이트의 해석을 선택했습니다. 형식은 파서에게 송신자가 무엇을 포함했다고 주장했는지 알려줄 수 있었습니다. 포워딩 데이터베이스가 올바른 송출을 선택했는지, 스패닝 트리 포트가 차단되지 않고 전달 중인지, 대상이 존재하는지는 증명할 수 없었습니다.

이 문서에는 운영자 구성, 협상 캡처, 포워딩 테이블 스냅샷, 트래픽 트레이스, 애플리케이션 로그가 없습니다. 보안 절에서는 보안 문제가 논의되지 않는다고 밝힙니다. 따라서 인증, 정책 권한, 기밀성, 안전한 롤백, 관찰된 서비스 결과를 확립할 수 없습니다.

지속되는 교훈은 BNCP Open이 약했다는 것이 아닙니다. 정확했다는 것입니다. 프로토콜이 브리지된 LAN 트래픽을 언제 시작하도록 허용하는지 답했습니다. 문제는 그 경계가 명확한 답이 확장 LAN이 동작했다는 주장으로 승격될 때만 시작됩니다.

출처