요약

  • RFC 3361은 DHCPv4 옵션 120에 두 가지 상호 배타적인 인코딩을 부여했다. 로컬 SIP 아웃바운드 프록시를 위한 선호되는 DNS 이름 목록과, 순서가 정해진 IPv4 주소 목록이 그것이다.
  • 이름 형태는 전송 방식, 포트, 인스턴스 선택 및 폴백을 DNS 서비스 레코드에 위임할 수 있었다. 주소 형태는 호스트 순서를 고정했다. 유효한 옵션도, 성공한 리스도 이후의 SIP 트랜잭션이나 통화 경로를 증명하지는 못했다.

네트워크 리스는 시작 지점에서 도착하기 때문에 마치 답처럼 보일 수 있다. 클라이언트는 주소와 라우터, 어쩌면 리졸버를 받고, RFC 3361에 따라 아웃바운드 SIP 요청을 보낼 곳까지 받는다. 이 패킷은 범위가 한정된 구성 교환 안에서는 권위를 갖는다. 그 권위를 동작하는 통화까지 확장하고 싶어지는 유혹이 생긴다.

그러나 프로토콜은 그런 확장을 만들지 않았다. 프로토콜이 제공한 것은 시작 좌표였다.

2002년 8월 Standards Track으로 공개된 RFC 3361은 로컬 SIP 아웃바운드 프록시를 위한 DHCPv4 옵션 120을 정의했다. SIP 클라이언트는 경우에 따라 SIP URI에 지정된 대상에 직접 연락할 수 있었다. 방화벽이 있는 환경 등 다른 환경에서는 아웃바운드 요청을 위한 로컬 서버가 필요했다. DHCP는 여러 발견 방법 중 하나였고, 수동 구성은 여전히 또 하나의 방법이었다.

옵션에는 작지만 결과가 큰 스위치가 있었다. 코드와 길이 뒤에 인코딩 바이트가 오는 자리였다. 0이면 나머지 값은 DNS 도메인 이름들의 연속이었다. 1이면 하나 이상의 이진 IPv4 주소였다. 구현체는 문서가 이름 형태를 선호한다고 해도 두 형태를 모두 지원해야 했다.

이 둘은 같은 사실의 두 표기법이 아니었다. 도메인 이름은 RFC 3263이 정의한 SIP 서버 위치 절차로 이어질 수 있었다. 그 절차는 NAPTR 레코드로 지원되는 전송 방식을 발견하고, SRV 레코드로 포트·우선순위·가중치를 가진 서비스 인스턴스를 식별하며, 주소 레코드를 폴백으로 사용했다. 클라이언트는 도메인이 제공하는 것과 자신이 사용할 수 있는 전송 방식의 교집합을 만들었다. 이름은 계속 변하는 서비스 발견 그래프에 대한 위임이었다.

IPv4 목록은 더 좁은 것을 담았다. 주소들은 선호도 순으로 정렬되어 있었다. 클라이언트는 한 호스트를 시도한 뒤 다른 호스트를 시도할 수 있었지만, 옵션 120 자체는 NAPTR 서비스, SRV 포트, 우선순위, 가중치, 전송 방식 메타데이터를 전혀 제공하지 않았다. 정렬된 주소 목록은 서비스 기술서라기보다 후보 호스트로 향하는 얼어붙은 경로에 가까웠다.

이 구분은 다음 결정을 누가 바꿀 수 있는지를 바꿔 놓았다. 도메인이 있으면 DNS 관리자는 새 DHCP 리스를 발행하지 않고도 인스턴스 간에 서비스를 옮기고, 광고된 전송 방식을 바꾸고, SRV 순서를 조정할 수 있었다. 리터럴 주소 목록에서는 그 선택의 상당 부분을 DHCP 관리자가 옵션 안에서 쥐고 있었다. 어느 모델도 클라이언트 정책, 소프트웨어 능력, 캐시된 상태, 실패를 없애지 못했다. 둘은 레버를 서로 다른 곳에 놓았을 뿐이다.

