IPv6 헤더 형식: 구조, 필드 및 확장 헤더

IPv6가 헤더를 변경한 이유#

IPv4의 헤더는 수십 년에 걸쳐 유기적으로 성장했습니다. 옵션이 추가되고, 필드가 재사용되었으며, 결국 14개의 서로 다른 필드(일부 선택 사항)가 있는 가변 길이 헤더와 라우터가 모든 홉에서 신중하게 구문 분석해야 하는 복잡한 구조를 갖게 되었습니다.

IPv6는 다른 접근 방식을 취했습니다: 고정 길이, 단순화, 빠른 포워딩에 최적화. 기본 헤더는 항상 정확히 40바이트이며 8개의 잘 정의된 필드가 있습니다. 가변 길이 옵션 없음, 헤더 체크섬 없음, 메인 헤더에 단편화 필드 없음.

결과는 라우터가 더 빠르게 처리할 수 있고, 하드웨어에서 구현하기 쉬우며, 이전 버전과의 호환성을 깨지 않고 확장을 지원하는 헤더입니다. IPv6 헤더를 이해한다는 것은 왜 이렇게 만들어졌는지, 설계자들이 어떤 절충을 했는지 이해하는 것을 의미합니다.

40바이트 기본 헤더#

모든 IPv6 패킷은 정확히 40바이트로 이 형식으로 시작합니다:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

고정 크기. 기본 헤더에 옵션 없음. 모든 라우터는 구문 분석 없이 각 필드가 정확히 어디에 있는지 알고 있습니다.

8개 필드#

라우터가 일반적으로 처리하는 순서대로 각 필드를 살펴보겠습니다.

1. 버전 (4비트)#

IPv6 패킷의 경우 항상 6. IPv4 패킷의 경우 항상 4. 이것이 장치가 회선에서 IPv6와 IPv4를 구별하는 방법입니다.

실질적 의미: 이중 스택 시스템은 나머지 패킷을 구문 분석하는 방법을 결정하기 위해 먼저 이 4비트를 봅니다.

버전 = 6 (이진: 0110)

간단하고, 변경되지 않으며, 프로토콜 식별에 중요합니다.

2. 트래픽 클래스 (8비트)#

초기 IPv6 사양에서 「Priority」라고 불렸던 이 필드는 서비스 품질(QoS) 처리를 위해 패킷을 표시합니다. IPv4의 서비스 유형(ToS) 또는 차등 서비스 코드 포인트(DSCP)와 동일한 목적을 수행합니다.

구조:

• 비트 0-5: DSCP (차등 서비스 코드 포인트)
• 비트 6-7: ECN (명시적 혼잡 알림)

일반적인 DSCP 값:

ECN은 라우터가 패킷을 드롭하지 않고 혼잡을 신호할 수 있게 합니다. 더 나은 혼잡 제어를 위해 최신 TCP 구현에서 사용됩니다.

예시:

트래픽 클래스 = 46 (EF) = 0b10111000
  DSCP = 46 (Expedited Forwarding)
  ECN = 0 (ECN 비지원)

QoS를 지원하는 라우터는 이 필드를 검사하여 패킷의 우선순위를 지정합니다. VoIP는 파일 다운로드보다 높은 우선순위를 받습니다. 실시간 비디오는 이메일보다 더 나은 처리를 받습니다.

3. 플로우 라벨 (20비트)#

IPv6의 가장 흥미롭지만 활용도가 낮은 기능 중 하나. 플로우 라벨은 동일한 플로우에 속하며 동일한 라우팅 처리를 받아야 하는 패킷을 식별합니다.

목적:

• 상위 계층 헤더를 검사하지 않고 라우터가 관련 패킷을 식별할 수 있도록 허용
• 알려진 플로우에 대한 빠른 경로 전달 지원
• 플로우별 QoS에 대한 핸들 제공

사양 (RFC 6437):

