IPv4
IPv4 는 데이터 한 덩이를 출발지에서 목적지까지 보내는 규칙을 적어 둔 문서입니다. 주소를 32비트로 정하고, 그 주소를 실어 나르는 헤더의 생김새를 정합니다. 보낸 것이 도착했는지는 확인하지 않습니다. 그런 일은 이 문서가 맡는 범위 밖입니다.
쉽고 빠른 이해
무슨 일을 하는 물건인가 — 데이터 한 덩이 앞에 보내는 쪽과 받는 쪽 주소를 붙여 목적지까지 넘기는 규칙입니다. 주소는 32비트짜리 값이고, 사설 대역인 192.168.0.0 부터 192.168.255.255 까지가 그런 값입니다.
왜 이렇게 하나 — 서로 다른 망을 이어 붙여 놓은 곳에서는, 어느 망에서나 똑같이 읽히는 주소와 겉포장이 있어야 한 덩이를 끝까지 나를 수 있습니다. 그 최소한만 여기서 정하고 나머지는 위에 얹히는 프로토콜에 넘깁니다.
어떻게 도나
- 보내는 쪽이 데이터 앞에 헤더를 붙입니다 — 출발지 주소, 목적지 주소, 전체 길이, 얼마나 오래 살 수 있나.
- 지나는 지점마다 목적지 주소를 보고 다음 쪽으로 넘깁니다. 지나갈 망이 작은 덩이만 받으면 쪼갰다가 받는 쪽에서 다시 이어 붙입니다.
- 헤더를 처리하는 지점마다 수명 값을 줄이고, 0 이 되면 그 덩이를 버립니다.
대가 — 도착했는지 알려주지 않습니다. 잃어버려도 다시 보내지 않고, 순서도 맞춰 주지 않으며, 보내는 속도도 조절해 주지 않습니다. 헤더 체크섬으로 헤더가 깨졌는지만 봅니다.
상세
IPv4(Internet Protocol version 4)는 인터넷 프로토콜의 네 번째 판입니다. 그 판을 정하는 정본 문서가 RFC 791 입니다. 헤더 맨 앞의 Version 필드가 헤더 형식을 가리키고, RFC 791 은 자신이 기술하는 것이 버전 4 라고 적습니다.
이 프로토콜의 범위는 좁게 못 박혀 있습니다. RFC 791 §1.2 Scope 는 서로 이어진 망 시스템 위에서 비트 묶음 하나, 곧 인터넷 데이터그램 하나를 출발지에서 목적지로 전달하는 데 필요한 기능만 제공하도록 범위가 한정된다고 적습니다. 종단 간 데이터 신뢰성을 높이거나, 흐름 제어를 하거나, 순서를 맞추는 장치는 없습니다. 그것들은 호스트 대 호스트 프로토콜이 흔히 갖는 서비스라고 같은 절이 적습니다. 대신 아래에 깔린 망이 제공하는 서비스를 끌어다 여러 종류와 품질의 서비스를 낼 수는 있습니다.
기본 기능은 둘입니다. RFC 791 §1.4 Operation 이 주소 지정과 단편화를 그 둘로 꼽습니다.
| 기본 기능 | 무엇을 하나 |
|---|---|
| 주소 지정 | 인터넷 모듈이 헤더에 실린 주소를 보고 데이터그램을 목적지 쪽으로 내보냅니다. 전송할 경로를 고르는 일을 라우팅이라고 부릅니다 |
| 단편화 | 작은 패킷만 다루는 망을 지나야 할 때, 인터넷 모듈이 헤더의 필드를 써서 데이터그램을 쪼개고 다시 이어 붙입니다 |
주소는 네 옥텟, 곧 32비트 고정 길이입니다. RFC 791 은 이것을 인터넷 주소라고 부릅니다. 오늘 흔히 IP 주소라고 부르는 그것입니다. 주소는 네트워크 번호로 시작하고 그 뒤에 로컬 주소가 붙습니다. RFC 791 은 이 로컬 주소를 "rest" 필드라고 부릅니다. 원문은 주소 형식을 세 클래스로 나눕니다. 셋 다 같은 32비트를 네트워크 번호와 로컬 주소로 가르지만, 앞머리에 오는 비트 값과 가르는 자리가 서로 다릅니다.
클래스 a — 최상위 비트가 0 입니다.
packet-beta 0: "0" 1-7: "네트워크 번호 7비트" 8-31: "로컬 주소 24비트"
클래스 b — 최상위 두 비트가 1-0 입니다.
packet-beta 0-1: "1-0" 2-15: "네트워크 번호 14비트" 16-31: "로컬 주소 16비트"
클래스 c — 최상위 세 비트가 1-1-0 입니다.
packet-beta 0-2: "1-1-0" 3-23: "네트워크 번호 21비트" 24-31: "로컬 주소 8비트"
이 클래스 구분은 뒤에 나온 문서가 버렸습니다. 그 자리는 아래 「출처 문서」가 받습니다.
출처 문서
정본과 대체 관계
| 문서 | 판과 상태 | 이 표준에 무엇을 하나 |
|---|---|---|
| RFC 791 | STD 5 · Internet Standard · 1981년 9월 · J. Postel | 프로토콜 본체. RFC 760 을 폐기했습니다 |
| RFC 1122 | — | §3 Internet Layer 에서 호스트가 지켜야 할 요구를 적습니다 |
| RFC 6864 | — | Identification 필드 요구를 갱신합니다. RFC 791 · RFC 1122 · RFC 2003 을 갱신 대상으로 적습니다 |
| RFC 2474 | — | Type of Service 옥텟의 기존 정의를 DS(Differentiated Services) 필드로 대체합니다 |
| RFC 3168 | — | IP 헤더에 두 비트짜리 ECN(Explicit Congestion Notification) 필드를 두고 코드포인트 넷을 정합니다 |
| RFC 4632 | BCP 122 · Best Current Practice · 2006년 8월 | 클래스 A/B/C 네트워크 주소 할당 체계를 버리고 클래스 없는 프리픽스로 갑니다. RFC 1519 를 폐기했습니다 |
판과 상태 칸이 빈 넷은 이 항목이 인용한 대목에 그 표기가 없는 문서입니다. 값은 각 문서의 정보 페이지가 갖습니다.
RFC 791 의 정보 페이지는 이 문서를 갱신한 것으로 RFC 1349 · RFC 2474 · RFC 6864 를 꼽습니다. RFC 791 §2.3 의 클래스 구분을 인용하면 RFC 4632 가 버린 체계를 드는 것입니다. RFC 4632 §3 은 커뮤니티가 만든 해법이 그 할당 체계를 버리고 "클래스 없는" 계층적 주소 블록을 쓰는 것이었다고 적고, 그 블록을 프리픽스라고 부릅니다. §3.1 은 이 변경을 32비트 주소 안에서 어느 비트가 사이트에 딸린 네트워크 번호이고 어느 비트가 사이트 안의 개별 종단 시스템을 매기는지를 명시적으로 만드는 일이라고 설명합니다.
요구 강도
낱말을 그대로 옮깁니다. 원문이 대문자로 쓴 MUST 와 소문자로 쓴 must · may 를 구분해 적었습니다.
| 요구 | 어느 문서 어느 절 | 원문 낱말 |
|---|---|---|
| 호스트 소프트웨어의 인터넷 레이어는 IP(Internet Protocol) 와 ICMP(Internet Control Message Protocol) 를 둘 다 구현한다 | RFC 1122 §3.1 | MUST implement |
| 나가는 데이터그램의 다음 홉 게이트웨이나 호스트를 고른다 | RFC 1122 §3.1 | 기본 기능 (1) |
| 들어온 데이터그램을 재조립한다 | RFC 1122 §3.1 | 기본 기능 (2) |
| 나가는 데이터그램을 일부러 단편화한다 | RFC 1122 §3.1 | may also |
| 진단 기능과 오류 기능을 제공한다 | RFC 1122 §3.1 | must |
| 옵션은 호스트와 게이트웨이의 모든 IP 모듈이 구현한다 | RFC 791 §3.1 | must be implemented |
| Time to Live 가 0 이면 데이터그램을 파기한다 | RFC 791 §3.1 | must be destroyed |
| Flags 의 비트 0 은 0 이어야 한다 | RFC 791 §3.1 | must be zero |
옵션 자체는 데이터그램에 들어갈 수도 안 들어갈 수도 있습니다. 들어가는 것은 선택이고, 구현해 두는 것은 선택이 아닙니다.
명세와 실무가 갈린 자리
Identification 필드가 그 자리입니다. RFC 6864 는 이 필드가 지금까지의 명세대로라면 출발지 주소, 목적지 주소, 프로토콜의 세 값이 같은 모든 데이터그램에 대해 최대 수명 안에서 유일해야 한다고 정리합니다. 이 유일성 요구를 강제하면 흔한 데이터그램 크기에서 모든 연결이 6.4Mbps 로 묶인다고 적습니다. 개별 연결이 이 속도를 넘는 일이 흔하므로, 기존 시스템들이 현행 명세를 어기고 있는 것이 분명하다는 것이 RFC 6864 의 진단입니다. 그래서 이 문서는 필드 값이 실제로 단편화가 일어났을 때만 정의되도록 명세를 고쳤습니다. 현행 관행에 더 가깝게 맞추고, IPv6 에도 더 가깝게 맞추려는 것이라고 적습니다.
예시
RFC 791 의 최소 데이터그램
RFC 791 부록 A 가 데이터를 나르는 최소 인터넷 데이터그램의 예로 든 값입니다.
packet-beta 0-3: "Ver = 4" 4-7: "IHL = 5" 8-15: "Type of Service" 16-31: "Total Length = 21" 32-47: "Identification = 111" 48-50: "Flg = 0" 51-63: "Fragment Offset = 0" 64-71: "Time = 123" 72-79: "Protocol = 1" 80-95: "header checksum" 96-127: "source address" 128-159: "destination address" 160-167: "data"
RFC 791 은 이 그림을 인터넷 프로토콜 버전 4 의 데이터그램이라고 적습니다. 인터넷 헤더는 32비트 낱말 다섯 개로 이루어지고, 데이터그램 전체 길이는 21옥텟입니다. IHL(Internet Header Length) 이 5 라는 값과 Total Length 가 21 이라는 값이 그 둘을 각각 말합니다. 그래서 마지막 줄만 32비트가 아니라 8비트, 곧 한 옥텟짜리 data 자리입니다. Flg 가 0 이고 Fragment Offset 이 0 입니다. RFC 791 은 이 데이터그램이 조각이 아니라 완전한 데이터그램이라고 못 박습니다. Time 은 123 이고 Protocol 은 1 입니다.
RFC 1918 의 사설 대역
IANA(Internet Assigned Numbers Authority)가 사설 인터넷용으로 예약해 둔 세 블록입니다.
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
RFC 1918 §3 은 첫 블록을 "24비트 블록", 둘째를 "20비트 블록", 셋째를 "16비트 블록" 이라고 부릅니다. 괄호 안의 표기가 프리픽스 길이입니다.
RFC 5737 의 문서용 대역
주소 예를 적을 자리에 놓으라고 따로 내준 대역도 있습니다.
192.0.2.0/24 TEST-NET-1
198.51.100.0/24 TEST-NET-2
203.0.113.0/24 TEST-NET-3
RFC 5737 §3 은 이 세 블록이 문서에서 쓰라고 제공된 것이라고 적습니다. 오른쪽이 각 블록에 붙은 이름입니다.
형태
RFC 791 §3.1 Internet Header Format 이 헤더 필드의 배치를 정합니다. 눈금 하나가 비트 하나입니다.
packet-beta 0-3: "Version" 4-7: "IHL" 8-15: "Type of Service" 16-31: "Total Length" 32-47: "Identification" 48-50: "Flags" 51-63: "Fragment Offset" 64-71: "Time to Live" 72-79: "Protocol" 80-95: "Header Checksum" 96-127: "Source Address" 128-159: "Destination Address" 160-183: "Options" 184-191: "Padding"
앞의 다섯 낱말이 올바른 헤더의 최솟값입니다. IHL 의 최솟값이 5 라는 것이 그 뜻입니다. 여섯째 낱말은 Options 와 Padding 이 나눠 씁니다. 옵션은 데이터그램에 들어갈 수도 안 들어갈 수도 있습니다. 각 필드가 몇 비트를 쓰고 무엇을 정하는지는 아래 표가 받습니다.
| 필드 | 길이 | 무엇을 정하나 |
|---|---|---|
| Version | 4비트 | 인터넷 헤더의 형식. RFC 791 이 기술하는 것이 버전 4 입니다 |
| IHL | 4비트 | 인터넷 헤더의 길이를 32비트 낱말 수로 셉니다. 그래서 데이터가 시작하는 자리를 가리킵니다. 올바른 헤더의 최솟값은 5 입니다 |
| Type of Service | 8비트 | RFC 791 이 이 옥텟을 둔 자리입니다. RFC 2474 가 정의를 대체했습니다 |
| Total Length | 16비트 | 인터넷 헤더와 데이터를 합친 데이터그램 길이를 옥텟으로 잽니다. 이 필드가 허용하는 길이는 65,535옥텟까지입니다 |
| Identification | 16비트 | 보낸 쪽이 매기는 식별 값. 데이터그램의 조각들을 다시 맞추는 데 씁니다 |
| Flags | 3비트 | 비트 0 은 예약이고 0 이어야 합니다. 비트 1 은 DF(Don't Fragment) 로 0 이면 단편화해도 되고 1 이면 하지 말라는 뜻입니다. 비트 2 는 MF(More Fragments) 로 0 이면 마지막 조각, 1 이면 뒤에 조각이 더 있다는 뜻입니다 |
| Fragment Offset | 13비트 | 이 조각이 데이터그램의 어디에 들어가는지. 단위는 8옥텟, 곧 64비트입니다. 첫 조각의 오프셋은 0 입니다 |
| Time to Live | 8비트 | 데이터그램이 인터넷 시스템에 머물 수 있는 최대 시간. 0 이면 파기해야 합니다 |
| Protocol | 8비트 | 데이터 부분에 실린 다음 레벨 프로토콜. 값의 목록은 "Assigned Numbers" 가 갖습니다 |
| Header Checksum | 16비트 | 헤더에만 걸리는 체크섬. Time to Live 처럼 바뀌는 필드가 있어서, 인터넷 헤더를 처리하는 지점마다 다시 계산하고 검증합니다 |
| Source Address | 32비트 | 출발지 주소 |
| Destination Address | 32비트 | 목적지 주소 |
| Options | 가변 | 데이터그램에 들어갈 수도 안 들어갈 수도 있습니다. 구현은 모든 IP 모듈이 해야 합니다 |
오늘의 헤더가 명세와 갈리는 자리
Type of Service 옥텟 자리가 그렇습니다. RFC 2474 §3 은 DS 필드라는 대체 헤더 필드를 정의하고, 그것이 기존 IPv4 의 Type of Service 옥텟 정의를 대신하도록 의도한 것이라고 적습니다.
---
config:
packet:
bitsPerRow: 8
---
packet-beta
0-5: "DSCP"
6-7: "CU"
앞 6비트가 코드포인트인 DSCP(differentiated services codepoint) 입니다. 패킷이 각 노드에서 어떤 취급을 받을지 고르는 값입니다. 뒤 2비트는 CU(currently unused) 로, RFC 2474 는 이 자리를 예약해 두고 그 정의와 해석을 자기 범위 밖으로 넘겼습니다.
RFC 3168 §5 는 IP 헤더에 두 비트짜리 ECN 필드를 둡니다. 두 비트로 코드포인트 넷이 나옵니다. 표의 ECT 는 ECN-Capable Transport 를 줄인 것입니다.
| 값 | 이름 | 누가 정하나 |
|---|---|---|
| 00 | Not-ECT | ECN 을 쓰지 않는 패킷 |
| 01 | ECT(1) | 데이터를 보내는 쪽이 전송 프로토콜의 양 끝이 ECN 을 다룰 수 있다고 알립니다 |
| 10 | ECT(0) | 위와 같습니다 |
| 11 | CE | 라우터가 종단 노드에 혼잡을 알리려고 설정합니다 |
큐가 가득 찬 상태에서 패킷이 도착하면 라우터는 그 패킷을 버립니다. ECN 이 없을 때와 같다고 RFC 3168 이 적습니다.
보장과 가정
RFC 791 §1.4 Operation 은 이 프로토콜이 신뢰성 있는 통신 설비를 제공하지 않는다고 적습니다. 없는 것을 하나씩 셉니다. 종단 간에도 홉 단위에도 확인 응답이 없습니다. 데이터에 대한 오류 제어가 없습니다. 헤더 체크섬 하나뿐입니다. 재전송이 없습니다. 흐름 제어가 없습니다. 감지된 오류는 ICMP 로 보고될 수 있습니다. RFC 791 은 이 대목을 "may be reported" 로 적습니다.
| 보장 | 그 보장이 서 있는 가정 | 가정이 깨지면 |
|---|---|---|
| 헤더가 깨졌는지는 알아냅니다 | 헤더 체크섬을 헤더 처리 지점마다 다시 계산하고 검증합니다 | 깨진 헤더를 알아채지 못한 채 넘깁니다. 오류 제어가 헤더 체크섬 하나뿐이므로 대신 잡아 줄 장치가 없습니다 |
| 데이터그램을 다음 게이트웨이나 목적지 호스트까지 나릅니다 | 하위 로컬 망 프로토콜이 실제로 그 일을 해 줍니다 | 데이터그램이 도착하지 않습니다. 확인 응답도 재전송도 없으므로 IPv4 가 그것을 다시 채워 넣지 않습니다 |
| 오래된 데이터그램이 무한정 떠돌지 않습니다 | 헤더를 처리하는 모든 지점이 Time to Live 를 줄입니다 | 수명 상한이 서지 않습니다 |
RFC 791 §1.3 Interfaces 는 이 관계를 위아래로 적습니다. 호스트 대 호스트 프로토콜이 이 프로토콜을 불러 쓰고, 이 프로토콜은 로컬 망 프로토콜을 불러 데이터그램을 다음 게이트웨이나 목적지 호스트까지 나르게 합니다.
block-beta columns 1 H["호스트 대 호스트 프로토콜"] I["IPv4"] L["로컬 망 프로토콜"]
위가 부르는 쪽이고 아래가 불려 나가는 쪽입니다.
TTL 이 떠받치는 것
RFC 791 §3.2 는 이 필드를 보낸 쪽이 정한다고 적습니다. 데이터그램이 인터넷 시스템에 머물 수 있는 최대 시간입니다. 그 시간을 넘겨 머물면 데이터그램은 파기되어야 합니다. 인터넷 헤더를 처리하는 지점마다 이 필드를 줄여서 처리에 쓴 시간을 반영합니다. 실제로 얼마나 걸렸는지에 대한 정보가 없더라도 최소 1 은 줄입니다. 단위는 초입니다. 값 1 이 1초를 뜻하므로 최대 수명은 255초, 곧 4.25분입니다. 데이터그램을 1초 안에 처리한 모듈도 최소 1 을 줄이므로, RFC 791 은 TTL(Time to Live) 을 데이터그램이 존재할 수 있는 시간의 상한으로만 생각해야 한다고 적습니다.
이 필드가 노리는 것은 둘입니다. 배달할 수 없는 데이터그램을 버리게 하는 것, 그리고 데이터그램의 최대 수명에 선을 긋는 것입니다. 그 선 위에 다른 프로토콜이 얹힙니다. 상위의 신뢰성 있는 연결 프로토콜 가운데는 일정 시간이 지나면 오래된 중복 데이터그램이 더는 도착하지 않는다는 가정에 기대는 것들이 있습니다. RFC 791 은 TTL 이 그런 프로토콜에게 자기 가정이 지켜진다는 확신을 주는 방법이라고 적습니다.
관련 항목
이것이 속하는 상위 분류
이 표준이 정하는 부품
헤더 · 데이터그램 · 주소 지정 · 단편화와 재조립 · 옥텟 · TTL · 체크섬 · 라우팅 · 경로표 · 사설 대역 · 프리픽스 · 옵션 · DSCP · ECN
이 표준을 정의·개정하거나 예시 대역을 지정한 문서
RFC 791 · RFC 760 · RFC 1122 · RFC 1349 · RFC 2474 · RFC 3168 · RFC 6864 · RFC 2003 · RFC 4632 · RFC 1519 · RFC 1918 · RFC 5737
이것에 관여하는 역할·참여자
위에 얹히는 프로토콜
TCP(Transmission Control Protocol, 전송 제어 프로토콜) · UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜) · ICMP
이 표준이 명시적으로 갖추지 않는 기능
이 주소를 쪼개거나 아껴 쓰는 기법
서브넷 · NAT(Network Address Translation, 네트워크 주소 변환) · 프리픽스
다른 이름으로 불리거나 자리를 잇는 이웃
다른 이름: Internet Protocol version 4 · IP version 4