요약
- RFC 3736은 이미 IPv6 주소를 가진 노드가 서버에 주소 할당을 요청하지 않고 두 개의 메시지로 이루어진 DHCPv6 Information-request/Reply 교환을 통해 다른 구성 정보를 요청할 수 있도록 했다.
- "스테이트리스"는 이 서비스에 대해 서버가 클라이언트별 동적 상태를 유지할 필요가 없다는 뜻이었다. 선택적 클라이언트 식별, 로컬 정책, 그리고 변하지 않는 릴레이 동작은 여전히 중요했다.
주소와 리졸버는 서로 다른 작업이다
IPv6의 스테이트리스 주소 자동 구성은 라우터 광고로부터 호스트에 주소를 부여할 수 있다. 그러나 그것만으로 호스트가 가진 모든 구성 질문에 답하지는 못한다. 재귀 DNS 서버 주소, SIP 서버 정보 또는 다른 옵션이 여전히 필요할 수 있다. RFC 3736 이전에는 DHCP를 하나의 묶음으로 생각하기 쉬웠다. 서버에 주소를 요청하면 나머지 네트워크 구성도 함께 받는 방식이었다.
RFC 3736은 이 두 기능을 분리했다. 이 RFC의 클라이언트는 다른 수단, 즉 보통 스테이트리스 주소 자동 구성이나 수동 구성을 통해 이미 주소를 가지고 있으며, 통신에 사용할 최소한 링크 로컬 주소를 갖고 있다. 클라이언트는 옵션 요청(Option Request) 옵션에 원하는 옵션 유형을 명시한Information-request를 보낸다. 서버는 자신이 선택한 구성 매개변수를 담은Reply로 응답한다. 이 모드에서는 주소 식별 연계(Identity Association)를 요청하지 않고 주소 할당도 이루어지지 않는다.
이 교환은 의도적으로 작게 설계되었다.Information-request, 그다음Reply. 호스트는 그 교환을 주소 임대로 만들지 않고도 DNS 구성을 요청할 수 있었다. 동일한 서버 시스템이 주소를 요청하는 클라이언트와 다른 매개변수만을 요청하는 클라이언트를 모두 처리할 수 있었고, 릴레이 에이전트는 스테이트풀 DHCP에서와 동일하게 동작했다.
그러나 "스테이트리스"가 구성이나 정책이 없는 서버를 의미하지는 않았다. RFC 3736은 서버가 개별 클라이언트에 대한 동적 상태를 유지할 필요가 없다고 명시하면서도, 관리자가 특정 노드에 맞춘 응답을 만들고자 할 때 요청에 클라이언트 식별자(Client Identifier)를 포함할 수 있도록 허용한다. 서버는 여전히 자신의 구성 정책에 따라 옵션을 선택할 수 있다. 릴레이가 교환을 전달할 수도 있다. 핵심은 좁다. 정보 전용 서비스는 각 클라이언트에 대한 주소 바인딩을 만들거나 추적할 필요가 없다는 것이다.
이 구분은 IPv6 라우터 광고 플래그를 읽을 때 중요하다. RFC 4861의 Managed 플래그는 주소가 DHCPv6를 통해 제공됨을 나타내고, Other-configuration 플래그는 다른 DHCPv6 정보가 제공됨을 알린다. Managed 플래그가 설정되면 Other 플래그는 중복된다. 이것들은 가용성 신호일 뿐이며, 호스트가 DHCP 교환을 완료했거나, DNS 서버를 설치했거나, 그 서버에 도달할 수 있다는 증거가 아니다.
주소 임대를 없애자 그 시계도 사라졌다
주소 할당에는 수명이 있어 클라이언트에게 주소가 선호되는지, 유효한지, 더 이상 사용할 수 없는지를 알려 준다. 다른 구성 정보에는 그런 수명이 없을 수 있다. RFC 3736은 호스트가 그 값들을 갱신하기 위해 언제 다시 Information-request를 보내야 하는지 명시적으로 열어 두었고, 새 링크로 이동한 뒤의 갱신에 대한 규칙도 제시하지 않았다.
RFC 4242가 이후 Information Refresh Time 옵션을 제공했다. 클라이언트가 갱신된 DHCPv6 정보를 요청하기 전까지 기다려야 하는 시간의 상한이다. 그 근거가 시사하는 바는 명확하다. 교환에 주소나 프리픽스 임대가 없으면 클라이언트가 언제 돌아와야 하는지 알려 줄 수명이 없을 수 있다는 것이다. RFC 8415는 이후 DHCPv6를 통합하면서 RFC 3736과 RFC 4242를 폐기했지만, 두 메시지로 이루어지는 정보 전용 운용은 유지했다.
따라서 이 역사는 "SLAAC가 주소를 만들자 DHCP가 사라졌다"는 이야기가 아니다. 주소 형성과 나머지 호스트 구성이 분리 가능했다는 이야기다. 이 분리는 정보 전용 서버가 추적해야 할 것을 줄였지만, 구성에는 여전히 출처 우선순위, 갱신, 인터페이스 범위, 호스트 내 리졸버 설치 동작이 필요했다.Reply는 프로토콜 교환이 옵션을 반환했다는 것만 증명한다. 그 자체로 호스트가 그것을 설치했거나 DNS 질의가 성공했다는 증거가 되지는 않는다.
이 기록의 어떤 RFC도 현재 클라이언트들이 이 모드를 얼마나 자주 사용하는지, 또는 특정 네트워크가 이를 어떻게 구성하는지를 규정하지 않는다. 표준은 메커니즘과 그 경계를 규정할 뿐, 배포 규모나 서비스 결과를 규정하지 않는다.
출처
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