• 값 0: 특별한 처리가 필요한 플로우의 일부가 아닌 패킷
• 값 1-0xFFFFF: 플로우 식별자 (소스에서 무작위로 선택)
• 플로우의 모든 패킷에 대해 일관되어야 함
• 라우터 해싱을 허용하기 위해 의사 무작위여야 함

플로우를 구성하는 것:

• 소스 + 대상 + 플로우 라벨이 고유하게 식별
• TCP 연결의 모든 패킷이 동일한 플로우 라벨을 사용할 수 있음
• 또는 각 비디오 스트림이 고유한 라벨을 받을 수 있음

실제 사용:

많은 구현이 플로우 라벨을 0으로 설정합니다. 그 이유는:

• 플로우 라벨을 기반으로 해시/전달하는 데 필요한 하드웨어가 보편적이지 않음
• 애플리케이션 지원이 제한적
• 선택 사항이며 0이 잘 작동함

그러나 올바르게 사용하면 플로우 라벨은 다음을 가능하게 합니다:

• ECMP(Equal Cost Multi-Path) 경로 간 로드 밸런싱
• 플로우별 트래픽 엔지니어링
• 하드웨어 빠른 경로 전달

플로우 라벨 설정 예시 (Linux):

# 자동 플로우 라벨 활성화
sysctl -w net.ipv6.auto_flowlabels=1
 
# 플로우 라벨은 5-tuple 해시를 기반으로 설정됨

Linux는 활성화되면 소스/대상 주소 및 포트의 해시를 사용하여 TCP 연결에 대한 플로우 라벨을 자동으로 생성합니다.

4. 페이로드 길이 (16비트)#

40바이트 기본 헤더를 제외한 패킷 페이로드의 길이(바이트).

범위: 0 ~ 65,535바이트

중요한 세부 사항:

• 확장 헤더(있는 경우) + 상위 계층 데이터 포함
• 기본 40바이트 IPv6 헤더는 포함하지 않음
• 최대값 65,535는 최대 패킷 크기가 65,575바이트(65,535 + 40)임을 의미

특수 사례: 점보그램

65,535바이트보다 큰 패킷의 경우 페이로드 길이가 0으로 설정되고 점보그램 옵션이 있는 홉별 옵션 확장 헤더가 실제 길이(최대 4,294,967,295바이트)를 전달합니다.

점보그램은 드뭅니다. 일반적으로 10Gbps+ 링크를 통해 점보 프레임 지원이 있는 특수 고성능 네트워크에서 사용됩니다.

예시:

페이로드 길이 = 1440바이트
  40바이트 IPv6 헤더 (계산되지 않음)
  1440바이트 페이로드 (TCP 헤더 + 데이터)
  전체 패킷 = 1480바이트

5. 다음 헤더 (8비트)#

IPv6 헤더 바로 다음에 오는 헤더 유형을 식별합니다. 이것이 확장 헤더와 상위 계층 프로토콜이 지정되는 방법입니다.

일반적인 값:

체인 작동 방식:

각 확장 헤더에는 자체 다음 헤더 필드가 포함되어 체인을 형성합니다:

IPv6 헤더 (다음 헤더 = 0)
  -> 홉별 옵션 (다음 헤더 = 43)
    -> 라우팅 헤더 (다음 헤더 = 6)
      -> TCP 헤더
        -> 데이터

수신 호스트는 전송 프로토콜(TCP/UDP) 또는 데이터에 도달할 때까지 순서대로 헤더를 처리합니다.

확장 헤더 없는 예시:

다음 헤더 = 6 (TCP)
  IPv6 헤더 바로 뒤에 TCP 헤더

확장 헤더가 있는 예시:

다음 헤더 = 44 (단편)
  IPv6 헤더 뒤에 단편 헤더 (다음 헤더 = 6)
    단편 헤더 뒤에 TCP 헤더

6. 홉 제한 (8비트)#

