[Computer network] Chapter 3 - Network layer : IPv4

이한량·2024년 11월 13일

Computer Network

목록 보기
5/11

1. Network layer protocols

  • Network layer version 4 : 네트워크 계층 버전 4는 하나의 주요 프로토콜과 세 개의 보조 프로토콜로 구성된다.

    • IPv4 : 주요 프로토콜인 IPv4는 데이터를 패킷화하고 목적지까지 전달한다.

    • ICMPv4 : IPv4 방식의 전송 중 발생할 수 있는 오류를 처리한다.

    • IGMP : IPv4가 멀티캐스팅을 수행하는 것을 지원한다.

    • ARP : 통신 과정에서 주소 매핑을 위해 사용된다.

2. Datagram in IPv4

  • IP Datagram : IPv4 프로토콜에서 사용되는 데이터 패킷으로, 다음과 같은 구조를 갖는다.

    • Header (20 ~ 60bytes) : 패킷이 올바르게 전달되도록 하기 위한 여러가지 제어 정보를 포함하는 필드이다.

      • VER (Version, 4bits) : IP 프로토콜의 버전을 나타냄

      • HLEN (Header Length, 4bits) : 헤더의 길이를 나타냄

      • Service type (8bits) : 서비스의 유형을 나타냄

      • Total Length (16bits) : 패킷의 전체 길이를 나타내며, 헤더 + 페이로드이다.

      • Identification (16bits) : 데이터그램을 구분하기 위한 식별자이다.

      • Flags (3bits) : 조각화된 데이터 그램을 재조립할 때, 정확한 정보를 추출하기 위해 사용되는 필드이다.

      • Fragmentation offset (13bits) : 조각화된 데이터그램의 시작 위치를 나타내기 위해 사용되는 필드이다.

      • Time-to-Live (TTL, 8bits) : 데이터그램의 생존 시간으로, 데이터그램이 목적지를 찾지 못한 상태로 네트워크 상에 존재하는 상황을 방지한다.

      • Protocol (8bits) : 상위 프로토콜(TCP, UDP 등)을 나타냄

      • Header checksum (16bits) : 헤더의 오류 검사(checksum)를 위해 사용됨

      • Source IP Address (32bits) : 출발지 주소

      • Destination IP Address (32bits) : 목적지 주소

      • Options + Padding (0~40bytes) : 추가 옵션과 패딩을 포함하는 선택적 필드

    • Payload (65,535 bytes - header) : 실제 전송하려는 데이터가 포함된 필드이다.

2-1. IP Header 분석

  • 예제 1 : 수신측에 도착한 IPv4 패킷의 첫 8비트는 다음과 같다. 이 패킷을 받은 수신측은 패킷을 폐기하였다. 그 이유는 무엇일까?

    (0100 0010)2(0100 \ 0010)_2
    • Solution

      • (0100)2(0100)_2 : IP 버전을 나타내며, IPv4로 올바르게 설정되어 있다.

      • (0010)2(0010)_2 : HLEN(헤더 길이)를 나타내는 값으로, 24=8bytes2 * 4 = 8bytes이다. IPv4 헤더의 최소 길이는 20바이트이므로, 이 패킷은 전송 중 손상되었음을 알 수 있다.

  • 예제 2 : IPv4 패킷에서 HLEN 값이 (1000)2(1000)_2이다. 이 패킷은 옵션을 포함하고 있을까?

    • Solution

      • HLEN 값이 8이기 때문에, 헤더의 길이는 32바이트이다.

      • Base Header Length = 20bytes

      • Padding(option) = 12bytes

  • 예제 3 : IPv4 패킷에서 HLEN 값이 5이고, 총 길이 필드 값이 (0028)16(0028)_{16}이다. 이 패킷이 포함하는 데이터의 크기는 무엇일까?

    • solution

      • Header Length = 20bytes

      • Total Length = 40bytes

      • Payload Length = Total Length - Header Length = 20bytes

  • 예제 4 : 다음은 IPv4 패킷의 16진수 패턴의 일부이다. 이 패킷은 Drop되기 전까지 몇 개의 Hop을 이동할 수 있을까? 또, 이 패킷은 어느 상위 계층 프로토콜에 속할까?

    (4500 0028 0001 0000 0102 ...)16(4500 \ 0028 \ 0001 \ 0000 \ 0102 \ ...)_{16}
    • solution

      • 1byte = 8bits, 8비트는 2개의 16진수로 표현된다. 따라서 1바이트는 2개의 16진수로 표현할 수 있다.

      • TTL 필드 찾기 : TTL 필드는 Header의 시작 지점에서 64bits 뒤의 위치에 존재한다. 따라서 16개의 16진수를 건너뛴 자리에 TTL 필드가 위치한다.

      • (01)16(01)_{16} : TTL 필드로, TTL 값이 1이므로 패킷이 단 하나의 홉만 이동할 수 있음을 의미한다.

      • Protocol 필드 찾기 : TTL 다음 8bits가 Protocol 필드이다.

      • (02)16(02)_{16} : 프로토콜 필드이며, 2 = IGMP이다.

