요약

  • RFC 1089는 표준 SNMP 메시지가 십진법 33100, 즉 16진법0x814C의 EtherType으로 식별되는 이더넷 프레임의 데이터 필드에 직접 실리는 것을 허용했습니다. 덕분에 리피터나 배선 집선기(wiring concentrator)는 IP와 UDP를 구현하지 않고도 관리될 수 있었습니다.
  • RFC 4789는 이후에 타입 코드를 유지하면서 운영 경계를 명확히 했습니다. 선택적 매핑은 하나의 논리적 IEEE 802 LAN, 브리지드 LAN 또는 VLAN에만 도달할 수 있으며, 주어진 인터페이스에서는 단 하나의 SNMP 엔진만 주소 지정할 수 있습니다.
  • MAC 주소는 전송 엔드포인트를 식별합니다. 주체를 인증하지 않고, MIB 뷰에 대한 접근을 허가하지 않으며,SET이 물리적 장비를 실제로 변경했다는 증거도 되지 않습니다. SNMP 보안, 접근 제어, 결과 증거는 별개로 남습니다.

장비는 회선 위에 있었지만 인터넷에는 없었다

이더넷 리피터는 세그먼트의 모든 패킷에 영향을 줄 수 있었습니다. 배선 집선기는 다수 호스트의 공통 물리적 지점이 될 수 있었습니다. 1989년 당시 이런 장비는 점차 프로그래밍 가능한 지능과 MAC 주소를 갖추고 있었지만, MAC 하위 계층 위에 인터넷 프로토콜을 전혀 갖지 않을 수도 있었습니다. IP 관리 스테이션 입장에서 장비는 중요하면서도 동시에 보이지 않는 존재였습니다.

RFC 1089는 이 불일치를 전송 문제로 다뤘습니다. SNMP는 UDP/IP에 대한 불가역적 결합이 아니라 주소 지정 가능성과 양방향 메시지 흐름을 중심으로 설계되어 있었습니다. 네트워크 요소가 이미 같은 이더넷 위에 살고 있다면, 요소에게 먼저 IP 호스트가 되라고 요구하지 않고도 프레임 안에서 관리 메시지를 전달할 수 있었습니다.

이 제안은 의도적으로 실험적이었습니다. MIB를 재설계하거나 새 관리 연산을 추가하거나 보편적 관리 네트워크를 정의하지 않았습니다. 당시 이미 규정되어 있던 SNMP 메시지를 그대로 두고 그 아래의 봉투(envelope)만 바꾼 것입니다.

이 좁음이 곧 역사적 기여입니다. 관리 프로토콜은 요청의 의미를 보존하면서 운반체를 바꿀 수 있었습니다. 이점과 한계는 같은 뺄셈에서 나왔습니다.

하나의 프레임이 상위 스택을 대체했다

RFC 1089의 회선 규칙은 몇 줄이면 충분했습니다. 제록스(Xerox)는 SNMP를 위해 이더넷 타입 33100, 즉 16진법814C를 배정했습니다. 이더넷 데이터 필드에는 표준 SNMP 메시지가 담겼습니다. 이더넷 프레임과 그 메시지 사이에 IP 헤더도 없었고, 에이전트를 고르는 UDP 포트도 없었습니다.

이것은 압축된 IP 패킷이 아니었습니다. MAC 목적지가 인터페이스를 선택했고, 타입 필드가 페이로드 문법을 선택했습니다. 장비는 ASN.1/BER을 디코딩하고 SNMP 에이전트를 구현하되, 이 경로에 한해 IP 주소 지정, 라우팅, 단편화, UDP 디멀티플렉싱까지 구현할 필요는 없었습니다.

RFC 1157은 이 구성이 SNMP의 철학에 왜 부합하는지 설명합니다. 그 아키텍처는 관리 대상 에이전트 안의 기능과 복잡도를 최소화하려 했습니다. 각 메시지는 독립적으로 표현되었고, 명세가 UDP를 사용했음에도 그 메커니즘은 다양한 전송 서비스에 적합하다고 서술되었습니다. 직접 이더넷은 그 분리의 하나의 구체적 시험이었습니다.

헤더를 제거했다고 상태 관리가 모두 사라지지는 않았습니다. 관리자는 여전히 어떤 MAC 목적지가 장비를 대표하는지, 장비가 속한 논리적 LAN이 어디인지, 어떤 SNMP 버전과 보안 매개변수를 쓸지, 응답을 어떻게 요청과 연관 지을지 알아야 했습니다. 요소 안의 단순함은 발견과 경계 지식을 운영자에게 넘겼습니다.

