IPv6
인터넷에서 패킷을 목적지까지 보내는 규칙의 다음 판입니다. 주소를 32비트에서 128비트로 늘렸습니다. 링크에 새로 붙은 노드는 이웃과 메시지를 주고받아 상대의 물리 주소를 알아냅니다. 자기가 쓸 주소도 그 과정에서 만듭니다.
쉽고 빠른 이해
무슨 일을 하는 물건인가 — 인터넷에서 패킷을 목적지까지 보내는 규칙의 새 판입니다. 주소 자리를
32비트에서 128비트로 늘려서 예전 판보다 훨씬 많은 기기에 저마다 다른 주소를 붙일 수 있습니다.
예를 들어 2001:DB8:0:0:8:800:200C:417A 같은 128비트 주소를 씁니다.
왜 이렇게 하나 — 주소를 32비트로 묶어 두면 주소 계층을 여러 단으로 나눌 수도, 붙일 수 있는 기기 수를 크게 늘릴 수도 없습니다. 흔한 경우의 패킷 처리 비용을 줄이려고 헤더에서 자주 안 쓰는 필드도 걷어냈습니다.
어떻게 도나
- 헤더를 여덟 필드로 딱 정해 두고, 자주 안 쓰는 옵션은 필요할 때만 따로 붙이는 별도 헤더(확장 헤더)로 뺍니다.
- 패킷을 쪼개는 일은 보내는 쪽만 합니다. 경로 위 라우터는 쪼개지 않습니다.
- 링크에 새로 붙으면 이웃과 신호를 주고받아 이웃의 물리 주소를 알아내고, 그 사이에 자기가 쓸 주소도 만듭니다.
대가 — 헤더 크기를 고정해 둔 대신 기능을 늘리려면 확장 헤더를 따로 붙여야 합니다. 새로 만든 주소는 곧바로 못 씁니다 — 다른 기기가 같은 주소를 안 쓰는지부터 확인해야 합니다. 그리고 데이터를 실어 보내는 쪽에서도 오류 검사를 이제는 반드시 해야 합니다. 상대가 아직 예전 판만 쓰는 망이면 이 규칙 하나로는 안 되고, 두 판을 함께 굴리는 전환 기법을 얹어야 합니다.
상세
주소 크기가 32비트에서 128비트로 늘었습니다. 예를 들어 2001:DB8:0:0:8:800:200C:417A 같은
모양입니다. 주소 계층을 여러 단으로 두려는 것입니다. 주소를 붙일 수 있는 노드 수도 훨씬 커집니다.
주소 자동설정도 더 단순해집니다. 멀티캐스트 주소(여러 인터페이스를 하나로 묶어 가리키는 식별자입니다)에는
범위(scope) 필드가 붙어 멀티캐스트 라우팅의 확장성이 개선됐습니다. 애니캐스트 주소라는 새 종류도
정의됐습니다. 한 무리의 노드 가운데 어느 하나에게 패킷을 보낼 때 씁니다. 상대가 아직 예전 판만 쓰는
망이면 이 프로토콜 하나로는 안 되고, 이중 스택처럼 두 판을 함께 굴리는 전환 기법을 얹어야 합니다.
IPv6(Internet Protocol version 6, 인터넷 프로토콜 6판)는 IPv4(Internet Protocol version 4, 인터넷 프로토콜 4판)의 후속으로 설계된 인터넷 프로토콜의 새 판입니다. 규격은 RFC(Request for Comments) 8200 입니다. RFC 8200 은 IPv4 에서 IPv6 로 바뀐 것을 다섯 갈래로 나눠 적습니다. 주소 능력 확장 · 헤더 형식 단순화 · 확장과 옵션 지원 개선 · 흐름 표시 능력 · 인증과 프라이버시 능력입니다.
헤더는 IPv4 헤더 필드 일부를 빼거나 선택 사항으로 돌려 단순해졌습니다. 흔한 경우의 패킷 처리 비용을 줄이고 헤더가 먹는 대역폭을 제한하려는 것입니다. 옵션은 헤더 본체에서 빠져 확장 헤더로 옮겼습니다. 옵션을 헤더에 부호화하는 방식도 바뀌었습니다. 전달이 더 효율적입니다. 옵션 길이 제한도 덜 빡빡합니다. 앞으로 새 옵션을 들이기도 쉬워졌습니다. 여기에 흐름 표시 능력이 더해졌습니다. 보내는 쪽이 네트워크에서 하나의 흐름으로 다뤄지기를 요청하는 패킷 열에 이름표를 붙이는 기능입니다. 인증 · 데이터 무결성 · 선택적인 기밀성을 위한 확장도 IPv6 용으로 규정되어 있습니다.
패킷 크기 규칙이 IPv4 와 크게 갈립니다. IPv6 는 인터넷의 모든 링크(노드들이 같은 매체를 공유해 서로 직접 주고받을 수 있는 구간입니다)가 1280옥텟 이상의 MTU(Maximum Transmission Unit, 최대 전송 단위)를 갖기를 요구합니다. 이것을 IPv6 최소 링크 MTU 라 부릅니다. 1280옥텟짜리 패킷을 한 조각으로 나르지 못하는 링크에서는 IPv6 아래 계층이 그 링크 고유의 단편화와 재조립을 제공해야 합니다. 이것은 그 링크를 지나갈 때만 쓰는 별도의 단편화입니다 — IPv6 자신이 정의하는 단편화와는 다른 것입니다.
IPv6 자신의 단편화는 출발지 노드만 합니다. IPv4 와 달리 패킷이 지나가는 경로 위의 라우터는 패킷을 쪼개지 않습니다. 출발지가 경로 MTU 보다 큰 패킷을 보내야 하면 단편 헤더를 써서 스스로 쪼갤 수 있습니다. 재조립은 목적지가 합니다. 라우팅 헤더를 처리한 중간 노드가 자기가 내보낼 링크의 MTU 보다 패킷이 크다는 것을 알게 되면, 그 패킷을 버리고 출발지 주소로 ICMP(Internet Control Message Protocol, 인터넷 제어 메시지 프로토콜) Packet Too Big 메시지를 보내야 합니다.
경로 MTU 탐색은 IPv6 노드가 구현하기를 강하게 권합니다. 1280옥텟보다 큰 경로 MTU 를 찾아 쓰라는 것입니다. 다만 최소 구현은 1280옥텟보다 큰 패킷을 보내지 않는 선으로 자신을 제한하고 경로 MTU 탐색 구현을 생략해도 됩니다. 부팅 롬 안의 구현 같은 경우입니다.
상위 계층 체크섬 규칙도 달라졌습니다. IPv4 와 달리 IPv6 노드가 UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜) 패킷을 만들어 낼 때의 기본 동작에서 UDP 체크섬은 선택이 아닙니다. UDP 패킷을 만들 때마다 노드는 패킷과 의사 헤더(계산에만 쓰고 실제 패킷에는 안 실리는 가상의 헤더)에 대해 체크섬을 계산해야 합니다. 계산 결과가 0이면 UDP 헤더에 넣을 값을 16진수 FFFF 로 바꿔야 합니다. 체크섬이 0인 UDP 패킷을 받은 IPv6 수신자는 그 패킷을 버려야 합니다. 그리고 그 오류를 로그로 남기도록 권합니다. ICMPv6(Internet Control Message Protocol version 6)도 체크섬 계산에 이 의사 헤더를 넣습니다. 의사 헤더를 넣지 않던 IPv4 판 ICMP 에서 바뀐 자리입니다.
형태
IPv6 헤더는 여덟 필드로 이루어집니다. 필드마다 폭이 다르고, 앞의 세 필드가 32비트 한 칸을, 그다음 세 필드가 32비트 한 칸을 나눠 채웁니다. Source Address 와 Destination Address 는 각각 128비트씩 통째로 씁니다.
---
config:
packet:
bitsPerRow: 32
---
packet-beta
0-3: "Version"
4-11: "Traffic Class"
12-31: "Flow Label"
32-47: "Payload Length"
48-55: "Next Header"
56-63: "Hop Limit"
64-191: "Source Address"
192-319: "Destination Address"
| 필드 | 길이 | 무엇을 담나 |
|---|---|---|
| Version | 4비트 | 인터넷 프로토콜 판 번호. 값은 6입니다 |
| Traffic Class | 8비트 | 패킷마다 처리 등급을 다르게 매기는 데 쓰는 필드입니다. 정확한 부호화 규칙은 RFC 8200 §7 이 정하는데, 이 문서의 자료에는 그 절 발췌가 없습니다 |
| Flow Label | 20비트 | 흐름 이름표 |
| Payload Length | 16비트 | IPv6 헤더 뒤에 오는 나머지 부분의 길이. 단위는 옥텟입니다 |
| Next Header | 8비트 | 이 헤더 바로 다음에 오는 헤더의 종류. IPv4 의 Protocol 필드와 같은 값을 씁니다 |
| Hop Limit | 8비트 | 패킷을 전달하는 노드마다 1씩 줄입니다 |
| Source Address | 128비트 | 패킷을 만들어 낸 쪽의 주소 |
| Destination Address | 128비트 | 받기로 되어 있는 쪽의 주소 |
Payload Length 는 확장 헤더까지 포함해서 셉니다. 확장 헤더도 페이로드의 일부로 봅니다. Hop Limit 이 0인 채로 받았거나 줄여서 0이 되면 전달하는 노드는 그 패킷을 버립니다. 패킷의 목적지인 노드는 다릅니다. Hop Limit 이 0인 패킷도 버리지 말고 평소대로 처리하도록 되어 있습니다. Destination Address 가 최종 수신자가 아닐 수도 있습니다. 라우팅 헤더가 붙어 있는 경우입니다.
확장 헤더 체인
인터넷 계층의 선택적 정보는 별도 헤더에 담깁니다. IPv6 헤더와 상위 계층 헤더 사이에 놓입니다. 확장 헤더 종류는 많지 않습니다. 각각 서로 다른 Next Header 값으로 구별합니다. Next Header 로 헤더를 잇는 예를 셋 듭니다.
확장 헤더가 없을 때입니다.
block-beta columns 2 A["IPv6 header (Next Header = TCP)"]:1 B["TCP header + data"]:1
라우팅 헤더를 하나 끼운 경우입니다. TCP(Transmission Control Protocol, 전송 제어 프로토콜)는 그다음에 옵니다.
block-beta columns 3 A["IPv6 header (Next Header = Routing)"]:1 B["Routing header (Next Header = TCP)"]:1 C["TCP header + data"]:1
라우팅 헤더 뒤에 단편 헤더까지 끼운 경우입니다. 이때 마지막 칸은 TCP 데이터 전체가 아니라 단편 헤더가 잘라낸 한 조각입니다. 단편화는 출발지 노드가 페이로드를 여러 조각으로 나눠 보내는 것이기 때문입니다.
block-beta columns 4 A["IPv6 header (Next Header = Routing)"]:1 B["Routing header (Next Header = Fragment)"]:1 C["Fragment header (Next Header = TCP)"]:1 D["fragment of TCP"]:1
IPv6 를 온전히 구현하면 다음 확장 헤더가 들어갑니다. 홉바이홉 옵션(Hop-by-Hop Options) · 단편 (Fragment) · 목적지 옵션(Destination Options) · 라우팅(Routing) · 인증(Authentication) · 캡슐화 보안 페이로드(Encapsulating Security Payload)입니다. 앞의 넷은 RFC 8200 이 규정하고 뒤의 둘은 각각 RFC 4302 와 RFC 4303 이 규정합니다.
한 패킷에 확장 헤더를 여럿 쓰면 아래 순서로 나타나기를 권합니다. 목적지 옵션 헤더는 이 순서에 두 번 나옵니다 — 라우팅 헤더 앞과 단편 헤더 뒤입니다.
block-beta columns 1 A["IPv6 헤더"] B["홉바이홉 옵션 헤더"] C["목적지 옵션 헤더"] D["라우팅 헤더"] E["단편 헤더"] F["인증 헤더"] G["캡슐화 보안 페이로드 헤더"] H["목적지 옵션 헤더"] I["상위 계층 헤더"]
주소 표기
RFC 4291 은 주소를 글자로 적는 형태를 셋으로 정합니다.
선호 형태는 x:x:x:x:x:x:x:x 입니다. 각 x 는 128비트를 16비트씩 여덟 조각으로 나눈 것이고
16진수 한 자리에서 네 자리까지로 적습니다. 한 칸 안의 앞자리 0은 안 써도 됩니다. 다만 모든 칸에
숫자가 최소 하나는 있어야 합니다. 다음 형태만 예외입니다.
둘째 형태가 :: 입니다. 16비트 0 묶음이 하나 이상 있다는 뜻입니다. 한 주소에 한 번만 나올 수
있습니다.
셋째 형태는 x:x:x:x:x:x:d.d.d.d 입니다. 앞의 여섯 칸은 16진수로 적은 16비트 조각이고 뒤의 네
칸은 10진수로 적은 8비트 조각입니다.
RFC 5952 는 이 문법 위에 정규 표기 권고를 얹었습니다. RFC 4291 에 온전히 들어맞으면서 여러 운영체제가 이미 구현하고 있는 형태입니다. 글로 적을 주소를 만들어 낼 때 시스템은 이 권고를 따라야 합니다(SHOULD). 반대로 읽을 때는 RFC 4291 에 맞는 어떤 형태든 받아들이고 다룰 수 있어야 합니다(MUST). 권고는 다섯 가지입니다.
| 규칙 | 내용 |
|---|---|
| 앞자리 0 | 반드시 지웁니다. 16비트 칸 하나가 통째로 0이면 0 한 글자로 적습니다 |
:: 최대 적용 |
줄일 수 있는 만큼 줄여야 합니다 |
:: 최소 길이 |
16비트 0 칸 하나만 줄이는 데는 쓰면 안 됩니다 |
:: 자리 |
연속한 0 칸이 가장 긴 구간을 줄입니다. 길이가 같으면 앞쪽 구간을 줄입니다 |
| 대소문자 | a 부터 f 까지는 소문자로 적어야 합니다 |
주소 종류
주소가 어느 종류인지는 앞쪽 비트가 정합니다.
| 종류 | 이진 접두 | IPv6 표기 |
|---|---|---|
| 미지정(Unspecified) | 128비트 전부 0 | ::/128 |
| 루프백(Loopback) | 127비트 0 뒤에 1 | ::1/128 |
| 멀티캐스트 | 11111111 |
FF00::/8 |
| 링크로컬 유니캐스트 | 1111111010 |
FE80::/10 |
| 글로벌 유니캐스트 | 나머지 전부 |
유니캐스트 주소는 인터페이스 하나를 가리킵니다. 패킷은 그 인터페이스 하나에만 갑니다. 멀티캐스트나 애니캐스트와 다른 점입니다.
링크로컬 유니캐스트 주소는 한 링크 안에서만 씁니다. 라우터가 없어도 되는 자동 주소 설정이나 이웃과 신호를 주고받는 용도로 쓰라고 만든 주소입니다. 라우터는 링크로컬 주소를 출발지나 목적지로 삼은 패킷을 다른 링크로 전달하면 안 됩니다.
애니캐스트 주소는 유니캐스트 주소 공간에서 가져옵니다. 문법으로는 유니캐스트 주소와 구별되지 않습니다.
멀티캐스트 주소는 고정된 접두사 뒤에 flgs(플래그) · scop(범위) 필드가 오고, 나머지가 group ID(그룹 식별자)입니다.
packet-beta 0-7: "11111111" 8-11: "flgs" 12-15: "scop" 16-127: "group ID"
scop 값은 이 멀티캐스트 그룹이 얼마나 멀리까지 퍼지는지를 정합니다. 인터페이스 로컬이 1, 링크 로컬이 2, 관리 로컬이 4, 사이트 로컬이 5, 조직 로컬이 8, 글로벌이 E 입니다.
이진 접두가 000 으로 시작하는 것(위 표의 미지정 · 루프백처럼 앞쪽이 온통 0인 주소)을 뺀 모든
유니캐스트 주소에서, 주소 뒤쪽에서 그 인터페이스 하나를 가리키는 조각인 인터페이스 식별자는
64비트여야 합니다. 그리고 Modified EUI-64 형식으로 만들어야 합니다. IEEE(Institute of Electrical
and Electronics Engineers, 전기전자기술자협회)가 정한 EUI-64(Extended Unique Identifier 64, 64비트
확장 고유 식별자) 식별자에서 인터페이스 식별자를 만들 때 u 비트(IEEE EUI-64 용어로 universal/local
비트)를 뒤집는 형식입니다. 뒤집은 결과에서 u 비트가 1이면 그 인터페이스 식별자가 전 세계에서
유일하게 정해진 값(전역 범위)이라는 뜻이고, 0이면 이 링크 안에서만 정한 값(지역 범위)이라는
뜻입니다.
교환 순서
IPv6 노드는 RFC 8200 의 패킷 전송 규칙을 따라야 합니다. 여기에 더해 이웃 탐색을 지원해야 합니다. 이웃 탐색은 링크 위에서 라우터와 프리픽스(라우터가 광고하는 주소 앞부분입니다)를 찾고, 이웃의 물리 주소를 확인하고, 이웃이 아직 응답하는지 살피는 절차를 통틀어 이르는 말입니다. 다만 예외가 있습니다 — 이를테면 이웃 도달 불가 탐지(이웃이 여전히 패킷을 받을 수 있는 상태인지 주기적으로 다시 확인하는 절차입니다)는 호스트와 이웃 사이의 모든 경로에는 요구되지만 라우터끼리의 경로에는 요구되지 않습니다. RFC 8504 는 IPv6 노드가 무엇을 갖춰야 하는지를 정한 문서입니다. 이 문서는 라우터 탐색과 프리픽스 탐색을 호스트의 필수로 못 박습니다. 그리고 모든 노드가 Neighbor Solicitation(이웃 요청)과 Neighbor Advertisement(이웃 광고)를 보내고 받을 수 있어야 한다고 적습니다. 이 두 메시지는 중복 주소 탐지(같은 주소를 다른 노드가 이미 쓰고 있는지 확인하는 절차입니다)에 필요하기 때문입니다.
링크에 붙는 순간
주소 자동설정은 링크로컬 주소를 만드는 것부터 시작합니다. 인터페이스에 붙은 인터페이스 식별자를 링크로컬 프리픽스 뒤에 붙여 만듭니다. 이 주소도 인터페이스에 붙이기 전에 중복 주소 탐지를 거칩니다.
호스트는 인터페이스가 켜지면 다음 라우터 광고를 기다리지 않으려 할 수 있습니다. 광고를 빨리 받으려면 Router Solicitation 을 모든 라우터 멀티캐스트 주소로 보내도록 권합니다. 최대 몇 번까지 보내는지와 사이 간격은 명세가 상수로 정해 둡니다. 라우터는 Router Advertisement 로 답합니다. 이 메시지의 출발지 주소는 반드시 그 인터페이스에 붙은 링크로컬 주소여야 합니다. 주기적으로도 보냅니다. Router Advertisement 에는 Prefix Information 옵션이 실릴 수 있습니다. 이 옵션이 어느 프리픽스(앞서 형태에서 본 이진 접두와 같은 것으로, 라우터가 광고하는 주소 앞부분입니다)가 이 링크에 있고 어느 것을 주소 자동설정에 쓸 수 있는지 알려 줍니다.
글로벌 주소는 그 프리픽스 뒤에 인터페이스 식별자를 붙여 만듭니다. Prefix Information 옵션의 Autonomous 플래그(그 프리픽스를 상태 없는 주소 자동설정에 써도 되는지 나타내는 표시입니다)가 안 서 있으면 그 옵션은 조용히 무시합니다.
주소는 만들었다고 바로 쓰지 않습니다. 모든 유니캐스트 주소는 인터페이스에 붙이기 전에 중복 주소 탐지를 거쳐야 합니다 — 상태 없는 자동설정(DHCPv6 같은 서버 없이 노드 혼자 프리픽스와 인터페이스 식별자로 주소를 만드는 방식입니다)으로 얻었든 DHCPv6(Dynamic Host Configuration Protocol for IPv6, IPv6 용 동적 호스트 설정 프로토콜)로 받았든 손으로 넣었든 마찬가지입니다. 다만 명세는 이 규칙에 예외를 몇 가지 두고 있습니다. 절차가 끝나기 전까지 그 주소는 tentative — 아직 확정되지 않은 상태입니다. 절차 중에 중복이 발견되면 그 주소는 인터페이스에 못 붙입니다. 중복이 없으면 절차가 끝나고 그 주소는 정식으로 인터페이스에 붙습니다.
sequenceDiagram
participant 호스트
participant 라우터
participant 다른 노드
Note over 호스트: 인터페이스 식별자로 링크로컬 주소부터 만든다
호스트->>라우터: Router Solicitation
라우터-->>호스트: Router Advertisement (Prefix Information)
Note over 호스트: 프리픽스에 인터페이스 식별자를 붙여 tentative 주소를 만든다
호스트->>다른 노드: Neighbor Solicitation (Target = 만든 주소, 멀티캐스트로 보낸다)
alt 같은 주소를 쓰는 노드가 있다
다른 노드-->>호스트: Neighbor Advertisement
Note over 호스트: 중복 — 주소를 못 붙인다
else 답이 없다
Note over 호스트: 정식으로 붙인다
end
Router Advertisement 의 M 플래그가 서 있으면 DHCPv6 로 주소를 받을 수 있다는 뜻입니다. MTU 옵션도 실릴 수 있습니다. 그 링크 자신의 MTU 가 고정돼 있지 않고 바뀔 수 있는 링크에서 보내도록 권합니다.
주소 해석
노드가 이웃에게 유니캐스트 패킷을 보내려는데 그 이웃의 링크 계층 주소(랜 카드마다 박힌 물리
주소)를 모를 때 주소 해석을 합니다. 멀티캐스트가 되는 인터페이스라면 먼저 이웃 캐시(이웃마다 주소와
물리 주소를 짝지어 적어 두는 표입니다)에 항목을 INCOMPLETE(아직 물리 주소를 못 채운) 상태로
만듭니다. 그리고 그 이웃을 겨냥한 Neighbor Solicitation 을 보냅니다. 목적지는 대상 주소에 대응하는
solicited-node 멀티캐스트 주소입니다(대상 주소의 하위 24비트를 FF02:0:0:0:0:1:FF00::/104 뒤에
붙여 만듭니다. 「예시」에서 더 자세히 다룹니다). 이때 보내는 쪽은 자기 링크 계층 주소가 있으면 그것을
Source Link-Layer Address 옵션으로 반드시 실어야 합니다.
한 왕복입니다. 답하는 쪽은 자기에게 붙은 주소를 겨냥한 유효한 요청에 Neighbor Advertisement 로 답합니다. 요청이 없어도 Neighbor Advertisement 를 보낼 때가 있습니다. 전달됐다는 보장 없이 새 정보를 빨리 퍼뜨리려는 것입니다. 요청에 답하는 광고라면 Target Address 는 그 요청의 Target Address 를 그대로 베낍니다. 요청이 멀티캐스트 주소로 왔으면 Target Link-Layer Address 옵션을 반드시 넣어야 합니다. 답하는 노드가 라우터면 Router 플래그를 1로, 아니면 0으로 설정해야 합니다.
요청을 보낸 쪽 주소가 미지정 주소이면 답하는 방식이 달라집니다. 이 경우 Solicited 플래그를 0으로 두고 광고를 모든 노드 멀티캐스트 주소로 보내야 합니다. 그 밖의 경우에는 Solicited 플래그를 1로 두고 요청의 출발지 주소로 유니캐스트합니다.
패킷이 너무 클 때
라우터는 내보낼 링크의 MTU 보다 패킷이 커서 전달하지 못하면 Packet Too Big 을 보내야 합니다. 이 메시지의 목적지 주소는 문제가 된 패킷의 출발지 주소를 그대로 베낍니다. 메시지에는 다음 홉 링크의 MTU 가 실립니다. 들어온 Packet Too Big 은 상위 계층 프로세스를 알아낼 수 있으면 그 프로세스에 반드시 전달해야 합니다.
sequenceDiagram
participant 송신
participant 라우터
participant 목적지
송신->>라우터: 경로 MTU 보다 큰 패킷
라우터-->>송신: ICMPv6 Packet Too Big (MTU)
Note over 송신: 경로 MTU 추정값을 줄인다
송신->>목적지: 줄인 크기의 패킷
이 왕복을 쓰는 것이 경로 MTU 탐색입니다. RFC 8201 은 IPv6 노드가 경로 MTU 탐색을 구현할 의무는 없다고 적습니다. 이 문서의 요구사항은 경로 MTU 탐색을 넣은 구현에만 걸립니다. 구현했다면 규칙이 넷입니다. Packet Too Big 을 받으면 메시지의 MTU 값을 근거로 그 경로의 경로 MTU 추정값을 줄여야 합니다. 그 추정값을 IPv6 최소 링크 MTU 아래로 내리면 안 됩니다. IPv6 최소 링크 MTU 보다 작은 다음 홉 MTU 를 알려 오는 Packet Too Big 은 버려야 합니다. 그리고 Packet Too Big 의 내용을 보고 추정값을 올려서도 안 됩니다.
예시
주소 한 벌
RFC 4291 이 싣고 있는 주소들입니다. 왼쪽이 선호 형태이고 오른쪽이 :: 로 줄인 형태입니다.
2001:DB8:0:0:8:800:200C:417A → 2001:DB8::8:800:200C:417A 유니캐스트 주소
FF01:0:0:0:0:0:0:101 → FF01::101 멀티캐스트 주소
0:0:0:0:0:0:0:1 → ::1 루프백 주소
0:0:0:0:0:0:0:0 → :: 미지정 주소
IPv4 주소를 뒤에 붙이는 셋째 형태의 실물입니다.
0:0:0:0:0:0:13.1.68.3 → ::13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38 → ::FFFF:129.144.52.38
같은 주소라도 정규 표기는 하나로 정해집니다. RFC 5952 가 실어 둔 대조입니다.
2001:0db8::0001 받아들이지 않습니다. 2001:db8::1 로 적습니다
2001:db8:0:0:0:0:2:1 줄여야 합니다. 2001:db8::2:1 로 적습니다
2001:db8:0:1:1:1:1:1 이대로가 맞습니다
2001:db8::1:1:1:1:1 틀린 표기입니다. 0 칸 하나만 `::` 로 줄였습니다
문서에 예로 쓸 주소는 2001:DB8::/32 에서 가져옵니다. 문서용으로 배정된 프리픽스입니다.
사이트 로컬 주소나 링크로컬 주소를 문서의 예로 쓰는 것은 맞지 않아 유니캐스트 주소 블록을 따로
잡아 둔 것입니다.
solicited-node 멀티캐스트 주소
이웃 요청이 목적지로 삼는 주소입니다. 노드의 유니캐스트 주소나 애니캐스트 주소에서 계산해
냅니다. 주소의 하위 24비트를 떼어 FF02:0:0:0:0:1:FF00::/104 뒤에 붙입니다. 그래서 나올 수 있는
값은 아래 범위 안에 있습니다.
FF02:0:0:0:0:1:FF00:0000
부터
FF02:0:0:0:0:1:FFFF:FFFF
미리 정해진 멀티캐스트 주소도 있습니다. 모든 노드 주소는 FF01:0:0:0:0:0:0:1 과
FF02:0:0:0:0:0:0:1 입니다. 모든 라우터 주소는 FF01:0:0:0:0:0:0:2 ·
FF02:0:0:0:0:0:0:2 · FF05:0:0:0:0:0:0:2 입니다.
이웃을 찾는 한 왕복
주소 해석에서 오가는 두 메시지의 실제 필드 값입니다.
Neighbor Solicitation
IP Source Address 보내는 인터페이스에 붙은 주소
Destination Address 대상 주소에 대응하는 solicited-node 멀티캐스트 주소
Hop Limit 255
ICMP Type 135
Code 0
Target Address 찾으려는 대상의 IP 주소. 멀티캐스트 주소면 안 됩니다
Option Type 1 Source Link-Layer Address
Neighbor Advertisement
IP Hop Limit 255
ICMP Type 136
Code 0
R 라우터면 1
S 요청에 답하는 것이면 1
O 기존 캐시 항목을 덮어쓰라는 뜻이면 1
Target Address 요청에 답하는 것이면 그 요청의 Target Address 를 그대로
Option Type 2 Target Link-Layer Address
두 메시지 다 Hop Limit 을 255 로 채웁니다. Hop Limit 은 8비트 필드이므로(「형태」 참고) 255 가 이 필드가 가질 수 있는 가장 큰 값입니다.
중복 주소 탐지로 보내는 Neighbor Solicitation 은 값 두 개가 다릅니다. Target Address 는 검사하는 주소 자신입니다. IP 출발지는 미지정 주소입니다. 목적지는 그 대상 주소의 solicited-node 멀티캐스트 주소입니다. 보내기 전에 인터페이스는 모든 노드 멀티캐스트 주소와 그 대상 주소의 solicited-node 멀티캐스트 주소에 가입해야 합니다.
패킷이 너무 클 때의 값
Packet Too Big 의 값은 다음과 같습니다.
ICMPv6 Packet Too Big
IP Destination Address 문제가 된 패킷의 Source Address 를 그대로
ICMP Type 2
Code 0
MTU 다음 홉 링크의 MTU
실패
이 프로토콜에서 절차가 깨지는 자리 가운데 아래 둘을 적습니다.
| 조건 | 결과 |
|---|---|
| 중복 주소 탐지 중 같은 주소를 쓰는 다른 노드가 Neighbor Advertisement 로 응답한다 | 그 주소는 tentative 상태를 벗어나지 못하고 인터페이스에 못 붙습니다 |
| Packet Too Big 메시지가 알려주는 다음 홉 MTU 가 IPv6 최소 링크 MTU(1280옥텟)보다 작다 | 그 메시지를 버리고 경로 MTU 추정값을 그 아래로 낮추지 않습니다 |
관련 항목
주소의 갈래
링크로컬 주소 · 글로벌 유니캐스트 주소 · 유니크 로컬 주소 · 멀티캐스트 주소 · 애니캐스트 주소 · Subnet-Router 애니캐스트 주소 · solicited-node 멀티캐스트 주소 · 미지정 주소 · 루프백 주소 · 인터페이스 식별자 · Modified EUI-64 · 프리픽스 · 멀티캐스트 범위
주소를 얻는 길
상태 없는 주소 자동설정 · 중복 주소 탐지 · 라우터 광고 · 라우터 요청 · DHCPv6 · 프리픽스 위임
이웃을 다루는 규칙
이웃 탐색 · 이웃 캐시 · 이웃 도달 불가 탐지 · 이웃 요청 · 이웃 광고 · ICMPv6 · 링크 계층 주소
IPv6 헤더를 이루는 구성 요소
확장 헤더 · 홉바이홉 옵션 헤더 · 목적지 옵션 헤더 · 라우팅 헤더 · 단편 헤더 · 인증 헤더 · 캡슐화 보안 페이로드 · 플로 레이블 · 홉 리밋 · 트래픽 클래스
패킷 크기를 다루는 요소
경로 MTU 탐색 · 최소 링크 MTU · Packet Too Big · 단편화 · 의사 헤더
IPv4 와 함께 쓰는 전환 기법
IPv4 · IPv4 주소 고갈 · 이중 스택 · NAT64(IPv6 전용 클라이언트가 IPv4 전용 서버와 통신하게 해 주는, 상태를 유지하는 주소·프로토콜 변환 메커니즘) · DNS64(IPv6 전용 클라이언트가 이름으로 IPv4 전용 서버와 통신하게 해 주는 이름 풀이 확장) · IPv6 노드 요구사항
다른 이름: Internet Protocol version 6 · IP version 6 · 인터넷 프로토콜 6판