IPv4

인터넷 프로토콜 버전 4(Internet Protocol version 4, IPv4)는 독립형 사양으로서 인터넷 프로토콜(IP)의 첫 번째 버전이다. 인터넷 및 기타 패킷 교환 네트워크에서의 표준 기반 인터네트워킹 방식의 핵심 프로토콜 중 하나이다. IPv4는 1982년 SATNET에서, 1983년 1월 ARPANET에서 운영을 위해 처음으로 배포된 버전이다. 후속 버전인 IPv6(Internet Protocol version 6)의 지속적인 배포에도 불구하고, 오늘날까지 대부분의 인터넷 트래픽을 라우팅하는 데 여전히 사용되고 있다.

IPv4는 4,294,967,296(232)개의 고유 주소를 제공하는 32비트 주소 공간을 사용하지만, 큰 블록들은 특수 네트워킹 목적으로 예약되어 있다. 이러한 고유 주소의 양은 전 세계 인터넷의 요구를 충족하기에 충분하지 않으며, 이로 인해 IPv6로 전환되는 과정에서 IPv4 주소 고갈이라는 중대한 문제가 발생했다.

 목적 
인터넷 프로토콜("IP")은 인터넷 프로토콜 스위트의 인터넷 계층에서 인터네트워킹을 정의하고 가능하게 하는 프로토콜이다. 이는 인터넷에 전 세계 규모의 논리적 주소 체계를 부여하여, 소스 호스트로부터 다른 네트워크에 있는 목적지 호스트에 한 홉 더 가까운 다음 라우터로 IP 데이터 패킷의 라우팅을 가능하게 한다.

IPv4는 비연결형 프로토콜이며, 전송을 보장하지 않고 적절한 순서 보장이나 중복 전송 방지를 확약하지 않는 최선 노력 전달 모델로 작동한다. 이러한 측면은 전송 제어 프로토콜(TCP)이나 QUIC 프로토콜과 같은 상위 계층 전송 프로토콜에 의해 처리될 수 있다.

 역사 
TCP/IP의 초기 버전은 TCP/IPv3를 통해 통합된 사양이었다. IPv4에 이르러 인터넷 프로토콜은 별개의 사양이 되었다.

인터넷 프로토콜 버전 4는 IETF 간행물 RFC 791(1981년 9월)에 설명되어 있으며, 1980년 1월의 이전 정의(RFC 760)를 대체했다. 1982년 3월, 미국 국방부는 모든 군용 컴퓨터 망의 표준으로 인터넷 프로토콜 스위트(TCP/IP)를 채택하기로 결정했다.

 주소 공간 고갈 

섬네일|upright=2|IPv4 주소 고갈 타임라인
1980년대 후반에 이르러, 사용 가능한 IPv4 주소 풀이 네트워크의 원래 설계 당시 예상하지 못했던 속도로 고갈되고 있다는 점이 분명해졌다. 1990년대부터 주소 고갈을 가속화한 주요 요인으로는 IP 데이터 서비스를 이용하는 노트북 컴퓨터, 개인 정보 단말기(PDA), 스마트폰 등 모바일 컴퓨팅 기기를 사용하는 인터넷 사용자 수의 급격한 증가가 포함되었다. 또한 초고속 인터넷 접속은 상시 접속 기기를 기반으로 했다. 고갈의 위협은 다음과 같은 여러 구제 기술의 도입을 촉진했다.
 소규모 ISP 할당을 위한 Classless Inter-Domain Routing(CIDR)
 전송 링크에서 주소의 필요성을 제거한 번호 없는 인터페이스
 엔드 투 엔드 원칙의 필요성을 제거한 네트워크 주소 변환(NAT)
1990년대 중반까지 NAT는 지역 및 로컬 인터넷 레지스트리의 엄격한 사용 기반 할당 정책과 함께 네트워크 접속 제공자 시스템에서 널리 사용되었다.

IANA가 관리하는 인터넷의 기본 주소 풀은 2011년 2월 3일 마지막 5개 블록이 5개의 대륙별 인터넷 레지스트리(RIR)에 할당되면서 고갈되었다. APNIC은 제한된 정책하에 할당되는 IPv6 전환 기술용으로 예약된 소량의 주소 공간을 제외하고, 2011년 4월 15일에 지역 풀이 고갈된 첫 번째 RIR이 되었다.