RFC 3361은 여러 도메인 이름에도 특정한 의미를 부여했다. 그 이름들은 같은 도메인의 여러 A 레코드가 아니라 서로 다른 NAPTR 도메인을 대표해야 했다. 클라이언트는 나열된 순서대로 시도했다. 첫 번째에 연락이 실패하거나, 공통 전송 방식이 없거나, 클라이언트 정책이 그 도메인을 금지할 때만 다음 이름으로 넘어갔다. 이 기능은 하나의 DHCP 권위가 서로 다른 사업자가 운영하는 아웃바운드 프록시를 지정할 수 있게 해 주었다. 그것은 사업자 내부의 NAPTR·SRV 부하 분산을 대체하려는 것이 아니었다.

따라서 순서는 여러 층에 존재했다. DHCP는 사업자 도메인들의 순서를 정했다. NAPTR은 전송 서비스들의 순서를 정했다. SRV는 인스턴스들 사이에 우선순위와 가중치를 적용했다. 주소 확인은 도달 가능한 후보들을 만들어냈다. 클라이언트의 능력과 정책은 받아들일 수 없는 선택을 제거했다. “구성된 프록시” 같은 한 구절은 이 모든 선택기를 감춘다.

RFC 3263은 중요한 트랜잭션 경계를 더했다. 어떤 SIP 서버가 트랜잭션에 대해 성공적으로 접촉되면, 재전송, CANCEL, 비-2xx 최종 응답에 대한 ACK는 같은 서버에 머물러야 했다. 발견 절차는 접촉 전에 후보들 사이에서 선택할 수 있었지만, 상태가 생긴 뒤에는 하나의 트랜잭션을 무작위로 흩을 수 없었다. 변하는 DNS 응답과 한 트랜잭션이 선택한 상대방은 서로 다른 시계에 속했다.

옵션 형식은 구문과 의미 사이의 또 다른 경계를 드러냈다. DHCP 서버는 하나의 메시지 안에서 DNS 인코딩과 IPv4 인코딩을 섞는 것이 금지되었으며, 옵션 120을 별도 인스턴스로 넣는 방식으로도 그럴 수 없었다. DHCP 처리는 반복되는 같은 옵션의 발생들을 해석하기 전에 이어 붙인다. 서로 다른 첫 바이트 문법을 가진 두 개의 국소적으로 잘 형성된 조각은 하나의 기형적인 의미 객체가 되어버린다.

이 금지 조항은 더 넓은 DHCP 문제를 예견한 것이었다. 같은 해 후반에 발행된 RFC 3396은 반복되는 DHCPv4 옵션의 연결 순서를 표준화하고, 긴 값이 옵션 인스턴스들과 과적합 필드에 걸쳐 있도록 허용했다. 또한 불편한 배포 현실을 기록했다. 당시 쓰이던 많은 DHCP 에이전트는 옵션 연결을 구현하지 않았다. 송신자가 긴 옵션 규칙을 따르더라도 허용된 값을 재구성할 수 없는 수신자를 만날 수 있었다.

RFC 3361은 하나의 옵션 용량보다 긴 DNS 이름 목록은 그 메커니즘을 사용하도록 요구했다. 따라서 DNS가 시작되기 전에도, 긴 사업자 목록은 올바른 DHCP 조각 순서화와 재조립에 의존했다. “서버가 보냈다”와 “클라이언트가 같은 옵션을 파싱했다”는 별개의 주장이었다.

이듬해의 DHCPv6 설계는 그 절충을 바꿔 가시화했다. RFC 3319는 SIP 서버 도메인 이름용과 IPv6 주소용이라는 두 개의 옵션 코드를 정의했다. DHCPv6에는 옵션 코드 부족이 없으므로 IPv4의 인코딩 바이트를 피할 수 있다고 명시했다. 별도 옵션은 파싱을 짧고 단순하게 만들고, 숫자 주소의 정렬을 개선했으며, 클라이언트가 원하는 형태를 요청할 수 있게 했다. 한 네임스페이스의 희소성이 다른 프로토콜 메시지의 복잡성을 형성했던 것이다.

