internet protocol (ip) header format & fragmentation

INTERNET PROTOCOL (IP)Header Format & Fragmentation

2008.10

Contents

Introductions– Motivation– Scope– Operation

Function Description– Addressing– Fragmentation

Internet Header Format– Header fields

Examples– Minimal datagram– 2-way fragmentation– Datagram containing options

Appendices– IPv6 header– Fragment and reassemble example procedure

Reference

2

Introduction

Motivation– Packet Switching (PS) computer communication network

들을 서로 연결하는 system 에서 사용하기 위해 설계– IP 는 data block 을 송신자 (source) 로부터 수신자

(destination) 까지 전달해 줌 IP 가 전달하는 data block 을 ‘ datagram’ 이라 부름 송신자와 수신자는 고정된 길이의 주소 (IP address) 로 식별

– 필요에 따라 fragmentation & reassembly 기능도 제공 Scope

– 서로 연결된 network 들을 통해서 송신자로부터 수신자에게 datagram 을 전달하는데 필요한 기능만을 제공

– Host-to-host protocol 에서 보통 제공하는 기능은 제공하지 않음

Reliability, flow control, sequencing, etc.

– 다양한 type 과 quality 의 service 를 제공하기 위해 IP 는 하위 network 의 기능을 활용할 수 있음

3

Introduction

Operation– IP 의 두 가지 기본 기능은 addressing 과 fragmentation– Internet module 들은 datagram 을 다음 목적지로 전송하기 위해

internet header 에 들어있는 address 를 참조 전송을 위한 경로 선택을 ‘ routing’ 이라 함

– Internet module 들은 “ small packet” network 을 통해 datagram 을 전송할 때 fragmentation 을 하기 위해 internet header 에 들어있는 관련 field 들을 사용

– Operation 의 주체들은 address 를 해석하고 , datagram 을 fragmenting and assembling 하기 위한 공통의 규칙을 가짐

통신에 관여하는 각 host 들의 internet module Network 들을 연결하는 각 gateway 들의 internet module 각 internet module 들 , 특히 gateway 의 module 은 routing 을

결정하기 위한 기능을 가짐– IP 는 각 datagram 을 서로 연관성 없는 독립된 개체로 취급

Connection 이나 logical circuit 의 개념이 없음– Header checksum error 는 IP module 내에 구현 된 ICMP 를

통해 상대에게 알려질 수 있음

4

Function Description

Addressing– Name, address, route 의 구별

Name: 찾아야 할 것 Address: 어디에 있는가 Route: 어떻게 갈 것인가 IP 는 이들 중 주로 address 과 관련이 있음

– Address mapping Name 과 address 를 mapping 하는 것은 상위 protocol 의 역할 Internet module 은 internet address 를 local net address 와

mapping Local net address 를 route 와 mapping 시키는 것은 하위 procedure

의 역할– Address

Address 의 길이는 4 octet 으로 고정 Network number + local address (rest fields) 의 형식

– Address format (class) Class A: 최상위 bit 은 0, 다음 7 bit 이 network, 나머지 24 bit 이

local Class B: 최상위 2 bit 은 10, 다음 14 bit 이 network, 나머지 16 bit

이 local Class C: 최상위 3 bit 은 110, 다음 21 bit 이 network, 나머지 8 bit

이 local

5


Fragmentation– 각 local network 이 허용하는 packet 크기에 따라 datagram 을

작게 나누어야 하는 경우가 발생 Datagram 이 처음 출발한 local network 보다 더 작은 크기의 packet

만을 허용하는 network 을 통과해야 하는 경우– “don’t fragment” 로 표시하여 해당 datagram 은 어떠한

경우에도 fragment 되지 않도록 할 수도 있음 Fragment 되지 않고는 destination 에 도착할 수 없는 경우 해당

datagram 을 폐기– Fragmentation and Reassembly 기능은 datagram 을 몇

조각으로든지 나누고 합칠 수 있어야 함 Fragment 를 수신하는 쪽에서는 서로 다른 datagram 들이 섞이지

