요약

  • RFC 3925는 DHCPv4가 같은 메시지에서 둘 이상의 벤더를 위한 데이터를 운반할 수 있도록 프레임 방식을 제공했다.
  • 바깥쪽 옵션 번호를 등록했지만, 내부 서브옵션 코드와 그 의미는 각 벤더에게 남겼다. PEN은 네임스페이스에 라벨을 붙이는 것이지 인증된 주장이 아니다.

10년 동안 벤더 정보를 위한 일반적인 DHCPv4 경로는 좁은 형태를 지녔다. RFC 2132의 옵션 60은 클라이언트가 벤더 클래스 문자열을 보내게 했고, 옵션 43은 불투명한 벤더 고유 객체를 운반했다. 서버는 옵션 60이 가리키는 벤더의 맥락에서 옵션 43을 해석했다. 한 벤더의 어휘로 충분할 때는 이 방식이 동작했지만, 어떤 기기나 산업 프로필이 둘 이상의 벤더를 위해 독립적으로 정의된 정보를 필요로 하게 되면 모호해졌다. RFC 3925는 이 충돌을 DHCP 주소 할당의 실패가 아니라 프레임 문제로 서술한다.

이 표준의 답은 두 번째 옵션 쌍이었다. 옵션 124(Vendor-Identifying Vendor Class)와 옵션 125(Vendor-Identifying Vendor-Specific Information)는 각 벤더의 데이터 옆에 IANA Private Enterprise Number를 놓는다. 옵션 125는 여러 항목을 담을 수 있다. 기업 번호, 길이, 그리고 해당 벤더의 바이트다. 길이는 하나의 페이로드를 다음 페이로드와 분리하고, 기업 번호는 어느 벤더의 해석이 적용되는지 선택한다. RFC 3925는 기존의 옵션 60과 43을 그대로 두기 때문에, 구현은 레거시 형태와 식별형 형태를 모두 만날 수 있다.

이 구조는 작지만 결과가 큰 설계 구분이다. 바깥쪽 DHCP 옵션 코드는 IANA가 할당한다. 벤더의 네임스페이스를 명명하는 번호는 IANA의 Enterprise Numbers 레지스트리가 할당한다. 어느 레지스트리도 벤더의 페이로드가 무엇을 의미하는지 정의하지 않는다. 각 페이로드 내부의 서브옵션은 코드/길이/값 프레임을 사용하지만, RFC 3925는 서브옵션 코드가 IANA가 관리하는 것이 아니라 벤더가 정의한다고 명시한다. 이 표준은 여러 사투리를 분리해 두는 장소를 만들었지, 그것들을 번역하는 공용 사전을 만들지 않았다.

패킷 자체에도 경계가 있다. 결합된 데이터가 옵션 길이의 1바이트 한도를 초과할 수 있으므로, RFC 3925는 옵션 124와 125를 RFC 3396에 따라 연결(concatenation)이 필요한 옵션으로 표시한다. 수신자는 내부 항목을 해석하기 전에 반복된 조각들을 하나의 논리적 옵션으로 합쳐야 한다. 각 조각을 새로운 벤더 기록으로 다뤄서는 안 된다. 표준은 기업 번호가 인스턴스 전체에서 한 번만 나타나도록 권고하며, 여러 번 나타나면 동작은 정의되지 않는다. 이 프레임은 다중성을 수용하지만, 모든 잘못된 형태나 반복된 조합을 의미 있게 만들지는 않는다.

RFC 3925는 이 패턴을 RFC 3315의 DHCPv6 벤더 클래스 및 벤더 고유 옵션에서 빌려왔다. 이는 의도적인 설계 재사용의 증거이지, 두 프로토콜 계열이 페이로드 의미나 배포를 공유한다는 증거가 아니다. 이 확장은 벤더를 인증하지도 않는다. RFC 3925는 자체적으로 어떤 보안도 제공하지 않는다고 말하며, 진위성이 필요할 때는 RFC 3118이 별도의 DHCP 인증 메커니즘을 정의한다. 옵션에 담긴 번호는 선택자이지 서명이 아니다.

이것이 RFC 3925가 역사적 관점에서 중요한 이유다. 이 표준은 경계를 명시하는 방식으로 공존을 해결하면서, 지역적 의미는 지역적으로 남겨두었다. 바깥쪽 레지스트리는 구현자에게 컨테이너를 어떻게 파싱하고 그것이 어느 네임스페이스를 명명하는지 알려줄 수 있다. 그러나 어떤 벤더 고유 바이트가 무엇을 할지, 기기가 실제로 그 벤더에 속하는지, 어떤 구현이 이 옵션을 지원하는지는 알려줄 수 없다. 이러한 사실들은 별도의 근거를 필요로 한다. RFC와 IANA 기록은 설계와 코드포인트 할당을 확립하지만, 채택률, 상호운용성, 운영 결과는 측정하지 않는다.

출처