요약

  • DHCPv4 /32 마스크에 라우터 옵션을 생략하면 레거시 클라이언트를 만족시키면서도 일반적인 링크 외부 IPv4 경로를 제거할 수 있습니다.
  • 이는 반복되는 탐색 요청의 한 원인을 잠재울 뿐, 클라이언트의 고유 임대를 해제하거나 해당 링크에서 들어오는 패킷을 차단하지는 않습니다.

요청을 잠재우는 것과 주소를 해제하는 것은 다릅니다

구형 듀얼 스택 기기는 운영자가 애플리케이션을 IPv6로 전환하기로 결정한 뒤에도 오랫동안 IPv4를 요구할 수 있습니다. 단순히 응답하지 않으면 클라이언트가 만족되지 않은 DHCPv4 요청을 계속 보낼 수 있습니다. LACNIC의 10월 2일자 기술 블로그는 개인 인터넷 드래프트에 있는 더 좁은 우회 방법을 소개합니다. 익숙한 DHCPv4 필드로 요청에 응답하되, 그 결과 구성되는 인터페이스가 다른 IPv4 목적지로 가는 일반 경로를 갖지 않도록 설정하는 것입니다.

이 방법은 의도적으로 단순합니다. DHCPv4 옵션 1이 255.255.255.255 서브넷 마스크, 즉 /32를 제공합니다. 서버는 라우터를 알려주는 옵션 3을 생략합니다. /32 마스크를 쓰면 다른 모든 IPv4 목적지는 링크 외부가 됩니다. 라우터가 제공되지 않으므로 호스트는 그 링크 외부 트래픽을 보낼 곳이 없습니다. 클라이언트는 요청한 IPv4 구성을 받았으므로 반복되는 탐색 문제가 멈출 수 있지만, 일반적인 링크 외부 IPv4 경로는 따라오지 않습니다.

이것은 유용한 호환성 경계이지, 컴퓨터가 IPv6 전용 기기가 되었다는 증거가 아닙니다. DHCPv4는 여전히 활성 상태입니다. 구성된 인터페이스에는 여전히 IPv4 주소가 있습니다. 기기에 다른 인터페이스, 수동 구성된 경로, 터널 또는 다르게 동작하는 애플리케이션이 있을 수 있습니다. 애플리케이션이 IPv4 실패 후 IPv6를 시도할 수 있지만, 드래프트는 예상되는 호스트 동작을 기술할 뿐 모든 소프트웨어 스택이나 서비스에 대한 보장이 아닙니다.

임대 기록은 여전히 서버 장부에 있습니다

드래프트는 '거의'라는 단어 뒤에 가려질 수 있는 회계적 사실을 지적합니다. DHCPv4 서버는 여전히 각 호스트에게 링크 상에서 고유한 IPv4 주소를 부여해야 합니다. 이 방법은 공유 세그먼트의 조용한 모든 클라이언트에게 같은 주소를 줄 수 없습니다. 주소 충돌 감지가 사용 전에 주소를 프로브할 수 있고, 두 클라이언트가 같은 주소를 받으면 충돌을 감지할 수 있습니다. 드래프트는 충돌하는 주소를 반복 반환하면 DHCPDECLINE 메시지 루프가 생길 수 있다고 경고합니다.

따라서 이 방법은 한 종류의 활동을 다른 활동으로 바꿉니다. 반복되는 무응답 요청은 줄일 수 있지만, 성공한 임대는 주소가 해제되거나 동적 임대가 만료될 때까지 풀 항목을 계속 점유합니다. RFC 2131은 동적 할당을 더 이상 필요하지 않을 때 재사용 가능한 기한이 있는 할당으로 정의합니다. 임대 기록은 트래픽 측정이 아니며, 조용한 클라이언트가 주소가 가용 풀로 돌아왔다는 증거가 아닙니다.

경제적 결과는 어떤 풀이 이 코호트에 서비스를 제공하는지에 달려 있습니다. 서버가 희소한 공용 IPv4 공간에서 할당한다면, 호스트가 그 주소를 통해 일반 트래픽을 라우팅할 수 없더라도 살아있는 임대에는 기회 비용이 있습니다. 드래프트는 이 목적으로 링크 로컬 또는 RFC1918 주소도 논의합니다. 전용 사설 풀은 공용 용량을 보호할 수 있지만, 여전히 고유 임대, 충돌 처리, 서버 상태, 운영자의 기존 사설 공간과의 중복 계획이 필요합니다.

드래프트는 DHCP 서버가 각 링크에 직접 연결된 경우 별도의 물리적 링크에서 풀을 신중하고 한정된 범위로 재사용하는 것을 허용합니다. 이는 보편적인 재사용 규칙이 아닙니다. DHCP 릴레이를 사용하면 서버가 릴레이의 주소로 풀을 선택하므로, 드래프트는 할당 풀이 릴레이된 네트워크 전체에서 고유해야 한다고 명시합니다. 주소 범위만 세고 릴레이 경계를 무시하는 다이어그램은 겉보기 절약을 주소 선택 오류로 바꿀 수 있습니다.

