IPv4 Addressing: 두 판 사이의 차이

youngwiki
 
(같은 사용자의 중간 판 12개는 보이지 않습니다)
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==
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''' ]]
이렇게 '''라우터를 통하지 않고 물리적으로 통신할 수 있는 호스트들 사이의 네트워크'''를 '''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>
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>
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이 존재한다:
* 라우터 R1과 R2를 연결하는 subnet <code>223.1.9.0/24</code>
* 라우터 R1과 R2를 연결하는 subnet <code>223.1.9.0/24</code>
* 라우터 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로 사용한다.
** 네트워크 ID의 개수는 126개이며, 호스트 ID의 개수는 약 1600만 개이다.
** 네트워크 ID의 개수는 126개이며, 호스트 ID의 개수는 약 1600만 개이다.
47번째 줄: 49번째 줄:


Classful Addressing의 가장 큰 문제는 낭비되는 IP 주소가 많다는 것이다. 예를 들어 class C는 최대 2<sup>8</sup> − 2 = 254 호스트밖에 수용하지 못하는데, 이는 대부분의 조직에 대해 너무 적은 수치이다. 또한 class B는 최대 65,534 호스트를 수용할 수 있었지만, 이는 너무 크다. 결과적으로는 2000명의 호스트를 가진 조직도 class B 주소를 할당받아야 하며, 나머지 63,000개 이상의 주소는 버려지므로 심각한 IP 주소 낭비이다.
Classful Addressing의 가장 큰 문제는 낭비되는 IP 주소가 많다는 것이다. 예를 들어 class C는 최대 2<sup>8</sup> − 2 = 254 호스트밖에 수용하지 못하는데, 이는 대부분의 조직에 대해 너무 적은 수치이다. 또한 class B는 최대 65,534 호스트를 수용할 수 있었지만, 이는 너무 크다. 결과적으로는 2000명의 호스트를 가진 조직도 class B 주소를 할당받아야 하며, 나머지 63,000개 이상의 주소는 버려지므로 심각한 IP 주소 낭비이다.
===IP Subnetting===
'''IP Subnetting'''이란 큰 IP 주소 블록을 subnet들로 나누는 작업이다. 이는 네트워크를 계층적으로 활용하여 트래픽을 분리할 수 있다는 점에서 유용하다. 이에 대해 더 자세히 설명하기 위해서는 '''subnet mask'''에 대해 알아보아야 한다. Subnet mask란 IP 주소에서 어디까지가 네트워크 부분이고, 어디부터가 호스트 부분인지를 알려주는 정보이다. 예를 들어, <code>192.168.0.0/24</code>와 같은 IP 주소에서 <code>/24</code>는 앞 24비트가 네트워크 부분, 나머지 8비트가 호스트 부분이라는 것을 의미한다. 이때 subnet mask에서 비트가 1이면 네트워크 정보, 0이면 호스트 정보를 의미한다. 예를 들어 <code>192.168.0.2/24</code>는 다음과 같이 subnet mask로 작성된다:
Subnet Mask: 11111111.11111111.11111111.00000000
10진수 표기: 255.255.255.0
이때, IP 주소와 subnet mask의 AND 연산을 하면 네트워크 주소를 얻을 수 있다.<br>
IP subnetting의 동작 방식을 이해하기 위해서, <code>192.168.0.0/24</code>라는 C class에 속하는 IP 주소 블록을 가정해보자. 이때 해당 네트워크에 추가로 5개의 subnet을 만들고 싶다면 <code>2<sup>2</sup><5<2<sup>2</sup></code>이므로 network ID에 추가로 3개의 비트를 할당하면 되며, 각각의 subnet은 <code>2<sup>5</sup>-2=32</code>개의 호스트를 사용할 수 있다.
이 경우, 각각의 subnet에 대한 네트워크 주소는 다음과 같다.
Subnet mask: 11111111.11111111.11111111.11100000
//네트워크 ID와 호스트 ID를 '/' 문자로 구분한다.
1번째 subnet 주소: 11000000.10101000.00000000.000/00000
2번째 subnet 주소: 11000000.10101000.00000000.001/00000
3번째 subnet 주소: 11000000.10101000.00000000.010/00000
4번째 subnet 주소: 11000000.10101000.00000000.011/00000
5번째 subnet 주소: 11000000.10101000.00000000.101/00000
이때 유의해야 할 점은, subnet을 더 많이 할당하기 위해서 네트워크 ID에 더 많은 비트를 할당할 수록, 사용가능한 호스트의 수는 줄어든다는 것이다.<br>
또한, <code>192.168.0.0/24</code>와 같은 호스트를 트리 구조와 같이 계층적으로 subnetting을 할 수도 있다:
//네트워크 ID와 호스트 ID를 '/' 문자로 구분한다.
subnet 0의 네트워크 주소:    11000000.10101000.00000000./00000000 → /24
subnet 1의 네트워크 주소:    11000000.10101000.00000000.0/0000000 → /25
subnet 2의 네트워크 주소:    11000000.10101000.00000000.1/0000000 → /25
subnet 2-1의 네트워크 주소:  11000000.10101000.00000000.10/000000 → /26
subnet 2-2의 네트워크 주소:  11000000.10101000.00000000.11/000000 → /26
subnet 2-2-1의 네트워크 주소: 11000000.10101000.00000000.110/00000 → /27
subnet 2-2-2의 네트워크 주소: 11000000.10101000.00000000.111/00000 → /27
위 예시에서, subnet 0는 원래의 네트워크에 해당하며 네트워크 ID에 추가로 비트를 할당하여 subnet 1과 subnet 2로 구분된다. 또한 subnet 2도 네트워크 ID에 추가로 비트를 할당하여 subnet 2-1과 subnet 2-2로 구분된다. 마지막으로 또한 subnet 2-2도 네트워크 ID에 추가로 비트를 할당하여 subnet 2-2-1과 subnet 2-2-2로 구분된다.


