IPv4 Addressing - 편집 역사

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

2026-01-15T12:59:39Z

봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

← 이전 판		2026년 1월 15일 (목) 12:59 판
124번째 줄:		124번째 줄:

	==각주==		==각주==
	[[분류:컴퓨터 ~~네트워크~~]]		[[분류:컴퓨터 네트워킹]]

Pinkgo: /* 개요 */

2025-05-11T08:04:42Z

개요

← 이전 판		2025년 5월 11일 (일) 08:04 판
6번째 줄:		6번째 줄:
	* 193은 처음 8비트를 10진수로 나타낸 것,		* 193은 처음 8비트를 10진수로 나타낸 것,
	* 32는 두 번째 8비트,		* 32는 두 번째 8비트,
	* 216은 세 번째,		* 216은 세 번째 8비트,
	* 9는 마지막 8비트에 해당한다.		* 9는 마지막 8비트에 해당한다.
	따라서 <code>193.32.216.9</code>는 2진수로 표현하면 다음과 같다:		따라서 <code>193.32.216.9</code>는 2진수로 표현하면 다음과 같다:
	11000001 00100000 11011000 00001001		11000001 00100000 11011000 00001001
	인터넷에 연결된 모든 호스트와 라우터의 각 인터페이스는 전세계에서 유일한 IP 주소를 가져야 한다.<ref>단, NAT 뒤에 있는 인터페이스는 예외이다.</ref>		인터넷에 연결된 모든 호스트와 라우터의 각 인터페이스는 전세계에서 유일한 IP 주소를 가져야 한다.<ref>단, NAT 뒤에 있는 인터페이스는 예외이다.</ref>

	==Subnet==		==Subnet==

Pinkgo: /* DHCP */

2025-04-23T04:57:27Z

DHCP

← 이전 판		2025년 4월 23일 (수) 04:57 판
112번째 줄:		112번째 줄:
	#* 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)<ref>application layer에 해당하므로 message가 사용된다.</ref>를 보낸다.		#* 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)<ref>application layer에 해당하므로 message가 사용된다.</ref>를 보낸다.
	#* 이 메시지는 UDP 포트 67번으로 전송되는 UDP 패킷 안에 담기며, 이 UDP 패킷은 IP 데이터그램에 캡슐화된다.		#* 이 메시지는 UDP 포트 67번으로 전송되는 UDP 패킷 안에 담기며, 이 UDP 패킷은 IP 데이터그램에 캡슐화된다.
	#* 이때 호스트는 DHCP 서버의 주소는 당연히 모르고 있기 때문에, datagram의 헤더필드를 구성할 때, 목적지의 IP 주소는 <code>255.255.255.255</code>(브로드캐스트 주소)로, 출발지 IP 주소는 <code>0.0.0.0</code>(미지정 주소)로 ~~구성한다~~.		#* 이때 호스트는 DHCP 서버의 주소는 당연히 모르고 있기 때문에, datagram의 헤더필드를 구성할 때, '''목적지의 IP 주소는 <code>255.255.255.255</code>(브로드캐스트 주소)로, 출발지 IP 주소는 <code>0.0.0.0</code>(미지정 주소)로 구성'''한다.
	#* 해당 IP 데이터그램은 link layer로 전달되고, link layer에서 해당 프레임(frame)은 같은 subnet에 있는 모든 노드에 브로드캐스팅한다.		#* 해당 IP 데이터그램은 link layer로 전달되고, link layer에서 해당 프레임(frame)은 같은 subnet에 있는 모든 노드에 브로드캐스팅한다.
	# DHCP 서버 응답 (DHCP offer)		# DHCP 서버 응답 (DHCP offer)
	#* DHCP Discover 메시지를 받은 DHCP 서버는 클라이언트에게 DHCP Offer 메시지로 응답한다.		#* DHCP Discover 메시지를 받은 DHCP 서버는 클라이언트에게 DHCP Offer 메시지로 응답한다.
	#* 이 메시지도 브로드캐스트로 보내지며, 목적지 IP 주소는 다시 <code>255.255.255.255</code>이다.		#* 이 '''메시지도 브로드캐스트로 보내지며, 목적지 IP 주소는 다시 <code>255.255.255.255</code>'''이다.
	#* 하나 이상의 DHCP 서버가 한 subnet 내에 존재하는 경우, 클라이언트는 여러 offer 중에서 선택할 수 있다.		#* 하나 이상의 DHCP 서버가 한 subnet 내에 존재하는 경우, 클라이언트는 여러 offer 중에서 선택할 수 있다.
	# DHCP 요청 (DHCP request)		# DHCP 요청 (DHCP request)
	#* 클라이언트는 받은 offer 중에서 하나를 선택하고, 그 선택된 서버에게 DHCP Request ~~메시지를~~ 보낸다.		#* 클라이언트는 받은 offer 중에서 하나를 선택하고, 그 선택된 '''서버에게 DHCP Request 메시지'''를 보낸다.
	# DHCP 승인 (DHCP ACK)		# '''DHCP 승인 (DHCP ACK)'''
	#* 서버는 클라이언트의 요청에 대해 DHCP ACK 메시지로 응답하여, 클라이언트가 요청한 IP 주소를 확인해준다.		#* 서버는 클라이언트의 요청에 대해 DHCP ACK 메시지로 응답하여, 클라이언트가 요청한 IP 주소를 확인해준다.

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* DHCP */

2025-04-19T06:17:21Z

DHCP

