지금까지는 네트워크를 이해하기 위한 OSI 7 계층과 패킷을 처리하기 위한 장비들에 대해 알아보았다.

종단 장비에서 패킷이 시작되어 중간 네트워크 장비에서 이 패킷을 처리하는 과정 외에도 사용자를 편리하게 해주는 다양한 서비스와 프로토콜이 있다.

NAT / PAT

NAT(Network Address Translation)는 네트워크 주소를 변환하는 기술이다.
NAT는 기본적으로 하나의 네트워크 주소에 다른 하나의 네트워크 주소로 1:1 변환이 기본이지만 IP 주소가 고갈되는 문제를 해결하기 위해 1:1 변환이 아닌 여러 개의 IP를 하나의 IP로 변환하기도 한다.
여러 개의 IP를 하나의 IP로 변환하는 기술도 NAT 기술 중 하나이며 NAT로 통칭하기도 하지만 실제 공식 용어는 NAPT(Network Address Port Translation)이며, 주로 PAT(Port Address Translation)라고도 많이 불린다.

NAT/PAT의 용도와 필요성

1. IPv4 주소 고갈문제의 솔루션으로 NAT가 사용된다.

IPv4의 주소 보존 전략중 단기, 중기, 단기 전략으로 각각 서브네팅, NAT와 사설 IP 체계, IPv6 전환이다.

그 중 NAT를 이용한 중기 전략이 IPv4 주소 보존에 큰 기여를 했는데 외부에 공개해야 하는 서비스에 대해서 공인 IP를 사용하고 외부에 공개하지 않는 곳에는 사설 IP를 사용함으로써 효율적으로 IP를 사용할 수 있게 되었다.

2. 보안을 강화하는데 NAT가 사용된다.
IP 주소는 네트워크에서 유일해야 하고 이 정보는 식별자로 사용되어 외부와 통신하게 해준다.
외부와 통신할 때 내부 IP를 다른 IP로 변환해 통신하면 외부에 사내 IP 주소 체계를 숨길 수 있다.

NAT는 주소 변환 후 역변환이 정상적으로 수행되어야만 통신이 가능하다.
이 성질을 이용해 복잡한 룰 설정 없이 방향성을 통제할 수 있다.
내부 네트워크에서 외부 네트워크로 나가는 방향의 통신은 허용하지만 외부에서 내부로 들어온느 통신은 방어할 수 있다.

3. IP 주소 체계가 같은 두 개의 네트워크 간 통신을 가능하게 한다.
IP 네트워크에서 서로 통신하려면 식별 가능한 유일한 IP 주소가 있어야 한다.
공인 IP는 인터넷에서 유일한 주소를 IP 주소가 중복되면 안 되지만 사설 IP는 외부와 통신할 때 공인 IP로 변환되어 통신하므로 서로 다른 회사에서 중복해 사용할 수 있다.

NAT 동작 방식

만약 사용자(10.10.10.10)가 웹 서버(20.20.20.20)로 통신하는 과정을 예를 들어보자

1. 사용자는 출발지(10.10.10.10)으로, 목적지(20.20.20.20)으로 포트 80으로 패킷으로 전송한다.

2. NAT 장비가 NAT 정책에 따라 공인 IP(11.11.11.11)로 IP 주소를 변경한다. NAT 변경 전후 IP 주소는 NAT 테이블에 저장된다.

3. NAT 장비에서 출발지(11.11.11.11)를 변환해 웹 서버로 패킷을 전송한다.

4. 패킷을 수신한 웹 서버는 사용자에게 응답을 보낼 때 수신한 내용을 반대로 출발지(20.20.20.20)와 목적지(11.11.11.11)로 사용자에게 전송한다.

5. 웹 서버로부터 응답 패킷을 수신한 NAT는 NAT 테이블에서 목적지 IP(11.11.11.11)를 원래 출발지 IP(10.10.10.10)으로 변경한다.

PAT 또한 위와 같이 동작하며, NAT 테이블에서 포트 정보까지 저장하여 포트 정보도 변경하는 것이다.

이를 통해 IP가 같아도 포트 번호를 통해 사용자를 구분할 수 있다.
하지만 서비스 포트는 개수가 제한되있으므로, 서비스 포트가 동시에 모두 사용 중이거나 재사용할 수 없을 때 PAT는 정상적으로 동작하지 않는다.
동시 사용자가 매우 많을 때는 PAT에서 사용하는 공인 IP Pool을 구성해야 한다.

