IPv4

주소 공간 고갈

 이 부분의 본문은 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)를 가능하게 하며, 최종 사용자에게 최소 2⁶⁴개의 호스트 주소를 갖는 대규모 서브넷 할당을 제공한다. 그러나 IPv4는 IPv6와 직접적으로 상호 운용되지 않으므로, IPv4 전용 호스트는 IPv6 전용 호스트와 직접 통신할 수 없다. 2004년부터 시작된 6bone 실험 네트워크의 단계적 중단과 함께, 2006년부터 IPv6의 영구적이고 공식적인 배포가 시작되었다. IPv6 배포의 완료에는 상당한 시간이 걸릴 것으로 예상되므로, 호스트가 두 버전의 프로토콜을 모두 사용하여 인터넷에 참여할 수 있도록 하는 중간 단계의 IPv6 전환 메커니즘이 필요하다.

주소 표현

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

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

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

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

할당

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

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

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

특수 용도 주소

국제 인터넷 표준화 기구(IETF)와 IANA는 다양한 특수 목적을 위해 일반적인 사용으로부터 여러 예약된 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에서 공식 표준을 정의했다.

루프백

 이 부분의 본문은 Localhost입니다.

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

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

 IPv4 서브네팅 참조 문서를 참고하십시오.

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

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

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

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

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

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

주소 확인

 이 부분의 본문은 도메인 네임 시스템입니다.

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

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

번호 없는 인터페이스

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

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

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

헤더

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

버전: 4 비트:IP 패킷의 첫 번째 헤더 필드는 버전 필드이다. IPv4의 경우, 이는 항상 4와 같다.

인터넷 헤더 길이 (IHL): 4 비트:IPv4 헤더는 선택 사항인 14번째 필드(옵션)로 인해 크기가 가변적이다. IHL 필드는 IPv4 헤더의 크기를 포함하며, 헤더에 있는 32비트 워드의 수를 지정하는 4비트로 구성된다. 이 필드의 최소값은 5이며, 이는 5 × 32비트 = 160비트 = 20바이트의 길이를 나타낸다. 4비트 필드로서 최대값은 15이며, 이는 IPv4 헤더의 최대 크기가 15 × 32비트 = 480비트 = 60바이트임을 의미한다.

차등 서비스 코드 포인트 (DSCP): 6 비트:원래 서비스 유형(ToS)으로 정의되었던 이 필드는 차등화 서비스(DiffServ)를 지정한다. 실시간 데이터 스트리밍은 DSCP 필드를 활용한다. 예로는 대화형 음성 서비스에 사용되는 음성 인터넷 프로토콜(VoIP)이 있다.

명시적 혼잡 알림 (ECN): 2 비트:이 필드는 패킷을 버리지 않고 네트워크 혼잡의 엔드 투 엔드 알림을 가능하게 한다. ECN은 양쪽 끝점이 이를 지원할 때 사용할 수 있는 선택적 기능이며, 하부 네트워크에서도 지원될 때 효과적이다.

총 길이: 16 비트:이 16비트 필드는 헤더와 데이터를 포함한 전체 패킷 크기를 바이트 단위로 정의한다. 최소 크기는 20바이트(데이터 없는 헤더)이고 최대 크기는 65,535바이트이다. 모든 호스트는 최대 576바이트 크기의 데이터그램을 재조합할 수 있어야 하지만, 대부분의 현대 호스트는 훨씬 더 큰 패킷을 처리한다. 링크가 패킷 크기에 추가 제한을 둘 수 있으며, 이 경우 데이터그램은 IP 단편화되어야 한다. IPv4에서의 단편화는 송신 호스트 또는 라우터에서 수행된다. 재조합은 수신 호스트에서 수행된다.

식별: 16 비트:이 필드는 식별 필드이며 주로 단일 IP 데이터그램의 단편 그룹을 고유하게 식별하는 데 사용된다. 일부 실험적인 작업에서는 위조된 소스 주소를 가진 데이터그램을 추적하는 데 도움이 되는 패킷 추적 정보를 추가하는 것과 같은 다른 목적으로 ID 필드를 사용하는 것을 제안했지만, 현재 그러한 사용은 금지되어 있다.

