INTERNET PROTOCOL (IP) Header Format & Fragmentation

1. INTERNET PROTOCOL (IP)Header Format & Fragmentation 2008.10

2. 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

3. 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의 기능을 활용할 수 있음

4. 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 checksumerror는 IP module 내에 구현 된 ICMP를 통해 상대에게 알려질 수 있음

5. 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 • Localnet 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

6. Function Description • 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)

7. Function Description • 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이 마지막

8. 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 정보를 가짐

9. Internet Header Format • 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로 재조합 될 수 있는 가능성이 생김

10. Internet Header Format • 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

11. Internet Header Format • 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

12. Internet Header Format • Header fields • Options (variable) • Option-type (8 bits) • Option number (5 bits): option의 종류를 나타냄

13. Examples • Minimaldatagram

14. Examples • 2-way fragmentation

15. Examples • Datagram containing options

16. Appendices • IPv6 header (RFC 2460) • Version (4 bits) • Internet Protocol version (6) • Traffic Class (8bits) • RFC 2474에 정의 된 DS(Differentiated Services)를 사용하여 QoS 지원 • IPv4의 TOS를 대체

17. 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 주소

18. 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

19. Appendices • Fragment and reassemble example procedure • Fragmentation procedure IF TL =< MTU THEN Submit this datagram to the next step in datagram processing ELSE IF DF = 1 THEN discard the datagram ELSE 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.

20. 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

21. 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.

22. References • RFC 791 • Internet Protocol (Sep. 1981) • RFC 2460 • Internet Protocol, Version 6 (Dec. 1998) • TCP/IP 완벽 가이드 (한글판) • 에이콘 출판 (2006년 1월)