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 Unit)를 가지고 있다. 각각의 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 기능이 활성화된 라우터의 작동 방식을 보여준다. 해당 라우터는 어떤 subnet에 속한 인터페이스를 가지고 있으며, 해당 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의 설계 철학인 호스트 간의 직접적인 통신을 위배하는 것이다.
IPv6
IPv6는 IPv4의 32비트 IP 주소가 고갈될 위험이 있다는 이유로 개발되었다.
IPv6 datagram format
Figure 5는 IPv6 데이터그램의 포맷을 보여준다. IPv6 데이터그램에서 변경된 점은 다음과 같다.
- IP 주소 확장: IPv6는 IP 주소 크기를 32비트에서 128비트로 확장하였다. 이를 통해서 사실상 IP 주소가 부족할 가능성은 사라졌다.
- Fixed 40 bytes header: IPv6는 IP헤더파일의 크기를 40바이트로 지정하였다. 이때 해당 길이는 고정되어있으며, 가변적인 길이를 가지는 IPv4 헤더필드에 비해 더욱 빠른 처리를 가능하게 한다.
- Flow labeling: Pv6 헤더에는 20비트의 Flow Label 필드가 있으며, 이는 "특정 트래픽 흐름(flow)"을 식별하기 위해 사용된다.
IPv6 데이터그램에는 다음과 같은 필드들이 정의되어있다.
- Version: 4비트 필드로 IP 버전 번호를 나타낸다. IPv6에서는 이 필드에 6이 들어간다.[6]
- Flow label: 20비트 필드로 데이터그램 흐름을 식별하는 데 사용된다.
- Payload length: 16비트 부호 없는 정수로, 고정 길이 40바이트 헤더 다음에 오는 IPv6 데이터그램의 바이트 수를 나타낸다.
- Next header: 데이터그램 내용이 전달될 프로토콜을 식별한다</ref>예를 들면, TCP 또는 UDP이다.</ref>. 이 필드는 IPv4의 프로토콜 필드와 동일한 값을 사용한다.
- Hop limit: 각 라우터가 이 필드를 1씩 감소시키며, 0이 되면 데이터그램은 폐기된다.
- Source and Destination Addresses: 송신측과 수신측의 IP 주소이다.
이때 IPv6 데이터그램에서는 fragmentation/reassembly 기능을 구현하기 위한 필드가 존재하지 않는다. 즉, IPv6에서는 중간 라우터에서의 fragment/reassembly를 허용하지 않는다. 이 작업은 오직 송신자와 수신자 내에서만 가능하다. 만약 라우터가 수신한 IPv6 데이터그램이 송신 링크보다 크면, 해당 라우터는 데이터그램을 폐기하고 송신측에게 "Packet Too Big" ICMP 오류 메시지를 보내며, 송신측은 더 작은 IP 데이터그램을 재전송한다. 이를 통해서 시간 소모가 큰 해당 작업들을 라우터가 아닌 end-system에 맡겨서 네트워크 내의 IP 전달 속도를 향상시킬 수 있다.
Transitioning from IPv4 to IPv6
IPv4에서 IPv6를 기반으로 하는 네트워크로 전환하기 위해서는 기술적인 문제가 존재한다. 이는 새로운 IPv6 시스템은 IPv4 데이터그램을 처리할 수 있으나, 그 반대는 불가능하다는 것이다. 이를 해결하기 위한 해결책은 몇가지가 존재한다. 첫번째 하나는 flag day를 선언하여 특정 날짜에 모든 인터넷 장비를 끄고 IPv4에서 IPv6로 업그레이드 하는 것이다. 현재는 수십억개가 넘는 네트워크 장치가 존재가 존재하기 때문에, 이들을 대상으로 하는 flag day는 사실상 불가능하다.
따라서 현실적으로 가장 널리 채택된 IPv4에서 IPv6로의 전환 방식은 터널링(tunneling)이다. Figure 6는 터널링에 어떻게 작동하는 지 잘 보여준다. Figure 6에서 두 IPv6 노드(B와 E)가 IPv6 데이터그램으로 통신하려 하는데, 그 사이에 IPv4 라우터들이 있다면 이 IPv4 라우터들로 구성된 경로를 tunnel이라고 부른다. 이 경우, 송신 측 IPv6 노드(B)는 전체 IPv6 데이터그램을 IPv4 데이터그램의 페이로드에 담는다. 이 IPv4 데이터그램은 수신 측 IPv6 노드(E)의 IP 주소를 목적지 주소로 가지고, 터널의 첫 노드(C)로 전송된다. 터널 내의 IPv4 라우터들은 이 IPv4 데이터그램을 일반적인 IPv4 데이터그램처럼 라우팅하며, 그 내부에 IPv6 데이터그램이 들어 있다는 사실은 인지하지 못한다. 터널의 수신 측에 있는 IPv6 노드(E)는 이 IPv4 데이터그램을 수신하면, 프로토콜 번호 필드가 41이라는 것을 확인하고[7], 그 안에 있는 IPv6 데이터그램을 추출하여 일반적인 방식으로 처리한다.
IPv6: adoption
IPv6 도입은 초기에는 더디게 진행되었지만, 점점 가속화되고 있다. 미국 NIST는 미국 정부의 2차 도메인 중 1/3 이상이 IPv6를 지원한다고 보고[8]>했으며, 구글은 자사 서비스를 이용하는 클라이언트 중 약 8%가 IPv6를 통해 접속한다고 보고했다.[9] IPv6의 경험에서 우리가 배울 수 있는 중요한 교훈은, 네트워크 계층 프로토콜을 변경하는 것은 매우 어렵다는 점이다. 1990년대 초 이래, 새로운 네트워크 계층 프로토콜들이 인터넷의 다음 주요 혁신으로 기대를 모았지만, 대부분은 제한적인 확산에 그쳤다. 반면, 인터넷은 애플리케이션 계층에서 새로운 프로토콜이 빠르게 도입되는 모습을 보여왔다. 웹, 인스턴트 메시징, 스트리밍 미디어, 온라인 게임, 소셜 미디어 등이 대표적 예이다.
각주
- ↑ Link layer에서의 데이터 단위이다.
- ↑ NAT 라우터는 새로 생성한 포트 번호가 NAT 변환 테이블에 이미 존재하지 않는 것 중에서 선택한다.
- ↑ 포트 번호는 16비트이므로, 이론적으로 하나의 공용 IP 주소로 60,000개 이상의 연결을 동시에 처리할 수 있다.
- ↑ 네트워크에서 특정 트래픽에 대해 우선순위를 부여하거나, 성능 보장을 해주는 기술이다.
- ↑ 즉, 실시간 비디오, 음성통화/고속, 우선 순위 트래픽/프리미엄 서비스 사용자 트래픽들을 하나의 flow로 묶고, 해당 흐름을 flow label로 식별한다.
- ↑ 4가 들어간다고 IPv4 데이터그램이 되지는 않는다.
- ↑ 이는 IPv4 페이로드가 IPv6 데이터그램임을 나타낸다.
- ↑ [NIST IPv6 2015]
- ↑ [Google IPv6 2015]
