1. Introduction
IP는 TCP/IP 프로토콜 스위트의 핵심 프로토콜이다. TCP, UDP, ICMP, IGMP 들은 모두 데이터를 IP datagram의 형식으로 전송한다. IP는 best-effort 기반의 connectionless datagram 전송 서비스를 제공한다. 여기서 best-effort이란 IP datagram이 목적지에 성공적으로 도달할 것을 보장하지 않는다는 뜻이다. 예를 들어, 라우터가 일시적으로 버퍼 메모리가 고갈되면 IP는 간단한 오류 처리 알고리즘을 사용한다. 바로 고갈 후 도착한 데이터를 버리는 것이다. 이 후 대처는 상위 계층이 제공해야한다. (타이머 설정 등). IPv4와 IPv6 모두 이러한 best-effort model을 사용한다.
Connectionless라는 용어는 IP가 라우터 내에서 관련 데이터그램에 대한 연결 정보를 유지하지 않는다는 뜻이다. 즉, 서로 연결되어있는 데이터그램이라고 하더라도 독립적으로 처리한다는 뜻이다. 이로 인해 IP datagram은 순서대로 전달되지 않을 수 있다. 따라서 1,2,3을 보내도 1,2,3 각 패킷이 다른 경로로 전달이 될 수 있으며 2,1,3과 같이 도착할 수 있다는 것이다. 아니면 전송 중에 복제되거나 오류로 인해 데이터가 변경될 수도 있다. 이러한 잠재적인 문제는 상위 계층 프로토콜이 처리해야하며 Application layer까지 갔을 때 오류가 없는 추상화를 제공해야한다.
2. IPv4 and IPv6 Headers
1. IP Header Fields
그림은 순서대로 IPv4, IPv6 header이다.
Version은 IPv4인지 v6인지를 표현하기 위한 필드이며, 유일하게 v4, v6 헤더가 공유하는 부분이다. 이 부분을 스캔한 스택은 이후 적절한 처리를 해야한다.
IHL 필드는 Internet Header Length field이고 IPv4 header의 32비트 단위 워드 수를 나타낸다. 4비트 크기이므로 32비트 워드 기준 최대 15*4 = 60 바이트 까지 IPv4 header의 길이를 설정할 수 있다. IPv6는 헤더 길이 40바이트로 고정이므로 해당 필드가 필요없다. 이후 6비트를 Differentiated Services 필드, 2비트를 Explicit Congestion Notification(ECN) 필드로 할당한다. 이 필드들은 datagram이 전달될 때 특별한 처리를 위해 사용된다.
Total length 필드는 IPv4 헤더에서 필수적이다. 그 이유는 IPv4 datagram을 전송하는 일부 하위 계층 프로토콜은 캡슐화된 데이터 크기를 정확히 전달하지 않기 때문이다. 만약 Total length 필드가 없다면 IPv4 구현은 46 바이트의 이더넷 프레임에서 실제 IP datagram 크기와 패딩 부분을 구분하지 못할 것이다. 65535 바이트 크기(최대 크기)의 IP datagram을 전송한다고 해보자. 이 경우 대부분의 link layer는 이렇게 큰 datagram을 작은 조각으로 fragmentation 하지 않고는 전송할 수가 없다. 게다가 IPv4 구조에서는 호스트가 576 바이트까지 처리할 수 있어야하는 것이 의무이고 그 이상은 의무가 아니다. UDP 프로토콜을 사용하는 많은 애플리케이션(DNS, DHCP 등)은 576바이트 IPv4 제한을 피하기 위해 데이터 크기를 512바이트로 제한한다. IPv4 datagram이 여러 조각으로 단편화될 경우, 각 조각은 독립적인 IP datagram으로 취급되며, Total length 필드는 단편화된 조각의 크기만을 기록한다. IPv6의 경우는 헤더가 단편화를 지원하지 않으며 datagram의 길이는 대신 Payload length 필드에 의해 지정된다. 이 필드는 IPv6 datagram의 길이를 헤더 제외 측정한다.(확장 헤더의 경우에는 Payload length 필드에 포함된다.) IPv4와 마찬가지로 16 비트를 할당하기 때문에 최대 65535로 크기가 제한된다. 추가적으로 jumbogram 옵션을 사용하면 페이로드가 4GB인 단일 패킷을 지원할 수도 있다.
Identification 필드는 IPv4 호스트가 전송하는 각 datagram을 식별하는데 이용된다. 각 데이터그램은 독립으로 전송되기 때문에, 하나의 데이터그램 조각이 다른 데이터그램 조각과 혼동되지 않으려면 필수이다. 송신 호스트는 일반적으로 각 전송시마다 카운터 값 1을 증가시키고 이를 IPv4 Identification에 넣는다. IPv6에서는 이 필드가 Fragmentation 확장 헤더에 포함된다.
Time-to-Live(TTL) 필드는 데이터램이 네트워크 토폴로지에 머물 수 있는 시간을 의미한다. 보통 통과 가능한 최대 라우터 수이다. 각 라우터를 지날 때마다 1씩 감소하며 0에 도달하면 도착한 라우터에서 폐기된다. 송신자는 ICMP 메시지로 통보를 받는다.
IPv4 헤더의 Protocol 필드는 데이터그램의 payload 부분에 포함된 데이터 유형을 나타내는 숫자이다. (Ex : 17 UDP, 6 TCP) 중요한 점은 항상 Transport layer 프로토콜을 전송하는 것이 아니라는 것이다. IPv4-in-IPv6와 같은 형태의 캡슐화 방식도 가능하다. IPv6 헤더의 Next Header 필드는 IPv4의 Protocol 필드를 일반화한 것이다. 이 필드는 IPv6 헤더 다음에 오는 헤더의 유형을 나타낸다.
Header Checksum 필드는 IPv4 헤더에 대해서만 계산하여 넣는다. 즉, IPv4 데이터 그램만 가지고는 Payload 부분의 정확성을 검사할 수 없는 것이다. IPv6에는 체크섬 필드가 없다.
2. The Internet Checksum
인터넷 체크섬은 16비트의 수학적 합이다. 이는 수신된 메시지가 송신되었을 때와 일치하는지 확인하는데 사용된다. CRC와는 다르며 CRC가 더 강력한 보호 기능이다.
IPv4 헤더의 체크섬을 계산하려면, 먼저 송신 데이터그램의 Checksum 필드를 0으로 설정한다. 그 다음 헤더 전체를 16비트 단위의 워드 시퀀스로 간주하여 16비트 1의 보수 합을 계산한다. 이후 이 합의 16비트 1의 보수값을 체크섬 필드에 저장한다. (end-round-carry addition)
IPv4 데이터그램이 수신되면, 체크섬 필드를 포함한 헤더 전체에 대해 다시 체크섬을 계산한다. 오류가 없으면 계산된 최종 값은 0이어야한다. 헤더가 손상된 경우 IPv4 구현은 수신된 데이터그램을 폐기한다.(이 때는 TTL drop과 다르게 ICMP 메시지가 생성되지 않는다.)
3. DS Field and ECN(ToS Byte or IPv6 Traffic Class)
IPv4 헤더의 3 번째와 4 번째 필드(IPv6 기준 2,3)는 DS 필드와 ECN 필드이다. DS는 인터넷에서 단순한 best-effort 전달을 넘어서는 차별화 서비스 클래스를 지원하기 위한 프레임 워크이다. 미리 정의된 패턴에 따라 DS 필드의 비트를 설정하여 IP datagram은 다른 datagram보다 빠르게 전달될 수 있다.
DS 필드에는 DSCP라는 숫자가 할당된다. CP(code point)는 합의된 의미를 가진 비트 배열을 의미한다. 헤더의 ECN 비트 쌍은 데이터그램이 내부적으로 많은 트래픽이 대기 중인 라우터를 통과할 때 혼잡 상태를 나타내기 위해 사용한다. 혼잡 상태인 ECN 인식 라우터는 패킷을 전달할 때 ECN 비트를 설정한다. ECN이 활성화되어있는 패킷을 받은 수신측은 이 사실을 송신 측에 알려줄 수 있다.(TCP 프로토콜 등이 제공) 그러면 송신측은 송신 속도의 조절이 가능해진다. 이 두 필드는 ToS 바이트라고 불린다.
D,T,R 서브필드는 데이터그램이 Delay, Throughput, Reliability 측면에서 우선적으로 처리되어야 함을 나타낸다. 값이 1이면 각각 낮은 지연, 높은 처리량, 높은 신뢰성을 제공하도록 요청하는 것을 의미한다.
precedence 값은 000~111 까지 증가하며 우선 순위가 높아질 수록 처리 우선권도 높아진다.
DS 필드를 정의할 때, 우선순위 값이 고려되어 제한적인 형태의 하위 호환성을 제공하도록 설계되었다. 상단 그림을 참조하면 DS 필드는 2^6, 즉 64가지의 개별 CP를 지원한다. DS 필드의 클래스 부분은 처음 3비트로 구성되며, 이는 ToS 필드의 Precedence 정의를 기반으로 한다. 일반적으로 라우터는 먼저 트래픽을 다른 클래스로 분류한다. 공통 클래스 내의 트래픽은 Drop prob.가 서로 다를 수 있으며 이를 통해 라우터는 트래픽을 폐기해야할 경우 어떤 트래픽을 우선적으로 폐기할지 결정한다.
3비트 Class selector는 8개의 정의된 CP를 제공하며, 이는 이전 IP 우선순위 기능과 유사한 기능을 제공하는 PHB(Per-Hop Behavior)와 연결된다. 이러한 PHB는 Class Selector Compliant PHBs라고 하며, IP Precedence 서브 필드의 원래 정의와 하위 호환성을 지원하도록 설계하였다. 형식이 xxx000인 CP는 항상 이러한 PHB와 매핑된다.
AF 그룹은 고정된 수의 독립적인 AF 클래스에서 IP 패킷의 전달을 제공하며, 이를 통해 우선순위 개념을 일반화한다.
AFij라는 이름은 i번 AF 클래스와 j번 드롭 우선 순위를 나타낸다. 드롭 우선 순위가 크면 클수록 먼저 서비스된다.
EF 서비스는 혼잡하지 않는 네트워크 상황을 가정한다. 즉, EF 트래픽은 비교적 낮은 지연, 낮은 지터, 낮은 손실을 제공받아야한다. (라우터에서 나가는 EF 트래픽의 속도가 들어오는 EF 트래픽의 속도와 최소한 같아야한다.)
4. IP Options
IP는 데이터그램 단위로 선택할 수 있는 여러 옵션을 지원한다. 이러한 옵션 대부분은 IPv4가 설계되던 당시에 도입된 것이며 당시의 인터넷은 현재보다 작았으며 공격법도 다양하지 않던 시기였다. 이로 인해, 많은 옵션이 IPv4 헤더의 제한된 크기나 보안 문제로 인해 현재는 사용되지 않게 되었다. 옵션을 사용하기 위해 Type 필드에 들어가게 되는 Value는 첫 번째 비트가 옵션이 단편화 될 경우 복사되어 들어가야하는지 여부를 표시하며, 다음 두 비트는 옵션의 클래스를 나타낸다.
이에 따라 IPv6에서는 대부분의 옵션이 제거되거나 변경되었다. 대신 이 옵션들은 IPv6 헤더 뒤의 헤더, 즉 Extension header(확장 헤더)로 배치된다. IPv6 라우터의 경우 일부 확장 헤더를 직접 처리하기도 하지만, 많은 확장헤더는 end host(종단)에서만 처리되도록 설계되었다. 이는 신속한 전송을 위해서이다. 옵션 영역은 항상 32비트 경계에서 끝난다. 만약 부족할 경우 이를 맞추기 위해 값이 0인 pad bytes를 추가하여 IPv4 헤더가 항상 32비트의 배수가 되도록 보장한다. (IHL 필드의 요구사항)
이전에 언급한대로 대부분의 표준화된 옵션은 오늘날 사용되지 않는다. 예를 들어 Source and Record Route는 IPv4 주소를 IPv4 헤더 안에 배치해야하고, 이는 평균적으로 약 15개의 라우터 홉이 있는 현대 인터넷에는 유용하지 않다.
따라서 IPv4 옵션은 일반적으로 엔터프라이즈 네트워크의 경계에서 방화벽에 의해 허용되지 않거나 제거된다.
엔터프라이즈 네트워크 내부에서는 평균 경로 길이가 짧고 악의적인 공격이 덜 우려되기 때문에 옵션이 여전히 유용할 수 있다. 또한 Router Alert 옵션은 성능 최적화를 목적으로 설계되었으며 라우터의 기본 동작에 영향이 없기 때문에 더 자주 허용된다. (Router Alert 옵션은 라우터에 특정 패킷이 일반적인 전달 알고리즘 외에 추가적인 처리가 필요하다는 것을 알리는 옵션이다.)
3. IPv6 Extension Headers
IPv6에서는 IPv4에서 제공되던 옵션과 같은 특수 기능을 확장 헤더를 통해 활성화할 수 있다. IPv4의 라우팅 및 타임스탬프 기능은 물론, 단편화 및 extra-large 패킷과 같은 기능도 이러한 방식으로 지원된다. 이렇게 확장헤더로 빠지는 기능들은 유용하다고 판단은 되었으나, 자주 사용되는 것은 아니라는 판단 하에 빠지게 된 것이다. 이러한 설계를 통해 IPv6 헤더는 40바이트로 고정되며, 확장 헤더는 필요할 때만 추가된다. IPv6 헤더 크기를 고정하고 확장 헤더가 종단에서만 처리되게 설계함으로써 고성능 라우터의 설계와 구축이 더 쉬워지게 된다.
확장 헤더는 TCP나 UDP와 같은 상위 계층 프로토콜의 헤더와 함께 IPv6 헤더와 연결되어 cascade of headers(헤더 체인)을 형성한다.
각 IPv6 헤더의 Next Header 필드는 다음 헤더의 종류를 명시하는 부분이다. 이는 IPv6 확장 헤더일 수도 있고, 바로 상위 계층 헤더로 이어질 수도 있다.
1. IPv6 Options
IPv6 옵션이 있는 경우, 이는 Hop-by-Hop Options(데이터 그램 경로 상의 모든 라우터와 관련된 옵션), Destination Options(수신자와만 관련된 옵션)으로 그룹화된다. HOPOPT만이 패킷이 경유하는 모든 라우터가 처리를 해야하는 옵션이다.
Hop-by-Hop OPT 헤더와 Destination OPT 헤더는 여러 옵션을 포함할 수 있으며, 각 옵션은 Type-Length-Value(TLV) 세트로 인코딩 된다. Type 부분의 첫 2 비트는 IPv6 노드가 Option Type 필드를 인식하지 못할 경우 수행해야할 동작을 나타낸다. 예를 들어 멀티캐스트 목적지로 전송된 데이터그램에 알 수 없는 옵션이 포함된 경우, 많은 노드가 소스로 트래픽을 일시에 생성할 가능성이 있다. 이는 Action 서브필드에 11 패턴을 사용하여 방지할 수 있다. Change 비트 필드는 데이터 그램이 전달되는 동안 옵션 데이터가 수정될 수 있음을 나타내며, 0과 1로 표현할 수 있다.
2. Routing Header
IPv6 라우팅 헤더는 IPv6 데이터그램의 송신자가 네트워크를 통해 데이터그램이 이동하는 경로를 부분적으로나마 제어할 수 있는 매커니즘을 제공한다. 현재까지 두 가지 유형의 라우팅 확장 헤더가 정의되어 있으며, 각각 RH0, RH2로 불린다. RH0은 보안상의 문제로 인해 더이상 사용되지 않게 되었고 RH2는 Mobile IP와 관련하여 정의되었다.
RH0은 데이터그램이 전달되는 동안 "방문"해야 할 하나 이상의 IPv6 노드를 지정한다.
이 헤더에는 8비트 Routing Type(0) 식별자와 Segments Left 필드가 포함되어있다. IPv6 주소의 경우 RoutingType 식별자는 RH0에서 0, RH2에서 2가 들어간다. Segments Left 필드에는 처리해야 할 경로 세그먼트 수를 나타낸다. 주소 블록은 송신자는 0, 수신자는 무시하는 32비트 0으로 시작한다. 이 블록에 포함된 주소는 데이터그램이 전달되는 동안 방문해야 할 non-multicast IPv6 address들 이다. Routing 헤더는 IPv6 헤더의 Destination IP Address 필드에 포함된 주소와 일치하는 노드에 도착하기 이전에는 처리되지 않는다. 처리될 노드에 도착하면 Segments Left 필드를 사용하여 주소 벡터에서 다음 홉 주소를 결정하고, 이 주소를 IPv6 헤더의 Destination IP Address 필드와 교체한다.
해당 그림에서 Routing 헤더가 중간 노드에 의해 어떻게 처리되는지 확인할 수 있다. 송신자 (S)는 목적지 주소를 R1로 설정하고 R2, R3 그리고 최종 목적지 D를 포함하는 RH0을 가진 데이터그램을 구성한다. Segments Left는 3으로 설정된다. 데이터그램은 S와 R0에 의해 자동으로 R1로 전송된다. R1에 도달하면 DST와 일치하는 IP 주소의 노드에 도착했으므로 R2로 목적지 주소를 고체하고 Segments Left 필드는 1로 감소한다. 이 과정은 DST에 도착할 때까지 반복된다.
RH0은 DoS 공격의 효과를 높이는데 악용될 수 있는 보안 문제 때문에 사용 중단되었다. 문제는 RH0이 Routing 헤더 내에 동일한 주소를 여러 위치에 지정할 수 있도록 허용한다는 점이다. 이로 인해 특정 경로를 따라 두 개 이상의 호스트 또는 라우터 간에 트래픽이 반복적으로 전달될 수 있다. 즉, 특정 경로에 집중적으로 데이터를 몰아버릴 수 있게 된다는 뜻이다. (A->B->A->B->A->B...) 결과적으로, RH0은 사용 중단되었으며, IPv6에서 유일하게 지원하는 Routing 헤더는 RH2로 남게 되었다. RH2는 RH0과 동일하지만, 하나의 주소만 포함할 수 있으며 Routing Type 필드에 다른 값을 이용한다.
3. Fragment Header
Fragment 헤더는 IPv6 송신자가 데이터그램의 최종 목적지까지의 Path MTU보다 큰 데이터그램을 전송할 때 사용된다. IPv4에서는 데이터그램이 다음 홉의 MTU보다 클 경우, 호스트나 라우터가 데이터그램을 단편화할 수 있으며, IPv4 헤더의 두 번째 32비트 워드에 있는 필드가 단편화 정보를 나타낸다. 그러나 IPv6에서는 데이터그램의 송신자만 단편화가 가능하며 이 경우 Fragment 헤더가 추가된다. Fragment Offset 필드는 Fragment 헤더 디에 오는 데이터가 원래 IPv6 데이터그램의 Fragmentable part를 기준으로 8바이트 단위의 양의 오프셋으로 위치를 나타낸 정보를 담는다. M 비트 필드는 값이 1이면 fragment가 뒤에 더 남았다는 뜻이다.
단편화 과정에서 입력으로 사용되는 데이터 그램은 original packet이라고 불리며, 단편화 불가능한 부분, 가능한 부분으로 나뉜다. 단편화 불가능한 부분은 IPv6 헤더와 중간 노드에서 목적지까지 처리해야하는 모든 확장 헤더를 포함한다. 단편화 가능한 부분은 데이터 그램의 나머지 부분이다. (DST OPT, 상위 계층 헤더, 페이로드 데이터)
각 단편의 Length 부분에는 자신의 길이만 들어가게 된다. 또한 단편화 불가능한 부분 뒤에, 적절히 할당된 Fragment Offset 필드를 가진 Fragment 헤더와 원래 패킷의 Identification 필드를 가진다.
송신자는 네트워크에서 데이터그램의 예상 수명 동안 서로 다른 원래 패킷에 동일한 Identification을 할당하지 않아야한다. Fragment 헤더의 Offset 필드는 8바이트 단위로 지정되므로 단편화는 8바이트 경계에서 수행된다. 이 때문에 1, 2번째 단편은 1452 바이트 데신 1448 바이트의 데이터를 포함한다. 따라서 마지막 단편을 제외한 모든 단편은 8바이트 배수로 정렬된다. 이에 따라 Offset은 이전 단편의 몇번째 비트부터 이어서 시작하면 되는지 정보를 담게 된다. (1번째 단편의 Data length가 1448 이었으므로 다음 단편의 Offset은 181이다.)
'Computer Network' 카테고리의 다른 글
| 4. System Configuration: DHCP & Autoconfiguration - 1 (0) | 2025.01.17 |
|---|---|
| 3. The Internet Protocol (IP) - 2 (0) | 2025.01.14 |
| 2. ARP : Address Resolution Protocol (0) | 2024.12.30 |
| 1. Link Layer - 2 (0) | 2024.12.26 |
| 1. Link Layer - 1 (0) | 2024.11.27 |