주소 고갈에 대한 장기적인 해결책은 1998년에 사양화된 인터넷 프로토콜의 새로운 버전인 IPv6였다. 이는 엄청나게 증가된 주소 공간을 제공할 뿐만 아니라, 인터넷 전반에 걸쳐 개선된 경로 집계(route aggregation)를 가능하게 하며, 최종 사용자에게 최소 264개의 호스트 주소를 갖는 대규모 서브넷 할당을 제공한다. 그러나 IPv4는 IPv6와 직접적으로 상호 운용되지 않으므로, IPv4 전용 호스트는 IPv6 전용 호스트와 직접 통신할 수 없다. 2004년부터 시작된 6bone 실험 네트워크의 단계적 중단과 함께, 2006년부터 IPv6의 영구적이고 공식적인 배포가 시작되었다. IPv6 배포의 완료에는 상당한 시간이 걸릴 것으로 예상되므로, 호스트가 두 버전의 프로토콜을 모두 사용하여 인터넷에 참여할 수 있도록 하는 중간 단계의 IPv6 전환 메커니즘이 필요하다.

 주소 지정 

IPv4는 32비트 주소를 사용하여 주소 공간을 (232)개의 주소로 제한한다.

IPv4는 사설망(224 + 220 + 216 ≈ 1,800만 개 주소) 및 멀티캐스트 주소(228 ≈ 2억 6,800만 개 주소)를 위해 특수 주소 블록을 예약해 두고 있다.

 주소 표현 
IPv4 주소는 32비트 정수 값을 나타내는 모든 표기법으로 표현될 수 있다. 가장 흔히 점-십진 표기법(dot-decimal notation)으로 작성되는데, 이는 주소의 4개 옥텟을 각각 십진법 숫자로(앞자리에 불필요한 0 없이) 표현하고 마침표로 구분하는 방식이다.

예를 들어, 그림의 4단위 점 IP 주소()는 32비트 십진법 숫자 2886794753을 나타내며, 이는 십육진법 형식으로 0xAC10FE01이다.

CIDR 표기법은 주소 뒤에 슬래시 문자(/)와 라우팅 접두사(서브넷 마스크)에서 연속된 1 비트의 개수를 덧붙여 주소와 라우팅 접두사를 간결한 형식으로 결합한다.

클래스 기반 네트워킹이 시행되던 시기에는 다른 주소 표현 방식도 흔히 사용되었다. 예를 들어, 루프백 주소 은 네트워크 마스크가 8비트이고 호스트 번호가 24비트인 클래스 A 네트워크에 속하므로 흔히 로 표기되었다. 점 표기법에서 주소에 4개 미만의 숫자가 지정된 경우, 마지막 값은 주소를 4개 옥텟으로 채우는 데 필요한 만큼의 바이트를 가진 정수로 취급되었다. 따라서 주소 은 과 동일하다.

 할당 
IPv4의 원래 설계에서 IP 주소는 두 부분으로 나뉘었다. 네트워크 식별자는 주소의 최상위 옥텟이었고, 호스트 식별자는 주소의 나머지 부분이었다. 후자는 나머지 필드(rest field)라고도 불렸다. 이 구조는 최대 256개의 네트워크 식별자만을 허용했는데, 이는 곧 부적절하다는 것이 밝혀졌다.

이 한계를 극복하기 위해 1981년에 최상위 주소 옥텟을 재정의하여 네트워크 클래스를 만들었으며, 이 시스템은 나중에 클래스 기반 네트워킹으로 알려지게 되었다. 개정된 시스템은 5개의 클래스를 정의했다. 클래스 A, B, C는 네트워크 식별을 위한 비트 길이가 달랐다. 주소의 나머지 부분은 이전과 마찬가지로 네트워크 내의 호스트를 식별하는 데 사용되었다. 클래스마다 필드의 크기가 달랐기 때문에 각 네트워크 클래스는 호스트 주소 지정 용량이 달랐다. 호스트 주소 지정을 위한 3개의 클래스 외에도, 멀티캐스트 주소 지정을 위한 클래스 D와 미래의 애플리케이션을 위해 예약된 클래스 E가 정의되었다.

