IPv4 Header.

IPv4 Header.

#1 Summary.

IP 글을 쓰다가 관련 중요 개념인 헤더에 대한 언급은 안 했기 때문에 IPv4 헤더에 대해 설명해보겠다. 같이 공부하는 입장으로써 저는 더 초짜이기 때문에 아시는 분은 부족한 부분에 대해 너그럽게 봐주셨으면 한다. IPv4헤더에 대해서만 언급하고 IPv4와 IPv6의 비교, IPv6 헤더는 다른 글에서 언급하도록 하겠다. 아마 관련 개념들도 많을텐데 점차적으로 다른 글에서 언급하겠다.

#2 IPv4 Header.

일단 IPv4 헤더는 13개의 필드로 구성되어 있다. IP Option 필드를 제외하고 12개는 무조건 사용하며 길이는 20Byte다. 참고로 IPv4는 1980년대에 만들어졌다보니까 굳이 사용하지 않아도 되는 필드까지도 사용한다는 점에서 비효율적이긴 하다. 하나의 IP 데이터그램은 헤더 부분과 텍스트 부분으로 구성된다. 헤더는 20Byte의 고정 부분과 가변 길이의 옵션 부분을 갖는다. 또한 헤더는 빅엔디안(Big Endian) 순서로 전달된다. 즉 왼쪽에서 오른쪽 Version 필드의 상위비트부터 전달된다. 엔디안에 대해서는 다른 글에서 언급하도록 하겠다.

1. Version(4Bits) ==> 현재 이 패킷이 IPv4인지 IPv6인지를 나타낸다. 즉 간단히 IP 프로토콜의 버전을 정의하고 IPv4는 당연히 4의 값을 가지며 4니까 0100로 표시된다. 다른 IP 버전 데이터그램은 폐기하고 라우터는 버전 번호를 확인하고 어떤 식으로 IP 데이터그램의 나머지 부분을 해석할지 결정한다.

2. IHL= IP Header Length(4Bits) ==> IP 헤더의 길이를 설정하는 필드이고 4bit로 이루어져 있다. 좀 더 자세히 말하면 2진수 = 10진수 X 4바이트 = 헤더 전체 길이고 2진수 0101 = 5 X 4바이트 = 20바이트다. 20바이트는 옵션 미지정된 일반적인 IPv4 헤더 길이다. 2진수 1111 = 15 X 4바이트 = 60바이트는 헤더의 최대 길이다. 즉 헤더의 전체 바이트 수 = 헤더 길이 X 4.

CF) IPv6는 고정 크기 헤더로 기본 40바이트로 고정되어져 있고 확장 헤더에 의해 붙여질 수는 있어도 기본 헤더 크기는 고정되어 있다.

3. TOS = Type Of Service(8Bits) ==> 서비스 품질에 따라 패킷의 등급을 구분한다. 높은 값을 우선처리하게 된다. 음성 > 영상 > Text 순서다. 8비트로 앞의 3비트는 우선 순위를 결정하고 뒤의 5비트는 서비스 유형을 나타낸다. 참고로 5비트 중 마지막 1비트는 사용하지 않는다.

4. Total Length(16Bits) ==> 간단히 말해 전체 IP 패킷의 길이를 바이트 단위로 나타낸다. 헤더+데이터의 크기,즉 패킷의 전체 길이를 나타내주는 필드로서 1비트당 1바이트를 의미한다. 필드 길이가 16비트이므로, 최대한의 패킷 크기는 2^16-1, 65,535바이트가 패킷 하나의 최대 크기다. 근데 1500바이트보다 큰 경우는 드물다.

5. Identification(16Bits) ==> 모든 IP 패킷은 생성될 시에 식별 번호를 부여 받는다. 식별 번호는 16 비트 필드 안에 있는데, IP 패킷은 더 작은 조각난 패킷으로 분리되어 목적지에 전송되는 경우가 있다. 즉 이것을 조각난 패킷, 프래그먼트 패킷이라고 한다. 각각의 프래그먼트 패킷은 고유 번호가 같기 때문에, 전송된 패킷이 다른 전송된 패킷과 같은 식별자를 가진다면 같은 패킷에서 조각난 것을 알 수 있다.

6. IP Flags(3Bits) ==> 3개의 비트로 이루어진 플래그이고 프래그먼트 패킷의 상태나 생성 여부를 결정하는 플래그다.

x => Reserved Flag ==> 항상 0으로 설정하는 플래그.

DF => Don't Fragment Flag ==> 0으로 설정하면 조각화가 가능한 패킷이며 1로 설정된 패킷은 분할하지 않는 설정을 하는 플래그.

MF=> More Fragment Flag ==> 0이면 더 이상 조각난 패킷이 없다는 뜻이고 1이면 아직 수신되지 않는 IP 패킷이 있다는 의미.

7. Fragment Offset(13Bits) ==> 쪼개진 패킷의 순서를 알려주기 위함이다. 패킷의 순서를 상대적인 개념을 사용해서 알려준다. 주의할 것은 Fragment Offset는 항상 바이트를 8로 나눈 값을 사용한다. 예를 들어 1600바이트를 표현하고 싶을 때 1600/8=200. 200라는 값이 필드에 입력되어있다. 쉽게 말해 1비트 설정당 8바이트의 오프셋을 의미한다.