==Obtaining a Block of Addresses==
==Obtaining a Block of Addresses==
60번째 줄: 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==
<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>
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 client and server.png|alt=Figure 6. DHCP client and server|섬네일|'''Figure 6. DHCP client and server''' ]]
어떤 조직이 IP 주소 블록을 하나 확보한 이후에는, 그 주소 블록 내에서 개별 호스트와 라우터 인터페이스에 IP 주소를 할당할 수 있다. 시스템 관리자는 보통 라우터에 IP 주소를 수동으로 설정하며, 이는 종종 네트워크 관리 도구를 통해 원격으로 수행된다. 호스트의 주소도 수동으로 설정될 수 있지만 때로는 자동으로 설정되어야 할 때도 있다. 그 이유는 호스트의 IP 주소는 종종 고정되어 있지 않기 때문이다. 예를 들어 figure 6와 같이 새로운 기기가  Wi-Fi 등을 통해 네트워크에 접속할 때, IP 주소를 매번 수동으로 입력하기란 정말 귀찮은 일이다. 따라서 이러한 경우, '''DHCP(Dynamic Host Configuration Protocol)'''이라고 하는 '''application layer'''의 프로토콜을 사용하여 호스트가 자동으로 IP 주소를 할당받도록 해준다. 이때 네트워크 관리자는 DHCP를 설정할 때, 특정 호스트가 매번 같은 IP 주소를 받도록 할 수도 있고, 또는 연결할 때마다 다른 임시 IP 주소를 할당하도록 설정할 수도 있다.<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 client-server interaction.png|alt=Figure 7. DHCP client-server interaction|섬네일|408x408픽셀|'''Figure 7. DHCP client-server interaction''' ]]
DHCP의 동작 방식은 figure 7에 잘 나타나 있다. 새로운 호스트가 네트워크에 도착했을 때, DHCP 프로토콜은 다음의 4단계 과정을 거친다.
# DHCP 서버 발견 (DHCP server discovery)
#* 새로 도착한 호스트는 우선 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>(미지정 주소)로 구성'''한다.
#* 해당 IP 데이터그램은 link layer로 전달되고, link layer에서 해당 프레임(frame)은 같은 subnet에 있는 모든 노드에 브로드캐스팅한다.
# DHCP 서버 응답 (DHCP offer)
#* DHCP Discover 메시지를 받은 DHCP 서버는 클라이언트에게 DHCP Offer 메시지로 응답한다.
#* 이 '''메시지도 브로드캐스트로 보내지며, 목적지 IP 주소는 다시 <code>255.255.255.255</code>'''이다.
#* 하나 이상의 DHCP 서버가 한 subnet 내에 존재하는 경우, 클라이언트는 여러 offer 중에서 선택할 수 있다.
# DHCP 요청 (DHCP request)
#* 클라이언트는 받은 offer 중에서 하나를 선택하고, 그 선택된 '''서버에게 DHCP Request 메시지'''를 보낸다.
# '''DHCP 승인 (DHCP ACK)'''
#* 서버는 클라이언트의 요청에 대해 DHCP ACK 메시지로 응답하여, 클라이언트가 요청한 IP 주소를 확인해준다.


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