DNS 인코딩에는 그만의 역사적 야망이 실려 있었다. RFC 3361은 RFC 1035 레이블 인코딩을 사용하고, 부분적으로는 미래의 국제화 도메인 이름 메커니즘을 수용하기 위해 클라이언트가 DNS 압축을 지원하도록 요구했다. 이름 아래의 서비스 레코드는 RFC 2782의 SRV 모델과 RFC 3403에서 형식화된 NAPTR 레코드에 기반했다. 옵션 120이 작았던 이유는 더 크고 독립적으로 유지되는 기계 장치를 가리킬 수 있었기 때문이다.

그 간접 참조는 유연성과 신뢰를 동시에 키웠다. RFC 3361은 DHCP 응답을 수정하거나 삽입할 수 있는 공격자가 사용자 에이전트를 악성 SIP 서버로 유도하여 가로채기나 서비스 거부를 가능하게 할 수 있다고 경고했다. 수정된 응답은 TLS 기반 SIP 서버로 해석될 호스트 이름을 생략하여 가로채기를 더 쉽게 만들 수도 있었다. 구성 소스는 미디어를 실어 나르지 않았지만, 클라이언트가 어떤 시그널링 관문에 접근할지, 그리고 선택에 앞서 어떤 더 안전한 가능성이 사라질지를 결정할 수 있었다.

현재의 IANA BOOTP 및 DHCP 파라미터 레지스트리는 여전히 코드 120을 SIP Servers DHCP Option으로 기록하고 있다. 그것은 내구성 있는 조정 기록이다. 그 기록이 증명하는 것은 코드의 등록된 연관성이지, 특정 서버가 이를 보내는지, 클라이언트가 요청하는지, 구현체가 두 형태를 파싱하는지, 오늘날 어떤 네트워크가 이를 사용하는지가 아니다.

같은 절제는 관찰된 리스에도 적용된다. 패킷 캡처는 옵션 120이 특정 바이트와 함께 도착했다는 것을 증명할 수 있다. 디코더는 그 바이트가 이름 목록인지 주소 목록인지를 증명할 수 있다. 그러나 어느 쪽도 DNS가 레코드를 반환했다는 것, 선택된 전송 방식이 클라이언트 능력과 겹쳤다는 것, 연결이 열렸다는 것, 프록시가 SIP 트랜잭션을 받아들였다는 것, 다운스트림 프록시가 대상을 찾았다는 것, 세션 협상이 완료되었다는 것, 미디어가 흐르었다는 것을 증명하지 않는다.

각 층에는 자기만의 영수증이 필요하다. DHCP 서버와 릴레이 경로, 원시 옵션 바이트, 인코딩과 순서를 보존하라. 이름이었다면 TTL과 클라이언트의 필터링된 선택을 포함해 NAPTR, SRV, A 또는 AAAA 응답을 보존하라. 주소였다면 시도 순서, 포트, 전송 방식을 보존하라. 그 다음에 프록시 접촉, 트랜잭션 응답, 다운스트림 라우팅, 세션 기술서 협상, 미디어를 별도로 기록하라.

여기서 Lu Heng의 두 에세이는 공개된 분석적 렌즈로 사용된다. “Minimum Initial Specification”은 사업자 운영, DNS 정책, 배포 결정을 로컬에 남겨두는 좁은 공통 옵션의 가치를 설명하는 데 도움이 된다. “Reality Layers”는 등록된 코드, 전달된 구성, 해석된 서비스, 구동 중인 구현, 통화 결과가 하나의 주장으로 무너지지 않게 해 준다. 이들은 편집적 독해이며, RFC 3361의 저작이나 의도에 대한 주장이 아니다.

옵션 120은 랑데부를 만들기에 딱 그만큼만 했다. 두 인코딩은 또한 랑데부가 살아 있는 이름 지정 시스템에 위임될 수도, 주소 순서로 얼려질 수도 있음을 보여주었다. 리스는 시그널링이 어디서 시작해야 하는지 이름으로 밝혔다. 시그널링이 계속되는지는 다음 근거 층의 문제였다.

출처