2-2. Checksum 예제

  • IPv4 Header checksum : Checksum은 IPv4의 모든 필드의 값을 더하여 구한다. 라우터를 지날 때마다 TTL 값이 1씩 감소하므로, 라우터에 도착할 때마다 체크섬은 재계산된다.

    • 계산 과정

      • 수신 측에서 IPv4 헤더 값을 2bytes(16bits)씩 나눈다.

      • 체크섬을 제외한 모든 필드의 값을 더한다.

      • 캐리가 발생할 경우, 뒷 비트에 더해준다.

      • 나온 값에 1의 보수를 취해준다.

  • 예제 : 헤더의 각 필드 값이 다음과 같이 16진수로 주어질 경우, 체크섬 예제

    • 각 필드를 2진수로 변환 :

      • (b1e6)16(b1e6)_{16}은 체크섬 필드로, 체크섬을 계산할 때 0으로 초기화한다.

      • 도착지에 도달한 경우, 체크섬 필드를 포함한 모든 필드를 더한 값이 0이 될 경우, 오류가 발생하지 않았다고 판단한다.

    • Checksum 계산

      • 4500 + 003c = 453c

      • 453c + 1c46 = 6182

      • 6182 + 4000 = A182

      • E188 + AC10 : 캐리가 발생했기 때문에 캐리가 발생한 비트를 오른쪽 16비트에 더해준다.

      • 위와 같은 방식으로 모든 필드들을 더해준다.

    • 최종 결과로 나온 4e19에 1의 보수를 취한 값이 체크섬 필드에 저장된다.

3. Fragmentation

  • Fragmentation : 데이터그램을 여러 조각의 프래그먼트로 나누는 것으로, 이는 다양한 네트워크 환경에서 맞게 데이터그램의 크기를 조절하여 전송할 수 있도록 하는 유연성을 제공한다.

    • 라우터는 수신한 프레임에서 데이터그램을 역캡슐화하여 필요한 처리 과정(예를 들면, 체크섬 재계산)을 거친 뒤 다시 새로운 프레임으로 캡슐화한다.

    • 프레임이 이동하는 네트워크 환경(프로토콜)에 따라 달라지기 때문에 라우터가 수신한 프레임과 전송하는 프레임은 형식이나 크기 등이 달라질 수 있다.

      • LAN과 WAN을 연결하는 라우터를 생각해보자. 라우터는 LAN 형식의 프레임을 수신하고 이를 WAN 형식의 프레임으로 변환하여 전송할 것이다.
  • Maximum Transfer Unit (MTU, 최대 전송 단위) : 프레임 Payload의 최대 크기를 나타내며, 이는 네트워크에서 전송 가능한 프레임의 최대 크기를 결정한다.

    • Frame Payload = IP Datagram(Header + Payload)

    • Frame = Header + Payload + Trailer

    • 데이터그램이 MTU보다 큰 경우, 전송을 위해선 단편화가 필수적이다.