2025년 5월 11일 (일) 08:04 기준 최신판

상위 문서: Internet Protocol

개요

호스트와 물리적 네트워크 링크(physical network link) 간의 접점을 인터페이스(interface)라고 한다. 예를 들어 호스트는 보통 Wi-Fi나 이더넷(Ethernet) 포트을 통해서만 네트워크와 연결될 수 있으므로, Wi-Fi나 이더넷이 호스트의 인터페이스이다. 또한 라우터(router)는 여러개의 링크(네트워크)와 연결되어 있으므로 해당 링크의 개수만큼 인터페이스를 가진다. 이때 각 호스트와 라우터는 IP 데이터그램을 송수신할 수 있기 때문에 IP(Internet Protocol)는 각 호스트와 라우터의 인터페이스마다 고유한 IP 주소를 요구한다. 즉, IP 주소는 호스트나 라우터 자체가 아닌 그 안에 있는 개별 인터페이스에 할당된다. 이는 라우터와 같이 여러 인터페이스를 가지고 있는 장치가 있을 수 있기 때문이다.[1]
각 IP 주소는 32비트(4바이트) 길이이며, 따라서 총 232개, 약 40억 개의 IP 주소가 존재할 수 있다. 이 주소들은 .으로 구분된 10진수 표기로 쓰인다. 즉, 주소의 각 바이트를 10진수로 쓰고, 각 바이트를 마침표(.)로 구분한다. 예를 들어 IP 주소 193.32.216.9는 다음과 같다:

  • 193은 처음 8비트를 10진수로 나타낸 것,
  • 32는 두 번째 8비트,
  • 216은 세 번째 8비트,
  • 9는 마지막 8비트에 해당한다.

따라서 193.32.216.9는 2진수로 표현하면 다음과 같다:

11000001 00100000 11011000 00001001

인터넷에 연결된 모든 호스트와 라우터의 각 인터페이스는 전세계에서 유일한 IP 주소를 가져야 한다.[2]

Subnet

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비트가 동일하다. 또한 해당 네 개의 인터페이스는 라우터 없이 하나의 네트워크로 연결되어 있다.[3]
이렇게 라우터를 통하지 않고 물리적으로 통신할 수 있는 호스트들 사이의 네트워크subnet이라고 한다. 즉, 네트워크에서 라우터를 뜯어내면 존재하는, 하위 네트워크를 의미한다. 이때 각각의 subnet에는 주소가 할당되며, 해당 예시에서는 223.1.1.0/24에 해당한다. 이때 /24는 subnet mask라고 불리며, 왼쪽부터 24비트가 subnet 주소를 정의한다는 것을 의미한다. 해당 subnet에 추가로 호스트를 연결하기 위해서는 해당 호스트의 IP 주소도 223.1.1.0/24 형식을 따라야 한다.
IP에서 정의하는 subnet은 호스트가 라우터 인터페이스에 연결된 이터넷 세그먼트에만 국한되지 않는다. Figure 5에는 세 개의 라우터가 point-to-point link로 서로 연결되어있으며 각각 세 개의 인터페이스를 가진다. 이때 figure 5에 존재하는 subnet 중 223.1.1.0/24, 223.1.2.0/24, 223.1.3.0/24은 figure 4의 subnet들과 비슷하다. 하지만 이 예시에는 추가로 세 개의 subnet이 존재한다:

  • 라우터 R1과 R2를 연결하는 subnet 223.1.9.0/24
  • 라우터 R2와 R3를 연결하는 subnet 223.1.8.0/24
  • 라우터 R3와 R1을 연결하는 subnet 223.1.7.0/24