SNAT, DNAT

• SNAT(Source NAT) - 출발지 주소를 변경하는 NAT
• DNAT(Destination NAT) - 도착지 주소를 변경하는 NAT

SNAT와 DNAT는 트래픽이 출발하는 시작 지점을 기준으로 구분한다.
어떤 주소를 변경해야 하는지는 서비스 흐름과 목적에 따라 결정된다.

요청 시 SNAT를 해서 목적지로 전송하면 해당 트래픽에 대한 응답을 받을 때는 출발지와 목적지가 반대가 되므로 DNAT이 되는데 이떼 트래픽을 요청하는 시작 지점만 고려해 SNAT 설정을 해야한다.
NAT 장비를 처음 통과할 때 NAT 테이블이 생성되므로 응답 패킷이 NAT 장비에 들어오면 별도의 NAT 설정 없이 패킷을 반대로 변환해줄 수 있다.

SNAT는 사설에서 공인으로 통신할 때 많이 사용된다.
공인 IP 주소의 목적지에서 출발지로 다시 응답을 받으려면 출발지 IP 주소 경로가 필요한데 공인 대역에서는 사설 대역으로의 경로를 알 수 없으므로 NAT를 통해 요청해야 한다.

보안상 SNAT를 사용하므로써, 사설 IP 대역을 숨기는 경우도 있다.

DNAT는 로드 밸런서에서 많이 사용한다.
사용자는 서비스 요청을 위해 로드 밸런서에 설정된 VIP로 서비스를 요청하고 로드 밸런서에서는 서비스 VIP를 로드 밸런싱될 서버의 실제 IP로 DNAT해서 내보낸다.

동적 NAT, 정적 NAT

출발지와 목적지 IP를 미리 매핑해 고정해놓은 NAT를 정적 NAT라고 한다.
반대로 출발지나 목적지 어느 경우든 NAT를 수행할 때 IP를 동적으로 변경하는 것을 동적 NAT라고 한다.

동적 NAT는 출발지와 목적지가 모두 정의된 것이 아니라 다수의 IP 풀에서 정해지므로 최소한 출발지나 목적지 중 한 곳이 다수의 IP로 구성된 IP 풀로 설정되어 있다.

NAT가 필요할 때 IP 풀에서 어떤 IP로 매핑될 것인지 판단해 NAT를 수행하는 시점에서 NAT 테이블을 만들어 관리한다.

DNS

네트워크 프로토콜은 두 가지 실제 데이터를 실어나르는 데이터 프로토콜과 데이터 프로토콜이 잘 동작하도록 도와주는 컨트롤 프로토콜이 있다.
컨트롤 프로토콜은 통신에 직접 관여하지 않지만 처음 통신 관계를 맺거나 유지하는 데 큰 역할을 한다.
TCP/IP 프로토콜 체계를 유지하기 위한 주요 컨트롤 프로토콜에는 ARP, ICMP, DNS가 있다.

DNS는 도메인 주소를 IP 주소로 변환하는 역할을 한다.
도메인 주소가 일반 사용자에게 더 익숙하고, 서버 IP 변경에 쉽게 대처할 수 있으므로 굉장히 중요하다.

DNS 동작 방식

도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 한다.
하지만 DNS 서버없이 로컬에 도메인과 IP 주소를 직접 설정해 사용할 수도 있다.
로컬에서 도메인과 IP 주소를 관리하는 파일을 hosts 파일이라고 한다.
hosts 파일에 도메인과 IP 주소를 설정해두명 해당 도메인 리스트는 항상 DNS 캐시에 저장된다.

도메인을 쿼리하면 동일한 도메인을 매번 질의하지 않고 성능을 향상 시키기 위해 DNS 캐시 정보를 미리 확인한다.
이런 캐시 정보에는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시와 hosts 파일에 저장된 DNS 캐시 정보가 함께 저장되어 있다.
DNS 캐시 서버로 쿼리를 수행하고 DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장한다.

DNS 시스템 관점에서 보자면,
모든 도메인 정보를 DNS 서버 하나에 저장할 수는 없다.
그래서 DNS는 분산된 데이터베이스를 서로 도와주도록 설계되었다.
자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받을 수 있다.