3-1. 단편화 예제

  • 예제 1 : 원본 데이터그램 단편화

    • 4000bytes 크기(0 ~ 3999byte)의 원본 데이터그램을 3개의 프레임으로 나눈다.

    • Offset : 원본 데이터그램 내의 위치를 나타내는 값이다. 프레임은 이 값을 활용하여 올바른 순서로 재조립된다.

  • 예제 2 : 데이터그램의 통신 과정

    • 원본 데이터그램 : MTU 제한으로 인해 3개의 프레임으로 분할

      • F1 : 0 ~ 1399bytes, Offset = 000 (0000 / 8)

      • F2 : 1400 ~ 2799bytes, Offset = 175 (1400 / 8)

      • F3 : 2800 ~ 3999bytes, Offset = 350 (2800 / 8)

    • 전송 과정

      • 첫 번째 라우터에 도달한 F2는 두 개의 프레임 F2.1, F2.2으로 다시 한번 나누어진다.

      • F2.1, F2.2는 두 번째 라우터로 이동

      • F3, F1은 세 번째 라우터로 이동한다.

      • 세 번째에 도달한 프레임은 총 4개

      • 목적지에 도착한 모든 프레임은 순서대로 재조립되어 원본 데이터그램으로 복원된다.

3-2. Fragment Offset, MF 예제

  • 예제 1 : MF = 0인 경우, 이 프레임이 어느 순서에 위치한 프레임인지 알 수 있을까?

    • solution : MF 비트가 0이라는 것은 더이상 프레임이 없다는 것을 의미한다. 따라서 MF 비트가 0인 프레임은 마지막 프레임이다.

      • 단편화되지 않은 패킷도 MF 비트는 0이다.

      • MF = 0, Offset = 0 : Invalid Packet

  • 예제 2 : MF 비트 값이 1인 경우, 이 프레임이 어느 순서에 위치한 프레임인지 알 수 있을까?

    • solution : MF 비트가 1이라는 것은 적어도 1개 이상의 다음 프레임이 존재한다는 것을 의미한다. 따라서 MF 비트가 1인 프레임은 마지막 프레임이 아닐뿐, 순서는 정확하게 판단할 수 없다.

      • Fragment offset을 통해 정확한 순서를 찾아낼 수 있다.
  • 예제 3 : MF 비트가 1이고, Fragment Offset 값이 0인 경우

    • solution : MF 비트가 1이고 Fragment offset이 0이라는 것은 해당 프레임이 첫 번째 프레임이라는 것을 의미한다.
  • 예제 4 : 프레임의 Fragment offset 값이 100일 때, 이 프레임의 첫 번째 바이트의 번호를 알 수 있을까?

    • solution : 100 * 8 = 800, 따라서 첫 번째 바이트 번호는 800이다.

      • 마지막 바이트의 번호는 데이터의 길이를 정확히 알아야 알 수 있다.
  • 예제 5 : Fragment offset 값이 100, HLEN 값이 5, 총 길이 필드 값이 100인 패킷

    • solution

      • 첫 번째 바이트의 번호 : 800

      • 총 길이 : 100bytes

      • 헤더 길이 : 5 * 4 = 20bytes

      • 데이터의 길이 : 100 - 20 = 80bytes

4. Option Field

  • Header : IPv4 데이터그램의 헤더는 고정 부분과 가변 부분으로 구성된다.

    • Fixed part (Base Header) : 20바이트 크기를 가지며, 필수적인 정보가 포함되어 있다.

      • IP 버전, 헤더 길이, 서비스 유형, 패킷의 전체 길이, TTL, 프로토콜 ...
    • Variable part (Header Option) : 옵션 필드로, 최대 40바이트까지 사용할 수 있다.

      • IPv4 헤더의 끝에 위치하며, 4바이트 단위로 설정하낟.
    • 몇 가지 주요 옵션들

