요약

  • RFC 9928은 DHCP 4o6을 인지하지 못하는 IPv4 전용 클라이언트를 위해 DHCPv4-over-DHCPv6 릴레이 에이전트가 캡슐화와 역캡슐화를 수행하도록 허용한다.
  • 이 기능을 중간 노드로 옮기면 DHCPv6 토폴로지 탐지에서 레이어-2 액세스 지점이 가려질 수 있다. RFC는 백투백(back-to-back) 구성의 4o6RA와 LDRA를 권고하지만, 두 기능 간 내부 인터페이스 정보 교환은 범위에서 제외한다.
  • 임대 성공은 할당과 반환 경로가 완료되었음을 증명할 뿐이다. 그것만으로 어느 액세스 포트가 관측되었는지, 어떤 불투명 Interface-ID가 그 포트를 표현했는지, 어느 서버 규칙이 그 값을 사용했는지, 직접 DHCPv4 경로가 릴레이를 우회했는지는 증명하지 못한다.
  • 릴레이 보관 영수증은 인그레스 관측, 캡슐화, LDRA Interface-ID, 중첩 릴레이 순서, 할당 규칙, 반환된 구성, 전달, 우회 탐지, 만료 또는 정정을 하나로 연결해야 한다.

주소는 동작하지만 포트는 보이지 않는다

레이어-2 프론트홀 스위치를 통해 접속된 IPv4 전용 무선국(radio unit)을 생각해 보자. 이 장치는 평범한 DHCPv4 요청을 브로드캐스트하고 주소, 기본 경로 및 기타 구성을 받는다. 트랜잭션은 녹색이다. 장치는 트래픽을 보낼 수 있다. 그러나 주소 풀이나 구성은 더 이상 DHCPv6 서버에 도달하지 않는 토폴로지 근거를 근거로 선택되었을 수 있다.

문제는 호환성을 위한 유용한 조치에서 시작된다.RFC 7341은 DHCPv4 over DHCPv6, 즉 DHCP 4o6을 정의한다. 원래 아키텍처에서는 기능을 갖춘 클라이언트가 DHCPv4 메시지를 DHCPv6 안에 넣고 IPv6 전송에 직접 참여한다. 레거시 IPv4 전용 장치는 그렇게 할 수 없다.

2026년 3월 IETF Standards Track으로 발표된RFC 9928은 이 기능을 릴레이로 옮긴다. 4o6RA는 클라이언트의 DHCPv4 메시지를 받아DHCPV4-QUERY를 생성하고, 요청을 캡슐화하여 DHCP 4o6 지원 서버 쪽으로 보낸다. 반환 경로에서는DHCPV4-RESPONSE를 검사하고 유효한 DHCPv4 메시지를 추출해 요청한 클라이언트로 전달한다.

레거시 클라이언트에게는 익숙한 교환이 보인다. 클라이언트는 자신의 요청이 다른 프로토콜에 의해 네트워크 일부를 통과했다는 사실을 명시적으로 알지 못한다. 그것이 바로 이 기능의 목적이다. 소프트웨어 변경 없이 구형 장비가 새로운 서비스에 접근한다. 동시에 이는 클라이언트가 캡슐화가 발생했는지, 의도된 릴레이 경로가 사용되었는지, 릴레이의 토폴로지 진술이 실제 접속을 정확히 기술했는지 증언할 수 없다는 뜻이기도 하다.

릴레이 경로는 할당 입력의 일부다

DHCP는 흔히 주소 배분 프로토콜로 소개된다. 운영적으로 서버는 더 좁은 질문에 답해야 할 수 있다. 네트워크의 이 지점에는 어느 구성이 속하는가?RFC 7969는 릴레이가 원래 요청이 어디에 도착했는지 알고 있으며, 서버가 적절한 주소 풀과 매개변수를 고르는 데 도움이 되는 정보를 제공할 수 있다고 설명한다.

토폴로지 문법은 서로 다르다. DHCPv4에서는 첫 번째 릴레이만giaddr을 설정해야 하므로, 다중 릴레이 경로는 토폴로지의 일부만 운반한다. DHCPv6는 중첩된 순서를 보존할 수 있다. 릴레이들은link-address와 필요한 경우Interface-ID를 기여하고, 연속된 Relay-forward 봉투가 서버를 향한 경로를 드러낸다. 반환 경로는 이 봉투들을 역순으로 푼다.