DNS 서버는 기본적으로 루트 DNS 관련 정보를 가지고 있다.
클라이언트의 쿼리가 자신에게 정보가 없다면, 루트 DNS에 쿼리하고 루트 DNS는 쿼리한 도메인의 TLD 값을 확인해 해당 TLD 값을 관리하는 DNS 서버 정보를 알려준다.

클라이언트에서 처음 질의를 받은 DNS가 중심이 되어 책임지고 루트 DNS부터 상위 DNS에 쿼리를 보내 결과값을 알아내 최종 결과값을 클라이언트에게 되돌려준다.
클라이언트는 한번의 쿼리를 보내지만 요청을 받은 DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내 정보를 얻는다.

호스트가 DNS 서버에 질의했던 방식을 재귀적 쿼리,
DNS 서버가 다른 DNS 서버에게 질의한 방식을 반복적 쿼리 라고한다.
재귀적 쿼리는 쿼리를 보낸 클라이언트에 서버가 최종 결괏값을 반환하는 서버 중심 쿼리이고,
반복적 쿼리는 최종값을 받을 때까지 클라이언트에서 쿼리를 계속 진행하는 방식이다.

마스터 슬레이브

DNS 서버는 마스터 서버와 슬레이브 서버로 나눌 수 있다.
마스터와 슬레이브는 우선순위의 차이가 아닌 도메인에 대한 Zone 파일을 직접 관리하는지 여부로 구분한다.
마스터 서버는 존 파일을 직접 생성해 도메인 관련 정보를 관리하고 슬레이브 서버는 마스터에 만들어진 존 파일을 복제한다.
이 과정을 영역 전송(Zone Transfer) 라고 한다.

마스터 서버는 도메인 영역을 생성하고 레코드를 직접 관리하지만 슬레이브 서버는 마스터 서버에 설정된 도메인이 가진 레코드 값을 정기적으로 복제한다.

DNS 마스터 서버와 슬레이브 서버는 일반적인 이중화 방식인 액티브 스탠바이나 액티브 액티브 방식으로 구성하지 않는다.
DNS 서버는 마스터 서버에 문제가 발생하고 일정 시간이 지나면 슬레이브 서버도 동작을 할 수 없다.
이 시간을 만료 시간이라 하며, 만료 시간내에 마스터 서버를 복구하거나 슬레이브를 마스터로 전환해야 서비스 장애를 막을 수 있다.

DNS 주요 레코드

도메인에는 다양한 내용을 매핑할 수 있는 레코드가 있다.

레코드 종류	내용
A (IPv4 호스트)	도메인 주소를 IP 주소(IPv4)로 매핑
AAAA (IPv6 호스트)	도메인 주소를 IP 주소(IPv6)로 매핑
CNAME (별칭)	도메인 주소에 대한 별칭
SOA(관한 시작)	본 영역 데이터에 대한 권한
NS (도메인의 네임서버)	본 영역에 대한 네임 서버
MX (메일 교환기)	도메인에 대한 메일 서버 정보
PTR (포인터)	IP 주소를 도메인에 매핑 (역방향)
TXT (레코드)	도메인에 대한 일반 텍스트

A 레코드

도메인 주소를 IP 주소로 변환하는 레코드
사용자가 DNS에 질의한 도메인 주소를 A 레코드에 설정된 IP 주소로 응답한다.
한 개의 도메인 주소와 IP 주소가 1:1로 매핑되는데 동일한 도메인을 가진 A 레코드를 여러 개 만들어 서로 다른 IP 주소와 매핑할 수 있다.
반대로 다수의 도메인에 동일한 IP를 매핑한 A 레코드를 만들 수도 있다.
서버 한 대에 여러 웹 서비스를 구동해야 한다면 여러 도메인에 동일한 IP를 매핑하고 HTTP 헤더의 HOST 필드에 도메인을 명시해 웹 서버를 구분해 서비스할 수 있다.

AAAA 레코드

A 레코드와 같지만, IPv6 버전

CNAME 레코드

별칭 이름을 사용하게 해주는 레코드이다.
레코드 값에 IP 주소를 매핑하지 않고 도메인 주소를 매핑한다.
네임 서버가 CNAME 레코드에 대한 질의를 받으면 CNAME 레코드에 설정된 도메인 정보를 확인하고 그 도메인 정보를 내부적으로 다시 질의한다.

SOA 레코드