기존의 클래스 기반 네트워크를 서브넷으로 나누는 작업은 1985년 의 발표와 함께 시작되었다. 이러한 분할은 1987년 에서 가변 길이 서브넷 마스크(VLSM)의 도입으로 더욱 유연해졌다. 1993년, 이 작업을 바탕으로 에서 Classless Inter-Domain Routing(CIDR)이 도입되었으며, 이는 (최상위 비트부터) 비트의 수를 와 같이 표현하게 되었고, 이와 대조적으로 기존의 클래스 기반 체계는 '클래스풀(classful)'이라 불리게 되었다. CIDR은 더 작거나 큰 주소 블록을 사용자에게 할당할 수 있도록 모든 주소 공간의 재분할을 허용하도록 설계되었다. CIDR에 의해 생성된 계층 구조는 IANA(Internet Assigned Numbers Authority)와 대륙별 인터넷 레지스트리(RIR)에 의해 관리된다. 각 RIR은 IP 주소 할당에 대한 정보를 제공하는 공개 검색 가능 WHOIS 데이터베이스를 유지 관리한다.

 특수 용도 주소 
국제 인터넷 표준화 기구(IETF)와 IANA는 다양한 특수 목적을 위해 일반적인 사용으로부터 여러 예약된 IP 주소를 제한해 왔다. 특히 이러한 주소는 멀티캐스트 트래픽 및 사설망에서의 제한 없는 사용을 위한 주소 공간을 제공하는 데 사용된다.

+ 특수 주소 블록주소 블록 (CIDR)주소 범위주소 개수범위설명0.0.0.0/80.0.0.0–0.255.255.255소프트웨어현재(로컬, "이") 네트워크10.0.0.0/810.0.0.0–10.255.255.255사설망사설망 내의 로컬 통신에 사용100.64.0.0/10100.64.0.0–100.127.255.255사설망캐리어급 NAT를 사용할 때 서비스 제공자와 가입자 간의 통신을 위한 공유 주소 공간127.0.0.0/8127.0.0.0–127.255.255.255호스트Localhost에 대한 루프백 주소로 사용169.254.0.0/16169.254.0.0–169.254.255.255서브넷DHCP 서버 등으로부터 IP 주소를 얻지 못했을 때, 단일 링크의 두 호스트 사이에서 사용되는 링크-로컬 주소172.16.0.0/12172.16.0.0–172.31.255.255사설망사설망 내의 로컬 통신에 사용192.0.0.0/24192.0.0.0–192.0.0.255사설망IETF 프로토콜 할당, DS-Lite (/29)192.0.2.0/24192.0.2.0–192.0.2.255문서화TEST-NET-1로 할당, 문서화 및 예제용192.88.99.0/24192.88.99.0–192.88.99.255인터넷예약됨. 이전에는 IPv6 to IPv4 릴레이용으로 사용됨 (2002::/16 주소 블록 포함).192.168.0.0/16192.168.0.0–192.168.255.255사설망사설망 내의 로컬 통신에 사용198.18.0.0/15198.18.0.0–198.19.255.255사설망두 개의 분리된 서브넷 간의 상호 네트워크 통신 벤치마크 테스트에 사용198.51.100.0/24198.51.100.0–198.51.100.255문서화TEST-NET-2로 할당, 문서화 및 예제용203.0.113.0/24203.0.113.0–203.0.113.255문서화TEST-NET-3로 할당, 문서화 및 예제용224.0.0.0/4224.0.0.0–239.255.255.255인터넷멀티캐스트용으로 사용 중 (구 클래스 D 네트워크)233.252.0.0/24233.252.0.0–233.252.0.255문서화MCAST-TEST-NET으로 할당, 문서화 및 예제용 (위의 멀티캐스트 공간의 일부임)240.0.0.0/4240.0.0.0–255.255.255.254인터넷미래 사용을 위해 예약됨 (구 클래스 E 네트워크)255.255.255.255/32255.255.255.255서브넷제한된 브로드캐스트 목적지 주소로 예약됨

 사설망 
