요약

  • RFC 3442는 DHCPv4 옵션 121에 명시적인 프리픽스 길이를 갖는 경로를 전달하는 방법을 제공하여, 구버전 고정 경로 옵션의 클래스 기반(classful) 가정을 바로잡았습니다.
  • 이를 지원하는 클라이언트는 해당 경로를 설치하고, 여러 옵션이 함께 도착했을 때 Router 옵션과 옵션 33보다 우선해야 했으며, RFC는 잘못된 다음 홉이 트래픽을 잘못된 경로로 보낼 수 있다고 경고했습니다.

주소 임대는 대개 하나의 할당처럼 들립니다. 네트워크가 호스트에게 어떤 주소를 사용할 수 있고 얼마나 유지할 수 있는지 알려주는 것이죠. 하지만 호스트는 로컬이 아닌 패킷을 어디로 보낼지도 알아야 합니다. RFC 3442는 이 두 번째 결정을 DHCP의 구성 대화의 일부로 만들었습니다. 이 클래스리스 고정 경로 옵션은 목적지 프리픽스와 그에 도달하기 위한 라우터 주소를 함께 전달할 수 있었습니다.

이 변화는 하나의 불일치를 해소했습니다. RFC 2132에서 정의된 DHCP 옵션 33은 목적지마다 별도의 마스크 없이 고정 경로를 기술했습니다. 네트워크 경계를 주소 클래스에서 추론할 수 있던 시절에는 그것이 자연스러웠습니다. 그러나 클래스리스 라우팅이 그 가정을 대체했습니다.10.0.0.0/8과10.0.0.0/24는 네트워크 번호의 시작이 같아도 서로 다른 목적지입니다. 클라이언트가 어떤 비트가 경로를 정의하는지 알려면 프리픽스 길이가 필요합니다.

옵션 121은 그 범위를 압축적으로 인코딩했습니다. 목적지 기술자는 프리픽스 너비로 시작해 의미 있는 주소 옥텟만 담았고, 그 뒤에 4바이트 라우터 주소가 이어졌습니다. 클라이언트는 목적지를 재구성하고 마스크 밖의 비트를 0으로 만든 뒤 경로를 설치했습니다. RFC 3442는 DHCP를 라우팅 프로토콜로 만들거나 인터넷 라우팅 테이블을 배포한 것이 아닙니다. 이미 호스트 구성을 제공하던 서버를 통해 관리자가 선택한 고정 경로를 클라이언트에 설치할 수 있도록 한 것입니다.

그로 인해 중요한 결정 하나가 관리 경계를 넘어 이동했습니다. 경로 테이블은 여전히 호스트에 존재했고, 클라이언트는 여전히 자신의 처리 규칙을 적용했습니다. 그러나 이제 경로가 장치를 직접 편집하던 사람이 아니라 DHCP 서버 구성에서 시작될 수 있게 되었습니다. 옵션 121을 지원하는 클라이언트에 대해 RFC는 로컬 서브넷 예외를 조건으로 해당 경로의 설치를 요구했습니다. 새 옵션이 구버전 Router 옵션이나 옵션 33과 함께 나타나면 클라이언트는 구버전 값을 무시해야 했습니다. 클라이언트가 옵션을 요청하는 순서도 중요했습니다. 파라미터 요청 목록에서 옵션 121은 Router와 옵션 33보다 앞서야 했습니다.

호환성은 설계의 일부였습니다. 옵션 121을 구현하지 않는 클라이언트는 이를 무시해야 했습니다. 따라서 RFC 3442는 관리자가 구버전 클라이언트를 위해 Router 옵션도 함께 보내 기본 라우터 정보를 중복 전달할 것을 권고했습니다. 이는 전환 전략이었을 뿐, 얼마나 많은 장치가 새 옵션을 지원했는지 또는 네트워크가 얼마나 빨리 채택했는지에 대한 증거는 아닙니다. 사양은 안전한 우선순위 규칙을 정의할 수 있지만, 모든 클라이언트가 그 규칙을 구현하도록 만들 수는 없습니다.

그 경계에는 보안적 함의도 있었습니다. RFC 3442는 잘못된 라우터 주소가 서비스 거부를 일으키거나 트래픽을 도청자를 통해 우회시킬 수 있다고 명시적으로 경고했습니다. 이 위험은 옵션 121에만 고유한 것이 아니었고, 구버전 경로 및 라우터 옵션 역시 잘못된 다음 홉을 가리킬 수 있었습니다. 옵션 자체는 제안된 경로가 승인되었거나, 올바르거나, 안전하다는 것을 증명하지 못했습니다. 사용되는 경우 메시지 인증은 별개의 DHCP 메커니즘이었고, 그것만으로 경로 선택이 현명했다는 것을 입증하지 못합니다.

패킷 크기조차 이 인계 과정에 영향을 미쳤습니다. 큰 경로 목록은 전통적인 DHCP 메시지 크기를 초과할 수 있었기에, RFC 3442는 더 큰 메시지 협상을 논의하고 긴 옵션 연결(concatenation) 지원을 요구했습니다. 여러 IP 서브넷이 공유 링크에 존재하는 경우에는 다음 홉0.0.0.0을 직접 도달 가능한 로컬 서브넷을 표시하는 특수 용도로 정의했으며, 필요한 스택 동작이 없는 클라이언트는 해당 항목을 무시해야 했습니다.

RFC 3442의 역사적 이동은 절제되었지만 시사하는 바가 컸습니다. 네트워크 라우팅이 클래스리스가 되는 순간, 주소 구성에도 경로 범위를 표현할 방법이 필요해졌습니다. 임대는 로컬 포워딩 정책의 가능한 운반체가 되었습니다. 클라이언트는 설치 지점으로 남았고, 서버 관리자는 경로를 설정하는 주체가 되었으며, 다음 홉 결정은 주소 할당을 넘어선 결과를 지니게 되었습니다.

출처