Figure 2. Three routers interconnecting six subnets
Figure 2. Three routers interconnecting six subnets

따라서 호스트와 라우터 시스템에서 subnet을 정하는 것은 어려운 일이지만, 다행히 아래와 같은 subnet을 식별하는 가이드 라인이 있다.

각 인터페이스를 호스트나 라우터에서 분리(detach)시키면, 인터페이스들이 끝점이 되는 고립된 네트워크들의 집합이 형성된다. 각 고립된 네트워크는 하나의 subnet이다.

따라서 이 가이드라인을 figure 2에 적용하면 총 6개의 subnet을 얻을 수 있다.

CIDR

CIDR(Classless InterDomain Routing)은 subnet 주소 지정 개념을 일반화한 인터넷의 주소 할당 전략이다. Subnet 주소 지정과 같이, 32비트 IP 주소는 두 부분으로 나뉘며, 주소 형식은 a.b.c.d/x이다. 이때 x는 주소 앞부분의 비트 수를 의미한다.
a.b.c.d/x에서 x개의 최상위 비트는 주소의 네트워크 부분이며, prefix라고 불린다. 이때 어떤 조직(enterprise)에 복수의 라우터들이 존재한다고 하더라도, 같은 조직내에 있는 인터페이스들은 동일한 prefix를 공유한다.
조직 외부의 라우터들은 오직 prefix(최상위 x 비트)만 보고 라우팅을 수행한다. 이는 라우팅의 forwarding table 크기를 크게 줄여준다. 나머지 32-x 비트는 조직 내부의 인터페이스들을 구분하는데 사용된다. 조직 내부의 라우터들은 이 하위 비트들을 기반으로 라우팅 결정을 내린다. 예를 들어, a.b.c.d/21과 같은 IP 주소는 조직의 네트워크 prefix가 21 비트라는 뜻이다. 그리고 남은 11비트는 해당 조직 내의 개별 호스트들의 인터페이스들을 구분하는데 사용된다. 또한 이 11비트 중 일부를 다시 subnetting[4]을 하는데 사용할 수 있다. 예를 들어, a.b.c.d/24와 같은 IP 주소는 추가로 8개의 subnet의 IP 주소를 지정할 수 있다.

Classful Addressing

CIDR이 도입되기 전에는 IP 주소의 prefix 길이가 반드시 8, 16, 24비트로 고정되었는데, 이를 Classful Addressing이라고 한다. 이는 figure 3와 같이 prefix의 크기를 class로 나누어 구분한다.

  • Figure 3. Classful Addressing
    Figure 3. Classful Addressing
    A class: 첫 옥텟[5]이 1~126에 해당한다.
    • 첫 옥텟에 0과 127이 포함되지 않는 이유는 첫 옥텟이 0과 127인 IP 주소는 예약이 되어있기 때문이다.[6]
    • 첫 비트는 항상 0이며 첫 8비트를 네트워크 ID로 사용하고, 나머지 24비트를 호스트 ID로 사용한다.
    • 네트워크 ID의 개수는 126개이며, 호스트 ID의 개수는 약 1600만 개이다.
    • A 클래스의 주소 범위는 1.0.0.0~126.255.255.255이다.
  • B class: 첫 옥텟이 128~191에 해당한다.
    • 첫 두비트는 항상 10이며 첫 16비트를 네트워크 ID로 사용하고, 나머지 16비트를 호스트 ID로 사용한다.
    • 네트워크 ID의 개수는 16,328개이며, 호스트 ID의 개수는 약 65534개이다.
    • B 클래스의 주소 범위는 128.0.0.0~191.255.255.255이다.
  • C class: 첫 옥텟이 192~223에 해당한다.
    • 첫 세비트는 항상 110이며 첫 24비트를 네트워크 ID로 사용하고, 나머지 8비트를 호스트 ID로 사용한다.
    • 네트워크 ID의 개수는 209만 7150개이며, 호스트 ID의 개수는 254개이다.
    • B 클래스의 주소 범위는 192.0.0.0~223.255.255.255이다.