패킷이 폐기되기 전에 남은 라우터 홉 수. 각 라우터는 이를 1씩 감소시킵니다. 0에 도달하면 라우터는 패킷을 드롭하고 ICMPv6 시간 초과 메시지를 보냅니다.

범위: 0-255

이것은 IPv4의 TTL(Time To Live) 필드에 해당하는 IPv6이지만, 이름이 더 정확합니다—시간이 아니라 홉을 계산합니다.

일반적인 초기 값:

다른 값이 핑거프린팅에 중요한 이유:

수신된 패킷의 홉 제한을 보고 소스 OS를 추측할 수 있습니다:

수신된 홉 제한: 56
  56 + 8 홉 = 64 (Linux/BSD일 가능성)
 
수신된 홉 제한: 117
  117 + 11 홉 = 128 (Windows일 가능성)

Traceroute는 홉 제한을 사용:

Traceroute는 증가하는 홉 제한 값으로 패킷을 전송하여 작동합니다:

• 홉 제한 1: 첫 번째 라우터가 시간 초과로 응답
• 홉 제한 2: 두 번째 라우터가 시간 초과로 응답
• 홉 제한 3: 세 번째 라우터가 시간 초과로 응답
• ...대상에 도달할 때까지

보안 고려 사항:

일부 공격은 낮은 홉 제한을 사용하여 IDS/IPS 시스템에 도달하기 전에 패킷이 만료되도록 합니다. 방화벽은 때때로 인바운드 트래픽에 대해 최소 홉 제한 값을 적용합니다.

예시:

홉 제한 = 64
  라우터 1 수신, 63으로 감소, 전달
  라우터 2 수신, 62로 감소, 전달
  ...
  라우터 64 수신, 0으로 감소, 드롭 및 ICMPv6 유형 3 전송

7. 소스 주소 (128비트)#

패킷 발신자의 IPv6 주소. 예외 없이 항상 128비트.

형식: 표준 IPv6 주소 표기법

2001:db8:1234:5678:9abc:def0:1234:5678

특수 고려 사항:

지정되지 않은 주소(::) 는 특정 경우에만 유효합니다:

• 중복 주소 감지(DAD)
• 주소 할당 전 DHCP 요청
• 특정 ICMPv6 메시지

링크 로컬 주소(fe80::/10) 는 유효한 소스 주소이지만 로컬 링크에서만 유효합니다. 라우터는 링크 로컬 소스가 있는 패킷을 전달하지 않습니다.

멀티캐스트 주소는 절대 유효한 소스 주소가 아닙니다. 멀티캐스트 소스가 있는 패킷은 즉시 드롭되어야 합니다.

실제 문제: 소스 주소 선택

호스트에 여러 IPv6 주소가 있는 경우(SLAAC, DHCPv6 및 프라이버시 확장으로 일반적), 소스로 사용할 주소를 선택해야 합니다. RFC 6724는 선택 알고리즘을 정의하며 다음을 선호합니다:

1. 대상과 동일한 주소 범위
2. 더 긴 일치하는 접두사가 있는 주소
3. 사용 중단되지 않은 주소
4. 더 높은 선호도가 있는 주소

8. 대상 주소 (128비트)#

패킷의 의도된 수신자의 IPv6 주소. 소스 주소와 마찬가지로 항상 128비트.

형식: 표준 IPv6 주소 표기법

2001:4860:4860::8888

라우팅 결정:

라우터는 이 필드를 검사하여 패킷을 전달할 위치를 결정합니다. NAT가 주소를 다시 쓸 수 있는 IPv4와 달리 IPv6 대상 주소는 일반적으로 엔드 투 엔드로 변경되지 않습니다.

특수 주소:

루프백(::1) 은 회선의 패킷에 절대 나타나지 않아야 합니다. ::1로의 패킷은 내부적으로 처리됩니다.

멀티캐스트 주소(ff00::/8) 는 패킷이 여러 수신자에게 전달되어야 함을 나타냅니다:

• ff02::1 - 로컬 링크의 모든 노드
• ff02::2 - 로컬 링크의 모든 라우터
• ff02::1:ff00:0/104 - 요청된 노드 멀티캐스트 (이웃 탐색용)

라우팅 헤더 수정:

라우팅 확장 헤더가 있는 경우 중간 노드가 대상 주소를 다르게 처리할 수 있지만 보안 문제로 인해 최신 네트워크에서는 드뭅니다.

IPv6 대 IPv4 헤더 비교#

무엇이 변경되었는지 이해하면 설계 결정을 이해하는 데 도움이 됩니다.

제거된 것과 이유#

헤더 체크섬: IPv4 라우터는 TTL이 변경되기 때문에 모든 홉에서 체크섬을 다시 계산합니다. 이것은 처리 오버헤드를 추가합니다. IPv6는 다음과 같은 이유로 제거합니다:

• 링크 계층(이더넷)에 자체 체크섬이 있음
• 전송 계층(TCP/UDP)에 자체 체크섬이 있음
• 라우터는 패킷 무결성을 확인할 필요가 없음—엔드포인트가 확인

헤더 길이 필드: IPv4는 옵션으로 인해 헤더가 가변 길이이기 때문에 이것이 필요합니다. IPv6의 고정 40바이트 헤더는 이 필드를 불필요하게 만듭니다.

단편화 필드: IPv4는 모든 라우터가 패킷을 단편화할 수 있도록 허용합니다. IPv6는 경로 MTU 탐색을 사용하여 소스가 단편화를 수행하도록 요구합니다. 이것은 복잡성을 엔드포인트로 이동하고 라우터 성능을 향상시킵니다.

옵션: IPv4 옵션은 거의 사용되지 않지만 라우터가 가변 길이 헤더를 구문 분석하도록 강제합니다. IPv6는 옵션을 확장 헤더로 이동하여 기본 헤더를 단순하게 유지합니다.

확장 헤더 설명#

확장 헤더는 기본 헤더를 복잡하게 만들지 않고 기능을 추가하는 IPv6의 방법입니다. IPv6 헤더와 전송 계층(TCP/UDP) 사이에 나타나 체인을 형성합니다.

확장 헤더 작동 방식#

각 확장 헤더에는 체인의 다음 헤더를 가리키는 다음 헤더 필드가 포함됩니다:

+--------+-------+--------+-------+--------+-------+-----+
| IPv6   | NH=0  | 홉별   | NH=43 | 라우팅 | NH=6  | TCP |
| 헤더   |       | 옵션   |       | 헤더   |       |     |
+--------+-------+--------+-------+--------+-------+-----+

호스트는 확장 헤더를 순서대로 처리합니다. 라우터는 일반적으로 홉별 옵션만 처리합니다. 다른 헤더는 대상에서만 검사됩니다.

표준 확장 헤더#

RFC 8200은 여러 확장 헤더가 있을 때 권장 순서를 정의합니다:

1. 홉별 옵션 (0)
2. 대상 옵션 (라우팅 헤더가 있을 때 중간 대상용)
3. 라우팅 (43)
4. 단편 (44)
5. 인증 헤더 (51)
6. 캡슐화 보안 페이로드 (50)
7. 대상 옵션 (60) (최종 대상용)
8. 상위 계층 (TCP=6, UDP=17, ICMPv6=58)

홉별 옵션 헤더 (유형 0)#

경로를 따라 모든 라우터가 검사해야 하는 옵션을 전달합니다.

형식:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  다음 헤더    |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         옵션                                  .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

일반적인 옵션:

Pad1 및 PadN: 정렬을 위한 패딩

라우터 알림 (유형 5): 라우터에게 패킷을 더 자세히 검사하도록 지시. MLD(멀티캐스트 리스너 탐색)와 같은 프로토콜에서 사용.