IPv4에서 정의된 약 40억 개의 주소 중, RFC 1918에 명시된 바와 같이 3개 범위의 약 1,800만 개 주소가 사설망에서 사용하기 위해 예약되어 있다. 이 범위의 주소를 가진 패킷은 공용 인터넷에서 라우팅할 수 없으며, 모든 공용 라우터에서 무시된다. 따라서 사설 호스트는 공용 네트워크와 직접 통신할 수 없으며, 이를 위해 라우팅 게이트웨이에서 네트워크 주소 변환(NAT)이 필요하다.

+ 예약된 사설 IPv4 네트워크 범위 이름  CIDR 블록  주소 범위  주소 개수  클래스풀 설명24비트 블록  10.0.0.0/8  10.0.0.0 – 10.255.255.255   단일 클래스 A20비트 블록  172.16.0.0/12  172.16.0.0 – 172.31.255.255   클래스 B 블록 16개의 연속 범위16비트 블록  192.168.0.0/16  192.168.0.0 – 192.168.255.255   클래스 C 블록 256개의 연속 범위

두 개의 사설망(예: 두 개의 지사)은 공용 인터넷을 통해 직접 상호 운용할 수 없으므로, 공용 네트워크를 통한 전송 중에 사설 주소를 포함하는 헤더를 포함한 패킷을 프로토콜 계층으로 캡슐화하는 가상사설망(VPN) 또는 IP 터널을 통해 인터넷을 가로질러 두 네트워크를 연결해야 한다. 또한, 캡슐화된 패킷은 데이터를 보호하기 위해 공용 네트워크를 통한 전송 시 암호화될 수 있다.

 링크-로컬 주소 지정 
RFC 3927은 링크-로컬 주소 지정을 위해 특수 주소 블록 169.254.0.0/16을 정의한다. 이 주소들은 이를 사용하는 호스트에 직접 연결된 링크(예: 로컬 네트워크 세그먼트 또는 점대점 연결)에서만 유효하다. 이 주소들은 라우팅할 수 없다. 사설 주소와 마찬가지로, 이 주소들은 인터넷을 통과하는 패킷의 소스 또는 목적지가 될 수 없다. 이 주소들은 주로 호스트가 DHCP 서버나 다른 내부 구성 방법으로부터 IP 주소를 얻을 수 없을 때 주소 자동 구성(Zeroconf)을 위해 사용된다.

이 주소 블록이 예약되었을 당시에는 주소 자동 구성에 대한 표준이 없었다. 마이크로소프트는 수백만 대의 기기에 배포되어 사실상 표준이 된 Automatic Private IP Addressing(APIPA)이라는 구현체를 만들었다. 수년 후인 2005년 5월, IETF는 "Dynamic Configuration of IPv4 Link-Local Addresses"라는 제목의 RFC 3927에서 공식 표준을 정의했다.

 루프백 

클래스 A 네트워크 (비클래스 네트워크 )는 루프백을 위해 예약되어 있다. 소스 주소가 이 네트워크에 속하는 IP 패킷은 호스트 외부로 나타나서는 안 된다. 루프백 소스 또는 목적지 주소를 가진 패킷이 루프백이 아닌 인터페이스에서 수신되면 반드시 폐기해야 한다.

 첫 번째 및 마지막 서브넷 주소 

모든 서브넷에서 모두 0인 호스트 주소와 모두 1인 호스트 주소는 모두 예약되어 있다. 모두 0인 호스트 주소는 주어진 서브넷을 식별하는 데 사용된다. 모든 호스트 비트가 1로 설정된 각 서브넷의 가장 높은 주소는 서브넷의 모든 장치에 동시에 메시지를 보내기 위한 로컬 브로드캐스트 주소이다. 크기가  이상인 네트워크의 경우, 점-십진 표기법의 브로드캐스트 주소는 항상 로 끝난다.

예를 들어, 서브넷 (서브넷 마스크 )에서 식별자 은 전체 서브넷을 지칭하는 데 사용된다. 네트워크의 브로드캐스트 주소는 이다.

