백서
개요
최신 장치에 대한 추가 기능 요구와 사용할 수 있는 인터넷 주소의 고갈이 임박해옴에 따라 IPv4라는 인터넷 프로토콜(IP)의 업그레이드 버전에 대한 표준화 작업이 진행되고 있습니다. IP 버전 6(IPv6)이라고 하는 이 새로운 버전은 예상치 못했던 IPv4의 설계 문제를 해결하고 21세기의 인터넷에 적합하게 만들어집니다. 이 백서에서는 IPv4 인터넷의 문제점에 대해 설명하고, IPv6, IPv6 주소 지정, 새로운 IPv6 헤더 및 확장, 인터넷 제어 메시지 프로토콜(ICMP)과 인터넷 그룹 관리 프로토콜(IGMP)에 대한 IPv6 대체, 인접 노드 상호 작용 및 IPv6 주소 자동 구성을 통해 이러한 문제점을 처리하는 방법에 대해 설명합니다. 이 문서는 인터넷 표준 기반 IPv6 개념을 위한 기초 자료이며, 기본적인 네트워킹 개념과 TCP/IP에 익숙한 네트워크 엔지니어와 지원 전문가용입니다.
소개
IP의 현재 버전(버전 4 또는 IPv4)은 실질적으로 1981년 RFC 791 발표 이후 바뀌지 않았습니다. IPv4는 확고하고 쉽게 구현되며 상호 운용이 가능하다는 것이 입증되었으며, 오늘날과 같은 규모의 인터넷을 전 세계적으로 이용할 수 있도록 네트워크간에 확장할 수 있음을 실증적으로 보여주었습니다. 이렇듯 초기에 설계된 버전은 지대한 공헌을 해왔음이 분명합니다.
그러나 초기 설계에서는 다음과 같은 사항을 미처 예상치 못했었습니다.
- 최근의 급속한 인터넷 성장과 IPv4 주소 공간의 고갈 임박
IPv4 주소가 상대적으로 부족해지면서 일부 조직에서는 네트워크 주소 변환기(NAT)를 사용하여 여러 개인 주소를 하나의 공용 IP 주소로 매핑하도록 만들고 있습니다. NAT가 개인 주소 공간의 재사용을 촉진하고 있기는 하지만, 표준 기반 네트워크 계층 보안이나 모든 상위 계층 프로토콜의 올바른 매핑이 지원되지 않으며 개인 주소 공간을 사용하는 두 조직을 연결할 때 문제가 생길 수 있습니다.
게다가 인터넷으로 연결된 장치와 가전 제품들이 증가함에 따라 결국 공용 IPv4 주소 공간이 고갈될 것이 확실해지고 있습니다.
- 인터넷의 성장 및 큰 라우팅 테이블을 유지 관리하는 인터넷 백본 라우터의 능력
현재의 IPv4 네트워크 ID 할당 방법으로 인해 인터넷 백본 라우터의 라우팅 테이블에는 보통 70,000개 이상의 라우터가 존재합니다. 현재의 IPv4 인터넷 라우팅 인프라에서는 기본 라우팅과 계층적 라우팅을 함께 사용하고 있습니다.
- 보다 단순한 구성에 대한 요구
현재 대부분의 IPv4 구현은 수동으로 구성되거나 동적 호스트 구성 프로토콜(DHCP)과 같은 스테이트풀(주: 상태 정보를 이용하는 방식) 주소 구성 프로토콜을 사용하고 있습니다. IP를 사용하는 컴퓨터와 장치가 많아지면서 주소를 보다 단순하고 자동화된 구성과 DHCP 인프라 관리를 필요로 하지 않는 기타 다른 구성 설정에 대한 요구가 생기고 있습니다.
- IP 수준에서의 보안 요구 사항
인터넷과 같은 공용 매체 상의 개인 통신에서는 전송 중인 데이터를 중간에 보거나 수정할 수 없도록 하는 암호화 서비스가 필요합니다. 현재 인터넷 프로토콜 보안 또는 IPSec이라고 알려진 IPv4 패킷에 보안을 제공하는 표준이 있기는 하지만 이는 옵션이며 독점 솔루션들이 널리 보급되고 있습니다.
- 서비스 품질(QoS)이라는 실시간 데이터 배달을 위한 더 나은 지원 요구
IPv4에 대한 QoS 표준도 있지만 실시간 트래픽 지원은 보통 UDP나 TCP 포트를 사용하는 페이로드의 식별과 IPv4 TOS(Type of Service) 필드에 좌우됩니다. 불행히도 IPv4 TOS 필드는 그 기능이 제한되어 있어서 계속해서 여러 가지 국부적인 해석이 등장하고 있습니다. 뿐만 아니라 IPv4 패킷 페이로드를 암호화할 때는 TCP와 UDP 포트를 사용하는 페이로드 식별이 가능하지 않습니다.
이와 같은 문제를 처리하기 위해 IETF(Internet Engineering Task Force)에서 IP 버전 6(IPv6)으로 알려진 프로토콜과 표준들을 개발하였습니다. 일전에는 IP-The Next Generation(IPng)이라고 했던 이 새로운 버전은 IPv4 프로토콜의 업데이트를 위해 제시된 여러 방법론의 개념을 통합했습니다. IPv6은 새 기능을 임의로 추가하지 못하도록 막으면서 상위 계층과 하위 계층 프로토콜에 미치는 영향을 최소화하도록 설계되었습니다.
IPv6의 기능
다음은 IPv6 프로토콜의 기능입니다.
- 새로운 헤더 형식
- 큰 주소 공간
- 효율적이고 계층적인 주소 지정 및 라우팅 인프라
- 스테이트리스(상태 정보를 이용하지 않고 클라이언트에서 받은 명령문에만 의존하는 방식) 주소 구성 및 스테이트풀(상태 정보를 이용하는 방식) 주소 구성
- 기본 제공되는 보안 기능
- 개선된 QoS 지원
- 인접 노드 상호 작용을 위한 새 프로토콜
- 확장성
다음 절에서는 이러한 각각의 새로운 기능에 대해 자세히 검토합니다.
새로운 헤더 형식
IPv6 헤더는 헤더의 오버헤드를 최소화하도록 설계된 새로운 형식입니다. 이 형식에서 중요하지 않은 필드와 옵션 필드는 IPv6 헤더 뒤에 있는 확장 헤더로 이동했습니다. IPv6 헤더를 이렇게 유선형으로 만듦으로써 중간 라우터가 보다 효율적으로 처리됩니다.
IPv4 헤더와 IPv6 헤더는 상호 운용이 가능하지 않습니다. 두 헤더 형식을 모두 인식하고 처리하기 위해서는 호스트나 라우터에서 IPv4 및 IPv6 모두를 구현해야 합니다. IPv6 주소는 IPv4 주소의 4배지만 새 IPv6 헤더는 IPv4 헤더의 2배에 불과합니다.
큰 주소 공간
IPv6은 128비트(16바이트) 원본 및 대상 IP 주소를 가집니다. 128비트가 3.4x1038개 이상 결합되어 표시될 수 있기는 하지만, IPv6의 주소 공간은 인터넷 백본부터 조직 내의 개별 서브넷까지 여러 수준의 서브네팅과 주소 할당이 가능하도록 크게 만들어졌습니다.
현재는 소수의 주소만 호스트에서 사용하도록 할당되어 있지만 앞으로는 많은 수의 주소를 사용할 수 있게 됩니다. 사용 가능한 주소가 매우 많기 때문에 더 이상 NAT의 구축과 같은 주소 변환 기술이 필요하지 않습니다.
효율적이고 계층적인 주소 지정 및 라우팅 인프라
다중 인터넷 서비스 공급자의 출현이 일반화됨에 따라 인터넷의 IPv6 부분에 사용된 IPv6 글로벌 주소는 효율적이고 계층적이며 요약 가능한 라우팅 인프라를 만들도록 설계됩니다. IPv6 인터넷에서는 최상위 집계기의 라우팅 인프라에 대응하는 백본 라우터의 라우팅 테이블 크기가 훨씬 작아졌습니다. 자세한 내용은 "집계 가능한 글로벌 유니캐스트 주소"를 참조하십시오.
스테이트리스 주소 구성 및 스테이트풀 주소 구성
호스트 구성을 단순화하기 위해 IPv6은 DHCP 서버가 있을 때의 주소 구성인 스테이트풀(주: 상태 정보를 이용하는 방식) 주소 구성과 DHCP 서버가 없을 때의 주소 구성인 스테이트리스(주: 상태 정보를 이용하지 않고 클라이언트에서 받은 명령문에만 의존하는 방식) 주소 구성을 모두 지원합니다. 스테이트리스 주소 구성의 경우, 링크의 호스트는 링크 로컬 주소라고 하는 링크용 IPv6 주소와 로컬 라우터가 게시한 접두사에서 파생된 주소로 자동 구성됩니다. 라우터가 없어도 동일한 링크에 있는 호스트는 링크 로컬 주소로 자신을 자동으로 구성할 수 있으며, 수동으로 구성하지 않아도 통신이 가능합니다.
기본 제공되는 보안 기능
IPSec에 대한 지원은 IPv6 프로토콜 제품군의 요구 사항입니다. 이 요구 사항은 네트워크 보안 요구에 맞는 표준 기반 솔루션을 제공하며, 다른 IPv6 구현들 사이의 상호 운용성을 촉진합니다.
개선된 QoS 지원
IPv6 헤더에 있는 새 필드는 트래픽의 처리 및 확인 방법을 정의합니다. IPv6 헤더의 흐름 레이블 필드를 사용한 트래픽 확인을 통해 라우터는 원본과 대상 사이에서 일련의 패킷 흐름에 속하는 패킷의 특수한 처리를 식별하고 제공할 수 있습니다. IPv6 헤더에서 트래픽이 식별되기 때문에 IPSec를 통해 패킷 페이로드가 암호화될 때에도 QoS를 지원할 수 있습니다.
인접 노드 상호 작용을 위한 새 프로토콜
IPv6의 네트워크 환경 검색 프로토콜은 인접 노드(동일한 링크에 있는 노드)의 상호 작용을 관리하는 IPv6(ICMPv6) 메시지를 위한 일련의 인터넷 제어 메시지 프로토콜입니다. 네트워크 환경 검색은 브로드캐스트 기반의 주소 확인 프로토콜(ARP), ICMPv4 라우터 검색 및 ICMPv4 리디렉트 메시지를 효율적인 멀티캐스트와 유니캐스트 네트워크 환경 검색 메시지로 대체합니다.
확장성
IPv6 헤더 뒤에 확장 헤더를 추가함으로써 IPv6을 새 기능에 맞게 쉽게 확장할 수 있습니다. 40바이트의 옵션만 지원할 수 있는 IPv4 헤더 옵션과 달리 IPv6 확장 헤더의 크기는 IPv6 패킷 크기에 의해서만 제한됩니다.
IPv4와 IPv6의 차이점
표 1은 IPv4와 IPv6의 중요한 몇 가지 차이점을 보여줍니다.
표 1 IPv4와 IPv6의 차이점
| IPv4 |
IPv6 |
| 원본과 대상 주소의 길이가 32비트(4바이트)입니다. |
원본과 대상 주소의 길이가 128비트(16바이트)입니다. 자세한 내용은 "IPv6 주소 지정"을 참조하십시오. |
| IPSec 지원이 선택 사항입니다. |
IPSec 지원이 필수입니다. 자세한 내용은 "IPv6 헤더"를 참조하십시오. |
| 라우터의 QoS 처리를 위한 페이로드 식별이 IPv4 헤더 내에 없습니다. |
라우터에 의한 QoS 처리용 페이로드 식별이 흐름 레이블 필드를 사용해서 IPv6 헤더에 포함됩니다. 자세한 내용은 "IPv6 헤더"를 참조하십시오. |
| 라우터와 전송측 호스트 모두에서 조각화가 지원됩니다. |
라우터에서 조각화가 지원되지 않습니다. 이러한 조각화는 전송측 호스트에서만 지원됩니다. 자세한 내용은 "IPv6 헤더"를 참조하십시오. |
| 헤더에 검사값이 포함됩니다. |
헤더에 검사값이 포함되지 않습니다. 자세한 내용은 "IPv6 헤더"를 참조하십시오. |
| 헤더에 옵션이 포함됩니다. |
모든 옵션 데이터가 IPv6 확장 헤더로 이동합니다. 자세한 내용은 "IPv6 헤더"를 참조하십시오. |
| 주소 확인 프로토콜(ARP)이 브로드캐스트 ARP 요청 프레임을 사용하여 링크 계층 주소에 대한 IPv4 주소를 확인합니다. |
ARP 요청 프레임이 멀티캐스트 네트워크 환경 요청 메시지로 대체됩니다. 자세한 내용은 "네트워크 환경 검색"을 참조하십시오. |
| 인터넷 그룹 관리 프로토콜(IGMP)이 로컬 서브넷 그룹 등록 관리에 사용됩니다. |
IGMP가 멀티캐스트 수신기 검색(MLD) 메시지로 대체됩니다. 자세한 내용은 "멀티캐스트 수신기 검색"을 참조하십시오. |
| ICMP 라우터 검색이 최상의 기본 게이트웨이 IPv4 주소를 판별하기 위해 사용되며, 이는 선택 사항입니다. |
ICMPv4 라우터 검색이 ICMPv6 라우터 요청과 라우터 알림 메시지로 대체되며, 이는 필수입니다. 자세한 내용은 "네트워크 환경 검색"을 참조하십시오. |
| 서브넷의 모든 노드로 트래픽을 보내기 위해 브로드캐스트 주소가 사용됩니다. |
IPv6 브로드캐스트 주소가 없습니다. 그 대신, 링크-로컬 범위-모든 노드 멀티캐스트 주소가 사용됩니다. 자세한 내용은 "멀티캐스트 IPv6 주소"를 참조하십시오. |
| 수동으로 구성하거나 DHCP를 통해 구성해야 합니다. |
수동 구성이나 DHCP 구성이 필요하지 않습니다. 자세한 내용은 "주소 자동 구성"을 참조하십시오. |
| 도메인 이름 시스템(DNS)의 호스트 주소(A) 리소스 레코드를 사용하여 호스트 이름을 IPv4 주소로 매핑합니다. |
도메인 이름 시스템(DNS)의 호스트 주소(AAAA) 리소스 레코드를 사용하여 호스트 이름을 IPv6 주소로 매핑합니다. 자세한 내용은 "IPv6 및 DNS"를 참조하십시오. |
| IN-ADDR.ARPA DNS 도메인의 포인터(PTR) 리소스 레코드를 사용하여 IPv4 주소를 호스트 이름으로 매핑합니다. |
IP6.INT DNS 도메인의 포인터(PTR) 리소스 레코드를 사용하여 IPv6 주소를 호스트 이름으로 매핑합니다. 자세한 내용은 "IPv6 및 DNS"를 참조하십시오. |
LAN 매체 상의 IPv6 패킷
IPv6 패킷을 포함하는 링크 계층 프레임은 다음과 같은 구조를 가집니다.
- 링크 계층 헤더 및 트레일러 – 링크 계층의 IPv6 패킷에 사용된 캡슐화
- IPv6 헤더 – 새로운 IPv6 헤더. 자세한 내용은 "IPv6 헤더"를 참조하십시오.
- 페이로드 – IPv6 패킷의 페이로드. 자세한 내용은 "IPv6 헤더"를 참조하십시오.
그림 1은 IPv6 패킷이 들어 있는 링크 계층 프레임의 구조를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 1 링크 계층의 IPv6 패킷
이더넷, 토큰 링 및 광섬유 분산 FDDI(Fiber Distributed Data Interface) 등의 전형적인 LAN 기술에서, IPv6 패킷은 IEEE 802.3(이더넷), IEEE 802.5(토큰 링) 및 FDDI에 사용되는 SNAP(Sub-Network Access Protocal) 헤더나 이더넷 II 헤더 중 한가지 방법으로 캡슐화됩니다.
이더넷 II 캡슐화
이더넷 II 캡슐화를 사용하는 경우 IPv6 패킷은 이더넷 II 헤더에서 이더넷 종류 필드를 0x86DD로 설정하여 나타냅니다. IPv4는 이더넷 종류 필드를 0x800으로 설정하여 나타냈었습니다. 이더넷 II 캡슐화를 사용하는 경우 IPv6 패킷의 최소 크기는 46바이트이고, 최대 크기는 1,500바이트입니다. 그림 2는 IPv6 패킷에 대한 이더넷 II 캡슐화를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 2 이더넷 II 캡슐화
IEEE 802.3, IEEE 802.5 및 FDDI 캡슐화
IEEE 802.3(이더넷), IEEE 802.5(토큰 링) 및 FDDI 네트워크의 경우에는 SNAP(Sub-Network Access Protocal) 헤더가 사용되며, 이더넷 종류 필드는 IPv6을 나타내기 위해 0x86DD로 설정됩니다. 그림 3은 SNAP 캡슐화를 보여줍니다.
그림 3 IEEE 802.3, IEEE 802.5 및 FDDI에 사용되는 SNAP 캡슐화
SNAP 헤더를 사용하는 IEEE 802.3 캡슐화의 경우, IPv6 패킷의 최소 크기는 38바이트이고 최대 크기는 1,492바이트입니다. SNAP 헤더를 사용하는 FDDI 캡슐화의 경우, IPv6 패킷의 최대 크기는 4,352바이트입니다. IEEE 802.5 네트워크의 최대 IPv6 패킷 크기에 대한 내용은 RFC 2470을 참조하십시오.
Microsoft IPv6 구현
Microsoft는 Microsoft Windows NT용과 Windows 2000용의 두 가지 방식으로 IPv6을 구현했습니다.
- Microsoft Research IPv6 구현은 http://www.research.microsoft.com/msripv6/에 있습니다.
- Windows 2000용 Microsoft IPv6 Technololgy Preview는 http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp에 있습니다.
참고 두 가지 Microsoft IPv6 구현 모두 제품으로 출시되지는 않았습니다. 실제 환경에서 사용하기 위해 만들어진 것이 아니므로 Microsoft 고객 지원 서비스(PSS)에서는 어떠한 경우에도 이를 지원하지 않습니다. Microsoft 제품 그룹으로 버그를 알리고 피드백을 보내는 방법에 대한 자세한 내용은 각 웹 사이트를 참조하십시오.
IPv6 트래픽의 캡처와 구문 분석은 Microsoft Systems Management Server(SMS) 버전 2.0 및 Windows 2000 Server와 함께 제공된 Microsoft 네트워크 모니터에서 지원합니다.
Microsoft Research IPv6 구현
Microsoft Research IPv6 구현은 Windows NT 4.0과 Windows 2000 모두에서 실행되는 IPv6 프로토콜입니다. 현재로서는 Windows 95, Windows 98 또는 Windows CE에 대한 지원 계획이 없습니다. Microsoft Research IPv6 구현은 전송 제어 프로토콜(TCP)과 사용자 데이터그램 프로토콜(UDP)의 자체 버전이 포함된 별개의 프로토콜로 실행됩니다. IPv4 통신에 영향을 미치지 않으면서 IPv6을 시험하는 것이 가능합니다.
Microsoft Research IPv6 구현은 설치용으로 컴파일된 파일, 원본 코드, 다양한 도구와 보조 파일을 포함합니다. 최신 버전과 지원되는 IPv6 기능 및 프로토콜 목록이 필요하면 Microsoft Research IPv6 구현 웹 사이트를 참조하십시오.
Windows 2000용 Micosoft IPv6 Technology Prieview
Windows 2000용 Microsoft IPv6 Technology Preview는 응용 프로그램 개발자를 위한 Microsoft Research IPv6 구현에서 비롯된 것입니다. 궁극적으로는 IPv6 상에서 응용 프로그램을 실행할 수 있도록 IPv6을 배우고 시험하기 위해 사용할 수 있습니다. 이름이 시사하는 것처럼 Windows 2000용 Microsoft IPv6 Technology Preview는 Windows 2000을 실행하는 컴퓨터에만 설치할 수 있습니다.
IPv6 주소 지정
IPv6 주소 공간
가장 두드러진 IPv6의 기능은 훨씬 많은 주소를 사용할 수 있다는 점입니다. IPv6에서 주소의 크기는 IPv4의 4배인 128비트입니다. 32비트 주소 공간에서는 4,294,967,296 주소가 허용됩니다. 128비트 주소 공간은 340,282,266,920,938,463,463,374,607,431,768,211,465(3.4 x 1038) 주소 공간을 허용합니다.
IPv4 주소 공간이 설계되었던 1970년 후반에는 공간이 고갈되리라고 생각도 못했었습니다. 그러나 당시에는 기술의 변화와 요즘의 인터넷 호스트 폭발의 폭발적인 증가를 예상치 못했기 때문에 1992년 경에는 대체가 필수적이라고 할 정도로 IPv4 주소 공간이 소모되었습니다.
IPv6을 사용하면 IPv6 주소 공간이 소모될 것이라는 상상은 더욱더 어려워집니다. 이 숫자를 전체적으로 배치하기 위해 128비트 주소 공간은 지구 표면의 평방 미터 당 655,570,793,348,866,943,898,599(6.5 x 1023)개의 주소를 제공합니다.
1평방 미터의 땅에 6.5 x 1023개의 주소를 가지기 위해 IPv6 주소 길이를 128비트로 만들기로 결정한 것은 아니었습니다. 그보다는, 현재의 인터넷 토폴로지를 반영하는 계층 라우팅 도메인으로 세분하기 위해 IPv6 주소를 상대적으로 크게 만든 것입니다. 128비트를 사용함으로써 현재 IPv4 기반 인터넷에서는 턱없이 부족한 계층적 주소 지정과 라우팅을 여러 수준의 계층 구조로 유연하게 설계할 수 있습니다.
IPv6 주소 지정 아키텍처는 RFC 2373에 설명되어 있습니다.
현재 할당
IPv4 주소 공간을 나눈 방법과 마찬가지로 IPv6 주소 공간도 상위 순서 비트 값에 따라 나누어집니다. 상위 순서 비트와 이 비트의 고정 값은 형식 접두사(FP)라고 합니다.
표 2는 FP별 IPv6 주소 공간의 할당을 보여줍니다.
표 2 현재 IPv6 주소 공간의 할당
| 할당 |
형식 접두사(FP) |
주소 공간의 분수 |
| 예약됨 |
0000 0000 |
1/256 |
| 할당되지 않음 |
0000 0001 |
1/256 |
| NSAP 할당용으로 예약됨 |
0000 001 |
1/128 |
| IPX 할당용으로 예약됨 |
0000 010 |
1/128 |
| 할당되지 않음 |
0000 011 |
1/128 |
| 할당되지 않음 |
0000 1 |
1/32 |
| 할당되지 않음 |
0001 |
1/16 |
| 집계 가능한 글로벌 유니캐스트 주소 |
001 |
1/8 |
| 할당되지 않음 |
010 |
1/8 |
| 할당되지 않음 |
011 |
1/8 |
| 할당되지 않음 |
100 |
1/8 |
| 할당되지 않음 |
101 |
1/8 |
| 할당되지 않음 |
110 |
1/8 |
| 할당되지 않음 |
1110 |
1/16 |
| 할당되지 않음 |
1111 0 |
1/32 |
| 할당되지 않음 |
1111 10 |
1/64 |
| 할당되지 않음 |
1111 110 |
1/128 |
| 할당되지 않음 |
1111 1110 0 |
1/512 |
| 링크 로컬 유니캐스트 주소 |
1111 1110 10 |
1/1024 |
| 사이트 로컬 유니캐스트 주소 |
1111 1110 11 |
1/1024 |
| 멀티캐스트 주소 |
1111 1111 |
1/256 |
IPv6 노드와 함께 사용할 수 있는 현재의 유니캐스트 주소 세트는 집계 가능한 글로벌 유니캐스트 주소, 링크 로컬 유니캐스트 주소 및 사이트 로컬 유니캐스트 주소로 구성됩니다. 이는 전체 IPv6 주소 공간의 15%에 불과합니다.
IPv6 주소 구문
IPv4 주소는 소수점 형식으로 표시됩니다. 이 32비트 주소는 8비트 단위로 나뉘어지며 각 8비트 세트는 그에 상응하는 소수점으로 변환되고 마침표로 구분됩니다. IPv6의 경우, 128비트 주소는 16비트 단위로 나뉘어지며 각 16비트 블록은 4자리 16진수로 변환되고 콜론으로 구분됩니다. 따라서 이러한 표시를 콜론 16진수라고 합니다.
다음은 이진 형식의 IPv6 주소입니다.
0010000111011010100100001101001100000000010100000010111100111011
0000001010101010000000001111111111111110001010001001110001011010
128비트 주소는 16비트 단위로 나뉘어집니다
0010000111011010 1001000011010011 0000000001010000 0010111100111011 0000001010101010 0000000011111111 1111111000101000 1001110001011010
각 16비트 블록은 16진수로 변환되고 콜론으로 구분됩니다. 결과는 다음과 같습니다.
21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A
IPv6 표시는 각 16비트 블록 내에서 앞에 오는 0을 제거하여 더 단순하게 만들 수 있습니다. 그러나 블록마다 최소한 하나의 숫자가 있어야 합니다. 앞에 오는 0을 제거한 주소 표시는 다음과 같습니다.
21DA:D3:0:2F3B:2AA:FF:FE28:9C5A
0 압축
일부 조소에서는 많은 0이 연속해서 나타나기도 합니다. IPv6 주소 표시를 더 단순하게 하기 위해 콜론 16진수 형식에서 0으로 설정된 16비트 블록의 연속 시퀀스를 "::"으로 압축할 수 있습니다.
예를 들면, 링크 로컬 주소 FE80:0:0:0:2AA:FF:FE9A:4CA2를 FE80::2AA:FF:FE9A:4CA2로 압축할 수 있습니다. 멀티캐스트 주소 FF02:0:0:0:0:0:0:2는 FF02::2로 압축할 수 있습니다.
0 압축은 콜론 16진수 표기로 표시된 연속되는 16비트 블록 시리즈를 압축하는데만 사용할 수 있습니다. 16비트 블록의 일부를 포함하는 0 압축은 가능하지 않습니다. 예를 들면, FF02:30:0:0:0:0:0:5를 FF02:3::5로 표시할 수 없습니다.
"::"으로 표시할 0 수는 압축 주소의 블록 수를 계산하고 이 숫자를 8에서 뺀 다음, 그 결과에 16을 곱하여 계산합니다. 예를 들어, 주소 FF02::2에는 두 개의 블록("FF02" 블록과 "2" 블록)이 있습니다. "::"으로 표시된 비트 수는 96(96 = (8 - 2)*16)입니다.
0 압축은 해당 주소마다 한 번만 사용할 수 있습니다. 그렇지 않으면 "::"의 각 인스턴스로 표시된 0비트 수를 결정할 수 없습니다.
IPv6 접두사
접두사는 고정 값을 가진 비트를 표시하는 주소의 일부이거나 네트워크 ID의 비트입니다. IPv6의 접두사는 IPv4의 클래스 도메인간 라우팅(CIDR) 표기와 같은 방법으로 표시됩니다. IPv6 접두사는 주소/접두사-길이 표기를 사용합니다. 예를 들어, FE80::2AA:FF:FE9A:4CA2/64는 주소의 처음 64비트가 네트워크 접두사라는 것을 의미합니다. 접두사 표기는 네트워크나 서브넷 ID를 표시하는 경우에도 사용됩니다. 예를 들어, 21DA:D3::/48은 서브넷입니다.
접두사를 가진 노드 주소는 서브넷 ID를 구하는데 사용할 수 있습니다. 예를 들어, 주소와 접두사 21DA:D3:0:2F3B:2AA:FF:FE28:9C5A/64에서 구한 서브넷 ID는 21DA:D3:0:2F3B::/64입니다.
참고 IPv4 구현에서는 보통 서브넷 마스크라고 하는 네트워크 접두사의 소수점 표시를 사용합니다. IPv6에는 서브넷 마스크가 사용되지 않으며, 접두사 길이 표기만 지원됩니다.
접두사를 비트 경계에 따라 정의할 수 있지만 IPv6 주소의 콜론 16진수 표기는 니블(4비트) 경계에 따라 표시됩니다. 길이가 4의 배수가 아닌 접두사를 가진 서브넷을 올바로 표시하려면 16진수를 이진수로 변환하여 적절한 서브넷 ID를 결정해야 합니다. 예를 들어, 주소와 접두사가 21DA:D3:0:2F3B:2AA:FF:FE28:9C5A/59인 서브넷을 표시하려면 "2F3B"에서 "3"을 이진수(0011)로 변환하고 니블을 세번째와 네번째 이진 숫자 사이에서 나눈 다음, 16진수로 다시 변환해야 합니다. 그 결과는 서브넷 ID 21DA:D3:0:2F20::/59입니다.
IPv6 주소의 종류
IPv6 주소에는 세 가지 종류가 있습니다.
- 유니캐스트
유니캐스트 주소는 유니캐스트 주소 종류의 범위 내에서 단일 인터페이스를 식별합니다. 유니캐스트 주소로 지정된 패킷은 적절한 유니캐스트 라우팅 토폴로지를 통해 단일 인터페이스로 배달됩니다. 로드 균형 시스템을 수용할 수 있도록, RFC 2373은 여러 인터페이스가 호스트에서 IPv6에 대한 단일 인터페이스로 나타나기만 한다면 이들 인터페이스가 동일한 주소를 사용하는 것을 허용합니다.
- 멀티캐스트
멀티캐스트 주소는 여러 인터페이스를 식별합니다. 멀티캐스트 주소로 지정된 패킷은 적절한 멀티캐스트 라우팅 토폴로지를 통해 주소로 식별되는 모든 인터페이스에 배달됩니다.
- 애니캐스트
애니캐스트 주소는 여러 인터페이스를 식별합니다. 애니캐스트 주소로 지정된 패킷은 적절한 멀티캐스트 라우팅 토폴로지를 통해 주소로 식별되는 가장 가까운 인터페이스인 단일 인터페이스로 배달됩니다. "가장 가까운" 인터페이스란 라우팅 거리가 가깝다는 것을 의미합니다. 멀티캐스트 주소는 여러 인터페이스로 배달되는 일대다 통신에 사용됩니다. 애니캐스트 주소는 단일 인터페이스로 배달되는 일대일 통신에 사용됩니다.
모든 경우에 IPv6 주소는 노드가 아닌 인터페이스를 식별합니다. 노드는 해당 인터페이스 중 하나에 할당된 유니캐스트 주소로 식별됩니다.
참고 RFC 2373은 브로드캐스트 주소를 정의하지 않습니다. 모든 종류의 IPv4 브로드캐스트 주소 지정은 멀티캐스트 주소를 사용하여 IPv6에서 수행됩니다. 예를 들어, IPv4의 제한된 브로드캐스트 주소 및 서브넷은 FF02::1이라는 링크-모든 로컬 범위-노드 멀티캐스트 주소로 바뀝니다.
링크 및 서브넷
IPv4와 마찬가지로 IPv6 서브넷 접두사(서브넷 ID)는 하나의 링크에 할당됩니다. 같은 링크에 여러 서브넷 ID를 할당할 수 있습니다. 이러한 기술을 멀티네팅이라고 합니다.
유니캐스트 IPv6 주소
유니캐스트 IPv6 주소의 종류는 다음과 같습니다.
- 집계 가능한 글로벌 유니캐스트 주소
- 링크 로컬 주소
- 사이트 로컬 주소
- 특수 주소
- NSAP 및 IPX 주소
집계 가능한 글로벌 유니캐스트 주소
FP 001로 식별되는 집계 가능한 글로벌 유니캐스트 주소는 공용 IPv4 주소와 같습니다. 6bone(IPv6 백본)이라고 하는 인터넷의 IPv6 부분에서 전체적으로 라우팅하고 연결할 수 있습니다.
이름이 의미하는 것처럼, 집계 가능한 글로벌 유니캐스트 주소는 효율적인 라우팅 인프라를 만들도록 집계 또는 요약됩니다. 기본 라우팅과 계층적 라우팅을 혼합한 현재의 IPv4 기반 인터넷과 달리 IPv6 기반 인터넷은 그 기초부터 효율적이고 계층적인 주소 지정과 라우팅을 지원할 수 있도록 설계되어 있습니다. 고유한 주소가 사용되는 IPv6 네트워크간 영역, 즉 집계 가능한 글로벌 유니캐스트 주소의 범위는 전체 IPv6 인터넷입니다.
그림 4는 집계 가능한 글로벌 유니캐스트 주소의 구조를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 4 집계 가능한 글로벌 유니캐스트 주소
집계 가능한 글로벌 유니캐스트 주소에는 다음과 같은 필드가 있습니다.
TLA ID – 주소에 대한 TLA(Top Level Aggregator)를 나타냅니다. 이 필드의 크기는 13비트입니다. TLA는 라우팅 계층 구조의 최상위 수준을 식별합니다. TLA는 IANA에서 관리하며, 로컬 인터넷 레지스트리에 할당되고 그 후 다시 개별 TLA가 대형 인터넷 서비스 공급자(ISP)에게 할당됩니다. 13비트 필드는 서로 다른 TLA를 최대 8,192까지 허용합니다. IPv6 인터넷 라우팅 계층 구조에서 최상위 수준의 라우터(기본 없는 라우터라고 함)에는 할당된 TLA에 대응하는 16비트 접두사를 갖는 기본 라우터가 없습니다.
예약 – 나중에 TLA ID나 NLA ID의 크기를 확장하는데 사용하기 위해 예약된 비트. 이 필드의 크기는 8비트입니다.
NLA ID – 주소에 대한 NLA(Next-Level Aggregator)를 나타냅니다. NLA ID는 특정 고객 사이트를 식별하는데 사용됩니다. 이 필드의 크기는 24비트입니다. ISP는 NLA ID를 사용하여 네트워크 안에 여러 수준의 주소 지정 계층 구조를 만들어 다운스트림 ISP에 대한 주소 지정과 라우팅을 구성하고 사이트를 식별할 수 있습니다. ISP의 네트워크 구조는 기본 없는 라우터에 대해 투명합니다.
SLA ID – 주소에 대한 SLA(Site-Level Aggregator)를 나타냅니다. SLA ID는 각 조직이 사이트 내의 서브넷을 식별하는데 사용합니다. 이 필드의 크기는 16비트입니다. 조직은 이 사이트 내에서 이러한 16비트를 사용하여 65,536개의 서브넷 또는 여러 수준의 주소 지정 계층 주소와 효율적인 라우팅 인프라를 만들 수 있습니다. 16비트의 서브네팅이 제공하는 유연성으로 인해 조직에 할당된 집계 가능한 글로벌 유니캐스트 접두사는 IPv4 클래스 A 네트워크 ID를 할당하는 조직과 동일합니다(마지막 8진수가 서브넷의 노드 식별에 사용된다고 가정함). 고객의 네트워크 구조는 ISP에 대해 투명합니다.
인터페이스 ID – 특정 서브넷의 인터페이스를 나타냅니다. 이 필드의 크기는 64비트입니다.
집계 가능한 글로벌 유니캐스트 주소 안의 필드는 그림 5에 표시한 세 수준의 구조를 만듭니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 5 집계 가능한 글로벌 유니캐스트 주소의 세 수준 구조
공용 토폴로지는 IPv6 인터넷에 대한 액세스를 제공하는 크고 작은 ISP들의 모음입니다. 사이트 토폴로지는 조직 사이트 내의 서브넷 모음입니다. 인터페이스 ID는 조직의 사이트 내에 있는 서브넷의 특정 인터페이스를 식별합니다. 집계 가능한 글로벌 유니캐스트 주소에 대한 자세한 내용은 RFC 2374를 참조하십시오.
로컬 사용 유니캐스트 주소
로컬 사용 유니캐스트 주소에는 두 가지 종류가 있습니다.
- 온링크 네트워크 환경들 사이와 네트워크 환경 검색 프로세스에서 사용되는 링크 로컬 주소
- 동일한 사이트의 다른 노드와 통신하는 노드들 사이에서 사용되는 사이트 로컬 주소
링크 로컬 주소
FP 1111 1110 10으로 식별되는 링크 로컬 주소는 동일한 링크에 있는 인접 노드와 통신할 때 노드에서 사용합니다. 예를 들어, 라우터가 없는 단일 링크 IPv6 네트워크에서 링크 로컬 주소는 링크 상의 호스트들 사이에서 통신하는데 사용됩니다. 링크 로컬 주소는 접두사 169.254.0.0/16을 사용하여 Microsoft Windows 시스템에서 자동 구성되는 IPv6 주소와 같습니다. 링크 로컬 주소의 범위는 로컬 링크입니다.
링크 로컬 주소는 네트워크 환경 검색 프로세스에 필요하며, 다른 모든 유니캐스트 주소가 없을 때에도 항상 자동으로 구성됩니다. 링크 로컬 주소의 주소 자동 구성 프로세스에 대한 자세한 내용은 "주소 자동 구성"을 참조하십시오.
그림 6은 링크 로컬 주소의 구조를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 6 링크 로컬 주소
링크 로컬 주소는 항상 FE80으로 시작됩니다. 64비트 인터페이스 ID의 경우, 링크 로컬 주소의 접두사는 항상 FE80::/64입니다. IPv6 라우터는 링크를 벗어나서는 링크 로컬 트래픽을 전달하지 않습니다.
사이트 로컬 주소
FP 1111 1110 11로 식별되는 사이트 로컬 주소는 IPv4 개인 주소 공간(10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16)과 같습니다. 예를 들어, IPv6 인터넷으로 직접 라우팅 연결되지 않은 개인용 인트라넷은 집계 가능한 글로벌 유니캐스트 주소와 충돌하지 않고 사이트 로컬 주소를 사용할 수 있습니다. 사이트 로컬 주소는 다른 사이트에서 연결할 수 없으므로 라우터는 사이트 로컬 트래픽을 사이트 밖으로 전달하면 안됩니다. 집계 가능한 글로벌 유니캐스트 주소 외에 사이트 로컬 주소도 사용할 수 있습니다. 사이트 로컬 주소의 범위는 사이트(조직 네트워크간)입니다.
링크 로컬 주소와 달리 사이트 로컬 주소는 자동으로 구성되지 않으며, 스테이트리스 주소나 스테이트풀 주소 구성 프로세스를 통해 할당해야 합니다. 자세한 내용은 "주소 자동 구성"을 참조하십시오.
그림 7은 사이트 로컬 주소의 구조를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 7 사이트 로컬 주소
첫 48비트는 항상 사이트 로컬 주소용으로 고정되며 FEC0::/48로 시작됩니다. 이러한 고정된 48비트 뒤에는 16비트 서브넷 ID(서브넷 ID 필드)가 있으며, 이 ID는 조직 내에서 서브넷을 만드는데 사용되는 16비트를 제공합니다. 16비트를 통해 기본 서브넷 구조에서 최대 65,536개의 서브넷을 가질 수 있으며, 서브넷 ID 필드의 상위 순서 비트를 세분하여 계층적이고 집계 가능한 라우팅 인프라를 만들 수 있습니다. 서브넷 ID 필드 뒤에는 서브넷의 특정 인터페이스를 식별하는 64비트 인터페이스 ID 필드가 있습니다.
집계 가능한 글로벌 유니캐스트 주소와 사이트 로컬 주소는 주소의 첫 48비트 뒤에서 같은 구조를 공유합니다. 집계 가능한 글로벌 유니캐스트 주소에서 SLA ID는 조직 안의 서브넷을 식별합니다. 사이트 로컬 주소의 서브넷 ID도 같은 기능을 수행합니다. 따라서 사이트 로컬 주소와 집계 가능한 글로벌 유니캐스트 주소에 모두 사용되는 서브네팅된 라우팅 인프라 구축이 가능합니다.
특수 IPv6 주소
다음은 특수 IPv6 주소입니다.
- 불특정 주소
불특정 주소(0:0:0:0:0:0:0:0 또는 ::)는 주소 부재를 나타내기 위해 사용됩니다. 이는 IPv4의 불특정 주소 0.0.0.0과 동일합니다. 불특정 주소는 일반적으로 임시 주소의 고유성을 확인하는 패킷의 원본 주소로 사용됩니다. 불특정 주소는 인터페이스에 할당되지 않으며 대상 주소로 사용되지도 않습니다.
- 루프백 주소
루프백 주소(0:0:0:0:0:0:0:1 또는 ::1)는 노드가 스스로에게 패킷을 보낼 수 있는 루프백 인터페이스를 식별하는데 사용됩니다. 이는 IPv4 루프백 주소 127.0.0.1과 동일합니다. 루프백 주소로 지정된 패킷을 링크 상에서 보내거나 IPv6 라우터가 전달하면 안됩니다.
호환 주소
IPv4에서 IPv6으로의 마이그레이션과 두 종류의 호스트의 공존을 지원하기 위해 다음 주소가 정의됩니다.
- IPv4 호환 주소
IPv4 호환 주소 0:0:0:0:0:0:w.x.y.z 또는 ::w.x.y.z(여기에서 w.x.y.z는 IPv4 주소의 소수점 표시임)는 IPv4 인프라 상에서 IPv6과 통신하는 이중 스택 노드에서 사용됩니다. 이중 스택 노드는 IPv4 프로토콜과 IPv6 프로토콜을 가진 노드입니다. IPv4 호환 주소가 IPv6 대상으로 사용되면 IPv6 트래픽은 IPv4 헤더로 자동으로 캡슐화되고 IPv4 인프라를 사용하여 대상으로 전송됩니다.
- IPv4 매핑된 주소
IPv4 매핑된 주소 0:0:0:0:0:FFFF:w.x.y.z 또는 ::FFFF:w.x.y.z는 IPv4 전용 노드를 IPv6 노드로 표시하는데 사용됩니다. 이는 내부 표시용으로만 사용됩니다. IPv4 매핑된 주소는 IPv6 패킷의 원본 주소나 대상 주소로 사용되지 않습니다.
NSAP 및 IPX 주소
네트워크 서비스 액세스 지점(NSAP)과 네트워크간 패킷 교환(IPX) 주소를 IPv6 주소로 매핑하는 방법을 제공하기 위해 NSAP 주소와 IPX 주소가 정의됩니다.
- NSAP 주소
NSAP 주소는 FP 0000001을 사용하며, IPv6 주소의 마지막 121비트를 NSAP 주소로 매핑합니다. 네 종류의 NSAP 주소 매핑에 대한 자세한 내용은 RFC 1888을 참조하십시오.
- IPX 주소
IPX 주소는 FP 0000010을 사용하며, IPv6 주소의 마지막 121비트를 IPX 주소로 매핑합니다. IPv6 주소에 대한 IPX 주소의 매핑은 아직 정의되지 않았습니다.
멀티캐스트 IPv6 주소
IPv6에서 멀티캐스트 트래픽은 IPv4에서와 동일한 방법으로 동작합니다. 임의의 위치에 있는 IPv6 노드는 임의의 IPv6 멀티캐스트 주소에서 멀티캐스트 트래픽을 수신 대기할 수 있습니다. IPv6 노드는 여러 멀티캐스트 주소를 동시에 수신 대기할 수 있습니다. 노드는 언제든지 멀티캐스트 그룹에 조인하거나 떠날 수 있습니다.
IPv6 멀티캐스트 주소는 FP 11111111을 가집니다. IPv6 주소는 항상 "FF"로 시작되기 때문에 쉽게 멀티캐스트로 분류할 수 있습니다. 멀티캐스트 주소는 라우팅 헤더에서 원본 주소나 중간 대상으로 사용할 수 없습니다.
멀티캐스트 주소에서는 FP 뒤에 플래그, 범위 및 멀티캐스트 그룹을 식별하는 추가 필드가 나옵니다. 그림 8은 IPv6 멀티캐스트 주소를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 8 IPv6 멀티캐스트 주소
멀티캐스트 주소에는 다음과 같은 필드가 있습니다.
플래그 – 멀티캐스트 주소의 플래그 세트를 나타냅니다. 이 필드의 크기는 4비트입니다. RFC 2373에서 정의된 유일한 플래그는 임시(T) 플래그입니다. T 플래그는 플래그 필드의 하위 순서 비트를 사용합니다. T 플래그가 0으로 설정되면 멀티캐스트 주소는 IANA(Internet Assigned Numbers Authority)에서 영구 할당한 잘 알려진 멀티캐스트 주소입니다. T 플래그가 1로 설정되면 멀티캐스트 주소는 임시(영구 할당되지 않은) 멀티캐스트 주소입니다.
범위 – 멀티캐스트 트래픽이 예정되는 IPv6 네트워크간 범위를 나타냅니다. 이 필드의 크기는 4비트입니다. 라우터는 멀티캐스트 라우팅 프로토콜에서 제공하는 정보 이외에도 멀티캐스트 범위를 사용하여 멀티캐스트 트래픽의 전달 여부를 결정합니다.
표 3은 범위 필드의 정의된 값을 보여줍니다.
표 3 범위 필드의 정의된 값
| 값 |
범위 |
| 0 |
예약됨 |
| 1 |
노드 로컬 범위 |
| 2 |
링크 로컬 범위 |
| 5 |
사이트 로컬 범위 |
| 8 |
조직 로컬 범위 |
| E |
글로벌 범위 |
| F |
예약됨 |
예를 들어, 멀티캐스트 주소가 FF02::2인 트래픽은 링크 로컬 범위를 가집니다. IPv6 라우터는 로컬 링크 이외에는 이 트래픽을 전달하지 않습니다.
그룹 ID – 멀티캐스트 그룹을 식별하며 범위 내에서 고유합니다. 이 필드의 크기는 112비트입니다. 영구 할당된 그룹 ID는 범위와 무관합니다. 임시 그룹 ID는 특정 범위에만 관련됩니다. FF01::부터 FF0F::까지의 멀티캐스트 주소는 잘 알려진 예약된 주소입니다.
노드 로컬 범위와 링크 로컬 범위에 해당되는 모든 노드를 식별하기 위해 다음 주소가 정의됩니다.
- FF01::1(노드-모든 로컬 범위-노드 멀티캐스트 주소)
- FF02::1(링크-모든 로컬 범위-노드 멀티캐스트 주소)
노드 로컬, 링크 로컬 및 사이트 로컬 범위에 해당되는 모든 라우터를 식별하기 위해 다음 주소가 정의됩니다.
- FF01::2(노드-모든 로컬 범위-라우터 멀티캐스트 주소)
- FF02::2(링크-모든 로컬 범위-라우터 멀티캐스트 주소)
- FF05::2(사이트-모든 로컬 범위-라우터 멀티캐스트 주소)
그룹 ID의 112비트를 사용하여 2112개의 그룹 ID를 가질 수 있습니다. 그러나 IPv6 멀티캐스트 주소는 이더넷 멀티캐스트 MAC 주소로 매핑되기 때문에, RFC 2373은 IPv6 멀티캐스트 주소의 하위 순서 32비트로부터 그룹 ID를 할당하고 나머지 원래의 그룹 ID 비트를 0으로 설정할 것을 권장합니다. 각 그룹 ID는 하위 순서 32비트만 사용하여 고유한 이더넷 멀티캐스트 MAC 주소로 매핑됩니다. 그림 9는 수정된 IPv6 멀티캐스트 주소를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 9 32비트 그룹 ID를 사용하는 수정된 IPv6 멀티캐스트 주소
요청된 노드 주소
요청된 노드 주소는 주소 확인 중에 네트워크 노드를 쿼리하므로 아주 효율적입니다. IPv4의 경우, ARP 요청 프레임은 MAC 수준의 브로드캐스트로 보내져서 IPv4를 실행하지 않는 세그먼트를 포함한 네트워크 세그먼트의 모든 노드를 방해합니다. IPv6은 네트워크 환경 검색 메시지를 사용하여 동일한 기능을 수행합니다. 그러나 로컬 링크의 모든 Ipv6 노드를 방해하는 네트워크 환경 요청 메시지 대상으로 로컬-모든 링크 범위-노드 멀티캐스트 주소를 사용하는 것이 아니라, 요청된 노드 멀티캐스트 주소가 사용됩니다. 요청된 노드 멀티캐스트 주소는 접두사 FF02::1:FF00:0/104와 확인 중인 IPv6 주소의 마지막 24비트로 구성됩니다.
예를 들어, 링크 로컬 IPv6 주소 FE80::2AA:FF:FE28:9C5A를 가진 노드의 경우, 그에 대응하는 요청된 노드 주소는 FF02::1:FF28:9C5A입니다. FE80::2AA:FF:FE28:9C5A 주소를 링크 계층 주소로 확인하기 위해 노드는 네트워크 환경 요청을 FF02::1:FF28:9C5A의 요청된 노드 주소로 보낼 수 있습니다. 주소 FE80::2AA:FF:FE28:9C5A를 사용하는 노드는 요청된 노드 주소의 멀티캐스트 트래픽과 물리 네트워크 어댑터 카드와 일치하는 인터페이스를 수신 대기하며, 네트워크 어댑터 카드를 사용해서 대응하는 멀티캐스트 주소를 등록합니다.
요청된 노드 멀티캐스트 주소를 사용하면 링크에서 공통적으로 발생하는 주소를 확인할 때, 모든 네트워크 노드를 방해하는 메커니즘을 사용하지 않아도 됩니다. 요청된 노드 주소를 사용하면 주소 확인 중에 노드가 거의 방해를 받지 않습니다. 실제로 이더넷 MAC 주소, 인터페이스 ID와 요청된 노드 주소의 관계로 인해 요청된 노드 주소는 효율적인 주소 확인을 위한 의사 유니캐스트 주소의 역할을 합니다.
애니캐스트 IPv6 주소
애니캐스트 주소는 여러 인터페이스에 할당됩니다. 애니캐스트 주소로 지정된 패킷은 애니캐스트 주소가 할당되어 있는 가장 가까운 인터페이스로 인프라를 라우팅하여 전달됩니다. 전달을 쉽게 하려면 애니캐스트 주소가 할당된 인터페이스와 라우팅 미터법에 따른 "거리" 등의 라우팅 인프라를 알아야 합니다. 현재, 애니캐스트 주소는 대상 주소로만 사용되며 라우터에만 할당됩니다. 애니캐스트 주소는 유니캐스트 주소 공간으로부터 할당되며, 애니캐스트 주소의 범위는 애니캐스트 주소를 할당한 유니캐스트 주소 종류의 범위입니다.
서브넷 라우터 애니캐스트 주소는 미리 정의되며 반드시 사용해야 합니다. 이 주소는 해당 인터페이스의 서브넷 접두사로부터 만들어집니다. 서브넷 라우터 애니캐스트 주소를 만들기 위해 서브넷 접두사의 비트가 해당 값에 고정되며, 나머지 비트는 0으로 설정됩니다. 그림 10은 서브넷 라우터 애니캐스트 주소를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 10 서브넷 라우터 애니캐스트 주소
서브넷에 접속되어 있는 모든 라우터 인터페이스에 해당 서브넷에 대한 서브넷 라우터 애니캐스트가 할당됩니다. 서브넷 라우터 애니캐스트 주소는 원격 서브넷에 접속된 여러 라우터 중 하나와 통신하는데 사용됩니다.
호스트용 IPv6 주소
단일 네트워크 어댑터를 가진 IPv4 호스트는 일반적으로 해당 어댑터에 할당한 하나의 IPv4 주소를 가집니다. 그러나 IPv6 호스트는 단일 인터페이스의 경우에도 여러 IPv6 주소를 가집니다. IPv6 호스트에는 다음과 같은 유니캐스트 주소가 할당됩니다.
- 각 인터페이스의 링크 로컬 주소
- 사이트 로컬 주소와 하나 이상의 집계 가능한 글로벌 유니캐스트 주소가 될 수 있는 각 인터페이스의 유니캐스트 주소
- 루프백 주소(::1)
전형적인 IPv6 호스트는 로컬 링크 트래픽을 위한 링크 로컬 주소와 라우팅 가능한 사이트 로컬 주소나 집계 가능한 주소 등, 최소한 두 주소로부터 패킷을 받을 수 있으므로 다중홈의 성격을 띄게 됩니다. 즉, 여러 인터페이스 또는 주소를 가집니다.
그 외에도 각 호스트는 다음과 같은 멀티캐스트 주소에서 트래픽을 수신 대기합니다.
- 노드-모든 로컬 범위-노드 멀티캐스트 주소(FF01::1)
- 링크-모든 로컬 범위-노드 멀티캐스트 주소(FF02::1)
- 각 유니캐스트 주소에 대한 요청된 노드 주소
- 조인된 그룹의 멀티캐스트 주소
라우터용 IPv6 주소
IPv6 라우터에는 다음과 같은 유니캐스트 주소가 할당됩니다.
- 각 인터페이스의 링크 로컬 주소
- 사이트 로컬 주소와 하나 이상의 집계 가능한 글로벌 유니캐스트 주소가 될 수 있는 각 인터페이스의 유니캐스트 주소
- 서브넷 라우터 애니캐스트 주소
- 추가 애니캐스트 주소(옵션)
- 루프백 주소(::1)
그 외에도 각 라우터는 다음과 같은 멀티캐스트 주소에서 트래픽을 수신 대기합니다.
- 노드-모든 로컬 범위-노드 멀티캐스트 주소(FF01::1)
- 노드-모든 로컬 범위-라우터 멀티캐스트 주소(FF01::2)
- 링크-모든 로컬 범위-노드 멀티캐스트 주소(FF02::1)
- 링크-모든 로컬 범위-라우터 멀티캐스트 주소(FF02::1)
- 사이트-모든 로컬 범위-라우터 멀티캐스트 주소(FF05::2)
- 각 유니캐스트 주소에 대한 요청된 노드 주소
- 조인된 그룹의 멀티캐스트 주소
IPv6 인터페이스 ID
001부터 111까지의 접두사를 사용하는 모든 주소는 EUI-64 주소로부터 파생된 64비트 인터페이스 ID도 사용합니다. 64비트 EUI-64 주소는 IEEE(Institue of Electrical and Electronic Engineers)에서 정의합니다. EUI-64 주소는 네트워크 어댑터 카드에 할당되거나 IEEE 802 주소에서 파생됩니다.
참고 이 문서에서는 RFC 2373을 토대로 파생된 IPv6 인터페이스 ID에 대해 검토합니다. IPv6 인터페이스 ID는 사생활 보호에 알맞도록 점차 변경되고 있으며, 이에 대한 내용은 " Privacy Extensions for Stateless Address Autoconfiguration in Ipv6"이라는 제목의 인터넷 초안에 수록되어 있습니다.
IEEE 802 주소
네트워크 어댑터의 기존 인터페이스 ID는 IEEE 802 주소라고 하는 48비트 주소를 사용합니다. 이 ID는 제조업체 ID라고도 하는 24비트 회사 ID와 보드 ID라고도 하는 24비트 확장 ID로 이루어집니다. 각 네트워크 어댑터 제조업체에 고유하게 할당된 회사 ID와 어셈블리 시점에서 각 네트워크 어댑터에 고유하게 할당된 보드 ID는 전체적으로 고유한 48비트 주소를 생성합니다. 이 48비트 주소는 물리 하드웨어 또는 매체 액세스 제어(MAC) 주소라고도 합니다.
그림 11은 48비트 IEEE 802 주소의 구조를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 11 48비트 IEEE 802 주소
IEEE 802 주소 내의 정의된 비트는 다음과 같습니다.
유니버설/로컬(U/L) – 첫번째 바이트에서 다음 하위 순서 비트는 주소의 유니버설 또는 로컬 관리 여부를 표시하는데 사용됩니다. U/L 비트가 0으로 설정되면 IEEE가 회사 고유 ID의 대상을 통해 주소를 관리합니다. U/L 비트가 1로 설정되면 주소는 로컬로 관리됩니다. 네트워크 관리자는 제조된 주소를 무시하고 다른 주소를 지정했습니다. 그림 11에서 U/L 비트는 u로 표시되어 있습니다.
개인/그룹(I/G) – 첫번째 바이트의 하위 순서 비트는 주소가 개인 주소(유니캐스트)인지 아니면 그룹 주소(멀티캐스트)인지 표시하는데 사용됩니다. 주소가 0으로 설정되면 유니캐스트 주소이고, 1로 설정되면 멀티캐스트 주소입니다. 그림 11에서 I/G 비트는 g로 표시되어 있습니다.
전형적인 802.x 네트워크 어댑터 주소에서 U/L 비트와 I/G 비트는 전체적으로 관리되는 유니캐스트 MAC 주소에 대응하는 0으로 설정됩니다.
IEEE EUI-64 인터페이스 ID
IEEE EUI-64 주소는 네트워크 인터페이스 주소 지정의 새로운 표준입니다. 회사 ID의 길이는 여전히 24비트이지만 40비트의 확장 ID를 사용하기 때문에, 네트워크 어댑터 제조업체는 훨씬 큰 주소 공간을 만들 수 있습니다. EUI-64 주소는 IEEE 802 주소와 동일한 방법으로 U/L 비트와 I/G 비트를 사용합니다.
그림 12는 EIU 64 주소의 구조를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 12 EUI-64 주소
EUI-64 주소로 IEEE 802 주소 매핑
IEEE 802 주소에서 EUI-64 주소를 만들기 위해, 그림 13과 같이 11111111 11111110(0xFFFE)의 16비트가 회사 ID와 확장 ID 사이의 IEEE 802 주소에 삽입됩니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 13 EUI 주소로 IEEE 802 주소 변환
IPv6 주소의 인터페이스 ID 받기
IPv6 유니캐스트 주소에 대한 64비트 인터페이스 ID를 받기 위해 EUI-64 주소의 U/L 비트가 보완됩니다. 즉, 1이면 0으로 설정되고 0이면 1로 설정됩니다. 그림 14는 전체적으로 관리되는 유니캐스트 EUI-64 주소의 변환을 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 14 전체적으로 관리되는 유니캐스트 EUI-64 주소를 IPv6 인터페이스 ID로 변환
IEEE 802 주소에서 IPv6 인터페이스 ID를 받으려면 먼저 IEEE 802 주소를 EUI-64 주소로 매핑한 다음, U/L 비트를 보완해야 합니다. 그림 15는 전체적으로 관리되는 유니캐스트 IEEE 802 주소에 대한 이러한 변환 프로세스를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 15 전체적으로 관리되는 유니캐스트 IEEE 802 주소를 IPv6 인터페이스 ID로 변환
IEEE 802 주소 변환 예
호스트 A는 이더넷 MAC 주소 00-AA-00-3F-2A-1C를 가집니다. 먼저 세번째 바이트와 네번째 바이트 사이에 FF-FE를 삽입하고 00-AA-00-FF-FE-3F-2A-1C를 생성하여 EUI-64 형식으로 변환됩니다. 그 다음에는 첫번째 바이트의 일곱번째 비트인 U/L 비트가 보완됩니다. 첫번째 바이트의 이진 형식은 00000000입니다. 일곱번째 비트는 보완된 후 00000010(0x02)이 됩니다. 마지막 결과는 02-AA-00-FF-FE-3F-2A-1C로, 이는 콜론 16진수 표기로 변환하면 인터페이스 ID 2AA:FF:FE3F:2A1C입니다. 그에 따라 MAC 주소 00-AA-00-2A-1C를 갖는 네트워크 어댑터에 대응하는 링크 로컬 주소는 FE80::2AA:FF:FE3F:2A1C입니다.
참고 U/L 비트를 보완할 때 주소가 전체적으로 관리되면 첫번째 바이트에 0x2를 추가하고, 주소가 로컬로 관리되면 첫번째 바이트에서 0x2를 빼십시오.
이더넷 주소로 IPv6 멀티캐스트 주소 매핑
이더넷 링크 상에서 IPv6 멀티캐스트 패킷을 보낼 때 그에 대응하는 대상 MAC 주소는 33-33-mm-mm-mm-mm입니다. 여기에서 mm-mm-mm-mm은 그림 16에서와 같이 IPv6 멀티캐스트 주소의 마지막 32비트를 직접 매핑한 것입니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 16 이더넷 멀티캐스트 MAC 주소로 IPv6 멀티캐스트 주소 매핑
이더넷 링크 상에서 IPv6 멀티캐스트 패킷을 효율적으로 수신하기 위해 이더넷 네트워크 어댑터는 원하는 추가 MAC 주소를 네트워크 어댑터의 테이블에 저장할 수 있습니다. 해당 MAC 주소를 갖는 이더넷 프레임을 수신하면 추가로 처리하기 위해 상위 계층까지 전달됩니다. 호스트에서 수신 대기 중인 모든 멀티캐스트 주소의 경우에는 해당 MAC 주소의 테이블에 그에 대응하는 항목이 있습니다.
예를 들어, 이더넷 MAC 주소가 00-AA-00-3F-2A-1C(FE80::2AA:FF:FE3F:2A1C의 링크 로컬 주소)인 호스트는 이더넷 어댑터를 사용하여 다음과 같은 멀티캐스트 MAC 주소를 등록합니다.
- 링크-모든 로컬 범위-노드 멀티캐스트 주소 FF02::1에 대응하는 주소 33-33-00-00-00-01
- 요청된 노드 주소 FF02::1:FF3F:2A1C에 대응하는 주소 33-33-FF-3F-2A-1C. 요청된 노드 주소는 접두사 FF02::1:FF00:0/104와 유니캐스트 IPv6 주소의 마지막 24비트입니다.
호스트에서 수신 대기 중인 멀티캐스트 주소가 추가되고, 필요하면 이더넷 네트워크 어댑터의 해당 주소 테이블에서 제거됩니다.
IPv6 및 DNS
IPv6에서 도메인 이름 시스템(DNS)의 개선된 점은 RFC 1886에 설명되어 있으며 다음과 같은 새로운 요소로 이루어집니다.
- 호스트 주소(AAAA) 리소스 레코드
- 역방향 쿼리를 위한 IP6.INT 도메인
호스트 주소(AAAA) 리소스 레코드
새 DNS 리소스 레코드 형식 AAAA("quad A"라고 함)는 Ipv6 주소에 대한 정식 도메인 이름을 확인하는데 사용되며, IPv4에서 사용되는 호스트 주소(A) 리소스 레코드와 비교됩니다. 128비트 IPv6 주소가 32비트 IPv4 주소의 네 배이므로 리소스 레코드 형식은 AAAA(형식 값 28)로 명명됩니다. 다음은 AAAA 리소스 레코드에 대한 예입니다.
host1.microsoft.com IN AAAA FEC0::2AA:FF:FE3F:2A1C
호스트는 DNS 쿼리 응답 섹션에서 IPv6 주소 확인 데이터를 받을 수 있도록 특정 호스트 이름으로 AAAA 쿼리 또는 일반 쿼리를 지정해야 합니다.
IP6.INT 도메인
IP6.INT 도메인은 IPv6 역방향 쿼리용으로 만든 것입니다. 포인터 쿼리라고도 하는 역방향 쿼리는 IP 주소를 토대로 호스트 이름을 결정합니다. 역방향 쿼리를 위한 이름 공간을 만들기 위해 전체가 표시된 32 자리 IPv6 주소의 각 16진수 자리는 역방향 도메인 계층 구조에서 순서가 반대인 별개의 수준이 됩니다.
예를 들어, 주소 FEC0::2AA:FF:FE3F:2A1C(FEC0:0000:0000:0000:02AA:00FF:FE3F:2A1C로 전체가 표시됨)의 역방향 조회 도메인 이름은 다음과 같습니다.
C.1.A.2.F.3.E.F.F.F.0.0.A.A.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.IP6.INT
RFC 1886에서 설명한 DNS 지원은 호스트 이름을 IPv6 주소로 매핑하고 역방향 이름 확인을 제공하는 간단한 방법입니다. 그러나 독단적인 비트 경계에서 사이트 번호 다시 매기기나 역방향 조회 영역의 위임으로 인해 변경 내용을 AAAA 레코드로 전파하는 경우, 이 지원이 결코 쉬운 방법은 아닙니다(IP6.INT는 니블 경계에 설계됨). 이 문제는 "DNS Extensions to Support Ipv6 Address Aggregation and Renumbering"이라는 제목의 인터넷 초안에서 설명한 새로운 "A6" 리소스 레코드를 사용하여 처리합니다.
IPv4 주소 및 IPv6 주소
표 4는 IPv4 주소와 주소 지정 개념 및 그에 상응하는 IPv6을 나열합니다.
표 4 현재 IPv6 주소 공간 할당
| IPv4 주소 |
IPv6 주소 |
| 인터넷 주소 클래스 |
IPv6에서는 구현되지 않음 |
| 멀티캐스트 주소(224.0.0.0/4) |
IPv6 멀티캐스트 주소(FF00::/8) |
| 브로드캐스트 주소 |
IPv6에서는 구현되지 않음 |
| 불특정 주소는 0.0.0.0임 |
불특정 주소는 ::임 |
| 조회 주소는 127.0.0.1임 |
조회 주소는 ::1임 |
| 공용 IP 주소 |
집계 가능한 글로벌 유니캐스트 주소 |
| 개인 IP 주소(10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16) |
사이트 로컬 주소(FEC0::/48) |
| 자동 구성된 주소(169.254.0.0/16) |
링크 로컬 주소(FE80::/64) |
| 텍스트 표시: 소수점 표기 |
텍스트 표시: 앞에 오는 0을 제거하고 0을 압축한 콜론 16진수 형식. IPv4 호환 주소는 소수점 표기로 표시됩니다. |
| 네트워크 비트 표시: 서브넷 마스크(소수점 표기 또는 접두사 길이 형식) |
네트워크 비트 표시: 접두사 길이 표기만 |
| DNS 이름 확인: IPv4 호스트 주소(A) 리소스 레코드 |
DNS 이름 확인: IPv6 호스트 주소(AAAA) 리소스 레코드 |
| DNS 역방향 확인: IN-ADDR.ARPA 도메인 |
DNS 역방향 확인: IP6.INT 도메인 |
IPv6 헤더
IPv6 헤더는 IPv4 헤더의 유선형 버전입니다. 필요하지 않거나 좀처럼 사용되지 않는 필드는 제거하고 개선된 실시간 트래픽 지원을 제공하는 필드를 추가했습니다. IPv4 헤더를 검토하면 IPv6 헤더를 이해하는데 도움이 됩니다.
IPv4 헤더
그림 17은 RFC 791에서 설명한 IPv4 헤더를 보여줍니다.
그림 17 IPv4 헤더
IPv4 헤더에는 다음과 같은 필드가 있습니다.
버전 – IP의 버전을 나타내며 4로 설정됩니다. 이 필드의 크기는 4비트입니다.
인터넷 헤더 길이 – IP 헤더의 4바이트 블록 수를 나타냅니다. 이 필드의 크기는 4비트입니다. IP 헤더의 최소 크기는 20바이트이므로 인터넷 헤더 길이(IHL) 필드의 최소값은 5입니다. IP 옵션은 최소 IP 헤더 크기를 4바이트씩 확장할 수 있습니다. IP 옵션이 IP 옵션 필드의 4바이트를 전부 사용하지 않으면 나머지 바이트는 0으로 채워져서 전체 IP 헤더를 32비트(4바이트)의 정수로 만듭니다. 최대값이 0xF이므로 옵션을 포함한 IP 헤더의 최대 크기는 60바이트(15*4)입니다.
서비스 종류 – IP 네트워크 사이에서 라우터를 통해 배달하는 경우 이 패킷에서 예상하는 원하는 서비스를 나타냅니다. 이 필드의 크기는 8비트로, 선행 규칙, 지연, 처리량 및 신뢰도 특성을 포함합니다.
전체 길이 – IP 패킷(IP 헤더 + IP 페이로드)의 전체 길이를 나타내며 링크 계층 프레이밍을 포함하지 않습니다. 이 필드의 크기는 16비트로, 최대 길이가 65,535바이트인 IP 패킷을 나타낼 수 있습니다.
식별 – 이 특정 IP 패킷을 식별합니다. 이 필드의 크기는 16비트입니다. 식별 필드는 IP 패킷의 원래 원본이 선택합니다. IP 패킷이 조각나면 대상 노드가 리어셈블리를 위해 조각들을 그룹화할 수 있도록 모든 조각에 식별 필드 값이 보존됩니다.
플래그 – 조각화 프로세스에 대한 플래그를 식별합니다. 이 필드의 크기는 3비트이지만 현재 사용되는 2비트만 정의됩니다. 플래그는 두 개가 있는데, 하나는 IP 패킷을 조각낼 수 있는지 여부를 나타내고 다른 하나는 현재의 조각 다음에 추가 조각이 있는지 여부를 나타냅니다.
조각 오프셋 – 원래 IP 페이로드에 대해 상대적인 조각의 위치를 나타냅니다. 이 필드의 크기는 13비트입니다.
생존 시간(Time to Live) – 무시하기 전에 IP 패킷이 이동할 수 있는 최대 링크 수를 나타냅니다. 이 필드의 크기는 8비트입니다. 생존 시간(TTL) 필드는 원래 IP 라우터가 IP 패킷을 전달하는데 필요한 시간(초 단위)을 결정하는 시간 크기로 사용되며, 그에 따라 TTL이 감소됩니다. 현재의 라우터는 IP 패킷을 거의 언제나 1초 미만의 짧은 시간에 전달하며 최소 1까지 TTL을 줄이기 위해 RFC 791에서 필요로 합니다. 따라서 TTL은 전송 노드에서 설정한 값을 가진 최대 링크 수가 됩니다. TTL이 0이면 패킷이 무시되고 ICMP 시간 만료 메시지가 원본 IP 주소로 전송됩니다.
프로토콜 – 상위 계층 프로토콜을 식별합니다. 이 필드의 크기는 8비트입니다. 예를 들어, TCP는 프로토콜 6을 사용하고 UDP는 프로토콜 17을 사용하며 ICMP는 프로토콜 1을 사용합니다. 프로토콜 필드는 상위 계층 프로토콜의 IP 패킷 멀티플렉스를 해제하는데 사용됩니다.
헤더 검사값 – IP 헤더에 대한 검사값만 제공합니다. 이 필드의 크기는 16비트입니다. IP 페이로드는 검사값 계산에 IP 페이로드로서 포함되지 않으며, 보통 자체 검사값을 포함합니다. IP 패킷을 받는 각 IP 노드는 IP 헤더 검사값을 확인하고, 검사값 확인에 실패하면 IP 패킷을 무시합니다. 라우터는 IP 패킷을 전달할 때 TTL을 줄여야 합니다. 따라서 헤더 검사값은 원본과 대상 사이의 각 홉마다 다시 계산됩니다.
원본 주소 – 원래 호스트의 IP 주소를 저장합니다. 이 필드의 크기는 32비트입니다.
대상 주소 – 대상 호스트의 IP 주소를 저장합니다. 이 필드의 크기는 32비트입니다.
옵션 – 하나 이상의 IP 옵션을 저장합니다. 이 필드의 크기는 여러 개의 32비트입니다. IP 옵션(들)은 32비트를 모두 사용하지 않으면 IP 헤더가 인터넷 헤더 길이 필드로 나타내는 4바이트 블록의 정수가 되도록 채우기 옵션을 추가해야 합니다.
IPv6 패킷의 구조
그림 18은 IPv6 패킷의 구조를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 18 IPv6 패킷의 구조
IPv6 헤더
IPv6 헤더는 항상 존재하며 40바이트의 고정된 크기를 가집니다. IPv6 헤더에 있는 필드는 이 문서의 뒷부분에서 자세히 설명합니다.
확장 헤더
0개 이상의 확장 헤더가 있을 수 있으며, 길이는 모두 다릅니다. IPv6 헤더에 있는 다음 헤더 필드는 다음 확장 헤더를 나타냅니다. 각 확장 헤더 내에는 다음 확장 헤더를 나타내는 다른 다음 헤더 필드가 있습니다. 마지막 확장 헤더는 상위 계층 프로토콜 데이터 단위 내에 포함된 TCP, UDP 또는 ICMPv6 등의 상위 계층 프로토콜을 나타냅니다.
IPv6 헤더와 확장 헤더는 기존 IPv4 IP 헤더와 달리 옵션으로 사용됩니다. 새 확장 헤더 형식을 사용하면 추후의 요구와 기능을 지원하기 위해 IPv6을 확대하는 것이 가능합니다. IPv4 헤더의 옵션과 달리 IPv6 확장 헤더에는 최대 크기가 없으며 IPv6 통신에 필요한 모든 확장 데이터를 처리할 수 있도록 확장할 수 있습니다.
상위 계층 프로토콜 데이터 단위
상위 계층 프로토콜 데이터 단위(PDU)는 보통 상위 계층 프로토콜 헤더와 ICMPv6 메시지, UDP 메시지 또는 TCP 세그먼트 등의 페이로드로 구성됩니다.
IPv6 패킷 페이로드는 IPv6 확장 헤더와 상위 계층 PDU를 결합한 것입니다. 보통 최대 길이는 65,535바이트까지 가능하며, 길이가 65,535바이트 이상인 페이로드는 홉별 옵션 확장 헤더에 있는 점보 페이로드 옵션을 사용하여 보낼 수 있습니다.
IPv6 헤더
그림 19는 RFC 2460에 정의되어 있는 IPv6 헤더를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 19 IPv6 헤더
IPv6 헤더에는 다음과 같은 필드가 있습니다.
버전 – IP의 버전을 나타내는데 사용되는 4비트로, 6으로 설정됩니다.
트래픽 클래스 – IPv6 패킷의 클래스나 우선 순위를 나타냅니다. 이 필드의 크기는 8비트입니다. 트래픽 클래스 필드는 IPv4 서비스 종류 필드와 유사한 기능을 제공합니다. RFC 2460에서 트래픽 클래스 필드의 값은 정의되지 않습니다. 그러나 IPv6 구현은 실험용 트래픽 클래스 필드의 값을 지정하기 위해 응용 프로그램 계층 프로토콜에 대한 하나의 수단을 제공하는데 필요합니다.
흐름 레이블 – 이 패킷은 원본과 대상 사이의 특정 패킷 시퀀스에 속하므로 중간 IPv6 라우터에 의한 특수 처리가 필요하다는 것을 나타냅니다. 이 필드의 크기는 20비트입니다. 흐름 레이블은 실시간 데이터(음성과 화상)처럼 서비스 연결에 대한 기본 이상의 품질을 제공하기 위해 사용됩니다. 기본 라우터를 처리할 때 흐름 레이블은 0으로 설정됩니다. 원본과 대상 사이에는 0이 아닌 별도의 흐름 레이블로 구별되는 여러 흐름이 있을 수 있습니다.
페이로드 길이 – IP 페이로드의 길이를 나타냅니다. 이 필드의 크기는 16비트입니다. 페이로드 길이 필드는 확장 헤더와 상위 계층 PDU를 포함합니다. 16비트를 사용하므로 IPv6 페이로드를 최대 65,535바이트까지 나타낼 수 있습니다. 길이가 65,535바이트 이상인 페이로드의 경우, 페이로드 길이 필드는 0으로 설정되며, 점보 페이로드 옵션은 홉별 옵션 확장 헤더에서 사용됩니다.
다음 헤더 – 첫번째 확장 헤더(있는 경우) 또는 TCP, UDP 또는 ICMPv6과 같은 상위 계층 PDU의 프로토콜을 나타냅니다. 이 필드의 크기는 8비트입니다. 인터넷 계층 이상의 상위 계층 프로토콜을 나타낼 때 IPv4 프로토콜 필드에 사용된 값과 동일한 값이 여기에서 사용됩니다.
홉 한계 – 무시하기 전에 IPv6 패킷이 이동할 수 있는 최대 링크 수를 나타냅니다. 이 필드의 크기는 8비트입니다. 홉 한계는 패킷이 라우터에서 대기하는 시간(초 단위)과 관계가 없다는 점을 제외하면 IPv4 TTL 필드와 유사합니다. 홉 한계가 0이면 패킷이 무시되고, ICMP 시간 만료 메시지가 원본 주소로 전송됩니다.
원본 주소 – 원래 호스트의 IPv6 주소를 저장합니다. 이 필드의 크기는 128비트입니다.
대상 주소 – 현재 대상 호스트의 IPv6 주소를 저장합니다. 이 필드의 크기는 128비트입니다. 대부분의 경우, 대상 주소는 마지막 대상 주소로 설정됩니다. 그러나 라우팅 확장 헤더가 있으면 대상 주소가 원본 라우터 목록에 있는 그 다음 라우터 인터페이스로 설정될 수 있습니다.
다음 헤더 필드의 값
표 5는 IPv6 헤더 또는 IPv6 확장 헤더에 대한 다음 헤더 필드의 전형적인 값을 보여줍니다.
표 5 다음 헤더 필드의 값
| 값(10진수) |
헤더 |
| 0 |
홉별 옵션 헤더 |
| 6 |
TCP |
| 17 |
UDP |
| 41 |
캡슐화된 IPv6 헤더 |
| 43 |
라우팅 헤더 |
| 44 |
조각 헤더 |
| 46 |
리소스 예약 프로토콜 |
| 50 |
보안 페이로드 캡슐화 |
| 51 |
인증 헤더 |
| 58 |
ICMPv6 |
| 59 |
다음 헤더 없음 |
| 60 |
대상 옵션 헤더 |
IPv4 헤더와 IPv6 헤더 비교
표 6에서는 IPv4 헤더 필드와 IPv6 헤더 필드의 차이점에 대해 설명합니다.
표 6 IPv4 헤더 필드와 IPv6 헤더 필드
| IPv4 헤더 필드 |
IPv6 헤더 필드 |
| 버전 |
같은 필드이지만 버전 번호가 다릅니다. |
| 헤더 길이 |
IPv6에서 제거됨. IPv6 헤더는 항상 40바이트로 고정되어 있기 때문에 IPv6에는 헤더 길이 필드가 포함되지 않습니다. 각 확장 헤더는 고정된 크기이거나 자체 크기를 나타냅니다. |
| 서비스 종류 |
IPv6 트래픽 클래스 필드로 바뀌었습니다. |
| 전체 길이 |
페이로드의 크기만 표시하는 IPv6 페이로드 길이 필드로 바뀌었습니다. |
| 식별 |
IPv6에서 제거됨. 조각화 정보는 IPv6 헤더에 있지 않고 조각 확장 헤더에 있습니다. |
| 조각화 플래그 |
IPv6에서 제거됨. 조각화 정보는 IPv6 헤더에 있지 않고 조각 확장 헤더에 있습니다. |
| 조각 오프셋 |
IPv6에서 제거됨. 조각화 정보는 IPv6 헤더에 있지 않고 조각 확장 헤더에 있습니다. |
| 생존 시간 |
IPv6 홉 한계 필드로 바뀌었습니다. |
| 프로토콜 |
IPv6 다음 헤더 필드로 바뀌었습니다. |
| 헤더 검사값 |
IPv6에서 제거됨. IPv6에서 전체 IPv6 패킷의 비트 레벨 오류 감지는 링크 계층에 의해 수행됩니다. |
| 원본 주소 |
IPv6 주소의 길이가 128비트라는 점을 제외하면 필드가 동일합니다. |
| 대상 주소 |
IPv6 주소의 길이가 128비트라는 점을 제외하면 필드가 동일합니다. |
| 옵션 |
IPv6에서 제거됨. IPv4 옵션이 IPv6 확장 헤더로 바뀌었습니다. |
IPv6 확장 헤더
IPv4 헤더에는 모든 옵션이 포함되어 있습니다. 따라서 각 중간 라우터가 그 존재 여부를 검사해야 하며, 옵션이 있으면 이를 처리해야 합니다. 그로 인해 IPv4 패킷을 전달할 때 성능이 저하될 수 있습니다. IPv6에서는 배달 및 전달 옵션이 확장 헤더로 이동했습니다. 각 중간 라우터에서 처리해야 하는 확장 헤더는 홉별 옵션 확장 헤더뿐입니다. 이 헤더는 IPv6 헤더의 처리 속도를 높이고 전달 프로세스의 성능을 향상시킵니다.
RFC 2460은 모든 IPv6 노드에서 지원해야 하는 다음과 같은 IPv6 확장 헤더를 정의합니다.
- 홉별 옵션 헤더
- 대상 옵션 헤더
- 라우팅 헤더
- 조각 헤더
- 인증 헤더
- 보안 페이로드 캡슐화 헤더
일반적인 IPv6 패킷에는 확장 헤더가 없습니다. 중간 라우터나 대상에서 특수한 처리를 필요로 하면 전송 호스트에서 하나 이상의 확장 헤더를 추가합니다.
각 확장 헤더는 64비트(8바이트) 이내로 구성되어야 합니다. 변수 크기의 확장 헤더는 헤더 확장 길이 필드를 포함하며, 크기가 여러 개의 8바이트로 구성되도록 필요하면 채우기를 사용해야 합니다.
그림 20은 IPv6 헤더의 다음 헤더 필드와 포인터 체인을 형성하는 0개 이상의 확장 헤더를 보여줍니다. 각 포인터는 상위 계층 프로토콜이 확인될 때까지 중간 헤더 다음에 오는 헤더 종류를 나타냅니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 20 IPv6 확장 헤더
확장 헤더 순서
확장 헤더는 존재하는 순서대로 처리됩니다. 경로에 있는 모든 노드에 의해 처리되는 확장 헤더는 유일한 홉별 옵션 헤더이므로 이는 맨 앞에 위치해야 합니다. 다른 확장 헤더에 대한 규칙도 이와 유사합니다. RFC 2460에서는 확장 헤더를 다음 순서대로 IPv6 헤더에 놓을 것을 권장합니다.
- 홉별 옵션 헤더
- 대상 옵션 헤더(라우팅 헤더가 존재할 때 중간 대상에서 필요함)
- 라우팅 헤더
- 조각 헤더
- 인증 헤더
- 보안 페이로드 캡슐화 헤더
- 대상 옵션 헤더(마지막 대상에서 필요함)
홉별 옵션 헤더
홉별 옵션 헤더는 경로의 각 홉에서 대상으로 배달하는 매개 변수를 지정하는데 사용됩니다. IPv6 헤더의 다음 헤더 필드에서 값 0으로 식별됩니다. 그림 21은 홉별 옵션 헤더를 보여줍니다.
그림 21 홉별 옵션 헤더
홉별 옵션 헤더는 다음 헤더 필드, 헤더 확장 길이 필드 및 하나 이상의 옵션이 들어 있는 옵션 필드로 구성됩니다. 헤더 확장 길이 필드의 값은 홉별 옵션 확장 헤더의 8바이트 블록 수(처음 8바이트 제외)입니다. 따라서 8바이트 홉별 옵션 헤더의 경우, 헤더 확장 길이 필드의 값은 0입니다. 채우기 옵션은 8바이트 경계를 확보하는데 사용됩니다.
옵션은 패킷 배달의 특성을 설명하거나 채우기를 제공하는 홉별 옵션 헤더 내에 있는 헤더입니다. 각 옵션은 TCP/IP 프로토콜에서 널리 사용되는 종류-길이-값(TLV) 형식으로 암호화됩니다. 옵션 종류는 옵션을 식별하고 처리 노드에 의한 처리 방법을 결정합니다. 옵션 길이는 길이를 식별합니다. 옵션 값은 옵션과 관련된 데이터입니다.
RFC 2460, 2675 및 2711은 다음 옵션을 정의합니다.
- Pad1 옵션(옵션 종류 0)은 단일 바이트의 채우기를 삽입하는데 사용됩니다.
- PadN 옵션(옵션 종류 1)은 2바이트 이상의 채우기를 삽입하는데 사용됩니다.
- 점보 페이로드 옵션(옵션 종류 194)은 65,535바이트 이상의 페이로드 크기를 나타내는데 사용됩니다. 점보 페이로드 옵션에서는 32비트 점보 페이로드 길이 필드를 사용하여 최대 4,294,967,295바이트의 페이로드 크기를 나타낼 수 있습니다. 페이로드 크기가 65,535 바이트 이상인 IPv6 패킷은 점보그램이라고 합니다.
- 라우터 경보 옵션(옵션 종류 5)은 패킷의 내용을 추가로 처리해야 하는 라우터를 나타내는데 사용됩니다. 라우터 경보 옵션은 멀티캐스트 수신기 검색과 리소스 예약 프로토콜(RSVP)에 사용됩니다.
대상 옵션 헤더
대상 옵션 헤더는 중간 대상이나 마지막 대상에 대한 패킷 배달 매개 변수를 지정하는데 사용됩니다. 이 헤더는 이전 헤더의 다음 헤더 필드에서 값 60으로 식별됩니다. 그림 22는 대상 옵션 헤더를 보여줍니다.
그림 22 대상 옵션 헤더
대상 옵션 헤더 필드는 홉별 옵션 헤더와 동일하게 정의됩니다.
대상 옵션 헤더는 두 가지 방법으로 사용됩니다.
- 라우팅 헤더가 있으면 중간 대상마다 배달 또는 전달 처리 옵션을 지정합니다.
- 마지막 대상에서도 배달 또는 처리 옵션을 지정합니다.
라우팅 헤더
IPv4에서 지원하는 원본 라우팅과 마찬가지로 IPv6 원본 노드는 라우팅 확장 헤더를 사용하여 원본 라우팅, 패킷에 대한 중간 대상 목록을 지정하여 경로 상의 마지막 대상으로 이동할 수 있습니다. 라우팅 헤더는 이전 헤더의 다음 헤더 필드에서 값 43으로 식별됩니다.
라우팅 헤더는 다음 헤더 필드, 헤더 확장 길이 필드(홉별 옵션 확장 헤더와 동일한 방법으로 정의됨), 라우팅 종류 필드, 남은 세그먼트 필드 및 라우팅 종류별 데이터 등으로 구성됩니다.
RFC 2460에 정의된 라우팅 종류 0의 경우, 라우팅 종류별 데이터는 중간 대상 주소의 목록입니다. IPv6 패킷이 중간 대상에 연결되면 라우팅 헤더가 처리되고 남은 세그먼트 필드의 값에 기초한 다음 중간 대상의 주소는 IPv6 헤더에서 대상 주소가 됩니다.
그림 23은 라우팅 종류 0에 대한 라우팅 헤더를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 23 라우팅 종류 0에 대한 라우팅 헤더
조각 헤더
조각 헤더는 IPv6 조각화 및 리어셈블리 서비스에 사용됩니다. 이 헤더는 이전 헤더의 다음 헤더 필드에서 값 44로 식별됩니다. 그림 24는 조각 헤더를 보여줍니다.
그림 24 조각 헤더
조각 헤더는 다음 헤더 필드, 13비트 조각 오프셋 필드, 추가 조각화 플래그 및 32비트의 식별 필드를 포함합니다. 조각 오프셋, 추가 조각화 플래그 및 식별 필드는 그에 해당하는 IPv4 헤더의 필드와 동일한 방법으로 사용됩니다. 8바이트 조각 블록에 대해 조각 오프셋 필드의 사용이 정의되므로 조각 헤더는 IPv6 점보그램에서 사용할 수 없습니다.
IPv6에서는 원본 노드만 페이로드를 조각낼 수 있습니다. 상위 계층 프로토콜에서 제출한 페이로드가 링크나 경로 MTU보다 크면 IPv6이 원본에서 페이로드를 조각내고, 조각 확장 헤더를 사용하여 리어셈블리 정보를 제공합니다.
IPv6 패킷이 조각날 때 처음에는 조각낼 수 없는 부분과 조각낼 수 있는 부분으로 나뉩니다.
- 원래 IPv6 패킷의 조각낼 수 없는 부분은 조각내는 노드와 대상 사이의 각 중간 노드에서 처리해야 합니다. 이 부분은 IPv6 헤더, 홉별 옵션 헤더, 중간 대상용 대상 옵션 헤더 및 라우팅 헤더로 구성됩니다.
- 원래 IPv6 패킷의 조각낼 수 있는 부분은 마지막 대상 노드에서만 처리해야 합니다. 이 부분은 인증 헤더, 보안 페이로드 캡슐화 헤더, 마지막 대상용 대상 옵션 헤더 및 상위 계층 PDU로 구성됩니다.
그 다음에는 IPv6 조각 패킷이 형성됩니다. 각 조각 패킷은 조각낼 수 없는 부분, 조각 헤더 및 조각낼 수 있는 부분으로 구성됩니다.
그림 25는 IPv6 패킷에 대한 조각화 프로세스를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 25 IPv6 조각화 프로세스
인증 헤더
인증 헤더는 데이터 인증(패킷을 보낸 노드의 확인), 데이터 무결성(전송할 때 데이터가 수정되지 않았는지 확인) 및 IPv6 패킷에 대한 재생 방지 보호(캡처된 패킷을 유효한 데이터로 다시 전송하거나 허용할 수 없는지 확인)를 제공합니다. RFC 2402에서 설명한 인증 헤더는 RFC 2401에서 정의한 인터넷 프로토콜에 대한 보안 아키텍처의 일부입니다.
인증 헤더는 이전 헤더의 다음 헤더 필드에서 값 51로 식별됩니다. 그림 26은 인증 헤더를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 26 인증 헤더
인증 헤더에는 다음 헤더 필드, 헤더 길이 필드, 특정 IP 보안(IPSec) 보안 협회(SA)를 식별하는 보안 매개 변수 인덱스(SPI), 재생 방지 보호를 제공하는 시퀀스 번호 필드 및 무결성 검사값(ICV)이 들어 있는 인증 데이터 필드가 있습니다. ICV는 데이터 인증과 무결성을 제공합니다.
인증 확장 헤더는 데이터 암호화에 의한 데이터 기밀유지 서비스를 제공하지 않습니다. 이 서비스를 제공하려면 보안 페이로드 캡슐화(ESP) 헤더와 함께 인증 헤더를 사용하면 됩니다.
인증 헤더가 암호화 기술을 통해 데이터 인증과 무결성을 제공하는 방법에 대한 자세한 내용은 본 문서의 범위를 벗어납니다. 자세한 내용은 RFC 2402를 참조하십시오.
보안 페이로드 캡슐화 헤더 및 트레일러
보안 페이로드 캡슐화(ESP) 헤더와 트레일러는 캡슐화된 페이로드에 데이터 기밀유지, 데이터 인증 및 데이터 무결성 서비스를 제공합니다. 그와 대조적으로 인증 헤더는 전체 IPv6 패킷에 데이터 인증과 무결성 서비스를 제공합니다. ESP 헤더와 트레일러는 이전 헤더의 다음 헤더 필드에서 값 50으로 식별됩니다. 그림 27은 ESP 헤더와 트레일러를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 27 ESP 헤더와 트레일러
ESP 헤더에는 IPSec SA를 식별하는 보안 매개 변수 인덱스(SPI) 필드와 재생 방지 보호를 제공하는 시퀀스 번호 필드가 있습니다. ESP 트레일러에는 채움, 채움 길이, 다음 헤더 및 인증 데이터 필드가 있습니다. 인증 데이터 필드에는 무결성 검사값(ICV)이 있습니다.
ESP 확장 헤더와 트레일러가 암호화 기술을 통해 데이터 기밀유지, 인증 및 무결성을 제공하는 방법에 대한 자세한 정보는 본 문서의 범위를 벗어납니다. 자세한 내용은 RFC 2406을 참조하십시오.
IPv6 MTU
IPv6에서 링크 계층은 최소 1280바이트의 IPv6 패킷을 지원해야 합니다. 이를 지원하지 않는 링크 계층은 IPv6에 투명한 링크 계층 조각화와 리어셈블리 구성표를 제공해야 합니다. 구성 가능한 MTU 크기를 지원할 수 있는 링크 계층의 경우에는 최소한 1500바이트 크기의 MTU(이더넷 II 캡슐화 IPv6 MTU)로 구성하는 것이 좋습니다. 구성 가능한 MTU에 대한 예로는 지점간 프로토콜(PPP) 링크의 최대 수신 단위(MRU)를 들 수 있습니다.
IPv4와 마찬가지로 IPv6은 "경로 MTU 검색"에서 설명한 너무 큰 ICMPv6 패킷 메시지를 사용하는 경로 MTU 검색 프로세스를 제공합니다. 경로 MTU 검색을 사용하면 크기가 1280바이트 이상인 IPv6 패킷을 전송할 수 있습니다.
IPv6 원본 호스트는 앞에서 설명한 프로세스와 조각 헤더를 사용하여 경로 MTU보다 큰 상위 계층 프로토콜의 페이로드를 조각낼 수 있습니다. 그러나 IPv6 조각화를 사용하는 것은 바람직하지 않습니다. IPv6 노드는 최소한 1500바이트의 조각난 패킷을 리어셈블리할 수 있어야 합니다.
상위 계층 검사값
현재 IPv4의 TCP와 UDP에서는 IPv4 원본 주소와 대상 주소 필드가 모두 포함된 의사 헤더를 검사값 계산으로 통합합니다. 이 검사값 계산 방식은 IPv6 주소를 포함할 수 있도록 IPv6 상에서 보낸 TCP와 UDP 트래픽에 맞게 수정해야 합니다. 그림 28은 TCP와 UDP 검사값에 사용해야 하는 새로운 의사 헤더를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 28 IPv6 의사 헤더
IPv6 의사 헤더는 원본 주소, 대상 주소, 상위 계층 PDU의 길이를 나타내는 상위 계층 패킷 길이 필드, 그리고 검사값을 계산할 상위 계층 프로토콜을 나타내는 다음 헤더 필드를 포함합니다.
이 의사 헤더는 ICMPv6 검사값 계산에도 사용됩니다.
ICMPv6
IPv4와 마찬가지로 IPv6은 오류 보고 기능을 제공하지 않습니다. 대신 IPv6은 ICMP 버전 6(ICMPv6)이라는 인터넷 제어 메시지 프로토콜(ICMP)의 업데이트된 버전을 사용합니다. ICMPv6에는 배달이나 전달 오류를 보고하고 문제 해결을 위해 간단한 에코 서비스를 제공하는 공통적인 IPv4 ICMP 기능이 있습니다.
ICMPv6 프로토콜은 다음과 같은 프레임워크도 제공합니다.
- 멀티캐스트 수신기 검색(MLD)
MLD는 서브넷 멀티캐스트 회원 관리를 위해 IPv4용 인터넷 그룹 관리 프로토콜(ICMP)의 버전 2를 대체하는 세 개의 ICMP 메시지입니다. MLD는 "멀티캐스트 수신기 검색" 절에 자세히 설명되어 있습니다.
- 네트워크 환경 검색(ND)
네트워크 환경 검색은 링크 상에서 노드 대 노드 통신을 관리하는 다섯 개의 ICMPv6 메시지입니다. 네트워크 환경 검색은 주소 확인 프로토콜(ARP), ICMPv4 라우터 검색 및 ICMPv4 리디렉트 메시지를 대체합니다. 네트워크 환경 검색은 "네트워크 환경 검색" 절에 자세히 설명되어 있습니다.
ICMPv6은 IPv6 구현에 필요하며 RFC2463에 문서화되어 있습니다.
ICMPv6 메시지 종류
ICMPv6 메시지에는 두 가지 종류가 있습니다.
- 오류 메시지
오류 메시지는 대상 노드나 중간 라우터에서 IPv6 패킷을 전달하거나 배달할 때 발생하는 오류를 보고하는데 사용됩니다. ICMPv6 오류 메시지에 있는 8비트 종류 필드의 값은 0-127(상위 순서 비트는 0으로 설정) 사이의 값입니다. ICMPv6 오류 메시지는 연결할 수 없는 대상, 너무 큰 패킷, 시간 초과 및 매개 변수 문제를 포함합니다.
- 정보 메시지
정보 메시지는 MLD와 네트워크 환경 검색과 같은 진단 기능 및 추가 호스트 기능을 제공하는데 사용됩니다. ICMPv6 정보 메시지에 있는 종류 필드의 값은 128-255(상위 순서 비트는 1로 설정) 사이의 값입니다. ICMPv6 정보 메시지는 RFC 2463에 설명되어 있으며, 에코 요청과 에코 응답을 포함합니다.
ICMPv6 헤더
그림 29는 모든 ICMPv6 메시지의 구조를 보여줍니다.
그림 29 ICMPv6 메시지 구조
ICMPv6 헤더에는 다음과 같은 필드가 있습니다.
종류 – ICMPv6 메시지의 종류를 나타냅니다. 이 필드의 크기는 8비트입니다. ICMPv6 오류 메시지에서 상위 순서 비트는 0으로 설정됩니다. ICMPv6 정보 메시지에서는 상위 순서 비트가 1로 설정됩니다.
코드 – 해당 메시지 종류에 속하는 여러 메시지를 구별합니다. 이 필드의 크기는 8비트입니다. 해당 종류의 메시지가 하나뿐이면 코드 필드는 0으로 설정됩니다.
검사값 – ICMP 메시지의 검사값을 저장합니다. 이 필드의 크기는 16비트입니다. 검사값을 계산할 때 ICMPv6 메시지에 IPv6 의사 헤더가 추가됩니다.
메시지 본문 – ICMPv6 메시지 고유의 데이터가 포함됩니다.
ICMPv6 오류 메시지
ICMPv6 오류 메시지는 라우터나 대상 호스트에서 오류를 전달하거나 배달할 때 발생하는 오류를 보고하는데 사용됩니다.
연결할 수 없는 대상
ICMPv6 연결할 수 없는 대상 메시지는 패킷을 대상으로 전달할 수 없을 때 라우터나 대상 호스트에서 보냅니다. 그림 30은 ICMPv6 연결할 수 없는 대상 메시지를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 30 ICMPv6 연결할 수 없는 대상 메시지
연결할 수 없는 대상 메시지에서 종류 필드는 1로 설정되고 코드 필드는 0-4의 값으로 설정됩니다. 검사값 필드 뒤에는 32비트의 미사용 필드와 ICMPv6 메시지를 포함하는 전체 IPv6 패킷을 1280바이트(최소 IPv6 MTU) 미만으로 만드는 무시된 패킷 부분이 있습니다. IPv6 확장 헤더가 있으면 메시지에 포함되어 있는 무시된 패킷의 바이트 수가 달라집니다. 확장 헤더가 없는 ICMPv6 메시지의 경우, 1280에서 40바이트의 IPv6 헤더와 8바이트의 ICMPv6 연결할 수 없는 대상 헤더를 뺀 크기인 1232바이트의 무시된 패킷이 포함됩니다.
표 7은 여러 개의 연결할 수 없는 대상 메시지에 대한 코드 필드 값을 보여줍니다.
표 7 ICMPv6 연결할 수 없는 대상 메시지
| 코드 값 |
설명 |
| 0 |
라우팅 테이블에 대상과 일치하는 라우트가 없습니다. |
| 1 |
대상과의 통신이 관리 정책에 의해 금지됩니다. 일반적으로 방화벽에서 패킷을 무시할 때 보냅니다. |
| 2 |
주소가 원본 주소의 범위를 벗어납니다. |
| 3 |
대상 주소에 연결할 수 없습니다. 일반적으로 대상의 링크 계층 주소를 확인할 수 없을 때 보냅니다. |
| 4 |
대상 포트에 연결할 수 없습니다. UDP 메시지가 들어 있는 IPv6 패킷이 대상에 도착했지만 대상 UDP 포트에서 수신 대기하는 응용 프로그램이 없을 때 보냅니다. |
너무 큰 패킷
ICMPv6 너무 큰 패킷 메시지는 전달하는 링크에서 링크 MTU가 IPv6 패킷보다 작아서 전달할 수 없을 때 전송됩니다. 그림 31은 ICMPv6 너무 큰 패킷 메시지를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 31 ICMPv6 너무 큰 패킷 메시지
너무 큰 패킷 메시지에서 종류 필드는 2로 설정되고 코드 필드는 0으로 설정됩니다. 검사값 필드 뒤에는 패킷을 전달하고 있는 링크의 링크 MTU를 저장하는 32비트 MTU 필드가 있습니다. 그 다음은 ICMPv6 메시지가 들어 있는 전체 IPv6 패킷을 최대 길이인 1280바이트와 똑같게 만드는 무시된 패킷 부분입니다. 너무 큰 패킷 메시지는 "경로 MTU 검색"에서 설명한 것처럼 IPv6 경로 MTU 검색 프로세스에 사용됩니다.
시간 초과
ICMPv6 시간 초과 메시지는 보통 전달 프로세스 중에 값을 받았거나 값이 감소한 후, IPv6 헤더의 홉 한계 필드가 0일 때 라우터에서 보냅니다. 그림 32는 ICMPv6 시간 초과 메시지를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 32 ICMPv6 시간 초과 메시지
시간 초과 메시지에서 종류 필드는 3으로 설정되고 코드 필드는 0(IPv6 헤더의 홉 한계 필드가 0이 될 때)이나 1(대상 호스트의 조각화 리어셈블리 시간이 초과될 때)로 설정됩니다. 검사값 필드 뒤에는 32비트의 미사용 필드와 ICMPv6 메시지가 포함되는 전체 IPv6 패킷이 1280바이트 미만이 되도록 만드는 무시된 패킷 크기 부분이 있습니다. Code=0이라는 시간 초과 메시지를 받으면 나가는 패킷의 홉 한계가 대상에 연결될 만큼 크지 않거나 라우팅 루프가 있다는 것을 의미합니다.
매개 변수 문제
ICMPv6 매개 변수 문제 메시지는 라우터나 대상에서 보냅니다. IPv6을 더 처리할 수 없게 만드는 오류가 IPv6 헤더나 확장 헤더에서 발생할 때 이 문제가 생깁니다. 그림 33은 ICMPv6 매개 변수 문제 메시지를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 33 ICMPv6 매개 변수 문제 메시지
매개 변수 문제 메시지에서 종류 필드는 4로 설정되고 코드 필드는 0-2의 값입니다. 검사값 필드 뒤에는 오류가 발생한 위반하는 IPv6 패킷의 바이트 오프셋을 표시하는 32비트 포인터 필드가 있습니다. 포인터 필드 뒤은 전체 ICMPv6 메시지가 1280바이트 미만이 되도록 만드는 무시된 패킷 부분입니다. 포인터 필드 값은 오류 위치가 무시된 패킷 부분에 포함되지 않은 경우에도 올바른 오프셋으로 설정됩니다.
표 8은 매개 변수 문제 메시지의 코드 필드 값을 보여줍니다.
표 8 ICMPv6 매개 변수 문제 메시지
| 코드 값 |
설명 |
| 0 |
IPv6 헤더나 확장 헤더 내의 필드에서 오류가 발생했습니다. |
| 1 |
인식할 수 없는 다음 헤더 필드 값이 있습니다. 이 값은 IPv4 연결할 수 없는 대상-연결할 수 없는 프로토콜 메시지와 같습니다. |
| 2 |
인식할 수 없는 IPv6 옵션이 발생했습니다. |
ICMP v6 정보 메시지
RFC 2463에서 정의한 ICMPv6 정보 메시지는 문제 해결에 도움이 되는 진단 기능을 제공합니다.
에코 요청
ICMPv6 에코 요청 메시지는 중간 에코 응답 메시지를 요청하기 위해 대상으로 전송됩니다. 에코 요청/에코 응답 메시지는 다양한 연결성 및 라우팅 문제의 해결에 도움이 되는 간단한 진단을 제공합니다. 그림 34는 ICMPv6 에코 요청 메시지를 보여줍니다.
그림 34 ICMPv6 에코 요청 메시지
에코 요청 메시지에서 종류 필드는 128로 설정되고 코드 필드는 0으로 설정됩니다. 검사값 필드 뒤에는 16비트 ID와 시퀀스 번호 필드가 있습니다. ID 및 시퀀스 번호 필드는 전송 호스트에 의해 설정되며, 들어오는 에코 응답 메시지를 그에 대응하는 에코 요청과 일치시키는데 사용됩니다. 데이터 필드는 전송 호스트에 의해서도 설정되는 0바이트 이상의 옵션 데이터입니다.
에코 응답
ICMPv6 에코 응답 메시지는 ICMPv6 에코 요청 메시지에 대한 응답으로 전송됩니다. 그림 35는 ICMPv6 에코 응답 메시지를 보여줍니다.
그림 35 ICMPv6 에코 응답 메시지
에코 응답 메시지에서 종류 필드는 129로 설정되고 코드 필드는 0으로 설정됩니다. 검사값 필드 뒤에는 16비트 ID와 시퀀스 번호 필드가 있습니다. ID, 시퀀스 번호 및 데이터 필드는 에코 응답 메시지를 처음에 표시했던 에코 요청 메시지에 있는 값과 동일한 값으로 설정됩니다.
ICMPv4 메시지와 ICMPv6 메시지 비교
표 9에는 ICMPv4 메시지와 그에 대응하는 ICMPv6 메시지들이 보여집니다.
표 9 ICMPv4 메시지와 ICMPv6 메시지
| ICMPv4 메시지 |
ICMPv6 메시지 |
| 연결할 수 없는 대상-연결할 수 없는 네트워크(종류 3, 코드 1) |
연결할 수 없는 대상-대상으로 라우팅하지 않음(종류 1, 코드 0) |
| 연결할 수 없는 대상-연결할 수 없는 호스트(종류 3, 코드 1) |
연결할 수 없는 대상-연결할 수 없는 주소(종류 1, 코드 3) |
| 연결할 수 없는 대상-연결할 수 없는 프로토콜(종류 3, 코드 2) |
매개 변수 문제-인식할 수 없는 다음 헤더 필드(종류 4, 코드 1) |
| 연결할 수 없는 대상-연결할 수 없는 포트(종류 3, 코드 3) |
연결할 수 없는 대상-연결할 수 없는 포트(종류 1, 코드 4) |
| 연결할 수 없는 대상-조각화 필요 및 DF 세트(종류 3, 코드 4) |
너무 큰 패킷(종류 2, 코드 0) |
| 연결할 수 없는 대상-관리 목적상 금지된 대상 호스트와의 통신(종류 3, 코드 10) |
연결할 수 없는 대상-관리 목적상 금지된 대상과의 통신(종류 1, 코드 1) |
| 시간 초과-TTL 만료(종류 11, 코드 0) |
시간 초과-홉 한계 초과(종류 3, 코드 0) |
| 시간 초과-조각화 타이머 만료(종류 11, 코드 1) |
시간 초과-조각화 타이머 초과(종류 3, 코드 1) |
| 매개 변수 문제(종류 12, 코드 0) |
매개 변수 문제(종류 4, 코드 0 또는 코드 2) |
| 원본 퀜치(종류 4, 코드 0) |
이 메시지는 IPv6에서 구현되지 않습니다. |
| 리디렉트(종류 5, 코드 0) |
네트워크 환경 검색 리디렉트 메시지(종류 137, 코드 0). 자세한 내용은 "네트워크 환경 검색"을 참조하십시오. |
경로 MTU 검색
경로 MTU는 원본과 대상 사이의 경로에 있는 모든 링크에 대한 최소 링크 MTU입니다. 최대 크기의 경로 MTU를 갖는 IPv6 패킷은 호스트에 의한 조각화가 필요하지 않으며, 경로의 모든 라우터에 의해 전달이 완료됩니다. 경로 MTU를 검색하기 위해, 전송 노드는 ICMP 너무 큰 패킷 메시지의 확인 메일을 사용합니다.
경로 MTU는 다음과 같은 프로세스를 통해 검색됩니다.
- 전송 노드는 경로 MTU가 트래픽이 전달되고 있는 인터페이스의 링크 MTU라고 가정합니다.
- 전송 노드는 경로 MTU 크기에서 IP 데이터그램을 보냅니다.
- 경로의 라우터가 패킷보다 작은 링크 MTU를 갖는 링크 상에서 패킷을 전달하지 못하면 IPv6 패킷을 무시하고 ICMP 너무 큰 패킷 메시지를 전송 노드로 다시 보냅니다. ICMP 너무 큰 패킷 메시지에는 전달하지 못한 링크의 링크 MTU가 포함됩니다.
- 전송 노드는 대상으로 보내는 패킷의 경로 MTU를 ICMPv6 너무 큰 패킷 메시지에 있는 MTU 필드의 값으로 설정합니다.
전송 노드는 2단계에서 다시 시작하고 경로 MTU의 검색에 필요한 횟수만큼 2단계부터 4단계까지 반복합니다. 경로 MTU는 더 이상 ICMPv6 너무 큰 패킷 메시지를 받지 않거나 대상으로부터 승인을 받을 때 결정됩니다.
RFC 1981에서는 IPv6 노드가 경로 MTU 검색을 지원할 것을 권장합니다. 1280바이트의 최소 링크 MTU를 경로 MTU로 사용하면 안됩니다.
경로 MTU의 변경
라우팅 토폴로지의 변경으로 인해 원본과 대상 사이의 경로는 시간이 지남에 따라 바뀔 수 있습니다. 새 경로에 더 낮은 경로 MTU가 필요한 경우, 이전의 프로세스는 3단계에서 시작되며 새 경로 MTU가 검색될 때까지 2단계부터 4단계까지 반복됩니다.
경로 MTU에서의 감소는 ICMP 너무 큰 패킷 메시지의 확인 메일을 통해 즉시 발견됩니다. 경로 MTU에서의 증가는 전송 노드에서 찾아야 합니다. RFC 1981에서 설명한 것처럼, 전송 노드는 ICMPv6 너무 큰 패킷 메시지를 받고 최소 5분(10분이 권장됨) 후에 더 큰 IPv6 패킷을 보낼 수 있습니다.
멀티캐스트 수신기 검색
멀티캐스트 수신기 검색(MLD)은 IPv4의 인터넷 그룹 관리 프로토콜 버전 2(IGMPv2)에 해당하는 IPv6의 기능입니다. MLD는 라우터와 노드가 교환한 메시지 세트로, 라우터는 멀티캐스트 주소 세트에 접속된 각 인터페이스에 대한 수신 대기 노드가 있는지 검색할 수 있습니다. IGMPv2와 마찬가지로 MLD는 각 멀티캐스트 주소에 대한 개별 멀티캐스트 수신기 목록이 아니라 하나 이상의 수신기가 있는 멀티캐스트 주소 목록만 검색합니다. 멀티캐스트 수신기 검색(MLD)은 RFC 2710에 문서화되어 있습니다.
IGMPv2와 달리 MLD는 자체 메시지 구조를 정의하지 않고 ICMPv6 메시지를 사용합니다. 모든 MLD 메시지는 ICMPv6 메시지 종류 130, 131 및 132입니다. MLD 메시지에는 다음과 같은 세 가지 종류가 있습니다.
- 멀티캐스트 수신기 쿼리
멀티캐스트 수신기 쿼리는 멀티캐스트 수신기에 대한 링크를 쿼리하기 위해 라우터에서 사용합니다. 멀티캐스트 수신기 쿼리 메시지는 일반 쿼리와 멀티캐스트 주소 고유의 쿼리의 두 종류가 있습니다. 일반 쿼리는 모든 멀티캐스트 주소의 멀티캐스트 수신기에 대해 쿼리하는데 사용됩니다. 멀티캐스트 주소 고유의 쿼리는 특정 멀티캐스트 주소의 멀티캐스트 수신기에 대해 쿼리하는데 사용됩니다. 두 메시지 종류는 IPv6 헤더에 있는 멀티캐스트 대상 주소와 멀티캐스트 수신기 쿼리 메시지 내에 있는 멀티캐스트 주소로 구별됩니다.
- 멀티캐스트 수신기 보고
멀티캐스트 수신기 보고는 특정 멀티캐스트 주소의 멀티캐스트 트래픽 수신에서 필요하다고 보고하거나 멀티캐스트 수신기 쿼리에 응답하기 위해 멀티캐스트 수신기에서 사용합니다.
- 멀티캐스트 수신기 완료
멀티캐스트 수신기 완료는 특정 멀티캐스트 주소의 멀티캐스트 트래픽 수신에서 더 이상 필요하지 않다고 보고하기 위해 멀티캐스트 수신기에서 사용합니다.
MLD 메시지 패킷은 IPv6 헤더, 홉별 옵션 확장 헤더 및 MLD 메시지로 구성됩니다. 홉별 옵션 확장 헤더에는 RFC 2711에 문서화된 IPv6 라우터 경고 옵션이 있습니다. 이 패킷은 라우터가 수신하지 않는 멀티캐스트 주소로 보낸 MLD 메시지를 라우터가 처리하도록 하는데 사용됩니다. 그림 36은 MLD 메시지 패킷의 형식을 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 36 MLD 메시지 패킷의 형식
멀티캐스트 수신기 쿼리
MLD 멀티캐스트 수신기 쿼리 메시지는 IGMPv2 호스트 회원 쿼리 메시지와 동일합니다. 이 메시지는 접속된 링크에 수신 대기 중인 호스트가 있는지 쿼리하기 위해 라우터에서 사용합니다.
IPv6 헤더에서 원본 주소는 쿼리를 전송할 인터페이스의 링크 로컬 주소입니다. 홉 한계 필드는 1로 설정됩니다. 일반 쿼리에서 대상 주소는 링크-모든 로컬 범위-노드 멀티캐스트 주소(FF02::1)입니다. 멀티캐스트 주소 고유의 쿼리에서 대상 주소는 쿼리 중인 특정 멀티캐스트 주소입니다.
그림 37은 MLD 멀티캐스트 수신기 쿼리 메시지를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 37 MLD 멀티캐스트 수신기 쿼리 메시지
MLD 멀티캐스트 수신기 쿼리 메시지에서 종류 필드는 130으로 설정되고 코드 필드는 0으로 설정됩니다. 검사값 필드 뒤에는 16비트 최대 응답 지연과 예약 필드가 있습니다. 최대 응답 지연은 멀티캐스트 그룹 구성원이 MLD 멀티캐스트 수신기 보고 메시지를 사용하여 회원을 보고하는 최대 시간(밀리초 단위)입니다. 일반 쿼리에서 멀티캐스트 주소 필드는 불특정 주소(::)로 설정됩니다. 멀티캐스트 주소 고유의 쿼리에서 멀티캐스트 주소 필드는 쿼리 중인 특정 멀티캐스트 주소로 설정됩니다.
멀티캐스트 수신기 보고
MLD 멀티캐스트 수신기 보고 메시지는 IGMPv2 호스트 회원 보고 메시지와 같습니다. 특정 멀티캐스트 주소에서 멀티캐스트 트래픽 수신에서 필요하다고 보고하거나 MLD 일반 메시지나 멀티캐스트 주소 고유의 쿼리 메시지에 응답하기 위해 수신 노드에서 사용합니다.
IPv6 헤더에서 원본 주소는 보고서를 보낼 인터페이스의 링크 로컬 주소입니다. 홉 한계 필드는 1로 설정되고 대상 주소는 보고될 특정 멀티캐스트 주소입니다.
그림 38은 MLD 멀티캐스트 수신기 보고 메시지를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 38 MLD 멀티캐스트 수신기 보고 메시지
MLD 멀티캐스트 수신기 보고 메시지에서 종류 필드는 131로 설정되고 코드 필드는 0으로 설정됩니다. 최대 응답 지연 필드는 멀티캐스트 수신기 보고 메시지에 사용되지 않으며 0으로 설정됩니다. 멀티캐스트 주소 필드는 보고될 특정 멀티캐스트 주소로 설정됩니다.
멀티캐스트 수신기 완료
MLD 멀티캐스트 수신기 완료 메시지는 IGMPv2 그룹 유지 메시지와 같습니다. 호스트가 더 이상 특정 멀티캐스트 주소에 대한 수신기가 아니라는 것을 로컬 라우터에 알리기 위해 수신 노드에서 사용합니다.
IPv6 헤더에서 원본 주소는 보고서를 보낼 인터페이스의 링크 로컬 주소입니다. 홉 한계 필드는 1로 설정되고 대상 주소는 링크-모든 로컬 범위-라우터 멀티캐스트 주소(FF02::2)입니다.
그림 39는 MLD 멀티캐스트 수신기 완료 메시지를 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 39 MLD 멀티캐스트 수신기 완료 메시지
MLD 멀티캐스트 수신기 완료 메시지에서 종류 필드는 132로 설정되고 코드 필드는 0으로 설정됩니다. 최대 응답 지연 필드는 멀티캐스트 수신기 완료 메시지에 사용되지 않으며 0으로 설정됩니다. 멀티캐스트 주소 필드는 더 이상 수신기가 아니라는 것을 전송 노드가 로컬 라우터에 알리는 특정 멀티캐스트 주소로 설정됩니다.
네트워크 환경 검색
IPv6 네트워크 환경 검색(ND)은 인접한 노드들 사이의 관계를 결정하는 메시지 및 프로세스 세트입니다. ND는 ARP, ICMP 라우터 검색 및 IPv4에 사용된 ICMP 리디렉트를 대체하며, 추가 기능을 제공합니다.
ND는 다음에서 사용합니다.
- 인접 라우터를 검색하는 호스트
- 주소, 주소 접두사 및 기타 구성 매개 변수를 검색하는 호스트
- IPv6 패킷이 전달될 인접 노드의 링크 계층 주소를 확인하고 인접 노드의 링크 계층 주소 변경 시기를 결정하는 노드
- 네트워크 환경이 연결 가능한지 여부를 결정하는 노드
- 존재 여부, 호스트 구성 매개 변수 및 온링크 접두사를 알리는 라우터
- 특정 대상에 대해 더 나은 패킷 전달용 다음 홉 주소를 호스트에게 알리는 라우터
표 10에는 RFC 2461에 문서화된 ND 프로세스가 수록되어 있습니다.
표 10 IPv6 네트워크 환경 검색 프로세스
| 프로세스 |
설명 |
| 라우터 검색 |
접속된 링크에서 호스트가 로컬 라우터를 검색하는 프로세스. ICMPv4 라우터 검색과 같습니다. 자세한 내용은 "라우터 검색"을 참조하십시오. |
| 접두사 검색 |
호스트가 로컬 링크 대상의 네트워크 접두사를 검색하는 프로세스. ICMPv4 주소 마스크 요청/응답과 유사합니다. 자세한 내용은 "라우터 검색"을 참조하십시오. |
| 매개 변수 검색 |
나가는 패킷에 대한 링크 MTU와 기본 홉 한계를 포함하여 호스트가 추가 운영 매개 변수를 검색하는 프로세스. 자세한 내용은 "라우터 검색"을 참조하십시오. |
| 주소 자동 구성 |
동적 호스트 구성 프로토콜 버전 6(DHCPv6)과 같은 스테이트풀 주소 구성 서버가 있거나 없을 때 인터페이스의 IP 주소를 구성하는 프로세스. 자세한 내용은 "주소 자동 구성"을 참조하십시오. |
| 주소 확인 |
노드가 링크 계층 주소에 대한 네트워크 환경의 IPv6 주소를 확인하는 프로세스. IPv4의 ARP와 같습니다. 자세한 내용은 "주소 확인"을 참조하십시오. |
| 다음 홉 결정 |
노드가 대상 주소에 따라 패킷을 전달할 네트워크 환경의 IPv6 주소를 판별하는 프로세스. 전달 주소나 다음 홉 주소는 대상 주소이거나 온링크 기본 라우터의 주소입니다. 자세한 내용은 "호스트 전송 알고리즘"을 참조하십시오. |
| 네트워크 환경 연결 불가능성 검색 |
네트워크 환경의 IPv6 계층이 더 이상 패킷을 받을 수 없다는 것을 노드가 판별하는 프로세스. 자세한 내용은 "네트워크 환경 연결 불가능성 검색"을 참조하십시오. |
| 중복 주소 검색 |
사용하기로 되어 있는 주소가 인접 노드에서 사용되고 있지 않다는 것을 노드가 판별하는 프로세스. IPv4의 무상 ARP 프레임 사용과 동일합니다. 자세한 내용은 "중복 주소 검색"을 참조하십시오. |
| 리디렉트 기능 |
대상에 연결하는 더 나은 첫번째 홉 IPv6 주소를 호스트에 알리는 프로세스. IPv4 ICMP 리디렉트 메시지와 동일합니다. 자세한 내용은 "리디렉트 기능"을 참조하십시오. |
네트워크 환경 검색 메시지 형식
멀티캐스트 수신기 검색(MLD) 메시지와 마찬가지로 ND 메시지는 ICMPv6 메시지 구조와 133-137의 ICMPv6 종류를 사용합니다. ND 메시지는 그림 40에 보여진 것처럼 ICMPv6 헤더, ND 메시지 고유의 데이터 및 0개 이상의 ND 옵션으로 구성된 ND 메시지 헤더로 되어 있습니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 40 네트워크 환경 검색 메시지의 형식
ND 메시지는 다음과 같은 다섯 가지가 있습니다.
- 라우터 요청
- 라우터 알림
- 네트워크 환경 요청
- 네트워크 환경 알림
- 리디렉트
ND 메시지 옵션은 보통 MAC 주소, 온링크 네트워크 접두사, 온링크 MTU 정보 및 리디렉션 데이터를 포함한 추가 정보를 제공합니다.
로컬 링크 상의 노드에서 시작된 ND 메시지를 받기 위해 홉 한계가 255인 모든 ND 메시지가 전송됩니다. ND 메시지를 받으면 IPv6 헤더에 있는 홉 한계 필드를 검사합니다. 255로 설정되어 있지 않은 메시지는 자동으로 무시됩니다. ND 메시지에 대한 홉 한계 255를 가지는지 확인함으로써 오프링크 노드에서 시작된 ND 기반 네트워크 공격을 처리합니다. 홉 한계가 255이면 오프링크 노드의 ND 메시지가 라우터에 전달될 수 없습니다.
네트워크 환경 검색 옵션
ND 옵션은 그림 41에 보여지는 것처럼 종류-길이-값 형식으로 설정됩니다.
그림 41 네트워크 환경 검색 옵션의 형식
8비트 종류 필드는 ND 옵션의 종류를 나타냅니다. 표 11은 RFC 2461에 정의되어 있는 ND 옵션 종류를 나열합니다.
표 11 IPv6 네트워크 환경 검색 옵션 종류
| 종류: |
옵션 이름 |
| 1 |
원본 링크 계층 주소 |
| 2 |
대상 링크 계층 주소 |
| 3 |
접두사 정보 |
| 4 |
리디렉트 헤더 |
| 5 |
MTU |
8비트 길이 필드는 전체 옵션의 길이를 8바이트 블록으로 나타냅니다. 모든 ND 옵션은 8바이트 이내로 구성되어야 합니다. 변수 길이 값 필드에는 옵션에 대한 데이터가 포함됩니다.
원본/타겟 링크 계층 주소 옵션
원본 링크 계층 주소 옵션은 ND 메시지 보낸 사람의 링크 계층 주소를 나타냅니다. 원본 링크 계층 주소 옵션은 네트워크 환경 요청, 라우터 요청 및 라우터 알림 메시지에 포함되어 있습니다. ND 메시지의 원본 주소가 불특정 주소(::)이면 원본 링크 계층 주소 옵션이 포함되지 않습니다.
타겟 링크 계층 주소 옵션은 IPv6 패킷을 보낼 인접 노드의 링크 계층 주소를 나타냅니다. 타겟 링크 계층 주소 옵션은 네트워크 환경 알림과 리디렉트 메시지에 포함되어 있습니다.
원본 링크 계층 주소 옵션과 타겟 링크 계층 주소 옵션은 그림 42와 동일한 형식을 가집니다.
그림 42 원본 및 타겟 링크 계층 주소 옵션의 형식
원본 링크 계층 주소 옵션에서 종류 필드는 1로 설정되고 타겟 링크 계층 주소 옵션에서는 2로 설정됩니다. 길이 필드는 전체 옵션에서 8바이트 블록의 수로 설정됩니다. 링크 계층 주소 필드는 그 안에 원본이나 타겟의 링크 계층 주소가 들어 있는 변수 길이 필드입니다. IPv6에 대해 정의한 각 링크 계층은 원본 및 타겟 링크 계층 주소 옵션에서 링크 계층 주소의 형식화 방법을 지정해야 합니다.
예를 들어, RFC 2464는 이더넷 네트워크 상에서 IPv6 패킷을 보내는 방법을 정의합니다. 원본 및 타겟 링크 계층 주소 ND 옵션에 대한 형식도 포함합니다. 이더넷의 경우, 링크 계층 주소의 길이는 48비트(6바이트)입니다. 그림 43은 이더넷의 원본 및 타겟 링크 계층 주소 옵션을 보여줍니다.
그림 43 이더넷의 원본 및 타겟 링크 계층 주소 옵션 형식
접두사 정보 옵션
접두사 정보 옵션은 주소 자동 구성에 관한 정보와 주소 접두사 둘 다를 나타내기 위해 라우터 알림 메시지로 전송됩니다. 라우터 알림 메시지에는 여러 개의 주소 접두사를 표시한 여러 접두사 정보 옵션이 있을 수 있습니다. 그림 44는 접두사 정보 옵션의 형식을 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 44 접두사 정보 옵션의 형식
접두사 정보 옵션에는 다음과 같은 필드가 있습니다.
종류 – 이 필드의 값은 3입니다.
길이 – 이 필드의 값은 4이고, 전체 옵션의 길이는 32바이트입니다.
접두사 길이 – 주소 접두사를 포함한 접두사 필드의 선행 비트 수를 나타냅니다. 이 필드의 크기는 8비트입니다. 접두사 길이 필드의 값은 0-128 사이의 값입니다.
온링크 플래그 – 1로 설정되면 포함된 접두사가 지정한 주소를 이 라우터 알림 메시지를 받은 온링크에서 사용할 수 있습니다. 0으로 설정되면 접두사와 일치하는 주소를 온링크에서 사용할 수 없습니다. 이 필드의 크기는 1비트입니다.
자율 플래그 – 1로 설정되면 포함된 접두사가 자율, 즉 스테이트리스 주소 구성을 만드는데 사용됩니다. 0으로 설정되면 포함된 접두사가 스테이트리스 주소 구성을 만드는데 사용되지 않습니다. 이 필드의 크기는 1비트입니다.
예약 필드 1 – 나중에 사용하기 위해 예약된 6비트 필드로, 0으로 설정됩니다.
유효 기간 – 포함된 접두사와 스테이트리스 주소 구성 사용에 따라 주소가 유효한 상태로 유지되는 시간(초 단위)을 나타냅니다. 이 필드의 크기는 32비트입니다. 유효 기간 필드는 포함된 접두사가 온링크 판별 중에 유효한 상태로 유지되는 시간(초 단위)도 나타냅니다. 유효 기간 필드를 0xFFFFFFFF로 설정하면 유효 기간이 무기한으로 설정됩니다.
기본 설정 기간 – 포함된 접두사와 스테이트리스 주소 구성 사용에 따라 주소가 기본 설정 상태로 유지되는 시간(초 단위)을 나타냅니다. 이 필드의 크기는 32비트입니다. 여전히 유효한 스테이트리스 자동 구성 주소는 기본 설정 상태(Preferred State)이거나 사용 지양 상태(Deprecated State)입니다. 기본 설정 상태에서 주소는 무제한 통신에 사용할 수 있습니다. 사용 지양 상태의 주소는 새 통신에서는 사용하지 않는 것이 좋습니다. 그러나 사용 지양 상태의 주소를 사용하여 기존 통신을 계속하는 것은 가능합니다. 주소는 기본 설정 기간이 만료되면 기본 설정 상태에서 사용 지양 상태로 바뀝니다. 기본 설정 기간 필드를 0xFFFFFFFF로 설정하면 유효 기간이 무기한으로 설정됩니다.
예약 필드 2 – 나중에 사용하기 위해 예약된 32비트 필드로, 0으로 설정됩니다.
접두사 – 스테이트리스 자동 구성으로 파생된 IPv6 주소의 접두사를 나타냅니다. 이 필드의 크기는 128비트입니다. 접두사 길이 필드와 접두사 필드를 함께 사용하면 노드에 대한 인터페이스 ID와 결합될 때 IPv6 주소를 만드는 접두사를 명확하게 표현할 수 있습니다. 접두사 길이 필드의 값보다 큰 접두사 필드의 비트는 0으로 설정됩니다. 링크 로컬 접두사는 전송해서는 안되며, 전송된 경우에도 받는 호스트에서 이를 무시합니다.
리디렉트 헤더 옵션
리디렉트 헤더 옵션은 라우터가 리디렉트 메시지를 보내도록 IPv6 패킷을 지정하기 위해 리디렉트 메시지로 전송됩니다. 처음에 보낸 IPv6 패킷의 크기에 따라, 리디렉트된 IPv6 패킷의 전부 또는 일부를 포함할 수 있습니다. 그림 45는 리디렉트 헤더 옵션의 형식을 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 45 리디렉트 헤더 옵션의 형식
리디렉트 헤더 옵션에는 다음과 같은 필드가 있습니다.
종류 – 이 필드의 값은 4입니다.
길이 – 전체 옵션에서 이 필드의 값은 8바이트 블록 수입니다.
예약 필드 – 나중에 사용하기 위해 예약된 48비트 필드로, 0으로 설정됩니다.
리디렉트된 패킷 부분 – IPv6 패킷 또는 리디렉트 메시지를 보낸 IPv6 패킷 부분이 들어 있습니다. 포함되어 있는 원래 패킷의 크기는 전체 리디렉트 메시지 길이를 1280바이트 미만으로 만드는 동안 조정된 패킷 부분입니다.
MTU 옵션
MTU 옵션은 링크의 IPv6 MTU를 나타내기 위해 라우터 알림 메시지로 전송됩니다. 이 옵션은 보통 링크에 대한 IPv6 MTU가 잘 알려져 있지 않거나 변환 가능한 브리지 구성으로 인해 설정이 필요한 경우에만 사용됩니다. MTU 옵션은 인터페이스 하드웨어에서 보고한 IPv6 MTU를 무시합니다.
브리지 또는 계층 2 스위치된 환경의 경우, 동일한 네트워크 세그먼트 상에서 서로 다른 링크 계층 MTU가 서로 다른 링크 계층 기술을 사용할 수 있습니다. 이 경우, 같은 네트워크 상에서 노드 간의 IPv6 MTU 차이는 경로 MTU 검색을 통해서는 발견할 수 없습니다. MTU 옵션은 네트워크 세그먼트 상에서 모든 링크 계층 사용 기술이 지원하는 최상위 IPv6 MTU를 나타내는데 사용됩니다.
그림 46에 있는 스위치된 구성을 고려해 보십시오.
그림 46 MTU 옵션을 활용하는 계층 2 스위치된 환경
두 개의 IPv6 호스트, 즉 호스트 A와 호스트 B는 광섬유 분산 데이터 인터페이스(FDDI) 포트를 사용하여 서로 다른 두 개의 이더넷(계층 2) 스위치에 연결됩니다. 두 스위치는 이더넷 백본으로 연결됩니다. 호스트 A와 호스트 B는 TCP 연결을 협상하며, 각각 4312의 TCP 최대 세그먼트 크기(4352의 FDDI 링크 계층 MTU에서 40바이트의 IPv6 헤더를 뺀 값)를 보고합니다. 연결된 TCP 데이터가 흐르기 시작하면 스위치는 호스트 A와 호스트 B 사이에서 전송되는 1500바이트 이상의 IPv6 패킷은 무시합니다.
MTU 옵션을 통해 네트워크 세그먼트의 라우터(그림에는 나타나 있지 않음)는 네트워크 세그먼트 상의 모든 호스트에 대해 라우터 알림 메시지에 1500의 IPv6 MTU를 보고합니다. 호스트 A와 호스트 B가 IPv6 MTU를 4312에서 1500으로 조정하면 그 사이의 최대 크기 TCP 연결 데이터를 중간 스위치가 무시하지 않습니다.
MTU 옵션의 형식은 그림 47에 보여집니다.
그림 47 MTU 옵션의 형식
MTU 옵션에는 다음과 같은 필드가 있습니다.
종류 – 이 필드의 값은 5입니다.
길이 – 이 필드의 값은 1이고, 전체 옵션에 8바이트가 있습니다.
예약 필드 – 나중에 사용하기 위해 예약된 16비트 필드로, 0으로 설정됩니다.
MTU – 라우터 알림을 받은 링크에 대해 호스트에서 사용해야 하는 IPv6 MTU를 나타냅니다. 이 필드의 크기는 32비트입니다. 링크 MTU보다 큰 MTU 필드의 값은 무시됩니다.
네트워크 환경 검색 메시지
IPv6 ND의 모든 기능은 다음 메시지와 함께 수행됩니다.
- 라우터 요청
- 라우터 알림
- 네트워크 환경 요청
- 네트워크 환경 알림
- 리디렉트
라우터 요청
라우터 요청 메시지는 링크에 있는 IPv6 라우터를 검색하기 위해 IPv6 호스트에서 전송합니다. 호스트는 정기적인 라우터 메시지를 기다리지 않고 멀티캐스트 라우터 요청을 보내 IPv6 라우터에게 즉시 응답하라는 메시지를 표시합니다.
예를 들어, 로컬 링크가 이더넷이라고 가정하는 경우 라우터 요청 메시지의 이더넷 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 보내는 네트워크 어댑터의 MAC 주소로 설정됩니다.
- 대상 주소 필드는 33-33-00-00-00-02로 설정됩니다.
라우터 요청 메시지의 IPv6 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 전송측 인터페이스에 할당된 IPv6 주소나 IPv6 불특정 주소(::)로 설정됩니다.
- 대상 주소 필드는 모든-라우터 링크-로컬 멀티캐스트 주소(FF02::2)로 설정됩니다.
- 홉 한계 필드는 255로 설정됩니다.
라우터 요청 메시지의 형식은 그림 48에 보여집니다.
그림 48 라우터 요청 메시지의 형식
라우터 요청 메시지에는 다음과 같은 필드가 있습니다.
종류 – 이 필드의 값은 133입니다.
코드 – 이 필드의 값은 0입니다.
검사값 – 이 필드의 값은 ICMPv6 검사값입니다.
예약 필드 – 나중에 사용하기 위해 예약된 32비트 필드로, 0으로 설정됩니다.
원본 링크 계층 주소 옵션 – ND 원본 링크 계층 주소 옵션에는 보낸 사람의 링크 계층 주소가 포함됩니다. 이더넷 노드의 경우, 원본 링크 계층 주소에는 전송 호스트의 이더넷 MAC 주소가 포함됩니다. 원본 링크 계층 주소 옵션의 주소는 대응하는 유니캐스트 라우터 알림을 보낸 호스트의 유니캐스트 MAC 주소를 결정하기 위해 수신 라우터에서 사용합니다.
라우터 알림
IPv6 라우터는 라우터 알림 메시지를 정기적으로 또는 라우터 요청 메시지에 대한 응답으로 보냅니다. 그 메시지에는 주소 자동 구성 사용 여부에 관계없이 링크 접두사, 링크 MTU 및 주소 자동 구성을 통해 만들어진 주소가 유효 상태와 기본 설정 상태에 있는 기간을 결정하기 위해 호스트에서 필요로 하는 정보가 포함됩니다.
예를 들어, 로컬 링크를 이더넷이라고 가정하는 경우 라우터 알림 메시지의 이더넷 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 보내는 네트워크 어댑터의 MAC 주소로 설정됩니다.
- 대상 주소 필드는 정기적인 라우터 알림 또는 라우터 요청을 보낸 호스트의 유니캐스트 MAC 주소로 설정됩니다.
라우터 알림 메시지의 IPv6 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 전송측 인터페이스에 할당된 링크 로컬 주소로 설정됩니다.
- 대상 주소 필드는 모든-노드 링크-로컬 멀티캐스트 주소(FF02::1) 또는 라우터 요청 메시지를 보낸 호스트의 유티캐스트 IPv6 주소로 설정됩니다.
- 홉 한계 필드는 255로 설정됩니다.
라우터 알림 메시지의 형식은 그림 49에 보여집니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 49 라우터 알림 메시지의 형식
라우터 알림 메시지에는 다음과 같은 필드가 있습니다.
종류 – 이 필드의 값은 134입니다.
코드 – 이 필드의 값은 0입니다.
검사값 – 이 필드의 값은 ICMPv6 검사값입니다.
현재 홉 한계 – 이 라우터 알림 메시지를 받는 호스트에서 보낸 패킷에 대한 IPv6 헤더에 있는 홉 수 필드의 기본값을 나타냅니다. 이 필드의 크기는 8비트입니다. 현재 홉 한계 0은 홉 수 필드의 기본값이 라우터에서 지정한 값이 아니라는 것을 나타냅니다.
관리된 주소 구성 플래그 – 1로 설정되면 이 라우터 알림 메시지를 받는 호스트가 스테이트리스 주소 자동 구성에서 파생된 주소 이외의 주소를 구하기 위해 스테이트풀 주소 구성 프로토콜(예: DHCPv6)을 사용해야 한다는 것을 의미합니다. 이 필드의 크기는 1비트입니다.
기타 스테이트풀 구성 플래그 – 1로 설정되면 이 라우터 알림 메시지를 받고 있는 호스트가 주소 구성 정보 이외의 정보를 얻기 위해 스테이트풀 주소 구성 프로토콜(예: DHCPv6)을 사용해야 한다는 것을 의미합니다. 이 필드의 크기는 1비트입니다.
예약 필드 – 나중에 사용하기 위해 예약된 6비트 필드로, 0으로 설정됩니다.
라우터 작동 시간 – 라우터의 작동 시간(초 단위)을 기본값으로 나타냅니다. 이 필드의 크기는 16비트입니다. 최대 라우터 작동 시간 값은 65,535초(약 18.2시간)입니다. 라우터 작동 시간 0은 라우터를 기본 라우터로 간주할 수 없다는 것을 의미합니다. 그러나 라우터 알림에 포함되어 있는 나머지 정보는 모두 유효합니다.
연결 가능한 시간 – 연결이 가능하다는 확인을 받은 후 노드를 연결 가능한 인접 노드로 간주할 수 있는 시간 크기(밀리초 단위)를 나타냅니다. 이 필드의 크기는 32비트입니다. 연결 가능한 시간 값 0은 라우터가 연결 가능한 시간을 지정하지 않았다는 것을 의미합니다. 자세한 내용은 "네트워크 환경 연결 불가능성 검색"을 참조하십시오.
재전송 타이머 – 네트워크 환경 요청 메시지의 재전송 사이의 시간 크기(밀리초 단위)를 나타냅니다. 이 필드의 크기는 32비트입니다. 재전송 타이머는 네트워크 환경 연결 불가능성 검색 중에 사용됩니다. 재전송 타이머 값 0은 라우터가 재전송 타이머를 지정하지 않았다는 것을 의미합니다.
원본 링크 계층 주소 옵션 – 원본 링크 계층 주소 옵션에는 네트워크 환경 요청 메시지를 보낸 인터페이스의 링크 계층 주소가 포함됩니다. 여러 링크 계층 주소에서 라우터가 로드 균형을 이루면 이 옵션을 생략할 수 있습니다.
MTU 옵션 – MTU 옵션에는 링크의 MTU가 포함됩니다. 가변 MTU가 있는 온링크 또는 동일한 네트워크 세그먼트에서 여러 링크 계층 기술이 사용된 스위치된 환경에서만 이 옵션을 보낼 수 있습니다.
접두사 정보 옵션 – 접두사 정보 옵션에는 주소 자동 구성에 사용되는 온링크 접두사가 포함됩니다. 로컬 링크 접두사를 접두사 정보 옵션으로서 보내면 안됩니다.
네트워크 환경 요청
네트워크 환경 요청 메시지는 온링크 IPv6 노드의 링크 계층 주소를 검색하기 위해 IPv6 호스트에서 보냅니다. 여기에는 보낸 사람의 링크 계층 주소가 포함됩니다. 전형적인 네트워크 환경 요청은 주소 확인을 위한 멀티캐스트와 인접 노드의 연결 가능성이 확인될 때의 유니캐스트입니다.
예를 들어, 로컬 링크를 이더넷으로 가정하는 경우 네트워크 환경 요청 메시지의 이더넷 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 보내는 네트워크 어댑터의 MAC 주소로 설정됩니다.
- 멀티캐스트 네트워크 환경 요청의 경우, 대상 주소 필드는 타겟의 요청된 노드 멀티캐스트 IP 주소와 일치하는 이더넷 MAC 주소로 설정됩니다. 유니캐스트 네트워크 환경 요청의 경우, 대상 주소 필드는 네트워크 환경의 유니캐스트 MAC 주소로 설정됩니다.
네트워크 환경 요청 메시지의 IPv6 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 전송측 인터페이스에 할당된 IPv6 주소로 설정되거나 중복 주소 검색 중에 IPv6 불특정 주소(::)로 설정됩니다.
- 멀티캐스트 네트워크 환경 요청에서 대상 주소 필드는 타겟의 요청된 노드 멀티캐스트 주소로 설정됩니다. 유니캐스트 네트워크 환경 요청에서 대상 주소 필드는 타겟의 유니캐스트 IP 주소로 설정됩니다.
- 홉 한계 필드는 255로 설정됩니다.
네트워크 환경 요청 메시지의 형식은 그림 50에 보여집니다.
그림 50 네트워크 환경 요청 메시지의 형식
네트워크 환경 요청 메시지에는 다음과 같은 필드가 있습니다.
종류 – 이 필드의 값은 135입니다.
코드 – 이 필드의 값은 0입니다.
검사값 – 이 필드의 값은 ICMPv6 검사값입니다.
예약 필드 – 나중에 사용하기 위해 예약된 32비트 필드로, 0으로 설정됩니다.
타겟 주소 – 타겟의 IP 주소를 나타냅니다. 이 필드의 크기는 128비트입니다.
원본 링크 계층 주소 옵션 – 원본 링크 계층 주소 옵션에는 보낸 사람의 링크 계층 주소가 포함됩니다. 이더넷 노드의 경우, 원본 링크 계층 주소 옵션에는 전송 노드의 이더넷 MAC 주소가 포함됩니다. 원본 링크 계층 주소 옵션의 주소는 대응하는 네트워크 환경 알림을 보낸 노드의 유니캐스트 MAC 주소를 결정하기 위해 수신 노드에서 사용합니다. 중복 주소 검색 도중 원본 IPv6 주소가 불특정 주소(::)이면 원본 링크 계층 주소 옵션이 포함되지 않습니다.
네트워크 환경 알림
네트워크 환경 알림 메시지는 네트워크 환경 요청 메시지에 대한 응답으로 IPv6 노드에서 전송합니다. IPv6 노드는 요청되지 않은 네트워크 환경 알림도 보내서 링크 계층 주소가 변경되었음을 인접 노드에 알립니다. 네트워크 환경 알림에는 노드가 네트워크 환경 알림 메시지의 종류, 보낸 사람의 링크 계층 주소 및 네트워크에 대한 보낸 사람의 역할을 결정하는데 필요한 정보가 포함됩니다.
예를 들어, 로컬 링크를 이더넷으로 가정하는 경우 네트워크 환경 알림 메시지의 이더넷 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 보내는 네트워크 어댑터의 MAC 주소로 설정됩니다.
- 요청된 네트워크 환경 알림의 경우, 대상 주소 필드는 초기 네트워크 환경 요청을 보낸 사람의 유니캐스트 MAC 주소로 설정됩니다. 요청되지 않은 네트워크 환경 알림의 경우, 대상 주소 필드는 33-33-00-00-00-01과 모든-노드 링크-로컬 멀티캐스트 주소와 일치하는 이더넷 MAC 주소로 설정됩니다.
네트워크 환경 알림 메시지의 IPv6 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 전송측 인터페이스에 할당된 링크 로컬 주소로 설정됩니다.
- 대상 주소 필드는 요청된 네트워크 환경 알림의 경우, 초기 네트워크 환경 요청을 보낸 사람의 유니캐스트 IP 주소로 설정됩니다. 요청되지 않은 네트워크 환경 알림의 경우, 대상 주소 필드는 모든-노드 링크-로컬 멀티캐스트 주소(FF02::1)로 설정됩니다.
- 홉 한계 필드는 255로 설정됩니다.
네트워크 환경 알림 메시지의 형식은 그림 51에 보여집니다.
그림 51 네트워크 환경 알림 메시지의 형식
네트워크 환경 알림 메시지에는 다음과 같은 필드가 있습니다.
종류 – 이 필드의 값은 136입니다.
코드 – 이 필드의 값은 0입니다.
검사값 – 이 필드의 값은 ICMPv6 검사값입니다.
라우터 플래그 – 라우터 알림 메시지의 보낸 사람 역할을 나타냅니다. 이 필드의 크기는 1비트입니다. 라우터 플래그는 보낸 사람이 라우터이면 1로 설정되고 보낸 사람이 라우터가 아니면 0으로 설정됩니다. 라우터 플래그는 라우터가 호스트로 변경되는 시기를 결정하기 위해 네트워크 환경 연결 불가능성 검색에서 사용합니다.
요청된 플래그 – 1로 설정되면 네트워크 환경 요청 메시지에 대한 응답으로 네트워크 환경 알림 메시지를 보냈다는 것을 나타냅니다. 이 필드의 크기는 1비트입니다. 요청된 플래그는 네트워크 환경 연결 불가능성 검색 중에 연결 가능성 확인을 위해 사용됩니다. 요청된 플래그는 멀티캐스트 네트워크 환경 알림과 요청되지 않은 유니캐스트 네트워크 환경 알림에서 모두 0으로 설정됩니다.
무시 플래그 – 1로 설정되면 타겟 링크 계층 주소 옵션에 포함된 링크 계층 주소는 기존 네트워크 환경 캐시 항목에 있는 링크 계층 주소를 무시해야 한다는 것을 나타냅니다. 이 필드의 크기는 1비트입니다. 무시 플래그가 0으로 설정된 경우, 링크 계층 주소가 알려져 있지 않으면 인용 부호 안에 있는 링크 계층 주소만 네트워크 환경 캐시 항목을 업데이트합니다. 무시 플래그는 요청된 애니캐스트 주소와 프록시 알림에 대해 0으로 설정되며, 다른 요청 및 요청되지 않은 알림에 대해서는 1로 설정됩니다. 네트워크 환경 캐시에 대한 자세한 내용은 "네트워크 환경 검색 프로세스"를 참조하십시오.
예약 필드 – 나중에 사용하기 위해 예약된 29비트 필드로, 0으로 설정됩니다.
타겟 주소 – 알릴 주소를 나타냅니다. 이 필드의 크기는 128비트입니다. 요청된 네트워크 환경 알림 메시지에서 타겟 주소는 대응하는 네트워크 환경 요청의 타겟 주소 필드에 포함됩니다. 요청되지 않은 네트워크 환경 알림 메시지에서 타겟 주소는 링크 계층 주소를 변경한 주소입니다.
타겟 링크 계층 주소 옵션 – 타겟 링크 계층 주소 옵션에는 네트워크 환경 알림을 보낸 사람인 타겟의 링크 계층 주소가 포함됩니다. 이더넷 노드의 경우, 타겟 링크 계층 주소 옵션에는 전송 노드의 이더넷 MAC 주소가 포함됩니다. 타겟 링크 계층 주소 옵션에 있는 주소는 알리는 노드의 유니캐스트 MAC 주소를 결정하기 위해 수신 노드에서 사용합니다.
리디렉트
리디렉트 메시지는 특정 대상에 대한 더 나은 첫번째 홉 주소를 원시 호스트로 알리기 위해 IPv6 라우터에서 보냅니다. 리디렉트 메시지는 유니캐스트 트래픽을 위해 라우터에서만 보내고 원래 호스트로만 유니캐스트되며 호스트에 의해서만 처리됩니다.
예를 들어, 로컬 링크를 이더넷으로 가정하는 경우 리디렉트 메시지의 이더넷 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 보내는 네트워크 어댑터의 MAC 주소로 설정됩니다.
- 대상 주소 필드는 원래 보낸 사람의 유니캐스트 MAC 주소로 설정됩니다.
네트워크 환경 알림 메시지의 IPv6 헤더에서 필드는 다음과 같이 설정됩니다.
- 원본 주소 필드는 전송측 인터페이스에 할당된 링크 로컬 주소로 설정됩니다.
- 대상 주소 필드는 원래 호스트의 유니캐스트 IP 주소로 설정됩니다.
- 홉 한계 필드는 255로 설정됩니다.
리디렉트 메시지의 형식은 그림 52에 보여집니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 52 리디렉트 메시지의 형식
리디렉트 메시지에는 다음과 같은 필드가 있습니다.
종류 – 이 필드의 값은 137입니다.
코드 – 이 필드의 값은 0입니다.
검사값 – 이 필드의 값은 ICMPv6 검사값입니다.
예약 필드 – 나중에 사용하기 위해 예약된 32비트 필드로, 0으로 설정됩니다.
타겟 주소 – 대상 주소 필드의 노드에 지정된 패킷에 대한 더 나은 다음 홉 주소를 나타냅니다. 이 필드의 크기는 128비트입니다. 오프링크 트래픽의 경우, 타겟 주소 필드는 로컬 라우터의 로컬 링크 주소로 설정됩니다. 온링크 트래픽의 경우, 타겟 주소 필드는 리디렉트 메시지의 대상 주소 필드로 설정됩니다.
대상 주소 – 라우터가 리디렉트 메시지를 보내도록 하는 패킷의 대상 주소가 포함됩니다. 이 필드의 크기는 128비트입니다. 원래 호스트에서 받는 즉시, 타겟 주소와 대상 주소 필드가 대상에 대한 전달 정보를 업데이트하는데 사용됩니다. 호스트가 대상으로 보낸 후속 패킷은 타겟 주소 필드에 있는 주소로 전달됩니다.
타겟 링크 계층 주소 옵션 – 타겟 링크 계층 주소 옵션에는 타겟의 링크 계층 주소(후속 패킷을 보낼 노드)가 포함됩니다. 타겟 링크 계층 주소 옵션은 라우터가 알릴 때에만 포함될 수 있습니다.
리디렉트 헤더 옵션 – 리디렉트 헤더 옵션은 리디렉트 메시지를 보내도록 한 원래 패킷 부분을 포함합니다. 포함되어 있는 원래 패킷 크기는 전체 리디렉트 메시지 길이를 1280바이트 미만으로 만드는 동안 조정된 리디렉트된 패킷 부분입니다.
네트워크 환경 검색 프로세스
ND 프로토콜은 다음과 같은 프로세스에 메시지 교환을 제공합니다.
- 주소 확인(중복 주소 검색 포함)
- 라우터 검색(접두사 및 매개 변수 검색 포함)
- 네트워크 환경 연결 불가능성 검색
- 리디렉트 기능
주소 자동 구성에 대한 자세한 내용은 "주소 자동 구성"을 참조하고, 다음 홉 결정에 대해서는 "호스트 전송 알고리즘"을 참조하십시오.
인접 노드 사이의 상호 작용을 용이하게 만들기 위해 RFC 2461은 다음과 같은 호스트 데이터 구조를 ND 처리를 위한 정보의 저장 방법에 대한 예로서 정의합니다.
- 네트워크 환경 캐시
네트워크 환경의 온링크 IP 주소, 그에 대응하는 링크 계층 주소 및 네트워크 환경의 연결 가능성 상태의 표시를 저장합니다. 네트워크 환경 캐시는 IPv4의 ARP 캐시와 동일합니다.
- 대상 캐시
최근에 트래픽을 보낸 대상의 전달 주소나 다음 홉 IP 주소에 대한 정보를 저장합니다. 대상 캐시의 항목에는 대상 IP 주소(로컬 또는 원격), 확인된 다음 홉 IP 주소 및 대상에 대한 경로 MTU가 있습니다.
- 접두사 목록
온링크 접두사를 나열합니다. 접두사 목록의 각 항목은 직접 연결할 수 있는 대상(네트워크 환경)에 대한 IP 주소의 범위를 정의합니다. 이 목록은 라우터가 라우터 알림 메시지 형태로 알린 접두사로부터 채워집니다.
- 기본 라우터 목록
라우터 알림 메시지를 보낸 온링크 라우터와 기본 라우터의 자격을 갖는 온링크 라우터에 대한 IP 주소를 나열합니다.
RFC 2461에서는 이러한 데이터 구조를 IPv6 호스트 개념 모델에 대한 예로서 정의합니다. 호스트의 외부 동작이 RFC 2461과 일치하는 한 정확한 데이터 구조를 만들기 위해 IPv6을 구현할 필요는 없습니다. 예를 들어, Microsoft Research IPv6 구현과 Windows 2000용 IPv6 Technology Preview에서는 접두사 목록과 기본 라우터 목록이 아닌 라우팅 테이블을 사용합니다.
주소 확인
IPv6 노드에 대한 주소 확인 프로세스는 해당 대상에 대한 온링크 다음 홉 주소의 링크 계층 주소를 확인하는 네트워크 환경 요청 메시지 및 네트워크 환경 알림 메시지의 교환으로 이루어집니다. 전송 호스트는 적절한 인터페이스에서 멀티캐스트 네트워크 환경 요청 메시지를 보냅니다. 네트워크 환경 요청 메시지의 멀티캐스트 주소는 타겟 IP 주소에서 파생된 요청된 노드 멀티캐스트 주소입니다. 네트워크 환경 요청 메시지는 원본 링크 계층 주소 옵션에 있는 전송 호스트의 링크 계층 주소를 포함합니다. 호스트가 대상의 다음 홉 주소를 결정하는 방법에 대한 정보는 "호스트 전송 알고리즘"을 참조하십시오.
타겟 호스트가 네트워크 환경 요청 메시지를 받으면 네트워크 환경 요청 메시지의 원본 주소와 원본 링크 계층 주소 옵션에 있는 링크 계층 주소를 기준으로 자체 네트워크 환경 캐시를 업데이트합니다. 그런 다음, 타겟 노드는 네트워크 환경 요청 보낸 사람에게 유니캐스트 네트워크 환경 알림을 보냅니다. 네트워크 환경 알림은 타겟 링크 계층 주소 옵션을 포함합니다.
타겟으로부터 네트워크 환경 알림을 받은 후, 전송 호스트는 네트워크 환경 캐시를 타겟 링크 계층 주소 옵션에 있는 정보를 기준으로 타겟의 항목을 사용하여 네트워크 환경 캐시를 업데이트합니다. 이 시점에서 전송 호스트와 네트워크 환경 요청의 타겟 사이에서 유니캐스트 IPv6 트래픽이 보내질 수 있습니다.
주소 확인 예
호스트 A는 이더넷 MAC 주소 00-AA-00-11-11-11과 그에 대응하는 링크 로컬 주소 FE80::2AA:FF:FE11:1111을 가집니다. 호스트 B는 이더넷 MAC 주소 00-AA-00-22-22-22와 그에 대응하는 링크 로컬 주소 FE80::2AA:FF:FE22:2222를 가집니다. 패킷을 호스트 B로 보내려면 호스트 A가 주소 확인을 사용하여 호스트 B의 링크 계층 주소를 확인해야 합니다.
호스트 B의 IP 주소를 기준으로 호스트 A는 요청된 노드 멀티캐스트 네트워크 환경 요청을 그림 53과 같이 주소 FF02::1:FF22:2222로 보냅니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 53 주소 확인을 위한 멀티캐스트 네트워크 환경 요청
이더넷 어댑터를 사용해서 요청된 노드 멀티캐스트 주소 33-33-22-22-22-22를 등록한 호스트 B는 네트워크 환경 요청을 받고 처리합니다. 호스트 B는 그림 54와 같이 유니캐스트 네트워크 환경 알림 메시지로 응답합니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 54 주소 확인을 위한 유니캐스트 네트워크 환경 알림
중복 주소 검색
IPv4 노드는 ARP 요청 메시지와 무상 ARP라는 방법을 사용하여 로컬 링크에서 중복 IP 주소를 검색합니다. 마찬가지로 IPv6 노드는 네트워크 환경 알림 메시지를 사용하여 로컬 링크에서 중복 주소가 사용되고 있는지 검색합니다.
IPv4 무상 ARP를 통해 ARP 요청 메시지 헤더의 원본 프로토콜 주소와 타겟 프로토콜 주소 필드는 중복을 검색할 IPv4 주소로 설정됩니다. IPv6 중복 주소 검색에서 네트워크 환경 요청 메시지의 타겟 주소 필드는 중복이 검색될 IPv6 주소로 설정됩니다.
중복 주소 검색은 다음과 같은 점에서 주소 확인과 다릅니다.
- 중복 주소 검색 네트워크 환경 요청 메시지에서 IPv6 헤더의 원본 주소 필드는 불특정 주소(::)로 설정됩니다. 중복 여부를 쿼리 중인 주소는 중복이 없다고 결정될 때까지 사용할 수 없습니다.
- 중복 주소 검색 네트워크 환경 요청 메시지에 대한 네트워크 환경 알림 응답에서 IP 헤더의 대상 주소는 링크-모든 로컬 범위-노드 멀티캐스트 주소(FF02::1)로 설정됩니다. 네트워크 환경 알림 메시지의 요청된 플래그는 0으로 설정됩니다. 중복 주소 검색 네트워크 환경 요청 메시지의 보낸 사람이 원하는 IP 주소를 사용하지 않으므로 유니캐스트 네트워크 환경 알림은 받을 수 없습니다. 따라서 네트워크 환경 알림에는 멀티캐스트 형식을 사용해야 합니다.
중복 여부를 검색할 IP 주소로 타겟 주소 필드가 설정된 멀티캐스트 네트워크 환경 알림을 받는 즉시, 노드는 인터페이스에서 중복 IP 주소를 사용하지 않도록 설정합니다. IPv6 주소의 사용을 막는 네트워크 환경 알림을 노드가 수신하지 않은 경우, 그 노드는 인터페이스에서 주소를 초기화합니다.
중복 주소 검색 예
호스트 B는 링크 로컬 주소 FE80::2AA:FF:FE22:2222를 가집니다. 호스트 A는 링크 로컬 주소 FE80::2AA:FF:FE22:2222를 사용하려고 합니다. 그러나 호스트 A가 이 링크 로컬 주소를 사용하기 전에 중복 주소 검색을 통해 그 고유성을 확인해야 합니다.
호스트 A는 그림 55와 같이 요청된 노드 멀티캐스트 네트워크 환경 요청을 주소 FF02::1:FF22:2222로 보냅니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 55 중복 주소 검색을 위한 멀티캐스트 네트워크 환경 요청
이더넷 어댑터를 사용해서 요청된 노드 멀티캐스트 주소 33-33-22-22-22-22를 등록한 호스트 B는 네트워크 환경 요청을 받고 처리합니다. 호스트 B는 원본 주소가 불특정 주소라고 기록합니다. 그런 다음, 호스트 B는 그림 56과 같이 멀티캐스트 네트워크 환경 알림 메시지를 사용해서 응답합니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 56 중복 주소 검색을 위한 멀티캐스트 네트워크 환경 알림
라우터 검색
라우터 검색은 노드가 로컬 링크에서 라우터 세트를 검색하려 시도하는 프로세스입니다. IPv6에서 라우터 검색은 RFC 1256에 설명된 IPv4의 ICMP 라우터 검색과 유사합니다.
ICMPv4 라우터 검색과 IPv6 라우터 검색의 중요한 차이점은 현재의 라우터를 사용할 수 없을 때 새 기본 라우터를 선택하는 메커니즘입니다. ICMPv4 라우터 검색에서 라우터 알림 메시지는 알림 작동 시간 필드를 포함합니다. 알림 작동 시간은 마지막 라우터 알림 메시지를 수신할 때 라우터를 사용할 수 없다고 간주할 수 있는 시간입니다. 최악의 경우 라우터를 사용할 수 없게 될 수도 있으며, 호스트는 라우터 알림 시간이 경과할 때까지 새 기본 라우터를 검색하지 않습니다.
IPv6의 경우, 라우터 알림 메시지에는 라우터 작동 시간 필드가 포함됩니다. 이 필드는 라우터를 기본 라우터로 간주할 수 있는 시간을 나타냅니다. 그러나 현재의 기본 라이터를 사용할 수 없게 되면, 라우터 알림 메시지에 있는 라우터 작동 시간 필드가 아닌 네트워크 환경 연결 불가능성 검색을 통해 상태를 감지합니다. 네트워크 환경 연결 불가능성 검색 결과, 더 이상 라우터를 연결할 수 없다고 판단되면 곧바로 기본 라우터 목록에서 새 라우터가 선택됩니다. 자세한 내용은 "네트워크 환경 연결 불가능성 검색"을 참조하십시오.
IPv6 라우터 검색을 통해 기본 라우터 구성 외에도 다음 사항을 구성할 수 있습니다.
- IPv6 헤더의 홉 한계 필드에 대한 기본 설정
- 주소 및 그외 다른 구성 매개 변수에 대하여 IPv6의 동적 호스트 구성 프로토콜(DHCPv6) 등의 스테이트풀 주소 프로토콜을 노드에서 사용해야 하는지 여부 결정
- 네트워크 환경 요청의 연결 가능성 검색과 재전송에 사용되는 타이머
- 링크에 대해 정의된 네트워크 접두사의 목록. 각 네트워크 접두사에는 IPv6 네트워크 접두사와 유효 기간 및 기본 설정 기간 모두 포함됩니다. 이 목록이 나타난 경우, 수신측 인터페이스에 대해 인터페이스 ID와 결합된 네트워크 접두사가 스테이트리스 IP 주소 구성을 만듭니다. 네트워크 접두사는 로컬 링크의 노드에 대한 주소 범위도 정의합니다.
- 로컬 링크의 MTU
IPv6 라우터 검색 프로세스는 다음과 같습니다.
- 로컬 링크에서 IPv6 라우터는 자신을 라우터라고 알리는 라우터 알림 메시지를 정기적으로 보냅니다. 또한 기본 홉 한계, MTU 및 접두사와 같은 구성 매개 변수도 제공합니다.
- 로컬 링크 상에 있는 사용 중인 IPv6 호스트는 라우터 알림 메시지를 받고 그 내용을 사용하여 기본 라우터 목록, 접두사 목록 및 기타 구성 매개 변수를 유지 관리합니다.
- 시작되는 호스트는 라우터 요청 메시지를 링크-모든 로컬 범위-라우터 멀티캐스트 주소(FF02::2)로 보냅니다. 라우터 요청 메시지를 받는 즉시, 로컬 링크 상의 모든 라우터는 라우터 요청을 보낸 노드로 유니캐스트 라우터 알림 메시지를 보냅니다. 노드는 라우터 알림 메시지를 받고 그 내용을 사용하여 기본 라우터와 접두사 목록을 구성하고 기타 구성 매개 변수를 만듭니다. 라우터 검색 프로세스를 중단하기 전에 보내는 라우터 요청 수는 구성 가능한 변수를 사용해서 설정됩니다. RFC 2461은 변수 이름 MAX_RTR_SOLICITATIONS를 사용하며 값 3을 사용할 것을 권장합니다.
라우터 및 접두사 검색 예
호스트 A는 이더넷 MAC 주소 00-AA-00-11-11-11과 그에 대응하는 링크 로컬 주소 FE80::2AA:FF:FE11:1111을 가집니다. 라우터 1은 이더넷 MAC 주소 00-AA-00-22-22-22와 그에 대응하는 링크 로컬 주소 FE80::2AA:FF:FE22:2222를 가집니다. 패킷을 오프링크 대상으로 전달하기 위해 호스트 A는 라우터 1이 있는지를 검색해야 합니다.
호스트 A는 그림 57과 같이 멀티캐스트 라우터 요청을 주소 FF02::2로 보냅니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 57 라우터와 접두사 검색을 위한 멀티캐스트 라우터 요청
이더넷 어댑터를 사용해서 멀티캐스트 주소 33-33-00-00-00-02를 등록한 라우터 1은 라우터 요청을 받고 처리합니다. 라우터 1은 그림 58에서 보는 것처럼 구성 매개 변수와 로컬 링크 접두사가 들어 있는 유니캐스트 라우터 알림 메시지로 응답합니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 58 라우터와 접두사 검색을 위한 유니캐스트 라우터 알림
네트워크 환경 연결 불가능성 검색
연결 가능성은 IPv6 패킷을 인접 노드로 올바로 보낼 수 있고 네트워크 환경의 IPv6 계층에서 패킷을 받아서 처리되도록 하는 능력으로 정의됩니다. 노드가 라우터로 패킷을 보낼 경우, 패킷은 라우터의 IPv6 계층으로 배달된 뒤 다음 홉으로 배달됩니다. 노드가 인접 노드로 패킷을 보낼 경우, 패킷은 노드의 IPv6 계층으로 배달됩니다. 연결 가능성에 대한 정의는 라우터에서 원격 노드를 통해 배달할 필요가 없으며, 인접하는 라우터로만 배달하면 됩니다.
네트워크 환경에 연결할 수 없게 되면 IPv6은 이 상태를 감지하여 해결하려고 합니다. IPv6은 통신 진행 상태를 나타내는 상위 계층 프로토콜이나 유니캐스트 네트워크 환경 요청 메시지에 대한 응답으로 보낸 네트워크 환경 알림의 확인 메일로 네트워크 환경의 연결 가능성 여부를 결정합니다.
TCP 트래픽의 경우, 통신 진행 상태는 새 데이터를 받거나 전송된 데이터에 대한 승인 세그먼트를 받을 때 나타납니다. UDP 트래픽의 경우에는 진행 상태 표시가 없을 수 있습니다. 이런 경우에는 노드가 유니캐스트 네트워크 환경 요청 메시지를 다음 홉 네트워크 환경으로 전송해서 연결 가능성을 모니터합니다.
요청된 네트워크 환경 알림의 확인 메일만 연결 가능성의 증거로 간주됩니다. 요청된 플래그를 1로 설정한 요청된 네트워크 환경 알림은 네트워크 환경 요청에 대한 응답으로만 전송됩니다. 요청되지 않은 네트워크 환경 알림 또는 라우터 알림 메시지는 연결 가능성의 증거로 간주되지 않습니다.
네트워크 환경 연결 불가능성 검색은 대칭 연결 가능성을 검색합니다. 이러한 경우, 패킷은 원하는 인접 노드로 전송하거나 그 노드로부터 전송될 수 있어야 합니다. 네트워크 환경 요청이 보내지고 요청된 네트워크 환경 알림을 받으면 두 노드 사이의 경로가 확인됩니다. 요청되지 않은 네트워크 환경 알림 또는 라우터 알림 메시지의 경우에는 메시지를 보내는 노드의 경로만 확인됩니다. 이를 대칭 연결 가능성이라고 합니다.
특정 로컬 노드의 경우, 연결 가능성은 네트워크 환경 요청을 보내고 네트워크 환경 알림을 받은 노드에 의해서만 확인됩니다. 네트워크 환경 알림을 받은 노드는 네트워크 환경 알림이 원하는 노드에 연결되었다는 확인을 받지 않습니다. 두 인접 노드가 모두 연결 가능한지 판단하려면, 각 노드가 네트워크 환경 요청과 네트워크 환경 알림 메시지를 서로 교환해야 합니다.
인접 노드의 연결 가능성은 네트워크 환경 캐시에 있는 인접 노드 항목의 상태를 모니터하여 판별됩니다. RFC 2461은 네트워크 환경 캐시 항목에 대한 상태를 다음과 같이 정의합니다.
- INCOMPLETE(불완전)
요청되지 않은 노드 멀티캐스트 네트워크 환경 요청을 사용하고 있는 IPv6 주소 확인이 진행 중입니다. 새 네트워크 환경 캐시 항목이 만들어졌지만 아직 노드의 대응하는 링크 계층 주소가 없을 때 INCOMPLETE 상태로 들어갑니다. 주소 확인 프로세스를 중단하고 네트워크 환경 캐시 항목을 제거하기 전에 전송된 멀티캐스트 네트워크 환경 요청 수는 구성 가능한 변수를 사용해서 설정됩니다. RFC 2461은 변수 이름 MAX_MULTICAST_SOLICIT를 사용하며 값 3을 사용할 것을 권장합니다.
- REACHABLE(연결 가능)
요청된 유니캐스트 네트워크 환경 알림의 확인 메일에 의해 연결 가능성이 확인되었습니다. 네트워크 환경 캐시 항목은 라우터 알림의 연결 가능한 시간 필드에 표시된 시간(밀리초 단위)이 경과할 때까지 REACHABLE 상태를 유지합니다.
- STALE(시간 경과)
마지막 연결 가능성 확인을 받은 이후 지속된 시간인 연결 가능한 시간이 경과했습니다. 네트워크 환경 캐시 항목은 연결 가능한 시간 필드에 표시된 값(밀리초 단위)이 경과하면 STALE 상태가 되서 패킷을 네트워크 환경으로 보낼 때까지 계속 그 상태를 유지합니다. 링크 계층 주소를 알리고 있는 요청되지 않은 네트워크 환경 알림을 받을 때에도 STALE 상태로 들어갑니다.
- DELAY(지연)
네트워크 환경 요청을 보내기 전에 상위 계층 프로토콜이 연결 가능성을 확인할 수 있도록 네트워크 환경 캐시 항목이 DELAY 상태가 되고 구성 가능한 시간 동안 기다립니다. RFC 2461은 변수 이름 DELAY_FIRST_PROBE_TIME을 사용하며 값 5초를 사용할 것을 권장합니다. 지연 시간까지 연결 가능성 확인을 받지 못하면, 항목은 PROBE 상태로 들어가고 유니캐스트 네트워크 환경 요청이 전송됩니다.
- PROBE(탐색)
STALE 상태와 DELAY 상태에 있던 네트워크 환경 캐시 항목에 대한 연결 가능성 확인을 진행하고 있는 상태입니다. 유니캐스트 네트워크 환경 요청 메시지는 이 호스트에서 받은 라우터 알림 메시지의 재전송 타이머 필드에 대응하는 간격으로 전송됩니다. 연결 가능성 검색 프로세스를 중단하고 네트워크 환경 캐시 항목을 제거하기 전에 보낸 네트워크 환경 요청 수는 구성 가능한 변수를 사용해서 설정됩니다. RFC 2461은 변수 이름 MAX_UNICAST_SOLICITS를 사용하며 값 3을 사용할 것을 권장합니다.
그림 59는 네트워크 환경 캐시의 항목에 대한 상태 다이어그램을 보여줍니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 59 네트워크 환경 캐시 항목의 상태
연결할 수 없는 네트워크 환경이 라우터인 경우, 호스트는 기본 라우터 목록에서 다른 라우터를 선택하고 주소 확인과 그에 대한 연결 불가능성 검색을 모두 수행합니다.
라우터가 호스트의 역할을 하게 되면 라우터 플래그를 0으로 설정하여 멀티캐스트 네트워크 환경 알림을 보내야 합니다. 라우터 플래그가 0으로 설정된 라우터로부터 호스트가 네트워크 환경 알림을 받으면 호스트는 해당 라우터를 기본 라우터 목록에서 제거하고, 필요하면 다른 라우터를 선택합니다.
리디렉트 기능
라우터는 리디렉트 기능을 사용하여 특정 대상으로 트래픽을 전달할 더 나은 첫번째 홉 네트워크 환경을 원래 호스트에게 알립니다. 리디렉트는 다음과 같은 두 가지 경우에 사용됩니다.
- 라우터가 대상과 "더 가까이" 있는 로컬 링크에서 사용할 수 있는 라우터의 IP 주소를 원래 호스트에 알리는 경우. "더 가깝다(Closer)"는 것은 대상 네트워크 세그먼트 연결에 사용된 라우팅 미터법 기능입니다. 이 상태는 네트워크 세그먼트에 라우터가 여러 개 있고, 원래 호스트에서 선택한 기본 라우터가 대상에 연결하는데 사용할 수 있는 가장 적합한 라우터가 아닌 경우에 발생합니다.
- 대상이 네트워크 환경(원래 호스트와 동일한 링크에 있음)이라고 라우터가 원래 호스트에게 알리는 경우. 이 상태는 호스트의 접두사 목록에 대상의 접두사가 포함되지 않는 경우에 발생합니다. 대상이 목록에 있는 접두사와 일치하지 않기 때문에 원래 호스트는 기본 라우터로 패킷을 전달합니다.
다음 단계는 IPv6 리디렉트 프로세스에서 발생합니다.
- 원래 호스트가 유니캐스트 패킷을 기본 라우터로 전달합니다.
- 라우터가 패킷을 처리하고 원래 호스트의 주소가 네트워크 환경이라고 기록합니다. 또한 원래 호스트와 다음 홉의 주소가 모두 동일한 링크에 있다고 기록합니다.
- 라우터가 적절한 다음 홉 주소로 패킷을 전달합니다.
- 라우터가 리디렉트 메시지를 원래 호스트로 보냅니다. 리디렉트 메시지의 타겟 주소 필드는 노드의 다음 홉 주소이며, 원래 호스트는 대상에 지정된 패킷을 이 주소로 보냅니다.
라우터로 리디렉트된 패킷의 경우, 타겟 주소 필드는 라우터의 링크 로컬 주소로 설정됩니다. 호스트로 리디렉트된 패킷의 경우, 타겟 주소 필드는 처음에 보낸 패킷의 대상 주소로 설정됩니다.
리디렉트 메시지는 리디렉트 헤더 옵션을 포함하며, 타겟 링크 계층 주소 옵션을 포함할 수도 있습니다.
- 리디렉트 메시지를 받는 즉시, 원래 호스트는 타겟 주소 필드에 있는 주소를 사용해서 대상 캐시의 대상 주소 항목을 업데이트합니다. 타겟 링크 계층 주소 옵션이 리디렉트 메시지에 포함되어 있으면 그 내용은 대응하는 네트워크 환경 캐시 항목을 만들거나 업데이트하는데 사용됩니다.
리디렉트 메시지는 원래 호스트와 대상 사이의 경로에 있는 첫번째 라우터에 의해서만 전송됩니다. 호스트는 리디렉트 메시지를 보내지 않으며 라우터는 리디렉트 메시지의 확인 메일을 기준으로 라우팅 테이블을 업데이트하지 않습니다.
리디렉트의 예
호스트 A는 이더넷 MAC 주소 00-AA-00-11-11-11과 그에 대응하는 링크 로컬 주소 FE80::2AA:FF:FE11:1111을 가지며, 사이트 로컬 주소 FEC0::1:2AA:FF:FE11:1111/64도 가집니다. 라우터 1은 이더넷 MAC 주소 00-AA-00-22-22-22와 그에 대응하는 링크 로컬 주소 FE80::2AA:FF:FE22:2222를 가지며, 사이트 로컬 주소 FEC0::1:2AA:FF:FE22:2222/64도 가집니다. 라우터 2는 이더넷 MAC 주소 00-AA-00-33-33-33과 그에 대응하는 링크 로컬 주소 FE80::2AA:FF:FE33:3333을 가지며, 사이트 로컬 주소 FEC0::1:2AA:FF:FE33:3333/64도 가집니다. 호스트 A는 FEC0::2:2AA:FF:FE99:9999(그림에는 나타나 있지 않음)의 오프링크 호스트로 패킷을 보내며 라우터 1을 현재의 기본 라우터로 사용합니다. 그러나 이 대상 연결에 사용할 더 나은 라우터는 라우터 2입니다.
호스트 A는 그림 60과 같이 FEC0::2:2AA:FF:FE99:9999로 지정된 패킷을 라우터 1로 보냅니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 60 원래 노드가 전달한 유니캐스트 패킷
라우터 1은 호스트 A에서 패킷을 받으며, 호스트 A가 네트워크 환경이라고 기록합니다. 호스트 A와 대상의 다음 홉 주소가 동일한 링크에 있다는 것도 기록합니다. 로컬 라우팅 테이블의 내용을 기준으로 라우터 2는 그림 61에서 보여진 것처럼 호스트 A에서 받은 유니캐스트 패킷을 라우터 2로 보냅니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 61 라우터가 전달한 유니캐스트 패킷
대상 FEC0::2:2AA:EE:FE99:9999에 대한 그 이후의 패킷을 라우터 2로 보내야 한다고 호스트 A에 알리기 위해 라우터 1은 그림 62에서 보는 것처럼 리디렉트 메시지를 호스트 A로 보냅니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 62 라우터가 보낸 리디렉트 메시지
호스트 전송 알고리즘
IPv6 호스트가 IPv6 패킷을 보내는 프로세스는 로컬 호스트 구조와 ND 프로토콜을 결합한 것입니다. IPv6 호스트는 패킷을 임의의 대상으로 보낼 때 다음 알고리즘을 사용합니다.
- 대상 캐시에 대상 주소와 일치하는 항목이 있는지 확인합니다.
- 대상 캐시에 대상 주소와 일치하는 항목이 있으면 대상 캐시 항목에서 다음 홉 주소를 얻습니다. 3단계로 가십시오.
대상 캐시에 대상 주소와 일치하는 항목이 없으면 대상 주소와 접두사 목록에 있는 접두사가 일치하는지 확인합니다.
대상 주소가 접두사 목록의 접두사와 일치하면 다음 홉 주소가 대상 주소로 설정됩니다. 3단계로 가십시오.
대상 주소가 접두사 목록의 접두사와 일치하지 않으면 다음 홉 주소가 현재 기본 라우터의 주소로 설정됩니다. 3단계로 가십시오.
기본 라우터가 없고 기본 라우터 목록에 라우터가 없으면 다음 홉 주소가 대상 주소로 설정됩니다.
- 네트워크 환경 캐시에 다음 홉 주소와 일치하는 항목이 있는지 확인합니다.
- 네트워크 환경 캐시에 다음 홉 주소와 일치하는 항목이 있으면 링크 계층 주소를 얻습니다.
네트워크 환경 캐시에 다음 홉 주소와 일치하는 항목이 없으면 주소 확인을 사용하여 다음 홉 주소의 링크 계층 주소를 얻습니다.
- 네트워크 환경 캐시 항목의 링크 계층 주소를 사용하여 패킷을 보냅니다.
호스트 전송 알고리즘은 그림 63에 보여집니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 63 호스트 전송 알고리즘
주소 자동 구성
IPv6의 가장 유용한 기능 중 하나는 IPv6의 동적 호스트 구성 프로토콜(DHCPv6)과 같은 스테이트풀 구성 프로토콜을 사용하지 않아도 자동으로 자신을 구성할 수 있다는 점입니다. 기본적으로 IPv6 호스트는 각 인터페이스마다 링크 로컬 주소를 구성할 수 있습니다. 호스트는 라우터 검색을 사용하여 라우터의 주소, 다른 구성 매개 변수, 추가 주소 및 온링크 접두사를 결정할 수도 있습니다. 라우터 알림 메시지에는 스테이트풀 주소 구성 프로토콜의 사용 여부에 대한 표시가 포함됩니다.
주소 자동 구성은 멀티캐스트 가능 인터페이스에서만 수행할 수 있습니다. 주소 자동 구성은 RFC 2462에 설명되어 있습니다.
자동 구성된 주소 상태
자동 구성된 주소는 다음 중 하나 이상의 상태에 있습니다.
- 임시
주소가 고유한지 확인되고 있는 상태입니다. 확인은 중복 주소 검색을 통해서 수행됩니다. 노드는 유니캐스트 트래픽을 임시 주소로 받을 수 없습니다. 그러나 중복 주소 검색 중에 전송된 네트워크 환경 요청 메시지에 대한 응답인 멀티캐스트 네트워크 환경 알림 메시지를 받고 처리할 수 있습니다.
- 기본 설정
고유성이 확인된 주소. 노드는 유니캐스트 트래픽을 기본 설정 주소로 보내거나 이 주소로부터 받을 수 있습니다. 주소가 기본 설정 상태를 유지할 수 있는 기간은 라우터 알림 메시지의 접두사 정보 옵션에 있는 기본 설정 기간 필드에서 결정합니다.
- 사용 지양
여전히 유효하지만 새로운 통신에서는 사용이 금지되는 주소. 기존 통신 세션에서는 사용 지양 주소를 계속 사용할 수 있습니다. 노드는 유니캐스트 트래픽을 사용 지양 주소로 보내거나 이 주소로부터 받을 수 있습니다.
- 유효함
유니캐스트 트래픽을 보내고 받을 수 있는 주소. 유효 상태는 기본 설정 상태와 사용 지양 상태를 모두 포함합니다. 주소가 유효 상태에 있는 시간은 라우터 알림 메시지의 접두사 정보 옵션에 있는 유효 기간 필드에서 결정합니다. 유효 기간은 기본 설정 기간 이상이어야 합니다.
- 유효하지 않음
노드가 더 이상 유니캐스트 트래픽을 보내거나 받을 수 없는 주소. 유효 기간이 만료되면 주소가 유효하지 않은 상태가 됩니다.
자동 구성된 주소의 상태와 기본 설정 및 유효 기간의 관계는 그림 64에 보여집니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 64 자동 구성된 주소에 대한 상태와 유효 기간
참고 링크 로컬 주소에 대한 자동 구성을 제외한 주소 자동 구성은 호스트에 대해서만 지정됩니다. 라우터는 수동 구성과 같은 다른 수단을 통해 주소와 구성 매개 변수를 얻어야 합니다.
자동 구성의 종류
자동 구성에는 세 가지 종류가 있습니다.
- 스테이트리스
관리된 주소 구성과 기타 스테이트풀 구성 플래그를 0으로 설정한 라우터 알림 메시지 및 하나 이상의 접두사 정보 옵션에 대한 확인 메일을 기준으로 주소가 구성됩니다.
- 스테이트풀
주소 및 그외 구성 옵션을 구하기 위해 사용된 DHCPv6과 같은 스테이트풀 주소 구성 프로토콜을 기준으로 구성됩니다. 호스트는 관리된 주소 구성 플래그나 기타 스테이트풀 구성 플래그를 1로 설정한 접두사 옵션이 없는 라우터 알림 메시지를 받을 때 스테이트풀 주소 구성을 사용합니다. 호스트는 로컬 링크에 라우터가 없는 경우에도 스테이트풀 주소 구성 프로토콜을 사용합니다.
- 모두
접두사 정보 옵션이 있는 라우터 알림 메시지와 1로 설정한 관리된 주소 구성이나 기타 스테이트풀 구성 플래그의 확인 메일을 기준으로 구성됩니다.
모든 종류에서 항상 링크 로컬 주소가 구성됩니다.
자동 구성 프로세스
IPv6 노드에 대한 주소 자동 구성 프로세스는 다음과 같습니다.
- 임시 링크 로컬 주소가 링크 로컬 접두사 FE80::/64와 64비트 인터페이스 ID를 기준으로 파생됩니다.
- 임시 링크 로컬 주소의 고유성 확인에 중복 주소 검색을 사용하면 네트워크 환경 요청 메시지가 임시 링크 로컬 주소로 설정된 타겟 주소 필드와 함께 전송됩니다.
- 네트워크 환경 요청에 대한 응답으로 전송된 네트워크 환경 알림 메시지를 받은 경우, 로컬 링크에 있는 다른 노드가 임시 링크 로컬 주소를 사용하고 있어서 주소 자동 구성이 중지합니다. 이러한 경우에는 노드를 수동으로 구성해야 합니다.
- 네트워크 환경 요청 메시지에 대한 응답으로 전송된 네트워크 환경 알림 메시지를 받지 않은 경우에는 임시 링크 로컬 주소를 고유하고 유효한 주소로 간주합니다. 인터페이스에 대해 링크 로컬 주소가 초기화됩니다. 대응하는 요청된 노드 멀티캐스트 링크 계층 주소가 네트워크 어댑트를 사용해서 등록됩니다.
IPv6 호스트에 대한 주소 자동 구성은 다음과 같이 계속됩니다.
- 호스트가 라우터 요청 메시지를 보냅니다.
- 라우터 알림 메시지를 받지 않으면 호스트가 스테이트풀 주소 구성 프로토콜을 사용하여 주소와 기타 구성 매개 변수를 얻습니다.
- 라우터 알림 메시지를 받으면 홉 한계, 연결 가능한 시간, 재전송 타이머 및 MTU(MTU 옵션이 있는 경우)가 설정됩니다.
- 각 접두사 정보 옵션이 있는 경우에는 다음이 수행됩니다.
온링크 플래그가 1로 설정되면 접두사 목록에 접두사가 추가됩니다.
자율 플래그가 1로 설정되면 접두사와 64비트 인터페이스 ID를 사용해서 임시 주소를 파생합니다.
중복 주소 검색은 임시 주소의 고유성을 확인하는데 사용됩니다.
임시 주소를 사용하고 있으면 인터페이스에 대해 주소의 사용이 초기화되지 않습니다.
임시 주소를 사용하고 있지 않으면 주소가 초기화됩니다. 여기에는 접두사 정보 옵션의 유효 기간과 기본 설정 기간 필드의 유효 기간 및 기본 설정 기간 설정이 포함됩니다. 대응하는 요청된 노드 멀티캐스트 링크 계층 주소를 네트워크 어댑터를 사용해서 등록하는 것도 포함됩니다.
- 라우터 알림 메시지의 관리된 주소 구성 플래그가 1로 설정되면 스테이트풀 주소 구성 프로토콜을 사용해서 추가 주소를 얻습니다.
- 라우터 알림 메시지의 기타 스테이트풀 구성 플래그가 1로 설정되면 스테이트풀 주소 구성 프로토콜을 사용해서 추가 구성 매개 변수를 얻습니다.
호스트에 대한 주소 자동 구성 프로세스는 그림 65와 66에 보여집니다.
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 65 호스트에 대한 주소 자동 구성 프로세스(파트 1)
현재 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 누르면 별도의 페이지에서 볼 수 있습니다.
그림 66 호스트에 대한 주소 자동 구성 프로세스(파트 2)
요약
이 백서에서는 IPv6 프로토콜 제품군과 유사한 현재 IPv4의 기능이나 개념과의 비교를 통하여 새로운 IPv6 프로토콜 제품군에 대해 검토하였습니다. 뿐만 아니라 IPv4 프로토콜 설계 문제에 대한 IPv6의 해결 방법, 새로운 IPv6 헤더와 확장 헤더, ICMPv6(IPv4용 ICMP 대체), MLD(IPv4용 IGMP 대체), 인접 IPv6 노드 사이의 상호 작용을 관리하는 IPv6 네트워크 환경 검색 프로세스 및 IPv6 주소 자동 구성에 대해서도 검토했습니다. 아직까지는 널리 사용되고 있지 않지만 인터넷의 미래는 IPv6 기반으로 짜여질 것입니다. 이 전략적 프로토콜을 이해하여 IPv6의 채택과 IPv6으로의 마이그레이션에 대비한 계획을 세워 두어야 합니다.
추가 정보
Windows 2000에 관한 최신 정보는 웹 사이트(http://www.microsoft.com/korea/ntserver/)와 Windows NT Server Forum on MSN™ 및 Microsoft 네트워크 온라인 서비스(GO WORD: MSNTS)를 참조하십시오.
IPv6에 관한 최신 정보는 IPv6 작업 그룹 웹 사이트(http://www.microsoft.com/windows.netserver/technologies/ipv6/default.asp
)를 참조하십시오. 이 사이트에는 현재의 RFC 세트에 대한 링크와 IPv6 프로토콜 제품군에 대해 설명한 인터넷 초안이 있습니다.
표준 기반 IPv6 배치 계획에 관한 최신 정보는 Next Generation Transition(ngtrans) Working Group 웹 사이트(http://www.ietf.org/html.charters/ngtrans-charter.html
)를 참조하십시오. 이 사이트에서 현재의 RFC 세트에 대한 링크와 다양한 배치 도구 및 인터넷 전환 전략에 대해 설명한 인터넷 초안을 구할 수 있습니다.