점보그램 (유형 194): 65,535바이트보다 큰 패킷용.

첫 번째여야 함: 있는 경우 홉별 옵션은 IPv6 헤더 바로 다음에 와야 합니다. RFC 8200은 이 엄격한 순서를 요구합니다.

보안 문제: 많은 라우터가 인식하지 못하는 홉별 헤더가 있는 패킷을 드롭하거나 심하게 속도 제한합니다. 실제로 이 확장 헤더는 특정 프로토콜(MLD, 점보그램) 외부에서는 드뭅니다.

라우팅 헤더 (유형 43)#

최종 대상에 도달하기 전에 패킷이 방문해야 하는 중간 노드를 지정합니다.

형식:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  다음 헤더    |  Hdr Ext Len  | 라우팅 유형   | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                     유형별 데이터                              .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

라우팅 유형:

유형 0 (사용 중단): 원래 느슨한 소스 라우팅. 보안 문제(증폭 공격)로 인해 RFC 5095에 의해 사용 중단.

유형 2: 모바일 IPv6에서 모바일 노드로의 라우팅에 사용. 제한된 사용 사례.

유형 3: SRv6용 세그먼트 라우팅 헤더(SRH). 캐리어 네트워크의 트래픽 엔지니어링 및 서비스 체인을 위한 최신 사용 사례.

보안: 유형 0 라우팅 헤더는 공격자가 임의의 노드를 통해 패킷을 라우팅하여 증폭 공격을 생성할 수 있도록 허용했습니다. 대부분의 네트워크는 유형 0을 드롭합니다. 유형 3(SRv6)는 더 신중하게 설계되었지만 여전히 공용 인터넷에서 보안 문제를 제기합니다.

단편 헤더 (유형 44)#

소스가 경로 MTU에 비해 너무 큰 패킷을 단편화할 때 사용됩니다.

형식:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  다음 헤더    |   예약        |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

필드:

• 다음 헤더: 단편화된 데이터의 프로토콜 (TCP, UDP 등)
• 단편 오프셋: 원래 패킷에서 이 단편의 오프셋 (8바이트 단위)
• M 플래그: 더 많은 단편 (1 = 더 있음, 0 = 마지막 단편)
• 식별: 재조립을 위한 고유 ID (한 패킷의 모든 단편에 대해 동일)

단편화 작동 방식:

1. 소스가 큰 패킷을 전송하려고 시도
2. ICMPv6 패킷 너무 큼 메시지 수신
3. 패킷을 더 작은 조각으로 단편화
4. 각 조각에 단편 헤더 추가
5. 대상이 식별 필드를 기반으로 재조립

예시:

원래 2000바이트 패킷, MTU 1280:

단편 1:
  IPv6 헤더 (40바이트)
  단편 헤더 (8바이트) [M=1, 오프셋=0, ID=12345]
  데이터 (1232바이트)
  전체: 1280바이트
 
단편 2:
  IPv6 헤더 (40바이트)
  단편 헤더 (8바이트) [M=0, 오프셋=154, ID=12345]
  데이터 (768바이트)
  전체: 816바이트

최소 MTU: IPv6는 모든 링크가 최소 1280바이트를 지원하도록 요구합니다. 소스는 준수하는 IPv6 네트워크에서 단편화 없이 1280바이트 패킷을 보낼 수 있습니다.

보안 문제: 단편화는 공격을 가능하게 합니다:

• 겹치는 단편 (IDS에서 페이로드 난독화)
• 단편 플러드 (재조립 리소스 고갈)
• 작은 단편 (처리 시간 낭비)

많은 방화벽은 단편화된 패킷을 드롭하거나 검사 전에 재조립합니다.

대상 옵션 헤더 (유형 60)#

대상 노드 전용 옵션을 전달합니다. 중간 라우터는 처리하지 않습니다.

