IPv6 패킷

3. 확장 헤더

IPv6 패킷은 필요에 따라 다양한 기능을 제공하는 확장 헤더를 포함할 수 있다. 확장 헤더는 고정 헤더와 상위 계층 프로토콜 헤더 사이에 위치하며, "다음 헤더" 필드를 통해 연결된다. 고정 헤더의 "다음 헤더" 필드는 첫 번째 확장 헤더의 유형을 나타내고, 마지막 확장 헤더의 "다음 헤더" 필드는 패킷 페이로드 내의 상위 계층 프로토콜 헤더 유형을 나타낸다. 모든 확장 헤더는 8옥텟의 배수 크기를 가지며, 일부는 이 요구 사항을 충족하기 위해 내부 패딩을 사용한다.

여러 확장 헤더가 정의되어 있으며, 앞으로 새로운 확장 헤더가 정의될 수 있다. 대부분의 확장 헤더는 패킷의 목적지에서 검사 및 처리된다. "홉 바이 홉 옵션"은 중간 노드에서 처리 및 수정될 수 있으며, 존재하는 경우 가장 먼저 와야 한다. 모든 확장 헤더는 선택 사항이며, "목적지 옵션" 헤더(두 번 나타날 수 있음)를 제외하고 최대 한 번 나타날 수 있다.

노드가 특정 확장 헤더를 인식하지 못하면 패킷을 폐기하고 "매개변수 문제" 메시지(ICMPv6 유형 4, 코드 1)를 보내야 한다.

다음은 정의된 확장 헤더와 그 "다음 헤더" 필드 값, 그리고 간략한 설명이다. (고정 헤더 다음에 둘 이상의 확장 헤더가 있는 경우 선호하는 순서)

다음 헤더 필드의 값 59(다음 헤더 없음)는 이 헤더 다음에 상위 계층 프로토콜의 헤더를 포함하여 어떠한 다음 헤더도 없음을 나타낸다. 즉, IPv6 패킷이 해당 헤더에서 바로 끝난다는 것을 의미한다. 페이로드 길이는 비어 있어야 한다. 그러나 패킷의 첫 번째 헤더의 페이로드 길이가 모든 확장 헤더의 길이보다 크면, 페이로드에 여전히 데이터가 있을 수 있다. 이 데이터는 호스트에서 무시해야 하지만, 라우터에서 변경되지 않고 전달되어야 한다.

3. 1. 홉 바이 홉 옵션 (Hop-by-Hop Options)

• 다음 헤더 (8비트): 다음 헤더의 유형을 지정한다.
• 확장 헤더 길이 (8비트): 첫 번째 8옥텟을 제외한 8옥텟 단위로 표시되는 이 헤더의 크기이다.
• 옵션 (가변): 하나 이상의 옵션과 옵션을 정돈하고 헤더 길이를 8옥텟의 배수로 만들기 위한 패딩을 포함한다. 옵션은 TLV 형식이다.

3. 2. 목적지 옵션 (Destination Options)

; '''다음 헤더''' (8비트): 다음 헤더의 유형을 지정한다.

; '''확장 헤더 길이''' (8비트): 첫 번째 8옥텟을 제외한 8옥텟 단위로 표시되는 이 헤더의 크기.

; '''옵션''' (가변): 하나 이상의 옵션과 옵션을 정돈하고 헤더 길이를 8옥텟의 배수로 만들기 위한 패딩을 포함한다. 옵션은 TLV 형식이다.

3. 3. 라우팅 (Routing)

• 다음 헤더 (8비트): 다음 헤더의 유형을 나타낸다.
• 확장 헤더 길이 (8비트): 첫 번째 8옥텟을 제외하고, 8옥텟 단위로 표시된 이 헤더의 크기다.
• 라우팅 유형 (8비트): IANA에서 할당한 0부터 255까지의 값이다.^[2]
• 남은 세그먼트 (8비트): 패킷이 최종 목적지에 도달하기 전에 방문해야 하는 노드의 수다.
• 유형별 데이터 (가변): 이 유형의 라우팅 헤더에 속하는 데이터다.

3. 4. 단편화 (Fragment)

• '''다음 헤더''' (8비트): 다음 헤더의 타입을 나타낸다.
• '''예약''' (8비트/2비트): 0으로 고정되어 있다.
• '''프래그먼트 오프셋''' (13비트): 원래 패킷의 단편화 가능한 부분의 시작 부분과 관련된 8옥텟 단위의 오프셋이다.
• '''M 플래그''' (1비트): 1은 추가 프래그먼트가 있음을 의미하며, 0은 이것이 마지막 프래그먼트임을 의미한다.
• '''식별 값''' (32비트): 송신 노드에 의해 생성되는 패킷 식별 번호. 원래 패킷의 재구성에 필요하다.

3. 5. 인증 헤더 (Authentication Header, AH)

3. 6. 캡슐화 보안 페이로드 (Encapsulating Security Payload, ESP)

4. 페이로드 (Payload)

IPv6 패킷의 페이로드는 TCP 세그먼트나 UDP 데이터그램과 같이 상위 계층 프로토콜에서 제공하는 데이터를 포함한다. 마지막 IPv6 헤더의 ''다음 헤더'' 필드는 이 페이로드의 유형을 나타낸다.^[1]