유형이진 형식점-십진 표기법네트워크 공간11000000.10101000.00000101.00000000192.168.5.0브로드캐스트 주소11000000.10101000.00000101.11111111192.168.5.255빨간색은 IP 주소의 호스트 부분을 나타내며, 다른 부분은 네트워크 접두사이다. 호스트 부분은 반전(논리 NOT)되지만 네트워크 접두사는 그대로 유지된다.

그러나 이것이 0 또는 255로 끝나는 모든 주소를 호스트 주소로 사용할 수 없음을 의미하지는 않는다. 예를 들어, 주소 범위 –와 동일한  서브넷 에서 브로드캐스트 주소는 이다. 255로 끝나더라도 ,  등의 주소를 호스트용으로 사용할 수 있다. 또한 은 네트워크 식별자이며 인터페이스에 할당해서는 안 된다. ,  등의 주소는 0으로 끝나더라도 할당될 수 있다.

과거에는 일부 소프트웨어가 1 대신 0을 사용하는 비표준 브로드캐스트 주소를 사용하여 네트워크 주소와 브로드캐스트 주소 간의 충돌이 발생하기도 했다.

보다 작은 네트워크에서 브로드캐스트 주소가 반드시 255로 끝나는 것은 아니다. 예를 들어, CIDR 서브넷 의 브로드캐스트 주소는 이다.

유형이진 형식점-십진 표기법네트워크 공간11001011.00000000.01110001.00010000203.0.113.16브로드캐스트 주소11001011.00000000.01110001.00011111203.0.113.31빨간색은 IP 주소의 호스트 부분을 나타내며, 다른 부분은 네트워크 접두사이다. 호스트 부분은 반전(논리 NOT)되지만 네트워크 접두사는 그대로 유지된다.

특수한 경우로,  네트워크는 단 두 개의 호스트를 위한 용량을 가진다. 이러한 네트워크는 일반적으로 점대점 연결에 사용된다. 이 네트워크들에는 네트워크 식별자나 브로드캐스트 주소가 없다.

 주소 확인 

인터넷상의 호스트는 보통 라우팅 및 네트워크 인터페이스 식별에 사용되는 IP 주소보다는 www.example.com과 같은 이름으로 알려져 있다. 도메인 이름을 사용하려면 이를 주소로 번역(확인)하거나 그 반대로 번역해야 한다. 이는 수신자의 이름을 사용하여 전화번호부에서 전화번호를 찾는 것과 유사하다.

주소와 도메인 이름 간의 번역은 도메인 네임 시스템(DNS)에 의해 수행되는데, 이는 이름공간의 하위 위임을 다른 DNS 서버에 허용하는 계층적이고 분산된 명명 시스템이다.

 번호 없는 인터페이스 
전송 링크라고도 불리는 번호 없는 점대점(PtP) 링크는 IP 네트워크 또는 서브넷 번호가 할당되어 있지 않지만 여전히 IP 주소를 갖는 링크이다. 1993년에 처음 도입되었으며, 퀄컴의 필 칸(Phil Karn)이 최초 설계자로 알려져 있다.

전송 링크의 목적은 데이터그램을 라우팅하는 것이다. 이들은 희소한 IP 주소 공간에서 IP 주소를 아끼거나, IP 할당 관리 및 인터페이스 구성을 줄이기 위해 사용된다. 이전에는 모든 링크가 점대점 링크당 2개 또는 4개의 IP 주소를 사용하는  또는  서브넷을 전용으로 할당해야 했다. 링크에 번호가 없는 경우, 정의된(보통 루프백) 인터페이스에서 빌려온 단일 IP 주소인 router-id가 사용된다. 동일한 router-id를 여러 인터페이스에서 사용할 수 있다.

번호 없는 인터페이스의 단점 중 하나는 원격 테스트 및 관리가 더 어렵다는 것이다.

 패킷 구조 
IP 패킷은 헤더 섹션과 데이터 섹션으로 구성된다. IP 패킷은 데이터 섹션 뒤에 데이터 체크섬이나 다른 푸터가 없다.
일반적으로 링크 계층은 대부분의 오류를 감지하는 CRC 푸터가 포함된 프레임에 IP 패킷을 캡슐화한다. IP에 의해 운반되는 많은 전송 계층 프로토콜들도 자체적인 오류 검사 기능을 가지고 있다.

 헤더 