← 이전 판		2025년 4월 19일 (토) 06:17 판
97번째 줄:		97번째 줄:
	Route aggregation은 주소가 ISP에게 블록 단위로 할당하고, 이 후 ISP가 이를 고객의 조직에게 다시 할당하는, 즉 계층적인 구조로 주소 블록이 할당될 때 효과적으로 작동한다. 하지만 주소 블록이 계층적인 방식으로 할당되지 않는 경우도 존재한다. 예를 들어, Figure 5와 같이 Fly-By-Night-ISP가 ISPs-R-Us라는 ISP를 인수하고, 1번 조직이 ISPs-R-Us를 통해 인터넷에 접속하는 경우가 있을 수 있다. 이 경우 ISPs-R-Us는 <code>199.31.0.0/16</code> 주소 블록을 가지고 있지만, 1번 조직의 IP 주소는 해당 주소 밖에 존재한다.<br>		Route aggregation은 주소가 ISP에게 블록 단위로 할당하고, 이 후 ISP가 이를 고객의 조직에게 다시 할당하는, 즉 계층적인 구조로 주소 블록이 할당될 때 효과적으로 작동한다. 하지만 주소 블록이 계층적인 방식으로 할당되지 않는 경우도 존재한다. 예를 들어, Figure 5와 같이 Fly-By-Night-ISP가 ISPs-R-Us라는 ISP를 인수하고, 1번 조직이 ISPs-R-Us를 통해 인터넷에 접속하는 경우가 있을 수 있다. 이 경우 ISPs-R-Us는 <code>199.31.0.0/16</code> 주소 블록을 가지고 있지만, 1번 조직의 IP 주소는 해당 주소 밖에 존재한다.<br>
	단순한 해결책은 1번 조직이 해당 조직의 네트워크 내의 모든 라우터와 호스트 주소들을 ISPs-R-Us 주소 블록 범위에 맞도록 바꾸는 것이다. 하지만 이는 비용이 많이 들기 떄문에 실제로 사용되는 방식은 아니다. 일반적인 해결책은 1번 조직이 기존의 IP 주소를 유지하는 것이다. 이 경우 figure 5에 나와 있듯이 Fly-By-Night-ISP는 계속해서 주소 블록 <code>200.23.16.0/20</code>을 광고하고, ISPs-R-Us는 <code>199.31.0.0/16</code>을 광고하는 동시에, 추가로 1번 조직의 주소 블록인 <code>200.23.18.0/23</code>도 함께 광고한다. 만약 목적지 IP 주소가 <code>200.23.18.5/23</code>인 패킷이 라우터 내에서 [[Network Layer#Routing and Forwarding\|forwarding]]된다면, 라우터는 [[Router#Input port function#Destination-based forwarding\|longest prefix matching]] 방식을 사용하므로 ISPs-R-Us 쪽으로 해당 패킷을 전송한다.		단순한 해결책은 1번 조직이 해당 조직의 네트워크 내의 모든 라우터와 호스트 주소들을 ISPs-R-Us 주소 블록 범위에 맞도록 바꾸는 것이다. 하지만 이는 비용이 많이 들기 떄문에 실제로 사용되는 방식은 아니다. 일반적인 해결책은 1번 조직이 기존의 IP 주소를 유지하는 것이다. 이 경우 figure 5에 나와 있듯이 Fly-By-Night-ISP는 계속해서 주소 블록 <code>200.23.16.0/20</code>을 광고하고, ISPs-R-Us는 <code>199.31.0.0/16</code>을 광고하는 동시에, 추가로 1번 조직의 주소 블록인 <code>200.23.18.0/23</code>도 함께 광고한다. 만약 목적지 IP 주소가 <code>200.23.18.5/23</code>인 패킷이 라우터 내에서 [[Network Layer#Routing and Forwarding\|forwarding]]된다면, 라우터는 [[Router#Input port function#Destination-based forwarding\|longest prefix matching]] 방식을 사용하므로 ISPs-R-Us 쪽으로 해당 패킷을 전송한다.


	==DHCP==		==DHCP==
	[[파일:DHCP client and server.png\|alt=Figure 6. DHCP client and server\|섬네일\|'''Figure 6. DHCP client and server''' ]]		[[파일:DHCP client and server.png\|alt=Figure 6. DHCP client and server\|섬네일\|'''Figure 6. DHCP client and server''' ]]

Pinkgo: /* Hierarchical addressing: route aggregation */

2025-04-12T04:38:20Z

Hierarchical addressing: route aggregation

← 이전 판		2025년 4월 12일 (토) 04:38 판
90번째 줄:		90번째 줄:

	==Hierarchical addressing: route aggregation==		==Hierarchical addressing: route aggregation==
	<gallery ~~caption="Sample gallery"~~ widths="405px" heights="265px">		<gallery widths="405px" heights="265px">
	Hierarchical addressing and route aggregation.png\|Figure 4. Hierarchical addressing and route aggregation		Hierarchical addressing and route aggregation.png\|Figure 4. Hierarchical addressing and route aggregation
	ISPs-R-Us has a more specific route to Organization 1.png\|Figure 5. ISPs-R-Us has a more specific route to Organization 1		ISPs-R-Us has a more specific route to Organization 1.png\|Figure 5. ISPs-R-Us has a more specific route to Organization 1
	</gallery>		</gallery>

	[[파일:Hierarchical addressing and route aggregation.png\|대체글=Figure 4. Hierarchical addressing and route aggregation\|가운데\|섬네일\|400x400픽셀\|'''Figure 4. Hierarchical addressing and route aggregation''' ]]
	[[파일:ISPs-R-Us has a more specific route to Organization 1.png\|대체글=Figure 5. ISPs-R-Us has a more specific route to Organization 1\|가운데\|섬네일\|400x400픽셀\|'''Figure 5. ISPs-R-Us has a more specific route to Organization 1''' ]]
	Figure 4는 8개의 조직을 연결해주는 ISP의 예시를 통해서 CIDR 방식으로 할당된 주소가 효율적으로 라우팅을 지원하는 것을 보여준다. Figure 4의 ISP(Fly-By-Night-ISP)는 외부 네트워크에 대해, prefix가 <code>200.23.16.0/20</code>과 일치하는 모든 데이터그램을 자신에게 보내라고 광고(advertise)한다. 이때 외부 네트워크는 <code>200.23.16.0/20</code>주소 블록 내부에 실제로 8개의 조직이 각각의 subnet을 가지고 있다는 사실을 알 필요가 없다. 이와 같이 '''하나의 prefix를 사용하여 여러 subnet을 광고'''하는 방식을 '''route aggregation'''이라고 한다.<br>		Figure 4는 8개의 조직을 연결해주는 ISP의 예시를 통해서 CIDR 방식으로 할당된 주소가 효율적으로 라우팅을 지원하는 것을 보여준다. Figure 4의 ISP(Fly-By-Night-ISP)는 외부 네트워크에 대해, prefix가 <code>200.23.16.0/20</code>과 일치하는 모든 데이터그램을 자신에게 보내라고 광고(advertise)한다. 이때 외부 네트워크는 <code>200.23.16.0/20</code>주소 블록 내부에 실제로 8개의 조직이 각각의 subnet을 가지고 있다는 사실을 알 필요가 없다. 이와 같이 '''하나의 prefix를 사용하여 여러 subnet을 광고'''하는 방식을 '''route aggregation'''이라고 한다.<br>
	Route aggregation은 주소가 ISP에게 블록 단위로 할당하고, 이 후 ISP가 이를 고객의 조직에게 다시 할당하는, 즉 계층적인 구조로 주소 블록이 할당될 때 효과적으로 작동한다. 하지만 주소 블록이 계층적인 방식으로 할당되지 않는 경우도 존재한다. 예를 들어, Figure 5와 같이 Fly-By-Night-ISP가 ISPs-R-Us라는 ISP를 인수하고, 1번 조직이 ISPs-R-Us를 통해 인터넷에 접속하는 경우가 있을 수 있다. 이 경우 ISPs-R-Us는 <code>199.31.0.0/16</code> 주소 블록을 가지고 있지만, 1번 조직의 IP 주소는 해당 주소 밖에 존재한다.<br>		Route aggregation은 주소가 ISP에게 블록 단위로 할당하고, 이 후 ISP가 이를 고객의 조직에게 다시 할당하는, 즉 계층적인 구조로 주소 블록이 할당될 때 효과적으로 작동한다. 하지만 주소 블록이 계층적인 방식으로 할당되지 않는 경우도 존재한다. 예를 들어, Figure 5와 같이 Fly-By-Night-ISP가 ISPs-R-Us라는 ISP를 인수하고, 1번 조직이 ISPs-R-Us를 통해 인터넷에 접속하는 경우가 있을 수 있다. 이 경우 ISPs-R-Us는 <code>199.31.0.0/16</code> 주소 블록을 가지고 있지만, 1번 조직의 IP 주소는 해당 주소 밖에 존재한다.<br>
	단순한 해결책은 1번 조직이 해당 조직의 네트워크 내의 모든 라우터와 호스트 주소들을 ISPs-R-Us 주소 블록 범위에 맞도록 바꾸는 것이다. 하지만 이는 비용이 많이 들기 떄문에 실제로 사용되는 방식은 아니다. 일반적인 해결책은 1번 조직이 기존의 IP 주소를 유지하는 것이다. 이 경우 figure 5에 나와 있듯이 Fly-By-Night-ISP는 계속해서 주소 블록 <code>200.23.16.0/20</code>을 광고하고, ISPs-R-Us는 <code>199.31.0.0/16</code>을 광고하는 동시에, 추가로 1번 조직의 주소 블록인 <code>200.23.18.0/23</code>도 함께 광고한다. 만약 목적지 IP 주소가 <code>200.23.18.5/23</code>인 패킷이 라우터 내에서 [[Network Layer#Routing and Forwarding\|forwarding]]된다면, 라우터는 [[Router#Input port function#Destination-based forwarding\|longest prefix matching]] 방식을 사용하므로 ISPs-R-Us 쪽으로 해당 패킷을 전송한다.		단순한 해결책은 1번 조직이 해당 조직의 네트워크 내의 모든 라우터와 호스트 주소들을 ISPs-R-Us 주소 블록 범위에 맞도록 바꾸는 것이다. 하지만 이는 비용이 많이 들기 떄문에 실제로 사용되는 방식은 아니다. 일반적인 해결책은 1번 조직이 기존의 IP 주소를 유지하는 것이다. 이 경우 figure 5에 나와 있듯이 Fly-By-Night-ISP는 계속해서 주소 블록 <code>200.23.16.0/20</code>을 광고하고, ISPs-R-Us는 <code>199.31.0.0/16</code>을 광고하는 동시에, 추가로 1번 조직의 주소 블록인 <code>200.23.18.0/23</code>도 함께 광고한다. 만약 목적지 IP 주소가 <code>200.23.18.5/23</code>인 패킷이 라우터 내에서 [[Network Layer#Routing and Forwarding\|forwarding]]된다면, 라우터는 [[Router#Input port function#Destination-based forwarding\|longest prefix matching]] 방식을 사용하므로 ISPs-R-Us 쪽으로 해당 패킷을 전송한다.


	==DHCP==		==DHCP==
	[[파일:DHCP client and server.png\|~~대체글~~=Figure 4. DHCP client and server\|섬네일\|'''Figure 4. DHCP client and server''' ]]		[[파일:DHCP client and server.png\|alt=Figure 6. DHCP client and server\|섬네일\|'''Figure 6. DHCP client and server''' ]]
	어떤 조직이 IP 주소 블록을 하나 확보한 이후에는, 그 주소 블록 내에서 개별 호스트와 라우터 인터페이스에 IP 주소를 할당할 수 있다. 시스템 관리자는 보통 라우터에 IP 주소를 수동으로 설정하며, 이는 종종 네트워크 관리 도구를 통해 원격으로 수행된다. 호스트의 주소도 수동으로 설정될 수 있지만 때로는 자동으로 설정되어야 할 때도 있다. 그 이유는 호스트의 IP 주소는 종종 고정되어 있지 않기 때문이다. 예를 들어 figure 4과 같이 새로운 기기가 Wi-Fi 등을 통해 네트워크에 접속할 때, IP 주소를 매번 수동으로 입력하기란 정말 귀찮은 일이다. 따라서 이러한 경우, '''DHCP(Dynamic Host Configuration Protocol)'''이라고 하는 '''application layer'''의 프로토콜을 사용하여 호스트가 자동으로 IP 주소를 할당받도록 해준다. 이때 네트워크 관리자는 DHCP를 설정할 때, 특정 호스트가 매번 같은 IP 주소를 받도록 할 수도 있고, 또는 연결할 때마다 다른 임시 IP 주소를 할당하도록 설정할 수도 있다.<br>		어떤 조직이 IP 주소 블록을 하나 확보한 이후에는, 그 주소 블록 내에서 개별 호스트와 라우터 인터페이스에 IP 주소를 할당할 수 있다. 시스템 관리자는 보통 라우터에 IP 주소를 수동으로 설정하며, 이는 종종 네트워크 관리 도구를 통해 원격으로 수행된다. 호스트의 주소도 수동으로 설정될 수 있지만 때로는 자동으로 설정되어야 할 때도 있다. 그 이유는 호스트의 IP 주소는 종종 고정되어 있지 않기 때문이다. 예를 들어 figure 6와 같이 새로운 기기가 Wi-Fi 등을 통해 네트워크에 접속할 때, IP 주소를 매번 수동으로 입력하기란 정말 귀찮은 일이다. 따라서 이러한 경우, '''DHCP(Dynamic Host Configuration Protocol)'''이라고 하는 '''application layer'''의 프로토콜을 사용하여 호스트가 자동으로 IP 주소를 할당받도록 해준다. 이때 네트워크 관리자는 DHCP를 설정할 때, 특정 호스트가 매번 같은 IP 주소를 받도록 할 수도 있고, 또는 연결할 때마다 다른 임시 IP 주소를 할당하도록 설정할 수도 있다.<br>
	IP 주소 할당 외에도, DHCP는 호스트가 다음과 같은 추가 정보도 함께 학습할 수 있도록 해준다:		IP 주소 할당 외에도, DHCP는 호스트가 다음과 같은 추가 정보도 함께 학습할 수 있도록 해준다:
	* subnet mask		* subnet mask
111번째 줄:		109번째 줄:

	DHCP는 클라이언트-서버(client-server) 프로토콜이며, 단순한 경우 각각의 subnet에 DHCP 서버가 하나씩 존재하여 새로운 클라이언트의 IP 주소 요청을 처리할 수 있다. 하지만 어떤 subnet에는 DHCP 서버가 없을 수 있는데, 이 때에는 DHCP 릴레이 에이전트(보통 라우터)가 존재하여, 해당 네트워크에 대한 DHCP 서버의 주소를 제공한다. figure 7에는 DHCP 서버가 <code>223.1.2.0/24</code> 서브넷에 연결되어 있고, 라우터가 <code>223.1.1.0/24</code> 및 <code>223.1.3.0/24</code> 서브넷에서 들어오는 클라이언트를 위한 릴레이 에이전트 역할을 수행하는 모습을 보여준다.		DHCP는 클라이언트-서버(client-server) 프로토콜이며, 단순한 경우 각각의 subnet에 DHCP 서버가 하나씩 존재하여 새로운 클라이언트의 IP 주소 요청을 처리할 수 있다. 하지만 어떤 subnet에는 DHCP 서버가 없을 수 있는데, 이 때에는 DHCP 릴레이 에이전트(보통 라우터)가 존재하여, 해당 네트워크에 대한 DHCP 서버의 주소를 제공한다. figure 7에는 DHCP 서버가 <code>223.1.2.0/24</code> 서브넷에 연결되어 있고, 라우터가 <code>223.1.1.0/24</code> 및 <code>223.1.3.0/24</code> 서브넷에서 들어오는 클라이언트를 위한 릴레이 에이전트 역할을 수행하는 모습을 보여준다.
	[[파일:DHCP client-server interaction.png\|~~대체글~~=Figure 5. DHCP client-server interaction\|섬네일\|408x408픽셀\|'''Figure 5. DHCP client-server interaction''' ]]		[[파일:DHCP client-server interaction.png\|alt=Figure 7. DHCP client-server interaction\|섬네일\|408x408픽셀\|'''Figure 7. DHCP client-server interaction''' ]]
	DHCP의 동작 방식은 figure 5에 잘 나타나 있다. 새로운 호스트가 네트워크에 도착했을 때, DHCP 프로토콜은 다음의 4단계 과정을 거친다.		DHCP의 동작 방식은 figure 7에 잘 나타나 있다. 새로운 호스트가 네트워크에 도착했을 때, DHCP 프로토콜은 다음의 4단계 과정을 거친다.
	# DHCP 서버 발견 (DHCP server discovery)		# DHCP 서버 발견 (DHCP server discovery)
	#* 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)<ref>application layer에 해당하므로 message가 사용된다.</ref>를 보낸다.		#* 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)<ref>application layer에 해당하므로 message가 사용된다.</ref>를 보낸다.

Pinkgo: /* Hierarchical addressing: route aggregation */

2025-04-12T04:37:00Z

Hierarchical addressing: route aggregation

← 이전 판		2025년 4월 12일 (토) 04:37 판
90번째 줄:		90번째 줄:

	==Hierarchical addressing: route aggregation==		==Hierarchical addressing: route aggregation==
			<gallery caption="Sample gallery" widths="405px" heights="265px">
			Hierarchical addressing and route aggregation.png\|Figure 4. Hierarchical addressing and route aggregation
			ISPs-R-Us has a more specific route to Organization 1.png\|Figure 5. ISPs-R-Us has a more specific route to Organization 1
			</gallery>

			[[파일:Hierarchical addressing and route aggregation.png\|대체글=Figure 4. Hierarchical addressing and route aggregation\|가운데\|섬네일\|400x400픽셀\|'''Figure 4. Hierarchical addressing and route aggregation''' ]]
			[[파일:ISPs-R-Us has a more specific route to Organization 1.png\|대체글=Figure 5. ISPs-R-Us has a more specific route to Organization 1\|가운데\|섬네일\|400x400픽셀\|'''Figure 5. ISPs-R-Us has a more specific route to Organization 1''' ]]
	Figure 4는 8개의 조직을 연결해주는 ISP의 예시를 통해서 CIDR 방식으로 할당된 주소가 효율적으로 라우팅을 지원하는 것을 보여준다. Figure 4의 ISP(Fly-By-Night-ISP)는 외부 네트워크에 대해, prefix가 <code>200.23.16.0/20</code>과 일치하는 모든 데이터그램을 자신에게 보내라고 광고(advertise)한다. 이때 외부 네트워크는 <code>200.23.16.0/20</code>주소 블록 내부에 실제로 8개의 조직이 각각의 subnet을 가지고 있다는 사실을 알 필요가 없다. 이와 같이 '''하나의 prefix를 사용하여 여러 subnet을 광고'''하는 방식을 '''route aggregation'''이라고 한다.<br>		Figure 4는 8개의 조직을 연결해주는 ISP의 예시를 통해서 CIDR 방식으로 할당된 주소가 효율적으로 라우팅을 지원하는 것을 보여준다. Figure 4의 ISP(Fly-By-Night-ISP)는 외부 네트워크에 대해, prefix가 <code>200.23.16.0/20</code>과 일치하는 모든 데이터그램을 자신에게 보내라고 광고(advertise)한다. 이때 외부 네트워크는 <code>200.23.16.0/20</code>주소 블록 내부에 실제로 8개의 조직이 각각의 subnet을 가지고 있다는 사실을 알 필요가 없다. 이와 같이 '''하나의 prefix를 사용하여 여러 subnet을 광고'''하는 방식을 '''route aggregation'''이라고 한다.<br>
	Route aggregation은 주소가 ISP에게 블록 단위로 할당하고, 이 후 ISP가 이를 고객의 조직에게 다시 할당하는, 즉 계층적인 구조로 주소 블록이 할당될 때 효과적으로 작동한다. 하지만 주소 블록이 계층적인 방식으로 할당되지 않는 경우도 존재한다. 예를 들어, Figure 5와 같이 Fly-By-Night-ISP가 ISPs-R-Us라는 ISP를 인수하고, 1번 조직이 ISPs-R-Us를 통해 인터넷에 접속하는 경우가 있을 수 있다. 이 경우 ISPs-R-Us는 <code>199.31.0.0/16</code> 주소 블록을 가지고 있지만, 1번 조직의 IP 주소는 해당 주소 밖에 존재한다.<br>		Route aggregation은 주소가 ISP에게 블록 단위로 할당하고, 이 후 ISP가 이를 고객의 조직에게 다시 할당하는, 즉 계층적인 구조로 주소 블록이 할당될 때 효과적으로 작동한다. 하지만 주소 블록이 계층적인 방식으로 할당되지 않는 경우도 존재한다. 예를 들어, Figure 5와 같이 Fly-By-Night-ISP가 ISPs-R-Us라는 ISP를 인수하고, 1번 조직이 ISPs-R-Us를 통해 인터넷에 접속하는 경우가 있을 수 있다. 이 경우 ISPs-R-Us는 <code>199.31.0.0/16</code> 주소 블록을 가지고 있지만, 1번 조직의 IP 주소는 해당 주소 밖에 존재한다.<br>

Pinkgo: /* Hierarchical addressing: route aggregation */

2025-04-12T04:32:14Z

Hierarchical addressing: route aggregation

← 이전 판		2025년 4월 12일 (토) 04:32 판
90번째 줄:		90번째 줄:

	==Hierarchical addressing: route aggregation==		==Hierarchical addressing: route aggregation==
	~~https:~~//~~chatgpt~~.~~com~~/c/~~67f90fc8~~-~~b8a8~~-~~800b~~-~~b953~~-~~e0c95ba30bac 참고하여 정리~~		Figure 4는 8개의 조직을 연결해주는 ISP의 예시를 통해서 CIDR 방식으로 할당된 주소가 효율적으로 라우팅을 지원하는 것을 보여준다. Figure 4의 ISP(Fly-By-Night-ISP)는 외부 네트워크에 대해, prefix가 <code>200.23.16.0/20</code>과 일치하는 모든 데이터그램을 자신에게 보내라고 광고(advertise)한다. 이때 외부 네트워크는 <code>200.23.16.0/20</code>주소 블록 내부에 실제로 8개의 조직이 각각의 subnet을 가지고 있다는 사실을 알 필요가 없다. 이와 같이 '''하나의 prefix를 사용하여 여러 subnet을 광고'''하는 방식을 '''route aggregation'''이라고 한다.<br>
			Route aggregation은 주소가 ISP에게 블록 단위로 할당하고, 이 후 ISP가 이를 고객의 조직에게 다시 할당하는, 즉 계층적인 구조로 주소 블록이 할당될 때 효과적으로 작동한다. 하지만 주소 블록이 계층적인 방식으로 할당되지 않는 경우도 존재한다. 예를 들어, Figure 5와 같이 Fly-By-Night-ISP가 ISPs-R-Us라는 ISP를 인수하고, 1번 조직이 ISPs-R-Us를 통해 인터넷에 접속하는 경우가 있을 수 있다. 이 경우 ISPs-R-Us는 <code>199.31.0.0/16</code> 주소 블록을 가지고 있지만, 1번 조직의 IP 주소는 해당 주소 밖에 존재한다.<br>
			단순한 해결책은 1번 조직이 해당 조직의 네트워크 내의 모든 라우터와 호스트 주소들을 ISPs-R-Us 주소 블록 범위에 맞도록 바꾸는 것이다. 하지만 이는 비용이 많이 들기 떄문에 실제로 사용되는 방식은 아니다. 일반적인 해결책은 1번 조직이 기존의 IP 주소를 유지하는 것이다. 이 경우 figure 5에 나와 있듯이 Fly-By-Night-ISP는 계속해서 주소 블록 <code>200.23.16.0/20</code>을 광고하고, ISPs-R-Us는 <code>199.31.0.0/16</code>을 광고하는 동시에, 추가로 1번 조직의 주소 블록인 <code>200.23.18.0/23</code>도 함께 광고한다. 만약 목적지 IP 주소가 <code>200.23.18.5/23</code>인 패킷이 라우터 내에서 [[Network Layer#Routing and Forwarding\|forwarding]]된다면, 라우터는 [[Router#Input port function#Destination-based forwarding\|longest prefix matching]] 방식을 사용하므로 ISPs-R-Us 쪽으로 해당 패킷을 전송한다.

	==DHCP==		==DHCP==

Pinkgo: /* Obtaining a Block of Addresses */

2025-04-11T20:06:38Z

Obtaining a Block of Addresses

← 이전 판		2025년 4월 11일 (금) 20:06 판
88번째 줄:		88번째 줄:
	</syntaxhighlight>		</syntaxhighlight>
	ISP로부터 주소 블록을 얻는 것이 주소 블록을 획득하는 한 가지 방법이지만, 유일한 방법은 아니다. 분명한 것은, ISP 자체도 주소 블록을 받을 수 있는 어떤 절차가 있어야 한다는 것이다. 이를 위해서 전세계적으로 IP 주소 공간을 관리하고 ISP 및 기타 조직에 주소 블록을 할당하는 궁극적인 권한을 가진 기관으로 '''ICANN'''(Internet Corporation for Assigned Names and Numbers)이 존재한다. 해당 기관은 IP 주소를 할당하는 것 뿐만 아니라 DNS root 서버를 관리하고, 도메인 이름을 할당하며 이와 관련된 분쟁을 해결하는 업무도 수행한다.		ISP로부터 주소 블록을 얻는 것이 주소 블록을 획득하는 한 가지 방법이지만, 유일한 방법은 아니다. 분명한 것은, ISP 자체도 주소 블록을 받을 수 있는 어떤 절차가 있어야 한다는 것이다. 이를 위해서 전세계적으로 IP 주소 공간을 관리하고 ISP 및 기타 조직에 주소 블록을 할당하는 궁극적인 권한을 가진 기관으로 '''ICANN'''(Internet Corporation for Assigned Names and Numbers)이 존재한다. 해당 기관은 IP 주소를 할당하는 것 뿐만 아니라 DNS root 서버를 관리하고, 도메인 이름을 할당하며 이와 관련된 분쟁을 해결하는 업무도 수행한다.

			==Hierarchical addressing: route aggregation==
			https://chatgpt.com/c/67f90fc8-b8a8-800b-b953-e0c95ba30bac 참고하여 정리

	==DHCP==		==DHCP==

2025년 4월 11일 (금) 19:59에 Pinkgo님의 편집

2025-04-11T19:59:44Z

← 이전 판		2025년 4월 11일 (금) 19:59 판
13번째 줄:		13번째 줄:

	==Subnet==		==Subnet==
	Figure 4는 각각의 인터페이스에 IP 주소가 ~~지정이되는~~ 예시를 보여준다. 해당 이미지에서는 세 개의 인터페이스를 가진 하나의 라우터가 일곱 개의 호스트를 연결하고 있는데, 인터페이스에 할당된 IP 주소를 유심히 살펴보면 주목할 점이 존재한다. Figure 4의 왼쪽 상단에 있는 세 개의 호스트와, 이들이 연결된 라우터의 인터페이스는 모두 223.1.1.xxx 형식의 IP 주소를 가지고 있다. 즉, 이 네 개의 인터페이스는 IP 주소의 왼쪽 24비트가 동일하다. 또한 해당 네 개의 인터페이스는 라우터 없이 하나의 네트워크로 연결되어 있다.<ref>해당 인터페이스들은 이더넷 스위치로 연결되어 있거나, 무선 액세스 포인트에 의해서 연결되었을 것이다.</ref><br>		[[파일:Interface addresses and subnets.png\|대체글=Figure 1. Interface addresses and subnets\|섬네일\|'''Figure 1. Interface addresses and subnets''' ]]
			Figure 1는 각각의 인터페이스에 IP 주소가 지정되는 예시를 보여준다. 해당 이미지에서는 세 개의 인터페이스를 가진 하나의 라우터가 일곱 개의 호스트를 연결하고 있는데, 인터페이스에 할당된 IP 주소를 유심히 살펴보면 주목할 점이 존재한다. Figure 4의 왼쪽 상단에 있는 세 개의 호스트와, 이들이 연결된 라우터의 인터페이스는 모두 223.1.1.xxx 형식의 IP 주소를 가지고 있다. 즉, 이 네 개의 인터페이스는 IP 주소의 왼쪽 24비트가 동일하다. 또한 해당 네 개의 인터페이스는 라우터 없이 하나의 네트워크로 연결되어 있다.<ref>해당 인터페이스들은 이더넷 스위치로 연결되어 있거나, 무선 액세스 포인트에 의해서 연결되었을 것이다.</ref><br>
	이렇게 '''라우터를 통하지 않고 물리적으로 통신할 수 있는 호스트들 사이의 네트워크'''를 '''subnet'''이라고 한다. 즉, 네트워크에서 라우터를 뜯어내면 존재하는, 하위 네트워크를 의미한다. 이때 각각의 subnet에는 주소가 할당되며, 해당 예시에서는 <code>223.1.1.0/24</code>에 해당한다. 이때 <code>/24</code>는 subnet mask라고 불리며, '''왼쪽부터 24비트가 subnet 주소를 정의'''한다는 것을 의미한다. 해당 subnet에 추가로 호스트를 연결하기 위해서는 해당 호스트의 IP 주소도 <code>223.1.1.0/24</code> 형식을 따라야 한다.<br>		이렇게 '''라우터를 통하지 않고 물리적으로 통신할 수 있는 호스트들 사이의 네트워크'''를 '''subnet'''이라고 한다. 즉, 네트워크에서 라우터를 뜯어내면 존재하는, 하위 네트워크를 의미한다. 이때 각각의 subnet에는 주소가 할당되며, 해당 예시에서는 <code>223.1.1.0/24</code>에 해당한다. 이때 <code>/24</code>는 subnet mask라고 불리며, '''왼쪽부터 24비트가 subnet 주소를 정의'''한다는 것을 의미한다. 해당 subnet에 추가로 호스트를 연결하기 위해서는 해당 호스트의 IP 주소도 <code>223.1.1.0/24</code> 형식을 따라야 한다.<br>
	IP에서 정의하는 subnet은 호스트가 라우터 인터페이스에 연결된 이터넷 세그먼트에만 국한되지 않는다. Figure 5에는 세 개의 라우터가 point-to-point link로 서로 연결되어있으며 각각 세 개의 인터페이스를 가진다. 이때 figure 5에 존재하는 subnet 중 <code>223.1.1.0/24</code>, <code>223.1.2.0/24</code>, <code>223.1.3.0/24</code>은 figure 4의 subnet들과 비슷하다. 하지만 이 예시에는 추가로 세 개의 subnet이 존재한다:		IP에서 정의하는 subnet은 호스트가 라우터 인터페이스에 연결된 이터넷 세그먼트에만 국한되지 않는다. Figure 5에는 세 개의 라우터가 point-to-point link로 서로 연결되어있으며 각각 세 개의 인터페이스를 가진다. 이때 figure 5에 존재하는 subnet 중 <code>223.1.1.0/24</code>, <code>223.1.2.0/24</code>, <code>223.1.3.0/24</code>은 figure 4의 subnet들과 비슷하다. 하지만 이 예시에는 추가로 세 개의 subnet이 존재한다:
19번째 줄:		20번째 줄:
	* 라우터 R2와 R3를 연결하는 subnet <code>223.1.8.0/24</code>		* 라우터 R2와 R3를 연결하는 subnet <code>223.1.8.0/24</code>
	* 라우터 R3와 R1을 연결하는 subnet <code>223.1.7.0/24</code>		* 라우터 R3와 R1을 연결하는 subnet <code>223.1.7.0/24</code>
			[[파일:Three routers interconnecting six subnets.png\|대체글=Figure 2. Three routers interconnecting six subnets\|섬네일\|217x217픽셀\|'''Figure 2. Three routers interconnecting six subnets''' ]]
	따라서 호스트와 라우터 시스템에서 subnet을 정하는 것은 어려운 일이지만, 다행히 아래와 같은 subnet을 식별하는 가이드 라인이 있다.		따라서 호스트와 라우터 시스템에서 subnet을 정하는 것은 어려운 일이지만, 다행히 아래와 같은 subnet을 식별하는 가이드 라인이 있다.
	각 인터페이스를 호스트나 라우터에서 분리(detach)시키면, 인터페이스들이 끝점이 되는 고립된 네트워크들의 집합이 형성된다. 각 고립된 네트워크는 하나의 subnet이다.		각 인터페이스를 호스트나 라우터에서 분리(detach)시키면, 인터페이스들이 끝점이 되는 고립된 네트워크들의 집합이 형성된다. 각 고립된 네트워크는 하나의 subnet이다.
	따라서 이 가이드라인을 figure 5에 적용하면 총 6개의 subnet을 얻을 수 있다.<br>		따라서 이 가이드라인을 figure 2에 적용하면 총 6개의 subnet을 얻을 수 있다.<br>

	==CIDR==		==CIDR==
29번째 줄:		31번째 줄:

	===Classful Addressing===		===Classful Addressing===
	CIDR이 도입되기 전에는 IP 주소의 '''prefix 길이가 반드시 8, 16, 24비트'''로 고정되었는데, 이를 '''Classful Addressing'''이라고 한다. 이는 figure 6와 같이 prefix의 크기를 class로 나누어 구분한다.		CIDR이 도입되기 전에는 IP 주소의 '''prefix 길이가 반드시 8, 16, 24비트'''로 고정되었는데, 이를 '''Classful Addressing'''이라고 한다. 이는 figure 3와 같이 prefix의 크기를 class로 나누어 구분한다.
	* [[파일:Classful Addressing.jpg\|~~대체글~~=Figure 6. Classful Addressing\|섬네일\|300x300픽셀\|Figure 6. Classful Addressing]]A class: 첫 옥텟<ref>맨 앞의 8비트의 10진수 표기이다.</ref>이 1~126에 해당한다.		* [[파일:Classful Addressing.jpg\|alt=Figure 3. Classful Addressing\|섬네일\|300x300픽셀\|Figure 3. Classful Addressing]]A class: 첫 옥텟<ref>맨 앞의 8비트의 10진수 표기이다.</ref>이 1~126에 해당한다.
	** 첫 옥텟에 0과 127이 포함되지 않는 이유는 첫 옥텟이 0과 127인 IP 주소는 예약이 되어있기 때문이다.<ref>0은 아직 주소가 없음을 의미하는 미지정 주소, 127은 자기 자신을 가리키는 루프백 주소이다.</ref>		** 첫 옥텟에 0과 127이 포함되지 않는 이유는 첫 옥텟이 0과 127인 IP 주소는 예약이 되어있기 때문이다.<ref>0은 아직 주소가 없음을 의미하는 미지정 주소, 127은 자기 자신을 가리키는 루프백 주소이다.</ref>
	** 첫 비트는 항상 0이며 첫 8비트를 네트워크 ID로 사용하고, 나머지 24비트를 호스트 ID로 사용한다.		** 첫 비트는 항상 0이며 첫 8비트를 네트워크 ID로 사용하고, 나머지 24비트를 호스트 ID로 사용한다.
88번째 줄:		90번째 줄:

	==DHCP==		==DHCP==
	어떤 조직이 IP 주소 블록을 하나 확보한 이후에는, 그 주소 블록 내에서 개별 호스트와 라우터 인터페이스에 IP 주소를 할당할 수 있다. 시스템 관리자는 보통 라우터에 IP 주소를 수동으로 설정하며, 이는 종종 네트워크 관리 도구를 통해 원격으로 수행된다. 호스트의 주소도 수동으로 설정될 수 있지만 때로는 자동으로 설정되어야 할 때도 있다. 그 이유는 호스트의 IP 주소는 종종 고정되어 있지 않기 때문이다. 예를 들어 figure 7과 같이 새로운 기기가 Wi-Fi 등을 통해 네트워크에 접속할 때, IP 주소를 매번 수동으로 입력하기란 정말 귀찮은 일이다. 따라서 이러한 경우, '''DHCP(Dynamic Host Configuration Protocol)'''이라고 하는 '''application layer'''의 프로토콜을 사용하여 호스트가 자동으로 IP 주소를 할당받도록 해준다. 이때 네트워크 관리자는 DHCP를 설정할 때, 특정 호스트가 매번 같은 IP 주소를 받도록 할 수도 있고, 또는 연결할 때마다 다른 임시 IP 주소를 할당하도록 설정할 수도 있다.<br>		[[파일:DHCP client and server.png\|대체글=Figure 4. DHCP client and server\|섬네일\|'''Figure 4. DHCP client and server''' ]]
			어떤 조직이 IP 주소 블록을 하나 확보한 이후에는, 그 주소 블록 내에서 개별 호스트와 라우터 인터페이스에 IP 주소를 할당할 수 있다. 시스템 관리자는 보통 라우터에 IP 주소를 수동으로 설정하며, 이는 종종 네트워크 관리 도구를 통해 원격으로 수행된다. 호스트의 주소도 수동으로 설정될 수 있지만 때로는 자동으로 설정되어야 할 때도 있다. 그 이유는 호스트의 IP 주소는 종종 고정되어 있지 않기 때문이다. 예를 들어 figure 4과 같이 새로운 기기가 Wi-Fi 등을 통해 네트워크에 접속할 때, IP 주소를 매번 수동으로 입력하기란 정말 귀찮은 일이다. 따라서 이러한 경우, '''DHCP(Dynamic Host Configuration Protocol)'''이라고 하는 '''application layer'''의 프로토콜을 사용하여 호스트가 자동으로 IP 주소를 할당받도록 해준다. 이때 네트워크 관리자는 DHCP를 설정할 때, 특정 호스트가 매번 같은 IP 주소를 받도록 할 수도 있고, 또는 연결할 때마다 다른 임시 IP 주소를 할당하도록 설정할 수도 있다.<br>
	IP 주소 할당 외에도, DHCP는 호스트가 다음과 같은 추가 정보도 함께 학습할 수 있도록 해준다:		IP 주소 할당 외에도, DHCP는 호스트가 다음과 같은 추가 정보도 함께 학습할 수 있도록 해준다:
	* subnet mask		* subnet mask
96번째 줄:		99번째 줄:

	DHCP는 클라이언트-서버(client-server) 프로토콜이며, 단순한 경우 각각의 subnet에 DHCP 서버가 하나씩 존재하여 새로운 클라이언트의 IP 주소 요청을 처리할 수 있다. 하지만 어떤 subnet에는 DHCP 서버가 없을 수 있는데, 이 때에는 DHCP 릴레이 에이전트(보통 라우터)가 존재하여, 해당 네트워크에 대한 DHCP 서버의 주소를 제공한다. figure 7에는 DHCP 서버가 <code>223.1.2.0/24</code> 서브넷에 연결되어 있고, 라우터가 <code>223.1.1.0/24</code> 및 <code>223.1.3.0/24</code> 서브넷에서 들어오는 클라이언트를 위한 릴레이 에이전트 역할을 수행하는 모습을 보여준다.		DHCP는 클라이언트-서버(client-server) 프로토콜이며, 단순한 경우 각각의 subnet에 DHCP 서버가 하나씩 존재하여 새로운 클라이언트의 IP 주소 요청을 처리할 수 있다. 하지만 어떤 subnet에는 DHCP 서버가 없을 수 있는데, 이 때에는 DHCP 릴레이 에이전트(보통 라우터)가 존재하여, 해당 네트워크에 대한 DHCP 서버의 주소를 제공한다. figure 7에는 DHCP 서버가 <code>223.1.2.0/24</code> 서브넷에 연결되어 있고, 라우터가 <code>223.1.1.0/24</code> 및 <code>223.1.3.0/24</code> 서브넷에서 들어오는 클라이언트를 위한 릴레이 에이전트 역할을 수행하는 모습을 보여준다.
			[[파일:DHCP client-server interaction.png\|대체글=Figure 5. DHCP client-server interaction\|섬네일\|408x408픽셀\|'''Figure 5. DHCP client-server interaction''' ]]
	DHCP의 동작 방식은 figure 8에 잘 나타나 있다. 새로운 호스트가 네트워크에 도착했을 때, DHCP 프로토콜은 다음의 4단계 과정을 거친다.		DHCP의 동작 방식은 figure 5에 잘 나타나 있다. 새로운 호스트가 네트워크에 도착했을 때, DHCP 프로토콜은 다음의 4단계 과정을 거친다.
	# DHCP 서버 발견 (DHCP server discovery)		# DHCP 서버 발견 (DHCP server discovery)
	#* 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)<ref>application layer에 해당하므로 message가 사용된다.</ref>를 보낸다.		#* 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)<ref>application layer에 해당하므로 message가 사용된다.</ref>를 보낸다.

Pinkgo: /* DHCP */

2025-04-11T18:25:37Z

DHCP

← 이전 판		2025년 4월 11일 (금) 18:25 판
88번째 줄:		88번째 줄:

	==DHCP==		==DHCP==
	어떤 조직이 IP 주소 블록을 하나 확보한 이후에는, 그 주소 블록 내에서 개별 호스트와 라우터 인터페이스에 IP 주소를 할당할 수 있다. 시스템 관리자는 보통 라우터에 IP 주소를 수동으로 설정하며, 이는 종종 네트워크 관리 도구를 통해 원격으로 수행된다. 호스트의 주소도 수동으로 설정될 수 있지만 때로는 자동으로 설정되어야 할 때도 있다. 그 이유는 호스트의 IP 주소는 종종 고정되어 있지 않기 때문이다. 예를 들어 figure 7과 같이 새로운 기기가 Wi-Fi 등을 통해 네트워크에 접속할 때, IP 주소를 매번 수동으로 입력하기란 정말 귀찮은 일이다. 따라서 이러한 경우, '''DHCP(Dynamic Host Configuration Protocol)'''이라고 하는 '''application layer'''의 프로토콜을 ~~사용한다~~.<br>		어떤 조직이 IP 주소 블록을 하나 확보한 이후에는, 그 주소 블록 내에서 개별 호스트와 라우터 인터페이스에 IP 주소를 할당할 수 있다. 시스템 관리자는 보통 라우터에 IP 주소를 수동으로 설정하며, 이는 종종 네트워크 관리 도구를 통해 원격으로 수행된다. 호스트의 주소도 수동으로 설정될 수 있지만 때로는 자동으로 설정되어야 할 때도 있다. 그 이유는 호스트의 IP 주소는 종종 고정되어 있지 않기 때문이다. 예를 들어 figure 7과 같이 새로운 기기가 Wi-Fi 등을 통해 네트워크에 접속할 때, IP 주소를 매번 수동으로 입력하기란 정말 귀찮은 일이다. 따라서 이러한 경우, '''DHCP(Dynamic Host Configuration Protocol)'''이라고 하는 '''application layer'''의 프로토콜을 사용하여 호스트가 자동으로 IP 주소를 할당받도록 해준다. 이때 네트워크 관리자는 DHCP를 설정할 때, 특정 호스트가 매번 같은 IP 주소를 받도록 할 수도 있고, 또는 연결할 때마다 다른 임시 IP 주소를 할당하도록 설정할 수도 있다.<br>
	DHCP는 클라이언트-서버(client-server) 프로토콜이며, 단순한 경우 각각의 subnet에 DHCP 서버가 하나씩 존재하여 새로운 클라이언트의 IP 주소 요청을 처리할 수 있다. 하지만 어떤 subnet에는 DHCP 서버가 없을 수 있는데, 이 때에는 DHCP 릴레이 에이전트(보통 라우터)가 존재하여, 해당 네트워크에 대한 DHCP 서버의 주소를 제공한다. figure 7에는 DHCP 서버가 <code>223.1.2.0/24</code> 서브넷에 연결되어 있고, 라우터가 <code>223.1.1.0/24</code> 및 <code>223.1.3.0/24</code> 서브넷에서 들어오는 클라이언트를 위한 릴레이 에이전트 역할을 수행하는 모습을 보여준다.~~<br>~~		IP 주소 할당 외에도, DHCP는 호스트가 다음과 같은 추가 정보도 함께 학습할 수 있도록 해준다:
			* subnet mask
			* 첫 번째 홉 라우터의 주소 (default gateway)
			* Local DNS 서버의 주소
			DHCP는 호스트를 네트워크에 연결하는 데 필요한 네트워크 관련 설정들을 자동화할 수 있기 때문에, 종종 plug-and-play 또는 zero-configuration, zeroconf 프로토콜이라고 불린다. 이 기능은 관리자가 일일이 수동으로 설정하지 않아도 되게 해주므로, 네트워크 관리자 입장에서 매우 매력적이다. 이러한 특징 때문에 DHCP는 가정용 인터넷, 기업 네트워크, 무선 LAN 등에서 널리 사용되는데, 이는 호스트들이 해당 환경에서 네트워크에 자주 연결되고 해재되기 때문이다.

			DHCP는 클라이언트-서버(client-server) 프로토콜이며, 단순한 경우 각각의 subnet에 DHCP 서버가 하나씩 존재하여 새로운 클라이언트의 IP 주소 요청을 처리할 수 있다. 하지만 어떤 subnet에는 DHCP 서버가 없을 수 있는데, 이 때에는 DHCP 릴레이 에이전트(보통 라우터)가 존재하여, 해당 네트워크에 대한 DHCP 서버의 주소를 제공한다. figure 7에는 DHCP 서버가 <code>223.1.2.0/24</code> 서브넷에 연결되어 있고, 라우터가 <code>223.1.1.0/24</code> 및 <code>223.1.3.0/24</code> 서브넷에서 들어오는 클라이언트를 위한 릴레이 에이전트 역할을 수행하는 모습을 보여준다.

	DHCP의 동작 방식은 figure 8에 잘 나타나 있다. 새로운 호스트가 네트워크에 도착했을 때, DHCP 프로토콜은 다음의 4단계 과정을 거친다.		DHCP의 동작 방식은 figure 8에 잘 나타나 있다. 새로운 호스트가 네트워크에 도착했을 때, DHCP 프로토콜은 다음의 4단계 과정을 거친다.
	# DHCP 서버 발견 (DHCP server discovery)		# DHCP 서버 발견 (DHCP server discovery)
	#* 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)<ref>application layer에 해당하므로 message가 사용된다.</ref>를 보낸다.		#* 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)<ref>application layer에 해당하므로 message가 사용된다.</ref>를 보낸다.
			#* 이 메시지는 UDP 포트 67번으로 전송되는 UDP 패킷 안에 담기며, 이 UDP 패킷은 IP 데이터그램에 캡슐화된다.
	#* 이때 호스트는 DHCP 서버의 주소는 당연히 모르고 있기 때문에, datagram의 헤더필드를 구성할 때, 목적지의 IP 주소는 <code>255.255.255.255</code>(브로드캐스트 주소)로, 출발지 IP 주소는 <code>0.0.0.0</code>(미지정 주소)로 구성한다.		#* 이때 호스트는 DHCP 서버의 주소는 당연히 모르고 있기 때문에, datagram의 헤더필드를 구성할 때, 목적지의 IP 주소는 <code>255.255.255.255</code>(브로드캐스트 주소)로, 출발지 IP 주소는 <code>0.0.0.0</code>(미지정 주소)로 구성한다.
	#* 해당 IP 데이터그램은 link layer로 전달되고, link layer에서 해당 프레임(frame)은 같은 subnet에 있는 모든 노드에 브로드캐스팅한다.		#* 해당 IP 데이터그램은 link layer로 전달되고, link layer에서 해당 프레임(frame)은 같은 subnet에 있는 모든 노드에 브로드캐스팅한다.