4. 1. 표준 페이로드 길이

4. 2. 점보그램 (Jumbogram)

5. 단편화 (Fragmentation)

IPv6에서 라우터는 IPv4와 달리 패킷을 단편화하지 않는다. 대신, 목적지 링크의 최대 전송 단위(MTU)를 초과하는 패킷은 삭제되고, 송신 노드에게 ''Packet too big'' ICMPv6 메시지를 통해 이 사실을 알린다.^[4] 이는 IPv4에서 ''분할 금지'' 비트가 설정된 경우와 유사하다.

IPv6의 최종 노드는 경로 MTU 탐색을 수행하여 전송할 패킷의 최대 크기를 결정해야 한다. 또는 상위 계층 프로토콜이 페이로드 크기를 제한해야 한다. 만약 상위 계층 프로토콜이 페이로드 크기를 제한할 수 없는 경우, 송신 호스트는 ''Fragment'' 확장 헤더를 사용하여 종단 간 단편화를 수행할 수 있다.

IPv6 데이터를 전송하는 모든 데이터 링크 계층은 단편화를 거치지 않고도 최대 1,280 바이트의 IP 패킷을 전송할 수 있어야 한다. 따라서 전송 엔드포인트는 패킷 크기를 1,280 바이트로 제한하여 단편화 또는 경로 MTU 탐색을 피할 수 있다.

5. 1. 단편화 과정

• 첫 번째 조각: 조각별 헤더, 0 Offset을 포함하는 ''Fragment'' 확장 헤더, 나머지 원래 확장 헤더, 원래 상위 계층 헤더(또는 ESP 헤더), 그리고 원래 페이로드의 일부로 구성된다.
• 후속 조각: 조각별 헤더, ''Fragment'' 확장 헤더, Fragment Offset으로 식별되는 원래 페이로드의 일부로 구성된다.

• 라우팅, 홉-바이-홉 헤더 모두 없음: 조각별 부분은 고정 헤더만 포함.
• 라우팅 헤더 존재: 조각별 헤더는 고정 헤더와 ''라우팅(Routing)'' 헤더를 포함한 모든 확장 헤더를 포함.
• 홉-바이-홉 헤더 존재: 조각별 헤더는 고정 헤더와 ''홉-바이-홉(Hop-by-Hop)'' 확장 헤더만 포함.

5. 2. 재조립 과정

6. 보안 (Security)

연구에 따르면 단편화를 활용하여 네트워크 보안 제어를 우회할 수 있는 것으로 나타났다. 그 결과, 2014년에는 매우 병적인 단편화 사례를 피하기 위해 첫 번째 조각을 넘어 IPv6 헤더 체인을 오버플로하는 이전 허용이 금지되었다.^[23] 또한, 라우터 광고(RA) 가드 회피에 대한 연구 결과^[24], 이웃 탐색을 사용한 단편화는 더 이상 사용되지 않으며, 보안 이웃 탐색(SEND)을 사용한 단편화는 권장되지 않는다.^[25]

참조

_[1] 문서 Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks http://tools.ietf.or[...]
_[2] 웹사이트 Internet Protocol Version 6 (IPv6) Parameters: Routing Types https://www.iana.org[...] IANA 2021-10-15
_[3] 웹사이트 IPv6 Routing Header Security http://www.secdev.or[...] EADS 2010-12-03
_[4] 간행물 Internet Protocol, version 6 (IPv6) Specification "//tools.ietf.org/ht[...] "[[Internet Engineering Task Force" 1998-12
_[5] IETF Definition of the Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers 1998-12
_[6] IETF New Terminology and Clarifications for DiffServ 2002-04
_[7] IETF Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers Network Working Group 2006-11
_[8] IETF The Addition of Explicit Congestion Notification (ECN) to IP 2001-09
_[9] IETF Textual Conventions for IPv6 Flow Label 2003-09
_[10] IETF IPv6 Flow Label Specification 2011-11
_[11] IETF IPv6 Jumbograms 1999-08
_[12] IETF Technical Criteria for Choosing IP The Next Generation (IPng) 1994-12
_[13] IETF Host Identity Protocol Version 2 (HIPv2) "[[Internet Engineering Task Force" 2015-04
_[14] IETF Shim6: Level 3 Multihoming Shim Protocol for IPv6 Networking Working Group 2009-06
_[15] IETF Assigning Experimental and Testing Numbers Considered Useful Network Working Group 2004-01
_[16] 웹사이트 Internet Protocol Version 6 (IPv6) Parameters: Routing Types https://www.iana.org[...] IANA 2017-11-17
_[17] 웹사이트 IPv6 Routing Header Security http://www.secdev.or[...] EADS 2010-12-03
_[18] IETF Deprecation of Type 0 Routing Headers in IPv6 2007-12
_[19] IETF The Nimrod Routing Architecture 1996-08
_[20] IETF An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) "[[Internet Engineering Task Force" 2012-03
_[21] IETF IP Authentication Header 2005-12
_[22] IETF IP Encapsulating Security Payload 2005-12
_[23] IETF Implications of Oversized IPv6 Header Chains 2014-01
_[24] IETF Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) 2014-02
_[25] IETF Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery 2013-08