플래그: 3 비트:이 필드 내에는 세 개의 플래그가 정의되어 있다.

예약됨 (R): 1 비트:예약됨. 0으로 설정되어야 한다.

단편화 방지 (DF): 1 비트:이 필드는 데이터그램의 단편화 가능 여부를 지정한다. 단편의 재조합을 수행할 자원이 없는 호스트로 패킷을 보낼 때 사용할 수 있다. 또한 호스트 IP 소프트웨어에 의해 자동으로, 또는 ping이나 Traceroute와 같은 진단 도구를 사용하여 수동으로 경로 MTU 탐색을 위해 사용될 수 있다. DF 플래그가 설정되어 있는데 패킷 라우팅을 위해 단편화가 필요한 경우, 패킷은 폐기된다.

추가 단편 (MF): 1 비트:단편화되지 않은 패킷의 경우 MF 플래그가 해제된다. 단편화된 패킷의 경우 마지막 단편을 제외한 모든 단편에 MF 플래그가 설정된다. 마지막 단편은 0이 아닌 단편 오프셋 필드를 가지므로 단편화되지 않은 패킷과 여전히 구별될 수 있다.

단편 오프셋: 13 비트:이 필드는 원래의 단편화되지 않은 IP 데이터그램의 시작 부분에 대한 특정 단편의 오프셋을 지정한다. 단편은 8바이트 단위로 지정되며, 이것이 마지막 단편을 제외한 단편의 길이가 항상 8의 배수인 이유이다.
첫 번째 단편의 단편화 오프셋 값은 항상 0이다. 필드 너비는 13비트이므로 오프셋 값의 범위는 0에서 8191((2⁰ – 1)에서 (2¹³ – 1))까지이다. 따라서 헤더 길이를 포함하여 (2¹³ – 1) × 8 = 65,528바이트(65,528 + 20 = 65,548바이트)의 최대 단편 오프셋을 허용하며, 이는 최대 IP 길이인 65,535바이트를 초과하는 패킷의 단편화를 지원한다.

타임 투 리브 (TTL): 8 비트:타임 투 리브 필드는 라우팅 루프 발생 시 네트워크 장애를 방지하기 위해 데이터그램의 수명을 제한한다. 초 단위로 지정되지만, 1초 미만의 시간 간격은 1로 올림된다. 실제로는 홉 수로 사용되며, 데이터그램이 라우터에 도착할 때마다 라우터는 TTL 필드를 1씩 감소시킨다. TTL 필드가 0이 되면 라우터는 패킷을 폐기하고 일반적으로 송신자에게 ICMP 시간 초과 메시지를 보낸다.

Traceroute 프로그램은 조정된 TTL 값을 가진 메시지를 보내고, 이러한 ICMP 시간 초과 메시지를 사용하여 소스에서 목적지까지 패킷이 통과한 라우터를 식별한다.

프로토콜: 8 비트:이 필드는 IP 데이터그램의 데이터 부분에 사용된 전송 계층 프로토콜을 정의한다. IP 프로토콜 번호 목록은 IANA(Internet Assigned Numbers Authority)에서 관리한다.

일반적인 페이로드 프로토콜은 다음과 같다.

프로토콜 번호	프로토콜 이름	약어
1	인터넷 제어 메시지 프로토콜	ICMP
2	인터넷 그룹 관리 프로토콜	IGMP
6	전송 제어 프로토콜	TCP
17	사용자 데이터그램 프로토콜	UDP
41	IPv6 캡슐화	ENCAP
89	최단 경로 우선 프로토콜	OSPF
132	스트림 제어 전송 프로토콜	SCTP

헤더 체크섬: 16 비트:IPv4 헤더 체크섬 필드는 헤더의 오류 검사에 사용된다. 패킷을 보내기 전에 체크섬은 헤더에 있는 모든 16비트 워드의 1의 보수 합에 대한 16비트 1의 보수로 계산된다. 이때 계산 중에 0으로 설정되는 헤더 체크섬 필드 자체도 포함된다. 패킷은 결과 값을 포함하는 헤더 체크섬과 함께 전송된다. 패킷이 라우터나 목적지에 도착하면 네트워크 장치는 이제 헤더 체크섬 필드를 포함하여 헤더의 체크섬 값을 재계산한다. 결과는 0이어야 하며, 다른 결과가 나오면 장치는 패킷을 폐기한다.

