요약

  • RFC 1449는 SNMPv2 메시지 하나를 동일하게 유지하면서 UDP, OSI, DDP 또는 IPX 위에서 전송했습니다. 주소는 보편적이지 않았습니다. OID 도메인이 그 옥텟을 해석할 수 있는 규약을 지정했습니다.
  • 네 가지 규약은 모두OCTET STRING에 기반했지만, 여섯 옥텟은 UDP에서는 IPv4 주소에 포트를 더한 것이었고, 열두 옥텟은 IPX에서 네트워크·물리 주소·소켓을 나타냈으며, OSI와 NBP는 길이 필드를 사용했습니다.
  • 도메인–주소 쌍은 값을 해석 가능하게 만들었습니다. 그러나 이는 할당, 라우팅, 수신 대기, 피어 신원, 권한 부여, 장비에 대한 효과를 증명하지 못했습니다.

저장 형식이 곧 의미는 아니다

데이터베이스는 무엇이든 담을 수 있는 열을 선호합니다. 바이트 필드는 이상적으로 보입니다. 짧은 주소도, 긴 값도, 이진열도, 인코딩된 이름도 받아들일 수 있으니까요. 그러나 이 편의는 그 필드가 주소 그 자체로 제시되는 순간 기만적이 됩니다.

RFC 1449는 '다형적'이라는 단어가 데이터 아키텍처에서 흔해지기 전에 이 문제를 다뤘습니다. 1993년 4월에 발표된 이 문서는 아직 단일 프로토콜 체계와 동의어가 아니었던 인터넷에서 SNMPv2를 유통시켜야 했습니다. IP는 OSI, AppleTalk, IPX와 공존했습니다. 관리 프로토콜은 모든 네트워크가 같은 주소 지정 체계를 채택하도록 요구하지 않고서 공통으로 남아야 했습니다.

해법은 모든 주소처럼 보일 만큼 유연한 문자열을 발명하는 것이 아니었습니다. 전송 도메인과 그 도메인에 부합하는 주소 값, 이 두 요소를 함께 유지하는 것이었습니다. 전자가 후자의 읽기 규칙을 선택했습니다.

RFC 1449 모듈에서snmpUDPDomain,snmpCLNSDomain,snmpCONSDomain,snmpDDPDomain,snmpIPXDomain은 서로 다른 식별자였습니다. CLNS와 CONS는 같은 OSI 주소 규약을 공유했으므로, 다섯 도메인은 네 가지 문법으로 귀결되었습니다.

UDP 세계의 여섯 옥텟

SnmpUDPAddress는 고정 6옥텟 크기였습니다. 처음 네 옥텟은 네트워크 바이트 순서의 IP 주소였고, 마지막 두 옥텟은 UDP 포트였습니다. 올바른 도메인과 함께라면 이 구분은 결정적이었습니다. 도구는 추측 없이 네 개의 십진수와 포트를 표시할 수 있었습니다.

에이전트에 포트 161이 권장된다는 사실은 이 의존성을 바꾸지 않았습니다. 그 숫자가 SNMP 접점으로 의미를 갖는 것은 UDP 매핑 안에서만이었습니다. 알림 수신자는 보통 162를 사용했습니다. 다른 도메인이 이 숫자들을 마법처럼 물려받지는 않았습니다.

여섯 옥텟만 보존하는 아카이브는 기껏해야 하나의 가설을 가능하게 합니다. 그 길이는SnmpUDPAddress와 닮았지만, 발신자가snmpUDPDomain아래에 이를 기록했다는 증거가 아닙니다. 형태는 타입이 지정된 출처를 대체하지 못합니다.

이 주의는 학문적 것이 아닙니다. 마이그레이션 프로그램은 잘린 값, 독자 형식, 이웃 필드가 사라진 오래된 표현을 만날 수 있습니다. 여섯 옥텟이 '그럴듯해 보인다'는 이유로 자동으로 IPv4를 선택하면, 증거의 부재를 정확한 목적지로 바꿔버립니다.