형식: 홉별 옵션과 동일하지만 대상에서만 검사됩니다.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  다음 헤더    |  Hdr Ext Len  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
.                         옵션                                  .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

사용 사례:

• 정렬을 위한 패딩
• 애플리케이션별 옵션
• 기본 헤더를 변경하지 않고 향후 확장

헤더 체인에 두 번 나타날 수 있습니다:

1. 라우팅 헤더 전 (중간 대상에서 처리)
2. ESP/AH 헤더 후 (최종 대상에서 처리)

인증 헤더 (유형 51) 및 ESP (유형 50)#

인증 및 암호화를 제공하는 IPsec 헤더.

AH (51): 인증 및 무결성을 제공하지만 기밀성은 제공하지 않습니다. ESP가 암호화와 함께 동일한 작업을 수행할 수 있기 때문에 거의 사용되지 않습니다.

ESP (50): 기밀성, 인증 및 무결성을 제공합니다. VPN 및 암호화된 통신의 표준.

IPsec은 헤더 구조를 넘어서는 큰 주제입니다. 핵심 포인트: 이러한 헤더는 IPv4에서 나중에 추가된 IPsec과 달리 처음부터 IPv6 설계의 일부입니다.

확장 헤더 처리#

호스트는 다음을 수행해야 합니다:

• 모든 확장 헤더를 순서대로 처리
• 모든 표준 확장 헤더 지원
• 다음 헤더 값에 따라 알 수 없는 헤더 처리

라우터는 일반적으로:

• 홉별 옵션만 검사
• 처리하지 않고 다른 확장 헤더 전달
• 보안을 위해 특정 헤더가 있는 패킷을 속도 제한하거나 드롭할 수 있음

방화벽 고려 사항:

확장 헤더는 다음과 같은 이유로 방화벽을 복잡하게 만듭니다:

• 전송 헤더(TCP/UDP)가 패킷 깊숙이 있을 수 있음
• 필터링을 위해 포트를 찾으려면 전체 체인을 구문 분석해야 함
• 공격자는 복잡한 헤더 체인으로 페이로드를 난독화할 수 있음

모범 사례:

• 확장 헤더 체인 길이 제한
• 사용 중단된 헤더가 있는 패킷 드롭 (유형 0 라우팅)
• 검사 전에 단편 재조립
• 홉별 옵션이 있는 패킷 속도 제한

체크섬이 없는 이유는?#

IPv4는 라우터가 모든 홉에서 다시 계산해야 하는 헤더 체크섬을 포함합니다(TTL이 변경되기 때문). IPv6는 의도적으로 이것을 생략합니다.

근거:

1. 링크 계층이 이미 체크섬을 수행: 이더넷에는 CRC32가 있습니다. Wi-Fi에는 체크섬이 있습니다. 최신 링크 계층은 신뢰할 수 있습니다.

2. 전송 계층 체크섬: TCP 및 UDP에는 데이터와 헤더를 포함하는 체크섬이 포함됩니다. 어쨌든 엔드 투 엔드 확인이 발생합니다.

3. 라우터 성능: 모든 홉에서 체크섬을 다시 계산하는 것은 CPU 사이클을 낭비합니다. 초당 수십억 개의 패킷을 전달하는 고속 라우터—체크섬 계산을 제거하면 도움이 됩니다.

4. 오류는 드뭅니다: 최신 네트워크는 비트 오류율이 낮습니다. 체크섬은 IPv4가 설계된 1980년대보다 적은 오류를 잡습니다.

손상은 어떻게 됩니까?

IPv6 헤더에서 비트가 뒤집히면:

• 잘못된 대상 주소: 패킷이 잘못된 곳으로 가거나 드롭되고 TCP가 재전송
• 잘못된 홉 제한: 패킷이 일찍 또는 늦게 죽을 수 있음, 한계 영향
• 잘못된 다음 헤더: 대상이 구문 분석할 수 없고 TCP가 누락된 데이터를 감지하고 재전송