위에서 class C의 호스트 ID의 개수는 8비트를 쓰고 있음에도 256개가 아닌 254개이다. 즉, 2개의 IP 주소가 특수한 용도로 사용되어 호스트에 할당 불가하다. 그 중 하나는 '네트워크 주소(network address)로 subnet 자체를 나타내는 주소이다. 즉, subnet 전체를 의미하므로 개별 장치에 할당할 수 없다. 네트워크 주소는 IP 주소에서 호스트 ID 부분을 전부 0으로 만든 값에 해당한다.
또다른 하나는 브로드캐스트 주소(broadcast address)로, subnet 내의 모든 호스트에게 메시지를 전송할 때 사용된다. 즉, 특정 장치가 아닌 전체 호스테에게 전송할 때 사용하므로 개별 장치에 할당할 수 없다. 브로드캐스트 주소는 IP 주소에서 호스트 ID 부분을 전부 1으로 만든 값에 해당한다.

Classful Addressing의 가장 큰 문제는 낭비되는 IP 주소가 많다는 것이다. 예를 들어 class C는 최대 28 − 2 = 254 호스트밖에 수용하지 못하는데, 이는 대부분의 조직에 대해 너무 적은 수치이다. 또한 class B는 최대 65,534 호스트를 수용할 수 있었지만, 이는 너무 크다. 결과적으로는 2000명의 호스트를 가진 조직도 class B 주소를 할당받아야 하며, 나머지 63,000개 이상의 주소는 버려지므로 심각한 IP 주소 낭비이다.

IP Subnetting

IP Subnetting이란 큰 IP 주소 블록을 subnet들로 나누는 작업이다. 이는 네트워크를 계층적으로 활용하여 트래픽을 분리할 수 있다는 점에서 유용하다. 이에 대해 더 자세히 설명하기 위해서는 subnet mask에 대해 알아보아야 한다. Subnet mask란 IP 주소에서 어디까지가 네트워크 부분이고, 어디부터가 호스트 부분인지를 알려주는 정보이다. 예를 들어, 192.168.0.0/24와 같은 IP 주소에서 /24는 앞 24비트가 네트워크 부분, 나머지 8비트가 호스트 부분이라는 것을 의미한다. 이때 subnet mask에서 비트가 1이면 네트워크 정보, 0이면 호스트 정보를 의미한다. 예를 들어 192.168.0.2/24는 다음과 같이 subnet mask로 작성된다:

Subnet Mask: 11111111.11111111.11111111.00000000 
10진수 표기: 255.255.255.0

이때, IP 주소와 subnet mask의 AND 연산을 하면 네트워크 주소를 얻을 수 있다.
IP subnetting의 동작 방식을 이해하기 위해서, 192.168.0.0/24라는 C class에 속하는 IP 주소 블록을 가정해보자. 이때 해당 네트워크에 추가로 5개의 subnet을 만들고 싶다면 22<5<22이므로 network ID에 추가로 3개의 비트를 할당하면 되며, 각각의 subnet은 25-2=32개의 호스트를 사용할 수 있다. 이 경우, 각각의 subnet에 대한 네트워크 주소는 다음과 같다.

