IPv6 패킷

IPv6 packet

IPv6 패킷은 인터넷 프로토콜 버전 6(IPv6)을 사용하여 교환되는 가장 작은 메시지 엔티티다. 패킷은 주소 지정 및 라우팅을 위한 제어 정보와 사용자 데이터의 페이로드로 구성된다. IPv6 패킷의 제어 정보는 필수 고정 헤더와 옵션 확장 헤더로 세분된다. IPv6 패킷의 페이로드(payload)는 일반적으로 상위 전송 계층 프로토콜의 데이터그램 또는 세그먼트이지만 대신 인터넷 계층(예: ICMPv6) 또는 링크 계층(예: OSPF)을 위한 데이터일 수 있다.

IPv6 패킷은 일반적으로 각 패킷을 프레임으로 캡슐화하는 링크 계층(즉, 이더넷 또는 Wi-Fi)을 통해 전송된다. 패킷은 또한 6to4 또는 Teredo 전환 기술을 사용할 때 IPv4와 같은 상위 계층 터널링 프로토콜을 통해 전송될 수 있다.

IPv4와 대조적으로 라우터는 최대 전송 단위(MTU)보다 큰 IPv6 패킷을 분할하지 않으며, 이는 원래 노드의 단독 책임이다. IPv6에서 최소 MTU 1,280 옥텟을 의무화하지만, 최소값보다 큰 MTU를 활용하기 위해 Path MTU Discovery를 사용하는 호스트를 "강력하게 권장"한다.[1]

2017년 7월부터 IANA(Internet Assigned Numbers Authority)는 IPv6 패킷 헤더에서 사용되는 모든 IPv6 파라미터를 등록하는 책임을 맡고 있다.[1]

고정 헤더

고정 헤더는 IPv6 패킷을 시작하고 크기가 40 옥텟(320비트)이다.[1]

고정 헤더 형식
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 버전 트래픽 클래스 흐름 레이블
4 32 페이로드 길이 다음 헤더 홉 한계
8 64 소스 주소
12 96
16 128
20 160
24 192 목적지 주소
28 224
32 256
36 288
버전(4비트)
상수 6(비트 시퀀스 )
트래픽 클래스(6+2비트)
이 필드의 비트는 두 개의 값을 가지고 있다. 가장 중요한 6개의 비트에는 패킷 분류에 사용되는 차별화된 서비스 필드(DS 필드)가 있다.[2][3] 현재 모든 표준 DS 필드는 '0' 비트로 끝난다. 두 개의 '1' 비트로 끝나는 DS 필드는 국부적 또는 실험적으로 사용하기 위한 것이다.[4]
나머지 2비트는 명시적 정체 알림(ECN)에 사용된다.[5] 우선 순위 값은 소스가 정체 제어를 제공하는 트래픽과 비혼합 제어 트래픽으로 세분된다.
흐름 레이블(20비트)
소스와 대상 사이의 패킷 흐름을 나타내는 고엔트로피 식별자. 흐름은 패킷 그룹(예: TCP 세션 또는 미디어 스트림)이다. 특수 흐름 라벨 0은 패킷이 어떤 흐름에도 속하지 않음을 의미한다(이 방법을 사용). 이전 계획은 소스 주소와 포트, 대상 주소와 포트, 프로토콜(마지막 Next Header 필드의 값)별로 흐름을 식별한다.[6] 또한 스푸핑된 패킷을 감지하는 데 흐름 라벨을 사용할 것을 제안했다.[7]
페이로드 길이(16비트)
확장 헤더를 포함하여 8진수 단위의 페이로드 크기. 이 길이는 Hop-by-Hop 확장 헤더가 점보 페이로드 옵션을 전송할 때 0으로 설정된다.[8]
다음 헤더(8비트)
다음 헤더의 유형을 지정하십시오. 이 필드는 일반적으로 패킷의 페이로드에 의해 사용되는 전송 계층 프로토콜을 지정한다. 패킷에 확장 헤더가 있을 때 이 필드는 어떤 확장 헤더를 따르는지 나타낸다. 이 값은 두 필드의 기능이 동일하기 때문에 IPv4 프로토콜 필드에 사용되는 값과 공유된다(IP 프로토콜 번호 목록 참조).
Hop 제한(8비트)
IPv4에서 라이브 필드까지의 시간 대체. 이 값은 각 포워딩 노드에서 하나씩 감소하고 패킷이 0이 되면 폐기된다. 그러나 대상 노드는 홉 제한 0으로 수신되더라도 패킷을 정상적으로 처리해야 한다.
소스 주소(128비트)
송신 노드의 유니캐스트 IPv6 주소.
대상 주소(128비트)
대상 노드의 IPv6 유니캐스트 또는 멀티캐스트 주소.