않도록 identification field 를 확인 해야 함• 이 field 의 값은 같은 source-destination 사이에서는 unique 해야 함

Fragment offset field 를 통해 원래 datagram 내에서 해당 fragment 의 위치를 알 수 있음

More-fragment field 를 reset 함으로써 마지막 fragment 를 표시할 수 있음

– 모든 Internet module 은 최소 68 octet 크기의 datagram 은 fragmentation 없이 전달할 수 있어야 함

Header 최대 크기 (60 octets) + data fragment 최소 크기 (8 octets)

6


Fragmentation– 2-way split process

두 개의 새로운 internet datagram 을 만들고 원래의 datagram header 를 각각에 복사

원래 datagram 의 data 를 둘로 분할• 8 octet 단위로 분할해야 함• 길이에 따라서는 8 의 배수가 되지 않을 수 있으나 분할 된 두 data 중 첫 번째는

반드시 8 의 배수가 되어야 함• 첫 번째 data 에 포함된 8 octet block 의 개수를 NFB (Number of Fragment

Blocks) 라 부름 분할 된 첫 번째 data 를 새로 만든 datagram 중 첫 번째에 넣음

• Total length field 에 datagram 의 길이를 기록• More-fragments flag 을 1 로 만듦

분할 된 두 번째 data 를 새로 만든 datagram 중 두 번째에 넣음• Total length field 에 datagram 의 길이를 기록• More-fragments flag 은 원래 datagram 과 같은 값을 가짐• Fragment offset field 는 원래 datagram 의 해당 field 값에 NFB 를 더한

값이 들어감 이상의 과정을 일반화하여 n-way split 을 구현할 수 있음

– Reassemble Identification, source, destination, protocol 의 네 field 가 같은 datagram

들을 모두 모아 fragment offset 값 순서대로 data 를 합침• Fragment offset 이 0 인 datagram 이 가장 첫 번째• More-fragments flag 이 0 인 datagram 이 마지막

7

Internet Header Format

Header fields– Version (4 bits)

Internet header format 의 버전• 위의 그림은 version 4 (RFC 791)

– IHL (Internet Header Length) (4 bits) Internet header 의 길이 (32 bit word 단위 ) 이며 data 가 시작되는 위치를

나타냄 이 값은 최소 5 가 되어야 함

– Type of Service (8 bits) Service 별로 datagram 의 우선순위를 정해 전송하는 기능을 제공하기 위해 정의

되었으나 현실적으로 거의 쓰이지 않음 Filed 내에 precedence, delay, throughput, reliability 정보를 가짐

8


Header fields– Total Length (16 bits)

Header 와 data 를 모두 포함하는 datagram 전체 길이 (octet 단위 )

Field 전체를 사용하면 65535 octet 길이의 datagram 을 보낼 수 있으나 이는 비현실적인 길이임• 실제로는 모든 host 에서 576 octet 까지의 datagram 은 처리할 수

있어야 함 (fragmentation 여부에 관계 없이 )• Destination 에서 576 octet 이상의 datagram 을 처리할 수 있음이

확실하면 그만큼 긴 datagram 도 전송할 수 있음– Identification (16 bits)

Fragment 된 datagram 의 assemble 에 사용하기 위해 송신자에 의해 부여 되는 값

이론적으로는 같은 source-destination 쌍 사이의 datagram 들 사이에서만 이 값이 중복되지 않으면 됨• 현실적으로는 이 filed 의 값이 65536 개나 되므로 모든 datagram 에

unique 하게 부여하는 것이 가능 TCP 와 같이 재전송을 하는 상위 protocol 을 사용하는 경우 , 이 field

의 값을 상위 protocol 이 결정하도록 하는 것이 좋음• 재전송에 대해서 동일한 identification 을 사용할 수 있음• Datagram 의 fragment 들이 처음 전송된 것이든 재전송 된 것이든 관계

없이 정상적인 TCP segment 로 재조합 될 수 있는 가능성이 생김

9


Header fields– Flags (3 bits)

