요약

  • DHCPv4 리스에는 세 가지 관련 시점이 있습니다. T1은 리스를 내어준 서버와의 갱신을 시작하고, T2는 브로드캐스트 리바인딩을 시작하며, 만료는 DHCPACK이 새 리스를 만들지 않는 한 클라이언트가 주소를 사용할 권한을 끝냅니다.
  • 리바인딩은 가용성을 높이지만, 도달 가능한 모든 서버를 권위자로 만들지는 않습니다. RFC 2131은 서버가 로컬 관리 권한을 가진 경우에만 대체 서버가 리스를 연장할 수 있다고 규정합니다. 관찰된 패킷 전달이 기한을 무효화하지는 않습니다.

권한이 좁아지기 시작했을 때도 주소는 여전히 동작했다

열린 연결과 동작하는 경로를 가진 노트북을 생각해 보십시오. 그 IPv4 주소는 여전히 응답합니다. 그러나 주소를 내어준 DHCP 서버는 더 이상 응답하지 않습니다.

와이어상에 아무런 가시적 신호도 사용자에게 권한 이동이 시작되었다는 사실을 알려주지 않습니다. 클라이언트는 리스를 수락할 때 세 개의 구간을 기록했기 때문에 이를 알고 있습니다. 첫 번째 시점 T1에서는 리스 서버에 연속성을 요청하고, 두 번째 시점 T2에서는 다른 권한 있는 서버가 응답할 수 있도록 요청을 브로드캐스트합니다. 세 번째 시점, 즉 리스 만료에는 확인(acknowledgement)이 도착하지 않으면 주소를 반드시 내려놓아야 합니다.

이 순서는 쉽게 “자동 갱신”으로 뭉뚱그려집니다. 그 표현은 설계를 감춥니다. DHCP는 리스 전체 기간에 걸쳐 하나의 응답자 집합을 유지하지 않습니다. 친화성으로 시작하고, 가용성을 보호하기 위해 그 친화성을 완화하며, 마지막에는 시간을 로컬 관찰보다 강하게 만듭니다.

재사용 가능한 주소에는 철회 가능한 바인딩이 필요했다

BOOTP는 부팅 중인 호스트에 구성을 전달할 수 있었지만, 제한된 주소 풀을 시한 관리를 통해 재사용 가능하게 만들지는 않았습니다. 1993년 10월에 발행된RFC 1541은 DHCP의 동적 할당을 제한된 기간 또는 명시적 반납까지의 주소 할당으로 기술했습니다.

이 RFC는 그 결과물인 상태를 바인딩이라고 불렀습니다. 바인딩이란 최소한 IP 주소를 포함한 구성 매개변수가 클라이언트와 연관되어 DHCP 서버가 관리하는 상태입니다. 동적 할당은 순차적 재사용을 가능하게 했습니다. 하나의 주소가 어느 클라이언트도 영구히 소유한다고 가장하지 않은 채, 서로 다른 시점에 서로 다른 클라이언트를 서비스할 수 있었습니다.

이 구분은 익숙한 네 메시지 발견 순서보다 여전히 더 중요합니다. 주소는 한 번 건네주고 끝나는 사실이 아닙니다. 로컬 정책에 따라 서비스가 유지하는, 시간으로 경계가 정해진 구성 결정의 한 부분입니다.

1997년 3월에 발행된RFC 2131은 세 가지 할당 모델을 유지했습니다. 자동 할당은 영구적일 수 있습니다. 수동 할당은 관리자의 선택을 전달합니다. 동적 할당은 이 글에서 다루는 리스 시계와 단계적 재획득 상태에 의존하는 모델입니다.

하나의 리스에 세 개의 시계가 담겼다

리스 기간과 두 재획득 시점은 별개의 값입니다.RFC 2132는 옵션 51을 주소 리스 시간에, 옵션 58을 갱신 시간 값 T1에, 옵션 59를 리바인딩 시간 값 T2에 배정합니다. 각 값은 날짜가 아니라 주소 할당으로부터의 초 단위 구간입니다.

서버가 유효한 T1과 T2를 제공하지 않을 때 RFC 2131은 기본값을 제시합니다. T1은 리스의 절반, T2는 8분의 7입니다. 그리고 서버 집단이 제각각 재획득을 동시에 시도하지 않도록 임의 변동을 권장합니다. 이 분수들은 보편적 운영 조언이 아니라 대체 프로토콜 값이며, 서버는 서로 다른 유효한 구간을 제공할 수 있습니다.