OSI는 자기 길이부터 설명했다

OSI 주소는 보편적 디코더의 불가능성을 더욱 선명하게 보여주었습니다. 첫 옥텟이 NSAP의 길이를 나타냈습니다. 그다음 NSAP이 오고, 전송 셀렉터가 나머지를 차지했습니다. 전체 값은 한 옥텟만 담을 수도 있고 네 개에서 여든다섯 개까지 담을 수도 있었습니다.

따라서 첫 옥텟은 IP 주소의 시작이 아니었습니다. 내부 구조에 대한 지시였습니다. 도메인을 잊으면 독자는 길이를 주소 데이터로 취급하고 그 뒤의 모든 경계를 밀어낼 수 있었습니다.

CLNS와 CONS는 같은SnmpOSIAddress를 선택했지만 두 개의 별개 도메인으로 남았습니다. 이 세부는 주소와 전송 서비스가 융합되지 않았음을 보여줍니다. 공통의 값 문법이 두 전송 동작에 사용될 수 있으면서도 그들을 동일하게 만들지는 않았습니다.

*1x:/1x:표시 관례는 운영자가 구성 요소를 보도록 도왔습니다. 그러나 이는 정규 값도 경로의 증거도 아니었습니다. 표시는 타입화된 데이터의 투영이었지 그 권위가 아니었습니다.

DDP는 이름을, IPX는 로컬 토폴로지를 인코딩했다

DDP 도메인은 전달 트리플렛을 필드에 직접 넣지 않았습니다. 대상은SnmpNBPAddress, 즉 개체, 유형, 영역 세 문자열로 이루어진 NBP 이름이었습니다. 각 문자열은 길이를 앞세웠습니다. 전체 크기는 3옥텟에서 99옥텟까지, 비교는 대소문자를 무시했고 문자열 안에서 255 옥텟은 금지되었습니다.

이 규약은 AppleTalk의 한 성질에 응답했습니다. 서비스 이름은 바뀔 수 있는 전달 주소보다 참조로서 더 유용할 수 있다는 것입니다. 다만 NBP 캐시, 장애 시 탐색, 재할당된 주소의 상세 역사는 RFC 1419의 몫입니다. 여기서 더 좁은 요점은 DDP 값이 UDP의 나눔도 OSI의 나눔도 따르지 않았다는 점입니다. 도메인은 필드를 즉석의 숫자 주소가 아니라 이름으로 읽어야 하는지조차 지정했습니다.

SnmpIPXAddress는 고정 12옥텟을 차지했습니다. 네 옥텟은 네트워크 번호, 여섯은 물리 주소, 둘은 소켓 번호였습니다. 고정 길이가 이를 의미상 UDP에 가깝게 만들지는 않았습니다. 단지 또 다른 분할을 정의했을 뿐입니다.

그럼에도 이 모든 객체는 같은 ASN.1 기반, 즉OCTET STRING을 공유했습니다. 이 유형은 옥텟 순서와 값으로서의 전송을 보장했습니다. 그러나 내부 경계, 비교 규칙, 값이 속하는 네트워크를 결정하지는 않았습니다.

메시지는 온전히 유지되었다

주소의 다양성이 관리 프로토콜을 늘리도록 강요하지는 않았습니다. RFC 1449는 SNMPv2 메시지를 BER(Basic Encoding Rules)에 따라 직렬화한 뒤, 완전한 인스턴스 하나를 전송 단위에 담았습니다. UDP, DDP, IPX에서는 그 단위가 데이터그램이었고, OSI 서비스에서는 TSDU였습니다.

문서는 결정된 BER 형식을 요구했습니다. 정의된 길이, 단순 유형의 프리미티브 인코딩, 구조체에만 허용되는 구성 형식이 그것입니다. 이 선택들은 SNMP 봉투, PDU 및 그 안에 담긴 객체에 적용되어, 전송 선택에 앞서 내부 문법을 안정화했습니다.

