hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
전자 플라이트 백 역사
초기 EFB의 전신은 1990년대 초 페덱스의 개별 조종사들이 개인 노트북을 사용하여 항공기 성능 계산을 수행했던 것이다. 이들은 공항 성능 노트북 컴퓨터라고 불렸고 상업용 기성 컴퓨터였으며 휴대용으로 간주되었다.
조종사의 전체 키트 가방을 대체하기 위해 특별히 설계된 최초의 진정한 EFB는 1999년 앤젤라 매슨이 전자 키트 가방(EKB)으로 특허를 받았다. 2003년 10월 KLM 항공은 보잉 777 항공기에 최초로 설치된 EFB를 수락했다. 보잉 EFB 하드웨어는 아스트로노틱스 코퍼레이션 오브 아메리카에서 제작했으며, 소프트웨어 애플리케이션은 젭슨과 보잉이 모두 제공했다. 2005년, 최초의 상업용 Class 2 EFB가 Avionics Support Group, Inc.에 발행되었으며, EFB의 일부로 Constant Friction Mount(cfMount)가 포함되었다. 이 설치는 마이애미 에어의 보잉 B737NG에서 수행되었다.
전자 플라이트 백 역사
2009년 콘티넨털 항공은 Class 2 전자 플라이트 백 플랫폼에서 "자체 항공기" 위치를 표시하는 젭슨 공항 지표면 이동 지도(AMM)를 사용하여 세계 최초의 비행을 성공적으로 완료했다. AMM 애플리케이션은 고해상도 데이터베이스를 사용하여 공항 지도를 동적으로 렌더링한다.
개인 컴퓨팅 기술이 더욱 소형화되고 강력해짐에 따라, EFB는 전 세계의 모든 항공 차트를 단일 3파운드(1.4kg) 컴퓨터에 저장할 수 있게 되었다. 이는 전 세계 종이 차트에 일반적으로 필요한 80파운드(36kg)에 비해 크게 줄어든 무게이다. EFB를 사용하면 안전성이 향상되고, 승무원이 운용 절차 및 비행 관리 정보에 더 쉽게 접근할 수 있으며, 항공승무원이 더 안전한 이착륙을 위한 항공기 성능과 적재 계획을 위한 항공기 중량 및 균형을 정확하게 계산할 수 있도록 하여 안전을 강화한다.
전자 플라이트 백 역사
공군특수작전사령부 (AFSOC)는 2011년 12월에 출시된 3,000대 이상의 아이패드 기반 EFB 초기 물량을 구매했다. 비슷한 구매로, 항공 수송 사령부는 최대 18,000대의 아이패드 기반 EFB 계약을 시작했다. 공군특수작전사령부는 전 세계 모든 사용자에게 NGA(National Geo-Spatial Intelligence Agency)의 월간 비행 정보 간행물(FLIP) 데이터셋을 전송하는 보안 방법을 내부적으로 개발했다.
2011년 조종실 아이패드를 EFB로 시범 사용한 후, 델타 항공은 2013년 8월 조종사들이 개인 태블릿을 EFB로 사용할 수 있도록 허용하는 정책을 교체할 것이라고 발표했다. 델타는 2월 FAA 승인 후 2014년 5월까지 모든 조종사에게 새로운 인증된 EFB를 제공할 계획이었다. EFB로 사용되는 아이패드의 초기 파손 위험은 견고한 케이스 설계로 해결되었다. 그러나 AFSOC의 아이패드 구매는 러시아산 소프트웨어 조달 문제가 최종 사용자에게 잠재적인 위험을 노출할 수 있다는 보안 우려로 인해 2012년 2월 취소되었다.
EFB는 처음에는 여러 하드웨어 클래스와 소프트웨어 유형으로 나뉘었다.
전자 플라이트 백 역사
기존 EFB 하드웨어 클래스는 다음과 같다:
Class 1 – 노트북이나 휴대용 전자기기와 같은 표준 상용 기성품(COTS) 장비. 이 장비는 느슨한 장비로 사용되며 일반적으로 비행의 중요 단계(10,000피트 미만)에서는 보관된다. Class 1 EFB는 휴대용 전자 기기(PED)로 간주된다. 조종실 아이패드와 같은 Class 1 EFB는 '보안 및 가시성'이 확보된 경우 비행의 중요 단계에서 Type B 애플리케이션을 표시하는 데 사용될 수 있다.
Class 3 – "설치된 장비"로 간주되며 감항성 요구 사항이 적용되며, PED와 달리 설계 제어하에 있어야 한다. 하드웨어는 제한된 수의 RTCA DO-160E 요구 사항(비필수 장비의 경우 - 일반적인 충돌 안전 및 전도 및 방사 방출 테스트)이 적용된다. Class 3 EFB는 일반적으로 STC 또는 기타 감항성 승인에 따라 설치된다.
EFB는 처음에 세 가지 소프트웨어 범주로 분류된 광범위한 애플리케이션을 호스팅할 수 있다.
Type C 애플리케이션은 감항성 요구 사항의 적용을 받는 것으로 간주되었으며, 따라서 DO-178/ED-12 목표에 따라 개발되어야 하며 Class 3 EFB에서 실행되어야 한다.
전자 플라이트 백 설계 특징
현재 EFB는 "휴대용"(PED) 또는 "설치형"으로 분류된다. 휴대용은 이전 Class 1 및 2의 구분을 통합한 것으로 볼 수 있으며, 설치형은 기존 Class 3와 동일하다. 이러한 단순화는 혼란을 줄이고 이미 발표된 EASA 및 ICAO 지침과 조화를 이루기 위해 이루어졌다.
2017년 AC 120-76D가 발표되면서 Type C 애플리케이션에 대한 언급이 삭제되었으며, 이러한 기능은 더 이상 EFB 기능이 아니다.
전자 플라이트 백 규정
FAR Part 91 운영자(개인 및 기업 운영자를 포함하여 영리 목적으로 비행하지 않는 자)는 조종사-기장 권한을 사용하여 PED인 EFB 사용을 승인할 수 있지만, OpSpecs(Part 135, Part 121)를 사용하는 운영자는 다음 요구 사항에 따라 OpSpecs 프로세스를 통해 운영 승인을 받아야 한다.
유럽 내 운영자를 위한 전자 플라이트 백(EFB)의 감항성 및 운영 고려 사항에 대한 지침은 EASA AMC 20-25가 적용된다.
영국 국방부는 Regulatory Article 1340에 설명된 대로 EFB의 감항성을 특정 항공기 유형에 대해 '항공 시스템의 기본이 아닌 장비(ENBAS)'로 분류하는 방식을 취한다. 형식 감항 당국(TAA)과 지원 전달팀은 EFB 장치 자체가 해당 항공기의 감항성에 부정적인 영향을 미치지 않도록 이 승인을 담당한다. 특정 애플리케이션 사용 승인에 관해서는 항공 책임자(ADH) 체인의 책임이다.
존 오브라이언 (2루수)
존 조지프 오브라이언(영어: John Joseph O'Brien, 1866년 7월 13일~1913년 5월 13일)은 캐나다의 프로 야구 선수로, 포지션은 2루수였다. 1891년부터 1899년까지 메이저 리그 베이스볼(MLB)의 브루클린 그룸스, 시카고 콜츠, 루이빌 커늘스, 워싱턴 세너터스, 볼티모어 오리올스, 피츠버그 파이리츠에서 선수로 뛰었다. 마이너 리그에서도 오랜 기간 선수 생활을 이어갔으며, 1904년에는 베이츠 칼리지 야구부의 감독을 맡았다.
픽션북
픽션북(FictionBook)은 러시아에서 시작되어 인기를 얻은 개방형 XML 기반 전자책 형식이다. FictionBook 파일은 버전에 따라 .fb2 또는 .fb3 파일 확장자를 갖는다. 모든 FB2/FB3 지원 리더는 ZIP 압축 FictionBook 파일(.fb2.zip 또는 .fbz)도 지원한다.
FictionBook2 형식은 전자책의 레이아웃을 정의하기보다는 전자책의 구조를 설명한다. 예를 들어, 에피그래프, 구절 및 인용문을 위한 특별한 태그가 있다. 저자 이름, 제목, 출판사 등 모든 전자책 메타데이터도 전자책 파일에 존재한다. 이로 인해 이 형식은 자동 처리, 색인 생성, 전자책 컬렉션 관리 및 다른 형식으로의 쉬운 자동 변환에 편리하다.
픽션북 소프트웨어 및 하드웨어 지원
FB2는 전자책 단말기인 FBReader, AlReader, Haali Reader, STDU Viewer, CoolReader, 아큘러, Ectaco jetBooks, IOS용 Documents 등 일부에서 지원된다. 파이어폭스는 FB2 Reader 확장을 설치하여 FictionBook2를 읽을 수 있다. 많은 하드웨어 공급업체가 펌웨어에서 FictionBook2를 지원한다: 유럽의 BeBook One, BeBook Mini 및 BeBook Club (및 기타 Hanlin V3 및 V5 기반 장치), 모든 PocketBook Readers, COOL-ER 장치, Cybook Opus]] 및 Cybook Gen3, ASUS Eee Reader DR900. Hanvon N516 디자인 기반 장치는 사용자 지정 OpenInkpot 펌웨어를 설치하면 FictionBook을 읽을 수 있다. Azbooka 516의 경우 공장 기본값이다. 아마존의 아마존 킨들, 반스 & 노블의 반스 & 노블 눅, 소니 장치는 FictionBook을 직접 지원하지 않는다.
픽션북 소프트웨어 및 하드웨어 지원
FictionBook2 파일(.fb2 및 .fbz)로의 변환 및 변환은 크로스 플랫폼 전자책 관리 소프트웨어인 캘리버를 통해 가능하다. FictionBook2 형식으로의 변환 및 변환은 Pandoc을 통해서도 가능하다.
픽션북 FictionBook3
FictionBook3는 FictionBook2를 확장하기 위한 베타 제안이다.
FictionBook2와 FictionBook3는 두 가지 면에서 다르다: FB2는 단일 XML 파일로 구성되어 있으며, 그림은 Base64 인코딩된 "이진" 블록으로 내장되어 추가 파일이 필요 없다. FB3는 ePub 형식과 유사한 디렉터리 구조를 가지며 멀티미디어 콘텐츠의 레이아웃 및 임베딩을 통합한다.
FB3는 레이아웃 기능을 추가하고 그림을 Base64 인코딩된 블록으로 내장할 필요성을 제거하지만, 대부분 FB2에서 확립된 개념을 따른다.
2025년 8월 현재 2008년 이후로 베타 사양에 대한 업데이트가 없으며 인기 있는 전자책 리더 소프트웨어는 이를 지원하지 않는다.
소니 태블릿 S
소니 태블릿 S(Sony Tablet S)는 2011년 9월 소니가 출시한 태블릿 컴퓨터이다. "독특한 비대칭 디자인"을 특징으로 하는 태블릿 S는 구글의 안드로이드 3.1 허니콤 운영체제를 실행하며, 9.4 in (240 mm) 멀티터치 디스플레이, 1 GHz 엔비디아 테그라 2 듀얼 코어 프로세서, 와이파이 기능, 전면 및 후면 카메라, 블루투스, 적외선 센서를 갖추고 있다. 또한 소니 엔터테인먼트 네트워크에 접속할 수 있도록 구성되어 있으며, PlayStation Certified 및 DLNA 호환된다. 태블릿 S는 소니의 첫 번째 현대 태블릿 컴퓨터였다. 이 제품은 소니의 새로운 자회사인 소니 모바일이 개발할 엑스페리아 태블릿 S로 대체되었다.
소니 태블릿 S 디자인
태블릿 S의 주요 특징은 기기 두께가 20.6 to 10.1 mm (0.81 to 0.40 in)로 얇아지는 "독특한 비대칭 디자인"이다. 이러한 "랩" 효과는 "뒷주머니에 구겨 넣은 펼쳐진 문고판이나, 한 페이지가 보이도록 뒤로 접힌 잡지"를 연상시키며, 들고 있을 때 토크의 양을 줄여준다. 소니는 이 "무게 중심이 다른 디자인"이 "안정성과 그립감을 제공하며, 안정감과 가벼움을 선사하여 몇 시간 동안 편안하게 사용할 수 있도록 한다"고 주장한다.
소니 태블릿 S 하드웨어
태블릿 S는 9.4 인치 (240 밀리미터), 1280×800 픽셀 해상도를 가진 TFT LCD를 사용하며, 소니의 독점적인 TruBlack 디스플레이 기술을 사용한다. 이는 회사의 브라비아 TV 라인업에서 사용되는 것과 동일한 기술이다.
이 태블릿은 1 GHz ARM Cortex-A9 듀얼 코어 프로세서와 ULP GeForce GPU로 구성된 엔비디아 테그라 T20 SoC를 사용하며, 1 GB RAM과 16 또는 32 GB의 내부 저장 공간, 그리고 최대 32 GB의 SD 메모리 카드 지원을 제공한다.
다른 온보드 기능으로는 가속도계, 3축 자이로스코프, 자기계 (디지털 나침반), GPS 수신기, 802.11b/g/n 와이파이, 블루투스 v2.1 + EDR, 적외선, Micro USB, 마이크, 3.5 mm 헤드폰 잭, 0.3 MP 전면 카메라 및 5 MP 후면 카메라가 포함된다.
다른 안드로이드 장치와 마찬가지로, 태블릿 S에는 하드웨어 내비게이션 버튼이 없으며, 모든 버튼은 지속적인 화면 버튼으로 구현된다. 장치에 있는 유일한 물리적 버튼은 한쪽의 움푹 들어간 부분에 있는 전원 버튼과 볼륨 로커이다.
이 태블릿은 독점적인 전원 커넥터를 사용한다.
소니 태블릿 S 소프트웨어
태블릿 S1은 초기에 안드로이드 3.1 허니콤과 함께 출시되었지만, 출시 직후 3.2 업데이트가 제공되었다. 또한 4월 말 (일본과 미국에서) 안드로이드 4.0.3으로 업그레이드되었다. 이 태블릿은 맞춤형 운영체제 버전을 사용한다. 소니 장치에만 있는 기능 및 애플리케이션은 다음과 같다:
소니 태블릿 S는 PlayStation Certified 장치임에도 불구하고, PlayStation Store 업데이트로 인해 PS one 클래식을 구매할 수 없게 되었다. 대신, 태블릿 S 소유자는 오리지널 콘텐츠만 구매할 수 있게 되었다.
2012년 9월, 소니 태블릿 S는 안드로이드 4.0.3 릴리스 5a로 주요 업데이트를 받았다. 이 업데이트에는 다음과 같은 주요 변경 사항이 포함되었다.
소니 태블릿 S는 2013년 2월에 출시될 안드로이드 4.1 젤리빈으로의 업데이트가 확정되었다. 그러나 소니가 커뮤니티 게시판에 "1세대 태블릿(소니 태블릿 S)에 대한 젤리빈 업데이트 로드맵이 없다"는 게시물(나중에 삭제됨)을 올리면서 젤리빈 4.1 업데이트는 비공식적으로 취소되었다.
소니 태블릿 S 평가
평론가들은 소니 태블릿 S의 독특한 ("완전히 새로워진") 디자인을 칭찬하며 대체로 긍정적인 평가를 내렸다. 월스트리트 저널은 "태블릿 S는 아이패드를 따라하려는 것처럼 보이지 않는, 신뢰할 수 있는 회사에서 나온 독특한 태블릿을 원하는 구매자들에게 어필할 것"이라고 말했고, PC 월드는 "[소니]는 오랜 세월 동안 디자인 감각을 잃지 않았으며, 이 모델은 소니의 독창성과 세련미를 절실히 필요로 하는 태블릿 시장에 가져왔다"고 평가했다. 시드니 모닝 헤럴드의 애셔 모세스(Asher Moses)는 이 제품을 "최고의 안드로이드 태블릿"이라고 불렀다.
소니 태블릿 S 평가
부정적인 의견은 기기의 높은 가격과 낮은 빌드 품질에 집중되었다. 테크 블로그 기즈모도는 이를 "플라스틱 같음"이라고 표현하며, 소니가 무게를 줄이기 위해 품질이 낮은 재료를 사용하여 "매우 평범한 사진 촬영 중 심하게 긁혔다"고 지적하고, 떨어뜨리면 "백만 조각으로 부서질 것"이라고 평했다. 타임은 태블릿 S가 아이패드와 경쟁하려는 소니의 포부에 미치지 못한다고 보며, 평론가 재러드 뉴먼(Jared Newman)은 하워드 스트링어 소니 CEO의 발언을 인용하며 "태블릿 S가 스트링어가 생각하는 것이라면, 나는 소니의 미래를 위해 슬퍼할 것"이라고 말했다. 익스퍼트리뷰스(ExpertReviews)는 비디오 출력이 없는 것이 성가신 단점이라고 썼다. 일부 평론가들은 낮은 해상도 화면과 오래된 소프트웨어에 대해 태블릿을 비판했다.
태블릿 S는 소비자 기술협회(Consumer Electronics Association)의 CES 혁신 디자인 및 엔지니어링 어워드 2012에서 "태블릿, E-리더 및 넷북" 부문에서 수상의 영예를 안았다.
링크-로컬 주소
컴퓨터 망에서 링크-로컬 주소(Link-local address)는 로컬 링크, 즉 호스트가 연결된 서브네트워크 내의 통신에만 유효한 네트워크 주소이다. 링크-로컬 주소는 일반적으로 링크-로컬 주소 자동 구성으로 알려진 프로세스를 통해 자동으로 할당되며, 이는 자동 IP, 자동 사설 IP 주소 지정 (APIPA, IPv4에 특화), 및 무상태 주소 자동 구성 (SLAAC, IPv6에 특화)으로도 알려져 있다. 대부분의 링크-로컬 주소는 유니캐스트이지만, 항상 그런 것은 아니다. 예를 들어, ff02: (ff02::/16)로 시작하는 IPv6 주소와 224.0.0. (224.0.0.0/24)로 시작하는 IPv4 주소는 링크-로컬인 멀티캐스트 주소이다.
링크-로컬 주소는 네트워크 세그먼트를 넘어 고유성이 보장되지 않는다. 따라서 라우터는 링크-로컬 소스 또는 목적지 주소를 가진 데이터 패킷을 전달하지 않는다.
IPv4 링크-로컬 유니캐스트 주소는 주소 블록 169.254.0.0/16 (169.254.0.0부터 169.254.255.255까지)에서 할당된다. IPv6에서는 유니캐스트 링크-로컬 주소가 블록 fe80::/10에서 할당된다.:2.4
링크-로컬 주소 주소 할당
링크-로컬 주소는 관리자가 수동으로 할당하거나 자동 운영체제 절차에 의해 할당될 수 있다. 인터넷 프로토콜 (IP) 네트워크에서는 대개 무상태 주소 자동 구성을 사용하여 할당되며, 이 프로세스는 종종 추계학적 프로세스를 사용하여 링크-로컬 주소의 값을 선택하고, 각 세션에 대해 다른 의사 무작위 주소를 할당한다. 그러나 IPv6에서는 개인 정보 보호 및 보안상의 이유로 더 이상 사용되지 않지만, 인터페이스 MAC 주소에서 규칙 기반 방식으로 링크-로컬 주소를 파생할 수도 있다.
IPv4에서는 링크-로컬 주소가 일반적으로 동적 호스트 구성 프로토콜 (DHCP)과 같은 외부의 상태 유지 주소 구성 메커니즘이 없거나, 다른 주요 구성 방법이 실패했을 때만 사용된다. IPv6에서는 링크-로컬 주소가 다른 범위의 주소와 함께 항상 할당되며, 다양한 프로토콜 구성 요소의 내부 기능에 필요하다.
링크-로컬 주소 IPv4
국제 인터넷 표준화 기구 (IETF)는 링크-로컬 주소 지정을 위해 IPv4 주소 블록 169.254.0.0/16 (169.254.0.0 – 169.254.255.255)을 예약했다. 이 범위 전체가 이 목적으로 사용될 수 있지만, 첫 256개와 마지막 256개 주소 (169.254.0.0/24 및 169.254.255.0/24)는 미래 사용을 위해 예약되어 있으며 이 동적 구성 메커니즘을 사용하는 호스트에 의해 선택되어서는 안 된다.(p. 2.1) 링크-로컬 주소는 다른 주소 할당 수단이 없는 경우 호스트 내부, 즉 무상태 주소 자동 구성을 통해 인터페이스에 할당된다.
동일한 인터페이스에서 링크-로컬 주소와 전역적으로 라우팅 가능한 주소와 같이 다른 범위의 IPv4 주소를 동시에 사용하면 혼란과 복잡성이 증가할 수 있다.(p. 1.9) 따라서 호스트는 링크-로컬 주소를 할당하기 전에 네트워크에서 DHCP 서버를 찾는다.
링크-로컬 주소 IPv4
자동 주소 구성 프로세스에서 네트워크 호스트는 예약된 범위 내에서 무작위 후보 주소를 선택하고 주소 결정 프로토콜 (ARP) 프로브를 사용하여 네트워크에서 해당 주소가 사용 중이 아닌지 확인한다. ARP 프로브에 대한 회신이 수신되면 후보 IP 주소가 이미 사용 중임을 나타낸다. 새로운 무작위 후보 IP 주소가 생성되고 프로세스가 반복된다. ARP에 대한 회신이 없을 때 프로세스가 종료되며, 이는 후보 IP 주소를 사용할 수 있음을 나타낸다.
링크-로컬 주소가 할당된 후 전역적으로 라우팅 가능한 주소 또는 사설 IP 주소를 사용할 수 있게 되면, 일반적으로 새로운 연결에는 새로운 주소를 선호해야 하지만 링크-로컬 주소를 통한 통신은 여전히 가능하다.(p. 2.6.1)
마이크로소프트는 이 주소 자동 구성 방법을 자동 사설 IP 주소 지정 (APIPA)이라고 부른다.
링크-로컬 주소 IPv6
인터넷 프로토콜 버전 6 (IPv6)에서 주소 블록 fe80::/10은 링크-로컬 유니캐스트 주소 지정을 위해 예약되어 있다.(p. 2.4) 링크-로컬 주소의 네트워크 구성 요소 64비트 중 최상위 10비트 (1111111010)는 IANA가 링크-로컬 주소를 위해 예약한 "글로벌 라우팅 프리픽스"에 해당하며, "서브넷 ID" (나머지 54비트)는 0이다.(p. 2.5.6)
IPv4와 달리 IPv6는 라우팅 가능한 주소도 할당된 경우에도 IPv6 프로토콜이 활성화된 모든 네트워크 인터페이스에 링크-로컬 주소가 필요하다.(p. 2.8) 결과적으로 IPv6 호스트는 일반적으로 IPv6가 활성화된 각 네트워크 인터페이스에 둘 이상의 IPv6 주소가 할당되어 있다. 링크-로컬 주소는 이웃 탐색 프로토콜의 IPv6 서브레이어 작업과 DHCPv6와 같은 다른 IPv6 기반 프로토콜에 필요하다.
링크-로컬 IPv6 주소를 사용하여 호스트에 연결할 때, 패킷이 올바른 인터페이스로 전송될 수 있도록 주소에 영역 인덱스를 추가해야 한다.
링크-로컬 주소 IPv6
IPv6에서는 주소가 무상태 (메모리 없음) 또는 상태 유지 (메모리 있음) 메커니즘에 의해 할당될 수 있다. IPv6 무상태 주소 자동 구성은 이웃 탐색 프로토콜 (NDP)의 구성 요소로 수행된다. 주소는 라우팅 프리픽스와 네트워크 인터페이스의 고유 식별자로부터 형성된다.
NDP 라우팅 프리픽스 광고를 통해 라우터 또는 서버 호스트는 모든 링크 연결 인터페이스에 구성 정보를 알릴 수 있으며, 이는 로컬 또는 전역 라우팅 목적을 위해 수신 인터페이스에 추가 IP 주소 할당을 유발한다. 이 프로세스는 프리픽스 서버가 호스트에 대한 개별 할당을 수신하거나 기록하지 않기 때문에 때때로 무상태로 간주된다. 고유성은 주소 선택 방법론에 의해 자동으로 보장된다. MAC 주소 기반일 수도 있고, 무작위일 수도 있다. 자동 중복 주소 감지 알고리즘은 할당 오류를 방지한다.
할당된 /8 IPv4 주소 블록 목록
일부 대규모 /8 블록의 IPv4 주소는 이전의 클래스 A 네트워크 블록으로, (IANA)를 통해 인터넷 할당 번호 관리 기관(ICANN) 또는 대륙별 인터넷 레지스트리에 의해 단일 조직 또는 관련 조직 그룹에 전체가 할당된다.
각 /8 블록에는 2563 = 224 = 16,777,216개의 주소가 포함되며, 이는 IP 주소의 마지막 세 가지 구분된 세그먼트의 전체 범위를 포함한다. 이는 256개의 /8 주소 블록이 전체 IPv4 공간에 들어맞는다는 것을 의미한다.
IPv4 주소 고갈이 마지막 단계로 접어들면서, 이전에는 36.0.0.0/8을 사용했던 스탠퍼드 대학교와 같은 일부 조직은 고갈 날짜를 늦추는 데 도움이 되도록 할당된 블록(이 경우 아태지역 네트워크 정보센터)을 반환했다.
할당된 /8 IPv4 주소 블록 목록 대륙별 인터넷 레지스트리에 할당된 /8 블록 목록
대륙별 인터넷 레지스트리 (RIR)는 전 세계 특정 지역 내에서 IP를 할당한다.
이 목록에는 모든 대륙별 인터넷 레지스트리 또는 국가 인터넷 레지스트리에 대한 현재 /8 블록 할당이 포함되지 않을 수 있다.
할당된 /8 IPv4 주소 블록 목록 원래 IPv4 할당 주소 블록 목록
원래 IPv4 주소 블록 목록은 1981년 9월에 발행되었다. 이전 버전의 문서에서 네트워크 번호는 IPv4에서 사용된 32비트 숫자가 아닌 8비트 숫자였다. 당시 이전에 나열되지 않았던 세 개의 네트워크(42.rrr.rrr.rrr, 43.rrr.rrr.rrr 및 44.rrr.rrr.rrr)가 추가되었다.
RFC 790의 관련 부분은 약간의 변경과 함께 여기에 재현되어 있다.
할당된 /8 IPv4 주소 블록 목록 원래 IPv4 할당 주소 블록 목록
000.rrr.rrr.rrr 예약됨 [JBP]
001.rrr.rrr.rrr BBN-PR BBN 패킷 라디오 네트워크 [DCA2]
002.rrr.rrr.rrr SF-PR-1 SF 패킷 라디오 네트워크 [JEM]
003.rrr.rrr.rrr BBN-RCC BBN RCC 네트워크 [SGC]
004.rrr.rrr.rrr 대서양 위성 네트워크 [DM11]
005.rrr.rrr.rrr SILL-PR 포트 실 패킷 라디오 네트워크[JEM]
006.rrr.rrr.rrr SF-PR-2 SF 패킷 라디오 네트워크 [JEM]
007.rrr.rrr.rrr CHAOS MIT CHAOS 네트워크 [MOON]
008.rrr.rrr.rrr CLARKNET 클락스버그용 SATNET 서브넷 [DM11]
009.rrr.rrr.rrr BRAGG-PR 포트 브래그 패킷 라디오 네트워크 [JEM]
010.rrr.rrr.rrr 아파넷 ARPANET [VGC]
011.rrr.rrr.rrr UCLNET 유니버시티 칼리지 런던 [PK]
012.rrr.rrr.rrr CYCLADES CYCLADES [VGC]
013.rrr.rrr.rrr 할당되지 않음 [JBP]
할당된 /8 IPv4 주소 블록 목록 원래 IPv4 할당 주소 블록 목록
014.rrr.rrr.rrr TELENET TELENET [VGC]
015.rrr.rrr.rrr EPSS 영국 우체국 EPSS [PK]
016.rrr.rrr.rrr DATAPAC DATAPAC [VGC]
017.rrr.rrr.rrr TRANSPAC TRANSPAC [VGC]
018.rrr.rrr.rrr LCSNET MIT LCS 네트워크 [DDC2]
019.rrr.rrr.rrr TYMNET TYMNET [VGC]
020.rrr.rrr.rrr DC-PR D.C. 패킷 라디오 네트워크 [VGC]
021.rrr.rrr.rrr EDN DCEC EDN [EC5]
022.rrr.rrr.rrr DIALNET DIALNET [MRC]
023.rrr.rrr.rrr MITRE MITRE 케이블넷 [APS]
024.rrr.rrr.rrr BBN-LOCAL BBN 로컬 네트워크 [SGC]
025.rrr.rrr.rrr RSRE-PPSN RSRE / PPSN [BD2]
026.rrr.rrr.rrr AUTODIN-II AUTODIN II [EC5]
027.rrr.rrr.rrr NOSC-LCCN NOSC / LCCN [KTP]
할당된 /8 IPv4 주소 블록 목록 원래 IPv4 할당 주소 블록 목록
028.rrr.rrr.rrr WIDEBAND 와이드 밴드 위성 네트워크 [CJW2]
029.rrr.rrr.rrr DCN-COMSAT COMSAT 분산 컴퓨팅 네트워크 [DLM1]
030.rrr.rrr.rrr DCN-UCL UCL 분산 컴퓨팅 네트워크 [PK]
031.rrr.rrr.rrr BBN-SAT-TEST BBN SATNET 테스트 네트워크 [DM11]
032.rrr.rrr.rrr UCL-CR1 UCL 캠브리지 링 1 [PK]
033.rrr.rrr.rrr UCL-CR2 UCL 캠브리지 링 2 [PK]
034.rrr.rrr.rrr MATNET 모바일 액세스 터미널 네트워크 [DM11]
035.rrr.rrr.rrr NULL UCL/RSRE 널 네트워크 [BD2]
036.rrr.rrr.rrr SU-NET 스탠퍼드 대학교 이더넷 [MRC]
037.rrr.rrr.rrr DECNET 디지털 이큅먼트 네트워크 [DRL]
038.rrr.rrr.rrr DECNET-TEST 테스트 디지털 이큅먼트 네트워크 [DRL]
039.rrr.rrr.rrr SRINET SRI 로컬 네트워크 [GEOF]
040.rrr.rrr.rrr CISLNET CISL 멀틱스 네트워크 [CH2]
041.rrr.rrr.rrr BBN-LN-TEST BBN 로컬 네트워크 테스트베드 [KTP]
042.rrr.rrr.rrr S1NET LLL-S1-NET [EAK]
043.rrr.rrr.rrr INTELPOST COMSAT 인텔포스트 [DLM1]
044.rrr.rrr.rrr AMPRNet 아마추어 무선 실험 네트워크 [HM]
할당된 /8 IPv4 주소 블록 목록 각주
역사적 IP 주소 목록:
“INTERNET PROTOCOL ADDRESS SPACE”. 인터넷 할당 번호 관리 기관 (IANA). October 2000. 2000년 10월 18일에 원본 문서에서 보존된 문서. 2011년 3월 27일에 확인함.  인터넷 아카이브 웨이백 머신을 통한 역사적 노트가 있는 IANA 테이블의 첫 번째 버전.
“Internet Protocol v4 Address Space”. 인터넷 할당 번호 관리 기관 (IANA). September 2007. 2007년 10월 28일에 원본 문서에서 보존된 문서. 2011년 3월 27일에 확인함.  인터넷 아카이브 웨이백 머신을 통한 역사적 노트가 있는 IANA 테이블의 마지막 버전.
Turtschi, Adrian (1999년 9월 13일). “Complete List of Class A and Class B Networks”. Adrian Turtschi. 2011년 3월 27일에 확인함.
할당된 /8 IPv4 주소 블록 목록 각주
Rogers, Paul (November 1999). “IP INDEX Encyclopedia”. flumps.org. 2001년 4월 14일에 원본 문서에서 보존된 문서. 2011년 3월 27일에 확인함. 
“IPv4 Addresses – the Complete Class A List”. Infocellar. 2003년 4월 5일. 2011년 4월 17일에 원본 문서에서 보존된 문서. 2011년 3월 27일에 확인함. 
“INTERNET PROTOCOL V4 ADDRESS SPACE”. DonkBoy Internet. 2005년 6월 30일. 2011년 3월 27일에 확인함. 
Cromwell, Bob (2008년 11월 13일). “The /8 or Class A Networks”. Bob Cromwell. 2010년 12월 17일에 원본 문서에서 보존된 문서. 2011년 3월 27일에 확인함.
캐리어급 NAT
캐리어급 NAT(Carrier-grade NAT, CGN 또는 CGNAT)은 대규모 NAT(large-scale NAT, LSN)으로도 알려져 있으며, IPv4 네트워크 설계에서 ISP가 사용하는 네트워크 주소 변환 (NAT) 유형이다. CGNAT를 사용하면 최종 사이트, 특히 주거용 네트워크는 네트워크 운영자의 네트워크에 내장된 미들박스 네트워크 주소 변환기 장치에 의해 사설망 주소로 구성되며, 이는 공용 IPv4 주소로 변환되어 많은 최종 사용자 간에 소규모 공용 주소 풀을 공유할 수 있도록 한다. 이는 기본적으로 ISP 수준에서 기존의 고객 구내 NAT 기능을 반복한다.
캐리어급 NAT는 IPv4 주소 고갈을 완화하는 데 자주 사용된다.
CGN의 한 사용 시나리오는 NAT444로 불리는데, 이는 공용 인터넷의 인터넷 서비스에 대한 일부 고객 연결이 고객의 사설망, 통신사의 사설망, 공용 인터넷이라는 세 가지 다른 IPv4 주소 지정 도메인을 통과하기 때문이다.
캐리어급 NAT
또 다른 CGN 시나리오는 듀얼 스택 라이트(Dual-Stack Lite)로, 통신사 네트워크가 IPv6를 사용하므로 두 개의 IPv4 주소 지정 도메인만 필요하다.
CGNAT 기술은 2000년에 모바일 네트워크의 GPRS 배포에서 대량의 IPv4 주소에 대한 즉각적인 요구를 수용하기 위해 처음 사용되었다. CGNAT 배포는 2014년 1,200개에서 2016년 3,400개로 증가했으며, 연구된 배포의 28.85%가 모바일 운영자 네트워크에 나타났다.
캐리어급 NAT 공유 주소 공간
ISP가 CGN을 배포하고 RFC 1918 주소 공간을 사용하여 고객 게이트웨이에 번호를 매기면 고객 네트워크가 이미 RFC 1918 주소 공간을 사용하는 경우 주소 충돌 및 라우팅 실패의 위험이 발생한다.
이로 인해 일부 ISP는 ARIN 내에서 CGN을 위한 새로운 사설 주소 공간을 할당하는 정책을 개발하게 되었지만, ARIN은 이 문제가 일반적인 할당 문제가 아니라 기술적 목적(RFC 2860에 따름)을 위한 주소 예약이라고 지적하며 정책을 구현하기 전에 IETF에 위임했다.
IETF는 RFC 6598을 발표하여, ISP CGN 배포에서 인바운드 및 아웃바운드 인터페이스 모두에서 동일한 네트워크 접두사가 발생하는 것을 처리할 수 있는 공유 주소 공간을 자세히 설명했다. ARIN은 이 할당을 위해 인터넷 할당 번호 관리기관에 주소 공간을 반환했다. 할당된 주소 블록은 100.64.0.0/10, 즉 100.64.0.0부터 100.127.255.255까지의 IP 주소이다.
캐리어급 NAT 공유 주소 공간
IPv4 주소가 공용인지 여부를 평가하는 장치는 새로운 주소 공간을 인식하도록 업데이트되어야 한다. NAT 장치에 더 많은 사설 IPv4 주소 공간을 할당하는 것은 IPv6로 전환할 필요성을 늦출 수 있다.
캐리어급 NAT 단점
캐리어급 NAT의 비판자들은 다음과 같은 측면을 주장한다:
일반적으로 ISP 고객이 포트 포워딩을 사용하는 것을 방지한다. NAT는 일반적으로 네트워크의 NAT 장치 포트를 외부 인터페이스의 다른 포트에 매핑하여 구현되기 때문이다. 이는 라우터가 응답을 올바른 장치에 매핑할 수 있도록 하기 위함인데, 캐리어급 NAT 네트워크에서는 소비자 측의 라우터가 포트 포워딩을 위해 구성되어 있더라도 CGN을 실행하는 ISP의 "마스터 라우터"가 실제 포트가 소비자가 구성한 포트가 아니므로 이 포트 포워딩을 차단한다. 이전 단점을 극복하기 위해 포트 제어 프로토콜 (PCP)은 RFC 6887에서 표준화되었다.
IP 주소를 기반으로 트래픽을 차단하는 경우, 시스템은 스팸 사용자 IP 주소를 차단하여 스팸 사용자의 트래픽을 차단할 수 있다. 이 사용자가 캐리어급 NAT 뒤에 있다면 스패머와 동일한 공용 주소를 공유하는 다른 사용자들도 의도치 않게 차단될 수 있다. 이는 합법적인 사용자와 IP 주소를 공유하는 단일 악성 사용자의 방해 행위를 처리하려는 포럼 및 위키 관리자에게 문제를 일으킬 수 있다.
캐리어급 NAT 단점
스트리밍 서비스는 CG-NAT 활동을 VPN 또는 계정 공유 트래픽과 동일하게 볼 수 있다. 이러한 서비스는 서비스 약관 위반을 이유로 VPN 사용자를 차단하거나 금지하는 경우가 많다. 이는 사용자가 더 저렴한 지역에서 콘텐츠에 접근하여 서비스 비용을 줄이려 한다는 가정하에 이루어지며, 계정 공유 트래픽은 여러 개의 독립적인 가구 또는 사용자가 하나의 로그인 비용으로 콘텐츠에 접근하는 것을 차단하기 위함이다.
IPv6 신속 배포
6rd는 인터넷 서비스 제공자(ISP)의 IPv4 인프라에서 IPv6 신속 배포(IPv6 rapid deployment)를 용이하게 하는 메커니즘이다.
이 프로토콜은 IPv4 네트워크를 통해 IPv6 패킷을 전송하는 기존 메커니즘인 6to4에서 파생되었으며, 최종 사용자의 ISP 네트워크 내에서 전적으로 작동하여 6to4 설계에 내재된 주요 아키텍처 문제를 피한다는 중요한 변경 사항이 있다. 6rd라는 이름은 IPv6의 신속한 배포를 가능하게 하는 것과 비공식적으로 발명가인 레미 데프레의 이니셜(RD)을 모두 참조한다.
6rd 원칙과 ISP 프리에 의한 첫 번째 적용에 대한 설명은 RFC 5569에 게시되어 있다. 국제 인터넷 표준화 기구에서 인터넷 표준화를 위해 준비된 6rd 사양은 RFC 5969로 제공된다.
IPv6 신속 배포 역사
2007년 11월, 1970년대 프랑스의 트랜스팩 데이터 네트워크 창시자 중 한 명이었던 레미 데프레는 프랑스에서 두 번째로 큰 ISP인 프리에 자신이 발명한 6rd 메커니즘을 사용하여 IPv6를 신속하게 배포할 것을 제안했다. 당시 프리에는 IPv6 서비스를 제공할 단기 계획이 없었지만, 프리의 CTO인 라니 아사프는 즉시 이 솔루션을 구현하기로 결정했다. 5주 후, 적절한 마케팅 승인 및 운영 검증을 거쳐 프리 고객에게 IPv6가 제공된다는 보도 자료가 발표되었다.
6rd 메커니즘과 프리의 배포를 설명하는 첫 번째 초안은 2008년 2월 9일 국제 인터넷 표준화 기구에 제출되었다. 개선 후 2010년 1월 24일에 정보 제공용 RFC 5569로 게시되었다.
2010년 3월, 국제 인터넷 표준화 기구의 워킹 그룹은 6rd에 대한 최신 초안이 추가 수정 후 표준 트랙 RFC가 되어야 한다고 승인했다. 2010년 8월, 표준 트랙 RFC 5969가 게시되었다.
2010년 10월, 컴캐스트는 홈 게이트웨이 장치용 6rd 소프트웨어를 오픈 소스로 무료로 제공했다.
IPv6 신속 배포 6to4와의 비교
6to4는 기본 IPv6와 IPv4 간의 트래픽을 중계 서버를 사용하여 중계한다. 이 중계 서버는 중계 서비스를 제공할 준비가 된 네트워크에 공통 IPv4 및 IPv6 프리픽스를 광고하지만, 모든 기본 IPv6 호스트가 이러한 중계기로 향하는 작동 경로를 가지고 있다는 보장은 없다. 이 때문에 6to4 호스트는 모든 기본 IPv6 호스트에서 도달할 수 있다는 보장이 없다. 중계기가 사용 가능하더라도 종종 트래픽 증가에 따라 좋은 서비스 품질을 유지할 의무가 없는 제3자에 의해 운영된다. 6rd는 각 ISP가 6to4에 대해 표준화된 특별한 2002::/16 프리픽스 대신 자체 IPv6 프리픽스 중 하나를 사용하도록 하여 이 모델을 변경한다. 따라서 공급자는 자사의 6rd 호스트가 IPv6 네트워크에 도달할 수 있는 모든 기본 IPv6 호스트에서 도달할 수 있도록 보장한다. 중계기는 ISP의 완전한 통제하에 있으므로 고객에 대한 서비스 품질에 대한 전적인 책임을 유지한다.
6rd 중계기는 동일한 관리 엔터티의 통제하에 있는 제한된 호스트 집합에 의해서만 사용될 수 있으므로 6to4에서 가능한 트래픽 익명화 공격의 범위도 줄어든다.
IPv6 신속 배포 주소 공간 소모
전체 IPv4 주소 공간을 매핑하기 위해 32비트의 IPv6 주소 공간을 사용하는 가장 간단한 6rd 배포는 모든 ISP 라우터에서 기본적으로 IPv6가 지원되는 경우보다 더 많은 주소 공간을 소모한다. 이는 IPv4 주소 공간의 중복 부분을 생략하고, 경우에 따라 여러 6rd 도메인을 배포함으로써 완화될 수 있다.
대륙별 인터넷 레지스트리(RIR)에 의한 IPv6 공간의 기본 할당은 32비트 프리픽스이다. 6rd를 사용하여 IPv4 주소를 매핑하는 데 32비트가 걸리므로, 이는 ISP가 전체 IPv4 주소를 사용하려면 고객에게 64비트 IPv6 프리픽스만 할당할 수 있음을 의미한다. 그러나 6rd는 IPv4 주소의 중복 부분을 버릴 수 있도록 허용한다. 예를 들어, ISP가 고객에게 발행하는 IPv4 주소들이 모두 처음 18비트를 공유하는 경우, 6rd 프리픽스는 나머지 14비트만 포함하면 된다. 이러한 유연성 없이 프리는 원래 고객에게 64비트 IPv6 프리픽스를 할당했지만, RIPE NCC로부터 더 큰 IPv6 공간 할당(26비트 프리픽스)을 받은 후 더 짧은 프리픽스를 할당할 수 있었다.
IPv6 신속 배포 현재 사용
컴캐스트는 2010년 1월에 2010년 2분기에 6rd를 사용하는 시험을 발표했다. 그들은 2010년 6월 30일에 6RD 시험을 시작했으며, 2010년 7월에는 수백 명의 사용자에게 확대될 것으로 예상되었다. 그러나 6rd는 컴캐스트의 주요 IPv6 전략이 될 것으로 예상되지 않았다. 컴캐스트는 6rd와 함께 2개의 다른 홈 게이트웨이를 테스트했으며, 그 중 하나는 오픈 소스로 제공되었다. 또한, 그들은 6rd 경계 중계기를 사용하고자 하는 네트워크 사용자를 위해 6rd 구성 지침을 게시했다. 컴캐스트는 듀얼 스택의 더 광범위한 배포를 예상하여 2011년 6월 30일에 6rd 서비스를 비활성화할 계획이었다.
2011년 12월, 네덜란드 ISP 텔포트는 6rd를 기반으로 한 IPv6 사전 파일럿을 시작하여 고객을 참여하도록 초대한다고 발표했다. 2013년 1월 현재, 6rd는 모든 텔포트 유선 (ADSL 및 VDSL) 고객에게 옵트인으로 공개되었다. "옵트인"은 고객이 IPv6 연결을 얻기 위해 텔포트 Zyxel 모뎀에서 6RD를 활성화해야 함을 의미한다. 그러나 이 파일럿은 모회사 KPN이 2019년에 텔포트 자회사를 폐쇄하면서 중단되었다.
세계 IPv6의 날
세계 IPv6의 날(World IPv6 Day)은 2011년에 인터넷 협회와 여러 대형 인터넷 콘텐츠 서비스가 주최하고 조직한 기술 테스트 및 홍보 행사로, 공개 IPv6 배포를 테스트하고 홍보하는 데 목적이 있었다. 2011년 테스트 날의 성공에 이어, 인터넷 협회는 2012년 6월 6일에 세계 IPv6 런칭의 날(World IPv6 Launch Day)을 개최했다. 이 행사는 단순히 테스트 날이 아니라, 참가자들의 제품과 서비스에 IPv6를 영구적으로 활성화하는 것을 목표로 했다.
세계 IPv6의 날 세계 IPv6의 날
세계 IPv6의 날은 2011년 1월 12일에 페이스북, 구글, 야후!, 아카마이 테크놀로지스, 라임라이트 네트워크 등 5개 주요 기업과 함께 발표되었다. 이 행사는 2011년 6월 8일 UTC 00:00에 시작하여 같은 날 23:59에 종료되었다. 이 행사의 주요 동기는 다양한 합성 테스트에서 나타난 IPv6 고장의 실제 영향을 평가하는 것이었다. 이를 위해 세계 IPv6의 날 동안 주요 웹 기업 및 기타 산업 플레이어들은 24시간 동안 자사의 주요 웹사이트에서 IPv6를 활성화했다. 추가 목표는 인터넷 서비스 제공업체, 하드웨어 제조업체, 운영 체제 공급업체 및 웹 기업과 같은 산업 전반의 조직들이 IPv6를 위한 서비스를 준비하도록 동기를 부여하여, IPv4 주소 공간이 고갈됨에 따라 IPv4에서 성공적인 전환을 보장하는 것이었다.
세계 IPv6의 날 세계 IPv6의 날
이 테스트는 주로 웹사이트가 AAAA 레코드를 발행하여 IPv6를 지원하는 호스트가 IPv6를 사용하여 연결할 수 있도록 하는 것으로 구성되었다. 인터넷 서비스 제공자(ISP)들은 참여를 권장받았지만, 그날 어떤 활동적인 것을 배포할 것으로 예상되지 않았고, 단지 지원 문제를 처리할 준비를 강화하는 것이었다. 이 개념은 2010년 구글 IPv6 컨퍼런스에서 광범위하게 논의되었다.
가장 큰 검색 엔진, 소셜 네트워킹 웹사이트, 인터넷 백본 및 콘텐츠 전송 네트워크를 포함한 많은 회사와 조직이 이 실험에 참여했다.
초기 세계 IPv6의 날에는 400개 이상의 참가자가 있었으며, 여기에는 인터넷에서 가장 많이 접속되는 일부 목적지, 콘텐츠 전송 네트워크뿐만 아니라 다음과 같은 다양한 인터넷 서비스 및 인프라 제공업체도 포함되었다. 컴캐스트, 구글, 야후!, 페이스북, 얀덱스 유튜브, 아카마이 테크놀로지스, 라임라이트 네트워크, 마이크로소프트, 보니지, AOL, 맵퀘스트, T-온라인, 시스코 시스템즈, 주니퍼 네트웍스, 화웨이, NTP 풀, 미국 상무부, 마스터카드, 영국방송공사, 텔멕스.
세계 IPv6의 날 세계 IPv6의 날
주요 통신사들은 모든 인터넷 트래픽 중 IPv6 트래픽의 비율이 기본 및 터널링 스택을 합쳐 0.024%에서 0.041%로 증가했다고 측정했다.
소비자 접속 네트워크의 대부분의 IPv6 트래픽은 구글 사이트로 향했다. 콘텐츠 사이트가 성공을 위해 IPv6를 채택해야 할 필요성을 보여주듯이, 가장 큰 증가는 실제로 6to4 전환 기술에서 나타났다.
초기 결과에 따르면, 그 날은 계획대로 진행되었고 참가자들에게 심각한 문제는 없었다.
시스코 시스템즈와 구글은 테스트 동안 심각한 문제가 없었다고 보고했다. 페이스북은 결과를 고무적이라고 평가했으며, 그 결과 개발자 사이트에 IPv6를 활성화한 상태로 유지하기로 결정했다. 그러나 IPv6가 일관되게 적용되기 전에 더 많은 작업이 필요하다는 것이 일반적인 의견이었다.
참가자들은 데이터에 대한 상세한 분석을 계속 수행할 것이라고 말했다. 많은 참가자들이 듀얼 스택을 계속 유지하는 것이 가치 있다고 여겼다.
세계 IPv6의 날 세계 IPv6 런칭
초기 세계 IPv6의 날의 성공에 이어, 2012년 6월 6일 세계 IPv6 런칭으로 행사가 반복되었으며, 이번에는 모든 참여 사이트에 IPv6를 영구적으로 활성화하는 것을 목표로 했다. 이 행사는 "이번에는 진짜다"라고 홍보되었다.
세계 IPv6 런칭 참가자에는 2011년 테스트 날의 참가자들과 더 많은 기업이 포함되었으며, 위키미디어 재단도 위키백과를 포함한 자사 사이트에 IPv6를 영구적으로 활성화했다.
시스코의 알랭 피오코에 따르면, 현재 전 세계 월드 와이드 웹 IPv4 페이지뷰의 약 30%를 차지하는 콘텐츠는 세계 IPv6 런칭의 날 이후 IPv6를 통해 접근 가능하게 되었다고 한다. AMS-IX의 IPv6 트래픽은 런칭 날 50% 증가하여 2 Gbit/s에서 3 Gbit/s로 늘었다. 암스테르담 인터넷 익스체인지의 IPv6 트래픽은 이더 타입 분포에 따라 0.4%로 측정되었으며, IPv4는 일별 및 주별 그래프 모두에서 평균 99.6%로 측정되었다.
IPv6 전환 메커니즘
IPv6 전환 메커니즘(IPv6 transition mechanism)은 1983년부터 사용된 인터넷 프로토콜 버전 4(IPv4) 인프라에서 후속 주소 지정 및 라우팅 시스템인 인터넷 프로토콜 버전 6(IPv6)으로 인터넷 전환을 용이하게 하는 기술이다. IPv4 및 IPv6 네트워크는 직접적으로 상호 운용되지 않으므로, 전환 기술은 두 네트워크 유형의 호스트가 다른 모든 호스트와 통신할 수 있도록 설계되었다.
기술적 기준을 충족하기 위해 IPv6는 현재의 IPv4로부터 간단한 전환 계획을 가져야 한다. 국제 인터넷 표준화 기구(IETF)는 인터넷 드래프트와 Request for Comments 프로세스를 통해 워킹 그룹과 논의를 진행하여 이러한 전환 기술을 개발하고 있다. 일부 기본 IPv6 전환 메커니즘은 RFC 4213에 정의되어 있다.
IPv6 전환 메커니즘 스테이트리스 IP/ICMP 변환
스테이트리스 IP/ICMP 변환 (SIIT)은 IPv6와 IPv4의 패킷 헤더 형식 간을 변환한다. SIIT 방식은 IPv4 변환 주소라고 불리는 IPv6 주소 클래스를 정의한다. 이들은 접두사 ::ffff:0:0:0/96을 가지며 ::ffff:0:a.b.c.d로 작성될 수 있으며, 여기서 IPv4 형식 주소 a.b.c.d는 IPv6 지원 노드를 나타낸다. 이 접두사는 전송 프로토콜 헤더 체크섬 변경을 피하기 위해 0 값의 체크섬을 생성하도록 선택되었다.
이 알고리즘은 영구적으로 할당된 IPv4 주소가 없는 IPv6 호스트가 IPv4 전용 호스트와 통신할 수 있도록 하는 솔루션에 사용될 수 있다. 주소 할당 및 라우팅 세부 사항은 사양에서 다루지 않는다. SIIT는 스테이트리스 네트워크 주소 변환의 특수한 경우로 볼 수 있다.
이 사양은 NGTRANS IETF 워킹 그룹의 산물이며, 2000년 2월 썬 마이크로시스템즈의 E. Nordmark에 의해 처음 작성되었다. 2011년에 개정되었고, 2016년에 현재 개정판이 발표되었다.
IPv6 전환 메커니즘 터널 브로커
터널 브로커는 IPv4 인터넷 전송 링크에서 IPv6 트래픽을 캡슐화하여 IPv6 연결을 제공하며, 일반적으로 6in4를 사용한다. 이는 IPv4 인터넷 내에 IPv6 터널을 설정한다. 터널은 터널 설정 프로토콜(TSP) 또는 AYIYA를 통해 관리될 수 있다.
IPv6 전환 메커니즘 6rd
6rd는 레미 데프레스가 개발했다. 이는 ISP의 IPv4 인프라를 통해 IPv6 서비스를 신속하게 배포하는 것을 용이하게 하는 메커니즘이다. IPv4와 IPv6 주소 간의 스테이트리스 주소 매핑을 사용하며, IPv4 패킷과 동일하게 고객 노드 간에 최적화된 경로를 따르는 자동 터널을 통해 IPv6 패킷을 전송한다.
2007년에 네이티브 주소를 사용하는 IPv6 서비스의 초기 대규모 배포에 사용되었다 (RFC 5569). 프로토콜의 표준-트랙 사양은 RFC 5969에 있다.
IPv6 전환 메커니즘 전송 릴레이 변환
전송 릴레이 변환 (TRT) 방식은 두 호스트 사이의 중간 장치 역할을 한다. 변환기의 기능은 IPv6 주소를 IPv4 주소로 변환하고 그 반대로도 변환하는 것이다. TRT는 IP 주소 매핑과 사용자 지정 IP 주소를 통해 이 변환을 수행한다.
예를 들어, IPv6 주소(fec0:0:0:1::/64)에서 IPv4 주소(10.1.1.1)로 패킷이 전송될 경우, 주소는 fec0:0:0:1::10.1.1.1로 읽힌다. 패킷은 먼저 IPv6/TCP 프로토콜을 통해 변환기로 라우팅된 다음, 변환기에서 IPv4/TCP 프로토콜을 통해 IPv4 호스트로 라우팅된다.
TRT는 DNS ALG로 알려진 AAAA 레코드와 A 레코드 간의 DNS 변환과 유사한 작업을 사용한다.
IPv6 전환 메커니즘 NAT64
NAT64는 IPv6 호스트가 IPv4 서버와 통신할 수 있도록 하는 메커니즘이다. NAT64 서버는 최소한 하나의 IPv4 주소와 32비트의 IPv6 네트워크 세그먼트(예: 64:ff9b::/96)의 종단점이다. IPv6 클라이언트는 이러한 비트를 사용하여 통신하려는 IPv4 주소를 내장하고, 결과 주소로 패킷을 보낸다. 그러면 NAT64 서버는 IPv6 주소와 IPv4 주소 사이에 NAT 매핑을 생성하여 통신할 수 있도록 한다.
IPv6 전환 메커니즘 DNS64
DNS64는 도메인의 AAAA 레코드를 요청받았을 때, A 레코드만 찾으면 A 레코드로부터 AAAA 레코드를 합성하는 DNS 서버를 설명한다. 합성된 IPv6 주소의 첫 번째 부분은 IPv6/IPv4 변환기를 가리키고, 두 번째 부분은 A 레코드의 IPv4 주소를 내장한다. 해당 변환기는 일반적으로 NAT64 서버이다. DNS64의 표준-트랙 사양은 RFC 6147에 있다.
이 전환 메커니즘에는 두 가지 주목할 만한 문제가 있다.
구현
IPv6 전환 메커니즘 ISATAP
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)은 IPv4 네트워크 위에 듀얼 스택 노드 간에 IPv6 패킷을 전송하기 위한 IPv6 전환 메커니즘이다.
6over4(IPv4 멀티캐스트를 사용하는 이전 유사 프로토콜)와 달리, ISATAP은 IPv4를 가상 비방송 다중 접근 네트워크(NBMA) 데이터 링크 계층으로 사용하므로 기본 IPv4 네트워크 인프라가 멀티캐스트를 지원할 필요가 없다.