요약

  • RFC 3315는 DHCPv6 클라이언트가 일반적인 Solicit–Advertise–Request–Reply 절차 대신 Solicit–Reply 교환을 요청할 수 있도록 했지만, 서버가 그 요청을 수용할지는 서버 자체의 설정과 정책에 따랐습니다.
  • Rapid Commit 서버는 Reply를 보내기 전에 할당을 확정하기 때문에, 서버가 둘 이상이거나 Reply가 클라이언트에 도달하지 못하면 할당이 기록되었으나 사용되지 않는 상태가 남을 수 있습니다. 메시지 수가 줄어든 것은 단순히 지연 시간이 아니라, 확정 시점과 리스크를 바꾼 것입니다.

익숙한 4메시지 교환에는 작지만 중요한 멈춤이 있습니다. 클라이언트가 Solicit을 보내면, 가용한 서버들이 Advertise로 응답하고, 클라이언트가 하나를 골라 Request를 보내면, 그 서버가 Reply로 확정합니다. 발견과 확정 사이의 간격은 클라이언트가 최종 할당 전에 제안들을 비교해 선택할 수 있게 합니다. 2003년 7월에 Standards Track 사양으로 발표된 RFC 3315는 더 짧은 경로를 가능하게 했지만, 그것을 기본값으로 만들지는 않았습니다.

2메시지 경로에서는 클라이언트가 Solicit에 길이가 0인 Rapid Commit 옵션을 담습니다. 이 옵션은 초대에 해당합니다. 클라이언트가 즉시 Reply를 받을 준비가 되어 있다는 뜻이지, 모든 서버에 대한 지시가 아닙니다. 서버는 여전히 자신의 관리 정책과, 이 경로에서 할당을 확정하도록 설정되어 있는지를 확인합니다. 그렇지 않다면 옵션을 무시하고 Advertise로 진행할 수 있으며, 클라이언트는 일반적인 선택 교환을 이용할 수 있습니다. 서버가 수용하는 경우, Reply를 전송하기 전에 주소와 요청된 다른 자원을 확정합니다.

이 순서가 바로 거래의 조건입니다. 유효한 Rapid Commit Reply를 받은 클라이언트는 Request를 보내지 않고도 구성을 사용할 수 있습니다. 그러나 서버는 클라이언트가 실제로 그 Reply를 받았다는 사후 확인을 받지 못합니다. 따라서 사양은 패킷 수로만 설명하면 놓치기 쉬운 사례를 명시합니다. 여러 서버가 하나의 Rapid Commit Solicit에 응답하면, 각 서버가 할당을 확정할 수 있는 반면 클라이언트는 하나의 임대만 사용합니다. 나머지는 사용되지 않은 채 확정 상태로 남을 수 있습니다. Reply가 전송 중 유실되면 서버 측 확정과 클라이언트가 실제 활용할 수 있는 것 사이에 유사한 간극이 생깁니다.

일반 4메시지 경로와 빠른 경로는 불확실성을 서로 다르게 분배합니다. Advertise와 Request를 사용하면 클라이언트가 선택한 서버가 최종 할당을 만들기 전에 눈에 보이는 선택을 합니다. Rapid Commit에서는 서버가 확정 시점을 앞당기는데, 이는 왕복 한 번을 줄일 수 있지만, 어느 응답을 클라이언트가 받아 사용했는지 알기 전에 둘 이상의 응답자가 주소 풀 용량을 소모할 수 있음을 뜻합니다. 이것은 주소 충돌이 발생했다는 증거도, 모든 추가 예약이 해롭다는 증거도 아닙니다. 서비스 배치 방식에 영향을 주는 프로토콜상 정의된 가능성입니다.

RFC 3315는 Solicit–Reply를 사용하는 배치에서는 통상 하나의 서버만 응답하도록 구성하고, 사용되지 않는 할당을 줄이는 또 하나의 방법으로 비교적 짧은 임대 기간을 제안한다고 설명합니다. 이것들은 단일 서버 토폴로지나 공유 상태를 보장하는 것이 아니라 설계상 완화책입니다. 빠른 경로는 서비스가 응답자 선택을 의도적으로 통제할 때 가장 명확하며, 여러 서버가 독립적으로 응답할 수 있는 경우 운영자는 각 서버가 확정할 가능성까지 고려해야 합니다.

2년 뒤 RFC 4039가 DHCPv4에 Rapid Commit 옵션을 도입했습니다. 그 도입 근거는 네트워크 접속 지점 사이를 자주 이동하는 환경, 즉 클라이언트 구성 속도가 중요한 환경을 언급합니다. 또한 4메시지 교환의 중복성 이점도 설명합니다. 여러 서버가 최종 할당을 만드는 대신, 클라이언트가 선택하는 동안 제안을 잠정 상태로 둘 수 있다는 것입니다. 이것은 유용한 비교이지만, RFC 4039가 광범위한 배치를 이끌었거나 모바일 클라이언트가 보편적으로 이 옵션을 사용했다는 증거는 아닙니다.

이후의 DHCPv6 사양들도 이 구분을 유지했습니다. RFC 8415가 2018년에 프로토콜을 통합했고, 2026년에 발표된 RFC 9915가 이제 이를 대체하면서도 여전히 Rapid Commit을 서버가 거부할 수 있는 클라이언트 요청 교환으로 기술합니다. 오래된 교훈은 속도가 안전하지 않다는 것이 아닙니다. 더 짧은 교환은 결정 경계를 옮긴다는 것입니다. 서버가 언제 확정하는지, 어떤 응답자가 확정할 수 있는지, 그리고 클라이언트가 실제로 자원을 확보하고 사용했음을 각 측에 알려주는 증거는 무엇인지. 아낀 메시지 하나는 곧 제거된 확인 단계이기도 합니다.

출처:RFC 3315,RFC 4039,RFC 8415,RFC 9915.