본문으로 이동

IPv6 주소

위키백과, 우리 모두의 백과사전.
IPv6 주소를 이진 형식으로 분해

인터넷 프로토콜 버전 6 주소(Internet Protocol version 6 address, IPv6 주소)는 IPv6를 사용하는 컴퓨터 망에 참여하는 컴퓨터 또는 네트워크 노드의 네트워크 인터페이스를 식별하고 찾는 데 사용되는 숫자 레이블이다. IP 주소는 각 패킷의 출발지 및 목적지를 나타내기 위해 패킷 헤더에 포함된다. 목적지의 IP 주소는 IP 패킷을 다른 네트워크로 라우팅하는 결정에 사용된다.

IPv6는 인터넷의 첫 번째 주소 지정 인프라인 인터넷 프로토콜 버전 4(IPv4)의 후속 버전이다. IP 주소를 32비트 값으로 정의한 IPv4와 달리 IPv6 주소는 128비트 크기이다. 따라서 비교적으로 IPv6는 훨씬 확장된 주소 공간을 갖는다.

주소 지정 방식

[편집]

IPv6 주소는 네트워크에서 일반적인 주요 주소 지정 및 라우팅 방식에 따라 유니캐스트 주소 지정, 애니캐스트 주소 지정 및 멀티캐스트 주소 지정으로 분류된다.[1]

유니캐스트 주소는 단일 네트워크 인터페이스를 식별한다. 인터넷 프로토콜은 유니캐스트 주소로 전송된 패킷을 해당 특정 인터페이스로 전달한다.

애니캐스트 주소는 일반적으로 다른 노드에 속하는 인터페이스 그룹에 할당된다. 애니캐스트 주소로 전송된 패킷은 라우팅 프로토콜의 거리 정의에 따라 일반적으로 가장 가까운 호스트인 멤버 인터페이스 중 하나로만 전달된다. 애니캐스트 주소는 쉽게 식별할 수 없으며, 유니캐스트 주소와 동일한 형식을 가지며 네트워크의 여러 지점에 존재한다는 점만 다르다. 거의 모든 유니캐스트 주소는 애니캐스트 주소로 사용될 수 있다.

멀티캐스트 주소는 네트워크 라우터 간의 멀티캐스트 배포 프로토콜에 참여하여 멀티캐스트 주소 목적지를 획득하는 여러 호스트가 사용한다. 멀티캐스트 주소로 전송된 패킷은 해당 멀티캐스트 그룹에 가입된 모든 인터페이스로 전달된다. IPv6는 브로드캐스트 주소 지정을 구현하지 않는다. 브로드캐스트의 전통적인 역할은 모든 노드 링크 로컬 멀티캐스트 그룹인 ff02::1에 대한 멀티캐스트 주소 지정으로 대체된다. 그러나 모든 노드 그룹의 사용은 권장되지 않으며, 대부분의 IPv6 프로토콜은 특정 네트워크의 모든 인터페이스를 방해하지 않기 위해 프로토콜별 링크 로컬 멀티캐스트 그룹을 사용한다.

주소 형식

[편집]

IPv6 주소는 128비트로 구성된다.[1] 주요 주소 지정 및 라우팅 방법론 각각에 대해 128개의 주소 비트를 비트 그룹으로 나누고 이러한 비트 그룹의 값을 특수 주소 지정 기능과 연결하는 확립된 규칙을 사용하여 다양한 주소 형식이 인식된다.

유니캐스트 및 애니캐스트 주소 형식

[편집]

유니캐스트 및 애니캐스트 주소는 일반적으로 두 가지 논리적 부분으로 구성된다: 라우팅에 사용되는 64비트 네트워크 접두사와 호스트의 네트워크 인터페이스를 식별하는 데 사용되는 64비트 인터페이스 식별자.

일반 유니캐스트 주소 형식 (라우팅 접두사 크기는 가변)
비트 48 (또는 그 이상) 16 (또는 그 이하) 64
필드 라우팅 접두사 서브넷 ID 인터페이스 식별자

네트워크 접두사(라우팅 접두사와 서브넷 ID가 결합된 것)는 주소의 가장 중요한 64비트에 포함된다. 라우팅 접두사의 크기는 다양할 수 있으며, 접두사 크기가 클수록 서브넷 ID 크기는 작아진다. 서브넷 ID 필드의 비트는 주어진 네트워크 내에서 서브넷을 정의하는 데 네트워크 관리자가 사용할 수 있다. 64비트 인터페이스 식별자는 자동으로 무작위로 설정되거나, DHCPv6 서버에서 얻거나, 수동으로 할당된다. (역사적으로는 인터페이스의 MAC 주소를 수정된 EUI-64 형식으로 사용하여 자동으로 생성되었지만, 현재는 개인 정보 보호상의 이유로 이 방법은 권장되지 않는다.[2])

고유 로컬 주소는 IPv4 사설망 주소와 유사한 주소이다.

고유 로컬 주소 형식
비트 7 1 40 16 64
필드 접두사 L 랜덤 서브넷 ID 인터페이스 식별자

접두사 필드에는 이진 값 1111110이 포함된다. L 비트는 로컬로 할당된 주소의 경우 1이고, L이 0으로 설정된 주소 범위는 현재 정의되어 있지 않다. 랜덤 필드는 /48 라우팅 접두사가 시작될 때 한 번 무작위로 선택된다.

링크 로컬 주소 또한 인터페이스 식별자를 기반으로 하지만, 네트워크 접두사에 대해 다른 형식을 사용한다.

링크 로컬 주소 형식
비트 10 54 64
필드 접두사 제로 인터페이스 식별자

접두사 필드는 이진 값 1111111010을 포함한다. 뒤따르는 54개의 0은 모든 링크 로컬 주소(fe80::/64 링크 로컬 주소 접두사)에 대해 총 네트워크 접두사를 동일하게 만들어 라우팅 불가능하게 만든다.

멀티캐스트 주소 형식

[편집]
 멀티캐스트 주소 § IPv6 문서에 이 부분의 추가 정보가 있습니다.

멀티캐스트 주소는 응용 프로그램에 따라 여러 특정 형식 규칙에 따라 형성된다.

일반 멀티캐스트 주소 형식
비트 8 4 4 112
필드 접두사 flg sc 그룹 ID

모든 멀티캐스트 주소에 대해 접두사 필드는 이진 값 11111111을 갖는다.

현재 flg 필드의 네 개 플래그 비트 중 세 개가 정의되어 있다.[1] 가장 중요한 플래그 비트는 향후 사용을 위해 예약되어 있다.

멀티캐스트 주소 플래그[3]
비트 플래그 0일 때 의미 1일 때 의미
8 예약됨 예약됨 예약됨
9 R (만남점)[4] 만남점 포함되지 않음 만남점 포함됨
10 P (접두사)[5] 접두사 정보 없음 네트워크 접두사를 기반으로 한 주소
11 T (일시적)[1] 잘 알려진 멀티캐스트 주소 동적으로 할당된 멀티캐스트 주소

4비트 범위 필드(sc)는 주소가 유효하고 고유한 영역을 나타내는 데 사용된다.

또한 범위 필드는 솔리시티드 노드와 같은 특수 멀티캐스트 주소를 식별하는 데 사용된다.

솔리시티드 노드 멀티캐스트 주소 형식
비트 8 4 4 79 9 24
필드 접두사 flg sc 제로 원 유니캐스트 주소

sc(범위) 필드는 이진 값 0010(링크 로컬)을 포함한다. 솔리시티드 노드 멀티캐스트 주소는 노드의 유니캐스트 또는 애니캐스트 주소 함수로 계산된다. 솔리시티드 노드 멀티캐스트 주소는 유니캐스트 또는 애니캐스트 주소의 마지막 24비트를 멀티캐스트 주소의 마지막 24비트로 복사하여 생성된다.

유니캐스트 접두사 기반 멀티캐스트 주소 형식[4][5]
비트 8 4 4 4 4 8 64 32
필드 접두사 flg sc res riid plen 네트워크 접두사 그룹 ID

링크 범위 멀티캐스트 주소는 유사한 형식을 사용한다.[6]


표현

[편집]

IPv6 주소는 4개의 십육진법 숫자 그룹 8개로 표현되며, 각 그룹은 16 비트를 나타낸다.[a] 그룹은 쌍점 (:)으로 구분된다. IPv6 주소의 예는 다음과 같다:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

표준은 IPv6 주소 표현에 유연성을 제공한다. 8개의 4자리 그룹으로 구성된 전체 표현은 여러 기술을 통해 단순화되어 표현의 일부를 제거할 수 있다. 일반적으로 표현은 가능한 한 짧게 줄인다. 그러나 이러한 관행은 텍스트 문서나 스트림에서 특정 주소 또는 주소 패턴을 검색하고, 주소 동등성을 비교하는 등 여러 일반적인 작업을 복잡하게 만든다. 이러한 복잡성을 완화하기 위해 국제 인터넷 표준화 기구(IETF)는 텍스트에서 IPv6 주소를 렌더링하기 위한 표준 형식을 정의했다.[9]

  • 십육진수 숫자는 항상 대소문자를 구분하지 않고 비교되지만, IETF 권장 사항은 소문자만 사용할 것을 제안한다. 예를 들어, 2001:DB8::1보다 2001:db8::1이 선호된다.
  • 각 16비트 필드의 선행 0은 생략되지만, 각 그룹은 최소한 하나의 숫자를 유지해야 한다. 예를 들어, 2001:0db8::0001:0000는 2001:db8::1:0으로 렌더링된다.
  • 연속된 모든 0 필드의 가장 긴 시퀀스는 두 개의 쌍점(::)으로 대체된다. 주소에 동일한 크기의 모든 0 필드가 여러 번 나타나는 경우, 모호성을 방지하기 위해 가장 왼쪽에 있는 필드가 압축된다. 예를 들어, 2001:db8:0:0:1:0:0:1는 2001:db8:0:0:1::1이 아닌 2001:db8::1:0:0:1으로 렌더링된다. ::는 단일 모든 0 필드를 나타내는 데 사용되지 않는다. 예를 들어, 2001:db8:0:0:0:0:2:1는 2001:db8::2:1로 단축되지만, 2001:db8:0000:1:1:1:1:1는 2001:db8:0:1:1:1:1:1로 렌더링된다.