순서 자체가 정책을 담고 있습니다. T1은 원래 권위자와의 대화를 위한 시간을 남겨야 하고, T2는 더 넓은 복구 시도를 위한 시간을 남겨야 합니다. 만료는 또 하나의 재시도 임계값이 아닙니다. 그것은 현재 바인딩의 끝입니다.

T1은 리스 서버에 첫 응답 기회를 주었다

T1이 도래하면 BOUND 상태의 클라이언트는 RENEWING 상태로 들어갑니다. 해당 서버의 주소를 알고 있다면 리스를 내어준 서버에 DHCPREQUEST를 보냅니다. 클라이언트의 현재 주소는ciaddr에 담기며, 이 메시지는 새로운 제안들 중에서 선택하는 것이 아닙니다.

이 선호는 상태 소유권을 보존합니다. 리스 서버는 자신이 만든 바인딩, 그 뒤에 있는 로컬 정책, 연장과 함께 반영해야 할 구성 변경 사항을 알고 있습니다. 서버는 관리 정책에 따라 더 긴 리스를 허가하거나, 수정된 매개변수를 반환하거나, 연장을 거절할 수 있습니다.

즉각적인 응답이 없다고 해서 주소가 무효화되지는 않습니다. 기존 리스가 여전히 클라이언트의 권한 근거입니다. 클라이언트는 T2까지 남은 시간을 재면서 재전송합니다. 서버 장애와 리스 철회는 서로 다른 사건입니다.

이 구분 덕분에 짧은 제어평면 장애가 즉각적인 데이터평면 중단으로 변하지 않습니다. 동시에 클라이언트가 서버의 침묵을 무제한 허가로 취급하는 것도 막습니다.

T2는 발견 범위를 넓혔지 권한을 넓히지 않았다

T2 이전에 DHCPACK이 도착하지 않으면 클라이언트는 REBINDING 상태로 들어갑니다. 사용 중인 주소를ciaddr에 채우고 서버 식별자를 생략한 채 DHCPREQUEST를 브로드캐스트합니다. 이 변경으로 원래 서버가 아예 받지 못할 요청을 다른 서버들이 들을 수 있게 됩니다.

그러나 브로드캐스트만으로 리스 연장 권한이 결정되지 않습니다. RFC 2131은 서버가 로컬 관리 권한을 가진 경우에만 연장할 수 있다고 명시합니다. 이 메커니즘은 여러 서버를 두고 리스 상태를 일관되게 유지하는 방법을 갖춘 사이트를 위한 것이었습니다.

여기가 리바인딩의 구조적 중심입니다. DHCP는 가용성이 중요하기 때문에 응답자 집합을 넓히지만, 네트워크 도달 가능성을 위임으로 바꾸지는 않습니다. 대체 서버에는 바인딩을 대변하기 위한 운영 권한과 상태가 필요합니다.

서버들끼리 불일치하면, 리바인딩은 가장 나쁜 순간에 그 불일치를 드러낼 수 있습니다. 한 서버는 주소가 여전히 바인딩되어 있다고 믿고 다른 서버는 사용 가능하다고 믿을 수 있습니다. 프로토콜은 브로드캐스트만으로 공유 관리를 만들어낼 수 없으며, 네트워크가 그것을 유지해야 합니다.

ACK, NAK, 침묵은 세 가지 서로 다른 판정이었다

RENEWING 또는 REBINDING 상태에서의 DHCPACK은 연속성을 만듭니다. 클라이언트는 반환된 리스를 기록하고 새로운 T1과 T2 타이머를 시작합니다. 확인은 변경된 구성을 함께 전달할 수도 있으므로, 갱신은 단지 숫자 하나를 의례적으로 늘리는 일이 아닙니다.

DHCPNAK은 그 반대입니다. 클라이언트에게 현재 네트워크 구성이 수용 불가능하다고 알립니다. 클라이언트는 사용을 중단하고 초기화로 돌아갑니다. NAK 이후 트래픽을 계속 내보내는 것은 기억된 상태를 경쟁하는 주소 청구로 만드는 일이 됩니다.

침묵은 ACK도 NAK도 아닙니다. 시간이 남아 있는 동안 현재 리스를 그대로 두고 유한한 재전송을 일으킵니다. 그러나 ACK 이전에 리스가 만료되면 RFC 2131은 클라이언트가 INIT로 이동해 다른 네트워크 처리를 중단하고, 미초기화 상태처럼 구성을 요구하도록 요구합니다.