성능을 높이기 위해, 그리고 현재의 링크 계층 기술과 전송 계층 프로토콜은 충분한 오류 감지를 제공하는 것으로 가정되기 때문에, 헤더에는 그것을 보호할 체크섬이 없다.[9][1]

확장 헤더

확장 헤더는 선택적 인터넷 계층 정보를 운반하며 고정 헤더와 상위 계층 프로토콜 헤더 사이에 배치된다.[1] 확장 헤더는 다음 헤더 필드를 사용하여 체인을 형성한다. 고정 헤더에서 다음 헤더 필드는 첫 번째 확장 헤더 유형을 나타내고, 마지막 확장 헤더에서 다음 헤더 필드는 패킷 페이로드에서 상위 계층 프로토콜 헤더 유형을 나타낸다. 모든 확장 헤더는 크기가 8옥텟의 배수이며, 일부 확장 헤더에는 이 요구 사항을 충족하기 위해 내부 패딩이 필요하다.

몇 개의 확장 헤더가 정의되어 있으며, 향후 새로운 확장 헤더가 정의될 수 있다. 대부분의 확장 헤더는 패킷의 대상에서 검사되고 처리된다. Hop-by-Hop 옵션은 중간 노드에서 처리 및 수정할 수 있으며, 있는 경우 첫 번째 확장자여야 한다. 모든 확장 헤더는 선택 사항이며, 두 번 나타날 수 있는 대상 옵션 헤더 확장을 제외하고 최대 한 번만 표시되어야 한다.[1]

노드가 특정 확장 헤더를 인식하지 못하면 패킷을 삭제하고 매개 변수 문제 메시지(ICMPv6 유형 4, 코드 1)를 전송해야 한다.[1]

아래 정의된 확장 헤더는 고정 헤더 다음에 둘 이상의 확장 헤더가 있는 경우에 대해 선호하는 순서로 나열되어 있다.