패킷이 라우터에 도착하면 라우터는 헤더의 TTL 필드를 감소시킨다. 결과적으로 라우터는 패킷을 다시 보내기 전에 새로운 헤더 체크섬을 계산해야 한다.

패킷의 데이터 부분에 있는 오류는 캡슐화된 프로토콜에 의해 별도로 처리된다. UDP와 TCP 모두 데이터에 적용되는 별도의 체크섬을 가지고 있다.

소스 주소: 32 비트:이 필드는 패킷 송신자의 IPv4 주소를 포함한다. 전송 중에 네트워크 주소 변환(NAT)에 의해 변경될 수 있다.

목적지 주소: 32 비트:이 필드는 패킷의 의도된 수신자의 IPv4 주소를 포함한다. 이 또한 NAT의 영향을 받을 수 있다.

목적지에 직접 도달할 수 있는 경우 패킷은 ARP의 도움을 받아 하부 링크 계층에 의해 전달된다. 그렇지 않은 경우 패킷은 라우팅이 필요하며 대신 게이트웨이 주소로 전달된다.

옵션: 0 - 320 비트, 32 비트의 배수로 패딩됨:옵션 필드는 자주 사용되지 않는다. 일부 옵션을 포함하는 패킷은 위험한 것으로 간주되어 일부 라우터에서 차단될 수 있다. IHL 필드의 값은 모든 옵션과 헤더가 32비트 워드의 정수 개수를 포함하도록 보장하는 데 필요한 패딩을 수용할 수 있을 만큼 충분한 추가 32비트 워드를 포함해야 한다. IHL이 5보다 크면(즉, 6에서 15 사이) 옵션 필드가 존재하며 반드시 고려되어야 함을 의미한다. 옵션 목록은 EOOL(End of Options List, 0x00) 옵션으로 종료될 수 있다. 이는 옵션의 끝이 헤더의 끝과 일치하지 않는 경우에만 필요하다.

대부분의 IP 옵션은 패킷이 얼마나 많은 혹은 어떤 중간 장치를 통과해야 하는지에 대한 사양을 포함하므로, IP 옵션은 인터넷 통신에 사용되지 않으며 일부 IP 옵션을 포함하는 IP 패킷은 네트워크 토폴로지나 네트워크 세부 정보를 노출할 수 있으므로 반드시 폐기되어야 한다.^: §3.13

 인터넷 프로토콜 옵션 문서에 이 부분의 추가 정보가 있습니다.

단편화

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

라우터는 패킷을 단편들로 나눈다. 각 단편의 최대 크기는 출력 MTU에서 IP 헤더 크기(최소 20바이트, 최대 60바이트)를 뺀 값이다. 라우터는 각 단편을 자체 패킷에 넣으며, 각 단편 패킷에는 다음과 같은 변경 사항이 적용된다.

• 총 길이 필드는 단편 크기가 된다.
• 추가 단편(MF) 플래그는 마지막 단편을 제외한 모든 단편에 대해 설정되며, 마지막 단편은 0으로 설정된다.
• 단편 오프셋 필드는 원래 데이터 페이로드에서의 단편 오프셋을 기준으로 설정된다. 이는 8바이트 블록 단위로 측정된다.
• 헤더 체크섬 필드가 재계산된다.

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

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

전체 데이터 크기는 유지된다: 2,480바이트 + 2,020바이트 = 4,500바이트. 오프셋은 ${\displaystyle 0}$과 ${\displaystyle {\frac {0+2{,}480}{8}}=310}$이다.

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

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

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

마지막 오프셋과 마지막 데이터 크기는 전체 데이터 크기를 계산하는 데 사용된다: ${\displaystyle 495\times 8+540=3{,}960+540=4{,}500}$.

재조합

수신자는 다음 조건 중 하나라도 참이면 패킷이 단편임을 알 수 있다.

• 추가 단편(MF) 플래그가 설정되어 있다(마지막을 제외한 모든 단편에 해당).
• 단편 오프셋 필드가 0이 아니다(첫 번째를 제외한 모든 단편에 해당).

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