요약

  • DHCP는 고정된 서버 이름 필드와 부팅 파일명 필드를 옵션 용도로 재활용할 수 있지만, 그 앞에 반드시 일반 옵션 필드에 명시적인 오버로드 선언이 있어야 한다.
  • 추가 저장 공간 문제와 긴 값의 인코딩 문제는 서로 별개다. RFC 3396은 반복된 옵션 데이터를 패킷 안의 물리적 순서가 아니라 옵션, file, sname의 논리적 순서로 결합한다.
  • 재활용은 필드 경계를 유지하며 기존 부팅 정보를 다른 곳으로 옮길 수 있다. 그러나 무한한 공간을 만들어 주지도, 오래된 수신기를 업그레이드하지도, 호스트를 구성할 권한을 부여하지도 않는다.

여전히 두 조각이 필요했던 짧은 이름

예시는 거의 노골적으로 평범하다:/diskless/foo. 이 경로는 13바이트를 차지하며, DHCP 옵션 한 인스턴스의 관례적인 255바이트 데이터 한도에는 한참 못 미친다. 그런데도 2002년 11월에 발행된RFC 3396은 이 이름을 7바이트와 6바이트로 나눈 사례를 보여준다.

분할 지점은 diskless라는 단어 안쪽에 있다. 디렉터리 구성 요소 사이를 나누는 것도, 두 개의 대체 파일명을 인코딩하는 것도 아니다. 목적은 패킹이다. 남은 공간이 옵션 전체를 담기에 부족한 필드는 그 일부를 담을 수 있고, 나머지는 다른 허용된 필드가 담는다.

이 작은 예시는 혼동하기 쉬운 두 가지 제약을 드러낸다. 옵션 값이 1바이트 길이 필드가 표현할 수 있는 범위를 초과할 수 있다. 또는 그 길이에는 충분히 들어가지만 특정 필드의 미사용 공간에는 들어가지 않을 수 있다. 옵션을 담을 자리를 늘리는 것만으로는 수신기가 어느 경우든 어떻게 재구성할지 정의하지 않는다.

DHCP는 이미 다른 용도로 배정된 공간들이 있는 패킷을 물려받았다. 첫 단계는 그 일부를 빌려 쓰는 것이었다. 더 어려운 단계는 수신기가 어느 공간의 용도가 바뀌었는지, 각 인코딩된 항목이 어디서 끝나는지, 그리고 조각들이 어떤 순서로 속하는지 알 수 있도록 보장하는 것이었다.

부팅 패킷에는 이름을 위한 예약 공간이 있었다

1985년 9월,RFC 951은 부팅에 적합한 고정 레이아웃을 갖춘 BOOTP를 기술했다. 기기는 완전한 운영 환경이 준비되기 전에 정보를 얻을 수 있었다: 주소, 서버, 부팅 파일.

패킷은 선택적 서버 호스트명을 sname이라 불리는 64바이트 필드에 담았다. 부팅 파일명은 file이라 불리는 128바이트 필드에 담았다. 둘 다 널 종료 문자열이었다. 별도의 64바이트 vend 영역은 벤더 고유 정보를 담을 수 있었다. 이들은 원래 설계에서 무의미한 빈틈이 아니라 그 서비스가 제공하려던 바를 반영한 공간이었다.

DHCP는 구성 범위를 넓히면서도 이 기본 레이아웃을 유지했다. 1997년 3월의RFC 2131에서 옵션은 가변 길이가 되었고, 클라이언트는 최소 312옥텟의 옵션 필드에 대비해야 했다. 더 큰 메시지 협상은 별도로 이용 가능한 메커니즘이었다. 전체 메시지가 한 옵션 데이터 길이로 표현 가능한 255옥텟에 제한되지는 않았다.