0x814C는 문법의 이름이지 주체의 이름이 아니었다

EtherType은 정확히 하나의 파싱 질문에 답했습니다: 이더넷 헤더 뒤에 오는 바이트를 어떤 프로토콜이 받아야 하는가? 이는 SNMP 메시지가 IP 데이터그램이나 다른 링크 페이로드로 오해되는 것을 막았습니다.

하지만 누가 메시지를 보냈는지는 답하지 않았습니다. 어떤 조직이 발신 인터페이스를 통제하는지, 요청이 허가된 운영자에게 속하는지, 발신자가 어떤 MIB 객체를 읽거나 변경할 수 있는지, 요청된 변경이 안전한지 말해주지 않았습니다. 올바른 타입 값은 직렬화에 대한 증거일 뿐 자격 증명이 아닙니다.

같은 구분이 목적지 MAC 주소에도 적용됩니다. 프레임이 인터페이스에 도달해야 하므로 유용합니다. 이후 전송 도메인 모델에서는 IEEE 802 매핑에 결부된 전송 주소가 됩니다. 그러나 주소는 권한 위임이 아닙니다. 엔드포인트에 바이트를 전달하는 것이 그 바이트가 서술하는 연산을 승인하지는 않습니다.

경로가 물리적으로 로컬일 때 이 차이는 쉽게 흐려집니다. "이 LAN 안에서만"이라는 말이 신뢰 정책처럼 들릴 수 있습니다. 하지만 RFC 기록은 그렇게 만들지 않았습니다. 지역성은 특정 토폴로지에서 누가 채널에 닿을 수 있는지를 좁힐 뿐, 그 채널을 사용할 자격이 있는 주체를 정의하지 않습니다.

2006년 개정판은 섬을 그렸다

17년 뒤RFC 4789는 실험적 메모를 폐기하고 IEEE 802 네트워크를 위한 표준 트랙 매핑으로 대체했습니다. 핵심 결정은 유지했습니다: SNMP 메시지를 직렬화하여 EtherType0x814C아래 MAC 프레임 데이터 필드에 실는 것입니다.

개정판은 더 넓은 802 계열도 다뤘습니다. 802.11 사례를 포함해 LAN이 프로토콜 식별에 LLC를 사용하는 경우, 매핑은 SNAP 캡슐화를 사용했습니다. 링크 봉투의 정확한 형태는 달라질 수 있지만 배정된 이더넷 타입과 직렬화된 SNMP 메시지는 여전히 식별 가능했습니다.

더 중요한 것은 문서가 도달 경계를 명시했다는 점입니다. IEEE 802 직접 SNMP는 단일 논리적 IEEE 802 LAN, 브리지드 LAN 또는 VLAN으로 제한됩니다. 브리지는 로컬 도메인을 확장할 수 있습니다. 라우터는 프레임을 일반 인터넷 경로로 바꾸지 않습니다. 따라서 VLAN 재구성은 장비와 MAC 주소가 그대로 있어도 관리 도달 범위를 바꿀 수 있습니다.

이것은 실질적인 설계 트레이드였습니다. 단순한 요소는 IP 아래에서 관리될 수 있지만, 관리자는 관련 논리적 LAN을 공유하거나 명시적으로 통제된 로컬 브리지를 통해 도달해야 했습니다. 이 매핑은 라우팅된 관리와 거리에서 경쟁하지 않았습니다. 다른 입장 문제를 풀었습니다: 직접 접속된 요소는 얼마나 작은 스택으로 충분한가?

공유 인터페이스에는 엔진 하나 크기의 개구부만 있었다

RFC 4789는 UDP 포트가 그렇지 않다면 가려졌을 또 하나의 한계를 추가했습니다. 주어진 IEEE 802 네트워크 인터페이스에서는 단 하나의 SNMP 엔진만 주소 지정할 수 있습니다. 명령 생성기와 알림 수신기는 명령 응답기 및 알림 발신기와 엔드포인트를 공유합니다.

UDP에서는 포트와 주소의 조합이 수신 역할을 구분하는 데 도움을 줍니다. 직접 매핑에는 MAC 주소와 프로토콜 타입은 있지만 전송 포트가 없었습니다. 그 결과 명세는 여러 역할을 하나의 인터페이스 목적지로 압축했습니다.