이러한 방법은 IPv6 주소에 대해 매우 짧은 표현을 이끌어낼 수 있다. 예를 들어, Localhost(루프백) 주소인 0:0:0:0:0:0:0:1과 IPv6 비지정 주소인 0:0:0:0:0:0:0:0는 각각 ::1과 ::로 축약된다.

IPv4에서 IPv6로의 인터넷 전환 기간 동안 혼합 주소 지정 환경에서 작동하는 것이 일반적이다. 이러한 사용 사례를 위해 특수 표기법이 도입되었는데, 이는 IPv4-매핑 및 IPv4-호환 IPv6 주소를 주소의 가장 덜 중요한 32비트를 친숙한 IPv4 닷 데시멀 노테이션으로 작성하고, 가장 중요한 96비트는 IPv6 형식으로 작성한다. 예를 들어, IPv4-매핑 IPv6 주소 ::ffff:c000:0280는 ::ffff:192.0.2.128로 작성되어 원래 IPv4 주소가 IPv6로 매핑되었음을 명확하게 나타낸다.

네트워크

[편집]

IPv6 네트워크는 2의 거듭제곱 크기의 연속된 IPv6 주소 그룹인 주소 블록을 사용한다. 주소의 선행 비트 집합은 주어진 네트워크의 모든 호스트에 대해 동일하며, 네트워크 주소 또는 라우팅 접두사라고 불린다.

네트워크 주소 범위는 CIDR 표기법으로 작성된다. 네트워크는 블록의 첫 번째 주소(모두 0으로 끝남), 빗금(/), 그리고 접두사의 비트 크기와 동일한 십진법 값으로 표시된다. 예를 들어, 2001:db8:1234::/48로 작성된 네트워크는 주소 2001:db8:1234:0000:0000:0000:0000:0000에서 시작하여 2001:db8:1234:ffff:ffff:ffff:ffff:ffff에서 끝난다.

인터페이스 주소의 라우팅 접두사는 CIDR 표기법을 사용하여 주소와 함께 직접 나타낼 수 있다. 예를 들어, 서브넷 2001:db8:a::/64에 연결된 주소 2001:db8:a::123를 가진 인터페이스의 구성은 2001:db8:a::123/64로 작성된다.

주소 블록 크기

[편집]

주소 블록의 크기는 슬래시(/) 뒤에 네트워크 접두사의 길이를 비트 단위로 나타내는 숫자를 십진수로 작성하여 지정한다. 예를 들어, 접두사에 48비트가 있는 주소 블록은 /48로 표시된다. 이러한 블록에는 2128 − 48 = 280개의 주소가 포함된다. 네트워크 접두사의 길이가 짧을수록 블록은 커진다. 즉, /21 블록은 /24 블록보다 8배 크다.

네트워크 리소스 식별자 내의 리터럴 IPv6 주소

[편집]

IPv6 주소의 쌍점(:) 문자는 URI 및 URL과 같은 리소스 식별자의 기존 구문과 충돌할 수 있다. 쌍점은 일반적으로 포트 번호 앞에 호스트 경로를 끝내는 데 사용된다.[10] 이러한 충돌을 완화하기 위해 리터럴 IPv6 주소는 이러한 리소스 식별자에서 대괄호로 묶인다. 예를 들면 다음과 같다.

http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/

URL에 포트 번호도 포함된 경우 표기법은 다음과 같다.

https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/

여기서 뒤의 443은 예시의 포트 번호이다.

범위 지정 리터럴 IPv6 주소 (영역 인덱스 포함)

[편집]