그럼에도 구성 패킷은 여전히 실질 공간이 부족할 수 있었다. 오래된 이름 필드들이 매력적인 용량이었던 것은 바로 위치가 안정적이었기 때문이다. 이들을 재활용하려면 뒤따르는 모든 필드를 이동할 필요는 없었다. 통제된 방식의 해석 변경만 필요했다.

선언은 긴 옵션 표준보다 먼저 등장했다

Option Overload는 이미 1993년 10월의RFC 1533에서 규정되어 있었다. 코드는 52였고, 1옥텟 값으로 1은 file, 2는 sname, 3은 둘 다를 선택했다. 이것은 2002년 연결 문서의 발명품이 아니며, 1997년 개정판이 처음 도입한 것도 아니었다.

선언은 해당 메시지와 지정된 필드에만 국한되었다. 파서가 바이트가 우연히 비슷해 보이는 곳이라면 어디든 옵션을 찾아 헤쳐도 된다는 허가를 주지 않았다. 또한 이후의 모든 패킷에 대한 해석을 영구적으로 바꾸지도 않았다.

RFC 2131은 오버로드 옵션이 일반 옵션 필드에 나타나야 한다고 요구했다. 수신기는 먼저 그 필드를 해석하고, 지정된 경우 file, 그다음 sname을 해석해야 했다. 필드를 다시 해석하라는 지시는 수신기가 이미 읽는 법을 아는 위치에 놓였다.

이 배치는 순환 의존을 피한다. 재활용된 필드를 파싱할 허가가 그 필드 안에서만 발견된다면 구현체는 시작해야 하는지를 추측해야 한다. 공통 선언은 발신자의 로컬 패킹 선택을 추측 없이 관찰 가능하게 만들었다.

빌려온 공간에도 벽은 남았다

일반 옵션 영역은 4옥텟 매직 쿠키로 시작하고, 그 뒤에 태그가 붙은 항목들이 온다. 전형적인 항목은 코드, 길이, 그리고 지정된 수의 데이터 옥텟으로 이루어진다. 길이에는 코드와 길이 옥텟 자체는 포함되지 않는다. Pad와 End는 일반적인 길이를 갖는 값이 아니라 1옥텟 예외다.

오버로드된 file 또는 sname은 해당 필드의 첫 옥텟에서 옵션 시퀀스를 시작한다. 새 매직 쿠키를 받지는 않는다. 이런 필드는 각각 옵션 시퀀스를 End로 종료하고 나머지를 Pad로 채워야 한다. 개별적으로 인코딩된 옵션은 반드시 하나의 필드 안에 온전히 머물러야 한다.

이 규칙들은 가용 용량과 연속적인 물리적 스트림을 구분한다. 발신자는 한 옵션이 벽을 넘어 다음 필드로 흘러들어 가도록 두고 수신기가 따라오기를 기대할 수 없다. 한 필드의 End 표식이 다른 필드들을 나중의 논리적 해석 대상에서 지워주지도 않는다.

file과 sname을 합치면 192옥텟의 필드 공간이 된다. 그러나 192옥텟의 자유 데이터 옥텟이 되는 것은 아니다. 태그, 길이, 종료, 패딩, 오버로드 선언, 그리고 자리를 비켜난 부팅 정보가 용량을 소비한다. 이는 경계가 있는 재활용이지 무한 확장이 아니며, 다른 이름의 IP 단편화도 아니다.

이름을 옮긴다고 부팅 정보가 사라진 것은 아니었다

1997년 3월의RFC 2132는 자리를 비켜난 의미를 표현하는 방법을 제공했다. 옵션 66은 sname이 옵션에 사용될 때 TFTP 서버를 식별하고, 옵션 67은 file이 용도가 바뀔 때 부팅 파일을 식별한다.

따라서 기존 파라미터는 전용 상자를 떠난 뒤에도 살아남을 수 있었다. 고정 필드에서 인쇄 가능한 파일명만 찾는 수신기는 정보가 단지 표현 방식을 바꿨을 뿐인데도 구성이 누락되었다고 보고할 수 있다. 기존 문자열의 부재는 부팅 파일의 부재가 아니었다.

현재의IANA BOOTP 및 DHCP 파라미터 레지스트리에는 Overload가 52, Server-Name이 66, Bootfile-Name이 67, Domain Search가 119로 기록되어 있다. 이들은 옵션 코드다. 옵션 67이 DHCP 서버 전송 포트라는 말은, 그 숫자가 우연히 UDP에서 같은 목적으로도 쓰인다는 이유만으로 성립하지 않는다.

등록은 파라미터에 대한 공통 인식을 확립할 뿐, 그것의 운영적 실체를 확립하지 않는다. 반환된 파일명은 그 파일이 존재한다는 것, 전송이 성공할 것이라는 것, 실행이 승인되었다는 것을 증명하지 않는다. 인코딩은 정보의 위치를 알려줄 뿐, 이후의 부팅 작업을 수행하지 않는다.

인스턴스는 여럿, 값은 하나

RFC 2131에는 달리 규정되지 않는 한 반복 옵션에 대한 제한과, 반복 값을 연결한다는 문구가 함께 있었다. RFC 3396은 일회 발생 문장을 명시적으로 삭제하고 분할 옵션의 구성과 해석을 정의했다. 이는 명확화이자 갱신이었으며, 모든 구형 구현체가 이미 일관되게 동작했다는 증거는 아니었다.

각 조각은 같은 옵션 코드와 자체 길이를 갖는다. 어떤 조각도 255옥텟을 초과하는 데이터를 담지 않는다. 조각들의 길이를 합하면 논리적 값의 길이가 되고, 각 인코딩된 인스턴스는 여전히 자신이 담긴 필드의 경계를 존중한다.

수신기는 코드와 길이의 껍데기가 아니라 데이터를 결합한다. 첫 인스턴스만 선택하거나, 마지막으로 덮어쓰거나, 모든 조각을 별개의 구성 항목으로 제시할 수 없다. 파일명 예시에서 7바이트와 6바이트는 13바이트짜리 경로 하나가 된다. 어느 조각도 쓸모 있는 대체 이름이 아니다.

분할 지점에 의미론적 중요성은 없다. 발신자는 어떤 옥텟 경계에서든 나눌 수 있다. 따라서 디코더는 해당 값의 규칙을 적용하기 전에 전체를 재구성해야 한다. 각 조각을 독립적으로 의미 있는 것으로 취급하면 패킹 결정이 구성 의미를 바꾸어 버린다.

논리적 순서가 물리적 순서에 우선했다

RFC 3396은 관련 시퀀스를 집합 옵션 버퍼라고 부르지만, 이 집합은 논리적이다. 실제 필드들은 제자리에 머문다. 공통 순서는 일반 옵션, 그다음 file, 그다음 sname이며, 선택되지 않은 빌려온 필드는 제외한다.

와이어에서는 sname이 file보다 앞서고, 둘 다 일반 옵션 영역보다 앞선다. 캡처한 패킷을 처음부터 읽으며 만나는 모든 인스턴스를 즉시 연결하면, 필드를 넘나드는 경우에 잘못된 시퀀스가 나온다.

수신기는 먼저 어느 필드가 유효한지 알아내고, 정의된 논리적 순서를 따르고, 그다음 일치하는 데이터 조각들을 결합한다. 저장 배치와 해석 순서는 달라도 된다. 다만 그 차이가 명시적이고 공유되어야 한다. 어떤 구현체가 우연히 쓰고 있던 스캐닝 루프에 맡길 수는 없다.

오버로드와 연결은 별개로 남는다. 빌려온 필드는 분할되지 않은 완전한 옵션을 담을 수 있다. 반복되는 조각이 오버로드 없이 일반 옵션 필드 안에 온전히 들어갈 수도 있다. 한 메커니즘은 허용되는 저장 위치를 늘리고, 다른 메커니즘은 여러 인코딩된 인스턴스에 걸친 논리적 값을 정의한다.

