요약

  • RFC 3319는 로컬 SIP 아웃바운드 프록시를 찾기 위한 두 가지 DHCPv6 옵션, 즉 순서가 지정된 도메인 이름 목록과 순서가 지정된 IPv6 주소 목록을 정의했습니다.
  • 클라이언트는 두 목록이 모두 도착하면 이름을 우선하며 SIP 서버 위치 규칙을 적용합니다. 이 옵션들은 후보를 제공할 뿐, 신뢰할 수 있는 프록시나 완료된 통화의 증거가 아닙니다.

임대 응답은 전화 통화가 묻는 질문보다 더 좁은 질문에 답할 수 있었다

RFC 3319가 다룬 문제는 쉽게 잘못 서술될 수 있었습니다. SIP 클라이언트는 SIP URI에 적힌 주소를 알고 있더라도 로컬 아웃바운드 프록시가 필요할 수 있습니다. 방화벽, 로컬 다이얼 플랜, 긴급 서비스 등 다른 로컬 서비스가 그러한 중개자를 유용하게 만들 수 있습니다. 수동 구성이 하나의 답이었고, 이 RFC는 다른 답을 제시했습니다: DHCPv6가 클라이언트에게 후보 아웃바운드 프록시를 찾을 수 있는 위치를 알려주도록 하는 것입니다.

경계는 그 명사에 있습니다. 이 옵션은아웃바운드 SIP 요청을 위한 서버를 식별합니다. SIP 서비스 전체를 설명하지는 않습니다. RFC 3261은 사용자 에이전트, 프록시 서버, 리디렉션 서버, 등록 서버를 구분합니다. RFC 3319는 “SIP 서버”라는 말을 특히 아웃바운드 프록시를 실행하는 호스트를 가리키는 데 사용합니다. 그런 호스트들의 목록만으로는 사용자가 등록되었는지, 목적지가 승인되었는지, SIP 대화가 완료되었는지, 미디어가 협상되었는지, 통화가 성공했는지 보여줄 수 없습니다.

두 가지 인코딩, 하나의 우선순위 절차

RFC 3319는 도메인 이름 목록인OPTION_SIP_SERVER_D에 옵션 21을, IPv6 주소 목록인OPTION_SIP_SERVER_A에 옵션 22를 할당합니다. 두 목록 모두 우선순위에 따라 정렬됩니다. 이 사양의 구현은 두 옵션을 모두 지원해야 합니다. 클라이언트는 DHCPv6의 옵션 요청 옵션(ORO)으로 두 옵션 중 하나 또는 둘 모두를 요청할 수 있으며, 서버의 응답은 여전히 서버의 구성과 클라이언트가 요청한 내용에 따라 달라집니다. 둘 모두를 요청했더라도 서버는 하나만 반환할 수 있으며, 도메인 이름 옵션을 우선해야 합니다.

두 목록이 모두 도착하면 클라이언트는 도메인 이름을 먼저 사용해야 합니다. 숫자 주소는 조건부 대체 수단입니다. 클라이언트는 첫 번째 목록의 어떤 이름도 확인하거나 도달할 수 없을 때에만 시도할 수 있습니다. 이는 “가능한 모든 주소를 시도한다”는 것보다 더 구체적인 규칙입니다. 클라이언트는 이후의 모든 이름을 즉시 확인하지도 않습니다. 목록을 우선순위 순서대로 따라가며, 이전 시도가 실패하거나 양측이 공유하는 전송 계층을 산출하지 못하거나 클라이언트 정책의 금지 규정에 해당할 때 다음으로 넘어갑니다.

이름은 SIP 위치 결정의 입력이었지, 그 대체물이 아니었다

도메인 이름 옵션은 RFC 3263이 기술한 서버 위치 동작에 입력됩니다. 목록의 이름들은 단순히 서로 다른 A 레코드가 아니라 서로 다른 NAPTR 레코드를 가리켜야 합니다. RFC 3319는 단일 DHCP 서버가 이를 통해 여러 공급자가 운영하는 프록시를 표시할 수 있다고 언급합니다. 하지만 이 옵션은 NAPTR이나 SRV 레코드를 대체하지 않습니다. 시작이 되는 도메인 집합을 제공할 뿐이며, 이후에도 SIP 위치 메커니즘과 전송 규칙이 여전히 중요합니다.

