요약

  • Remco van Mook의 활성 INTAREA 워킹그룹 드래프트는192.0.0.11/32를 센티널 IPv4 기본 게이트웨이로 제안합니다. 업데이트된 호스트는 이 주소에 대해 ARP를 수행하지 않고, 대신 선택된 IPv6 기본 라우터의 링크 계층 주소를 사용합니다.
  • 패킷은 네이티브 IPv4로 유지됩니다. 터널도 변환도 없지만, 복귀 경로는 별도의 의무입니다. 호스트의 IPv4/32가 라우팅 가능한 IPv6 넥스트 홉을 통해 도달 가능해야 합니다.
  • 이 단순화는 두 개의 제어 평면을 결합합니다. DHCP 구성, 라우터 광고(RA) 선택, 이웃 도달성, IPv4 포워딩, 복귀 라우팅, 레거시 ARP 폴백은 서로 다른 영수증이며 독립적으로 실패할 수 있습니다.

명령인 주소

제안의 가장 우아한 부분은 동시에 가장 오해하기 쉬운 부분입니다.192.0.0.11은 라우터 주소처럼 보입니다. 그러나 드래프트에 따르면 그렇지 않습니다. 이는 IPv4 라우팅 테이블에 배치된 센티널로, "이 경로의 이더넷 목적지는 IPv6에서 얻으라"고 말하는 명령입니다.

호스트는 여전히 IPv4 주소를 소유하고, 애플리케이션은 여전히 IPv4 소켓을 열고, 라우터는 여전히 일반 IPv4 패킷을 포워딩합니다. 업데이트된 호스트에서 사라지는 것은 평소의 질문, 즉 "내 IPv4 게이트웨이를 누가 가지고 있나?"입니다. 이 호스트는192.0.0.11에 대해 ARP를 브로드캐스트하지 않습니다. 대신 동일 인터페이스의 IPv6 기본 라우터 목록을 확인하고 라우터를 선택한 뒤, IPv6 이웃 캐시에서 해당 링크 계층 주소를 사용합니다.

이 구분은 중요합니다. 주소 계열을 변환하지 않으므로 NAT64가 아니고, IPv4 패킷을 IPv6로 감싸지 않으므로 터널이 아니며, IPv6 링크 위에 IPv4 서브넷을 늘인 것도 아닙니다. 이 설계는 첫 링크 계층 홉의 해석만 바꿉니다.

van Mook의 드래프트는 2026년 8월 INTAREA 워킹그룹 트랙에 도달했습니다. 이 문서는 해당 동작이 Windows 11, macOS, Android, iOS, Linux, FreeBSD, ChromeOS에서 애플리케이션이나 DHCPv4 변경 없이 검증되었음을 보고합니다. 이는 저자의 크로스 플랫폼 결과이며 독립 인증 프로그램이 아닙니다. 문서는 여전히 인터넷 드래프트이며 변경될 수 있고,192.0.0.11은 이미 할당된 보편적 게이트웨이로 묘사되어서는 안 됩니다.

하나의 패킷, 여러 영수증

센티널을 담은 DHCP 임대는 구성이 도착했다는 것만 증명합니다. IPv6 라우터 광고가 도착했는지, 선택된 라우터가 도달 가능한지, 그 MAC 주소 뒤의 장치가 IPv4를 포워딩할지는 증명하지 않습니다.

따라서 드래프트는 동작하는 IPv6 첫 홉 제어 평면에 의존합니다. 첫 라우터 광고 전에는 이웃을 빌려올 정당한 IPv6 기본 라우터가 없습니다. 구현은 패킷이 무한정 대기하지 않도록 대기열에 상한을 두어야 합니다. 라우터가 알려진 후에는 RFC 4191의 선호 메커니즘, 그다음 도달성을 따르며, 그 외 동등한 후보 사이의 선택은 구현별 정의에 맡깁니다. 선택된 라우터가 바뀌면 IPv4 경로를 재평가해야 합니다. 기존 세션은 변경을 견디지 못할 수 있습니다.