도메인 영역에 대한 권한을 나타내는 레코드이다.
현재 네임 서버가 이 도메인 영역에 대한 관리 주체임을 의미하므로 해당 도메인에 대해서는 다른 네임 서버에 질의하지 않고 직접 응답한다.
도메인 영역 선언 시 SOA 레코드가 필수 항목이므로, 이를 만들지 않으면 해당 도메인은 네임 서버에서 정상적으로 동작할 수 없다.
SOA 레코드는 도메인 관리에 필요한 값들을 설정하게 된다.

NS 레코드

도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드이다.
NS 레코드의 경우, 권한이 있는 네임 서버 정보를 해당 도메인에 설정하는 역할 외에 하위 도메인에 대한 권한을 다른 네임 서버로 위임하는 역할로도 많이 사용된다.

MX 레코드

메일 서버를 구성할 때 사용되는 레코드이다.
해당 도메인을 메일 주소로 갖는 메일 서버를 MX 레코드를 통해 선언한다.

PRT 레코드

A 레코드는 도메인 주소에 대한 질의를 IP로 응답하기 위한 레코드이고 PTR 레코드는 그 반대로 IP 주소에 대한 질의를 도메인 주소로 응답하기 위한 레코드이다.

TXT 레코드

도메인에 대한 간단한 텍스트를 입력할 수 있는 레코드이다.

DNS에서 많이 사용하는 개념

도메인 위임(DNS Delegation)

도메인은 그 도메인에 대한 정보를 관리할 수 있는 네임 서버를 지정하지만 도메인 내의 모든 레코드를 네임 서버가 직접 관리하지 않고 일부 영역에 대해서는 다른 곳에서 레코드를 관리하도록 위임하기도 한다.

자신의 가진 도메인 관리 권한을 다른 곳으로 일부 위임해 위임한 곳에서 세부 레코드를 관리하도록 하는 것이다.
CDN을 이용하거나 GSLB를 사용하는 것이 대표적인 경우이다.
도메인은 계층 구조이기에 특정 계층의 레코드를 위임하면 하위 계층은 함께 위임된다.

즉, 도메인 위임은 특정 영역을 다른 네임 서버에서 관리할 수 있는 권한을 위임하게 된다.
특정 영역에 대한 관리 주체를 분리하는 용도로 사용할 수 있어 계열사에서 특정 도메인을 분리하거나 GSLB 등 다용한 용도로 사용할 수 있다.

TTL

도메인의 TTL 값은 DNS에 질의해 응답받은 결과값을 캐시에서 유지하는 시간이다.
로컬 캐시에 저장된 도메인 정보를 무작정 갖고 있는 것이 아니라 DNS에 설정된 TTL 값에 따라 캐시에서 가지고 있는다.

TTL 값을 늘려 캐시를 많이 이용한다면, DNS 재귀적 쿼리로 인한 응답 시간을 많이 줄일 수 있지만 DNS에서 해당 도메인 관련 정보가 변경되었을 때, TTL 값이 크면 새로 변경된 값으로 DNS 정보 갱신이 그만큼 지연되는 단점이 발생한다.
반대로 TTL이 작으면, DNS 정보 갱신이 빨라져 DNS 쿼리량이 늘어나 서버 부하가 발생할 수 있다.

GSLB(Global Server/Service Load Balancing)

DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있다.
이렇게 설정하면 도메인 질의에 따라 응답 받는 IP 주소를 나누어 로드밸런싱할 수 있다.
이것을 DNS 로드밸런싱이라고 한다.
하지만 DNS만 이용한 로드밸런싱으로는 정상적으로 서비스를 할 수 없다.
DNS는 설정된 서비스 상태의 정상 여부를 확인하지 않고 도메인에 대한 질의는 무조건 응답한다.

GSLB는 DNS의 무넺점을 해결해 도메인을 통한 로드밸런싱 구현을 도와준다.
DNS와 동일하게 도메인 질의에 응답해주는 역할과 동시에 로드 밸런서처럼 등록된 도메인에 연결된 서비스가 정상적인지 헬스 체크를 수행한다.

GSLB 동작 방식

GSLB는 IP 주소만 단순히 갖고 있다가 응답해주는 것이 아니라 헬스 체크를 통해 해당 IP가 정상적인 서비스가 가능한지 확인한다.
만약 한 서버에 문제가 발생한다면, 동작 가능한 다른 서버의 IP 주소를 응답한다.

