Movatterモバイル変換


[0]ホーム

URL:


본문으로 이동
위키백과
검색

IPv6

위키백과, 우리 모두의 백과사전.
인터넷 프로토콜 버전 6
Internet Protocol version 6
프로토콜 스택
IPv6 헤더 도식
IPv6 헤더
목적인터네트워킹 프로토콜
개발국제 인터넷 표준화 기구 (IETF)
도입일1995년 12월(30년 전)(1995-12)
기반IPv4
OSI 계층네트워크 계층
RFC2460,8200
인터넷 프로토콜 스위트
응용 계층
전송 계층
인터넷 계층
링크 계층

인터넷 프로토콜 버전 6(Internet Protocol version 6,IPv6)는 네트워크상의 컴퓨터에 대한 식별 및 위치 시스템을 제공하고인터넷을 가로질러 트래픽을 라우팅하는통신 프로토콜인터넷 프로토콜(IP)의 최신 버전이다. IPv6는 오랫동안 예상되었던IPv4 주소 고갈 문제를 해결하기 위해국제 인터넷 표준화 기구(IETF)에 의해 개발되었으며,IPv4를 대체하기 위해 고안되었다.[1] 1998년 12월, IPv6는 IETF의 드래프트 표준(Draft Standard)이 되었으며,[2] 이후 2017년 7월 14일에인터넷 표준으로 승인되었다.[3][4]

인터넷상의 장치들은 식별 및 위치 정의를 위해 고유한IP 주소를 할당받는다. 1990년대 상업화 이후 인터넷이 급격히 성장하면서, IPv4가 제공하는 40억(232) 개의 주소보다 훨씬 더 많은 주소가 장치 연결에 필요할 것이라는 사실이 자명해졌다. 1998년까지 IETF는 후속 프로토콜인 IPv6를 공식화했다. 이는 128비트 주소를 사용하여 2128, 즉 1038개 또는 약 340간(undecillion) 개의 전체 주소 공간을 제공한다. IPv4와 IPv6가 상호 운용될 수 있도록 여러전환 매커니즘이 고안되었지만, IPv6는 IPv4와 하위 호환되지 않으며 두 프로토콜은 직접적으로 상호 운용되지 않는다.

IPv6는 더 큰 주소 공간 외에도 다른 기술적 이점을 제공한다. 특히 인터넷 전반에 걸쳐경로 집약을 용이하게 하는 계층적 주소 할당 방법을 허용하여라우팅 테이블의 확장을 제한한다. 멀티캐스트 주소 지정의 사용이 확장 및 단순화되어 서비스 전달을 위한 추가적인 최적화를 제공한다. 프로토콜 설계 시 장치 이동성, 보안 및 구성 측면이 고려되었다.

IPv6 주소는 콜론으로 구분된 4개의십육진법 숫자 그룹 8개로 표시된다. 전체 표기법은 특정 규칙에 따라 단축될 수 있다. 예를 들어,2001:0db8:0000:0000:0000:8a2e:0370:73342001:db8::8a2e:370:7334가 된다.

주요 특징

[편집]
IPv6 주소에 사용되는 용어 설명

IPv6는패킷 교환인터네트워킹을 위한인터넷 계층 프로토콜이며, 이전 버전 프로토콜인인터넷 프로토콜 버전 4(IPv4)에서 개발된 설계 원칙을 밀접하게 준수하면서 여러 IP 네트워크에 걸쳐 엔드 투 엔드데이터그램 전송을 제공한다.

IPv6는 더 많은 주소를 제공하는 것 외에도 IPv4에 없는 기능들을 구현한다. 네트워크 연결 제공자를 변경할 때 주소 구성, 네트워크 번호 재할당 및 라우터 광고 측면을 단순화한다. 패킷 단편화에 대한 책임을 엔드 포인트에 두어 라우터에서의 패킷 처리를 단순화한다. IPv6서브넷 크기는 주소의 호스트 식별자 부분의 크기를 64비트로 고정함으로써 표준화되었다.

IPv6의 주소 지정 구조는유니캐스트,애니캐스트,멀티캐스트의 세 가지 전송 유형을 허용한다.[5][6]:210 IPv6는브로드캐스트를 구현하지 않으므로브로드캐스트 주소라는 개념이 없다.

동기 및 기원

[편집]

IPv4 주소 고갈

[편집]
 이 부분의 본문은IPv4 주소 고갈입니다.
점-십진법IPv4 주소 표현의 이진 표기법 분해

인터넷 프로토콜 버전 4(IPv4)는 공개적으로 사용된 인터넷 프로토콜의 첫 번째 버전이었다. IPv4는인터넷월드 와이드 웹의 토대가 되기 전,미국 국방부산하방위고등연구계획국(DARPA)에 의해 연구 프로젝트로 개발되었다. IPv4는 32비트로 구성된 숫자 식별자를 사용하는 주소 체계를 포함한다. 이러한 주소는 일반적으로 0에서 255 사이의 범위를 갖는 4개의 옥텟(각 8비트)을 십진수 값으로 표시하는점-십진 표기법으로 표시된다. 따라서 IPv4는 232개, 즉 약 43억 개의 주소 지정 능력을 제공한다. 주소 고갈은 초기 IPv4에서 우려 사항이 아니었는데, 이 버전은 원래 DARPA의 네트워킹 개념을 테스트하기 위한 것으로 가정되었기 때문이다.[7] 인터넷 운영 첫 10년 동안 주소 공간을 보존하기 위한 방법을 개발해야 한다는 것이 분명해졌다. 1990년대 초,비계층적 네트워크 모델을 사용하여 주소 체계를 재설계한 후에도IPv4 주소 고갈을 방지하기에 충분하지 않으며 인터넷 인프라에 대한 추가적인 변화가 필요하다는 것이 명확해졌다.[8]

1,600만 개의 IPv4 주소로 구성된 마지막 미할당 최상위 주소 블록은 2011년 2월IANA(IANA)에 의해 5개의대륙별 인터넷 레지스트리(RIR)에 할당되었다.[9] 그러나 각 RIR에는 여전히 가용 주소 풀이 있었으며, 하나의/8CIDR 블록이 남을 때까지 표준 주소 할당 정책을 계속할 것으로 예상되었다. 그 후에는 RIR에서로컬 인터넷 레지스트리(LIR)로 1,024개의 주소(/22) 블록만 제공된다. 2025년 4월 기준,아태지역 네트워크 정보센터(APNIC),RIPE NCC,라틴아메리카 및 카리브해 네트워크 정보센터(LACNIC),AFRINIC(AFRINIC),미국 인터넷 번호 등록 협회(ARIN) 모두 이 단계에 도달했다.[10][11][12][13]

RIPE NCC는 2019년 11월 25일에 IPv4 주소가 완전히 소진되었다고 발표했으며,[14] IPv6 채택에 대한 더 큰 진전을 촉구했다.

IPv4와의 비교

[편집]

인터넷에서 데이터는네트워크 패킷의 형태로 전송된다. IPv6는 라우터에 의한 패킷 헤더 처리를 최소화하도록 설계된 새로운패킷 형식을 지정한다.[2][15] IPv4 패킷과 IPv6 패킷의 헤더가 크게 다르기 때문에 두 프로토콜은 상호 운용되지 않는다. 그러나 대부분의 전송 및 응용 계층 프로토콜은 IPv6에서 작동하기 위해 변경이 거의 또는 전혀 필요하지 않다. 단,파일 전송 프로토콜(FTP) 및네트워크 타임 프로토콜(NTP)과 같이 인터넷 계층 주소를 포함하는 응용 프로토콜은 예외이며, 여기서 새로운 주소 형식은 기존 프로토콜 구문과 충돌을 일으킬 수 있다.

더 큰 주소 공간

[편집]

IPv4에 비해 IPv6의 주요 장점은 더 큰 주소 공간이다. IPv6 주소의 크기는 128비트로, IPv4의 32비트와 비교된다.[2] 따라서 주소 공간은 2128개(340, 약3.4×1038개)의 주소를 가진다. 이 공간의 일부 블록과 일부 특정 주소는특별한 용도를 위해 예약되어 있다.

이 주소 공간은 매우 크지만, IPv6 설계자들의 의도는 지리적으로 사용 가능한 주소로 포화시키는 것이 아니었다. 오히려 긴 주소는 주소 할당을 단순화하고, 효율적인경로 집약을 가능하게 하며, 특수 주소 지정 기능을 구현할 수 있게 한다. IPv4에서는 좁은 주소 공간을 최대한 활용하기 위해 복잡한CIDR(CIDR) 방법이 개발되었다. IPv6에서 주소의 네트워크 식별자 부분은 보통 264개의 주소로, 전체 IPv4 주소 공간의 약 40억 배 크기이다. 따라서 IPv6에서 실제 주소 공간 활용률은 낮겠지만, 넓은 서브넷 공간과 계층적 경로 집약으로 네트워크 관리 및 라우팅 효율성이 향상된다.

멀티캐스팅

[편집]
IPv6의 멀티캐스트 구조

단일 전송 작업으로 패킷을 여러 목적지로 전송하는멀티캐스트는 IPv6의 기본 사양의 일부이다. IPv4에서 이는 선택적(흔히 구현되기는 하지만) 기능이다.[16] IPv6 멀티캐스트 주소 지정은 IPv4 멀티캐스트와 공통된 기능 및 프로토콜을 갖지만, 특정 프로토콜의 필요성을 제거함으로써 변화와 개선을 제공한다. IPv6는 전통적인IP 브로드캐스트, 즉 특수 브로드캐스트 주소를 사용하여 연결된 링크의 모든 호스트로 패킷을 전송하는 방식을 구현하지 않으며, 따라서 브로드캐스트 주소를 정의하지 않는다. IPv6에서 동일한 결과는 링크-로컬 모든 노드 멀티캐스트 그룹 주소인ff02::1로 패킷을 전송함으로써 달성되며, 이는 IPv4에서224.0.0.1 주소로 멀티캐스팅하는 것과 유사하다. IPv6는 또한 IPv6 멀티캐스트 그룹 주소에 랑데부 포인트 주소를 내장하는 것을 포함하여 새로운 멀티캐스트 구현을 제공하며, 이는 도메인 간 솔루션 배포를 단순화한다.[17]

IPv4에서는 조직이 전역적으로 라우팅 가능한 멀티캐스트 그룹 할당을 하나라도 받는 것이 매우 어렵고, 도메인 간 솔루션 구현이 복잡하다.[18]로컬 인터넷 레지스트리에 의한 IPv6용 유니캐스트 주소 할당은 최소 64비트 라우팅 접두사를 가지며, 이는 IPv6에서 사용 가능한 가장 작은 서브넷 크기(역시 64비트)를 산출한다. 이러한 할당을 통해 유니캐스트 주소 접두사를 IPv6 멀티캐스트 주소 형식에 내장할 수 있으며, 동시에 주소의 최하위 비트인 32비트 블록, 즉 약 42억 개의 멀티캐스트 그룹 식별자를 제공할 수 있다. 따라서 각 IPv6 서브넷 사용자는 멀티캐스트 응용 프로그램을 위해 전역적으로 라우팅 가능한 소스 특정 멀티캐스트 그룹 세트를 자동으로 사용할 수 있다.[19]

상태 비저장 주소 자동 설정 (SLAAC)

[편집]

IPv6 호스트는 자동으로 자신을 구성한다. 모든 인터페이스에는 자체 생성된 링크-로컬 주소가 있으며, 네트워크에 연결되면 충돌 해결이 수행되고 라우터는 라우터 광고를 통해 네트워크 접두사를 제공한다.[20] 라우터의 상태 비저장 구성은 특수 라우터 번호 재할당 프로토콜을 통해 달성할 수 있다.[21] 필요한 경우 호스트는DHCPv6(DHCPv6)를 통해 추가적인 상태 저장 주소를 구성하거나 정적 주소를 수동으로 구성할 수 있다.

IPv4와 마찬가지로 IPv6는 전역적으로 고유한IP 주소를 지원한다. IPv6의 설계는네트워크 주소 변환(NAT)을 불필요하게 만듦으로써 초기 인터넷 구축 당시 원래 구상되었던 네트워크 설계의엔드 투 엔드 원칙을 다시 강조하고자 했다. 따라서 네트워크상의 모든 장치는 다른 모든 장치로부터 직접 전역적으로 주소 지정이 가능하다.

안정적이고 고유하며 전역적으로 주소 지정 가능한 IP 주소는 네트워크 전반에서 장치를 추적하는 것을 용이하게 할 것이다. 따라서 이러한 주소는 노트북 및 휴대전화와 같은 모바일 장치에 대한 특정 개인정보 보호 우려 사항이다.[22] 이러한 개인정보 보호 문제를 해결하기 위해 SLAAC 프로토콜에는 일반적으로 "개인정보 보호 주소" 또는 더 정확하게는 "임시 주소"라고 불리는 기능이 포함되어 있다.[23] 임시 주소는 무작위이며 불안정하다. 일반적인 소비자 장치는 매일 새로운 임시 주소를 생성하고 일주일 후에는 이전 주소로 지정된 트래픽을 무시한다. 임시 주소는 윈도우 XP SP1 이후의 윈도우,[24] (Mac OS X) 10.7 이후의 macOS, 안드로이드 4.0 이후, iOS 버전 4.3 이후부터 기본적으로 사용된다. 리눅스 배포판의 임시 주소 사용 여부는 다양하다.[25]

서로 다른 라우팅 접두사를 가진 새로운 연결 제공자를 위해 기존 네트워크의 번호를 재할당하는 것은 IPv4에서 큰 노력이 필요한 작업이다.[26][27] 그러나 IPv6를 사용하면 몇몇 라우터에 의해 광고된 접두사를 변경하는 것만으로 원칙적으로 전체 네트워크의 번호를 재할당할 수 있는데, 이는 호스트 식별자(주소의 최하위 64비트)를 호스트가 독립적으로 자체 구성할 수 있기 때문이다.[20]

SLAAC 주소 생성 방법은 구현에 따라 다르다. IETF는 주소가 결정론적이지만 의미상 불투명(semantically opaque)할 것을 권장한다.[28]

IPsec

[편집]

IPsec(IPsec)은 원래 IPv6를 위해 개발되었으나, IPv4용으로 재설계되어 IPv4에서 먼저 광범위하게 배포되었다. IPsec은 모든 IPv6 프로토콜 구현의 의무 사항이었으며,[2]인터넷 키 교환(IKE)이 권장되었으나,RFC 6434와 함께 IPv6를 사용하는 모든 유형의 장치에 대해 완전한 IPsec 구현을 요구하는 것이 비현실적이라고 간주되어 IPv6 구현에서의 IPsec 포함은 권장 사항으로 등급이 낮아졌다.[29] 그러나RFC 4301을 기준으로 IPsec을 구현하는 IPv6 프로토콜 구현은 IKEv2를 구현해야 하며 최소한의암호 알고리즘 세트를 지원해야 한다. 이 요구 사항은 서로 다른 벤더의 장치 간에 IPsec 구현의 상호 운용성을 높이는 데 도움이 될 것이다. IPsec 인증 헤더(AH)와 보안 페이로드 캡슐화(ESP) 헤더는 IPv6 확장 헤더로 구현된다.[30]

라우터에 의한 단순화된 처리

[편집]

IPv6의 패킷 헤더는 IPv4 헤더보다 단순하다. 드물게 사용되는 많은 필드가 선택적 헤더 확장으로 옮겨졌다. IPv6 패킷 헤더는라우터에 의한 패킷 포워딩 프로세스를 단순화했다. IPv6 패킷 헤더는 IPv4 패킷 헤더보다 최소 두 배 크지만, 기본 IPv6 헤더만 포함하는 패킷의 처리는 경우에 따라 라우터에서 더 효율적일 수 있는데, 이는 헤더가 일반적인워드 크기에 맞춰 정렬되어 있어 라우터에서 필요한 처리가 적기 때문이다.[2][15] 그러나 많은 장치가 하드웨어가 아닌 소프트웨어에서 IPv6 지원을 구현하므로 패킷 처리 성능이 매우 나빠질 수 있다.[31] 또한 많은 구현에서 확장 헤더의 사용은 패킷이 라우터의 CPU에 의해 처리되도록 하여 성능 저하나 보안 문제를 초래한다.[32]

더욱이 IPv6 헤더에는 체크섬이 포함되지 않는다.IPv4 헤더 체크섬은 IPv4 헤더에 대해 계산되며,타임 투 리브(IPv6 프로토콜에서는홉 제한이라고 함)가 1씩 감소할 때마다 라우터에서 다시 계산해야 한다. IPv6 헤더에 체크섬이 없는 것은 네트워크의 대부분 처리가 리프 노드에서 발생한다는 인터넷 설계의엔드 투 엔드 원칙을 더욱 강화한다. IPv6 패킷에 캡슐화된 데이터에 대한 무결성 보호는링크 계층 또는 상위 계층 프로토콜, 즉전송 계층전송 제어 프로토콜(TCP) 및사용자 데이터그램 프로토콜(UDP)의 오류 검출에 의해 보장되는 것으로 상정된다. 따라서 IPv4는 UDP 데이터그램 헤더에 체크섬이 없는 것을 허용했지만(헤더 필드에 0으로 표시), IPv6는 UDP 헤더에 체크섬을 요구한다.

IPv6 라우터는IP 단편화를 수행하지 않는다. IPv6 호스트는경로 MTU 탐색을 수행하거나, 엔드 투 엔드 단편화를 수행하거나, 기본최대 전송 단위(MTU)인 1280옥텟보다 크지 않은 패킷을 보내야 한다.

이동성

[편집]

모바일 IPv4와 달리모바일 IPv6삼각 라우팅을 피하므로 네이티브 IPv6만큼 효율적이다. IPv6 라우터는 또한 전체 서브넷이 번호 재할당 없이 새로운 라우터 연결 지점으로 이동하는 것을 허용할 수 있다.[33]

확장 헤더

[편집]
IPv6 확장 헤더의 몇 가지 예시

IPv6 패킷 헤더는 최소 크기가 40옥텟(320비트)이다. 옵션은 확장으로 구현된다. 이는 핵심 패킷 구조에 영향을 주지 않으면서 미래에 프로토콜을 확장할 수 있는 기회를 제공한다.[2] 그러나RFC 7872는 일부 네트워크 운영자가 확장 헤더가 있는 IPv6 패킷이 전송자율 시스템(AS)을 통과할 때 이를 폐기한다고 지적한다.

점보그램

[편집]

IPv4는 패킷의 페이로드를 65,535(216 − 1)옥텟으로 제한한다. IPv6 노드는 선택적으로 이 제한을 넘는 패킷을 처리할 수 있으며, 이를점보그램이라고 하며, 크기는 최대 4,294,967,295(232 − 1)옥텟에 달할 수 있다. 점보그램의 사용은 높은MTU 링크에서 성능을 향상시킬 수 있다. 점보그램의 사용은 점보 페이로드 옵션 확장 헤더에 의해 표시된다.[34]

IPv6 패킷

[편집]
 이 부분의 본문은IPv6 패킷입니다.
IPv6 패킷 헤더

IPv6 패킷은헤더페이로드의 두 부분으로 구성된다.

헤더는 모든 패킷에 필요한 최소한의 기능을 가진 고정 부분으로 구성되며, 특수 기능을 구현하기 위한 선택적 확장이 뒤따를 수 있다.

고정 헤더는 IPv6 패킷의 처음 40옥텟(320비트)을 차지한다. 여기에는 소스 및 목적지 주소, 트래픽 클래스, 홉 카운트, 헤더 뒤에 오는 선택적 확장 또는 페이로드의 유형이 포함된다. 이 다음 헤더(Next Header) 필드는 수신자에게 헤더 뒤에 오는 데이터를 해석하는 방법을 알려준다. 패킷에 옵션이 포함된 경우 이 필드에는 다음 옵션의 옵션 유형이 포함된다. 마지막 옵션의 "다음 헤더" 필드는 패킷의페이로드에 실린 상위 계층 프로토콜을 가리킨다.

IPv6 트래픽 클래스 필드의 현재 사용은 6비트차등화 서비스 코드 포인트[35]와 2비트명시적 혼잡 알림 필드[36]로 나뉜다.

확장 헤더는 네트워크에서 패킷의 특수 처리를 위해 사용되는 옵션을 전달하며, 예를 들어 라우팅, 단편화 및IPsec 프레임워크를 사용한 보안 등을 위해 사용된다.

특별한 옵션이 없으면 페이로드는64kB 미만이어야 한다. 점보 페이로드 옵션(Hop-By-Hop 옵션 확장 헤더에 포함됨)을 사용하면 페이로드는 4GB 미만이어야 한다.

IPv4와 달리 라우터는 패킷을 단편화하지 않는다. 호스트는경로 MTU 탐색을 사용하여 단편화할 필요 없이 목적지에 도달할 수 있을 만큼 패킷을 작게 만들 것으로 예상된다.IPv6 패킷 단편화를 참조하라.

주소 지정

[편집]
 이 부분의 본문은IPv6 주소입니다.
IPv6 유니캐스트 주소의 일반적인 구조

IPv6 주소는 128비트를 가진다. IPv6 주소 공간의 설계는 좁은 주소 공간의 활용 효율성을 높이기 위해 서브네팅을 사용했던 IPv4와는 다른 설계 철학을 구현한다. IPv6에서 주소 공간은 예측 가능한 미래를 위해 충분히 크다고 간주되며, 로컬 영역 서브넷은 항상 주소의 호스트 부분에 대해 64비트를 사용하며 이를 인터페이스 식별자로 지정하고, 최상위 64비트는 라우팅 접두사로 사용된다.[5]:9 IPv6 서브넷을 스캔하는 것이 불가능하다는 신화가 존재해 왔지만,RFC 7707은 일부 IPv6 주소 구성 기술 및 알고리즘으로 인해 발생하는 패턴이 많은 실제 시나리오에서 주소 스캔을 허용한다고 지적한다.

주소 표현

[편집]

IPv6 주소의 128비트는 각각 16비트인 8개의 그룹으로 표현된다. 각 그룹은 4개의 십육진수 숫자로 작성되며(때로는헥스텟[37][38] 또는 더 공식적으로 hexadectet[39], 비공식적으로 quibble 또는 quad-nibble[39]이라고 함), 그룹은 콜론(:)으로 구분된다. 이 표현의 예는2001:0db8:0000:0000:0000:ff00:0042:8329이다.

편의성과 명확성을 위해 IPv6 주소 표현은 다음 규칙에 따라 단축될 수 있다.

  • 십육진수 숫자의 그룹에서 하나 이상의선행 제로를 제거하며, 보통 모든 선행 제로에 대해 수행된다. 예를 들어, 그룹004242로 변환된다. 그룹00000으로 변환된다.
  • 연속된 0의 섹션은 두 개의 콜론(::)으로 대체된다. 이는 주소에서 한 번만 사용할 수 있는데, 여러 번 사용하면 주소를 확정할 수 없게 되기 때문이다. 이중 콜론은 생략된 단일 0 섹션을 나타내는 데 사용해서는 안 된다.[40]:§4.2.2

이 규칙을 적용한 예:

초기 주소:2001:0db8:0000:0000:0000:ff00:0042:8329.
각 그룹에서 모든 선행 제로를 제거한 후:2001:db8:0:0:0:ff00:42:8329.
연속된 0 섹션을 생략한 후:2001:db8::ff00:42:8329.

루프백 주소는0000:0000:0000:0000:0000:0000:0000:0001[41]로 정의되며 두 규칙을 모두 사용하여::1로 약칭된다.

IPv6 주소는 하나 이상의 표현을 가질 수 있으므로, IETF는텍스트 표현을 위한 제안 표준을 발행했다.[40]

IPv6 주소에는 콜론이 포함되어 있고 URL은 콜론을 사용하여 호스트와 포트 번호를 구분하므로, URL의 호스트 부분으로 사용되는 IPv6 주소는 대괄호로 묶어야 한다.[42] 예:http://[2001:db8:4006:812::200e] 또는http://[2001:db8:4006:812::200e]:8080/path/page.html.

링크-로컬 주소

[편집]
IPv6의 링크-로컬 유니캐스트 주소 구조

IPv6 호스트의 모든 인터페이스는링크-로컬 주소가 필요하며, 이는fe80::/10 접두사를 가진다. 이 접두사 뒤에는 서브네팅에 사용할 수 있는 54비트가 오지만 보통 0으로 설정되며, 64비트 인터페이스 식별자가 뒤따른다. 호스트는 링크-로컬 주소 자동 설정이라는 프로세스를 통해 DHCP 서버와 같은 외부 네트워크 구성 요소의 존재나 협력 없이 스스로 인터페이스 식별자를 계산하고 할당할 수 있다.

링크-로컬 주소의 하위 64비트(접미사)는 원래 기본 네트워크 인터페이스 카드의 MAC 주소에서 파생되었다. 주소를 할당하는 이 방법은 결함이 있는 네트워크 카드를 교체할 때 원치 않는 주소 변경을 초래하고 여러 보안 및 개인정보 보호 문제를 겪었기 때문에,RFC 8064는 원래의 MAC 기반 방법을RFC 7217에 지정된 해시 기반 방법으로 대체했다.

주소 고유성 및 라우터 요청

[편집]

IPv6는 IPv4의주소 결정 프로토콜(ARP) 기능의 기반이 되는브로드캐스트 주소 지정 방식을 지원하지 않기 때문에, IP 주소를 링크 계층 주소(예:MAC 주소)에 매핑하기 위해 새로운 매커니즘을 사용한다. IPv6는링크 계층에서이웃 탐색 프로토콜(NDP, ND)을 구현하며, 이는ICMPv6멀티캐스트 전송에 의존한다.[6]:210 IPv6 호스트는 해당 IP 주소의 링크 계층 주소를 묻는 이웃 요청 메시지를 보냄으로써근거리 통신망(LAN)에서 자신의 IPv6 주소의 고유성을 확인한다. LAN의 다른 호스트가 해당 주소를 사용 중인 경우 응답을 보낸다.[43]

새로운 IPv6 인터페이스를 가동하는 호스트는 먼저 고유한 주소를 생성하도록 설계된 여러 매커니즘 중 하나를 사용하여 고유한 링크-로컬 주소를 생성한다. 고유하지 않은 주소가 감지되면 호스트는 새로 생성된 주소로 다시 시도할 수 있다. 고유한 링크-로컬 주소가 설정되면, IPv6 호스트는 이 링크의 LAN이 IPv6를 지원하는라우터 인터페이스에 연결되어 있는지 확인한다. 이는 자신의 링크-로컬 주소를 소스로 하여 모든 라우터[44] 멀티캐스트 그룹으로 ICMPv6 라우터 요청 메시지를 보냄으로써 수행된다. 미리 정해진 횟수의 시도 후에도 응답이 없으면 호스트는 연결된 라우터가 없다고 결론짓는다. 라우터로부터 라우터 광고라고 알려진 응답을 받으면, 해당 응답에는 적절한 유니캐스트 네트워크 접두사로 전역적으로 고유한 주소를 설정할 수 있도록 하는 네트워크 구성 정보가 포함된다.[45] 또한 호스트가 추가 정보 및 주소를 얻기 위해 DHCP를 사용해야 하는지 여부를 알려주는 두 개의 플래그 비트가 있다.

  • Manage 비트: 호스트가 라우터 광고의 자동 구성 주소에 의존하는 대신 추가 주소를 얻기 위해 DHCP를 사용해야 하는지 여부를 나타낸다.
  • Other 비트: 호스트가 DHCP를 통해 다른 정보를 얻어야 하는지 여부를 나타낸다. 다른 정보는 호스트가 연결된 서브넷에 대한 하나 이상의 접두사 정보 옵션, 접두사의 수명 및 두 개의 플래그로 구성된다.[43]
    • On-link: 이 플래그가 설정되면 호스트는 특정 서브넷의 모든 주소를 온-링크(on-link)로 간주하고 지정된 수명 동안 라우터로 보내는 대신 직접 패킷을 보낸다.
    • Address: 이 플래그는 호스트에게 실제로 전역 주소를 생성하라고 지시한다.

전역 주소 지정

[편집]
IPv6의 전역 유니캐스트 주소 구조

전역 주소의 할당 절차는 로컬 주소 구축과 유사하다. 접두사는 네트워크의 라우터 광고로부터 제공된다. 여러 접두사 광고는 여러 주소가 구성되게 한다.[43]

상태 비저장 주소 자동 설정(SLAAC)에는/64 주소 블록이 필요하다.[5]로컬 인터넷 레지스트리는 최소/32 블록을 할당받아 이를 하위 네트워크로 나눈다.[46]2001년 9월의 초기 권고안은 최종 소비자 사이트에/48 서브넷을 할당하도록 명시했다.[47]2011년 3월에 이 권고안은 다음과 같이 개선되었다.[48]IETF는 "가정용 사이트에 단일/64보다 훨씬 더 많은 것을 제공할 것을 권장하지만, 모든 가정용 사이트에/48을 제공할 것을 권장하지도 않는다"라고 밝혔다. 특히/56 블록이 고려된다. ISP가 이 권고를 준수할지는 지켜봐야 한다. 예를 들어 초기 시험 기간 동안컴캐스트 고객에게는 단일/64 네트워크가 제공되었다.[49]

도메인 네임 시스템에서의 IPv6

[편집]

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

듀얼 스택 호스트가전체 주소 도메인 네임(FQDN)을 해석하기 위해 DNS 서버에 쿼리할 때, 호스트의 DNS 클라이언트는 기본적으로 AAAA 레코드를 쿼리하는 요청과 A 레코드를 쿼리하는 요청 두 개를 순서대로 보낸다. DNS에 의해 두 유형의 주소가 모두 반환되고 경로가 있는 경우, IPv4 주소보다 IPv6 주소가 선호된다. 그러나 호스트 운영체제는 주소 선택에 대해 대체 선호도를 갖도록 구성될 수 있다.[51][52]

초기 IPv6용 DNS 구현에서는 네트워크 번호 재할당을 용이하게 하도록 설계된 대체 레코드 유형이 사용되었다. A6 리소스 레코드는 정방향 조회에 사용되었으며 비트 문자열 레이블 및DNAME 레코드와 같은 여러 다른 혁신과 함께 완성되었다.[53] 두 체계의 장단점에 대한 논의 후([54]) A6 리소스 레코드의 사용은 실험적 상태로 격하되었다.[55]

 해피 아이볼 문서를 참고하십시오.

전환 매커니즘

[편집]
 이 부분의 본문은IPv6 전환 매커니즘입니다.

IPv6가 즉각적으로 IPv4를 대체할 것으로 예상되지는 않는다. 두 프로토콜은 당분간 동시에 작동할 것이다. 따라서 IPv6 호스트가 IPv4 서비스에 도달하고 고립된 IPv6 호스트와 네트워크가 IPv4 인프라를 통해 서로 도달할 수 있도록IPv6 전환 매커니즘이 필요하다.[56]

실비아 하겐에 따르면, 장치에서 IPv4와 IPv6를 듀얼 스택으로 구현하는 것이 IPv6로 마이그레이션하는 가장 쉬운 방법이다.[57] 다른 많은 전환 매커니즘은 터널링을 사용하여 IPv4 네트워크 내에 IPv6 트래픽을 캡슐화하거나 그 반대로 수행한다. 이는 링크의최대 전송 단위(MTU)를 줄여경로 MTU 탐색을 복잡하게 만들고 지연 시간을 증가시킬 수 있는 불완전한 솔루션이다.[58][59]

듀얼 스택 IP 구현

[편집]

듀얼 스택 IP 구현은이더넷과 같은 공통물리 계층 구현 위에컴퓨터 또는네트워크 장치의 운영체제에서 완전한 IPv4 및 IPv6 프로토콜 스택을 제공한다. 이는 듀얼 스택 호스트가 IPv6 및 IPv4 네트워크에 동시에 참여할 수 있게 한다.[60]

운영체제에 듀얼 스택 구현이 있는 장치는 IPv4 및 IPv6 주소를 가지며, IPv4 또는 IPv6를 사용하여 LAN 또는 인터넷의 다른 노드와 통신할 수 있다. DNS 프로토콜은 두 IP 프로토콜 모두에서 전체 주소 도메인 네임과 IP 주소를 해석하는 데 사용되지만, 듀얼 스택은 해석하는 DNS 서버가 두 유형의 주소를 모두 해석할 수 있어야 한다. 이러한 듀얼 스택 DNS 서버는 A 레코드에 IPv4 주소를, AAAA 레코드에 IPv6 주소를 보유한다. 해석할 목적지에 따라 DNS 네임 서버는 IPv4 또는 IPv6 IP 주소 중 하나를 반환하거나 둘 다 반환할 수 있다. 호스트 또는 DNS 서버에서 기본 주소 선택 매커니즘 또는 선호 프로토콜을 구성해야 한다. IETF는해피 아이볼(Happy Eyeballs)을 발표하여 듀얼 스택 응용 프로그램이 IPv4와 IPv6를 모두 사용하여 연결할 수 있지만 사용 가능한 경우 IPv6 연결을 선호하도록 지원한다. 그러나 듀얼 스택은 DNS 서버가 IPv6 주소를 반환한 서비스와 호스트 사이의 모든 라우터에서도 구현되어야 한다. 듀얼 스택 클라이언트는 네트워크가라팅 프로토콜의 IPv6 버전을 사용하여 IPv6 패킷을 전달할 수 있는 경우에만 IPv6를 선호하도록 구성되어야 한다. 듀얼 스택 네트워크 프로토콜이 마련되면응용 계층을 IPv6로 마이그레이션할 수 있다.[61]

듀얼 스택은 주요운영체제 및 네트워크 장치 벤더에 의해 지원되지만, 오래된 네트워크 하드웨어 및 서버는 IPv6를 지원하지 않는다.

공인 IPv6를 사용하는 ISP 고객

[편집]
IANA, RIR 및 ISP를 통한 IPv6 접두사 할당 매커니즘

인터넷 서비스 제공자(ISP)들은 기업 및 개인 고객에게 공인 IPv6 전역 유니캐스트 주소를 점점 더 많이 제공하고 있다. 그러나 근거리 통신망(LAN)에서 여전히 IPv4를 사용하고 ISP가 공인 IPv6 주소를 하나만 제공할 수 있는 경우, IPv4 LAN 주소는네트워크 주소 변환(NAT) 매커니즘인NAT64를 사용하여 공인 IPv6 주소로 변환된다. 일부 ISP는 전역적으로 라우팅 가능한 IPv4 주소 풀이 소진되었기 때문에 고객에게 공인 IPv4 및 IPv6 주소를 모두 제공하여 듀얼 스택 네트워킹을 지원할 수 없다. 그동안 ISP 고객들은 여전히 IPv4웹 서버 및 기타 목적지에 도달하려고 시도하고 있다.[62]

모든대륙별 인터넷 레지스트리(RIR) 구역의 상당수 ISP가 IPv6 주소 공간을 확보했다. 여기에는버라이즌 와이어리스,스타허브 케이블,주부 텔레커뮤니케이션즈,Kabel Deutschland,스위스컴,T-모바일,인터노드텔레포니카와 같은 세계 주요 ISP 및이동 통신망 운영자가 포함된다.[63]

일부 ISP는 여전히 고객에게 IPv4 주소만 할당하지만, 많은 ISP가 고객에게 IPv6 전용 또는 듀얼 스택 IPv4 및 IPv6를 할당한다. ISP들은 자사 네트워크를 통한 고객의 IPv6 트래픽 점유율이 20%에서 40% 사이인 것으로 보고하고 있지만, 2017년 중반까지 IPv6 트래픽은 여러 대형인터넷 익스체인지 포인트(IXP)에서 전체 트래픽의 극히 일부만을 차지했다.AMS-IX는 2%,SeattleIX는 7%라고 보고했다. 2017년 한 조사에 따르면 듀얼 스택 ISP의 서비스를 받는 많은 DSL 고객이 DNS 서버에 전체 주소 도메인 네임을 IPv6 주소로 해석하도록 요청하지 않았다. 또한 조사 결과 IPv6 준비가 된 웹 서버 리소스로부터의 트래픽 대부분이 여전히 IPv4를 통해 요청되고 제공되었는데, 이는 주로 ISP가 제공하는 듀얼 스택 기능을 사용하지 않는 ISP 고객과 소수의 IPv4 전용 ISP 고객 때문이었다.[64]

터널링

[편집]

IPv4 패킷 내에 IPv6 패킷을 터널링하거나 캡슐화하는 기술적 기반은RFC 4213에 요약되어 있다. 인터넷 백본이 IPv4 전용이었을 때 자주 사용되었던 터널링 프로토콜 중 하나는6to4였다.[65]테레도 터널링 또한 IPv6 LAN을 IPv4 인터넷 백본과 통합하는 데 자주 사용되었다. 테레도는RFC 4380에 요약되어 있으며 IPv6 패킷을 UDP 내에 캡슐화하여 IPv6근거리 통신망이 IPv4 네트워크를 통해 터널링할 수 있게 한다. 테레도 릴레이는 테레도 서버와 네이티브 IPv6 네트워크 사이를 중재하는 IPv6 라우터이다. ISP 네트워크가 네이티브 IPv6로 전환될 때까지 6to4와 테레도가 널리 배포될 것으로 예상되었으나, 2014년 구글 통계에 따르면 두 매커니즘의 사용량은 거의 0으로 떨어졌다.[66]

IPv4 매핑 IPv6 주소

[편집]
IPv4 호환 IPv6 유니캐스트 주소
IPv4 매핑 IPv6 유니캐스트 주소

하이브리드 듀얼 스택 IPv6/IPv4 구현은 특수한 주소 클래스인 IPv4 매핑 IPv6 주소를 인식한다.[67]:§2.2.3[5] 이러한 주소는 일반적으로 표준 IPv6 형식의 96비트 접두사로 작성되며 나머지 32비트는 IPv4의 관습적인점-십진 표기법으로 작성된다.

이 그룹의 주소는 80비트의 0 접두사로 구성되며 다음 16비트는 1이고 나머지 최하위 32비트에는 IPv4 주소가 포함된다. 예를 들어,::ffff:192.0.2.128은 IPv4 주소192.0.2.128을 나타낸다. "IPv4 호환 IPv6 주소"라고 불리는 이전 형식은::192.0.2.128이었으나, 이 방법은 권장되지 않는다.[5]

IPv4와 IPv6 프로토콜 스택 사이의 상당한 내부 차이로 인해, IPv6 스택에서 프로그래머가 사용할 수 있는 일부 하위 수준 기능은 IPv4 매핑 주소와 함께 사용될 때 동일하게 작동하지 않는다. 일부 일반적인 IPv6 스택은 IPv6와 IPv4 스택이 별개의 구현이거나(마이크로소프트 윈도우 2000, XP 및 서버 2003 등), 보안 우려(OpenBSD) 때문에 IPv4 매핑 주소 기능을 구현하지 않는다. 이러한 운영체제에서 프로그램은 사용하는 각 IP 프로토콜에 대해 별도의 소켓을 열어야 한다.리눅스 커널,NetBSDFreeBSD와 같은 일부 시스템에서 이 기능은 소켓 옵션 IPV6_V6ONLY에 의해 제어된다.[68]:22

주소 접두사64:ff9b::/96NAT64 전환 방법에서 사용하기 위한 IPv4 내장 IPv6 주소 클래스이다.[69] 예를 들어,64:ff9b::192.0.2.128은 IPv4 주소192.0.2.128을 나타낸다.

보안

[편집]

IPv6의 사용으로 인해 여러 보안 관련 영향이 발생할 수 있다. 그중 일부는 IPv6 프로토콜 자체와 관련이 있을 수 있고, 다른 것들은 구현 결함과 관련이 있을 수 있다.[70][71]

섀도 네트워크

[편집]

소프트웨어 제조사가 기본적으로 IPv6를 활성화한 노드를 추가하면 의도치 않게 섀도 네트워크(shadow networks)가 생성될 수 있으며, 이로 인해 IPv4 보안 관리만 이루어지는 네트워크로 IPv6 트래픽이 유입될 수 있다. 이는 이전 운영체제는 기본적으로 IPv6를 활성화하지 않았으나 최신 운영체제는 활성화하는 경우의 운영체제 업그레이드 시에도 발생할 수 있다. IPv6를 수용하도록 보안 인프라를 업데이트하지 않으면 IPv6 트래픽이 보안 시스템을 우회하게 될 수 있다.[72] 섀도 네트워크는 기업이 IPv6 스택이 기본적으로 활성화되지 않은윈도우 XP 시스템을 활성화된윈도우 7 시스템으로 교체하는 비즈니스 네트워크에서 발생해 왔다.[73] 따라서 일부 IPv6 스택 구현자들은 IPv4 매핑 주소를 비활성화하고 대신 IPv4와 IPv6 지원이 모두 필요한 듀얼 스택 네트워크를 사용할 것을 권장해 왔다.[74]

IPv6 패킷 단편화

[편집]

연구에 따르면 IPv4와 유사하게 단편화의 사용이 네트워크 보안 제어를 우회하는 데 활용될 수 있음이 밝혀졌다. 결과적으로 이제 IPv6 패킷의 첫 번째 단편이 전체 IPv6 헤더 체인을 포함해야 하며([75]), 이에 따라 일부 매우 비정상적인 단편화 사례는 금지된다. 또한 RA-Guard 우회 연구 결과로 인해이웃 탐색 프로토콜에서의 단편화 사용은 권장되지 않으며([76]), 보안 이웃 탐색(SEND)에서의 사용도 억제된다.[77]

RFC를 통한 표준화

[편집]

작업 그룹 제안

[편집]
IPv6를 관장하는 표준들의 타임라인

인터넷의 예상되는 전 세계적 성장에 따라,국제 인터넷 표준화 기구(IETF)는 1990년대 초에 차세대 IP 프로토콜을 개발하기 위한 노력을 시작했다.[6]:209 1992년 초까지 확장된 인터넷 주소 체계에 대한 여러 제안이 나타났고 1992년 말까지 IETF는 백서(white papers) 모집을 공고했다.[78] 1993년 9월, IETF는 이러한 문제를 구체적으로 다루기 위해 임시 ad hoc 차세대 IP(IPng) 영역을 만들었다. 이 새로운 영역은앨리슨 맨킨스콧 브래드너가 주도했으며, 방향 설정 및 예비 문서 검토를 위해 다양한 배경을 가진 15명의 엔지니어로 구성된 운영위원회를 두었다.[8][79] 작업 그룹 구성원은J. 알라드(마이크로소프트),스티브 벨로빈(AT&T), 짐 바운드(디지털 이큅먼트 코퍼레이션), 로스 캘론(Wellfleet),브라이언 카펜터(CERN),데이브 클라크(MIT),존 커런(NEARNET),스티브 디어링(제록스), 디노 파리나치(시스코), 폴 프랜시스(NTT), 에릭 플라이슈만(보잉), 마크 노퍼(아메리텍), 그레그 민셜(노벨), 롭 울맨(로터스) 및리샤장(제록스)이었다.[80]

국제 인터넷 표준화 기구는 1994년 7월 25일에 여러 IPng 작업 그룹을 구성하며 IPng 모델을 채택했다.[8] 1996년부터RFC 1883을 시작으로 인터넷 프로토콜 버전 6(IPv6)를 정의하는 일련의RFC가 발표되었다. (버전 5는 실험적인인터넷 스트림 프로토콜에 의해 사용되었다.)

RFC 표준화

[편집]

IPv6를 표준화한 첫 번째 RFC는 1995년의RFC 1883이었다.[81] 1998년RFC 2460이 IPv6용 RFC가 되었다.[6]:209 2017년 7월RFC 2460RFC 8200에 의해 대체되었으며, 이는 IPv6를 "인터넷 표준"(IETF 프로토콜의 최고 성숙도 단계)으로 격상시켰다.[3].RFC 8201은 패킷 단편화를 피하기 위해 허용되는 최대 패킷 크기를 갖는 소스에서 목적지까지의 가장 효율적인 네트워크 경로를 찾는 방법을 설명하는 관련 IPv6 표준이다.

도입

[편집]
 이 부분의 본문은IPv6 도입입니다.
대륙별 인터넷 레지스트리(RIR)별 월간 IPv6 할당률

1993년 인터넷의 라우팅 및 IP 주소 할당에CIDR(CIDR)이 도입되고네트워크 주소 변환(NAT)이 광범위하게 사용되면서, 2000년대 중반에 시작된 IPv6 도입을 가능하게 하도록IPv4 주소 고갈이 지연되었다.

대학교들은 IPv6를 조기에 채택한 곳 중 하나였다.버지니아 공과대학교는 2004년에 시험 장소에 IPv6를 배포하고 나중에캠퍼스 통신망 전체로 IPv6 도입을 확장했다. 2016년까지 해당 네트워크 트래픽의 82%가 IPv6를 사용했다.임페리얼 칼리지 런던은 2003년에 실험적인 IPv6 도입을 시작했으며 2016년까지 해당 네트워크의 IPv6 트래픽은 평균 20%에서 40% 사이였다. 이 IPv6 트래픽의 상당 부분은 전적으로 IPv6에 의존하는유럽 입자 물리 연구소(CERN)와의고에너지 물리학 협력을 통해 생성되었다.[82]

도메인 네임 시스템(DNS)은 2008년부터 IPv6를 지원해 왔다. 같은 해, IPv6는베이징 2008 하계 올림픽 기간 동안 주요 세계 행사에서 처음으로 사용되었다.[83][84]

2011년까지 개인용 컴퓨터 및 서버 시스템에서 사용되는 모든 주요 운영체제는 상용 수준의 IPv6 구현을 갖추었다. 휴대 전화 시스템은 모바일 전화 서비스가3G에서4G 기술로 전환됨에 따라 인터넷 프로토콜 장치의 대규모 도입 분야가 되었으며, 여기서 음성은 IPv6 향상 기능을 활용하는음성 인터넷 프로토콜(VoIP) 서비스로 제공된다. 2009년 미국의 이동 통신사버라이즌은 자사의 "차세대" 네트워크에서 장치가 작동하기 위한 기술 사양을 발표했다.[85] 이 사양은 3GPP 릴리스 8 사양(2009년 3월)에 따른 IPv6 운영을 의무화하고 IPv4를 선택적 기능으로 격하시켰다.[85]

인터넷 백본에서의 IPv6 도입은 계속되었다. 2018년에는 약 54,000개의 자율 시스템 중 25.3%만이 전역경계 경로 프로토콜(BGP) 라우팅 데이터베이스에서 IPv4와 IPv6 접두사를 모두 광고했다. 추가로 243개의 네트워크가 IPv6 접두사만 광고했다. IPv6 지원을 제공하는 인터넷 백본 전송 네트워크는아프리카 일부 지역,중동 및 중국을 제외하고 전 세계 모든 국가에 존재했다.[86]:6 2018년 중반까지 일부 주요 유럽광대역 ISP는 대다수 고객에게 IPv6를 배포했다.스카이 UK는 고객의 86% 이상에게 IPv6를 제공했고,도이체 텔레콤은 56%의 IPv6 배포율을 보였으며, 네덜란드의XS4ALL은 73%, 벨기에의 광대역 ISPVOO텔레넷은 각각 73%와 63%의 IPv6 배포율을 기록했다.[86]:7 미국에서 광대역 ISPXfinity의 IPv6 배포율은 약 66%였다. 2018년에 Xfinity는 약 3,610만 명의 IPv6 사용자를 보고했으며,AT&T는 2,230만 명의 IPv6 사용자를 보고했다.[86]:7–8

2025년 12월 기준, 구글의 통계에 따르면 약 44%의 사용자가 네이티브 IPv6 연결을 통해 구글 서비스에 접속한다.[87] 도입률은 지역별로 큰 차이가 있는데, 인도, 프랑스, 독일과 같은 국가들은 70% 이상의 도입률을 기록하는 반면 다른 국가들은 뒤처져 있다.[88]

피어링 이슈

[편집]

IPv6에서허리케인 일렉트릭(Hurricane Electric)과코젠트 커뮤니케이션즈(Cogent Communications) 사이에 피어링 분쟁이 발생하고 있으며, 두 네트워크 제공업체는 피어링을 거부하고 있다.[89]

각주

[편집]
  1. FAQs. New Zealand IPv6 Task Force. 2019년 1월 29일에원본 문서에서 보존된 문서. 2015년 10월 26일에 확인함. 
  2. 123456S. Deering;R. Hinden(December 1998).Internet Protocol, Version 6 (IPv6) Specification.Network Working Group.RFC 2460.https://tools.ietf.org/html/rfc2460. Obsolete. Obsoleted byRFC 8200. ObsoletesRFC 1883. Updated byRFC 5095,5722,5871,6437,6564,6935,6946,7045 and7112.
  3. 12S. Deering;R. Hinden(July 2017).Internet Protocol, Version 6 (IPv6) Specification.IETF.STD 86.RFC 8200.https://tools.ietf.org/html/rfc8200. Internet Standard. ObsoletesRFC 2460.
  4. Siddiqui, Aftab (2017년 7월 17일).RFC 8200 – IPv6 Has Been Standardized.인터넷 협회. 2023년 10월 23일에원본 문서에서 보존된 문서. 2018년 2월 25일에 확인함. 
  5. 12345R. Hinden;S. Deering(February 2006).IP Version 6 Addressing Architecture.Network Working Group.RFC 4291.https://tools.ietf.org/html/rfc4291. Draft Standard. ObsoletesRFC 3513. Updated byRFC 5952,6052,7136,7346,7371 and8064.
  6. 1234Rosen, Rami (2014).Linux Kernel Networking: Implementation and Theory. New York: Apress.ISBN 9781430261971.OCLC 869747983. 
  7. Google IPv6 Conference 2008: What will the IPv6 Internet look like?. 13:35에 발생. 2021년 12월 11일에원본 문서에서 보존된 문서. 
  8. 123Bradner,S.;Mankin,A.(January 1995).The Recommendation for the IP Next Generation Protocol.IETF.RFC 1752.https://tools.ietf.org/html/rfc1752. 
  9. Free Pool of IPv4 Address Space Depleted.NRO.net.몬테비데오: The Number Resource Organization. 2011년 2월 3일. 2024년 1월 18일에원본 문서에서 보존된 문서. 2022년 1월 19일에 확인함. 
  10. Rashid, Fahmida (2011년 2월 1일).IPv4 Address Exhaustion Not Instant Cause for Concern with IPv6 in Wings. eWeek. 2024년 1월 20일에원본 문서에서 보존된 문서. 2012년 6월 23일에 확인함. 
  11. Ward, Mark (2012년 9월 14일).Europe hits old internet address limits.BBC 뉴스. 2023년 11월 5일에원본 문서에서 보존된 문서. 2012년 9월 15일에 확인함. 
  12. Huston, Geoff.IPV4 Address Report. 2024년 1월 10일에원본 문서에서 보존된 문서. 
  13. AFRINIC (2020년 1월 13일).AFRINIC enters IPv4 Exhaustion Phase 2 (영국 영어).afrinic.net. 2025년 4월 20일에 확인함. 
  14. The RIPE NCC has run out of IPv4 Addresses (보도 자료).RIPE NCC. 2019년 11월 25일. 2024년 1월 19일에원본 문서에서 보존된 문서. 2019년 11월 26일에 확인함. 
  15. 12C. Partridge;F. Kastenholz(December 1994).Technical Criteria for Choosing IP The Next Generation (IPng).Network Working Group.RFC 1726.https://tools.ietf.org/html/rfc1726. Informational.
  16. S. Deering(August 1989).Host Extensions for IP Multicasting.Network Working Group.STD 5.RFC 1112.https://tools.ietf.org/html/rfc1112. Internet Standard 5. ObsoletesRFC 988 and1054. Updated byRFC 2236.
  17. 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 byRFC 7371. UpdatesRFC 3306.
  18. D. Thaler;M. Handley;D. Estrin(September 2000).The Internet Multicast Address Allocation Architecture.Network Working Group.RFC 2908.https://tools.ietf.org/html/rfc2908. Obsolete. Obsoleted byRFC 6308.
  19. 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 byRFC 3956,4489 and7371.
  20. 12S. Thomson;T. Narten;T. Jinmei(September 2007).IPv6 Stateless Address Autoconfiguration.Network Working Group.RFC 4862.https://tools.ietf.org/html/rfc4862. Draft Standard. ObsoletesRFC 2462. Updated byRFC 7527.
  21. M. Crawford(August 2000).Router Renumbering for IPv6.Network Working Group.RFC 2894.https://tools.ietf.org/html/rfc2894. Proposed Standard.
  22. T. Narten; R. Draves; S. Krishnan (September 2007).Privacy Extensions for Stateless Address Autoconfiguration in IPv6.www.ietf.org. 2017년 3월 13일에 확인함. 
  23. 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. ObsoletesRFC 4941.
  24. Overview of the Advanced Networking Pack for Windows XP.마이크로소프트. 2017년 9월 7일에원본 문서에서 보존된 문서. 2019년 4월 15일에 확인함. 
  25. Privacy Extensions for IPv6 SLAAC.인터넷 협회. 2014년 8월 8일. 2023년 10월 23일에원본 문서에서 보존된 문서. 2020년 1월 17일에 확인함. 
  26. Ferguson, P.; Berkowitz, H. (January 1997).Network Renumbering Overview: Why would I want it and what is it anyway?.IETF.doi:10.17487/RFC2071.RFC 2071. 2024년 1월 7일에원본 문서에서 보존된 문서. 
  27. Berkowitz, H. (January 1997).Router Renumbering Guide.IETF.doi:10.17487/RFC2072.RFC 2072. 2023년 6월 8일에원본 문서에서 보존된 문서. 
  28. Cooper,Alissa;Gont,Fernando;Thaler,Dave.Recommendation on Stable IPv6 Interface Identifiers.RFC 8064.https://tools.ietf.org/html/rfc8064. 
  29. E. Jankiewicz;J. Loughney;T. Narten(December 2011).IPv6 Node Requirements.Internet Engineering Task Force.ISSN 2070-1721.RFC 6434.https://tools.ietf.org/html/rfc6434. Obsolete. p. 17. Obsoleted byRFC 8504. ObsoletesRFC 4294.이전에 IPv6는 IPsec의 구현을 의무화하고 IKE의 키 관리 방식을 권장했습니다. 이 문서는 모든 IPv6 노드에 대해RFC 4301 IPsec 아키텍처 지원을 'SHOULD'로 만듦으로써 해당 권장 사항을 업데이트합니다.
  30. Silvia Hagen (2014).IPv6 Essentials: Integrating IPv6 into Your IPv4 Network 3판. Sebastopol, CA: O'Reilly Media. 196쪽.ISBN 978-1-4493-3526-7.OCLC 881832733. 
  31. Zack, E. (July 2013).IPv6 Security Assessment and Benchmarking. 
  32. Gont, F. (March 2016).Operational Implications of IPv6 Packets with Extension Headers.IETF. 2023년 10월 27일에원본 문서에서 보존된 문서. 
  33. V. Devarapalli;R. Wakikawa;A. Petrescu;P. Thubert(January 2005).Network Mobility (NEMO) Basic Support Protocol.Network Working Group.RFC 3963.https://tools.ietf.org/html/rfc3963. Proposed Standard.
  34. D. Borman;S. Deering;R. Hinden(August 1999).IPv6 Jumbograms.Network Working Group.RFC 2675.https://tools.ietf.org/html/rfc2675. Proposed Standard. ObsoletesRFC 2147.
  35. K. Nichols;S. Blake;F. Baker;D. Black(December 1998).Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.Network Working Group.RFC 2474.https://tools.ietf.org/html/rfc2474. Proposed Standard. ObsoletesRFC 1455 and1349. Updated byRFC 3168,3260 and8436.
  36. K. Ramakrishnan;S. Floyd;D. Black(September 2001).The Addition of Explicit Congestion Notification (ECN) to IP.Network Working Group.RFC 3168.https://tools.ietf.org/html/rfc3168. Proposed Standard. ObsoletesRFC 2481. UpdatesRFC 2474,2401 and793. Updated byRFC 4301,6040 and8311.
  37. Graziani, Rick (2012).IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6.Cisco Press. 55쪽.ISBN 978-0-13-303347-2. 
  38. Coffeen, Tom (2014).IPv6 Address Planning: Designing an Address Plan for the Future.O'Reilly Media. 170쪽.ISBN 978-1-4919-0326-1. 
  39. 12Horley, Edward (2013).Practical IPv6 for Windows Administrators.Apress. 17쪽.ISBN 978-1-4302-6371-5. 
  40. 12S. 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. UpdatesRFC 4291.
  41. M. Blanchet(April 2008).Special-Use IPv6 Addresses.Network Working Group.RFC 5156.https://tools.ietf.org/html/rfc5156. Proposed Standard. Obsoleted byRFC 6890.
  42. 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 66. ObsoletesRFC 2732,2396 and1808. Updated byRFC 6874,7320 and8820. UpdatesRFC 1738.
  43. 123Narten, T. (August 1999).Neighbor discovery and stateless autoconfiguration in IPv6.IEEE Internet Computing3. 54–62쪽.Bibcode:1999IIC.....3d..54N.doi:10.1109/4236.780961. 
  44. Narten, T. (September 2007).Neighbor Discovery for IP version 6 (IPv6).IETF. section 6.3.7.doi:10.17487/RFC4861.RFC 4861. 2024년 1월 17일에원본 문서에서 보존된 문서. 
  45. Thomson, S. (September 2007).IPv6 Stateless Address Autoconfiguration - Section 5.5.1.IETF.doi:10.17487/RFC4862.RFC 4862. 2024년 1월 11일에원본 문서에서 보존된 문서. 
  46. IPv6 Address Allocation and Assignment Policy.RIPE NCC. 2011년 2월 8일. 2023년 6월 3일에원본 문서에서 보존된 문서. 2011년 3월 27일에 확인함. 
  47. 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 byRFC 6177.
  48. 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. ObsoletesRFC 3177.
  49. Brzozowski, John (2011년 1월 31일).Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS (보도 자료).컴캐스트. 2023년 10월 23일에원본 문서에서 보존된 문서. 2019년 4월 15일에 확인함. 
  50. 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. ObsoletesRFC 3152 and1886.
  51. 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. ObsoletesRFC 3484.
  52. Silvia Hagen (2014).IPv6 Essentials: Integrating IPv6 into Your IPv4 Network. O'Reilly Media, Inc. 176쪽.ISBN 9781449335267. 
  53. 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 byRFC 3152,3226,3363 and3364. UpdatesRFC 1886.
  54. 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. UpdatesRFC 2673,2874.
  55. R. Bush;A. Durand;B. Finket 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. UpdatesRFC 2673,2874.
  56. IPv6 Transition Mechanism/Tunneling Comparison. Sixxs.net. 2023년 10월 23일에원본 문서에서 보존된 문서. 2012년 1월 20일에 확인함. 
  57. Silvia Hagen (2014).IPv6 Essentials: Integrating IPv6 into Your IPv4 Network. O'Reilly Media, Inc. 222–223쪽.ISBN 9781449335267. 
  58. Carpenter, B. (August 2011).Advisory Guidelines for 6to4 Deployment.IETF.doi:10.17487/RFC6343.RFC 6343. 2023년 1월 28일에원본 문서에서 보존된 문서. 2012년 8월 20일에 확인함. 
  59. IPv6: Dual stack where you can; tunnel where you must. networkworld.com. 2007년 9월 5일. 2024년 1월 20일에원본 문서에서 보존된 문서. 2012년 11월 27일에 확인함. 
  60. E. Nordmark;R. Gilligan(October 2005).Basic Transition Mechanisms for IPv6 Hosts and Routers.Network Working Group.RFC 4213.https://tools.ietf.org/html/rfc4213. Proposed Standard. ObsoletesRFC 2893.
  61. Silvia Hagen (2014).IPv6 Essentials: Integrating IPv6 into Your IPv4 Network. O'Reilly Media, Inc. 222쪽.ISBN 9781449335267. 
  62. Understanding Dual Stacking of IPv4 and IPv6 Unicast Addresses.Juniper.net. Juniper Networks. 2017년 8월 31일. 2022년 1월 19일에 확인함. 
  63. IPv6.NRO.net. 2017년 1월 12일에원본 문서에서 보존된 문서. 2017년 3월 13일에 확인함. 
  64. Pujol, Enric (2017년 6월 12일).What Stops IPv6 Traffic in a Dual-Stack ISP?.APNIC.net.APNIC. 2023년 3월 27일에원본 문서에서 보존된 문서. 2017년 6월 13일에 확인함. 
  65. Vaughan-Nichols, Steven J. (2010년 10월 14일).Five ways for IPv6 and IPv4 to peacefully co-exist.ZDNET. 2023년 12월 5일에원본 문서에서 보존된 문서. 2017년 3월 13일에 확인함. 
  66. Silvia Hagen (2014).IPv6 Essentials: Integrating IPv6 into Your IPv4 Network. O'Reilly Media, Inc. 33쪽.ISBN 9781449335267. 
  67. 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. ObsoletesRFC 4773,5156,5735 and5736. Updated byRFC 8190.
  68. R. Gilligan;S. Thomson;J. Bound;J. McCann;W. Stevens(February 2003).Basic Socket Interface Extensions for IPv6.Network Working Group.RFC 3493.https://tools.ietf.org/html/rfc3493. 
  69. 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. UpdatesRFC 4291.
  70. Gont, Fernando (2019년 3월 10일),IPv6 Security for IPv4 Engineers(PDF), 2019년 8월 30일에 확인함 
  71. Gont, Fernando (2019년 1월 10일),IPv6 Security Frequently Asked Questions (FAQ)(PDF), 2019년 8월 30일에 확인함 
  72. Mullins, Robert (2012년 4월 5일),Shadow Networks: an Unintended IPv6 Side Effect,Network Computing, 2013년 4월 11일에원본 문서에서 보존된 문서, 2013년 3월 2일에 확인함 
  73. Cicileo, Guillermo; Gagliano, Roque; O'Flaherty, Christian 외 (October 2009).IPv6 For All: A Guide for IPv6 Usage and Application in Different Environments(PDF). 5쪽. 2013년 3월 2일에 확인함. 
  74. Jun-ichiro itojun Hagino (October 2003).IPv4-Mapped Addresses on the Wire Considered Harmful. 
  75. F. Gont;V. Manral;R. Bonica(January 2014).Implications of Oversized IPv6 Header Chains.IETF.ISSN 2070-1721.RFC 7112.https://tools.ietf.org/html/rfc7112. Proposed Standard. UpdatesRFC 2460.
  76. F. Gont(February 2014).Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard).IETF.ISSN 2070-1721.RFC 7113.https://tools.ietf.org/html/rfc7113. Informational. UpdatesRFC 6105.
  77. F. Gont(August 2013).Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery.Internet Engineering Task Force.ISSN 2070-1721.RFC 6980.https://tools.ietf.org/html/rfc6980. Proposed Standard. UpdatesRFC 3971 and4861.
  78. Bradner, S.; Mankin, A. (December 1993).IP: Next Generation (IPng) White Paper Solicitation.RFC 1550. 
  79. History of the IPng Effort.The Sun. 2014년 5월 23일에원본 문서에서 보존된 문서. 
  80. Bradner, Scott O.; Mankin, Allison J. (January 1995).The Recommendation for the IP Next Generation Protocol – Appendix B.RFC 1752. 
  81. Wang, Tao; Gao, Jiaqiong (2019년 1월 1일).The Shortcomings of Ipv6 and Upgrade of Ipv4 (영어).International Journal of Advanced Network, Monitoring and Controls4. 1–9쪽.doi:10.21307/ijanmc-2019-029. 
  82. State of IPv6 Deployment 2018,인터넷 협회, 2018, 3쪽 
  83. Beijing2008.cn leaps to next-generation Net (보도 자료). The Beijing Organizing Committee for the Games of the XXIX Olympiad. 2008년 5월 30일. 2009년 2월 4일에원본 문서에서 보존된 문서. 
  84. Das, Kaushik (2008).IPv6 and the 2008 Beijing Olympics.IPv6.com. 2008년 8월 1일에원본 문서에서 보존된 문서. 2008년 8월 15일에 확인함. 
  85. 12Morr, Derek (2009년 6월 9일).Verizon Mandates IPv6 Support for Next-Gen Cell Phones. CircleID. 
  86. 123State of IPv6 Deployment 2018(PDF).InternetSociety.org.인터넷 협회. 2022년 1월 19일에 확인함. 
  87. IPv6 Adoption. 2025년 12월 15일에 확인함. 
  88. State of the Internet / IPv6 Adoption Visualization. Akamai. 2020년 11월 11일에원본 문서에서 보존된 문서. 2025년 12월 15일에 확인함. 
  89. The case of Hurricane Electric And Cogent.BGP.tools. 2024년 9월 10일에 확인함. 

외부 링크

[편집]
  • 위키미디어 공용에IPv6 관련 미디어 분류가 있습니다.
  • (영어)IPv6 포럼

IPv6 표준 문서

[편집]
  • (영어)RFC2460 Internet Protocol, Version 6 (IPv6) 규격
  • (영어)RFC4291 Internet Protocol Version 6 (IPv6) 주소 할당 구조
  • (영어)RFC4861 Neighbor Discovery for IP Version 6 (IPv6)
  • (영어)RFC4884 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 규격
원본 주소 "https://ko.wikipedia.org/w/index.php?title=IPv6&oldid=41229089"
분류:
숨은 분류:

[8]ページ先頭

©2009-2026 Movatter.jp