IPv4 패킷 헤더는 14개의 필드로 구성되며, 그중 13개는 필수 항목이다. 14번째 필드는 선택 사항이며 적절하게 옵션(options)이라는 이름이 붙여졌다. 헤더의 필드들은 최상위 바이트가 먼저 오도록 채워지며(네트워크 바이트 순서), 도식 및 논의를 위해 최상위 비트가 먼저 오는 것으로 간주한다(MSB 0 비트 번호 지정). 최상위 비트는 0번으로 번호가 매겨지므로, 예를 들어 버전 필드는 실제 첫 번째 바이트의 상위 4개 비트에서 발견된다.

일반적인 페이로드 프로토콜은 다음과 같다.
{|class=wikitable
|-
!프로토콜 번호!!프로토콜 이름!!약어
|-
|1||인터넷 제어 메시지 프로토콜||ICMP
|-
|2||인터넷 그룹 관리 프로토콜||IGMP
|-
|6||전송 제어 프로토콜||TCP
|-
|17||사용자 데이터그램 프로토콜||UDP
|-
|41||IPv6 캡슐화||ENCAP
|-
|89||최단 경로 우선 프로토콜||OSPF
|-
|132||스트림 제어 전송 프로토콜||SCTP
|}

 단편화 및 재조합 

인터넷 프로토콜은 네트워크 간의 트래픽을 가능하게 한다. 설계상 다양한 물리적 성질을 가진 네트워크를 수용하며, 링크 계층에서 사용되는 하부 전송 기술로부터 독립적이다. 하드웨어가 다른 네트워크들은 일반적으로 전송 속도뿐만 아니라 최대 전송 단위(MTU)도 다르다. 한 네트워크가 MTU가 더 작은 네트워크로 데이터그램을 전송하고자 할 때, 데이터그램을 단편화할 수 있다. IPv4에서 이 기능은 인터넷 계층에 배치되었으며, 호스트가 이러한 문제에 노출되는 것을 제한하기 위해 IPv4 라우터에서 수행된다.

대조적으로, 차세대 인터넷 프로토콜인 IPv6는 라우터가 단편화를 수행하는 것을 허용하지 않으며, 호스트가 데이터그램을 보내기 전에 경로 MTU 탐색을 수행해야 한다.

 단편화 