GSLB는 일반 DNS와 거의 동일하게 동작하지만, 서비스 IP 정보에 대한 헬스 체크와 사전에 지정한 다양한 분산 방법을 이용한 부하 분산이 일반 DNS와 큰 차이점이다.
일반 DNS는 두 개이상의 항목이 있다면 단순히 라운드 로빈으로 응답하지만, GSLB는 사전에 정의한 알고리즘에 의해 응답 주소를 결정한다.

GSLB 구성 방식

GSLB를 사용한 도메인 설정 방법은 두 가지가 있다.

• 도메인 자체를 GSLB로 사용
• 도메인 내의 특정 레코드만 GSLB를 사용

도메인 자체를 GSLB로 사용하면 해당 도메인에 속하는 모든 레코드 설정을 GSLB 장비에서 관리한다.
즉, 도메인에 대한 모든 레코드를 GSLB에서 설정한다.
GSLB 자체가 도메인의 네임 서버 역할을 하는 경우이다.

이 경우는 모든 레코드의 질의가 GSLB를 통하기 때문에 부하를 주게된다.

도메인 내의 특정 레코드만 GSLB를 사용한다면, DNS에서 도메인 설정 시 GSLB를 사용하려는 레코드에 대해서만 GSLB로 처리하도록 설정한다.
이를 설정하기 위해 CNAME(별칭)이나 NS(위임) 레코드를 통해 구성할 수 있다.

CDN처럼 GSLB를 운영해주는 외부 사업자가 있거나 GSLB를 사용해야 하는 도메인이 많은 경우, 별도의 GSLB를 운영하기 위해 별칭을 사용하고,
위임의 경우, 그 도메인의 하위 도메인은 같이 위임 처리되기 때문에, 도메인 내에서 GSLB를 사용한 하부 도메인을 계층화해 사용하면 DNS 서버 설정을 최소화해 GSLB로 다수의 위임 처리를 할 수 있다.

DHCP

IP 주소, 서브넷 마스크, 게이트웨이와 같은 네트워크 정보와 DNS 주소도 설정이 필요하다.
이런 네트워크 정보를 호스트에 적용하려면 사용자가 IP 정보를 직접 설정하거나 IP 정보를 할당해주는 서버를 이용해 자동으로 설정해야한다.

이것을 자동으로 해주는 것이 DHCP이다.
별도의 IP 설정 작업없이 네트워크에 접속할 수 있고 사용하지 않는 IP 정보는 회수되어 재사용할 수 있어 한정된 IP 주소를 유용하게 사용할 수 있고,
IP가 자동으로 관리되므로 설정 정보 오류나 중복 IP 할당 문제를 방지할 수 있다.

DHCP 프로토콜

DHCP는 BOOTP 프로토콜을 기반으로 한다.
BOOTP 프로토콜과 유사하게 동작하지만 기능이 추가 확장된 프로토콜이다.
DHCP와 BOOTP는 호환성이 있어 사용하는 포트가 같고 서로 호환하여 사용할 수 있다.

DHCP 동작 방식

DHCP는 아래와 같이 동작한다.

1. DHCP Discover
DHCP 클라이언트는 DHCP 서버를 찾기 위해 DHCP Discover 메시지를 브로드캐스트 한다.

2. DHCP Offer
DHCP Discover를 수신한 DHCP 서버는 클라이언트에 할당된 IP 주소와 서브넷, 게이트웨이, DNS 정보, Lease Time 등의 정보를 포함한 DHCP 메시지를 클라이언트로 전송한다.

3. DHCP Request
DHCP 서버로부터 제안받은 IP 주소와 DHCP 서버 정보를 포함한 DHCP 요청 메시지를 브로드캐스트로 전송한다.

4. DHCP Acknowledgement
DHCP 클라이언트로부터 IP 주소를 사용하겠다는 요청을 받으면 DHCP 서버에 해당 IP를 어던 클라이언트가 사용하는지 정보를 기록하고 DHCP Request 메시지에 대한 Ack를 전송한다.