글로벌 범위를 제외한 주소(##Address scopes 참조)에 대해, 특히 링크 로컬 주소의 경우, 패킷을 보내기 위한 네트워크 인터페이스의 선택은 주소가 속한 영역에 따라 달라질 수 있다. 동일한 주소가 다른 영역에서 유효할 수 있으며, 각 영역의 다른 호스트가 사용할 수 있다. 단일 주소가 다른 영역에서 사용되지 않더라도, 해당 영역의 주소 접두사는 여전히 동일할 수 있으며, 이는 운영체제가 (접두사 기반인) 라우팅 테이블의 정보를 기반으로 송신 인터페이스를 선택할 수 없게 만든다.

텍스트 주소의 모호성을 해결하려면 영역 인덱스를 주소에 추가해야 한다. 영역 인덱스는 백분율 기호(%)로 주소와 구분된다.[11] 숫자 영역 인덱스는 보편적으로 지원되어야 하지만, 영역 인덱스는 구현에 따라 달라지는 문자열일 수도 있다. 링크 로컬 주소

fe80::1ff:fe23:4567:890a

는 다음과 같이 표현될 수 있다.

fe80::1ff:fe23:4567:890a%eth2[b]

또는

fe80::1ff:fe23:4567:890a%3

전자의 방식(인터페이스 이름 사용)은 대부분의 유닉스 계열 운영체제(예: BSD, 리눅스, macOS)에서 일반적으로 사용된다.[12] 후자의 방식(인터페이스 번호 사용)은 마이크로소프트 윈도우에서 유일한 구문이지만, 이 구문에 대한 지원이 표준에 따라 필수적이므로 다른 운영체제에서도 사용할 수 있다.[c]

BSD 기반 운영체제(macOS 포함)도 숫자 영역 인덱스가 주소의 두 번째 16비트 단어에 인코딩되는 대체 비표준 구문을 지원한다. 예:

fe80:3::1ff:fe23:4567:890a

위에서 언급된 모든 운영 체제에서 링크 로컬 주소의 영역 인덱스는 실제로는 영역이 아니라 인터페이스를 참조한다. 여러 인터페이스가 동일한 영역에 속할 수 있으므로(예: 동일한 네트워크에 연결된 경우) 실제로는 서로 다른 영역 식별자를 가진 두 개의 주소가 실제로 동일할 수 있으며 동일한 링크의 동일한 호스트를 참조할 수 있다.[d]

균일 자원 식별자에 사용될 때, 백분율 기호의 사용은 구문 충돌을 야기하므로, 퍼센트 인코딩을 통해 이스케이프되어야 한다.[13] 예:

http://[fe80::1ff:fe23:4567:890a%25eth0]/

UNC 경로명 내의 리터럴 IPv6 주소

[편집]

마이크로소프트 윈도우 운영체제에서 IPv4 주소는 균일 명명 규칙(UNC) 경로명에서 유효한 위치 식별자이다. 그러나 콜론은 UNC 경로명에서 사용할 수 없는 문자이다. 따라서 IPv6 주소도 UNC 이름에서는 사용할 수 없다. 이러한 이유로 마이크로소프트는 UNC 경로에서 사용할 수 있는 도메인 이름 형식으로 IPv6 주소를 나타내는 전사 알고리즘을 구현했다. 이를 위해 마이크로소프트는 인터넷에서 2단계 도메인 ipv6-literal.net을 등록하고 예약했다(하지만 2014년 1월에 도메인을 포기했다[14]). IPv6 주소는 다음 방식으로 이 이름공간 내에서 호스트명 또는 서브도메인 이름으로 전사된다.

2001:db8:85a3:8d3:1319:8a2e:370:7348

는 다음과 같이 작성된다.

2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net

이 표기법은 DNS 이름 서버에 대한 쿼리 없이 마이크로소프트 소프트웨어에 의해 로컬에서 자동으로 해결된다.

IPv6 주소에 영역 인덱스가 포함된 경우 's' 문자 다음에 주소 부분에 추가된다.

fe80::1ff:fe23:4567:890a%3

는 다음과 같이 작성된다.

fe80--1ff-fe23-4567-890as3.ipv6-literal.net

주소 범위

[편집]

비지정 주소(::)를 제외한 모든 IPv6 주소에는 범위[11]가 있으며, 이는 네트워크의 어떤 부분에서 유효한지 지정한다.

유니캐스트

[편집]

유니캐스트 주소의 경우 링크 로컬 및 전역의 두 가지 범위가 정의된다.

링크 로컬 주소와 루프백 주소는 링크 로컬 범위를 가지며, 이는 단일 직접 연결된 네트워크에서만 사용할 수 있음을 의미한다. 다른 모든 주소(고유 로컬 주소 포함)는 전역(또는 보편) 범위를 가지며, 이는 잠재적으로 전역 라우팅이 가능하며 어디서든 전역 범위 주소에 연결하거나 직접 연결된 네트워크에서 링크 로컬 범위 주소에 연결하는 데 사용될 수 있음을 의미한다.

고유 로컬 주소는 전역 범위를 가지지만, 전역적으로 관리되지는 않는다. 결과적으로, 동일한 관리 도메인(예: 조직) 또는 협력하는 관리 도메인 내의 다른 호스트만이 적절하게 라우팅된 경우 이러한 주소에 도달할 수 있다. 범위가 전역적이므로, 이러한 주소는 다른 전역 범위 주소와 통신할 때 소스 주소로 유효하지만, 목적지에서 소스로 패킷을 라우팅하는 것이 불가능할 수 있다.

애니캐스트

[편집]

애니캐스트 주소는 문법적으로 유니캐스트 주소와 동일하며 구별할 수 없다. 유일한 차이점은 관리적이다. 따라서 애니캐스트 주소의 범위는 유니캐스트 주소의 범위와 동일하다.

멀티캐스트

[편집]

멀티캐스트 주소의 경우, 두 번째 주소 옥텟(ff0s::)의 가장 낮은 4비트는 주소의 범위를 식별한다. 즉, 멀티캐스트 패킷이 전파되어야 하는 도메인을 식별한다. 미리 정의되고 예약된 범위는 다음과 같다.

범위 값[1]:2.7
값 범위 이름 참고
0x0 예약됨
0x1 인터페이스 로컬 인터페이스 로컬 범위는 노드의 단일 인터페이스에만 걸쳐 있으며, 멀티캐스트의 루프백 전송에만 유용하다.
0x2 링크 로컬 링크 로컬 범위는 해당 유니캐스트 범위와 동일한 토폴로지 영역에 걸쳐 있다.
0x3 영역 로컬 영역 로컬 범위는 링크 로컬보다 크다고 정의되며, 네트워크 토폴로지에 의해 자동으로 결정되며 다음 범위보다 커서는 안 된다.[15]
0x4 관리 로컬 관리 로컬 범위는 관리적으로 구성되어야 하는 가장 작은 범위이다. 즉, 물리적 연결 또는 다른 멀티캐스트 관련 구성에서 자동으로 파생되지 않는다.
0x5 사이트 로컬 사이트 로컬 범위는 조직에 속한 단일 사이트에 걸쳐 있다.
0x8 조직 로컬 조직 로컬 범위는 단일 조직에 속한 모든 사이트에 걸쳐 있다.
0xe 글로벌 글로벌 범위는 인터넷의 모든 도달 가능한 노드에 걸쳐 있으며, 제한이 없다.
0xf 예약됨

다른 모든 범위는 할당되지 않았으며 관리자가 추가 영역을 정의하는 데 사용할 수 있다.

주소 공간

[편집]

일반 할당

[편집]

IPv6 주소 할당 프로세스의 관리는 인터넷 아키텍처 위원회 및 IESG에 의해 IANA에 위임된다.[16] 그 주요 기능은 지역 인터넷 레지스트리(RIR)에 대규모 주소 블록을 할당하는 것이며, RIR은 네트워크 서비스 제공업체 및 기타 지역 레지스트리에 할당하는 위임된 작업을 수행한다. IANA는 1995년 12월부터 IPv6 주소 공간 할당의 공식 목록을 유지해 왔다.[17]

효율적인 경로 통합을 허용하고 인터넷 라우팅 테이블의 크기를 줄이기 위해 전체 주소 공간의 8분의 1(2000::/3)만이 현재 인터넷에서 사용하도록 할당되어 있다. 나머지 IPv6 주소 공간은 향후 사용 또는 특별한 목적을 위해 예약되어 있다. 주소 공간은 /23부터 /12까지의 블록으로 RIR에 할당된다.[18]

RIR은 더 작은 블록을 로컬 인터넷 레지스트리에 할당하고, 로컬 인터넷 레지스트리는 이를 사용자에게 배포한다. 이러한 블록은 일반적으로 /19부터 /32까지의 크기이다.[19][20][21] 전역 유니캐스트 할당 기록은 다양한 RIR 또는 다른 웹사이트에서 찾을 수 있다.[22]

주소는 일반적으로 최종 사용자에게 /48에서 /56 크기의 블록으로 배포된다.[23] IPv6 주소는 IPv4 주소 할당에 비해 훨씬 더 큰 블록으로 조직에 할당된다. 권장되는 할당은 280개의 주소를 포함하는 /48 블록이며, 이는 전체 IPv4 주소 공간인 232개 주소보다 248배, 즉 약 2.8×1014배 크고, IPv4 주소의 가장 큰 할당인 /8 블록보다 약 7.2×1016배 크다. 그러나 전체 풀은 2128(정확히 340,282,366,920,938,463,463,374,607,431,768,211,456개, 또는 약 3.4×1038개, 즉 340 언데실리온개)의 고유한 IPv6 주소가 있으므로 예측 가능한 미래에 충분하다.

각 RIR은 여러 /23 블록 각각을 512개의 /32 블록으로 나눌 수 있으며, 일반적으로 각 ISP에 하나씩 할당한다. ISP는 /32 블록을 65536개의 /48 블록으로 나눌 수 있으며, 일반적으로 각 고객에게 하나씩 할당한다.[24] 고객은 할당된 /48 블록에서 65536개의 /64 네트워크를 생성할 수 있으며, 각 네트워크에는 264(정확히 18,446,744,073,709,551,616개, 또는 약 1.8×1019개)의 주소가 있다. 대조적으로, 전체 IPv4 주소 공간은 232(정확히 4,294,967,296개, 또는 약 4.3×109개)의 주소만을 갖는다.

설계상 주소 공간의 작은 부분만이 적극적으로 사용될 것이다. 대규모 주소 공간은 주소가 거의 항상 사용 가능하도록 보장하여 주소 보존 목적의 네트워크 주소 변환(NAT)을 불필요하게 만든다. NAT는 IPv4 주소 고갈을 완화하는 데 도움이 되도록 IPv4 네트워크에 점점 더 많이 사용되어 왔다.

특수 할당

[편집]

공급자 독립 주소 공간은 RIR이 특수 범위인 2001:678::/29에서 최종 사용자에게 직접 할당하며, 고객이 네트워크를 재할당하지 않고도 공급자를 변경할 수 있도록 한다.

인터넷 익스체인지 포인트(IXP)에는 연결된 ISP와의 통신을 위해 2001:7f8::/32, 2001:504::/30, 2001:7fa::/32[25] 범위의 특수 주소가 할당된다.

루트 네임 서버에는 2001:7f8::/29 범위의 주소가 할당되었다.[26]

예약된 애니캐스트 주소

[편집]

각 서브넷 접두사 내에서 가장 낮은 주소(인터페이스 식별자가 모두 0으로 설정된 주소)는 서브넷-라우터 애니캐스트 주소로 예약되어 있다.[1] 애플리케이션은 사용 가능한 라우터 중 하나와 통신할 때 이 주소를 사용할 수 있는데, 이 주소로 전송된 패킷은 하나의 라우터로만 전달되기 때문이다.

각 /64 서브넷 접두사 내의 가장 높은 128개 주소는 애니캐스트 주소로 사용하기 위해 예약되어 있다.[27] 이러한 주소는 일반적으로 인터페이스 식별자의 첫 57비트가 1로 설정되고, 그 뒤에 7비트 애니캐스트 ID가 따른다. 네트워크 접두사는 라우팅 목적으로 어떤 길이든 될 수 있지만, 서브넷은 64비트 길이어야 한다. 가장 낮은 7비트에 0x7e 값을 가진 주소는 모바일 IPv6 홈 에이전트 애니캐스트 주소로 정의된다. 0x7f 값(모든 비트가 1)을 가진 주소는 예약되어 있으며 사용될 수 없다. 이 범위에서 더 이상 할당이 이루어지지 않았으므로, 나머지 모든 값 0x00부터 0x7d까지도 예약되어 있다.

특수 주소

[편집]
 예약된 IP 주소 § IPv6 문서를 참고하십시오.

IPv6에는 특별한 의미를 지닌 여러 주소가 있다.[28] IANA는 이러한 특수 목적 주소의 레지스트리를 유지한다.[29] 이들은 전체 주소 공간의 2% 미만을 차지한다.

특수 주소 블록
주소 블록 (CIDR) 첫 주소 마지막 주소 주소 수 사용처 목적
::/128 :: :: 1 소프트웨어 비지정 주소
::1/128 ::1 ::1 1 호스트 루프백 주소—모든 트래픽을 자신에게 다시 루프백시키는 가상 인터페이스인 Localhost
::ffff:0:0/96 ::ffff:0.0.0.0 ::ffff:0:0 ::ffff:255.255.255.255 ::ffff:ffff:ffff 232 소프트웨어 IPv4 매핑 주소
64:ff9b::/96 64:ff9b::0.0.0.0 64:ff9b::0:0 64:ff9b::255.255.255.255 64:ff9b::ffff:ffff 232 글로벌 인터넷 NAT64 IPv4/IPv6 변환[30]
64:ff9b:1::/48 64:ff9b:1:: 64:ff9b:1:ffff:ffff:ffff:ffff:ffff 280, 각 IPv4에 대해 248 사설 인터넷 로컬 사용 IPv4/IPv6 변환[31]
100::/64 100:: 100::ffff:ffff:ffff:ffff 264 라우팅 폐기 접두사[32]
2001::/32 2001:: 2001:0:ffff:ffff:ffff:ffff:ffff:ffff 296 글로벌 인터넷 테레도 터널링
2001:20::/28 2001:20:: 2001:2f:ffff:ffff:ffff:ffff:ffff:ffff 2100 소프트웨어 ORCHIDv2[33]
2001:db8::/32 2001:db8:: 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff 296 문서 문서 및 예제 소스 코드에 사용되는 주소[34]
2002::/16 2002:: 2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2112 글로벌 인터넷 6to4 주소 지정 방식
3fff::/20 3fff:: 3fff:fff:ffff:ffff:ffff:ffff:ffff:ffff 2108 문서 문서 및 예제 소스 코드에 사용되는 주소REFERENCE FOR RFC9637 IS NOT DEFINED YET. You are invited to add it here.
5f00::/16 5f00:: 5f00:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2112 라우팅 IPv6 세그먼트 라우팅 (SRv6)REFERENCE FOR RFC9602 IS NOT DEFINED YET. You are invited to add it here.
fc00::/7 fc00:: fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2121 사설 인터넷 고유 로컬 주소[35]
fe80::/64 from fe80::/10 fe80:: fe80::ffff:ffff:ffff:ffff 264 링크 링크 로컬 주소
ff00::/8 ff00:: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2120 글로벌 인터넷 멀티캐스트 주소

과거에는 ::ffff:0:0.0.0.0/96이 IPv4/IPv6 변환에 고려되었으나[36], 더 이상 예약되지 않는다.[37][30]

유니캐스트 주소

[편집]

비지정 주소

[편집]
  • ::/128 – 모든 비트가 0인 주소를 비지정 주소(IPv4의 0.0.0.0/32에 해당)라고 한다. 이 주소는 인터페이스에 할당되어서는 안 되며, 애플리케이션이 보류 중인 연결에 적합한 호스트의 소스 주소를 학습하기 전에 소프트웨어에서만 사용되어야 한다. 라우터는 비지정 주소를 가진 패킷을 전달해서는 안 된다.

애플리케이션은 들어오는 연결을 위해 하나 이상의 특정 인터페이스에서 수신할 수 있으며, 이는 특정 IP 주소(및 콜론으로 구분된 포트 번호)로 활성 인터넷 연결 목록에 표시된다. 비지정 주소가 표시되면 애플리케이션이 사용 가능한 모든 인터페이스에서 들어오는 연결을 수신 대기하고 있음을 의미한다.

라우팅 테이블 구성에서 비지정 주소는 라우팅 테이블의 다른 곳에 지정되지 않은 목적지 주소(유니캐스트, 멀티캐스트 등)에 대한 기본 경로 주소(IPv4의 0.0.0.0/0에 해당)를 나타내는 데 사용될 수 있다.

로컬 주소

[편집]
  • ::1/128 – 루프백 주소는 유니캐스트 Localhost 주소이다. 이 주소는 IPv4의 127.0.0.1/8에 해당한다.
    호스트의 애플리케이션이 이 주소로 패킷을 보내면, IPv6 스택은 이 패킷을 동일한 가상 인터페이스에서 다시 루프백한다.
  • fe80::/10 – 링크 로컬 접두사의 주소는 로컬 서브넷에서만 유효하고 고유하다. 이 주소 범위는 IPv4의 자동 구성 주소 169.254.0.0/16와 유사하다.
    이 접두사 내에서는 하나의 /64 서브넷만 할당된다(54개의 0비트가 있음). 이는 효과적으로 fe80::/64 형식을 생성한다. 가장 낮은 64비트는 이전에 수정된 EUI-64 형식으로 구성된 인터페이스 하드웨어 주소로 선택되었지만, 이제는 개인 정보 보호를 위해 유사 난수 값이다. 모든 IPv6 지원 인터페이스에는 링크 로컬 주소가 필요하며, IPv6 라우팅이 없는 경우에도 애플리케이션은 링크 로컬 주소의 존재 여부에 의존할 수 있다.

고유 로컬 주소

[편집]
  • fc00::/7 — 고유 로컬 주소(ULA)는 로컬 통신을 위한 것이다.[35] (IPv4 사설 주소 10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16에 해당).
    이들은 협력하는 사이트 집합 내에서만 라우팅할 수 있다. 블록은 두 개의 절반으로 나뉜다. 블록의 하위 절반(fc00::/8)은 전역적으로 할당된 접두사를 위한 것이었지만, 할당 방법은 아직 정의되지 않았다. 상위 절반(fd00::/8)은 /8 접두사가 40비트 로컬 생성 유사 난수와 결합되어 /48 사설 접두사를 얻는 확률적으로 고유한 주소에 사용된다. 40비트 숫자를 선택하는 절차는 병합 또는 통신하려는 두 사이트가 주소 충돌을 겪을 가능성이 무시할 수 있을 정도로 작지만, 동일한 /48 접두사를 사용할 수 있도록 한다.[35]

IPv4에서 전환

[편집]
  • ::ffff:0:0/96 — 이 접두사는 IPv6 전환 메커니즘에 사용되며 IPv4 매핑 IPv6 주소로 지정된다.
    몇 가지 예외를 제외하고, 이 주소 유형은 IPv6 네트워킹 응용 프로그래밍 인터페이스를 통해 IPv4 위에서 전송 계층 프로토콜을 투명하게 사용할 수 있도록 한다. 이 듀얼 스택 구성에서 서버 애플리케이션은 IPv6 또는 IPv4 프로토콜을 사용하는 클라이언트의 연결을 처리하기 위해 단일 수신 소켓만 열면 된다. IPv6 클라이언트는 기본적으로 네이티브로 처리되며, IPv4 클라이언트는 IPv4 매핑 IPv6 주소에서 IPv6 클라이언트로 나타난다. 전송도 유사하게 처리된다. IPv6 주소 또는 IPv4 매핑 주소에 대한 바인딩을 기반으로 IPv4 또는 IPv6 데이터그램을 전송하기 위해 설정된 소켓을 사용할 수 있다.
  • ::ffff:0:0:0/96 — IPv4 변환 주소에 사용되는 접두사이다. 이들은 스테이트리스 IP/ICMP 변환(SIIT) 프로토콜에서 사용된다.[37]
  • 64:ff9b::/96 — 잘 알려진 접두사이다. 이 접두사를 가진 주소는 자동 IPv4/IPv6 변환에 사용된다.[30]
  • 64:ff9b:1::/48 — 로컬에서 변환된 IPv4/IPv6 주소를 위한 접두사이다. 이 접두사를 가진 주소는 NAT64 및 SIIT와 같은 여러 IPv4/IPv6 변환 메커니즘에 사용될 수 있다.[31] 64:ff9b::/96과 비교하여, 이 주소는 변환된 IPv4 주소를 48-63 및 72-87 위치에 포함한다.[30] 이는 각 IPv4 주소에 대해 /88 IPv6 접두사가 장치에 할당된다는 것을 의미한다. 이를 통해 6to4와 유사한 사용 사례가 가능하며, 단일 공용 IPv4 주소가 접두사로 변환된다. 이러한 방식으로 하나의 NAT 수준만 필요하며, 장치가 추가 주소가 필요한 경우(예: P2P 인터페이스 또는 도커 컨테이너) 내부적으로 NAT66을 수행할 필요가 없다.
  • 2002::/16 — 이 접두사는 6to4 주소 지정에 사용되었다(IPv4 네트워크의 접두사 192.88.99.0/24도 사용되었다).
    6to4 주소 지정 방식은 더 이상 사용되지 않는다.[38]

특수 목적 주소

[편집]

IANA는 특수 할당을 위해 이른바 서브 TLA ID 주소 블록을 예약했다.[28][39] 2001::/23 (64개의 네트워크 접두사 범위 2001:0000::/29부터 2001:01f8::/29까지 분할됨). 현재 이 블록에서 세 개의 할당이 이루어졌다.

  • 2001::/32 — 테레도 터널링, 즉 IPv6 전환 메커니즘에 사용된다.
  • 2001:2::/48 — IPv6 벤치마킹에 사용된다. IPv4 벤치마킹에 사용되는 198.18.0.0/15와 일치한다. Benchmarking Methodology Working Group (BMWG)에 할당되었다.[40]
  • 2001:20::/28 — ORCHIDv2(Overlay Routable Cryptographic Hash Identifiers).[33] 이들은 암호화 해시에 사용되는 라우팅되지 않는 IPv6 주소이다.

문서화

[편집]
  • 2001:db8::/32 — 이 접두사는 문서화에 사용된다.[34][e] 예제 IPv6 주소가 주어지거나 모델 네트워킹 시나리오가 설명되는 모든 곳에서 사용된다.
  • 3fff::/20 — 이 문서 접두사는 2024년에 단일 /32 접두사로 커버할 수 없는 현대 대규모 네트워크 모델링을 위해 할당되었다.REFERENCE FOR RFC9637 IS NOT DEFINED YET. You are invited to add it here.

폐기

[편집]
  • 100::/64 — 이 접두사는 트래픽을 폐기하는 데 사용된다.[32]

사용 중단 및 구식

[편집]

사용 중단 및 구식 주소 참조.

멀티캐스트 주소

[편집]

멀티캐스트 주소 ff0x::, 여기서 x는 모든 십육진수 값이며, 예약되어 있으며[1] IANA가 관리한다.[42]

일반적인 IPv6 멀티캐스트 주소
주소 설명 사용 가능한 범위
ff0x::1 모든 노드 주소, 모든 IPv6 노드 그룹 식별 범위 1 (인터페이스 로컬) 및 2 (링크 로컬)에서 사용 가능:
  • ff01::1 → 인터페이스 로컬의 모든 노드
  • ff02::1 → 링크 로컬의 모든 노드
ff0x::2 모든 라우터 범위 1 (인터페이스 로컬), 2 (링크 로컬) 및 5 (사이트 로컬)에서 사용 가능:
  • ff01::2 → 인터페이스 로컬의 모든 라우터
  • ff02::2 → 링크 로컬의 모든 라우터
  • ff05::2 → 사이트 로컬의 모든 라우터
ff02::5 OSPFIGP 2 (링크 로컬)
ff02::6 OSPFIGP 지정 라우터 2 (링크 로컬)
ff02::9 RIP 라우터 2 (링크 로컬)
ff02::a EIGRP 라우터 2 (링크 로컬)
ff02::c 웹 서비스 동적 검색 2 (링크 로컬)
ff02::d 모든 PIM 라우터 2 (링크 로컬)
ff02::1a 모든 RPL 라우터 2 (링크 로컬)
ff0x::fb mDNSv6 모든 범위에서 사용 가능
ff0x::101 모든 NTP 서버 모든 범위에서 사용 가능
ff02::1:1 링크명 2 (링크 로컬)
ff02::1:2 모든 DHCPv6 서버 및 릴레이 에이전트[43] 2 (링크 로컬)
ff02::1:3 링크 로컬 멀티캐스트 이름 확인 2 (링크 로컬)
ff05::1:3 릴레이 에이전트는 이 주소를 사용하여 사이트의 모든 DHCPv6 서버에 도달할 수 있다.[43] 5 (사이트 로컬)
ff02::1:ff00:0/104 솔리시티드 노드 멀티캐스트 주소 (아래 참조) 2 (링크 로컬)
ff02::2:ff00:0/104 노드 정보 쿼리 2 (링크 로컬)

솔리시티드 노드 멀티캐스트 주소

[편집]

솔리시티드 노드 멀티캐스트 주소 그룹 ID의 가장 낮은 24비트는 인터페이스의 유니캐스트 또는 애니캐스트 주소의 가장 낮은 24비트로 채워진다. 이러한 주소는 이웃 탐색 프로토콜(NDP)을 통해 링크 계층 주소 확인을 허용하며, 로컬 네트워크의 모든 노드를 방해하지 않는다. 호스트는 구성된 각 유니캐스트 또는 애니캐스트 주소에 대해 솔리시티드 노드 멀티캐스트 그룹에 가입해야 한다.

무상태 주소 자동 구성 (SLAAC)

[편집]
 IPv6 § 무상태 주소 자동 구성 (SLAAC) 및 링크 로컬 주소 § IPv6 문서를 참고하십시오.

시스템 시작 시 노드는 IPv6가 활성화된 각 인터페이스에 링크 로컬 주소를 자동으로 생성한다. 이는 전역 라우팅 가능한 주소가 수동으로 구성되거나 구성 프로토콜(아래 참조)을 통해 얻어지더라도 마찬가지이다. 이는 이웃 탐색 프로토콜의 구성 요소를 사용하여 독립적으로, 그리고 사전 구성 없이 무상태 주소 자동 구성(SLAAC)[44]을 통해 수행된다. 이 주소는 접두사 fe80::/64로 선택된다.

IPv4에서는 일반적인 구성 프로토콜로 DHCP 또는 PPP가 포함된다. DHCPv6가 존재하지만, IPv6 호스트는 일반적으로 이웃 탐색 프로토콜을 사용하여 전역 라우팅 가능한 유니캐스트 주소를 생성한다. 호스트는 라우터 요청을 보내고 IPv6 라우터는 접두사 할당으로 응답한다.[45]

인터페이스 식별자

[편집]

fe80::/64 주소의 하위 64비트는 64비트 인터페이스 식별자로 채워진다. 이는 다음 소스에서 파생될 수 있다.

  • "인터페이스 식별자"라는 이름에서 알 수 있듯이, 이는 네트워크 어댑터의 48비트 MAC 주소일 수 있으며, 이는 고유성이 보장된다. MAC 주소 00-0C-29-0C-47-D5는 중간에 FF-FE를 삽입하여 64비트 EUI-64로 변환된다: 00-0C-29-FF-FE-0C-47-D5. SLAAC는 실제로는 EUI-64의 수정된 버전을 사용하며, 여기서 Universal/Local 비트의 의미가 반전된다: 02-0C-29-FF-FE-0C-47-D5가 된다.
  • 그러나 어댑터의 실제 MAC 주소를 사용하여 인터페이스 주소를 파생하는 것은 현재 비난받고 있는데, 이는 MAC 주소를 인터넷 전체에 유출하여 사용자의 활동을 추적하기 매우 쉽게 만들기 때문이다. 결과적으로, 대신 유사 난수 주소를 사용하는 것이 일반적이다. 기존 옵션으로는 임시 주소, 안정적인 개인 정보 보호 주소 및 암호화 생성 주소가 있다. 이는 MAC 스푸핑과 관련이 있지만 동일한 메커니즘은 아니다. 유사 난수 인터페이스 식별자는 실제 또는 스푸핑된 MAC 주소와 일치할 필요가 없다.

임시 주소

[편집]

무상태 주소 자동 구성에 사용되는 전역 고유 및 정적 MAC 주소는 시간 및 IPv6 네트워크 접두사 변경 전반에 걸쳐 User Equipment를 추적할 수 있는 기회를 제공한다.[46] 사용자 신원이 IPv6 주소 부분에 영구적으로 연결될 가능성을 줄이기 위해 노드는 시간에 따라 변하는 무작위 비트 문자열[47] 및 비교적 짧은 수명(수 시간에서 수 일)을 기반으로 인터페이스 식별자를 가진 임시 주소를 생성할 수 있으며, 이 수명 이후에는 새 주소로 대체된다.

임시 주소는 연결을 시작하기 위한 소스 주소로 사용될 수 있으며, 외부 호스트는 도메인 네임 시스템(DNS)을 쿼리하여 공용 주소를 사용한다.

IPv6용으로 구성된 네트워크 인터페이스는 OS X 라이언 및 이후 Apple 시스템, 윈도우 비스타, 윈도우 서버 2008 및 이후 마이크로소프트 시스템에서 기본적으로 임시 주소를 사용한다.[48]

암호화 생성 주소

[편집]

이웃 탐색 프로토콜의 보안을 강화하기 위한 수단으로 2005년에 Secure Neighbor Discovery(SEND) 프로토콜의 일부로 암호화 생성 주소(CGA)가 도입되었다.[49]

이러한 주소는 여러 입력을 받는 두 가지 해시 함수를 사용하여 생성된다. 첫 번째 함수는 공개 키와 무작위 수정자를 사용하며, 후자는 결과 해시의 특정 양의 0비트가 얻어질 때까지 반복적으로 증가한다.[f] 두 번째 해시 함수는 네트워크 접두사와 이전 해시 값을 받는다. 두 번째 해시 결과의 가장 낮은 64비트는 64비트 네트워크 접두사에 연결되어 128비트 주소를 형성한다.

해시 함수는 특정 IPv6 주소가 유효한 CGA 요구 사항을 충족하는지 확인하는 데도 사용할 수 있다. 이러한 방식으로 신뢰할 수 있는 주소 간에만 통신을 설정할 수 있다.

안정적인 개인 정보 보호 주소

[편집]

무상태 주소 자동 구성에서 사용하는 전역적으로 고유하고 정적인 MAC 주소는 심각한 보안 및 개인 정보 보호 문제를 야기한다.[50] 이는 기본 하드웨어 주소(대부분 MAC 주소)가 로컬 네트워크를 넘어 노출되어 사용자 활동 추적 및 사용자 계정을 다른 정보와 연관시키는 것을 허용하기 때문이다. 또한 공급자별 공격 전략을 허용하고 공격 대상을 검색하기 위한 주소 공간의 크기를 줄인다.

이러한 단점을 해결하기 위해 안정적인 개인 정보 보호 주소가 도입되었다. 이 주소는 특정 네트워크 내에서는 안정적이지만 다른 네트워크로 이동할 때 변경되어 개인 정보 보호를 향상시킨다. 네트워크의 전체 주소 공간에서 결정론적이지만 무작위로 선택된다.

안정적인 개인 정보 보호 주소의 생성은 여러 안정적인 매개변수를 사용하는 해시 함수를 기반으로 한다. 이는 구현별이지만, 최소한 네트워크 접두사, 네트워크 인터페이스 이름, 중복 주소 카운터 및 비밀 키를 포함하는 것이 권장된다. 결과 해시 값은 최종 주소를 구성하는 데 사용된다. 일반적으로 가장 낮은 64비트는 64비트 네트워크 접두사에 연결되어 128비트 주소를 생성한다. 네트워크 접두사가 64비트보다 작으면 해시의 더 많은 비트가 사용된다. 결과 주소가 기존 또는 예약된 주소와 충돌하지 않으면 인터페이스에 할당된다. 충돌은 중복 주소 카운터를 조정하여 해결된다.[50]

이웃 탐색 프로토콜 작동

[편집]

솔리시티드 노드 멀티캐스트 주소

[편집]

SLAAC의 각 인터페이스는 네트워크 접두사 ff02::1:ff00:0/104와 인터페이스의 유니캐스트 또는 애니캐스트 주소의 가장 낮은 24비트에서 형성된 솔리시티드 노드 멀티캐스트 주소도 사용한다. 이 멀티캐스트 주소는 NDP에서 중복 주소를 감지하고 IP 주소와 링크 계층(MAC) 주소 간의 대응을 설정하는 데 사용된다.

중복 주소 감지

[편집]

하드웨어에서 파생되지 않은 주소의 사용은 중복 주소의 가능성을 제시한다. 인터페이스에 유니캐스트 IPv6 주소를 할당하는 것은 이웃 요청(Neighbor Solicitation) 및 이웃 광고(Neighbor Advertisement) (ICMPv6 유형 135 및 136) 메시지를 사용하여 해당 주소의 고유성을 내부적으로 테스트하는 것을 포함한다. 고유성을 확립하는 과정에서 주소는 잠정적인 상태를 갖는다.

노드는 잠정 주소에 대한 솔리시티드 노드 멀티캐스트 주소에 가입하고, 잠정 주소를 대상 주소로, 비지정 주소(::/128)를 소스 주소로 하는 이웃 요청을 보낸다. 또한 노드는 모든 호스트 멀티캐스트 주소 ff02::1에 가입하여 이웃 광고를 수신할 수 있다.

노드가 자신의 잠정 주소를 대상 주소로 하는 이웃 요청을 받으면 자신의 주소가 고유하지 않음을 알게 된다. 잠정 주소를 광고의 소스로 하는 이웃 광고를 수신하는 경우에도 마찬가지이다. 주소가 고유하다는 것을 성공적으로 확립한 후에만 인터페이스에 할당되고 사용될 수 있다.

애니캐스트 주소가 인터페이스에 할당될 때(예: 서브넷-라우터 애니캐스트 주소), 이 유형 주소의 고유성이 내재적으로 없으므로 중복 주소 감지는 수행되지 않는다.

라우터 작동

[편집]

NDP에서 라우터는 더 넓은 인터넷에 접근할 수 있는 /64 크기의 접두사 및 기타 네트워크 매개변수도 광고한다. 이 정보를 수신한 노드는 자체 인터페이스 식별자와 함께 접두사를 결합하여 더 넓은 인터넷에서 유니캐스트 주소를 얻는다. 예를 들어, 라우터가 2001:db8:1:2::/64에 접근할 수 있고 기계에 인터페이스 식별자 02-0C-29-FF-FE-0C-47-D5 (위 예제 계속)가 있는 경우, 기계는 주소 2001:db8:1:2:020c:29ff:fe0c:47d5를 자체 할당한다.

DHCPv6는 다른 목적을 위해 여전히 유용하다. 예를 들어, ISP 라우터가 고객 라우터에 /64 크기 또는 더 짧은 접두사를 전달하는 프리픽스 위임이라는 프로세스에 사용될 수 있다.

주소 수명

[편집]

인터페이스에 바인딩된 각 IPv6 주소에는 정의된 수명이 있다. 수명은 더 짧은 기간으로 구성되지 않는 한 무한하다. 주소의 상태를 관리하는 두 가지 수명이 있다: 선호 수명(preferred lifetime)과 유효 수명(valid lifetime).[51] 수명은 자동 구성에 사용되는 값을 제공하는 라우터에 구성하거나 인터페이스에 주소를 수동으로 구성할 때 지정할 수 있다.

주소가 인터페이스에 할당되면 '선호(preferred)' 상태가 되며, 이는 선호 수명(preferred-lifetime) 동안 유지된다. 해당 수명이 만료되면 상태는 '비권장(deprecated)'이 되며 이 주소를 사용하여 새 연결을 생성해서는 안 된다.[g] 유효 수명(valid-lifetime)도 만료된 후 주소는 '무효(invalid)' 상태가 된다. 주소는 인터페이스에서 제거되며 인터넷의 다른 곳에 할당될 수 있다.

기본 주소 선택

[편집]

IPv6 지원 네트워크 인터페이스는 일반적으로 하나 이상의 IPv6 주소를 가지고 있다. 예를 들어, 링크 로컬 주소와 전역 주소가 있다. 또한 특정 수명이 만료되면 변경되는 임시 주소를 가질 수도 있다. IPv6는 주소 범위 및 선택 선호도 개념을 도입하여 다른 호스트와의 통신에서 소스 및 목적지 주소에 대한 여러 선택지를 제공한다.

선호 선택 알고리즘은 듀얼 스택 구현에서 IPv4 매핑 주소의 사용을 포함하여 특정 목적지와의 통신에 사용할 가장 적절한 주소를 선택한다.[52] 이는 각 라우팅 접두사를 우선 순위 수준과 연결하는 구성 가능한 선호도 테이블을 사용한다. 기본 테이블은 다음 내용을 포함한다.

접두사 우선 순위 레이블 사용처
::1/128 50 0 로컬 호스트
::/0 40 1 기본 유니캐스트
::ffff:0:0/96 35 4 IPv4 매핑 IPv6 주소
2002::/16 30 2 6to4
2001::/32 5 5 테레도 터널링
fc00::/7 3 13 고유 로컬 주소
::/96 1 3 IPv4 호환 주소 (사용 중단됨)
fec0::/10 1 11 사이트 로컬 주소 (사용 중단됨)
3ffe::/16 1 12 6bone (반환됨)

기본 구성은 IPv6 사용에 우선 순위를 두며, 가능한 가장 작은 범위 내에서 목적지 주소를 선택하여, 다른 모든 조건이 동일할 때 전역 라우팅 경로보다 링크 로컬 통신이 선호되도록 한다. 접두사 정책 테이블은 라우팅 테이블과 유사하며, 우선 순위 값은 링크 비용의 역할을 하며, 더 높은 우선 순위는 더 큰 값으로 표현된다. 소스 주소는 목적지 주소와 동일한 레이블 값을 갖는 것이 선호된다. 주소는 가장 긴 일치 최상위 비트 시퀀스를 기반으로 접두사에 매핑된다. 후보 소스 주소는 운영체제에서 얻을 수 있으며, 후보 목적지 주소는 DNS를 통해 쿼리할 수 있다.

통신에 여러 주소가 사용 가능할 때 연결 설정 시간을 최소화하기 위해 해피 아이즈 알고리즘이 고안되었다. 이 알고리즘은 대상 호스트의 IPv6 및 IPv4 주소를 DNS에 쿼리하고, 기본 주소 선택 테이블을 사용하여 후보 주소를 정렬한 다음, 병렬로 연결을 설정하려고 시도한다. 첫 번째로 설정된 연결은 다른 주소에 대한 현재 및 미래의 연결 시도를 중단한다.

도메인 네임 시스템

[편집]

도메인 네임 시스템에서 호스트명은 AAAA 리소스 레코드, 즉 쿼드-A 레코드를 통해 IPv6 주소에 매핑된다.[53] 역방향 DNS 조회를 위해 IETF는 도메인 ip6.arpa를 예약했으며, 여기서 이름 공간은 IPv6 주소의 니블 단위(4비트)의 1자리 십육진법 표현에 의해 계층적으로 나뉜다.

IPv4와 마찬가지로 각 호스트는 DNS에서 두 개의 DNS 레코드, 즉 주소 레코드와 역방향 매핑 포인터 레코드로 표현된다. 예를 들어, example.com 영역의 derrick이라는 호스트 컴퓨터가 고유 로컬 주소 fdda:5cc1:23:4::1f를 갖는다고 가정해 보자. 그 쿼드-A 주소 레코드는 다음과 같다. 

 derrick.example.com.  IN  AAAA  fdda:5cc1:23:4::1f

그리고 그 IPv6 포인터 레코드는 다음과 같다. 

 f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.c.c.5.a.d.d.f.ip6.arpa.  IN  PTR   derrick.example.com.

이 포인터 레코드는 d.f.ip6.arpa 영역의 권한 위임 체인에 따라 여러 영역에서 정의될 수 있다.

DNS 프로토콜은 전송 계층 프로토콜과 독립적이다. 쿼리 및 응답은 요청된 데이터의 주소 패밀리에 관계없이 IPv6 또는 IPv4 전송을 통해 전송될 수 있다.

AAAA 레코드 필드
NAME 도메인 이름
TYPE AAAA (28)
CLASS 인터넷 (1)
TTL Time to live, 초 단위
RDLENGTH RDATA 필드의 길이
RDATA 네트워크 바이트 순서의 128비트 IPv6 주소

역사적 참고 사항

[편집]

사용 중단 및 구식 주소

[편집]
  • 사이트 로컬 접두사 fec0::/10는 주소가 조직의 사이트 네트워크 내에서만 유효함을 지정한다. 이는 1995년 12월의 원래 주소 지정 아키텍처의 일부였지만, 2004년 9월에 '사이트'라는 용어의 정의가 모호하여 혼란스러운 라우팅 규칙을 초래했기 때문에 사용이 중단되었다. 새로운 네트워크는 이러한 특수 유형의 주소를 지원해서는 안 된다.[54] 2005년 10월, 새로운 사양은 이 주소 유형을 고유 로컬 주소로 대체했다.[35]
  • 주소 블록 200::/7은 1996년 8월에 OSI NSAP-매핑 접두사 세트로 정의되었지만,[55][56] 2004년 12월에 사용이 중단되었다.[57]
  • 96비트 0값 접두사 ::/96(원래는 IPv4 호환 주소로 알려짐)은 1995년에 언급되었으나[58] 완전히 설명되지는 않았다. 이 주소 범위는 IPv6 전환 기술 내에서 IPv4 주소를 나타내는 데 사용되었다. 이러한 IPv6 주소는 첫 번째(가장 중요한) 96비트가 0으로 설정되고, 마지막 32비트는 표현된 IPv4 주소이다. 2006년 2월, IETF는 IPv4 호환 주소의 사용을 중단했다.[1] 이 주소 형식의 유일한 남은 용도는 IPv6 주소도 저장할 수 있어야 하는 고정 크기 멤버가 있는 테이블이나 데이터베이스에서 IPv4 주소를 나타내는 것이다.
  • 주소 블록 3ffe::/16은 1998년 12월 6bone 네트워크의 테스트 목적으로 할당되었다.[59] 그 전에는 주소 블록 5f00::/8이 이 목적으로 사용되었다. 두 주소 블록 모두 2006년 6월에 주소 풀로 반환되었다.[60]
  • 6to4의 운영 문제로 인해 주소 블록 2002::/16의 사용은 줄어들고 있다. 6to4 메커니즘은 2015년 5월부터 더 이상 사용되지 않기 때문이다.[38] IPv4 주소 블록 192.88.99.0/24는 더 이상 사용되지 않지만, 2002::/16은 그렇지 않다.
  • 2007년 4월, 주소 블록 2001:10::/28이 ORCHID(Overlay Routable Cryptographic Hash Identifiers)에 할당되었다.[61] 이는 실험용으로 의도되었다. 2014년 9월에 ORCHID의 두 번째 버전이 지정되었고,[33] 블록 2001:20::/28의 도입과 함께 원래 블록은 IANA로 반환되었다.

기타

[편집]
  • 역방향 DNS 조회를 위해 IPv6 주소는 원래 DNS 영역 ip6.int에 등록되었다. arpa 최상위 도메인이 은퇴될 것으로 예상되었기 때문이다. 2000년 인터넷 아키텍처 위원회(IAB)는 이러한 의도를 철회하고 2001년에 arpa가 원래 기능을 유지해야 한다고 결정했다. ip6.int의 도메인은 ip6.arpa로 이전되었으며[62] ip6.int 영역은 2006년 6월 6일에 공식적으로 제거되었다.
  • 2011년 3월, IETF는 최종 사이트에 대한 주소 블록 할당 권장 사항을 개선했다.[23] 2001년 IAB와 IESG의 관점[63]에 따라 /48, /64 또는 /128을 할당하는 대신, 인터넷 서비스 제공업체는 최종 사용자에게 더 작은 블록(예: /56)을 할당하는 것을 고려해야 한다. ARIN, RIPE, APNIC 지역 레지스트리의 정책은 적절한 경우 /56 할당을 권장한다.[23]
  • 원래 도메인 이름을 IPv6 주소로 변환하는 두 가지 제안이 있었다. 하나는 AAAA 레코드를 사용하는 것이고,[64] 다른 하나는 A6 레코드를 사용하는 것이다.[65] 우세했던 AAAA 레코드 방식은 IPv4의 A 레코드와 유사하여 호스트 이름에서 IPv6 주소로 간단한 매핑을 제공한다. A6 레코드를 사용하는 방식은 계층적 체계를 사용했는데, 주소 비트의 후속 그룹 매핑은 추가 A6 레코드로 지정되어 단일 A6 레코드를 변경하여 네트워크의 모든 호스트를 재넘버링할 수 있는 가능성을 제공했다. A6 형식의 인지된 이점이 인지된 비용보다 크지 않다고 판단되어[66][67][68][69] 이 방식은 2002년에 실험 상태로 이동되었고,[67] 최종적으로 2012년에 역사적 상태로 이동되었다.[69]
  • 2009년, 홈 네트워킹 NAT 장치 및 라우터의 많은 DNS 확인자가 AAAA 레코드를 부적절하게 처리하는 것으로 나타났다.[70] 이들 중 일부는 적절한 부정적인 DNS 응답을 반환하는 대신 단순히 이러한 레코드에 대한 DNS 요청을 삭제했다. 요청이 삭제되면 요청을 보내는 호스트는 시간 초과를 기다려야 하므로 듀얼 스택 IPv6/IPv4 호스트에 연결할 때 지연이 증가한다. 클라이언트 소프트웨어는 IPv4를 시도하기 전에 IPv6 연결이 실패할 때까지 시간 초과를 기다리기 때문이다. 해피 아이즈는 이 문제에 대한 해결책을 제공한다.

내용주

[편집]
  1. ↑ 16비트 또는 2개의 옥텟 수량은 때때로 헥스텟이라고도 불린다.[7][8]
  2. ↑ eth2가 영역 번호 3과 동일하다고 가정한다. 실제 영역 번호는 1부터 시작하므로(0은 '기본 영역') 보통 그렇다
  3. ↑ 윈도우는 이름에서 인터페이스 번호로 변환하는 RFC 3493 if_nametoindex() API를 지원하지만, 일반적인 "% 뒤의 이름" 확장자는 지원하지 않는다.
  4. ↑ 현재 제거된 fec0::/10의 사이트 로컬 주소도 영역 인덱스가 필요하다.[12]
  5. ↑ IPv4에서는 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24가 문서화에 사용된다.[41]
  6. ↑ 비트코인 채굴의 '작업 증명' 필드와 유사하다.
  7. ↑ 대부분의 경우, 새 라우터 광고(RA)가 타이머를 새로 고치므로 수명이 만료되지 않는다. 그러나 더 이상 RA가 없으면 결국 선호 수명이 경과하고 주소는 비권장 상태가 된다.

각주

[편집]
  1. ↑ 가 나 다 라 마 바 사 아 R. Hinden; S. Deering (February 2006). IP Version 6 Addressing Architecture. Network Working Group. RFC 4291. https://tools.ietf.org/html/rfc4291.  Draft Standard. Obsoletes RFC 3513. Updated by RFC 5952, 6052, 7136, 7346, 7371 and 8064.
  2. ↑ F. Gont; A. Cooper; D. Thaler; W. Liu (February 2017). Recommendation on Stable IPv6 Interface Identifiers. IETF. RFC 8064. https://tools.ietf.org/html/rfc8064.  Proposed Standard. Updates RFC 2464, 2467, 2470, 2491, 2492, 2497, 2590, 3146, 3572, 4291, 4338, 4391, 5072 and 5121.
  3. ↑ Silvia Hagen (May 2006). 《IPv6 Essentials》 Seco판. O'Reilly. ISBN 978-0-596-10058-2. 
  4. ↑ 가 나 P. Savola; B. Haberman (November 2004). Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. Network Working Group. RFC 3956. https://tools.ietf.org/html/rfc3956.  Proposed Standard. Updated by RFC 7371. Updates RFC 3306.
  5. ↑ 가 나 B. Haberman; D. Thaler (August 2002). Unicast-Prefix-based IPv6 Multicast Addresses. Network Working Group. RFC 3306. https://tools.ietf.org/html/rfc3306.  Proposed Standard. Updated by RFC 3956, 4489 and 7371.
  6. ↑ J-S. Park; M-K. Shin; H-J. Kim (April 2006). A Method for Generating Link-Scoped IPv6 Multicast Addresses. Network Working Group. RFC 4489. https://tools.ietf.org/html/rfc4489.  Proposed Standard. Updates RFC 3306.
  7. ↑ Graziani, Rick (2012). 《IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6》. Cisco Press. 55쪽. ISBN 978-0-13-303347-2. 
  8. ↑ Coffeen, Tom (2014). 《IPv6 Address Planning: Designing an Address Plan for the Future》. 오라일리 미디어. 170쪽. ISBN 978-1-4919-0326-1. 
  9. ↑ S. Kawamura; M. Kawashima (August 2010). A Recommendation for IPv6 Address Text Representation. Internet Engineering Task Force. ISSN 2070-1721. RFC 5952. https://tools.ietf.org/html/rfc5952.  Proposed Standard. Updates RFC 4291.
  10. ↑ T. Berners-Lee; R. Fielding; L. Masinter (January 2005). Uniform Resource Identifier (URI): Generic Syntax. Network Working Group. STD 66. RFC 3986. https://tools.ietf.org/html/rfc3986.  Internet Standard. Obsoletes RFC 2732, 2396 and 1808. Updated by RFC 6874, 7320 and 8820. Updates RFC 1738.
  11. ↑ 가 나 S. Deering; B. Haberman; T. Jinmei; E. Nordmark; B. Zill (March 2005). IPv6 Scoped Address Architecture. Network Working Group. RFC 4007. https://tools.ietf.org/html/rfc4007.  Proposed Standard. Updated by RFC 7346.
  12. ↑ 가 나 inet6(4) – FreeBSD Kernel Interfaces 매뉴얼 페이지 "KAME 구현은 "fe80::1%de0"과 같은 링크 로컬 주소를 위한 확장된 숫자 IPv6 주소 표기법을 지원한다 [...] draft-ietf-ipngwg-scopedaddr-format-02.txt"
  13. ↑ B. Carpenter; S. Cheshire; R. Hinden (February 2013). Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. IETF. ISSN 2070-1721. RFC 6874. https://tools.ietf.org/html/rfc6874.  Proposed Standard. Updates RFC 3986.
  14. ↑ “ipv6-literal.net Domain History”. who.is. 2014년 10월 20일에 확인함. 
  15. ↑ R. Droms (August 2014). IPv6 Multicast Address Scopes. Internet Engineering Task Force. ISSN 2070-1721. RFC 7346. https://tools.ietf.org/html/rfc7346.  Proposed Standard. Updates RFC 4007 and 4291.
  16. ↑ Internet Architecture Board; Internet Engineering Steering Group (December 1995). IPv6 Address Allocation Management. Network Working Group. RFC 1881. https://tools.ietf.org/html/rfc1881.  Informational.
  17. ↑ IPv6 address space at IANA. Iana.org (2010-10-29). Retrieved on 2011-09-28.
  18. ↑ IPv6 unicast address assignments, IANA
  19. ↑ DE-TELEKOM-20050113 db.ripe.net. Retrieved 2011-09-28.
  20. ↑ “ARIN Number Resource Policy Manual: Initial allocation to ISPs”. 
  21. ↑ “RIPE NCC IPv6 Address Allocation and Assignment Policy: Minimum allocation”. 
  22. ↑ for example. Iana.org. Retrieved on 2011-09-28.
  23. ↑ 가 나 다 T. Narten; G. Huston; L. Roberts (March 2011). IPv6 Address Assignment to End Sites. Internet Engineering Task Force (IETF). ISSN 2070-1721. BCP 157. RFC 6177. https://tools.ietf.org/html/rfc6177.  Best Common Practice. Obsoletes RFC 3177.
  24. ↑ “IPv6 Addressing Plans”. ARIN IPv6 Wiki. 2018년 7월 15일에 확인함. 모든 고객은 65k 서브넷 이상이 필요함을 입증하지 않는 한 /48를 받는다. [...] 소비자 고객이 많다면 사설 주거지에 /56를 할당하는 것이 좋다. 
  25. ↑ “What are Bogons?”. 2021년 11월 15일에 확인함. 
  26. ↑ “Address Space Managed by the RIPE NCC”. 2011년 5월 22일에 확인함. 
  27. ↑ D. Johnson; S. Deering (March 1999). Reserved IPv6 Subnet Anycast Addresses. Network Working Group. RFC 2526. https://tools.ietf.org/html/rfc2526.  Proposed Standard.
  28. ↑ 가 나 M. Cotton; L. Vegoda; B. Haberman (April 2013). R. Bonica. ed. Special-Purpose IP Address Registries. IETF. ISSN 2070-1721. BCP 153. RFC 6890. https://tools.ietf.org/html/rfc6890.  Best Common Practice. Obsoletes RFC 4773, 5156, 5735 and 5736. Updated by RFC 8190.
  29. ↑ “IANA IPv6 Special-Purpose Address Registry”. 《www.iana.org》. 2024년 8월 2일에 확인함. 
  30. ↑ 가 나 다 라 C. Bao; C. Huitema; M. Bagnulo; M. Boucadair; X. Li (October 2010). IPv6 Addressing of IPv4/IPv6 Translators. IETF. ISSN 2070-1721. RFC 6052. https://tools.ietf.org/html/rfc6052.  Proposed Standard. Updates RFC 4291.
  31. ↑ 가 나 T. Anderson (August 2017). Local-Use IPv4/IPv6 Translation Prefix. Internet Engineering Task Force. RFC 8215. https://tools.ietf.org/html/rfc8215.  Proposed Standard.
  32. ↑ 가 나 N. Hilliard; D. Freedman (August 2012). A Discard Prefix for IPv6. Internet Engineering Task Force. ISSN 2070-1721. RFC 6666. https://tools.ietf.org/html/rfc6666.  Informational.
  33. ↑ 가 나 다 J. Laganier; F. Dupont (September 2014). An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2). Internet Engineering Task Force. ISSN 2070-1721. RFC 7343. https://tools.ietf.org/html/rfc7343.  Proposed Standard. Obsoletes RFC 4843.
  34. ↑ 가 나 G. Huston; A. Lord; P. Smith (July 2004). IPv6 Address Prefix Reserved for Documentation. Network Working Group. RFC 3849. https://tools.ietf.org/html/rfc3849.  Informational.
  35. ↑ 가 나 다 라 R. Hinden; B. Haberman (October 2005). Unique Local IPv6 Unicast Addresses. Network Working Group. RFC 4193. https://tools.ietf.org/html/rfc4193.  Proposed Standard.
  36. ↑ E. Nordmark (February 2000). Stateless IP/ICMP Translation Algorithm (SIIT). Network Working Group. RFC 2765. https://tools.ietf.org/html/rfc2765.  Obsolete. Obsoleted by RFC 6145.
  37. ↑ 가 나 C. Bao; X. Li; F. Baker; T. Anderson; F. Gont (June 2016). IP/ICMP Translation Algorithm. Internet Engineering Task Force (IETF). RFC 7915. https://tools.ietf.org/html/rfc7915.  Proposed Standard. Obsoletes RFC 6145.
  38. ↑ 가 나 O. Troan (May 2015). B. Carpenter. ed. Deprecating the Anycast Prefix for 6to4 Relay Routers. Internet Engineering Task Force. BCP 196. RFC 7526. https://tools.ietf.org/html/rfc7526.  Best Common Practice. Obsoletes RFC 3068 and 6732.
  39. ↑ R. Hinden; S. Deering; R. Fink; T. Hain (September 2000). Initial IPv6 Sub-TLA ID Assignments. Network Working Group. RFC 2928. https://tools.ietf.org/html/rfc2928.  Informational.
  40. ↑ C. Popoviciu; A. Hamza; G. Van de Velde; D. Dugatkin (May 2008). IPv6 Benchmarking Methodology for Network Interconnect Devices. Network Working Group. RFC 5180. https://tools.ietf.org/html/rfc5180.  Informational.
  41. ↑ J. Arkko; M. Cotton; L. Vegoda (January 2010). IPv4 Address Blocks Reserved for Documentation. Internet Engineering Task Force. ISSN 2070-1721. RFC 5737. https://tools.ietf.org/html/rfc5737.  Informational. Updates RFC 1166.
  42. ↑ “IPv6 Multicast Address Space Registry”. IANA. 
  43. ↑ 가 나 T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (November 2018). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). IETF. ISSN 2070-1721. RFC 8415. https://tools.ietf.org/html/rfc8415.  Proposed Standard. Obsoletes RFC 3315, 3633, 3736, 4242, 7083, 7283 and 7550.
  44. ↑ S. Thomson; T. Narten; T. Jinmei (September 2007). IPv6 Stateless Address Autoconfiguration. Network Working Group. RFC 4862. https://tools.ietf.org/html/rfc4862.  Draft Standard. Obsoletes RFC 2462. Updated by RFC 7527.
  45. ↑ T. Narten; E. Nordmark; W. Simpson; H. Holiman (September 2007). Neighbor Discovery for IP version 6 (IPv6). Network Working Group. RFC 4861. https://tools.ietf.org/html/rfc4861.  Draft Standard. Obsoletes RFC 2461. Updated by RFC 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425 and 9131.
  46. ↑ The privacy implications of stateless IPv6 addressing. Portal.acm.org (2010-04-21). Retrieved on 2011-09-28.
  47. ↑ F. Gont; S. Krishnan; T. Narten; R. Draves (February 2021). Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6. Internet Engineering Task Force. ISSN 2070-1721. RFC 8981. https://tools.ietf.org/html/rfc8981.  Proposed Standard. Obsoletes RFC 4941.
  48. ↑ “IPv6 on Windows”. 2024년 3월 25일에 확인함. 
  49. ↑ T. Aura (March 2005). Cryptographically Generated Addresses (CGA). Network Working Group. RFC 3972. https://tools.ietf.org/html/rfc3972.  Proposed Standard. Updated by RFC 4581 and 4982.
  50. ↑ 가 나 F. Gont (April 2014). A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). Internet Engineering Task Force. ISSN 2070-1721. RFC 7217. https://tools.ietf.org/html/rfc7217.  Proposed Standard.
  51. ↑ Iljitsch van Beijnum (2006). “IPv6 Internals”. 《The Internet Protocol Journal》 9 (3). 16–29면. 
  52. ↑ D. Thaler; R. Draves; A. Matsumoto; T. Chown (September 2012). D. Thaler. ed. Default Address Selection for Internet Protocol Version 6 (IPv6). IETF. ISSN 2070-1721. RFC 6724. https://tools.ietf.org/html/rfc6724.  Proposed Standard. Obsoletes RFC 3484.
  53. ↑ S. Thomson; C. Huitema; V. Ksinant; M. Souissi (October 2003). DNS Extensions to Support IP Version 6. Network Working Group. RFC 3596. https://tools.ietf.org/html/rfc3596.  Internet Standard. Obsoletes RFC 3152 and 1886.
  54. ↑ C. Huitema; B. Carpenter (September 2004). Deprecating Site Local Addresses. Network Working Group. RFC 3879. https://tools.ietf.org/html/rfc3879.  Proposed Standard.
  55. ↑ G. Houston (Aug 2005). Proposed Changes to the Format of the IANA IPv6 Registry. Network Working Group. RFC 4147. https://tools.ietf.org/html/rfc4147.  Informational.
  56. ↑ J. Bound; B. Carpenter; D. Harrington; J. Houldsworth; A. Lloyd (August 1996). OSI NSAPs and IPv6. Network Working Group. RFC 1888. https://tools.ietf.org/html/rfc1888.  Obsolete. Obsoleted by RFC 4048. Updated by RFC 4548.
  57. ↑ B. Carpenter (Apr 2005). RFC 1888 Is Obsolete. RFC 4048. https://tools.ietf.org/html/rfc4048.  Informational. Updated by RFC 4548.
  58. ↑ 인용 오류: <ref> 태그가 잘못되었습니다; rfc1884라는 이름을 가진 주석에 텍스트가 없습니다
  59. ↑ R. Hinde; R. Fink; J. Postel (December 1998). IPv6 Testing Address Allocation. Network Working Grouop. RFC 2471. https://tools.ietf.org/html/rfc2471.  Obsolete. Obsoleted by RFC 3701. Obsoletes RFC 1897.
  60. ↑ R. Fink; R. Hinden (March 2004). 6bone (IPv6 Testing Address Allocation) Phaseout. Network Working Group. RFC 3701. https://tools.ietf.org/html/rfc3701.  Informational. Obsoletes RFC 2471.
  61. ↑ P. Nikander; J. Laganier; F. Dupont (April 2007). An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). Network Working Group. RFC 4843. https://tools.ietf.org/html/rfc4843.  Obsolete. Obsoleted by RFC 7343.
  62. ↑ R. Bush (August 2001). Delegation of IP6.ARPA. Network Working Group. BCP 49. RFC 3152. https://tools.ietf.org/html/rfc3152.  Obsolete. Obsoleted by RFC 3596. Updates RFC 1886, 2553, 2766, 2772 and 2874
  63. ↑ IAB; IESG (September 2001). IAB/IESG Recommendations on IPv6 Address Allocations to Sites. Network Working Group. RFC 3177. https://tools.ietf.org/html/rfc3177.  Obsolete. Obsoleted by RFC 6177.
  64. ↑ S. Thomson; C. Huitema (December 1995). DNS Extensions to support IP version 6. Network Working Group. RFC 1886. https://tools.ietf.org/html/rfc1886.  Obsolete. Obsoleted by RFC 3596. Updated by RFC 2874 and 3152.
  65. ↑ M. Crawford; C. Huitema (July 2000). DNS Extensions to Support IPv6 Address Aggregation and Renumbering. Network Working Group. RFC 2874. https://tools.ietf.org/html/rfc2874.  Historic. Updated by RFC 3152, 3226, 3363 and 3364. Updates RFC 1886.
  66. ↑ Comparison of AAAA and A6 (do we really need A6?), Jun-ichiro itojun Hagino, (July 2001)
  67. ↑ 가 나 R. Bush; A. Durand; B. Fink et al., eds. (August 2002). Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). Network Working Group. RFC 3363. https://tools.ietf.org/html/rfc3363.  Informational. Updates RFC 2673, 2874.
  68. ↑ R. Austein (August 2002). Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). Network Working Group. RFC 3364. https://tools.ietf.org/html/rfc3364.  Informational. Updates RFC 2673, 2874.
  69. ↑ 가 나 A. Bierman; M. Bjorklund (March 2012). Network Configuration Protocol (NETCONF) Access Control Model. Internet Engineering Task Force. RFC 6536. https://tools.ietf.org/html/rfc6536.  Obsolete. Obsoleted by RFC 8341.
  70. ↑ Y. Morishita; T. Jinmei (May 2005). Common Misbehavior Against DNS Queries for IPv6 Addresses. RFC 4074. https://tools.ietf.org/html/rfc4074.  Informational.

추가 읽을거리

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=IPv6_주소&oldid=40822896"