Internet Protocol
상위 문서: Network Layer
개요
IP(Internet Protocol)은 인터넷에서 패킷을 송신하기 위한 network layer의 프로토콜이다.
IPv4 Datagram Format
인터넷의 network layer의 데이터 단위는 데이터그램(datagram)이다. 데이터그램의 데이터 그램은 figure 1과 같이 구성되어있다. 이때 이 문서를 이해하기 위해서는, fragmentation/reassembly의 구현을 위한 16-bit identifier, flgs, fragment offset과 32비트 IP 주소를 나타내기 위한 헤더 필드가 존재가 존재한다는 것만 기억하면 된다.
이때 datagram의 IP 헤더필드는 20bytes이고, TCP 헤더필드는 20bytes이다. 따라서 datagram의 overhead는 40bytes + app layer overhead이다.
Fragmentation
모든 링크(link)들은 각각의 해당 link-level이 운반할 수 있는 최대 frame[1]의 크기인 MTU(Max Transfer Size)를 가지고 있다. 각각의 IP 데이터그램은 한 라우터(router)에서 다음 라우터로 이동할 때 link layer의 frame에 캡슐화되기 때문에, MTU는 IP 데이터그램의 크기에 대해 제약을 가한다. 이로 인해 발생하는 진짜 문제는 송신 호스트(host)에서 수신 호스트로 패킷이 이동할 때 거쳐가는 링크의 MTU들이 서로 다른 수 있다는 것이다. 예를 들어, 다양한 링크를 연결하는 라우터에서 한 링크에서 IP 데이터그램을 수신했을 때, 출력 링크의 MTU가 입력 링크의 MTU보다 작으면 문제가 된다. 이 경우 문제는 커다란 IP 데이터그램을 그보다 작은 크기의 MTU를 가지는 링크에 어떻게 전달할지이다.
이때 해결책은 IP 데이터그램의 페이로드를 두 개이상의 더 작은 IP 데이터그램에 나누어 담고(fragment), 각각의 쪼개진 데이터그램을 frame으로 캡슐화해서 전송하는 것이다. 이때 쪼개진 데이터그램을 fragment라고 한다. 이때 fragment들을 라우터에서 합쳐서 다시 이를 보내는 것은 네트워크 성능을 저하시킬 수 있기 때문에, 수신측 호스트에서 fragment들을 받아서 원래대로 재조립(reassemble)한다. 이때 reassemble을 수신측 호스트가 수행할 수 있도록, IP 데이터그램 헤더에는 identifier, flag, fragmentation offset 필드가 존재한다.
Figure 2는 fragmentation과 reassembly가 일어나는 간단한 상황을 보여준다. 그리고 figure 3은 해당 상황에서 어떻게 데이터그램이 쪼개지는지 보여준다. 해당 상황은 4000bytes의 크기를 가지는 데이터그램은 MTU가 1500bytes인 링크에 전송하고자 할 때이다. Figure 3의 각 데이터그램에 있는 필드들의 역할은 다음과 같다.
- length: datagram의 전체길이
- ID: 원래 데이터그램의 고유 식별자
- fragflag: 마지막 fragment이면 0, 아니면 1
- offset: 데이터그램의 데이터 부분을 기준으로, 8bytes 단위로 몇 번째인지를 의미한다.
이를 바탕으로 각각의 fragment들의 헤더필드가 어떻게 설정되는지 살펴보면 다음과 같다.
| 헤더 필드 | 값 | 이유 |
|---|---|---|
| length | 1500 | MTU 한도인 1500 바이트까지 전송 (1480 데이터 + 20 헤더) |
| ID | x | 동일한 원래 데이터그램이므로 ID는 같음 |
| fragflag | 1 | 뒤에 조각이 더 있음을 나타냄 (More Fragments = 1) |
| offset | 0 | 데이터의 시작 위치는 0바이트 → 0 / 8 = 0 |
| 헤더 필드 | 값 | 이유 |
|---|---|---|
| length | 1500 | MTU 한도인 1500 바이트까지 전송 (1480 데이터 + 20 헤더) |
| ID | x | 동일한 원래 데이터그램이므로 ID는 같음 |
| fragflag | 1 | 뒤에 조각이 더 있음을 나타냄 (More Fragments = 1) |
| offset | 185 | 데이터의 시작 위치는 1480바이트 → 1480 / 8 = 185 |
| 헤더 필드 | 값 | 이유 |
|---|---|---|
| length | 1000 | 남은 데이터는 4000 - 2960 = 1040 (1020 데이터 + 20 헤더) |
| ID | x | 동일한 원래 데이터그램이므로 ID는 같음 |
| fragflag | 0 | 마지막 조각이므로 더 이상 남은 조각 없음 (MF = 0) |
| offset | 370 | 데이터의 시작 위치는 2960바이트 → 2960 / 8 = 370 |
IPv4 Addressing
자세한 내용은 IPv4 Addressing 문서를 참조하십시오.
Network Address Translation (NAT)
IP 기능을 갖춘 모든 장치는 IP 주소를 필요로 한다. 즉, 어떤 subnet 내에서 호스트가 추가될 때마다, ISP는 해당 호스트를 위한 주소 범위를 할당해주어야 한다. 만약 subnet이 더욱 커진다면, 더욱 큰 주소 블록이 할당되어야 한다. 하지만 이미 ISP가 이미 해당 subnet 내의 현재 주소 범위에 해당하는 인접하는 주소 블록을 할당해버렸다면 어떻게 될까? 이러한 문제를 해결하기 위해서 등장한 주소 할당 방법이 NAT(Network Address Translation)이다.
Public/Private IP Address
IP 주소는 크게 두가지로 나뉜다. 하나는 public IP address(공인 IP 주소)이고, 또 다른 하나는 private IP address(사설 IP 주소)이다.
공인 IP 주소는 글로벌하게 공유되며, 전체 네트워크 상에서 유효하므로, 인터넷에 직접 연결되는 라우터와 같은 장치에 필요하다. 공인 IP 주소 얻기 위해서는 ISP로부터 구매하거나 임대하여야 한다.
사설 IP 주소는 subnet 내에서만 유효한 주소이므로, 외부 인터넷과 통신하는데 사용될 수 없다. 즉, NAT을 통해서 변환이 필요한 주소이다. 사설 IP 주소는 RFC 1918에 따라 정해진 3가지 대역만 사용 가능하며, 이는 아래 표에 나타나 있다.
| 주소 대역 | 호스트 수 | 예시 용도 |
|---|---|---|
| 10.0.0.0/8 | 약 1,600만 | 대기업, 통신사 내부 |
| 172.16.0.0/12 | 약 100만 | 기관, 기업용 |
| 192.168.0.0/16 | 약 6.5만 | 가정용, 소규모 사무실 (SOHO) |
NAT의 동작 방식
Figure 4는 NAT 기능이 활성화된 라우터의 작동 방식을 보여준다. 해당 figure의 라우터는 어떤 가정의 네트워크에 속한 인터페이스를 가지고 있으며, 해당 subnet에 속한 모든 인터페이스는 10.0.0/24라는 동일한 subnet 주소를 가지고 있다. 이때 10.0.0.0/8은 위 문단에서 설명했듯이 사설 주소 영역(realm with private addresses)에서 사용하기 위해 예약된 주소 블록이다. 사설 주소 영역이란 해당 사설 주소가 subnet 내부의 장치들 사이에서만 의미를 가지는 네트워크를 의미한다. 이때 10.0.0.0/24 주소 블록은 해당 figure 말고도 셀 수 없이 많은 subnet의 상당수에 의해 사용되고 있으며, 특정 subnet 내에서는 이 주소들을 사용하여 패킷을 주고 받을 수 있다. 하지만 사설 IP 주소들을 통해서는 외부 인터넷으로 나가는 패킷의 송수신에 사용할 수 없다. 왜냐하면 전세계적으로 같은 주소 블록을 사용하는 네트워크가 셀수 없이 많기 때문이다. 즉, NAT는 subnet 안에서만 사용되는 사설 IP 주소를 외부에서 통용되도록 번역(translate)하는 역할을 한다.
NAT 기능이 있는 라우터는 외부 네트워크에서 보기에는 라우터가 아닌 '하나의 장치'처럼 동작한다. 즉, NAT 라우터는 외부 세계에 대해 단일 IP 주소만을 사용한다. Figure 4에서는 가정용 라우터를 통해 인터넷으로 나가는 모든 트래픽의 출발지 IP 주소는 138.76.29.7이며, 인터넷에서 라우터로 들어오는 모든 트래픽의 목적지 IP 주소 역시 138.76.29.7이다. 따라서 NAT 라우터는 subnet의 내부 정보를 외부로부터 숨기고 있다고 볼 수 있다.
모든 데이터그램에서 외부 네트워크에서 NAT 라우터로 들어올 때, 목적지의 IP 주소가 동일하다면, 다음과 같은 궁금증이 생겨야 한다.
"라우터는 그 데이터그램을 어떤 호스트로 전달해야 하는지 어떻게 알까?"
그 핵심은 NAT 라우터가 NAT 테이블(NAT translation table)을 사용하며, 이 테이블 항목에 포트 번호와 IP 주소 정보를 함께 저장한다는 것이다. 예를 들어, figure 4처럼 어떤 사용자가 subnet 내의 10.0.0.1에서, IP 주소 128.119.40.186을 가진 웹 서버의 포트 80으로 HTTP 요청을 보낸다고 하자. 이때 10.0.0.1 호스트는 임의로 포트번호 3345를 출발지 포트 번호로 지정하여 데이터그램을 LAN으로 보낸다. 해당 데이터그램을 받는 NAT 라우터는 다음을 수행한다:
그리고 NAT 라우터는 다음과 같은 변환 테이블 항목을 생성한다.
(공용 IP 138.76.29.7, 포트 5001) → (내부 IP 10.0.0.1, 포트 3345)
외부의 웹 서버는 NAT 라우터에 의해 변경된 데이터그램을 받고, 응답을 보낼 때 아래와 같이 보낸다.
목적지 IP 주소: 138.76.29.7 목적지 포트 번호: 5001
해당 응답이 NAT 라우터에 도착하면 라우터는 NAT 변환 테이블을 조회하여 목적지 IP 주소를 10.0.0.1로, 목적지 포트 번호를 3345로 다시 바꾼 후 해당 데이터그램을 내부 네트워크로 전달한다.
NAT Controversies
NAT는 매우 널리 사용되고 있는 기술이지만, NAT에 대해 비판적인 시선도 존재한다.
기술적으로는 포트 번호는 원래 프로세스를 구분하는 데 사용되는 것이지, 호스트를 구분하는 데 쓰는 것이 아니라는 점이다.
구조적으로는 라우터가 원래는 데이터그램의 헤더 필드까지만 처리하여야 하지만, NAT에서는 세그먼트(segment)의 헤더 필드인 포트 번호까지 수정한다. 이는 IP의 설계 철학인 호스트 간의 직접적인 통신을 위배하는 것이다.