긴 임대는 갱신 부담을 점유율과 교환합니다

드래프트는 이런 호스트의 임대가 하루에서 수 주까지 지속될 수 있다고 제안합니다. 호스트가 할당된 주소를 외부 IPv4에 사용할 것으로 예상되지 않고, 로컬 또는 사설 풀은 클 수 있기 때문입니다. 긴 임대는 갱신과 서버 작업을 줄일 수 있습니다. 동시에 예약이 더 오래 지속됩니다. 제한된 공용 풀에서는 DHCP 메시지 감소가 자동으로 가용 주소 증가를 의미하지 않으며, 운영자는 요청 비율과 주소-일 수를 함께 세어야 합니다. 이는 임대 모델에서 나온 운영적 추론이며 블로그가 측정한 결과가 아닙니다.

옵션 108은 다른 코호트를 위한 다른 거래를 제공합니다. RFC 8925는 명시적으로 구성된 IPv6-mostly 네트워크에서 유능한 클라이언트를 위한 IPv6-Only Preferred 옵션을 표준화합니다. 양측이 이 동작을 지원하면 클라이언트가 IPv4 주소를 포기할 수 있습니다. 이는 풀 용량을 보존할 수 있습니다. 레거시 /32 방법은 옵션 108을 이해하지 못하는 클라이언트를 위해 제시되며, 드래프트는 두 접근이 공존할 수 있다고 말합니다. 어느 메커니즘 하나만으로 클라이언트의 애플리케이션, DNS64/NAT64 경로 또는 필요한 서비스가 작동한다는 증명이 되지 않습니다.

게이트웨이 부재는 방화벽이 아닙니다

라우터 옵션을 주지 않으면 호스트가 링크 외부 IPv4 목적지에 도달하는 데 쓰는 일반 경로가 제거됩니다. 그렇다고 인터페이스가 이웃 시스템에게 보이지 않게 되는 것은 아닙니다. 드래프트의 보안 섹션은 링크 상의 다른 호스트가 여전히 /32 호스트에게 IPv4 패킷을 보낼 수 있다고 명시합니다. 그 인터페이스에서 클라이언트와 서버 또는 릴레이 간 DHCPv4 트래픽만 허용하는 호스트 방화벽을 권장합니다.

이것이 중요한 이유는 '호스트가 정상적인 라우팅된 IPv4 연결을 시작할 수 없다'와 '호스트가 IPv4 트래픽을 받을 수 없다'가 서로 다른 진술이기 때문입니다. 전자는 제안된 라우팅 구성에서 나옵니다. 후자는 아닙니다. 운영자는 경로 실패를 인바운드 정책의 대체물로 사용해서는 안 되며, 특히 로컬 서비스가 여전히 활성화되어 있거나 같은 기기가 다른 경로로 도달 가능한 경우 그렇습니다.

공개 근거가 보여주는 것과 보여주지 않는 것

LACNIC 블로그는 저자 알레한드로 아코스타가 Windows 11, Fedora 43, Debian Trixie 기반 Raspberry Pi OS, Chromecast 및 Google Nest 기기에서 이 기법을 시도했다고 말합니다. 스마트폰은 테스트되지 않았으며 더 넓은 호환성 작업을 요청한다고도 합니다. 이는 유용한 실험 보고이지만 독립적으로 재현된 연구, 대표적인 기기 조사 또는 프로덕션 배포의 증거는 아닙니다. 해당 글 자체가 저자의 견해가 반드시 LACNIC의 견해를 반영하지는 않는다고 말합니다.

참조된 드래프트는 개인 인터넷 드래프트의 버전 02입니다. IETF Datatracker는 이를 2026년 6월 15일에 만료된 것으로 기록하며 IETF 표준 과정에서 공식 지위가 없다고 명시합니다. 만료가 그 메커니즘이 기술 검토에서 실패했다는 뜻은 아니며, 드래프트가 존재한다고 해서 그 방법이 승인된 표준이 되는 것도 아닙니다. 여기서 검토한 공개 자료에는 DHCP 브로드캐스트의 측정된 감소, 전후 풀 점유 시계열, 애플리케이션 폴백 결과, 인바운드 보안 감사가 제공되지 않습니다.

이 방법을 테스트하는 운영자는 단일한 'IPv6 전용' 성공 라벨이 아니라 누락된 구분을 공개해야 합니다. 대상 클라이언트 코호트의 반복되는 무응답 요청을 세십시오. 해제, 만료, DHCPDECLINE 이벤트와 함께 공용, 사설, 링크 로컬 풀별로 활성 임대 수와 주소-일 수를 보고하십시오. 릴레이와 링크 경계를 기록하십시오. 필요한 애플리케이션이 실제로 IPv6 위에서 완료되는지 표본 조사하고, 인바운드 IPv4 방화벽 정책을 보여주십시오. 각 지표는 서로 다른 질문에 답합니다. 조용해진 링크, 회수된 희소 주소, 작동하는 애플리케이션, 통제된 노출은 서로 바꿔 쓸 수 없는 결과입니다.

출처: