IPv6 주소

IPv6 address
IPv6 주소를 이진 형식으로 분해

인터넷 프로토콜 버전 6 주소(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 서버에서 가져온 수정된 EUI-64 형식을 사용하여 인터페이스의 MAC 주소에서 자동으로 생성되거나, 임의로 자동으로 설정되거나, 수동으로 할당된다.

고유 로컬 주소는 IPv4 전용 네트워크 주소와 유사한 주소다.

고유한 로컬 주소 형식
조각들 7 1 40 16 64
밭을 갈다 접두사를 붙이다 L 무작위의 서브넷 ID 인터페이스 식별자

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

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

링크 로컬 주소 형식
조각들 10 54 64
밭을 갈다 접두사를 붙이다 영점 인터페이스 식별자

접두사 필드에는 이진수 값 11111010이 포함되어 있다.뒤에 나오는 54개의 0은 모든 링크 로컬 주소(fe80::/64 링크 로컬 주소 접두사)에 대해 총 네트워크 접두사를 동일하게 하여 라우팅할 수 없게 한다.

멀티캐스트 주소 형식

추가 정보:멀티캐스트 주소 § IPv6

멀티캐스트 어드레스는 어플리케이션에 따라 몇 가지 구체적인 포맷 규칙에 따라 형성된다.

일반 멀티캐스트 주소 형식
조각들 8 4 4 112
밭을 갈다 접두사를 붙이다 털갈이하다 샅이 뒤지다 그룹 ID

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

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

멀티캐스트 주소 플래그[2]
물다 깃발을 꽂다 0일 때의 의미 1일 때의 의미
8 내성의 내성의 내성의
9 R (랑데부)[3] 랑데부 지점이 포함되지 않음 랑데부 포인트 내장
10 P(프리픽스)[4] 접두사 정보 없음 네트워크 접두사 기반 주소
11 T(변환)[1] 잘 알려진 멀티캐스트 주소 동적으로 할당된 멀티캐스트 주소

4비트 범위 필드(sc)는 주소가 올바르고 고유한 위치를 나타내기 위해 사용된다.

또한 스코프 필드는 요청된 노드 같은 특수 멀티캐스트 주소를 식별하는 데 사용된다.

요청된 노드 멀티캐스트 주소 형식
조각들 8 4 4 79 9 24
밭을 갈다 접두사를 붙이다 털갈이하다 샅이 뒤지다 영점 하나 유니캐스트 주소

sc(ope) 필드는 이진수 값 0010(링크-로컬)을 보유한다.요청된 노드 멀티캐스트 주소는 노드의 유니캐스트 또는 모든 캐스트 주소의 함수로 계산된다.요청된 노드 멀티캐스트 주소는 유니캐스트 또는 캐스트 주소의 마지막 24비트를 멀티캐스트 주소의 마지막 24비트로 복사함으로써 생성된다.

유니캐스트 프리픽스 기반 멀티캐스트 주소 형식[3][4]
조각들 8 4 4 4 4 8 64 32
밭을 갈다 접두사를 붙이다 털갈이하다 샅이 뒤지다 재방송하다 리드의 터벅터벅 걷다 네트워크 접두사 그룹 ID

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

표현

IPv6 주소는 16비트를[a] 나타내는 각 그룹 16진수 4자리 8개 그룹으로 표시된다. 그룹은 콜론(:)으로 구분된다.IPv6 주소의 예는 다음과 같다.

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

표준은 IPv6 주소의 표현에 유연성을 제공한다.8개의 4자리 그룹의 전체 표현은 몇 가지 기법으로 단순화하여 표현의 일부를 제거할 수 있다.일반적으로 표현은 가능한 한 단축된다.그러나 이러한 관행은 텍스트 문서나 스트림에서 특정 주소나 주소 패턴을 검색하고 주소를 비교하여 동등성을 결정하는 것과 같은 몇 가지 일반적인 작업을 복잡하게 만든다.이러한 복잡성을 완화하기 위해 IETF는 IPv6 주소를 텍스트로 렌더링하기 위한 표준 형식을 정의했다.[8]

  • 16진수는 항상 대소문자를 구분하지 않는 방식으로 비교되지만 IETF 권고안은 소문자만 사용할 것을 제안한다.예를 들어 2001:db8::1이 2001보다 선호된다.DB8::1;
  • 각 16비트 필드의 선행 0은 억제되지만 각 그룹은 최소한 한 자리수를 유지해야 한다.예를 들어 2001:0db8::0001:0000은 2001:db8::1:0으로 렌더링된다.
  • 연속 올제로 필드의 가장 긴 순서는 콜론 2개(::)로 대체한다.주소가 같은 크기의 0개 필드의 다중 런을 포함하는 경우, 모호성을 방지하기 위해 가장 왼쪽이 압축된 것이다.예를 들어 2001:db8:0:0:0:0:0:0:0:0:0:0:0:1:0:1:0:1:0:1:1:0:1 : : : ::는 하나의 올제로 필드만을 나타내기 위해 사용되지 않는다.예를 들어 2001:db8:0:0:0:0:0:2:1로 단축되지만 2001:db8:00:00:1:1:1:1:1:1은 2001:db8:0:1:1:1:1:1:1:1:1로 렌더링된다.

이러한 방법은 IPv6 주소를 매우 짧게 나타낼 수 있다.예를 들어 localhost(루프백) 주소, 0:0:0:0:0:0:0:0:0:1 및 IPv6 지정되지 않은 주소인 0:0:0:0:0:0:0:0:0:0:0:0:0:0은 각각 :1과 : : : : : : : :로 축소된다.

인터넷이 IPv4에서 IPv6으로 전환되는 동안 혼합 주소 환경에서 작동하는 것이 일반적이다.이러한 사용 사례에 대해서는, 친숙한 IPv4 도트-십진법 표기법으로 주소의 최소 유의 32비트를 작성하여 IPv4-매핑 및 IPv4 호환 IPv6 주소를 표현하는 특수 표기법이 도입되었다. 반면, 96개의 가장 유의미한 비트는 IPv6 형식으로 작성되었다.예를 들어 IPv4 매핑된 IPv6 주소 ::ffff:c000:0280은 ::ffff:192.0.2.128로 쓰여 있으므로 IPv6에 매핑된 원래 IPv4 주소를 명확하게 표현한다.

네트워크

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

네트워크 주소 범위는 CIDR 표기법으로 작성된다.네트워크는 블록의 첫 번째 주소(모든 0으로 끝나는 주소), 슬래시(/), 접두사의 비트 크기와 같은 십진수 값으로 표시된다.예를 들어 2001:db8:1234:::/48로 작성된 네트워크는 주소 2001:db8:1234:0000:0000:0000:0000:0000에서 시작하여 2001:db8:1234:fffff:fffff:fffff:fff:ffffff:fff:fff:fff:fff:fff:fff에 종료한다.

인터페이스 주소의 라우팅 접두사는 CIDR 표기법을 사용하는 주소로 직접 표시할 수 있다.예를 들어 주소 2001:db8:a:::123이 서브넷 2001:db8:a:::/64에 연결된 인터페이스의 구성은 2001:db8:a:::123/64로 기록된다.

주소 블록 크기

주소 블록의 크기는 슬래시(/)를 작성한 후 10진수 숫자로 네트워크 접두사 길이(비트)를 지정한다.예를 들어 접두사에 48비트가 있는 주소 블록은 /48로 표시된다.이러한 블록은 2128 − 48 = 2 주소를80 포함한다.네트워크 접두사 값이 작을수록 블록: /21 블록은 /24 블록보다 8배 크다.

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

IPv6 주소의 콜론(:) 문자는 URI 및 URL과 같은 리소스 식별자의 확립된 구문과 충돌할 수 있다.콜론은 전통적으로 포트 번호 이전에 호스트 경로를 종료하는 데 사용되어 왔다.[9]이러한 충돌을 완화하기 위해 리터럴 IPv6 주소는 다음과 같은 리소스 식별자에서 대괄호로 묶는다.

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

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

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

여기서 후행 443은 예시의 포트 번호다.

범위 지정 리터럴 IPv6 주소(구역 색인 포함)

글로벌 범위를 제외한 주소(아래 설명)와 특히 링크 로컬 주소의 경우, 패킷 전송을 위한 네트워크 인터페이스의 선택은 주소가 어느 구역에 속하느냐에 따라 달라질 수 있다: 동일한 주소가 다른 구역에서 유효할 수 있으며, 각 구역에서 다른 호스트가 사용 중이다.단일 주소가 다른 영역에서 사용되고 있지 않더라도, 해당 구역의 주소 접두사는 여전히 동일할 수 있으므로, 운영 체제는 (접두사 기반인) 라우팅 테이블의 정보에 기초하여 송신 인터페이스를 선택할 수 없다.

텍스트 주소의 모호성을 해소하기 위해서는 구역 지수를 주소에 추가해야 하며, 두 지수를 백분율 기호(%)[10]로 구분해야 한다.구역 지수의 구문은 구현에 의존하는 문자열이지만, 숫자 구역 지수도 보편적으로 지원되어야 한다.링크 로컬 주소

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

에 의해 표현될 수 있다.

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

또는:

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

전자(인터페이스 이름 사용)는 대부분의 Unix 유사 운영 체제(예: BSD, Linux, macOS)에서 관습적으로 사용된다.후자(인터페이스 번호 사용)는 마이크로소프트 윈도에서는 표준 구문이지만, 이 구문에 대한 지원이 필수적이기 때문에 다른 운영 체제에서도 사용할 수 있다.

BSD 기반 운영 체제(macOS 포함)도 대체적인 비표준 구문을 지원하는데, 여기서 숫자 영역 색인이 주소의 두 번째 16비트 단어로 인코딩된다.예:

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

위에서 언급한 모든 운영 체제에서 링크 로컬 주소에 대한 구역 지수는 실제로 구역이 아닌 인터페이스를 가리킨다.여러 인터페이스가 동일한 영역(예: 동일한 스위치에 연결되었을 때)에 속할 수 있으므로, 실제로는 서로 다른 영역 식별자를 가진 두 개의 주소가 실제로 동일할 수 있으며, 동일한 링크의 동일한 호스트를 참조한다.

URI의 구역 지수 사용

균일한 리소스 식별자(URI)에서 사용할 경우 백분율 기호를 사용하면 구문 충돌이 발생하므로 백분율 인코딩을 통해 다음과 같이 이스케이프해야 한다.[11]

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

UNC 경로 이름의 리터럴 IPv6 주소

Microsoft 윈도우즈 운영 체제에서 IPv4 주소는 UNC(유니트 명명 규칙) 경로 이름에 유효한 위치 식별자임.그러나, 결장은 UNC 경로 이름의 불법 문자다.따라서, IPv6 주소의 사용은 UNC 이름에서도 불법이다.이 때문에 마이크로소프트는 UNC 경로에서 사용할 수 있는 도메인 이름의 형태로 IPv6 주소를 나타내는 전사 알고리즘을 구현했다.이를 위해 마이크로소프트는 2단계 도메인 ipv6-literal.net을 인터넷에 등록해 예약했다(2014년[12] 1월 도메인을 포기했지만).IPv6 주소는 이 이름 공간 내에서 호스트 이름 또는 하위 도메인 이름으로 변환되며, 다음과 같은 방식으로 변환된다.

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

라고 쓰여 있다.

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

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

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

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

라고 쓰여 있다.

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

주소 범위

지정되지 않은 주소(::)를 제외한 모든 IPv6 주소에는 "스코프"가 있으며, 이 "스코프"[10]는 네트워크의 어느 부분에 유효한지 명시한다.

유니캐스트

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

링크-로컬 어드레스와 루프백 어드레스는 링크-로컬 스코프가 있어, 그것들은 단일 직접 연결된 네트워크(링크)에서만 사용할 수 있다는 것을 의미한다.다른 모든 주소(Unique local address 포함)는 글로벌(또는 범용) 범위를 가지며, 이는 글로벌 범위를 가진 주소 또는 직접 연결된 네트워크에서 링크 로컬 범위를 가진 주소에 연결하는 데 사용할 수 있다.하나의 범위에 소스 또는 대상이 있는 패킷은 다른 스코프로 라우팅할 수 없다.[13]

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

애니캐스트

모든 캐스트 주소는 구문론적으로 동일하며 유니캐스트 주소와 구분할 수 없다.그들의 유일한 차이점은 행정이다.따라서 모든 캐스트 주소의 범위는 유니캐스트 주소와 동일하다.

멀티캐스트

멀티캐스트 어드레스의 경우, 두 번째 어드레스 옥텟(ff0s::)의 네 가지 중요도가 낮은 비트는 주소 범위, 즉 멀티캐스트 패킷이 전파되어야 하는 도메인을 식별한다.사전 정의된 및 예약된 범위[1]:

범위 값
가치 범위명 메모들
0x0 내성의
0x1 인터페이스-로 된 인터페이스 로컬 스코프는 노드의 단일 인터페이스에만 적용되며 멀티캐스트의 루프백 전송에만 유용하다.
0x2 국부적 링크 로컬 스코프는 해당 유니캐스트 스코프와 동일한 위상학적 영역에 걸쳐 있다.
0x3 국부적 영역 로컬 범위는 링크 로컬보다 큰 것으로 정의되며 네트워크 토폴로지에 의해 자동으로 결정되며 다음 범위보다 커서는 안 된다.[14]
0x4 행정 구역의 관리 로컬 범위는 관리적으로 구성해야 하는 최소 범위로서, 즉 물리적 연결이나 기타 비 멀티캐스트 관련 구성에서 자동으로 파생되지 않는다.
0x5 현지의 사이트-지역 범위는 조직에 속하는 단일 사이트를 포괄하는 것을 목적으로 한다.
0x8 지역 조직 조직-지역 범위는 단일 조직에 속하는 모든 사이트를 포괄하는 것을 목적으로 한다.
0xe 전지구적 전지구적 범위는 인터넷의 모든 도달 가능한 노드에 걸쳐 있다 - 그것은 무한하다.
0xf 내성의

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

주소 공간

일반할당

IPv6 주소 할당 프로세스의 관리는 인터넷 아키텍처 위원회와 인터넷 엔지니어링 스티어링 그룹에 의해 IANA([15]Internet Assigned Numbers Authority)에 위임된다.그것의 주요 기능은 네트워크 서비스 제공자와 다른 지역 등록국에 할당하는 위임된 임무를 가진 지역 인터넷 등록국에 대형 주소 블록을 할당하는 것이다.IANA는 1995년 12월부터 IPv6 주소 공간의 공식 할당 목록을 유지하고 있다.[16]

전체 주소 공간의 8분의 1만 현재 인터넷 사용용으로 할당되어 효율적인 경로 집계를 제공함으로써 인터넷 라우팅 테이블의 크기를 줄인다. 나머지 IPv6 주소 공간은 미래 또는 특수 목적을 위해 예약된다.주소 공간은 /23의 큰 블록에서 /12까지 /IRs에 할당된다.[17]

RIR는 더 작은 블록을 사용자에게 배포하는 로컬 인터넷 레지스트리에 할당한다.이것들은 일반적으로 /19에서 /32까지 크기가 있다.[18][19][20]주소는 일반적으로 최종 사용자에게 /48에서 /56 크기의 블록으로 배포된다.[21]

글로벌 유니캐스트 할당 레코드는 다양한 RIR 또는 다른 웹사이트에서 찾을 수 있다.[22]

로 IPv4주소로 assignments—the 권장된 분배는 280주소가 포함된 /48 블록, 248일 혹은 2.8×1014배 232개의 주소를 전체 IPv4주소 공간보다 약 7.2×1016번은 IPv4주소의 맞게 된다. 그 /8의 블록보다 더 큰 더 큰 것은 비해 IPv6주소 단체에 훨씬 더 큰 블록에 따라 할당됩니다.e는 largIPv4 주소 할당.그러나 총 풀은 2개128(정확히 340,282,366,920,938,463,463,374,607,431,768,211,456) 또는 약 3.4×1038(340조)의 고유한 IPv6 주소가 있기 때문에 예측 가능한 미래에 충분하다.

각 RIR는 각각의 다중 /23 블록을 512 /32 블록으로 나눌 수 있으며, 일반적으로 ISP는 그것의 /32 블록을 65536 /48 블록으로 나눌 수 있고,[23] 고객들은 그들의 할당된 /48 블록에서 65536 /64 네트워크를 만들 수 있고, 각각 2개64(18,446,7444,073,709,551,616) 주소를 가지고 있다.이와는 대조적으로 전체 IPv4 주소 공간에는 2개의32 주소(정확히 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[24] 범위의 특별 주소가 할당된다.

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

예약된 임의의 캐스트 주소

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

각 /64 서브넷 접두사 내에서 가장 높은 128개의 주소는 모든 캐스트 주소로 사용되도록 예약되어 있다.[26]이 주소들은 보통 인터페이스 식별자의 처음 57비트를 1로 설정하고 그 다음에 7비트 애니캐스트 ID를 가진다.서브넷을 포함한 네트워크 접두사는 64비트의 길이가 필요하며, 이 경우 주소가 전역적으로 고유하지 않음을 나타내려면 범용/로컬 비트를 0으로 설정해야 한다.7개의 최소 중요 비트에서 값이 0x7e인 주소는 이동형 IPv6 홈 에이전트 애니캐스트 주소로 정의된다.값이 0x7f(모든 비트 1)인 주소는 예약되어 있으므로 사용할 수 없다.이 범위의 할당은 더 이상 수행되지 않으므로 값 0x00 ~ 0x7d도 예약된다.

특별주소

참고 항목:예약된 IP 주소 § IPv6

IPv6에는 특별한 의미를 갖는 여러 주소가 있다.[27]전체 주소 공간의 2% 미만:

특수 주소 블록
주소 블록(CIDR) 첫 번째 주소 마지막 주소 주소 수 사용법 목적
::/0 :: fff:ffffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffffff 2128 라우팅 기본 경로(특정 경로 없음)
::/128 :: :: 1 소프트웨어 지정되지 않은 주소
::1/128 ::1 ::1 1 호스트 루프백 주소—모든 트래픽을 자체, 로컬 호스트로 되돌리는 가상 인터페이스
::fff:0:0:0/96 ::ffff:0.0.0.0 ::fff:fiff.properties.properties.fiff. 2128 − 96 = 232 = 4294967296 소프트웨어 IPv4 매핑된 주소
::ffff:0:0:0:0/96 ::ffff:0:0.0.0.0 ::fff:0:reason.properties.properties.properties 232 소프트웨어 IPv4 변환된 주소
64:ff9b::/96 64:ff9b::0.0.0.0.0 64:ff9b::192.190.190.190.190.201 232 글로벌 인터넷 IPv4/IPv6 변환[28]
64:ff9b:1::/48 64:ff9b:1::0.0.0.0 64:ff9b:1:ffffff:ffff:ffff:fff:fff:fff:reason.properties.properties.properties.f 280 개인 내신 IPv4/IPv6 변환[29]
100::/64 100:: 100::ffffff:ffff:ffffff:ffffff:ffffff 264 라우팅 접두사[30] 삭제
2001:0000::/32 2001:: 2001::fffff:ffff:ffffff:ffffff:ffff:ffff:ffffff:ffffff 296 글로벌 인터넷 테레도 터널링[31]
2001:20::/28 2001:20:: 2001:2f:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:fffff 2100 소프트웨어 난초v2[32]
2001:db8:::/32 2001:db8:: 2001:db8:ffff:fffff:ffffff:fffff:ffffff:ffffff:ffffff 296 문서화 문서화 및 소스[33] 코드 예제에 사용되는 주소
2002::/16 2002:: 2002:fffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffffff 2112 글로벌 인터넷 6to4 주소 지정 체계(사용되지 않음)[34]
fc00:/7 fc00: fdff:ffffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffffff 2121 개인 내신 고유 로컬 주소[35]
fe80::/10 fe80:: 2월f::ffff:ffffff:ffffff:ffffff 264 링크 링크 로컬 주소
ff00:/8 ff00:: fff:ffffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffffff 2120 글로벌 인터넷 멀티캐스트 주소

유니캐스트 주소

기본 경로

  • :::/0 — 라우팅 테이블의 다른 곳에 지정되지 않은 목적지 주소(단일화, 멀티캐스트 및 기타)에 대한 기본 경로 주소(IPv4의 0.0.0.0/0에 대응함)

지정되지 않은 주소

  • ::://128 — 모든 0비트가 포함된 주소를 지정되지 않은 주소(IPv4의 0.0.0.0/32에 대응함)라고 한다.
    이 주소는 인터페이스에 할당되어서는 안 되며 애플리케이션이 보류 중인 연결에 적합한 호스트의 소스 주소를 학습하기 전에 소프트웨어에서만 사용되어야 한다.라우터는 지정되지 않은 주소로 패킷을 포워드해서는 안 된다.
    애플리케이션은 특정 IP 주소(및 콜론으로 구분된 포트 번호)에 의해 활성 인터넷 연결 목록에 표시되는 하나 이상의 수신 연결을 위한 특정 인터페이스에서 수신 중일 수 있다.지정되지 않은 주소가 표시되면 응용 프로그램이 사용 가능한 모든 인터페이스에서 들어오는 연결을 수신하고 있음을 의미한다.

로컬 주소

  • ::1/128 — 루프백 주소는 유니캐스트 localhost address (IPv4의 127.0.0.1/8에 대응)이다.
    호스트의 애플리케이션이 이 주소로 패킷을 전송하는 경우 IPv6 스택은 이러한 패킷을 동일한 가상 인터페이스에서 다시 루프한다.
  • fe80::/10 — 링크 로컬 접두사의 주소는 단일 링크에서만 유효하고 고유하다(IPv4의 자동 구성 주소 169.254.0/16과 비교).
    이 접두사 내에는 하나의 서브넷만 할당되며(54 0비트) fe80::/64의 유효 형식을 제공한다.최소 64비트는 대개 수정된 EUI-64 형식으로 구성된 인터페이스 하드웨어 주소로 선택된다.링크 로컬 주소는 모든 IPv6 사용 인터페이스에 필요하다. 즉, 애플리케이션은 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비트 숫자를 선택하는 방법은 서로 병합하거나 통신하려는 두 사이트가 동일한 40비트 번호를 사용하므로 동일한 /48 접두사를 사용할 가능성이 매우 작다.[35]

IPv4에서 전환

  • ::fff:0:0/96 — 이 접두사는 IPv6 전환 메커니즘에 사용되며 IPv4 매핑 IPv6 주소로 지정된다.
    몇 가지 예외를 제외하고, 이 주소 유형은 IPv6 네트워킹 애플리케이션 프로그래밍 인터페이스를 통해 IPv4를 통한 전송 계층 프로토콜의 투명한 사용을 허용한다.서버 애플리케이션은 IPv6 또는 IPv4 프로토콜을 사용하는 클라이언트로부터의 연결을 처리하기 위해 단일 수신 소켓만 열면 된다.IPv6 클라이언트는 기본적으로 기본적으로 처리되며 IPv4 클라이언트는 IPv4 매핑된 IPv6 주소에 IPv6 클라이언트로 나타난다.전송은 비슷하게 처리된다. 설정된 소켓은 IPv6 주소 또는 IPv4 매핑된 주소에 대한 바인딩에 기초하여 IPv4 또는 IPv6 데이터그램을 전송하는 데 사용될 수 있다.
참고 항목:이중 스택
  • ::fff:0:0:0:0/96 — IPv4 변환 주소에 사용되는 접두사.
    이들은 상태 비저장 IP/ICMP Translation(SIIT) 프로토콜에서 사용된다.[36]
  • 64:ff9b::/96 — "잘 알려진" 접두사.
    이 접두사가 있는 주소는 자동 IPv4/IPv6 변환에 사용된다.[28]
주요 기사: NAT64
  • 64:ff9b:1::/48 — 로컬로 변환된 IPv4/IPv6 주소의 접두사.
    이 접두사가 있는 주소는 NAT64 및 SIIT와 같은 여러 IPv4/IPv6 변환 메커니즘에 사용할 수 있다.[29]
참고 항목: IPv6 전환 메커니즘
  • 2002::/16 — 이 접두사는 6to4 주소 지정에 사용됨(IPv4 네트워크 192.88.99.0/24의 주소도 사용됨)
    6to4 어드레싱 체계는 더 이상 사용되지 않는다.[34]
주요기사 : 6to4

특수 목적 주소

IANA는 2001:::/23(네트워크 접두사 2001:0000:/29~2001:01f8:/29)의 특별 할당을[27][37] 위해 이른바 'Sub-TLA ID' 주소 블록을 예약했다.이 블록의 세 가지 할당이 현재 할당됨:
  • 2001::/32 — Teredo 터널링에 사용.
    참고 항목: IPv6 전환 메커니즘
  • 2001:2::/48 — IPv6 벤치마킹에 사용됨(198.18.0.0/15에 대응하여 IPv4를 벤치마킹함)
    벤치마킹 방법론 작업 그룹(BMWG)에 할당됨.[38]
  • 2001:20::/28 — OFDv2(오버레이 라우팅 가능한 암호화 해시 식별자)[32]
    이들은 암호화 해시 식별자에 사용되는 라우팅되지 않은 IPv6 주소들이다.

문서화

  • 2001:db8:::/32 — 이 접두사는 설명서에[33] 사용된다(192.0.2.0/24, 198.51.100.0/24 및 IPv4의 203.0.113.0/24에 대응).[39]
    주소는 IPv6 주소의 예제가 주어지거나 모델 네트워킹 시나리오가 설명되는 모든 곳에서 사용해야 한다.

폐기하다

  • 100::/64 — 이 접두사는 트래픽을 삭제하는 데 사용된다.[30]

사용되지 않거나 사용되지 않는 주소

추가 정보: § 기록 참고 사항

멀티캐스트 주소

멀티캐스트 어드레스 ff0x: 여기서 x는 16진수 값이 예약되어 있으므로[1] 어떤 멀티캐스트 그룹에도 할당되어서는 안 된다.IANA(Internet Assigned Numbers Authority)는 주소 예약을 관리한다.[40]

일부 공통 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:d 모든 PIM 라우터 2(링크-로컬)
ff02:1a 모든 RPL 라우터 2(링크-로컬)
ff0X::fb mDNSv6 모든 범위에서 사용 가능
ff0X::101 모든 NTP 서버 모든 범위에서 사용 가능
ff02:1:1 링크명 2(링크-로컬)
ff02:1:2 All-dhCP-agents(DHCPv6) 2(링크-로컬)
ff02:1:3 링크 로컬 멀티캐스트 이름 확인 2(링크-로컬)
ff05:1:3 All-dhCP-servers(DHCPv6) 5(사이트-로컬)
ff02:1:ff00:0/message 요청된 노드 멀티캐스트 주소.아래 내용 참조. 2(링크-로컬)
ff02:2:ff00:0/message 노드 정보 쿼리 2(링크-로컬)

요청된 노드 멀티캐스트 주소

요청된 노드 멀티캐스트 어드레스 그룹 ID의 최소 24비트는 인터페이스의 유니캐스트 또는 어떤 캐스트 어드레스의 최소 24비트로 채워진다.이러한 주소는 로컬 네트워크의 모든 노드를 방해하지 않고 링크의 NDP(Neighborhood Discovery Protocol)를 통해 링크 계층 주소 확인을 허용한다.호스트는 각각의 구성된 유니캐스트 또는 모든 캐스트 주소에 대해 요청된 노드 멀티캐스트 그룹에 가입해야 한다.

상태 비저장 주소 자동 구성

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

IPv4에서 대표적인 "구성 프로토콜"은 DHCP 또는 PPP를 포함한다.DHCPv6이 존재하지만 IPv6 호스트는 일반적으로 Neighbor Discovery Protocol을 사용하여 글로벌 라우팅 가능한 유니캐스트 주소를 생성하는데, 즉 호스트가 라우터 요청 요청을 보내고 IPv6 라우터는 접두사 할당으로 응답한다.[42]

이들 주소의 하위 64비트는 수정된 EUI-64 형식의 64비트 인터페이스 식별자로 채워진다.이 식별자는 일반적으로 그 인터페이스의 자동 구성된 모든 주소에 의해 공유되는데, 이것은 이웃 발견을 위해 오직 하나의 멀티캐스트 그룹만 가입하면 된다는 장점을 가지고 있다.이를 위해, 멀티캐스트 어드레스는 네트워크 접두사 ff02::1:ff00:0/104와 주소의 24개 최소 중요 비트로부터 형성되어 사용된다.

수정된 EUI-64

64비트 인터페이스 식별자는 가장 일반적으로 48비트 MAC 주소에서 파생된다.MAC 주소 00-0C-29-0C-47-D5는 중간에 FF-FE: 00-0C-29-FF-FE-0C-47-D5를 삽입하여 64비트 EUI-64로 변환된다.이 EUI-64를 IPv6 주소를 형성하는 데 사용할 때 수정한다: 유니버설/로컬 비트(EUI-64의 7번째 가장 중요한 비트, 1부터 시작)의 의미가 반전되어 1은 이제 유니버설(Universal)을 의미한다.[1]네트워크 접두사 2001:db8:1:2::/64로 IPv6 주소를 생성하려면 2001:db8:1:2:020c:29ff:fe0c:47d5(Universal/Local 비트 사용, MAC 주소가 보편적으로 고유하기 때문에 이 경우 밑줄이 그어진 4중주단의 두 번째 리스트 유의 비트)를 1로 반전시킨다.

중복 주소 탐지

유니캐스트 IPv6 주소를 인터페이스에 할당하는 작업은 인접 네트워크 요청 및 인접 네트워크 광고(ICMPv6 유형 135 및 136) 메시지를 사용하여 해당 주소의 고유성에 대한 내부 테스트를 포함한다.고유성을 확립하는 과정에서 연설은 잠정적인 상태를 갖는다.

노드는 임시 주소에 대해 요청된 노드 멀티캐스트 주소에 조인하고(아직 그렇게 하지 않은 경우), 임시 주소를 대상 주소로, 지정되지 않은 주소(:/128)를 소스 주소로 하여 이웃 요청을 보낸다.노드는 또한 All-hosts 멀티캐스트 어드레스 ff02::1에 가입하므로 Neighborhood Adverties를 수신할 수 있을 것이다.

노드가 자신의 임시 주소를 대상 주소로 하여 인접 요청을 받는 경우, 해당 주소가 고유하지 않다.노드가 임시주소를 광고의 출처로 하여 이웃 광고를 받는 경우에도 마찬가지다.주소가 고유하다는 것을 성공적으로 설정한 후에만 인터페이스에 의해 할당되고 사용될 수 있다.

주소 수명

인터페이스에 바인딩된 각 IPv6 주소의 수명은 고정되어 있다.더 짧은 기간으로 구성되지 않는 한 수명은 무한하다.주소의 상태를 지배하는 두 가지 수명, 즉 선호되는 수명 및 유효 수명이다.[43]수명은 자동 구성에 사용되는 값을 제공하는 라우터에서 구성하거나 인터페이스에서 주소를 수동으로 구성할 때 지정할 수 있다.

주소가 인터페이스에 할당되면 우선 수명 동안 보유하는 "우선" 상태가 된다.해당 수명이 만료된 후에는 상태가 "비사용" 상태가 되며, 이 주소를 사용하여 새 연결을 만들 수 없다.주소는 유효 수명이 만료된 후 "유효하지 않음"이 된다. 주소는 인터페이스에서 제거되고 인터넷의 다른 곳에 할당될 수 있다.

참고: 대부분의 경우, 새로운 라우터 알림(RA)이 타이머를 새로 고치기 때문에 수명이 만료되지 않는다.그러나 더 이상 RA가 없다면, 결국 선호하는 수명은 늘어남에 따라 주소가 "비사용"이 된다.

임시 주소

인터페이스 식별자를 생성하기 위해 상태 비저장 주소 자동 구성에 의해 사용되는 전지구적으로 고유한 정적 MAC 주소는 시간 경과 및 IPv6 네트워크 접두사 변경 등 사용자 장비를 추적할 수 있는 기회를 제공한다.[44]사용자 ID가 IPv6 주소 부분에 영구적으로 연결될 가능성을 줄이기 위해, 노드는 시간 분산 무작위 비트[45] 문자열과 비교적 짧은 수명(시간에서 일)에 기반한 인터페이스 식별자를 가진 임시 주소를 생성할 수 있으며, 그 후 새로운 주소로 대체될 수 있다.

임시 주소는 원본 연결을 위한 소스 주소로 사용할 수 있으며, 외부 호스트는 도메인 이름 시스템을 쿼리하여 공용 주소를 사용한다.

IPv6용으로 구성된 네트워크 인터페이스는 OS X Lion 및 이후 Apple 시스템뿐 아니라 Windows Vista, Windows 2008 Server 및 이후 Microsoft 시스템에서도 기본적으로 임시 주소를 사용한다.

암호화된 방식으로 생성된 주소

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

그러한 어드레스는 여러 입력을 사용하는 두 개의 해시함수를 사용하여 생성된다.첫 번째는 공개키와 무작위 수식어를 사용한다. 후자는 결과 해시의 특정 0비트를 획득할 때까지 반복적으로 증가된다. (비트코인 채굴의 '작업증명' 분야와 비교된다.)두 번째 해시함수는 네트워크 접두사와 이전 해시 값을 취한다.두 번째 해시 결과 중 가장 중요도가 낮은 64비트를 64비트 네트워크 접두사에 추가하여 128비트 주소를 형성한다.

해시함수는 또한 특정 IPv6 주소가 유효한 CGA가 되는 요건을 충족하는지 검증하는 데 사용될 수 있다.이런 식으로, 신뢰할 수 있는 주소들 사이의 통신은 독점적으로 설정될 수 있다.

안정적인 개인 정보 주소

기본 하드웨어 주소(대부분 MAC 주소)가 로컬 네트워크를 넘어 노출되어 사용자 활동의 추적과 사용자 계정의 상관관계를 다른 정보에 대한 추적을 허용하기 때문에 상태 비저장 자동 구성 주소를 사용하는 것은 보안 및 개인 정보 보호 문제에 심각한 영향을 미친다.[47]벤더별 공격 전략도 허용하고, 공격 대상 검색을 위한 주소 공간도 축소한다.

이러한 단점을 보완하기 위해 안정적인 개인정보 보호주소가 도입되었다.그들은 특정 네트워크 내에서 안정적이지만 다른 네트워크로 이동할 때 프라이버시를 개선하기 위해 변화한다.그것들은 네트워크의 전체 주소 공간에서 결정적으로, 그러나 무작위로 선택된다.

안정된 프라이버시 주소의 생성은 여러 개의 안정된 파라미터를 사용하는 해시함수에 기초한다.구체적인 구현이지만 최소한 네트워크 접두사, 네트워크 인터페이스 이름, 중복 주소 카운터, 비밀키를 사용하는 것이 좋다.결과 해시 값은 최종 주소를 구성하는 데 사용된다.일반적으로 최소 64비트는 128비트 주소를 제공하기 위해 64비트 네트워크 접두사에 연결된다.네트워크 접두사가 64비트보다 작으면 더 많은 해시 비트가 사용된다.결과 주소가 기존 주소 또는 예약된 주소와 충돌하지 않는 경우 인터페이스에 할당된다.

기본 주소 선택

IPv6 지원 네트워크 인터페이스는 일반적으로 둘 이상의 IPv6 주소를 가지고 있다(예: 링크 로컬 주소와 글로벌 주소).그들은 또한 특정 수명이 만료된 후에 변경되는 임시 주소를 가질 수 있다.IPv6은 주소 범위와 선택 선호도의 개념을 도입하여 다른 호스트와의 통신에서 소스와 목적지 주소 선택을 위한 다중 선택을 제공한다.

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

접두사 우선 순위 라벨 사용법
::1/128 50 0 로컬호스트
::/0 40 1 기본 유니캐스트
::fff:0: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 사이트-로컬 주소(사용되지 않음)
3fe::/16 1 12 6골(골)

기본 구성은 IPv6 사용에 우선 순위를 두고 가능한 최소 범위 내에서 목적지 주소를 선택하여 링크-로컬 통신이 동일하게 적합할 경우 글로벌 라우팅 경로보다 우선하도록 한다.접두사 정책 테이블은 라우팅 테이블과 유사하며, 우선 순위 값이 링크 비용의 역할을 하며, 높은 선호도가 더 큰 값으로 표현된다.소스 주소는 대상 주소와 동일한 라벨 값을 가지는 것이 바람직하다.주소가 가장 긴 일치하는 가장 중요한 비트 순서에 기반하여 접두사와 일치한다.후보 소스 주소는 운영 체제에서 얻으며 후보 대상 주소는 DNS(Domain Name System)를 통해 쿼리할 수 있다.

다수의 주소가 통신에 이용 가능한 경우 접속을 설정하는 시간을 최소화하기 위해 해피 아이즈 알고리즘을 고안했다.대상 호스트의 IPv6 및 IPv4 주소를 도메인 이름 시스템에 쿼리하고, 기본 주소 선택 테이블을 사용하여 후보 주소를 정렬하고, 병렬로 연결을 시도한다.처음 연결된 연결은 현재와 미래의 다른 주소에 대한 연결을 중단한다.

도메인 네임 시스템

도메인 이름 시스템에서 호스트 이름은 AAAA 리소스 레코드, 소위 쿼드A 레코드라고 불리는 IPv6 주소에 매핑된다.[49]역방향 조회를 위해 IETF는 도메인 ip6.arpa을 예약했는데, 여기서 이름 공간은 IPv6 주소의 니블 단위(4비트)의 1자리 16진수 표현으로 계층적으로 구분된다.

IPv4에서와 같이 각 호스트는 주소 레코드와 역방향 매핑 포인터 레코드라는 두 개의 DNS 레코드로 DNS에 표시된다.예를 들어 존 example.com의 데릭이라는 호스트 컴퓨터에는 고유 로컬 주소 fddda:5cc1:23:4:1f가 있다.4분의 1 주소 기록은

derrick.example.com.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.PTR에서 derrick.example.com.

이 포인터 기록은 구역 d.f.ip6.arpa의 권한 위임 체인에 따라 여러 구역에서 정의될 수 있다.

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

AAAA 레코드 필드
이름 도메인 이름
유형 AAAA(28)
클래스 인터넷(1)
TTL 생존 시간(초)
RDLEND RDATA 필드의 길이
RDATA 128비트 IPv6 주소, 네트워크 바이트 순서

역사 노트

사용되지 않거나 사용되지 않는 주소

  • 사이트-로컬 접두사 fec0::/10은 주소가 조직의 사이트 네트워크 내에서만 유효함을 명시한다.1995년 12월 원래의 어드레스 아키텍처의[50] 일부였지만, 2004년[51] 9월 사이트 용어 정의가 모호하여 라우팅 규칙을 혼동하게 되었기 때문에 사용이 더 이상 사용되지 않았다.새로운 네트워크는 이 특별한 유형의 주소를 지원하지 않아야 한다.2005년 10월에 새로운 규격은[35] 이 주소 유형을 고유한 로컬 주소로 대체했다.
  • 주소 블록 200::/7은 1996년 8월에 OSI NSAP 매핑 접두사로 정의되었으나 2004년 12월에 더 이상 사용되지 않았다.[52][53][54]
  • 원래 IPv4 호환 주소로 알려진 96비트 제로 값 접두사 ::/96은 1995년에[50] 언급되었지만 1998년에 처음 설명되었다.[55][failed verification]이 주소의 범위는 IPv6 전환 기술 내에서 IPv4 주소를 나타내기 위해 사용되었다.그러한 IPv6 주소는 첫 번째(가장 중요한) 96비트가 0으로 설정되어 있는 반면 마지막 32비트는 표시된 IPv4 주소다.2006년 2월, IETF(Internet Engineering Task Force)는 IPv4 호환 주소의 사용을 금지했다.[1]이 주소 형식의 유일한 남은 용도는 IPv6 주소도 저장할 수 있어야 하는 고정 크기 멤버가 있는 테이블이나 데이터베이스에 IPv4 주소를 표시하는 것이다.
  • 주소 블록 3ffe::/16은 1998년 12월에 6bone 네트워크에 대한 테스트 목적으로 할당되었다.[55]그 이전에는 5f00::/8 주소 블록이 이 목적으로 사용되었다.두 주소 블록 모두 2006년 6월에 주소 풀로 반환되었다.[56]
  • 6to4의 운영상의 문제로 인해, 6to4 메커니즘이 2015년 5월 이후로 더 이상 사용되지 않기 때문에, 2002:/16 어드레스 블록의 사용이 줄어들고 있다.[34]IPv4 주소 블록 192.88.99.0/24는 더 이상 사용되지 않지만, 2002::/16은 그렇지 않다.
  • 2007년 4월에 주소 블록 2001:10:::/28이 ORchid(Overlay Routloadable Cryptical Hash Identifier)에 할당되었다.[57]그것은 실험용으로 의도되었다.2014년 9월, 두 번째 버전의 OFT가 지정되었고,[32] 블록 2001:20::/28의 도입으로 원본 블록은 IANA로 반환되었다.

잡다한

  • 역 DNS 조회의 경우, 최상위 도메인 arpa가 폐기될 것으로 예상되었기 때문에 원래 IPv6 주소는 DNS 존 ip6.int에 등록되었다.2000년, 인터넷 아키텍처 위원회(IAB)는 이러한 의도를 되돌렸고, 2001년 아르파가 원래의 기능을 유지해야 한다고 결정했다.ip6.int의 도메인들은 ip6.arpa[58]으로 옮겨졌고 ip6.int 구역은 2006년 6월 6일에 공식적으로 제거되었다.
  • 2011년 3월, IETF는 최종 사이트에 주소 블록을 할당하기 위한 권고안을 조정했다.[21]인터넷 서비스 제공자들은 (IAB와 IESG의 2001년 견해에 따르면) /48, /64 또는 /128 중 하나를 할당하는 대신에 최종 사용자에게 더 작은 블록(예: /56)을 할당하는 것을 고려해야 한다.[59]ARIN, RIP & APNIC 지역 등록국의 정책은 적절한 경우 /56 할당을 장려한다.[21]
  • 원래, 도메인 이름을 IPv6 주소로 변환하기 위한 두 가지 제안이 존재했는데,[60] 하나는 AAAA 레코드를 사용하고 다른 하나는 A6 레코드를 사용한다.[61]AAAA 레코드는 지배적인 방법으로, 호스트 이름에서 IPv6 주소로 간단한 매핑을 제공하는 IPv4용 A 레코드와 비교 가능하다.A6 레코드를 사용하는 방법은 A6 레코드의 추가 A6 레코드에 의해 주소 비트의 후속 그룹 매핑이 지정되어 단일 A6 레코드를 변경함으로써 네트워크의 모든 호스트의 번호를 재지정할 수 있는 가능성을 제공하는 계층 구조를 사용했다.A6 형식의 인식된 편익이 인식된 비용을 초과하지 않는다고 간주됨에 따라, 이 방법은 2002년에 실험적인 상태로,[63] 그리고 마지막으로 2012년에 역사적 상태로 이동되었다.[62][63][64][65][65]
  • 2009년, 홈 네트워크 NAT 기기와 라우터의 많은 DNS 확인자가 AAAA 기록을 부적절하게 처리하는 것을 발견했다.[66]이 중 일부는 적절한 음의 DNS 응답을 적절히 반환하는 대신 해당 레코드에 대한 DNS 요청을 간단히 삭제했다.요청이 삭제되기 때문에 요청을 보내는 호스트는 시간 초과가 트리거될 때까지 기다려야 한다.클라이언트 소프트웨어는 IPv4를 시도하기 전에 IPv6 연결이 실패하기를 기다리기 때문에 이중 스택 IPv6/IPv4 호스트에 연결할 때 속도가 느려지는 경우가 많다.
    참고 항목:해피 아이즈

메모들

  1. ^ 16비트 또는 2옥텟 수량을 헥스텟이라고도 한다.[6][7]

참조

  1. ^ a b c d e f g h i R. Hinden; S. Deering (February 2006). IP Version 6 Addressing Architecture. Network Working Group. doi:10.17487/RFC4291. RFC 4291. 업데이트 대상: RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064
  2. ^ Silvia Hagen (May 2006). IPv6 Essentials (Second ed.). O'Reilly. ISBN 978-0-596-10058-2.
  3. ^ a b P. Savola; B. Haberman (November 2004). Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. Network Working Group. doi:10.17487/RFC3956. RFC 3956.
  4. ^ a b B. Haberman; D. Thaler (August 2002). Unicast-Prefix-based IPv6 Multicast Addresses. Network Working Group. doi:10.17487/RFC3306. RFC 3306.
  5. ^ J-S. Park; M-K. Shin; H-J. Kim (April 2006). A Method for Generating Link-Scoped IPv6 Multicast Addresses. Network Working Group. doi:10.17487/RFC4489. RFC 4489.
  6. ^ Graziani, Rick (2012). IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6. Cisco Press. p. 55. ISBN 978-0-13-303347-2.
  7. ^ Coffeen, Tom (2014). IPv6 Address Planning: Designing an Address Plan for the Future. O'Reilly Media. p. 170. ISBN 978-1-4919-0326-1.
  8. ^ S. Kawamura; M. Kawashima (August 2010). A Recommendation for IPv6 Address Text Representation. IETF. doi:10.17487/RFC5952. ISSN 2070-1721. RFC 5952.
  9. ^ T. Berners-Lee; R. Fielding; L. Masinter (January 2005). Uniform Resource Identifier (URI): Generic Syntax. Network Working Group. doi:10.17487/RFC3986. STD 66. RFC 3986.
  10. ^ a b S.Deering; B. Haberman; T. Jinmei; E. Nordmark; B. Zill (March 2005). IPv6 Scoped Address Architecture. Network Working Group. doi:10.17487/RFC4007. RFC 4007.
  11. ^ B. Carpenter; S. Cheshire; R. Hinden (February 2013). Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. IETF. doi:10.17487/RFC6874. RFC 6874. RFC 3986 업데이트.
  12. ^ "ipv6-literal.net Domain History". who.is. Retrieved 20 October 2014.
  13. ^ "Scope zones". IBM Knowledge Centre. 27 September 2013. Retrieved 13 December 2019. Packets that contain a source or destination address of a given scope can be routed only within the same scope zone, and cannot be routed between different scope zone instances.
  14. ^ R Droms (August 2014). IPv6 Multicast Address Scopes. IETF. doi:10.17487/RFC7346. ISSN 2070-1721. RFC 7346.
  15. ^ IPv6 Address Allocation Management. Network Working Group, IETF. December 1995. doi:10.17487/RFC1881. RFC 1881.
  16. ^ IANA의 IPv6 주소 공간.Iana.org (2010-10-29)2011-09-28일에 검색됨.
  17. ^ IPv6 유니캐스트 주소 할당, IANA
  18. ^ DE-TELKOM-20050113 db.ripe.net.2011-09-28 검색됨
  19. ^ "ARIN Number Resource Policy Manual: Initial allocation to ISPs".
  20. ^ "RIPE NCC IPv6 Address Allocation and Assignment Policy: Minimum allocation".
  21. ^ a b c T. Narten; G. Houston; L. Roberts (March 2011). IPv6 Address Assignment to End Sites. IETF. doi:10.17487/RFC6177. BCP 157. RFC 6177.
  22. ^ 예를 들면Iana.org.2011-09-28일에 검색됨.
  23. ^ "IPv6 Addressing Plans". ARIN IPv6 Wiki. Retrieved 2018-07-15. All customers get one /48 unless they can show that they need more than 65k subnets. [...] If you have lots of consumer customers you may want to assign /56s to private residence sites.
  24. ^ "What are Bogons?". Retrieved 2021-11-15.
  25. ^ "Address Space Managed by the RIPE NCC". Retrieved 2011-05-22.
  26. ^ D. Johnson; S. Deering (March 1999). Reserved IPv6 Subnet Anycast Addresses. Network Working Group. doi:10.17487/RFC2526. RFC 2526.
  27. ^ a b M. Cotton; L. Vegoda; R. Bonica; B. Haberman (April 2013). Special-Purpose IP Address Registries. Internet Engineering Task Force. doi:10.17487/RFC6890. BCP 153. RFC 6890. RFC 8190에 의해 업데이트됨.
  28. ^ a b C. Bao; C. Huitema; M. Bagnulo; M. Boucadair; X. Li (October 2010). IPv6 Addressing of IPv4/IPv6 Translators. Internet Engineering Task Force. doi:10.17487/RFC6052. RFC 6052.
  29. ^ a b T. Anderson (August 2017). Local-Use IPv4/IPv6 Translation Prefix. Internet Engineering Task Force. doi:10.17487/RFC8215. RFC 8215.
  30. ^ a b N. Hilliard; D. Freedman (August 2012). A Discard Prefix for IPv6. Internet Engineering Task Force. doi:10.17487/RFC6666. RFC 6666.
  31. ^ RFC 4680
  32. ^ a b c J. Laganier; F. Dupont (September 2014). An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2). Internet Engineering Task Force. doi:10.17487/RFC7343. RFC 7343.
  33. ^ a b G. Huston; A. Lord; P. Smith (July 2004). IPv6 Address Prefix Reserved for Documentation. Network Working Group. doi:10.17487/RFC3849. RFC 3849.
  34. ^ a b c O. Troan (May 2015). B. Carpenter (ed.). Deprecating the Anycast Prefix for 6to4 Relay Routers. Internet Engineering Task Force. doi:10.17487/RFC7526. BCP 196. RFC 7526.
  35. ^ a b c d R. Hinden; B. Haberman (October 2005). Unique Local IPv6 Unicast Addresses. Network Working Group. doi:10.17487/RFC4193. RFC 4193.
  36. ^ C. Bao; X. Li; F. Baker; T. Anderson; F. Gont (June 2016). Stateless IP/ICMP Translation Algorithm. doi:10.17487/RFC7915. RFC 7915.
  37. ^ R. Hinden; S. Deering; R. Fink; T. Hain (September 2000). Initial IPv6 Sub-TLA ID Assignments. Network Working Group. doi:10.17487/RFC2928. RFC 2928.
  38. ^ C. Popoviciu; A. Hamza; G. Van de Velde; D. Dugatkin (May 2008). IPv6 Benchmarking Methodology for Network Interconnect Devices. Network Working Group. doi:10.17487/RFC5180. RFC 5180.
  39. ^ J. Arkko; M. Cotton; L. Vegoda (January 2010). IPv4 Address Blocks Reserved for Documentation. Internet Engineering Task Force. doi:10.17487/RFC5737. ISSN 2070-1721. RFC 5737.
  40. ^ IANA 인터넷 프로토콜 버전 6 멀티캐스트 주소
  41. ^ S. Thomson; T. Narten; T. Jinmei (September 2007). IPv6 Stateless Address Autoconfiguration. Network Working Group. doi:10.17487/RFC4862. RFC 4862.
  42. ^ T. Narten; E. Nordmark; W. Simpson; H. Holiman (September 2007). Neighbor Discovery for IP version 6 (IPv6). Network Working Group. doi:10.17487/RFC4861. RFC 4861.
  43. ^ Iljitsch van Beijnum (2006). "IPv6 Internals". The Internet Protocol Journal. Vol. 9, no. 3. pp. 16–29.
  44. ^ 상태 비저장 IPv6 주소 지정의 개인 정보 영향.Portal.acm.org (2010-04-21)2011-09-28일에 검색됨.
  45. ^ T. Narten; R. Draves; S. Krishnan (September 2007). Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Network Working Group. doi:10.17487/RFC4941. RFC 4941.
  46. ^ T. Aura (March 2005). Cryptographically Generated Addresses (CGA). Network Working Group IETF. doi:10.17487/RFC3972. RFC 3972.
  47. ^ F. Gont (April 2014). A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). IETF. doi:10.17487/RFC7217. ISSN 2070-1721. RFC 7217.
  48. ^ a b D. Thaler; R. Draves; A. Matsumoto; T. Chown (September 2012). D. Thaler (ed.). Default Address Selection for Internet Protocol Version 6 (IPv6). IETF. doi:10.17487/RFC6724. ISSN 2070-1721. RFC 6724.
  49. ^ S. Thomson; C. Huitema; V. Ksinant; M. Souissi (October 2003). DNS Extensions to Support IP Version 6. Network Working Group. doi:10.17487/RFC3596. RFC 3596.
  50. ^ a b R. Hinden; S. Deering (December 1995). IP Version 6 Addressing Architecture. Network Working Group. doi:10.17487/RFC1884. RFC 1884.
  51. ^ C. Huitema; B. Carpenter (September 2004). Deprecating Site Local Addresses. Network Working Group. doi:10.17487/RFC3879. RFC 3879.
  52. ^ G. Houston (Aug 2005). Proposed Changes to the Format of the IANA IPv6 Registry. Network Working Group. doi:10.17487/RFC4147. RFC 4147.
  53. ^ J. Bound; B. Carpenter; D. Harrington; J. Houldsworth; A. Lloyd (Aug 1996). OSI NSAPs and IPv6. Network Working Group. doi:10.17487/RFC1888. RFC 1888. RFC 4048에 의해 폐기됨.
  54. ^ B. Carpenter (Apr 2005). RFC 1888 Is Obsolete. doi:10.17487/RFC4048. RFC 4048.
  55. ^ a b R. Hinden; R. Fink; J. Postel (Dec 1998). IPv6 Testing Address Allocation. doi:10.17487/RFC2471. RFC 2471. RFC 3701에 의해 폐기됨.
  56. ^ R. Fink; R. Hinden (Mar 2004). 6bone (IPv6 Testing Address Allocation) Phaseout. Network Working Group. doi:10.17487/RFC3701. RFC 3701.
  57. ^ P. Nikander; J. Laganier; F. Dupont (April 2007). An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). Network Working Group. doi:10.17487/RFC4843. RFC 4843.
  58. ^ R. Bush (Aug 2001). Delegation of IP6.ARPA. doi:10.17487/RFC3152. RFC 3152. RFC 3596에 의해 폐기됨
  59. ^ IAB; IESG (September 2001). IAB/IESG Recommendations on IPv6 Address Allocations to Sites. doi:10.17487/RFC3177. RFC 3177.
  60. ^ S. Thomson; C. Huitema (December 1995). DNS Extensions to support IP version 6. Network Working Group. doi:10.17487/RFC1886. RFC 1886. RFC 3596에 의해 폐기됨.
  61. ^ M. Crawford; C. Huitema (July 2000). DNS Extensions to Support IPv6 Address Aggregation and Renumbering. doi:10.17487/RFC2874. RFC 2874.
  62. ^ AAAA와 A6의 비교 (A6가 정말 필요한가?) , 이토준 하기노 준이치로(2001년 7월)
  63. ^ a b R. Bush; A. Durand; B. Fink; O. Gudmundsson; T. Hain (August 2002). Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). Network Working Group. doi:10.17487/RFC3363. RFC 3363..
  64. ^ R. Austein (August 2002). Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). Network Working Group. doi:10.17487/RFC3364. RFC 3364.
  65. ^ a b S. Jiang; D. Conrad; B. Carpenter (March 2012). Moving A6 to Historic Status. IETF. doi:10.17487/RFC6536. RFC 6536.
  66. ^ Y. Morishita; T. Jinmei (May 2005). Common Misbehavior Against DNS Queries for IPv6 Addresses. doi:10.17487/RFC4074. RFC 4074.

외부 링크