IPv6 링크-로컬 및 사이트-로컬 주소
IPv6 링크-로컬 및 사이트-로컬 주소를 범위가 지정된 주소라고 합니다. Winsock(Windows Sockets) API는 범위가 지정된 주소와 함께 사용할 sockaddr_in6 구조의 sin6_scope_id멤버를 지원합니다. IPv6 링크-로컬 주소(fe80::/10 접두사)의 경우 sockaddr_in6 구조의 sin6_scope_id 멤버는 인터페이스 번호입니다. IPv6 사이트-로컬 주소(fec0::/10 접두사)의 경우 sockaddr_in6 구조의 sin6_scope_id 멤버는 사이트 식별자입니다.
인터페이스 #5의 링크 로컬 IPv6 주소의 예는 다음과 같습니다.
fe80::208:74ff:feda:625c%5
다음 명령은 Windows XP SP1(서비스 팩 1) 이상에서 로컬 컴퓨터에서 IPv6을 쿼리하고 구성하는 데 사용할 수 있습니다.
Netsh.exe 명령을 사용하여 변경한 구성은 영구적이며 컴퓨터 또는 IPv6 프로토콜을 다시 시작할 때 손실되지 않습니다.
WINDOWS XP SP1(서비스 팩 1)을 사용하는 이전에는 IPv6 구성 및 관리에서 몇 가지 이전 명령줄 도구(Net.exe, Ipv6.exe 및 Ipsec6.exe)를 사용하여 IPv6을 구성하고 관리했습니다. 이러한 이전 도구를 사용하면 IPv6 변경 내용이 영구적이지 않으며 컴퓨터 또는 IPv6 프로토콜이 다시 시작될 때 손실됩니다. 이러한 이전 명령줄 도구는 Windows XP에서만 지원됩니다.
WINDOWS XP SP1에서 다음 명령은 인터페이스 인덱스, 인터페이스 이름 및 기타 다양한 인터페이스 속성을 포함하여 로컬 컴퓨터의 IPv6 인터페이스 목록을 표시합니다.
netsh 인터페이스 ipv6 show 인터페이스
WINDOWS XP SP1에서 다음 명령은 인터페이스 인덱스와 연결된 사이트 식별자를 변경합니다.
netsh 인터페이스 ipv6 set interface <InterfaceIndex 또는 Name> siteid=value
Windows XP에서 다음 이전 명령은 사이트-로컬 주소와 연결된 사이트 식별자도 3으로 변경합니다.
ipv6 rtu fec0::/10 3
범위가 지정된 주소를 보내거나 연결하는 경우 sockaddr_in6 구조의 sin6_scope_id 멤버는 모호한 범위 주소를 나타내는 지정되지 않은(0)으로 남을 수 있습니다. 예를 들어 다음 링크-로컬 주소는 모호합니다.
fe80::10
범위가 지정된 주소에 바인딩하는 경우 sockaddr_in6 구조의 sin6_scope_id 멤버에는 링크-로컬 주소의 유효한 인터페이스 번호 또는 사이트-로컬 주소의 사이트 식별자를 지정하는 0이 아닌 값이 포함되어야 합니다.
모호한 범위 주소
범위가 지정된 주소를 보내거나 연결하는 중이고 sockaddr_in6 구조에서 sin6_scope_id 멤버를 지정하지 않은 경우 범위가 지정된 주소는 모호합니다. 이를 resolve 위해 IPv6 프로토콜은 먼저 소켓을 원본 주소에 바인딩했는지 여부를 결정합니다. 이 경우 바인딩된 원본 주소는 인터페이스 번호 또는 사이트 식별자를 제공하여 모호성을 해결합니다.
범위가 지정된 주소를 보내거나 연결 중이고 sin6_scope_id 멤버를 지정하거나 원본 주소를 바인딩하지 않은 경우 IPv6 프로토콜은 라우팅 테이블을 확인합니다. 예를 들어 다음 명령은 로컬 컴퓨터에 IPv6 라우팅 테이블을 표시합니다.
netsh 인터페이스 ipv6 경로 표시
No Manual 256 fe80::/64 13 Local Area Connection
No Manual 256 fe80::/64 14 Wireless Network Connection
이는 링크 로컬 주소가 기본적으로 인터페이스 #13 및 #14에 대한 링크로 처리됨을 나타냅니다.
모호성은 로컬 컴퓨터에 네트워크 어댑터가 여러 대 있는 경우에 발생합니다. 예를 들어 위의 netsh 명령은 두 개의 네트워크 인터페이스(로컬 영역 연결 및 무선 네트워크 연결)가 있음을 나타냅니다. 애플리케이션이 scope ID 없이 대상 링크-로컬 주소(예: fe80::10)를 지정하는 경우 패킷을 보내는 데 사용할 어댑터가 명확하지 않습니다. 링크 로컬 유니캐스트(fe80:::/64) 또는 link-scope 멀티캐스트(ff00:::/8) IPv6 대상 주소만 패킷을 보낼 때 scope ID가 없어질 수 있습니다.
네트워크 환경 검색
sockaddr_in6 구조에서 sin6_scope_id 멤버를 지정하지 않은 경우 원본 주소를 바인딩하지 않았으며 링크-로컬 주소에 대한 경로를 지정하지 않은 경우 IPv6 프로토콜은 인접 검색을 시도하여 대상 링크-로컬 주소를 resolve. 전송되는 지정된 패킷의 경우 하나의 인터페이스가 시도됩니다. 시도되는 이 첫 번째 인터페이스는 가장 선호되는 인터페이스로 간주됩니다. 인접 검색이 인터페이스에서 링크-로컬 주소를 resolve 못하면 전송할 패킷이 삭제되고 시스템에서 해당 인터페이스를 통해 대상 링크-로컬 주소에 연결할 수 없다는 것을 기억합니다. 동일한 모든 조건에서 보낼 다음 패킷에서 인접 검색을 위해 다른 인터페이스를 시도합니다. 이 프로세스는 인접 검색이 대상 링크-로컬 주소에 대해 응답하거나 가능한 모든 인터페이스가 시도되고 실패할 때까지 각 새 패킷에 대해 로컬 컴퓨터의 각 인터페이스를 계속 진행합니다. 인접 resolve 시도가 실패할 때마다 해당 인접 항목에 대해 하나의 인터페이스가 제거됩니다.
대상 링크-로컬 주소가 확인되면 해당 인터페이스를 사용하여 현재 패킷을 보냅니다. 이 인터페이스는 동일한 링크-로컬 대상 주소로 전송되는 이후의 모호한 범위 패킷에도 사용됩니다.
인접 검색이 모든 인터페이스에서 대상 링크-로컬 주소를 resolve 못하는 경우 시스템은 가장 선호하는 인터페이스(첫 번째 인터페이스가 시도됨)에서 패킷을 보내려고 시도합니다. 네트워크 스택은 가장 선호되는 인터페이스에서 대상 링크-로컬 주소를 계속 resolve. 모든 인터페이스에서 인접 검색이 실패한 후 일정 기간이 지나면 네트워크 스택이 프로세스를 다시 시작하고 모든 인터페이스에서 대상 링크-로컬 주소를 resolve 시도합니다. 현재 모든 인터페이스에서 인접 검색을 다시 시도하는 이 시간 간격은 60초입니다. 그러나 이 시간 간격은 Windows 버전에서 변경될 수 있으며 애플리케이션에서 가정해서는 안 됩니다.
참고
네이버 검색에서 링크-로컬 주소를 해결한 후 애플리케이션이 동일한 링크-로컬 주소를 다른 인터페이스에 바인딩하는 경우 인접 검색에서 반환된 링크-로컬 대상 주소로 인터페이스를 재정의하지 않습니다.
IP 버전 6용 인접 검색에 대한 자세한 내용은 IETF에서 게시한 RFC4861 을 참조하세요.
관련 항목