이웃 캐시 항목도 하나의 영수증입니다. RFC 4861의 reachable, stale, delay, probe 상태는 서로 같지 않지만, 탐지가 진행되는 동안 각각 사용 가능한 이웃을 나타낼 수 있습니다. 라우터가 IPv4 포워딩을 멈춘 뒤에도 캐시에 남아 있는 MAC 주소는 더 약한 증거입니다. 반대로 포워딩 중인 라우터도 RA나 Neighbor Discovery 상태가 만료되면 사용할 수 없습니다. 이 설계의 단순함은 하나의 불리언이 아니라 여러 상태의 조합입니다.

송신 방향과 복귀 방향도 비대칭입니다. 호스트의 첫 홉에는 IPv6 링크 로컬 라우터 주소로 충분할 수 있습니다. 그 링크 너머에서는 링크 로컬 넥스트 홉이 네트워크 전반의 경로를 식별할 수 없습니다. 운영자는 라우팅 가능한 IPv6 GUA 또는 ULA 넥스트 홉과 함께 호스트별 IPv4/32를 액세스 구간 쪽으로 광고해야 합니다. RFC 8950은 BGP에서 IPv6 넥스트 홉과 함께 IPv4 도달성을 전달하는 것을 표준화하고, 보완적인v4-via-v6작업은 이 모델의 라우터 간 부분을 발전시킵니다.

따라서 외부로 나가는 성공적인 핑만으로는 전체 검증이 아닙니다. 액세스 노드는 임대가 수용되었고, RA가 의도된 라우터를 선택했으며, 이웃 항목이 의도된 MAC을 가리키고, 라우터가 네이티브 IPv4를 포워딩하며, 네트워크 나머지가 올바른/32복귀 경로를 가지고 있음을 증명해야 합니다. 각 항목이 녹색인 동안 다른 항목이 빠져 있을 수 있습니다.

/32가 메커니즘의 일부인 이유

호스트 주소는/32마스크로 구성되어야 합니다. 더 넓은 IPv4 프리픽스는 호스트에게 다른 주소들이 온링크에 있다고 알려줍니다. 그러면 호스트는 그 목적지들에 대해 ARP를 수행할 수 있고, 제안이 제거하려던 인접성을 재현합니다. 특별 주소는 실제 경로로 재배포되어서는 안 되고, 포워딩된 패킷의 출발지나 목적지로 사용되어서는 안 되며, 살아 있는 라우터 인터페이스처럼 테스트되어서도 안 됩니다. 범위를 의도적으로 좁게 제한한 로컬 명령입니다.

드래프트는 이 아이디어를 호스팅 네트워크에서 이미 익숙한 관행과 연결합니다. 고객은 개별 IPv4 주소를 받고 오프링크 게이트웨이를 사용합니다. Hetzner, OVH, Scaleway를 현재 OS별 우회 방법을 요구하는 운영 사례로 인용합니다. 이 역사는 공통 동작에 대한 수요를 뒷받침하지만, 센티널 설계 자체가 그 제공자들에서 운영되었다는 증거는 아닙니다. 귀속은 드래프트에 머물러야 합니다.

RFC 8925는 또 다른 유용한 맥락을 제공합니다. 네트워크는 가능한 클라이언트에게 IPv6 전용 운영을 선호하도록 지시할 수 있습니다. 센티널은 여전히 네이티브 IPv4가 필요한 듀얼스택 호스트에게 다른 거래를 제시합니다. IPv4 서비스는 유지하되 액세스 구간에서 IPv4 서브네팅과 일반 ARP를 제거합니다. 두 메커니즘은 IPv6-mostly 설계에서 만날 수 있지만, 어느 쪽도 다른 쪽 테스트를 대체하지 못합니다.

호환성은 두 번째 경로이지 마법이 아니다

구형 호스트는 센티널을 이해하지 못합니다.192.0.0.11을 일반 게이트웨이로 취급하고 ARP를 보냅니다. 드래프트는 라우터가 그 요청에 자기 MAC으로 응답해야 한다고 말합니다. 이를 통해 업데이트된 무-ARP 호스트와 레거시 ARP 호스트가 공존할 수 있습니다.