Bit 0: Reserved, 항상 0 Bit 1: DF (Don’t Fragment), 0 이면 fragment 가능 , 1 이면 불가능 Bit 2: MF (More Fragments), 0 이면 마지막 fragment, 1 이면 이후에

fragment 가 더 있음 – Fragment Offset (13 bits)

전체 datagram 내에서 이 fragment 의 위치를 나타냄 8 octet 단위의 값 첫 번째 fragment 는 이 field 의 값이 0

– Time to Live (8 bits) Datagram 이 internet system 상에 남아있을 수 있는 최대 시간을 나타냄 Internet header processing 과정에서 이 값을 감소 시킴

• 이 값이 0 이 되면 Datagram 을 버림 원래 의도는 초 단위의 시간을 나타내는 값이었으나 header processing 에

대부분 1 초 미만의 시간이 걸리므로 이 값은 시간이 아닌 최대 hop 수를 나타내는 것으로 변경되어 사용

Routing 에 loop 이 생겨 datagram 이 network 상에서 무한하게 돌아다니는 것을 방지

– Protocol (8 bits) Datagram 의 data 부분이 어떤 protocol 을 사용하는 data 인지 나타냄 값은 IANA 관리하는 미리 정의된 값을 사용

• ICMP 는 1, TCP 는 6, UDP 는 17

10


Header fields– Header Checksum (16 bits)

Data 는 제외한 header 부분 만의 checksum TTL 과 같은 값은 계속하여 변하므로 매번 checksum 을 재계산 해야

함 이 값이 올바르지 않으면 datagram 을 버림

– Source Address (32 bits) 송신자의 IP 주소

– Destination Address (32 bits) 수신자의 IP 주소

– Options (variable) Option 의 사용은 선택적이나 각 node 는 정의된 모든 option 을

이해하고 처리할 수 있도록 구현되어야 함 Option 은 두 가지 형태 중 하나를 가짐

• Case 1: 1 octet 으로 option-type 만을 나타냄• Case 2: option-type 1 octet, option-length 1 octet, 여러 octet 의

option-data Option-type (8 bits)

• Copied flag (1 bit): fragmentation 이 일어나는 경우에 이 값이 1 이면 모든 fragment 에 이 option 을 복사 , 0 이면 그렇게 하지 않음

• Option class (2 bits): 0 이면 control option, 2 이면 debugging and measurement option, 1 과 3 은 reserved

11


Header fields– Options (variable)

Option-type (8 bits)• Option number (5 bits): option 의 종류를 나타냄

12

CLASS

NUMBER

LENGTH

DESCRIPTION

0 0 - End of Option list: option 목록이 끝났음을 표시

0 1 - No Operation: 다음 option 의 시작을 32 bit 경계에 맞추기 위해 option 들 사이에 이 option 을 끼워넣음

0 2 11 Security: 보안에 관련된 security, compartment, handling restriction, TCC parameter 를 포함

0 3 가변 Loose Source Routing: destination 까지 가는 경로를 송신자가 지정하기 위해 사용 , IP 주소 목록을 포함하고 있으며 이 목록 사이에 다른 gateway 등을 거치는 것을 허용

0 9 가변 Strict Source Routing: Loose Source Routing 과 같으나 주소 목록 사이에 다른 node 를 거치는 것을 허용하지 않음

0 7 가변 Record Route: datagram 이 거쳐간 경로를 기록

0 8 4 Stream ID: stream 개념을 지원하지 않는 network 에서 사용

2 4 가변 Internet Timestamp: datagram 이 경로를 지나간 시간을 기록

Examples

Minimal datagram

13

Examples

2-way fragmentation

14

Examples

Datagram containing options

15

Appendices

IPv6 header (RFC 2460)– Version (4 bits)

Internet Protocol version (6)– Traffic Class (8bits)

RFC 2474 에 정의 된 DS(Differentiated Services) 를 사용하여 QoS 지원

IPv4 의 TOS 를 대체

16

Appendices

IPv6 Header (RFC 2460)– Flow Label (20 bits)

Real-time traffic 과 QoS 보장을 위해 만들어짐 여러 datagram 을 하나의 흐름으로 표시하여 보낼 수 있으며 router