클라이언트는 캐시된 이웃에 대한 응답을 여전히 볼 수 있습니다. 스위치 포트는 올라가 있을 수 있고, 라우터는 포워딩을 계속할 수 있습니다. 그 어떤 관찰도 리스를 연장하지 못합니다. 기한은 권한 유지 시도의 실패와 무단 계속 사용 사이의 경계입니다.

기억된 주소는 판단에 부쳐야 했다

재부팅은 거짓 연속성으로 가는 또 하나의 유혹을 더합니다. 클라이언트는 이전 주소를 기억하고 같은 네트워크로 돌아왔다고 믿을 수 있습니다. DHCP의 INIT-REBOOT 경로는 클라이언트가 그 주소를 요청할 수 있게 해주지만, 그 기억은 권리가 아니라 제안입니다.

요청은 브로드캐스트됩니다. 클라이언트는 예전 서버, 심지어 예전 네트워크가 여전히 유효한지 알지 못할 수 있기 때문입니다. 서버는 DHCPACK으로 확인하거나 DHCPNAK으로 거부할 수 있습니다. 서버에 연락할 수 없다면 RFC 2131은 만료되지 않은 리스 잔여 기간에 한해 이전 구성을 사용할 수 있도록 허용합니다.

이로써 “재시작 후 같은 주소”는 검증된 결과가 됩니다. 프로토콜은 연속성을 중요하게 여기면서도, 클라이언트에 저장된 값으로부터 현재의 권한을 도출하는 것은 거부합니다.

이후의 서버 메시지는 갱신을 앞당길 수 있었다

원래 상태 머신에서 갱신은 주로 타이머에 의해 구동되었습니다. 이후RFC 3203은 유니캐스트 FORCERENEW를 도입해, 서버가 T1 이전에 클라이언트를 정상적인 RENEW 상태로 들어가게 할 수 있게 했습니다. 예를 들어 구성을 변경해야 할 때입니다.

FORCERENEW 자체는 새 구성을 설치하지 않습니다. 평범한 DHCPREQUEST를 유도할 뿐입니다. 클라이언트에게 주소를 내려놓길 원하는 서버는 그 요청에 DHCPNAK으로 응답해 클라이언트를 발견 단계로 되돌릴 수 있습니다.

이 권한은 활성 세션을 끊을 수 있고, 위조된 트리거는 클라이언트를 반복적으로 혼란에 빠뜨릴 수 있습니다. 그래서 RFC 3203은RFC 3118의 절차를 통한 FORCERENEW 인증을 요구합니다. 이 확장은 같은 경계를 반대 방향에서 보여줍니다. 서버는 클라이언트에게 리스를 조기에 다시 살펴보도록 요청할 수 있지만, 로컬 상태를 몰래 다시 쓰는 대신 통제된 상태 전이를 사용해야 합니다.

리스는 허가였지, 링크가 비어 있다는 증명이 아니었다

진짜 DHCPACK조차 로컬 링크에서 다른 호스트가 그 주소를 사용하고 있지 않음을 증명할 수 없습니다. 구성 권한과 관찰된 링크 상태는 별개입니다.

RFC 5227은 IPv4 호스트가 새로 구성된 주소를 사용하기 시작하기 전에 프로브할 것을 요구합니다. 충돌을 감지한 DHCP 클라이언트는 DHCPDECLINE을 보냅니다. 서버의 계획이 모순되는 로컬 증거와 마주했으므로 재검토되어야 합니다.

이 단서 조항은 리스 주장의 범위를 유한하게 만듭니다. DHCP는 관리 서비스가 일정 기간 동안 클라이언트에게 주소를 할당했다고 말할 수 있습니다. 그러나 클라이언트를 사용하는 사람을 인증하거나, 법적 소유를 증명하거나, 종단 간 도달성을 보장하거나, 중복 주소를 불가능하게 만들지는 않습니다.

출처와 근거의 한계

역사적·프로토콜 관련 주장은 RFC 1541, RFC 2131, RFC 2132, RFC 3118, RFC 3203 및 RFC 5227에서 나옵니다:

이 문서들은 DHCPv4 계약을 정의합니다. 그러나 특정 제품이나 네트워크의 현재 기본값, 페일오버 설계, 클라이언트 정확성, 배포 점유율을 확립하지는 않습니다. DHCPv6은 다른 프로토콜입니다. 기본 T1·T2 분수는 모든 서버가 그 값을 보내고 모든 클라이언트가 그 값을 사용한다는 증거가 아닙니다.