확장 헤더 다음 헤더 필드 값 설명
홉 바이 홉 옵션 0 경로의 모든 장치에서 검사해야 하는 옵션
라우팅 43 데이터그램의 경로를 지정하는 방법(Mobile IPv6과 함께 사용)
파편 44 데이터그램 조각화를 위한 매개 변수 포함
인증 헤더(AH) 51 패킷의 대부분의 부분의 신뢰성을 확인하는 데 사용되는 정보 포함
보안 페이로드(ESP) 캡슐화 50 안전한 통신을 위해 암호화된 데이터 전송
대상 옵션(상층 헤더 이전) 60 패킷의 대상만 검사해야 하는 옵션
이동성(현재 상위 계층 헤더 미포함 135 Mobile IPv6에 사용되는 매개 변수
호스트 ID 프로토콜 139 호스트 ID 프로토콜 버전 2(HIPv2)[10]에 사용
심6 의정서 140 심6에[11] 사용
예약됨 253 실험 및 테스트에[12][4] 사용됨
예약됨 254 실험 및 테스트에[12][4] 사용됨

Next Header 필드의 Value 59 (No Next Header)는 상층 프로토콜의 헤더도 아니고 이 헤더에 따르는 다음 헤더가 전혀 없음을 나타낸다. 헤더의 관점에서 보면 IPv6 패킷은 그 직후 종료된다는 뜻인데, 페이로드는 비어 있어야 한다. 그러나 패킷의 첫 번째 헤더에 있는 페이로드 길이가 패킷의 모든 확장 헤더 길이보다 클 경우 페이로드에는 여전히 데이터가 있을 수 있다. 이 데이터는 호스트에서 무시되어야 하지만 라우터에 의해 변경되지 않고 전달되어야 한다.[1]: 4.7

홉 바이 홉 옵션 및 대상 옵션

Hop-by-Hop Options 확장 헤더는 송신 및 수신 노드를 포함하여 패킷 경로의 모든 노드에 의해 검사 및 변경될 수 있다. (인증의 경우 경로에 따라 변경될 수 있는 옵션 값은 무시된다.) Destination Options 확장 헤더는 대상 노드만 검사하면 된다. 확장 헤더는 둘 다 최소 8옥텟이며, 해당 공간에 맞는 것보다 더 많은 옵션이 있는 경우 모든 옵션이 표시될 때까지 8옥텟의 블록이 헤더에 반복적으로 추가된다.

Hop-by-Hop 옵션 및 대상 옵션 확장 헤더 형식
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 다음 헤더 헤더 확장 길이 옵션 및 패딩
4 32 옵션 및 패딩
8 64 옵션: 추가 옵션 및 패딩
12 96
다음 헤더(8비트)
다음 헤더의 유형을 지정하십시오.
헤더 확장 길이(8비트)
이 헤더의 길이는 처음 8옥텟을 포함하지 않고 8옥텟 단위로 표시된다.
옵션 및 패딩(변수)
옵션을 정렬하고 전체 머리글 길이를 8옥텟의 배수로 만들기 위한 하나 이상의 옵션 및 선택적 패딩 필드가 포함되어 있다. 옵션은 TLV 코드화된다.

라우팅

라우팅 확장 헤더는 패킷을 대상으로 전송되기 전에 패킷을 하나 이상의 중간 노드로 전달하는 데 사용된다. 헤더 크기는 최소 8 옥텟이며, 4 옥텟에 맞는 것보다 더 많은 유형별 데이터가 필요한 경우, 모든 유형별 데이터가 배치될 때까지 8 옥텟의 블록을 헤더에 반복적으로 추가한다.[1]

라우팅 확장 헤더 형식
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 다음 헤더 헤더 확장 길이 라우팅 유형 왼쪽 세그먼트
4 32 유형별 데이터
8 64 선택 사항: 추가 유형별 데이터...
12 96
다음 헤더(8비트)
다음 헤더의 유형을 나타낸다.
헤더 확장 길이(8비트)
처음 8개의 옥텟을 포함하지 않고 8개의 옥텟의 배수인 이 헤더의 길이.
라우팅 유형(8비트)
IANA가 할당한 0에서 255 사이의 값.[13]
유형 상태 댓글
0 사용되지 않음 라우팅 헤더 유형 0에서는 간단하지만 효과적인 서비스 거부 공격이 실행될 수 있기 때문에,[14] 이 헤더는 2007년에 더 이상 사용되지 않으며 호스트와 라우터는 이러한 헤더를 무시해야 한다.[15]
1 사용되지 않음 DARPA가 후원하는 님로드 프로젝트에[16] 사용됨. 그것은 2009년에 더 이상 사용되지 않았다.
2 허용된 타입 0의 한정된 버전으로, 모바일 노드의 홈 어드레스를 보유할 수 있는 Mobile IPv6에 사용된다.
3 허용된 저전력 및 소실 네트워크를 위한 RPL 소스 경로 헤더[17].
4 허용된 세그먼트 라우팅 헤더(SRH)[18]
253 사적 사용 실제 구현이 아닌 테스트에 사용될 수 있음. RFC3692 스타일의 실험 1.[12]
254 사적 사용 실제 구현이 아닌 테스트에 사용될 수 있음. RFC3692 스타일의 실험 2.[12]
왼쪽 세그먼트(8비트)
최종 대상에 도달하기 전에 이 패킷이 여전히 방문해야 하는 노드 수입니다.
유형별 데이터(변수)
이 유형의 라우팅 헤더에 속하는 데이터.

파편

경로 MTU보다 큰 패킷을 보내기 위해 송신 노드는 패킷을 조각으로 분할한다. 파편 확장 헤더는 원본(파쇄되지 않은) 패킷을 재조립하는 데 필요한 정보를 담고 있다.[1]

조각 확장 헤더 형식
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 다음 헤더 예약됨 조각 간격띄우기 레스 M
4 32 식별
다음 헤더(8비트)
다음 헤더의 유형을 식별한다.
예약(8비트)
모든 0으로 초기화됨.
조각 오프셋(13비트)
원본 패킷의 단편적인 부분의 시작에 상대적인 오프셋(8-octet 단위.
Res(2비트)
예약됨, 0으로 초기화됨.
M 플래그(1비트)
1은 더 많은 파편이 뒤따른다는 뜻이고, 0은 마지막 파편을 의미한다.
식별(32비트)
소스 노드에서 생성된 패킷 식별 값. 원본 패킷의 재조립에 필요.

인증 헤더(AH) 및 ESP(Encapsulation Security Payload(ESP)

Authentication Header 및 Encapsulating Security Payload는 IPsec의 일부로서 IPv6과 IPv4에서 동일하게 사용된다.[19][20]

페이로드

고정된 IPv6 헤더와 옵션인 IPv6 헤더는 TCP 세그먼트 또는 UDP 데이터그램과 같이 전송 계층에서 제공하는 데이터인 상위 계층 페이로드 다음에 온다. 마지막 IPv6 헤더의 Next Header 필드는 이 패킷에 포함된 페이로드 유형을 나타낸다.

표준 페이로드 길이

IPv6(및 IPv4)의 페이로드 길이 필드는 16비트의 크기를 가지며, 페이로드에 대해 최대 길이 65535 옥텟을 지정할 수 있다. 실제로 호스트는 패킷을 분할할 필요가 없도록 경로 MTU 검색(보낸 사람에서 수신자까지의 경로를 따라 최소 MTU 확보)을 사용하여 사용 가능한 최대 페이로드 길이를 결정한다. 대부분의 링크 계층 프로토콜은 65535 옥텟보다 상당히 작은 MTU를 가진다.

점보그램

IPv6의 선택적 기능인 Hop-By-Hop 옵션 확장 헤더의 점보 페이로드 옵션은 32비트 길이 필드를 사용하여 최대 1 옥텟(232 - 1 = 4294967295 옥텟) 미만의 페이로드로 패킷을 교환할 수 있다.[8] 그러한 페이로드의 패킷은 점보그램이라고 불린다.

TCP와 UDP 모두 16비트(길이, 긴급 데이터 포인터)로 제한된 필드를 포함하므로 IPv6 점보그램에 대한 지원은 전송 계층 프로토콜 구현을 수정해야 한다.[8] 점보그램은 MTU가 65583 옥텟(페이로드의 경우 65535 옥텟 이상, 고정 헤더의 경우 40 옥텟 이상, Hop-by-Hop 확장 헤더의 경우 8 옥텟)보다 큰 링크에만 관련된다. 65535 옥텟보다 큰 패킷을 처리할 수 있는 링크 계층 프로토콜은 거의 없다.[citation needed]

단편화

IPv4와 달리 IPv6 라우터는 IPv6 패킷을 분할하지 않는다. 대상 링크의 최대 전송 단위(MTU) 크기를 초과하는 패킷은 삭제되며, 이 상태는 Don't Fragment 비트가 설정된 IPv4 방법과 유사하게 원본 노드에 대한 Packet too big ICMPv6 메시지에 의해 신호된다.[1] IPv6의 엔드 노드는 전송할 패킷의 최대 크기를 결정하기 위해 경로 MTU 검색을 수행할 것으로 예상되며, 상위 계층 프로토콜은 페이로드 크기를 제한할 것으로 예상된다. 상위계층 프로토콜이 그렇게 할 수 없는 경우, 송신 호스트는 대신 Fragment 확장 헤더를 사용할 수 있다.

IPv6 데이터를 전달하는 데이터 링크 계층은 최대 1,280바이트를 포함하는 IP 패킷을 전송할 수 있어야 하므로 송신 끝점은 패킷을 1,280바이트로 제한하고 조각화 또는 경로 MTU 검색의 필요성을 피할 수 있다.

조각

원본(더 큰) 패킷의 첫 번째 파편을 포함하는 패킷은 조각당 헤더(각 파편에서 반복적으로 사용되는 중요한 원본 헤더)의 다섯 부분으로 구성되며, 그 다음에 0 Offset을 포함하는 파편 확장 헤더, 그 다음에 나머지 모든 원본 확장 헤더, 그 다음에 원래의 상위 계층 헤더로 구성된다.대체적으로 ESP 헤더) 및 원래 페이로드의 일부.[1] 각각의 후속 패킷은 조각당 헤더와 조각 확장 헤더, 그리고 조각 간격띄우기로 식별된 원래 페이로드의 일부의 세 부분으로 구성된다.

장애별 헤더는 원본에 라우팅 또는 Hop-by-Hop 확장 헤더가 포함되어 있는지 여부에 따라 결정된다. 둘 다 존재하지 않는 경우, 골격당 부분은 고정 헤더일 뿐이다. 라우팅 확장 헤더가 존재하는 경우, 장애별 헤더에는 고정 헤더와 라우팅 헤더를 포함한 모든 확장 헤더가 포함된다. Hop-by-Hop 확장 헤더가 있는 경우, 장애별 헤더는 고정 헤더와 Hop-by-Hop 확장 헤더로만 구성된다.

어떤 경우든, 파편당 부품의 마지막 헤더에는 파편 확장 헤더가 뒤따른다는 것을 나타내기 위해 설정된 Next Header 값이 있다. 각 파편 확장 헤더에는 (더 많은 파편이 뒤따른다는 것을 나타냄)로 설정된 M 플래그가 있으며, 마지막 파편을 제외한 각 파편 길이는 8 옥텟의 배수로 되어 있다.

조각별 헤더는 역사적으로 2014년 이전 헤더의 나머지 부분을 조각낼 수 있는 가능성을 언급하면서 "조각 낼 수 없는 부분"이라고 불렸다. 이제 어떤 머리글도 실제로 쪼개질 수 없다.[21]

재조립

원본 패킷은 모든 파편을 수집하여 각 파편을 표시된 오프셋에 배치하고, 파편을 운반한 패킷의 파편 확장 헤더를 폐기하여 수신 노드에 의해 재조립된다. 조각이 포함된 패킷은 순차적으로 도착할 필요가 없으며, 수신 노드에 의해 재배열될 것이다.

파편과 함께 첫 번째 패킷을 받은 후 60초 이내에 모든 파편이 수신되지 않으면 원래의 패킷의 재조립은 폐기되고 모든 파편이 폐기된다. 첫 번째 조각(고정 헤더를 포함)이 수신되고 하나 이상의 조각이 누락된 경우, 시간 초과 메시지(ICMPv6 유형 3, 코드 1)가 조각난 패킷을 발생시키는 노드로 반환된다.

재조립 노드가 다른 파편과 겹치는 파편을 감지하면 원래 패킷의 재조립이 중단되고 모든 파편이 삭제된다. 노드는 정확한 중복을 서로 겹치는 것으로 취급하는 대신 선택적으로 파편의 정확한 중복을 무시할 수 있다.[1]

수신 호스트는 재조립 후 최대 1500바이트를 포함하는 단편화된 IP 데이터그램을 재조립하기 위한 최선의 시도를 해야 한다. 호스트는 조각난 데이터그램을 1,500바이트보다 크게 재조립할 수 있도록 허용되지만, 재조립된 패킷이 1,500바이트보다 클 것이 명백해진 후에는 데이터그램을 자동으로 폐기할 수도 있다. 따라서 송신자는 수신자가 그러한 큰 데이터그램을 재조립할 수 있다는 사실을 알고 있지 않는 한, 총 재조립된 크기가 1,500바이트 이상인 단편화된 IP 데이터그램의 전송을 피해야 한다.

보안

네트워크 보안 제어를 회피하기 위해 단편화를 이용할 수 있다는 연구 결과가 나왔다. 그 결과, 2014년에는 매우 병적인 단편화 사례를 피하기 위해 첫 번째 파편을 넘어 IPv6 헤더 체인에 대한 초과 허용이 금지되었다.[21] 또한, 라우터 광고 가드의 회피에 관한 연구 결과, 인접 검색에 의한 단편화의 사용이 금지되고, SEND(Secure Neighbor Discovery)에 의한 단편화의 사용이 금지된다.[22][23]

참조

  1. ^ a b c d e f g h i j k l m S. Deering; R. Hinden (July 2017). Internet Protocol, Version 6 (IPv6) Specification. IETF. doi:10.17487/RFC8200. STD 86. RFC 8200. Obsoletes RFC 2460.
  2. ^ K. Nichols; S. Blake; F. Baker; D. Black (December 1998). Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. Network Working Group. doi:10.17487/RFC2474. RFC 2474. Obsoletes RFC 1455와 1349. RFC 3168, 3260 및 8436에 의해 업데이트됨.
  3. ^ D. Grossman (April 2002). New Terminology and Clarifications for DiffServ. doi:10.17487/RFC3260. RFC 3260. RFC 2474, 2475 및 2597 업데이트.
  4. ^ a b c B. Fenner (November 2006). Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. Network Working Group. doi:10.17487/RFC4727. RFC 4727.
  5. ^ K. Ramakrishnan; S. Floyd; D. Black (September 2001). The Addition of Explicit Congestion Notification (ECN) to IP. Network Working Group. doi:10.17487/RFC3168. RFC 3168. Obsoletes RFC 2481. RFC 2474, 2401 및 793 업데이트 RFC 4301, 6040 및 8311에 의해 업데이트됨.
  6. ^ S. Amante; B. Carpenter; S. Jiang; J. Rajahalme (November 2011). IPv6 Flow Label Specification. IETF. doi:10.17487/RFC6437. ISSN 2070-1721. RFC 6437. Obsoletes RFC 3697. RFC 2205 및 2460 업데이트
  7. ^ 오프패스 스푸핑 공격으로부터 방어하기 위해 IPv6 플로우 레이블을 전송 계층 노이스로 사용
  8. ^ a b c D. Borman; S. Deering; R. Hinden (August 1999). IPv6 Jumbograms. Network Working Group. doi:10.17487/RFC2675. RFC 2675. Obsoletes RFC 2147.
  9. ^ C. Partridge; F. Kastenholz (December 1994). Technical Criteria for Choosing IP The Next Generation (IPng). sec. 6.2. doi:10.17487/RFC1726. RFC 1726.
  10. ^ T. Heer; P. Jokela; T. Henderson (April 2015). R. Moskowitz (ed.). Host Identity Protocol Version 2 (HIPv2). Internet Engineering Task Force (IETF). doi:10.17487/RFC7401. ISSN 2070-1721. RFC 7401.
  11. ^ E. Nordmark; M. Bagnulo (June 2009). Shim6: Level 3 Multihoming Shim Protocol for IPv6. Networking Working Group. doi:10.17487/RFC5533. RFC 5533.
  12. ^ a b c d T. Narten (January 2004). Assigning Experimental and Testing Numbers Considered Useful. Network Working Group. doi:10.17487/RFC3692. RFC 3692. BCP 82. RFC 2434 업데이트.
  13. ^ "Internet Protocol Version 6 (IPv6) Parameters: Routing Types". IANA. Retrieved 2021-10-15.
  14. ^ Philippe Biondi, Arnoud Ebalard (April 2007). "IPv6 Routing Header Security" (PDF). EADS. Retrieved 3 December 2010. Type 0: the evil mechanism...
  15. ^ J. Abley; P. Savola; G. Neville-Neil (December 2007). Deprecation of Type 0 Routing Headers in IPv6. doi:10.17487/RFC5095. RFC 5095.
  16. ^ I. Castineyra; N. Chiappa; M. Steenstrup (August 1996). The Nimrod Routing Architecture. doi:10.17487/RFC1992. RFC 1992.
  17. ^ J. Hui; JP. Vasseur; D. Culler; V. Manral (March 2012). An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL). Internet Engineering Task Force (IETF). doi:10.17487/RFC6554. RFC 6554.
  18. ^ S. Previdi; J. Leddy; S. Matsushima; D. Voyer (March 2020). C. Filsfils; D. Dukes (eds.). IPv6 Segment Routing Header (SRH). Internet Engineering Task Force (IETF). doi:10.17487/RFC8754. RFC 8754.
  19. ^ S. Kent (December 2005). IP Authentication Header. Network Working Group. doi:10.17487/RFC4302. RFC 4302. Obsoletes RFC 2402.
  20. ^ S. Kent (December 2005). IP Encapsulating Security Payload. Network Working Group. doi:10.17487/RFC4303. RFC 4303. Obsoletes RFC 2406.
  21. ^ a b F. Gont; V. Manral; R. Bonica (January 2014). Implications of Oversized IPv6 Header Chains. IETF. doi:10.17487/RFC7112. ISSN 2070-1721. RFC 7112. RFC 2460 업데이트.
  22. ^ F. Gont (February 2014). Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard). IETF. doi:10.17487/RFC7113. ISSN 2070-1721. RFC 7113. RFC 6105 업데이트.
  23. ^ F. Gont (August 2013). Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery. IETF. doi:10.17487/RFC6980. ISSN 2070-1721. RFC 6980. RFC 3971 및 4861 업데이트.