이는 운영상 유용하지만 진단상 위험합니다. 구형 호스트가 동작하는 것은 호환성 응답자가 동작한다는 것만 증명합니다. 업데이트된 호스트가 올바른 IPv6 라우터를 선택했다는 것은 증명하지 않습니다. 업데이트된 호스트가 동작하는 것은 빌려온 이웃 경로가 해당 스택에서 동작한다는 것만 증명합니다. 레거시 계층이 사용 가능하다는 것은 증명하지 않습니다. 두 모집단은 별도의 카운터와 테스트 클라이언트를 필요로 합니다.

IETF 126에서 이 논의는 이 경계를 드러냈습니다. Lorenzo Colitti는 호스트가 IPv6 라우팅 변경을 따라가야 하는지 물었고, 잘못된 구현이 IPv4를 깨뜨릴 수 있다고 경고했습니다. van Mook은 예라고 답했습니다. 의존성은 의도된 것입니다. Tobias Fiebig는 DHCPv4를 DHCPv6 안에 담아 전달하는 방식과 비교해 이 접근을 우아하다고 평했습니다. 여기서 우아함은 와이어상의 움직이는 부분이 적다는 뜻이지 관찰할 상태가 적다는 뜻이 아닙니다.

구현은 경계가 있는 증거다

공개된v4-with-v6-nh저장소는 제안을 서면 이상으로 만듭니다. 이 Linux 사용자 공간 데몬은 센티널을 인식하고, RFC 4191 정보를 사용해 IPv6 라우터를 선택하고, IPv6 넥스트 홉을 경유하는 IPv4 기본 경로를 설치하고, 라우터 변경을 따르며, 전제 조건이 사라지면 경로를 철회합니다. Linux는 커널 5.2부터 IPv6 넥스트 홉을 가진 IPv4 경로를 지원해 왔습니다.

이 저장소는 주장하지 않는 것에서도 똑같이 가치 있습니다. 데몬은 첫 RA를 기다리며 개별 패킷을 대기열에 넣을 수 없으므로 시작 동작은 근사치라고 명시합니다. systemd-networkd 변경은 일반 릴리스가 아니라 패치입니다. FreeBSD 구문은 검증되었으나 테스트되지 않았고, 상용 구성은 하드웨어에서 확인되지 않았으며, 저장소에는 태그된 릴리스가 없습니다. 데모는 제어 평면 아이디어를 검증할 수 있지만 운영 성숙도를 확립하지는 못합니다.

따라서 드래프트 저장소와 적합성 자료는 테스트 계약의 시작으로 읽어야 합니다. 결정적인 사례는 정상 상태의 성공만이 아닙니다. DHCP 만료, 첫 RA 지연, 선호 라우터 철회, 스테일 이웃 상태, 동등 선호 라우터들의 다른 선택,/32복귀 경로의 상실, 업데이트된 호스트와 미수정 호스트가 섞인 구간이 포함됩니다.

보안 경계의 이동

ARP 제거는 업데이트된 호스트에서 오래된 스푸핑 소스와 운영 잡음을 없앱니다. 하지만 첫 홉 신뢰를 제거하지는 않습니다. IPv4 가용성은 이제 IPv6 라우터 광고와 Neighbor Discovery에 의존합니다. 악의적이거나 잘못된 RA는 IPv4에 사용될 MAC을 공급하는 라우터에 영향을 줄 수 있고, 깨진 ND 경로는 두 프로토콜 계열을 동시에 끊을 수 있습니다.

따라서 RA Guard, 신뢰할 수 있는 접속 지점, 이웃 상태 검사, 통제된 라우터 선호가 IPv4 보안 자세의 일부가 됩니다. 동등 선호의 두 라우터를 가진 네트워크는 호스트들의 불일치 선택을 수용할지도 결정해야 합니다. 모든 스택이 같은 타이브레이크를 만들 것이라고 가정하는 것보다 명시적 선호가 더 안전할 수 있습니다.

제안의 가장 심각한 실패는 조용합니다. 호스트와 라우터 어느 쪽도 의도된 동작을 지원하지 않는 구간에서 DHCP 서비스가 센티널을 제공하면 IPv4가 그냥 멈출 수 있습니다. 일부 DHCP 구현은 그 지점 전에 검증 단계에서 오프링크 게이트웨이를 거부할 수 있습니다. 두 실패 모두 유용합니다. 구성 수용과 포워딩 준비성을 단일 출시 플래그로 묶어서는 안 된다는 점을 보여줍니다.

출처