신중한 발신자라도 능력 있는 수신기가 필요했다

2002년 문서는 배포 제약을 기록했다: 당시 사용 중인 많은 DHCP 에이전트가 연결을 구현하지 않았다는 것이다. 문서는 필요하지 않거나 통신 상대가 결과를 처리할 수 있음을 알지 못하는 한 분할을 피하도록 권했다. 발행은 설치된 파서에 대한 원격 업그레이드가 아니었다.

이 연결 메커니즘을 요구하는 옵션을 제공하거나 요청한 뒤에는 상대가 능력 있다고 가정할 수 있었다. 관리자가 그 가정을 명시적으로 설정할 수도 있었다. 이는 새로운 범용 기능 비트가 아니었고, 당시의 관찰은 오늘날 기기 수에 대한 집계가 아니었다.

구현체는 연결이 필요한 옵션만 분할하도록 선택할 수 있었다. 그러나 그런 옵션을 지원하는 순간, 수신된 다른 옵션들의 조각도 연결할 수 있어야 했다. 출력의 단순함이 허용하는 입력 언어를 임의로 좁힐 허가권은 아니었다.

이 구분은 책임을 서로 다른 곳에 배정한다. 인코더는 분할이 정당한지, 호환성 가정이 뒷받침되는지 판단한다. 디코더는 수신된 표현에 공통 재구성 규칙을 적용한다. 어느 쪽도 로컬 선호로 공유 바이트 순서를 대체할 수 없다.

조립 후에만 존재하는 원점을 가진 포인터

같은 달인 2002년 11월의 동반 문서RFC 3397은 재구성을 제대로 해야 할 구체적인 이유를 제공한다. 코드 119의 도메인 검색 옵션은 반복된 옵션 인스턴스에 걸쳐 DNS 검색 목록을 운반할 수 있다. 공유 접미사를 반복해서 표기하지 않기 위해 DNS 방식의 이름 압축도 사용한다.

압축 오프셋은 완전히 연결된 데이터 부분을 기준으로 한다. 개별 옵션 코드와 길이는 제외한다. DHCP 패킷의 시작점부터 재거나 조각마다 0으로 초기화하지도 않는다.

따라서 모든 검색 목록 데이터는 해석 전에 논리적으로 결합되어야 한다. 라벨 안쪽에서 끝나는 조각은 반드시 기형적인 완전한 이름은 아니다. 애초에 완전한 항목이 아직 아니기 때문이다. 해석의 올바른 경계는 하위 수준의 조립 규칙이 확립한다.

이 예시는 DNS 압축의 전체 역사를 다시 이야기할 필요가 없다. 관련성은 의존성에 있다: 더 높은 수준의 좌표계는 더 낮은 수준의 재구성에 의존한다. 패킹 지름길은 모든 개별 조각이 그럴듯한 길이를 갖는 경우에도 의미를 훼손할 수 있다.

마찬가지로 올바른 재구성이 신뢰를 부여하지는 않는다. RFC 3397은 검색 목록이 짧은 이름으로 인해 다른 완전 한정 도메인을 선택하게 만들 수 있다고 경고하며, 그 다른 도메인에 유효한 DNSSEC 서명이 있어도 마찬가지다. 구문적 정확성과 호스트를 구성할 권한은 여전히 별개의 질문이다.

DHCP의 빌려온 필드는 재활용을 명시적으로 만드는 방식으로 작동했다. 오래된 경계가 사라진 것처럼 가장함으로써가 아니었다. 지속적인 합의는 단순히 더 많은 바이트를 쓸 수 있다는 것이 아니라, 모든 참여자가 그 바이트가 무엇을 의미하는지 결정하기 전에 어디에 속하는지 판단할 수 있다는 것이었다.