이 구분은 4o6 기능이 클라이언트에서 멀어질 때 중요해진다. RFC 9928은 DHCP 4o6을 IPv6 네트워크 가장자리에 두면 DHCPv6 릴레이로부터 레이어-2 네트워크가 가려진다고 명시한다. 4o6RA만 있는 구성은 캡슐화된 메시지 안에 인터페이스 정보를 제공하지 않는다. DHCP 교환은 여전히 잘 형성되고 완전할 수 있지만, 토폴로지 의존적 서버가 필요로 하는 입력은 없다.

결과가 뻔한 실패일 필요는 없다. 넓은 폴백 풀이 사용 가능한 주소를 돌려줄 수 있다. 기본 구성이 부분 서비스를 허용할 수 있다. 눈에 보이는 임대는 서버가 결정을 내렸고 응답이 돌아왔음을 증명할 뿐이다. 그 결정이 의도된 물리적 액세스 지점을 근거로 사용했음을 증명하지는 않는다.

LDRA는 보관 고리를 회복할 뿐, 보편적 이름이 아니다

RFC 9928은 4o6RA를 경량 DHCPv6 릴레이 에이전트(LDRA)와 백투백 구조로 결합할 것을 권고한다. LDRA는 클라이언트 접속 인터페이스에 대한 정보를 얻어 나가는DHCPV4-QUERY에Interface-ID를 추가한다. 이를 통해 DHCPv6 릴레이 경로가 결여된 레이어-2 관측을 운반할 수 있다.

RFC 6221은 이 값에 규율 있는 의미를 부여한다. LDRA는 모든 Relay-forward에Interface-ID를 포함해야 한다. 이 값은 클라이언트 메시지가 수신된 인터페이스를 식별하며, 재시작 전반에 걸쳐 해당 인터페이스에 대해 안정적으로 유지되어야 하고, 서버는 매개변수 할당 정책에서 이를 사용할 수 있다.

그러나Interface-ID는 불투명하다. 서버는 이를 이식 가능한 설명으로 해석하지 말고 정확히 비교해야 한다. 한 시스템에서 “액세스 노드 A의 7번 포트, 매핑 세대 42”를 의미하는 옥텟 문자열이 와이어상에서 그 의미를 알려주지는 않는다. 따라서 운영 근거에는 양쪽이 필요하다. 프로토콜 경계를 넘은 불투명 값과, 어떤 관측된 액세스 지점이 그 값을 만들어냈는지 설명하는 로컬 매핑이다.

RFC 9915는 서버가 Relay-reply에서Interface-ID를 되돌려 보내도록 요구한다. 릴레이는 이 값을 사용해 클라이언트 접속 인터페이스를 고른다. 보관(custody)은 양방향으로 흐른다. 관측이 불투명한 토큰이 되고, 토큰은 특정 중첩 릴레이 계층에 놓이며, 서버 정책이 그것을 소비할 수 있고, 되돌려진 값이 최종 전달을 안내한다.

해결되지 않은 경계는 의도적으로 로컬이다

표준은 상호운용 가능한 메시지를 기술하지만, RFC 9928은 결정적인 경계를 구현에 맡긴다. 4o6RA가 LDRA에 인터페이스 정보를 넘기는 내부 메커니즘은 범위 밖이다. 그 형식과, 그 정보가 4o6RA의 개입 여부를 말하는지에 대한 질문도 범위 밖이다.

이는 발명된 와이어 필드로 메워야 할 프로토콜 공백이 아니다. 배포 책임이다. 한 장치가 두 기능을 하나의 프로세스로 구현할 수 있다. 다른 배포는 스위치 실리콘, 에이전트, 제어평면 서비스를 결합할 수 있다. 두 경우 모두 표준에 부합하면서 내부 인계에 관한 극히 다른 근거를 만들어낼 수 있다.

따라서 영수증은 RFC가 이를 표준화하는 것처럼 가장하는 대신, 구현 경계와 매핑 세대를 식별해야 한다. 4o6RA가 무엇을 관측했는지, LDRA에 무엇을 넘겼는지, LDRA가 어떤 불투명 값을 내보냈는지, 그리고 배포가 결여되었거나 오래된 매핑을 어떻게 탐지할지 기록해야 한다.