DHCP Discover 메시지는 서버를 찾기 위해 브로드캐스트 한다.
DHCP 서버가 Discover 메시지를 받고 IP 풀중 할당할 IP 정보와 서브넷, 게이트웨이, DNS정보, IP 주소 임대 시간, DHCP 서버 IP 정보를 포함한 Offer 메시지를 전송한다.
클라이언트는 서버로부터 제안받은 IP 정보를 사용하기 위해 Request 메시지를 전송한다.
Offer 메시지에 IP 설정 정보를 모두 포함하고 있어 IP를 설정하고 유니캐스트로 패킷을 전달해도 되지만 DHCP 서버가 여러 대인 환경을 위해 브로드캐스트 한다.
DHCP 서버가 여러 대라면 클라이언트는 DHCP 서버로부터 Offer를 여러 개 받게되고 그중 한 Offer에 대해서 Request를 보낸다.
서버들은 자신이 제안한 IP 주소인지 여부를 확인해 자신의 Offer에 대한 Request인지 확인하고 그 패킷에 대해서만 응답한다.
서버는 마지막으로 Acknowledgement를 보내고 Offer와 내용이 동일하다.

IP 임대 시간은 이 IP를 사용할 수 있는 시간을 나타내며, 이 시간마다 갱신을 해줘야한다.
하지만 실제로 그러기는 힘들기 때문에 임대를 갱신한다.
임대 시간의 50%가 지나면 DHCP 갱신을 진행한다.
클라이언트는 이제 서버 정보를 알기 때문에 Discover와 Offer를 생략하고 Request부터 진행하고, 서버도 ACK를 보낸다.
갱신 과정은 임대 과정에 비해 절차가 짧으며 유니캐스트로 진행되므로 불필요한 브로드캐스트가 발생하지 않는다.

DHCP 릴레이

DHCP 서버에서 IP 주소를 할당받기 위해 DHCP 클라이언트와 DHCP 서버 간에 전송되는 패킷은 모두 브로드캐스트이다.
브로드캐스트는 동일 네트워크에만 전송되므로 DHCP를 사용하려면 각 네트워크마다 DHCP 서버가 있어야 한다.

여러 네트워크에서도 DHCP 서버 한 대로 IP 풀을 관리하기 위해 DHCP 릴레이 에이전트 기능이 있다.
DHCP 릴레이 에이전트가 DHCP 클라이언트와 서버 사이의 DHCP 패킷을 중계해주는 역할을 한다.

DHCP 릴레이 에이전트를 사용하면 브로드캐스트인 DHCP 패킷을 동일 네트워크 대역의 DHCP 에이전트가 수신해 DHCP 서버로 갈 수 있도록 유니캐스트로 변환해준다.

DHCP 릴레이 에이전트가 있을 때의 DHCP 흐름은 아래와 같다.

1. DHCP Discover (클라이언트 -> 릴레이 에이전트)
DHCP 서버를 찾기위해 브로드캐스트

2. DHCP Discover (릴레이 에이전트 -> 서버)
에이전트는 클라이언트가 보낸 Discover를 출발지와 목적지를 에이전트 IP 주소와 서버 IP 주소로 변환한다.

3. DHCP Offer (서버 -> 릴레이 에이전트)
서버는 클라이언트에 할당할 IP 주소 등을 에이전트로 전송한다.
이때도 유니캐스트이다.

4. DHCP Offer (릴레이 에이전트 -> 클라이언트)
에이전트는 서버로부터 받은 Offer를 클라이언트로 브로드캐스트한다.
DHCP Server Identifier는 실제 서버 IP 에서 에이전트의 인터페이스 IP로 변경된다.

5. DHCP Reqeuest (클라이언트 -> 릴레이 에이전트)
서버로부터 받은 Offer에 대한 요청을 브로드캐스트한다.

6. DHCP Reqeuest (릴레이 에이전트 -> 서버)
클라이언트에서 보낸 요청을 유니캐스트로 변환해 전송한다.

7. DHCP ACK (서버 -> 릴레이 에이전트)
요청에 대한 정볼르 기록하고 Ack를 유니캐스트 한다.

8. DHCp ACK (릴레이 에이전트 -> 클라이언트)
Ack를 다시 클라이언트에게 브로드캐스트 한다.

위 과정을 보면, DHCP 클라이언트는 중간에 에이전트가 꼈는지 알지 못하므로 전체 동작 자체는 동일하다.
이때 클라이언트와 에이전트는 브로드캐스트로 동작하고 에이전트와 서버는 유니캐스트로 동작한다.
이것을 위해 에이전트는 클라이언트와 같은 네트워크 내에 존재해야 하며 서버의 IP를 알고 있어야한다.