이 순서에서 “대체(fallback)”라는 단어는 실질적인 역할을 합니다. 패킷에 나중 도메인이 등장했다고 해서 자동으로 백업이 되는 것은 아닙니다. 클라이언트는 정의된 조건이 충족된 후에야 그 도메인에 도달합니다. 도메인 이름도 함께 제공된 경우 숫자 IPv6 목록은 우선순위 경로에서 더 아래에 놓입니다. 클라이언트 정책이 특정 이름을 배제할 수도 있습니다. 따라서 DHCP 목록은 목적지 후보와 정렬 순서를 모두 전달하지만, 확인·전송·허용 가능한 사용에 대한 결정은 클라이언트가 유지합니다.

이는 유용한 제어 평면의 분업입니다. 네트워크는 모든 클라이언트에 하나의 프록시를 하드코딩하지 않고도 로컬 서비스 선택을 배포할 수 있습니다. 그러나 그 응답이 나열된 호스트가 응답하는지, 상호 사용 가능한 전송을 말하는지, 이 사용자의 요청을 수락하는지, 세션의 나머지를 전달할 수 있는지를 확립하지는 못합니다. “선호하도록 구성됨”과 “성공적으로 사용됨”은 서로 다른 관찰입니다.

구성은 신뢰가 재지향될 수 있는 지점이기도 하다

보안 절에서 이 경계의 중요성이 드러납니다. 공격자가 DHCP 응답을 수정하거나 거짓 응답을 삽입하면 사용자 에이전트가 불량 SIP 서버로 유도될 수 있습니다. 그런 서버는 통화 요청을 가로채거나 서비스를 거부할 수 있습니다. 변조된 응답은 TLS 지원 SIP 서버로 이어질 수 있었던 호스트 이름을 생략하여 가로채기를 용이하게 할 수도 있습니다.

이는 RFC의 위협 모델이지 사고 보고가 아닙니다. RFC는 임의로 수신한 주소가 진짜라고 하거나, 구성된 모든 이름이 TLS로 확인된다고 말하지 않습니다. 이 옵션은 신뢰 사슬의 일부입니다. DHCP 응답은 애플리케이션이 다음에 신호를 보낼 위치에 영향을 줍니다. 그 사슬에는 여전히 더 넓은 시스템이 요구하는 보호 장치, 신원 확인 및 정책이 필요합니다. 서버를 찾는 것은 그 서버를 인증하는 것이 아닙니다.

오래된 옵션은 더 새로운 DHCPv6 기록에도 여전히 보인다

DHCPv6 사양은 이후 발전했습니다. RFC 9915가 현재의 일반 사양이며 RFC 8415를 대체했습니다. 그럼에도 IANA DHCPv6 옵션 코드 레지스트리는 여전히 코드 21과 22를 RFC 3319 아래에 기록하고 있으며, RFC 9243은 나중에 두 SIP 서버 옵션 형식에 대한 YANG 구성 그룹을 제공합니다. 이러한 기록은 지속적인 행정적·데이터 모델 참조를 보여줍니다. 이는 운영자 사용, 클라이언트 지원, 성공적인 대체 동작 또는 통화 완료를 측정하지 않습니다.

RFC 3319의 기여는 “DHCP가 전화 서버를 찾아준다”는 것보다 더 좁고 더 흥미로웠습니다. 클라이언트가 로컬 아웃바운드 프록시를 발견하는 순위화된 방법, 즉 도메인 이름 우선 경로와 주소 목록 대체 경로를 형식화한 것입니다. 최종 통화는 그 옵션 밖에 남아 있었습니다. 발견은 신호가 어딘가를 향하도록 할 수 있었지만, 그 다음에 무슨 일이 일어났는지 보증할 수는 없었습니다.

출처