이는 모든 메시지가 같은 기능을 한다는 뜻이 아닙니다. SNMP의 메시지 처리는 여전히 요청, 응답, 알림을 구분합니다. 링크 계층 봉투가 같은 인터페이스 뒤의 여러 엔진 중 하나를 고를 수 없다는 뜻입니다. 구현이 내부 디멀티플렉싱이 필요하다면 그것은 사적인 구성이며, 매핑이 노출하는 두 번째 표준화된 엔드포인트가 아닙니다.

크기 계약도 명시적이었습니다. 엔터티는 484옥텟까지 메시지를 수락해야 했고, 1472옥텟까지 수락하도록 권장되며 더 큰 값도 장려되었습니다.RFC 3417은 SNMP 전송 매핑에 같은 수신 임계값을 사용했으며, IPv4 시스템에 대해 IPv4상 UDP를 선호 매핑으로 정했습니다. 직접 IEEE 802는 선택 사항으로 남았고, 평범한 IP 경로의 상호운용성 가치를 지우지 않았습니다.

전송 도메인은 좌표를 정직하게 유지했다

이후의 SNMP 프레임워크는 모든 엔드포인트가 IPv4에 UDP 포트를 더한 것이라고 가정하지 않고 엔드포인트를 지칭하기 위해 일반 MIB 모듈이 필요했습니다. 따라서 RFC 4789는snmpIeee802Domain을 등록했습니다. 그에 대응하는 전송 주소는MacAddress입니다.

이 쌍은 자격 없는 바이트열보다 정보가 많습니다. 도메인이 주소를 어떻게 해석할지 말해줍니다. IEEE 802 도메인 아래의 6옥텟은 조용히 IP 주소, 사용자 이름 또는 전역 라우팅 서비스로 변환되지 않습니다. 좌표는 그 좌표에 의미를 부여하는 전송에 한정된 채로 남습니다.

이 규율은 로그와 구성에서 중요합니다. MAC 값만 기록하면 어느 VLAN 또는 브리지드 LAN이 그 주소를 도달 가능하게 만들었는지 잃습니다. SNMP 엔진 식별자만 기록하면 어느 인터페이스가 그 엔진을 실었는지 잃습니다. 사용자 이름만 기록하면 전송 관측 자체를 잃습니다. 각 식별자는 서로 다른 질문에 답하며 각자의 수명을 갖습니다.

보안은 프레임이 도착한 뒤에 시작된다

RFC 4789는 물리적 근접성을 보호로 취급하지 않았습니다. 보안 절에서 SNMPv1과 SNMPv2c 메시지는 안전하다고 간주되지 않는다고 밝히고, SNMPv3의 사용자 기반 보안 모델(User-based Security Model)과 뷰 기반 접근 제어 모델(View-based Access Control Model)을 권장합니다.

RFC 3414는 인증되고 시간성 있는 SNMPv3 메시지와, 선택 시 기밀성을 위한 메커니즘을 제공합니다.RFC 3415는 다른 질문을 던집니다: 이 보안 이름이 이 모델과 컨텍스트 아래에서 이 MIB 뷰에 대해 이 연산을 수행할 수 있는가?

어느 결정도 EtherType의 몫이 아닙니다. 링크 계층은 후보 메시지를 전달합니다. 보안 모델은 그 보호와 주체를 평가합니다. 접근 제어는 요청된 객체와 연산을 평가합니다. 그다음 인스트루멘테이션이 허가된 연산이 장비에게 무엇을 의미하는지 결정합니다.

응답 또한 유한한 증거입니다. 어떤 SNMP 엔진이 요청을 처리하고 적용 모델 아래에서 값 또는 상태를 반환했다는 것은 보여줄 수 있습니다. 그것만으로 릴레이가 상태를 변경했는지, 패킷이 새 경로를 따랐는지, 효과가 재시작 후에 지속되는지 증명하지는 않습니다. 그런 주장에는 이후의 읽기, 독립적인 카운터, 물리적 관찰 또는 다른 결과 전용 신호가 필요합니다.

그러므로 1989년의 작은 실험은 하나의 큰 규칙을 드러냈습니다. 전송 요구사항을 낮추면 관리 가능한 장비의 집합은 넓어지지만 관리 채널의 범위는 좁아집니다. 도달 가능성, 메시지 진위성, 권한, 효과는 그 사이에 끼는 프로토콜 계층이 줄었다고 해서 하나로 합쳐지지 않습니다.

출처