들이 이 흐름에 속한 datagram 들을 동일하게 처리할 수 있음– Payload Length (16 bits)

Header 를 제외한 payload 의 길이 (octet 단위 ) RFC 2460 에 정의 된 extension header 를 사용하는 경우 이들은

payload 로 취급하며 payload length 에도 포함– Next Header (8 bits)

IPv6 header 다음에 따라오는 header 의 종류를 나타냄 IPv4 의 Protocol field 와 같음

– Hop Limit (8 bits) 각 node 를 지날 때마다 1 씩 감소 되며 0 이 되면 packet 을 폐기 IPv4 의 TTL 과 같은 용도

– Source Address (128 bits) 송신자의 IP 주소

– Destination Address (128 bits) 수신자의 IP 주소

17

Appendices

Fragment and reassemble example procedure– General notation =< - less than or equal # - not equal = - equal <- - is set to x to y - includes x and excludes y– Fragmentation notation FO - Fragment Offset IHL - Internet Header Length DF - Don't Fragment flag MF - More Fragments flag TL - Total Length OFO - Old Fragment Offset OIHL - Old Internet Header Length OMF - Old More Fragments flag OTL - Old Total Length NFB - Number of Fragment Blocks MTU - Maximum Transmission Unit

18

Appendices

Fragment and reassemble example procedure– Fragmentation procedureIF TL =< MTU THEN Submit this datagram to the next step in datagram

processingELSE IF DF = 1 THEN discard the datagramELSE To produce the first fragment: (1) Copy the original internet header; (2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF; (3) NFB <- (MTU-IHL*4)/8; (4) Attach the first NFB*8 data octets; (5) Correct the header: MF <- 1; TL <- (IHL*4)+(NFB*8); Recompute Checksum; (6) Submit this fragment to the next step in datagram processing; To produce the second fragment: (7) Selectively copy the internet header (some options are not copied, see option definitions); (8) Append the remaining data; (9) Correct the header: IHL <- (((OIHL*4)-(length of options not copied))+3)/4; TL <- OTL - NFB*8 - (OIHL-IHL)*4); FO <- OFO + NFB; MF <- OMF; Recompute Checksum; (10) Submit this fragment to the fragmentation test; DONE.

19

Appendices

Fragment and reassemble example procedure– Reassembly notation FO - Fragment Offset IHL - Internet Header Length MF - More Fragments flag TTL - Time To Live NFB - Number of Fragment Blocks TL - Total Length TDL - Total Data Length BUFID - Buffer Identifier RCVBT - Fragment Received Bit Table TLB - Timer Lower Bound

20

Appendices

Fragment and reassemble example procedure– Reassembly procedure (1) BUFID <- source | destination | protocol | identification; (2) IF FO = 0 AND MF = 0 (3) THEN IF buffer with BUFID is allocated (4) THEN flush all reassembly for this BUFID; (5) Submit datagram to next step; DONE. (6) ELSE IF no buffer with BUFID is allocated (7) THEN allocate reassembly resources with BUFID; TIMER <- TLB; TDL <- 0; (8) put data from fragment into data buffer with BUFID from octet FO*8 to octet (TL-(IHL*4))+FO*8; (9) set RCVBT bits from FO to FO+((TL-(IHL*4)+7)/8); (10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8) (11) IF FO = 0 THEN put header in header buffer (12) IF TDL # 0 (13) AND all RCVBT bits from 0 to (TDL+7)/8 are set (14) THEN TL <- TDL+(IHL*4) (15) Submit datagram to next step; (16) free all reassembly resources for this BUFID; DONE. (17) TIMER <- MAX(TIMER,TTL); (18) give up until next fragment or timer expires; (19) timer expires: flush all reassembly with this BUFID; DONE.

21

References

RFC 791– Internet Protocol (Sep. 1981)

RFC 2460– Internet Protocol, Version 6 (Dec. 1998)

TCP/IP 완벽 가이드 ( 한글판 )– 에이콘 출판 (2006 년 1 월 )

22

internet protocol (ip) header format & fragmentation

Documents