Subnet mask: 11111111.11111111.11111111.11100000 
//네트워크 ID와 호스트 ID를 '/' 문자로 구분한다.
1번째 subnet 주소: 11000000.10101000.00000000.000/00000
2번째 subnet 주소: 11000000.10101000.00000000.001/00000
3번째 subnet 주소: 11000000.10101000.00000000.010/00000
4번째 subnet 주소: 11000000.10101000.00000000.011/00000
5번째 subnet 주소: 11000000.10101000.00000000.101/00000

이때 유의해야 할 점은, subnet을 더 많이 할당하기 위해서 네트워크 ID에 더 많은 비트를 할당할 수록, 사용가능한 호스트의 수는 줄어든다는 것이다.
또한, 192.168.0.0/24와 같은 호스트를 트리 구조와 같이 계층적으로 subnetting을 할 수도 있다:

//네트워크 ID와 호스트 ID를 '/' 문자로 구분한다.
subnet 0의 네트워크 주소:     11000000.10101000.00000000./00000000 → /24
subnet 1의 네트워크 주소:     11000000.10101000.00000000.0/0000000 → /25
subnet 2의 네트워크 주소:     11000000.10101000.00000000.1/0000000 → /25
subnet 2-1의 네트워크 주소:   11000000.10101000.00000000.10/000000 → /26
subnet 2-2의 네트워크 주소:   11000000.10101000.00000000.11/000000 → /26
subnet 2-2-1의 네트워크 주소: 11000000.10101000.00000000.110/00000 → /27
subnet 2-2-2의 네트워크 주소: 11000000.10101000.00000000.111/00000 → /27

위 예시에서, subnet 0는 원래의 네트워크에 해당하며 네트워크 ID에 추가로 비트를 할당하여 subnet 1과 subnet 2로 구분된다. 또한 subnet 2도 네트워크 ID에 추가로 비트를 할당하여 subnet 2-1과 subnet 2-2로 구분된다. 마지막으로 또한 subnet 2-2도 네트워크 ID에 추가로 비트를 할당하여 subnet 2-2-1과 subnet 2-2-2로 구분된다.

Obtaining a Block of Addresses

어떤 조직의 Subnet 내에서 사용할 IP 주소 블록을 얻기 위해서 네트워크 관리자는 자신의 ISP에 연락할 수 있으며, ISP는 이미 자신에게 할당된 더 큰 주소 블록으로부터 주소를 제공할 수 있다.
예를 들어 ISP가 200.23.16.0/20 주소 블록을 할당받았다고 하자. 이 ISP는 자신의 주소 블록을 서로 인접하고 크기가 같은 8개의 주소 블록으로 나눈 다음, 해당 ISP가 지원하는 최대 8개의 조직 각각에 하나씩 주소 블록을 제공할 수 있다. 아래는 ISP의 주소 블록과 각각의 조직에 할당된 주소 블록이며, 이해를 돕기 위해 네트워크 ID와 호스트 ID를 '/'를 통해 구분하였다:

ISP 블록:           200.23.16.0/20      11001000 00010111 000100/00 00000000
조직 0:             200.23.16.0/23      11001000 00010111 000100/00 00000000
조직 1:             200.23.18.0/23      11001000 00010111 000100/10 00000000
조직 2:             200.23.20.0/23      11001000 00010111 000101/00 00000000
...                ...                 ...
조직 7:             200.23.30.0/23      11001000 00010111 000111/10 00000000

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

Hierarchical addressing: route aggregation

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

DHCP

Figure 6. DHCP client and server
Figure 6. DHCP client and server