엔드 투 엔드 원칙은 엔드포인트가 오류를 감지하고 처리해야 한다고 말합니다. 중간 라우터는 패킷을 빠르게 전달하기만 하면 됩니다.

실질적 의미#

네트워크 엔지니어를 위한#

방화벽 구성:

• 전송 헤더를 찾기 위해 확장 헤더 체인을 구문 분석해야 함
• 남용을 방지하기 위해 체인 깊이를 제한해야 함
• 사용 중단된 헤더 드롭 (유형 0 라우팅)

성능 튜닝:

• 헤더 체크섬이 없다는 것은 하드웨어에서 더 빠른 전달을 의미
• 고정 헤더 크기는 라우터에서 더 나은 파이프라이닝을 가능하게 함
• 확장 헤더는 느린 경로 처리를 트리거할 수 있음

문제 해결:

• tcpdump가 모든 헤더를 표시: tcpdump -i eth0 -vv ip6
• Wireshark가 확장 헤더를 명확하게 구문 분석
• 드롭을 유발하는 예기치 않은 확장 헤더 확인

개발자를 위한#

소켓 프로그래밍:

• IPv6 소켓은 보조 데이터를 통해 확장 헤더를 수신할 수 있음
• 애플리케이션은 확장 헤더를 수동으로 구성할 필요가 거의 없음
• OS가 단편화를 자동으로 처리

패킷 구성:

• QoS에 민감한 애플리케이션(VoIP, 비디오)에 대한 트래픽 클래스 설정
• 더 나은 ECMP 로드 밸런싱을 위해 자동 플로우 라벨 생성 활성화
• 단편화할 수 있다고 가정하지 마십시오—PMTUD를 올바르게 사용

보안:

• 소스 주소 유효성 검사 (멀티캐스트 소스 거부 등)
• 단편화된 패킷을 신중하게 처리하거나 거부
• 미들박스가 확장 헤더를 드롭할 수 있다는 점 인식

시스템 관리자를 위한#

MTU 구성:

• 모든 링크에서 MTU가 최소 1280바이트인지 확인
• 더 큰 MTU는 성능 향상 (1500 표준, 9000 점보 프레임용)
• 방화벽을 통해 ICMPv6 패킷 너무 큼 허용

QoS 설정:

• 트래픽 클래스 표시를 존중하도록 라우터 구성
• 애플리케이션 트래픽을 적절한 DSCP 값에 매핑
• QoS 정책이 올바르게 작동하는지 모니터링

IPsec/VPN:

• AH 및 ESP는 확장 헤더—방화벽이 허용해야 함
• IPsec은 오버헤드를 추가—MTU 계산에서 이를 고려
• 전송 모드 대 터널 모드가 헤더에 미치는 영향 고려

도구로 헤더 검사#

tcpdump#

IPv6 헤더 캡처 및 표시:

# 기본 IPv6 패킷 캡처
sudo tcpdump -i eth0 -n ip6
 
# 모든 헤더 필드를 보여주는 자세한 출력
sudo tcpdump -i eth0 -vv ip6
 
# 확장 헤더가 있는 패킷만 표시
sudo tcpdump -i eth0 -vv 'ip6 and ip6[6] != 6 and ip6[6] != 17 and ip6[6] != 58'
 
# 단편화된 패킷 캡처
sudo tcpdump -i eth0 -n 'ip6 and ip6[6] = 44'

예시 출력:

12:34:56.789012 IP6 2001:db8::10 > 2001:db8::20: DSTOPT (TCP)
  2001:db8::10.54321 > 2001:db8::20.80: Flags [S], seq 123456789, win 65535
 
분석:
- 소스: 2001:db8::10, 포트 54321
- 대상: 2001:db8::20, 포트 80
- 확장 헤더: 대상 옵션 (DSTOPT)
- 전송: TCP SYN

Wireshark#

