요약

  • RFC 3679는 IANA로 반환될 수 있는 제안용 옵션 코드와, 공개된 RFC 설명은 없지만 이미 사용 중이던 PXE 및 Apple 코드를 구분했다.
  • RFC 3942는 사설 범위 코드에 대한 전환 절차를 제공했고, RFC 8910은 실험에서 Polycom의 충돌 용도가 드러난 뒤 캡티브 포털 신호를 코드 160에서 옮겼다. 레지스트리 항목은 조정을 기록할 뿐, 배치된 기기의 조사 결과가 아니다.

빈 참고문헌이 빈 네트워크는 아니었다

DHCP 옵션은 주소 구성 과정에서 전달되는 간결한 지시 사항으로, 클라이언트는 이를 통해 서브넷 마스크, 라우터 주소, 기타 서비스 매개변수 등을 받을 수 있다. 그 번호들은 공유된 이름공간이다. 버려진 제안이 한 번호를 영원히 점유하면 이후 작업의 공간이 줄어들고, 실제 배치된 옵션이 재할당되면 두 기기가 같은 필드를 다르게 해석할 수 있다.

2004년 1월 RFC 3679는 이 문제의 양면을 다루었다. 제안이 만료되었거나 공개된 정의에 도달하지 못했거나 당시 페일오버 프로토콜에서 더 이상 사용되지 않는 기존 할당을 나열하며, 이 코드들은 IANA의 사용 가능 풀로 반환될 수 있었다. 그러나 별도 항목에서는 PXE 옵션 코드 93, 94, 97이 공개된 RFC 없이도 널리 사용되고 있음을 기술했고, 95와 112–114의 Apple 용도를 RFC 문서 없이 언급했다. 이 문서는 DHC 워킹 그룹이 처리 방향을 검토하는 동안 이들이 할당된 상태로 남도록 요청했다. 핵심 근거는 공개 상태만이 아니라 보고된 사용이었다.RFC 3679

이 구분은 의도적으로 신중한 것이었으며, 문서화되지 않은 사용이 영구적 공개 번호를 얻는다는 일괄 규칙이 아니었다. 이 RFC는 회수 이유를 개별적으로 나열하고 알려진 PXE 및 Apple 사례를 다르게 다루었다. IANA 지침은 회수 가능 코드를 미할당 번호와 이전에 반환된 번호가 소진된 뒤에야 풀로 돌려보내도록 했다. 이는 Informational 메모이며, 언급된 모든 구현이 여전히 존재하거나 모든 할당이 현장에서 해결되었다는 증명이 아니었다.RFC 3679 상태

목록에서 전환 절차로

같은 해 늦게 RFC 3942는 사설 용도로 예약되어 있던 상위 범위를 재분류하면서 공개적으로 정의된 DHCPv4 옵션 공간을 1–127에서 1–223으로 넓혔다. 이 조치로 기존의 로컬 구성이 사라지지는 않았다. 따라서 표준은 전환을 도입했다. 알려진 사설 용도를 가진 코드는 벤더가 워킹 그룹과 IANA에 통보하는 동안 사용 불가로 표시될 수 있었고, 잠정적 공개 할당에는 6개월 통보 기간과 18개월 Internet-Draft 마감이 부과되었다. 사이트는 남은 사설 용도 범위로 이동하도록 권장되었다.RFC 3942

충돌 규칙은 더 엄격했다. 여러 벤더가 같은 번호를 상당히 널리 사용하고 있다고 보이면, 어느 누구도 그것을 자신의 사설 코드로 계속 유지할 수 없었고 각자 정상적인 공개 할당을 요청해야 했다. 이는 사설 사용을 불법으로 선언한 것이 아니다. 각 벤더가 자국에서 사용했다는 이유만으로는 하나의 번호가 두 가지 호환되지 않는 의미를 조정할 수 없다는 점을 인정한 것이다. RFC 3942는 또한 초기 도입자에게 부담을 주는 16비트 확장이나, 호환성과 발견 비용을 늘리는 새로운 형식 또는 매직 쿠키 같은 대안을 기각했다.

이 구분을 구체적으로 만든 뒤의 충돌

RFC 4578은 이후 PXE 옵션 93, 94, 97이 널리 사용된다고 기술하면서도, PXE 클라이언트가 PXE용으로 공식 할당되지 않은 코드 128–135를 요청하며 같은 네트워크의 다른 용도와 충돌할 수 있다고 밝혔다. 이는 유용한 경계선이다. 클라이언트에서 관찰된 요청 자체가 코드를 공식 할당으로 만들지는 않는다.

더 명시적인 사례는 캡티브 포털에서 왔다. RFC 7710은 처음에 DHCPv4 옵션 160으로 포털 URI를 알렸다. IETF 106 네트워크 실험에서 일부 Polycom 기기가 160을 다른 목적으로 사용했고, 그곳에 포털 URI를 실으면 이 기기들이 의도대로 작동하지 않았다. RFC 8910은 그래서 캡티브 포털 신호를 옵션 114로 옮기고, RFC 3679를 갱신하며, 알려진 Polycom 사용을 기록한 채 160을 Unassigned로 반환했다. 저자들은 이 실험에서 관찰된 충돌을 기술할 뿐, 모든 네트워크에서의 보급률을 주장하지 않는다.RFC 7710RFC 8910

현재 IANA 표는 여러 번호의 사후 상태를 보여준다. 83은 이후 iSNS를, 88과 89는 이후 BCMCS 옵션을 담고, 114는 Captive-Portal이며, 96은 여전히 미할당이다. 126과 127도 미할당으로 표시되어 있다. 이는 레지스트리 상태이며, 어떤 코드가 모든 실제 네트워크에서 침묵한다는 증거가 아니다. 뒤따른 할당이 이전 구현이 모두 사라졌음을 증명하지도 않는다.IANA BOOTP/DHCP ParametersRFC 4174RFC 4280

Lu Heng의 후속 노트 72는 좁은 개념적 공명을 제공한다. 조정 기록과 운영 현실은 서로 다른 종류의 근거라는 점이다. 이 노트는 DHCP가 아니라 인터넷 번호의 고유성을 다루며, 이 RFC 결정들을 야기하거나 승인하지 않았다. 여기서 실용적 교훈은 DHCP 기록 자체에서 나온다. 번호를 회수하려면 사용에 관한 근거가 필요하고, 재할당은 사무적 수정이 아니라 전환 문제라는 것이다.노트 72

출처

추가 프로토콜 맥락