어떤 조직이 IP 주소 블록을 하나 확보한 이후에는, 그 주소 블록 내에서 개별 호스트와 라우터 인터페이스에 IP 주소를 할당할 수 있다. 시스템 관리자는 보통 라우터에 IP 주소를 수동으로 설정하며, 이는 종종 네트워크 관리 도구를 통해 원격으로 수행된다. 호스트의 주소도 수동으로 설정될 수 있지만 때로는 자동으로 설정되어야 할 때도 있다. 그 이유는 호스트의 IP 주소는 종종 고정되어 있지 않기 때문이다. 예를 들어 figure 6와 같이 새로운 기기가 Wi-Fi 등을 통해 네트워크에 접속할 때, IP 주소를 매번 수동으로 입력하기란 정말 귀찮은 일이다. 따라서 이러한 경우, DHCP(Dynamic Host Configuration Protocol)이라고 하는 application layer의 프로토콜을 사용하여 호스트가 자동으로 IP 주소를 할당받도록 해준다. 이때 네트워크 관리자는 DHCP를 설정할 때, 특정 호스트가 매번 같은 IP 주소를 받도록 할 수도 있고, 또는 연결할 때마다 다른 임시 IP 주소를 할당하도록 설정할 수도 있다.
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 서버가 223.1.2.0/24 서브넷에 연결되어 있고, 라우터가 223.1.1.0/24223.1.3.0/24 서브넷에서 들어오는 클라이언트를 위한 릴레이 에이전트 역할을 수행하는 모습을 보여준다.

Figure 7. DHCP client-server interaction
Figure 7. DHCP client-server interaction

DHCP의 동작 방식은 figure 7에 잘 나타나 있다. 새로운 호스트가 네트워크에 도착했을 때, DHCP 프로토콜은 다음의 4단계 과정을 거친다.

  1. DHCP 서버 발견 (DHCP server discovery)
    • 새로 도착한 호스트는 우선 DHCP 서버를 찾는 작업을 해야 하므로 호스트는 DHCP discover 메시지(message)[7]를 보낸다.
    • 이 메시지는 UDP 포트 67번으로 전송되는 UDP 패킷 안에 담기며, 이 UDP 패킷은 IP 데이터그램에 캡슐화된다.
    • 이때 호스트는 DHCP 서버의 주소는 당연히 모르고 있기 때문에, datagram의 헤더필드를 구성할 때, 목적지의 IP 주소는 255.255.255.255(브로드캐스트 주소)로, 출발지 IP 주소는 0.0.0.0(미지정 주소)로 구성한다.
    • 해당 IP 데이터그램은 link layer로 전달되고, link layer에서 해당 프레임(frame)은 같은 subnet에 있는 모든 노드에 브로드캐스팅한다.
  2. DHCP 서버 응답 (DHCP offer)
    • DHCP Discover 메시지를 받은 DHCP 서버는 클라이언트에게 DHCP Offer 메시지로 응답한다.
    • 메시지도 브로드캐스트로 보내지며, 목적지 IP 주소는 다시 255.255.255.255이다.
    • 하나 이상의 DHCP 서버가 한 subnet 내에 존재하는 경우, 클라이언트는 여러 offer 중에서 선택할 수 있다.
  3. DHCP 요청 (DHCP request)
    • 클라이언트는 받은 offer 중에서 하나를 선택하고, 그 선택된 서버에게 DHCP Request 메시지를 보낸다.
  4. DHCP 승인 (DHCP ACK)
    • 서버는 클라이언트의 요청에 대해 DHCP ACK 메시지로 응답하여, 클라이언트가 요청한 IP 주소를 확인해준다.

각주

  1. 어떤 라우터는 192.168.1.1, 10.0.0.1, 172.16.0.1 같은 여러 주소를 가질 수 있다.
  2. 단, NAT 뒤에 있는 인터페이스는 예외이다.
  3. 해당 인터페이스들은 이더넷 스위치로 연결되어 있거나, 무선 액세스 포인트에 의해서 연결되었을 것이다.
  4. Subnet을 또 다른 subnet으로 나누는 것이다.
  5. 맨 앞의 8비트의 10진수 표기이다.
  6. 0은 아직 주소가 없음을 의미하는 미지정 주소, 127은 자기 자신을 가리키는 루프백 주소이다.
  7. application layer에 해당하므로 message가 사용된다.