라우터가 패킷을 수신하면 목적지 주소를 확인하고 사용할 출력 인터페이스와 해당 인터페이스의 MTU를 결정한다. 패킷 크기가 MTU보다 크고 패킷 헤더의 DF(Don't Fragment) 비트가 0으로 설정되어 있으면 라우터는 패킷을 단편화할 수 있다.

라우터는 패킷을 단편들로 나눈다. 각 단편의 최대 크기는 출력 MTU에서 IP 헤더 크기(최소 20바이트, 최대 60바이트)를 뺀 값이다. 라우터는 각 단편을 자체 패킷에 넣으며, 각 단편 패킷에는 다음과 같은 변경 사항이 적용된다.
 총 길이 필드는 단편 크기가 된다.
 추가 단편(MF) 플래그는 마지막 단편을 제외한 모든 단편에 대해 설정되며, 마지막 단편은 0으로 설정된다.
 단편 오프셋 필드는 원래 데이터 페이로드에서의 단편 오프셋을 기준으로 설정된다. 이는 8바이트 블록 단위로 측정된다.
 헤더 체크섬 필드가 재계산된다.

예를 들어, MTU가 1,500바이트이고 헤더 크기가 20바이트인 경우, 단편 오프셋은 의 배수(0, 185, 370, 555, 740 등)가 된다.

한 라우터에서 패킷이 단편화되고, 그 단편들이 다른 라우터에서 추가로 단편화되는 것이 가능하다. 예를 들어, 20바이트 IP 헤더를 포함하여 4,520바이트인 패킷이 MTU가 2,500바이트인 링크에서 두 개의 패킷으로 단편화된다.

단편크기(바이트)헤더 크기(바이트)데이터 크기(바이트)플래그추가 단편단편 오프셋(8바이트 블록)12,500202,4801022,040202,0200310

전체 데이터 크기는 유지된다: 2,480바이트 + 2,020바이트 = 4,500바이트. 오프셋은 과 이다.

MTU가 1,500바이트인 링크로 전달될 때, 각 단편은 다시 두 개의 단편으로 단편화된다.

단편크기(바이트)헤더 크기(바이트)데이터 크기(바이트)플래그추가 단편단편 오프셋(8바이트 블록)11,500201,4801021,020201,000118531,500201,48013104560205400495

마찬가지로 데이터 크기는 유지된다: 1,480 + 1,000 = 2,480, 그리고 1,480 + 540 = 2,020.

또한 이 경우, MF 비트는 1이 포함된 채로 도착한 모든 단편에 대해 1로 유지되며, 도착하는 마지막 단편에 대해서는 평소와 같이 작동한다. 즉, MF 비트는 마지막 단편에서만 0으로 설정된다. 그리고 물론 식별(Identification) 필드는 모든 재단편화된 단편에서 동일한 값을 계속 가진다. 이러한 방식으로 단편이 다시 단편화되더라도 수신자는 처음에 모두 동일한 패킷에서 시작되었음을 알 수 있다.

마지막 오프셋과 마지막 데이터 크기는 전체 데이터 크기를 계산하는 데 사용된다: .

 재조합 
수신자는 다음 조건 중 하나라도 참이면 패킷이 단편임을 알 수 있다.
 추가 단편(MF) 플래그가 설정되어 있다(마지막을 제외한 모든 단편에 해당).
 단편 오프셋 필드가 0이 아니다(첫 번째를 제외한 모든 단편에 해당).

수신자는 소스 및 목적지 주소, 프로토콜 ID, 식별 필드를 사용하여 일치하는 단편들을 식별한다. 수신자는 단편 오프셋과 추가 단편 플래그를 모두 사용하여 동일한 ID를 가진 단편들의 데이터를 재조합한다. 수신자가 추가 단편 플래그가 0으로 설정된 마지막 단편을 받으면, 마지막 단편의 오프셋에 8을 곱하고 마지막 단편의 데이터 크기를 더하여 원래 데이터 페이로드의 크기를 계산할 수 있다. 주어진 예에서 이 계산은 바이트였다. 수신자가 모든 단편을 가지면 오프셋에 따라 올바른 순서로 재조합하여 원래의 데이터그램을 형성할 수 있다.

 보조 프로토콜 
IP 주소는 네트워킹 하드웨어와 영구적으로 연결되어 있지 않으며, 실제로 현대의 운영체제에서 네트워크 인터페이스는 여러 개의 IP 주소를 가질 수 있다. 링크상의 목적지 호스트로 IP 패킷을 적절하게 전달하기 위해, 호스트와 라우터는 네트워크 인터페이스의 하드웨어 주소와 IP 주소 간의 연관을 맺기 위한 추가 메커니즘이 필요하다. 주소 결정 프로토콜(ARP)은 IPv4를 위해 이러한 IP 주소 대 하드웨어 주소 번역을 수행한다. 또한 반대 방향의 상관관계가 필요한 경우도 많다. 예를 들어 관리자에 의해 주소가 미리 구성되지 않은 경우, IP 호스트가 부팅되거나 네트워크에 연결될 때 자신의 IP 주소를 결정해야 한다. 이러한 역상관을 위한 프로토콜에는 동적 호스트 구성 프로토콜(DHCP), 부트스트랩 프로토콜(BOOTP) 및 드물게 사용되는 리버스 ARP가 포함된다.

 같이 보기 
 IPv4 주소 할당량에 따른 나라 목록
 IPv4 주소 고갈
 IPv6

 각주 

 내용주

 외부 링크 

대한민국
 KISA: Korea Internet & Security Agency, 한국인터넷진흥원
아시아 지역
 APNIC: Asia Pacific Network Information Center
북미 지역
 ARIN: American Registry for Internet Numbers
중남미 지역
 LACNIC: Latin American and Caribbean Internet Addresses Registry
유럽 지역
 RIPE: Réseaux IP Européens


분류:인터넷 표준
분류:인터넷 프로토콜
분류:네트워크 계층 프로토콜
분류:인터넷 계층 프로토콜