8. TTL = Time To Live(8Bits) ==> IP 패킷이 라우터를 지나칠 때마다 라우터는 TTL 값을 1씩 감소시킨다. 그래서 TTL이 0이 되면, 패킷은 더 이상 전송하지 않는다. TTL 값이 0이 될 때까지 전송되지 않는 것은 전송할 수 없다고 생각하고 패킷을 버리게 된다. 즉 패킷 수명을 제한하기 위해 사용하는 카운터다. 시간은 초 단위이고 최대 수명은 255초다. 각 홉마다 감소되어야 하고 라우터에서 장시간 대기 했을 때에는 해당 시간만큼 감소된다. 하지만 시간은 구현하기 곤란한 이유로 현재는 홉수로 표현한다. 라우터를 지날 때 마다 홉수는 하나씩 감소하며 이 값이 0이 되면 해당 라우터에서 폐기하고, 경고 패킷의 경우는 원래 호스트로 돌려보낸다. 이것의 목적은 라우팅 테이블의 오류로 인해 패킷이 네트워크 상에서 영원히 떠돌아 다니는 것을 방지하게 된다.

9. Protocol(8Bits) ==> 네트워크 계층에서 데이터그램을 재조합할 때, 어떤 상위 프로토콜로 조합해야 하는지 알 필요가 있으므로 UDP 또는 TCP를 알려주기 위해 사용한다. 또한 네트워크와 트렌스포트 계층을 하나로 결합하고 ​IP 데이터그램이 최종 수신지에 도착했을 때만 사용된다. 대표적인 타입은 ICMP, IGMP, TCP, UDP다.

10. Header CheckSum(16Bits) ==> IP 헤더가 생성되거나 수정될 때마다 IP 헤더 내 비트를 검사한다. IP 패킷이 전송되거나 계산결과가 똑같이 나타난다면 IP 헤더의 모든 비트는 정확하게 전송된 것이다. 결과가 다르게 나타나면, 이는 전송 중에 IP 패킷이 일부가 손상되거나, 조작되었다는 것을 의미한다. IP 프로토콜 헤더 자체의 내용이 바르게 교환되고 있는가를 점검한다. 체크섬의 장점은 체크섬을 하나 안하나 속도 차이가 없다. 수신된 패킷 안에서 IP헤더 자체의 데이터를 검사하는데 사용한다. 라우터는 수신하는 IP 데이터그램 마다 인터넷 체크섬을 계산하고 이 값과 데이터그램의 체크섬이 다르면 오류 상태임을 검출하고 보통 오류가 검출된 데이터그램을 폐기한다.

CF) IP헤더 체크섬 계산방법 ==> IP헤더의 영역만을 가지고 체크섬을 계산한다. 2바이트씩 IP헤더를 모두 잘라 더한 후에 발생한 올림 영역까지 더해준 후, 1의 보수(비트반전)을 시켜주면, IP헤더의 체크섬 값이 계산된다.

11. Source Address(32Bits) ==> 출발지 주소를 32비트 주소로 표현한 것일 뿐이다. 즉 데이터그램을 보낸 송신지 주소를 나타낸다.

12. Destination Address(32Bits) ==> 도착지 주소를 32비트 주소로 표현한 것 뿐이다. 즉 데이터그램을 받을 목적지 주소를 나타낸다.

13. Options(Variable) ==> 원래 설계에서 소개 되지 않은 추가 정보를 포함하는 차기 프로토콜을 수용하고, 새로운 실험을 위해서나 헤더정보에 추가 정보를 표시하기 위해 설계되었다. 옵션은 가변길이로서 각각은 옵션을 확인할 수 있는 1바이트 코드로 시작한다.

CF) 위의 IPv4 Header처럼 패딩이랑 데이터도 나타낸 그림이 있으니 추가적으로 언급하겠다.

14. Padding(Variable) ==> IP 헤더의 크기는 16비트 워드의 크기가 4의 배수가 되도록 설계되어 있다. 앞서 설명한 필드의 전체 크기가 이 조건에 맞지 않으면 이 필드를 사용해 조정할 수 있다. 필요한 경우에만 사용하고 옵션을 사용하다 보면 헤더가 32비트의 정수배로 되지 않는 경우가 있다. 여기서 필요한 경우는 위의 그림처럼 헤더 길이를 32비트 단위로 맞추기 위해서 사용된다고 볼 수 있다. 즉 패딩을 옵션과 함께 둬서 IP header를 좀 더 효율적으로 구성할 수 있게 되지 않았나 싶다.

15. Data(Variable) ==> 데이터 그램에서 전송할 데이터로 전체 상위 계층 메시지 또는 하나의 프래그먼트(조각)다.

​

#3 Additionally.

#3-1 9에서 언급한 Protocol의 Number와 Type은 아래와 같다.

#3-2 3에서 언급한 TOS = Type Of Service에 관한 추가 설명이다.

위의 그림들처럼 3비트의 우선권(Precedence)필드와 4비트의 TOS 필드, 그리고 값이 0인 사용되지 않는 1비트로 구성되어 있다. 0000은 default(기본 값), 0001은 Minimize Cost(최소 비용), 0010은 Maximize Reliability(최대 신뢰성), 0100은 Maximize Throughput(최대 처리율), 1000은 Minimize Delay(최소 지연)을 의미한다. IP Precedence에 대해 말하면 Type Of Service 필드의 상위 3 비트를 사용하고 숫자가 클수록 우선 순위가 높다. 0, 즉 Routine은 우선 순위가 가장 낮은 Best-Effort이고 6과 7은 인터넷과 네트워크 용도로 예약되어 있다. 가장 우선 순위가 높은 것은 5(Critical)다. 

Related Link => http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

      => http://jinynet9.tistory.com/48