RFC 9928은 단순한 경우도 보존한다. 같은 노드가 4o6RA와 DHCP 4o6 서버를 함께 호스팅하면 4o6RA만으로 충분할 수 있다. “모든 곳에 LDRA를 사용하라”는 것은 표준보다 더 넓은 주장이다. 지배적인 질문은 모든 다이어그램이 같은 상자 수를 갖는지가 아니라, 서버가 자신의 할당 정책이 요구하는 토폴로지 근거를 받는지 여부다.

우회는 두 번째 진실을 만들 수 있다

레거시 클라이언트는 메커니즘을 인지하지 못하므로, 네트워크는 브로드캐스트와 유니캐스트 DHCPv4 트래픽을 모두 4o6RA를 통해 유도해야 한다. RFC 9928은 잘못 구성된 레이어-2 네트워크가 클라이언트가 DHCPv4 서버에 직접 도달하도록 허용할 수 있다고 지적한다. RFC는 그 결과로 생기는 잘못된 클라이언트·서버 상태와 가능한 도달성 영향을 새로운 보안 우려가 아니라 배포 오류로 분류한다.

운영 관점에서 이 분류가 그 경로를 무해하게 만들지는 않는다. 의도된 4o6 교환과 직접 DHCPv4 교환은 각각 로컬에서 그럴듯한 기록을 만들 수 있다. 한 서버는 토폴로지를 실은 릴레이 경로를 보고, 다른 서버는 평범한 DHCPv4 요청을 본다. 클라이언트에는 어느 제어평면이 이겼는지 설명할 프로토콜 수단이 없다.

따라서 릴레이 보관 기록에는 긍정 근거와 함께 부정 근거도 필요하다. 브로드캐스트가 가로채졌는지, 유니캐스트 갱신 트래픽이 의도된 경로에 남았는지, 직접 서버 경로가 없거나 차단되었는지 보여야 한다. 클라이언트에서만 관측된 임대는 그 증명을 제공할 수 없다.

10개 항목으로 이루어진 릴레이 보관 영수증

제안하는 영수증은 RFC 9928 메시지도 IETF 준수 인증서도 아닌, 편집적 운영 통제 장치다.

첫째, 관측된 DHCPv4 요청을 보존한다. 경계가 있는 트랜잭션 근거, 클라이언트 링크 관측, 시각, 인그레스 장치다. 둘째, 물리적 또는 클라이언트 접속 인터페이스와 관측 시점에 존재했던 로컬 매핑 세대를 기록한다. 셋째, 4o6RA의 이름, 선택된 업스트림 인터페이스, 캡슐화 이벤트를 명시한다.

넷째, 구현 버전과 4o6 개입이 로컬에서 표시되었는지 여부를 포함해 내부 4o6RA-LDRA 인계를 기록한다. 다섯째, LDRA의 불투명Interface-ID, 그 안정성 세대, 그 값이 나타난 중첩 Relay-forward 계층을 보존한다. 여섯째, 할당 정책이 실제로 사용한 추가link-address,Interface-ID, 홉 순서를 보존한다.

일곱째, 서버, 정확한 토폴로지 규칙, 선택된 주소 풀, 반환된 매개변수를 기록한다. 여덟째, 중첩 Relay-reply, 역캡슐화, 최종 전달을 원래 클라이언트 접속 인터페이스로 연결한다. 아홉째, 우회 검사와 그 결과를 보존한다. 열째, 갱신, 포트 이동, 정정, 만료 또는 롤백과, 근거를 안전하게 폐기할 수 있는 시점으로 기록을 닫는다.

어떤 단일 필드도 전체 체인을 증명하지 못한다. 서버 로그는 물리적 인그레스를 증명할 수 없다. 스위치 로그는 할당 규칙을 증명할 수 없다. 되돌려진 Interface-ID는 오래된 로컬 매핑을 설명할 수 없다. 클라이언트 임대는 릴레이 순서를 증명할 수 없다. 이 영수증이 유용한 이유는 그 주장들을 분리되면서도 결합 가능하게 유지하기 때문이다.

거버넌스 경계도 똑같이 중요하다. IETF는 상호운용 가능한 동작을 정의한다. 인터페이스 매핑은 액세스 운영자가, 캡슐화와 트래픽 유도는 릴레이 운영자가, 할당 정책은 DHCP 서비스 소유자가, 레거시 장치는 장비 소유자가 통제한다. 인지하지 못하는 클라이언트를, 자신이 볼 수 없는 결정의 허구적 주체로 삼아서는 안 된다.

출처