4-1. Loose & Strict source routing

  • Loose source and record route (LSRR, 느슨한 소스 및 경로 기록) : 데이터그램이 특정 경유 노드를 통과하도록 설정하지만, 지정된 노드 사이에 다른 경로를 추가적으로 선택할 수 있다.

  • Strict source and record route (SSRR, 엄격한 소스 및 경로 기록) : 데이터그램이 오직 지정된 노드만을 경유하도록 한다.

5. ICMPv4

  • Security of IPv4 Datagrams : IPv4가 설계될 당시 Error reporting / correction에 대한 기능은 포함되지 않았었다. 따라서 다음과 같은 세 가지의 주요한 보안 이슈가 존재한다.

    • Packet sniffing (패킷 스니핑)

    • Packet modification (패킷 수정)

    • IP spoofing (IP 스푸핑)

  • ICMPv4 (Internet Control Message Protocol version 4) : IPv4가 갖는 보안 문제를 해결하기 위해 고안된 프로토콜이다. ICMP는 다음과 같은 두 가지 형태의 메시지를 사용한다.

    • Error-Reproting message : 네트워크 라우터나 목적지 호스트가 IP 패킷을 처리하는 동안 발생한 오류에 대한 보고 메시지이다.

      • 예를 들면, 패킷이 잘못된 경로로 전달되었거나, 손실되었거나 하는 등의 오류이다.
    • Query message : 요청(Request)와 응답(Reply) 쌍으로 이루어진 메시지로, 네트워크 관리자나 호스트가 네트워크에 대한 특정 정보를 얻기 위해 사용된다.

      • 예를 들어, 호스트가 네트워크 상의 라우터에게 요청 메시지를 보내면, 라우터는 응답 메시지를 보내는 식이다.

5-1. Debugging Tool - Ping

  • Ping : ICMPv4에서 사용되는 네트워크 디버깅 도구 중 하나로, 네트워크의 지연 상태를 파악하는데 유용하다.

    • 호스트 또는 서버가 네트워크에 정상적으로 연결되었는지 확인 가능

    • 패킷의 왕복 시간, 손실률 등을 측정하여 네트워크 상태(혼잡도)를 확인할 수 있다.

  • 사용 예시 : ping 명령어를 사용하여 auniversity.edu 서버의 혼잡도 측정

    • Ping 측정 과정

      1). Ping auniversity.edu 명령어를 입력하여 Echo Request 메시지를 대상 호스트(auniversity.edu)로 전송한다.

      2). 요청 메시지는 다음 정보를 포함한다.

      • 시퀀스 번호가 0에서 시작하여 요청 메시지가 전송될 때마다 1씩 증가한다.

      • 데이터 섹션에 전송 시간이 기록되어 있다.

      3). 요청 메시지를 받은 대상 호스트(auniversity.edu)는 Echo reply 메시지를 반환한다.

      4). 송신자는 Echo reply를 수신하고, RTT(Round Trip time, 왕복 시간)를 계산한다. (RTT = 응답 수신 시간 - 송신 시간)

    • Ping 결과

5-2. Debugging Tool - Traceroute

  • Traceroute : 패킷이 목적지까지 이동하는 과정에서 경유하는 라우터의 경로를 확인하는 방법이다.

    • 작동 원리

      • Traceroute는 패킷을 전송할 때 초기 TTL 값을 1로 설정한다.

      • TTL이 0이 되면, 이 패킷을 받은 라우터는 패킷을 폐기하고 Time-exceeded 메시지를 송신자에게 전송한다.

      • 이후 Traceroute는 TTL 값을 1씩 증가시키며 위 과정을 반복하여 경유하는 라우터의 정보를 수집한다.

      • 최종 목적지에 도달할 경우, 목적지 호스트는 송신자에게 ICMP Echo Reply 메시지를 전송한다.

    • 위 방식을 통해 어떤 라우터를 경유하여 패킷이 이동하는지 확인할 수 있다.

profile
한량 극복 프로젝트

0개의 댓글