Wireshark는 자세한 헤더 분석을 제공합니다:

필터:

# 모든 IPv6 트래픽
ipv6
 
# 특정 확장 헤더가 있는 패킷
ipv6.nxt == 0    # 홉별 옵션
ipv6.nxt == 43   # 라우팅
ipv6.nxt == 44   # 단편
ipv6.nxt == 60   # 대상 옵션
 
# 단편화된 패킷
ipv6.fragment
 
# 특정 트래픽 클래스
ipv6.tclass == 46  # Expedited Forwarding

헤더 검사:

1. 패킷 세부 정보에서 「Internet Protocol Version 6」확장
2. 명확하게 레이블이 지정된 모든 8개 필드 보기
3. 확장 헤더가 별도의 레이어로 나타남
4. 필터링을 위해 필드를 마우스 오른쪽 버튼으로 클릭

Scapy (Python)#

프로그래밍 방식으로 IPv6 패킷 빌드 및 분석:

from scapy.all import *
 
# IPv6 패킷 생성
pkt = IPv6(src="2001:db8::10", dst="2001:db8::20", tc=46, fl=12345)
pkt = pkt/TCP(sport=54321, dport=80, flags="S")
 
# 패킷 구조 표시
pkt.show()
 
# 출력:
# ###[ IPv6 ]###
#   version= 6
#   tc= 46
#   fl= 12345
#   plen= None
#   nh= TCP
#   hlim= 64
#   src= 2001:db8::10
#   dst= 2001:db8::20
# ###[ TCP ]###
#   sport= 54321
#   dport= http
 
# 확장 헤더 추가
pkt = IPv6(dst="2001:db8::20")/IPv6ExtHdrDestOpt()/TCP(dport=80)
pkt.show()

일반적인 잘못된 구성#

확장 헤더를 완전히 차단#

문제: 방화벽이 확장 헤더가 있는 모든 패킷을 드롭합니다.

영향:

• 단편화가 작동하지 않음 (유형 44 차단)
• IPsec VPN 실패 (유형 50/51 차단)
• 일부 합법적인 트래픽 드롭

해결: 필요한 헤더 허용 (단편, AH, ESP), 사용 중단된 헤더 차단 (유형 0 라우팅).

# iptables: 단편 허용, 유형 0 라우팅 드롭
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

트래픽 클래스 무시#

문제: QoS 없이 구성된 라우터, 모든 패킷이 최선 노력 처리를 받습니다.

영향:

• VoIP 품질 저하
• 비디오 스트림 버퍼링
• 시간에 민감한 트래픽이 대량 전송과 경쟁

해결: 트래픽 클래스/DSCP를 기반으로 QoS 정책 구성.

! Cisco IOS 예시
class-map match-any VOICE
  match dscp ef
!
policy-map WAN-QOS
  class VOICE
    priority percent 20
  class class-default
    fair-queue
!
interface GigabitEthernet0/1
  service-policy output WAN-QOS

MTU 불일치#

문제: MTU < 1280인 링크 또는 ICMPv6 패킷 너무 큼을 차단하는 방화벽.

영향:

• 연결이 중단됨
• 대량 전송 실패
• PMTUD가 작동하지 않음

해결: 모든 곳에서 최소 1280 MTU 확인, ICMPv6 유형 2 허용.

# MTU 설정
ip link set dev eth0 mtu 1500
 
# 확인
ip -6 link show eth0
 
# 패킷 너무 큼 허용
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

관련 문서#

• IPv6 기초 - 헤더를 자세히 살펴보기 전에 기본 IPv6 주소 지정 및 개념을 이해합니다.
• ICMPv6 설명 - 다음 헤더 값 58을 사용하고 IPv6에 중요한 ICMPv6에 대해 알아봅니다.
• IPv6 방화벽 구성 - IPv6 헤더와 확장 헤더를 올바르게 처리하도록 방화벽을 구성합니다.

자주 묻는 질문#