이 아키텍처는 겹쳐진 두 계약으로 이해할 수 있습니다. 안쪽 계약은 관리 작업을 어떻게 인코딩하는지를, 바깥쪽 계약은 목적지를 어떻게 명명하고 메시지를 어떤 단위로 전달하는지를 말했습니다. 도메인을 바꾼다고 전송이 작업을 재작성할 권한을 얻지는 않았습니다.

UDP는 선호되는 매핑으로 남았습니다. 다른 매핑을 선택한 시스템은 상호운용성을 높이기 위해 UDP로의 프록시를 제공하도록 권장되었습니다. 이 선호는 실용적 만남의 지점을 가리켰지, 다른 주소들을 흡수할 수 있는 보편 형식을 지정하지 않았습니다.

후속 표준은 그 결합을 무시할 수 없게 만들었다

RFC 1906은 1996년에 RFC 1449를 대체했습니다. 그 모듈에서 각 도메인은 대응하는 주소 규약의 이름을 설명에 명시하는주체-IDENTITY가 되었습니다. UDP 도메인은 명시적으로SnmpUDPAddress를, DDP는SnmpNBPAddress를, IPX는SnmpIPXAddress를 가리켰습니다.

이 서술은 도구들에게 중요했습니다. OID는 문자열 옆에 놓인 장식이 아니었습니다. 구체적인 유형을 선택했습니다. 이 관계는 1993년판에 이미 존재했지만, 이후의 표현은 두 필드를 의존성 이해 없이 저장하는 구현을 더 어렵게 만들었습니다.

RFC 3417은 2002년에 이 계보를 이어받았습니다. IPv4 위의 UDP 매핑을 명확히 명명하고, 도메인별 유형을 유지하며, 1993년과 1996년의 개정을 모듈에 기록했습니다. 식별자의 연속성은 기존 독자와 데이터를 보호했습니다.

그러나 이는 실태 조사가 아니었습니다. OSI, DDP 또는 IPX 도메인이 표준에 지속적으로 존재한다는 사실은 현재 어떤 장비가 이를 구현한다는 것을 입증하지 않습니다. 정의는 값이 존재할 경우 이를 어떻게 해석할지 말하고, 관찰은 그것이 지금 여기 존재하는지를 말합니다.

디코딩은 첫 번째 관문일 뿐이었다

유효한 쌍은 한정된 주장만 가능하게 합니다. 도메인이 UDP이고 값이 여섯 옥텟이라면, 규약에 따라 IPv4 주소와 포트를 만들어낼 수 있습니다. 그 주소가 의도된 장비에 속했다고 주장하려면 시점이 명시된 할당 데이터가 필요합니다. 도달 가능했다고 주장하려면 전송 관찰이 필요합니다. 피어를 식별하려면 해당 교환에 결부된 인증 증거가 필요합니다.

권한 부여는 그 이후입니다. 응답하는 에이전트는 요청된 객체를 거부할 수 있습니다. 수용된 작업이 기대된 물리적 효과를 낼 수는 없습니다. 변하는 카운터가 사용자 결과를 보장하지 않습니다. 단계들은 시각적으로 유지되어야 합니다.

octets → domain → typed address → chosen transport → observed exchange → authenticated peer → authorized operation → measured effect

가장 심각한 결함은 따라서 만료된 주소가 아닙니다. 만료된 주소는 테스트하고 시점을 확정할 수 있습니다. 도메인의 상실은 과거 그 자체를 해석 불가능하게 만듭니다. 분석가는 옥텟을 그대로 보존했음에도, 생산자가 어떤 규칙을 적용했는지 더는 알 수 없습니다.

출처와 한계

1차 출처는RFC 1449의 RFC Editor 정보 페이지와RFC 1449 전문입니다. 후속 개정은RFC 1906입니다. 현재 계보는RFC 3417 정보 페이지와RFC 3417로 문서화되어 있습니다. 이 문서들은 형식, 결합, 표준 역사를 확립합니다. 그러나 어떠한 배포, 공급자, 트래픽, 사건 또는 현재의 결과도 입증하지 않습니다.