DNS를 사용하여 전 세계 IPv6 채택 현황 추정하기

하나의 장치에서 적절한 이름의 인터넷 프로토콜(IP)을 사용하여 인터넷에서 다른 장치와 통신하려면 먼저 고유한 숫자 주소가 할당되어야 합니다. 이 주소의 모습은 사용 중인 IP 버전에 따라 IPv4 또는 IPv6일 수 있습니다.

IPv4는 1983년에 처음 배포되었습니다. IPv4는 현대 인터넷을 탄생시킨 IP 버전으로, 오늘날에도 여전히 지배적인 위치를 차지하고 있습니다. IPv6는 1998년 초까지 거슬러 올라갈 수 있지만, 지난 10년 동안에야 심층 방어가 크게 주목받기 시작했으며, 보고하는 사람과 측정 대상 및 방법에 따라 1% 미만에서 30~40%까지 증가했습니다.

연결된 장치의 개수가 사용 가능한 IPv4 주소의 수를 훨씬 초과하고 비용이 상승하는 상황에서, IPv6가 훨씬 더 넓은 주소 공간을 제공하므로 IPv6는 지금쯤 지배적인 프로토콜이 되었어야 합니다. 하지만 잠시 후 살펴보겠지만, 현실은 그렇지 않습니다.

Cloudflare에서는 여러 해 동안 IPv6를 강력하게 지지해 왔으며, Cloudflare Radar를 통해 인터넷 전반의 IPv6 채택을 면밀히 추적해 왔습니다. 이제 3년이 된 Radar는 비교적 최근에 출시된 플랫폼입니다. 시간을 더 거슬러 올라가서 APNIC1의 친구들(5개의 지역 인터넷 레지스트리(RIR) 중 하나)을 잠시 살펴볼 수 있습니다. 2012년으로 거슬러 올라가는 그들의 데이터를 통해 IPv6는 2017년 중반까지 기하급수적으로 성장한 것처럼 보이는 시기를 경험했으며, 그 이후에는 선형적인 성장기에 접어들어 여전히 성장 중이라는 것을 알 수 있습니다.

두 프로토콜 간의 호환성 부족(장치에 IPv4 및 IPv6 주소를 모두 할당해야 함)과 인터넷의 거의 모든 장치가 여전히 IPv4를 지원한다는 사실로 인해 IPv6 채택이 더디게 진행되고 있습니다. 그럼에도 불구하고 IPv6는 인터넷의 미래를 위해 매우 중요하며 배포를 늘리기 위한 지속적인 노력이 필요합니다.

APNIC 및 오늘날 대부분의 다른 출처와 마찬가지로, Cloudflare Radar에서는 주로 인터넷 서비스 공급자(ISP)가 IPv6를 배포한 정도, 즉 _클라이언트 측_을 반영하는 수치를 발표합니다. 이는 매우 중요한 관점이며 최종 사용자에게 직접적인 영향을 미치지만, 상황의 다른 쪽 끝인 _서버 측_도 있습니다.

이를 염두에 두고 Cloudflare에서는 서버 측의 IPv6 채택과 클라이언트가 실제로(또는 가능성이 있는) IPv6를 통해 서버와 통신하는 빈도를 엿볼 수 있는 간단한 실험에 여러분을 초대합니다. 우리는 이 탐색을 위해 DNS에 의존할 것이며, 그 결과는, 그들의 말에 따르면, 여러분을 놀라게 할 것입니다.

2023년 10월 말까지 Cloudflare의 관점에서 볼 때, 인터넷 전체에서 IPv6 채택률은 시간대와 요일에 따라 약간의 차이가 있지만, 전체 트래픽의 약 **36%**에 달했습니다. 봇을 제외하면 이 수치는 46%를 조금 넘는 수준으로 올라가고, 사람을 제외하면 24%에 가깝게 떨어집니다. 이 수치는 모든 IPv6 지원 콘텐츠(기본 설정)에 걸쳐 IPv6를 통해 제공되는 HTTP 요청의 점유율을 나타냅니다.

이 연습에서 가장 중요한 것은 인간 및 봇 모두의 수입니다. 사용되는 수많은 클라이언트 소프트웨어의 다양한 IPv6 지원 수준, 트래픽이 발생하는 수많은 네트워크 내부의 다양한 IPv6 배포 수준, 네트워크의 다양한 크기 등 두 종류의 트래픽 간에 채택 격차가 발생하는 데는 여러 가지 이유가 있지만, 이는 또 다른 복잡한 상황입니다. 특정 국가 또는 네트워크에 대한 수치가 궁금하다면Cloudflare Radar와 2023년 연례 검토 보고서에서 확인할 수 있습니다 .

독자 여러분은 클라이언트-서버 상황의 클라이언트 측을 측정하는 것은 이야기의 절반만 들려준다고 지적할 수 있습니다. IPv6 지원 클라이언트가 IPv6를 통해 서버와 연결을 설정하려면 서버도 IPv6를 지원해야 하기 때문입니다.

여기서 두 가지 의문이 생깁니다.

1. 서버 측에서는 IPv6를 어느 정도로 채택했을까요?

2. 클라이언트 측의 IPv6 채택이 서버 측의 채택과 얼마나 잘 일치할까요?

사용자, 장치, 전송된 바이트 등 어떤 것에 대해 이야기하는 것인지에 따라 가능한 답변이 몇 가지 있습니다. 여기서는 _연결_에 초점을 맞추고(잠시 후에 그 이유를 설명하겠습니다), 이 두 가지를 결합하여 다음과 같이 질문하겠습니다.

일반적인 사용 패턴에서 IPv6 지원 클라이언트가 인터넷의 서버에 연결할 때 IPv6를 얼마나 자주 사용할 수 있을까요?

일반적인 사용 패턴으로는 하루 중 특정 웹 사이트를 다른 웹 사이트보다 더 자주 방문하는 사람이나 API를 호출하는 자동화된 클라이언트가 있습니다. 이러한 관점을 얻기 위해 DNS를 살펴보겠습니다.

클라이언트가 기존 IPv4 프로토콜이나 최신 IPv6를 사용하여 이름으로 서버와 연결을 시도하려면 먼저 인터넷 전화번호부인 도메인 네임 시스템(DNS)에서 서버의 IP 주소를 조회해야 합니다.

DNS에서 호스트 이름을 조회하는 것은 재귀적인 프로세스입니다. 서버의 IP 주소를 찾으려면 도메인 계층 구조(점으로 구분된 서버 이름의 구성 요소)를 따라 여러 DNS 권한 있는 서버 중 하나가 원하는 응답을 반환할 때까지 여러 서버를 거쳐야 합니다2. 그러나 대부분의 클라이언트는 이 작업을 직접 수행하지 않고 대신 재귀 확인자라고 하는 중개 서버에 이 작업을 수행하도록 요청합니다. Cloudflare에서는 누구나 사용할 수 있는 이러한 재귀 확인자 1.1.1.1을 운영합니다.

간소화된 예를 들면, 클라이언트가 1.1.1.1에 "www.example.com"의 IP 주소를 요청하면, 1.1.1.1은 나가서 DNS 루트 서버3에 ".com"에 대해 문의한 다음, .com DNS 서버에 "example.com"에 대해 문의하고, 마지막으로 "www.example.com"에 대해 직접 알고 있고 IP 주소로 응답하는 example.com DNS 서버에 "www.example.com"에 대해 문의합니다. 1.1.1.1은 다음 클라이언트가 비슷한 질문을 할 때 더 빠르게 처리할 수 있도록 최종 답변과 그 사이의 단계를 모두 캐시(잠시 동안 기억)합니다.

이는 1.1.1.1이 관찰 가능한 인터넷의 대부분을 포괄하여 클라이언트가 IPv4 주소를 조회하는 빈도(A 유형 쿼리)와 대비하여 IPv6 주소를 조회하는 빈도(AAAA 유형 쿼리)를 계산하기에 매우 좋은 위치에 있음을 의미합니다.

그렇다면 클라이언트는 언제 서버의 IPv4 주소를 요청할지, 아니면 IPv6 주소를 요청할지 어떻게 알 수 있을까요?

간단히 말하자면, IPv6를 사용할 수 있는 클라이언트는 연결하려는 모든 서버에 대해 별도의 A와 AAAA 조회를 수행하여 두 가지를 모두 요청합니다. 이러한 IPv6를 사용할 수 있는 클라이언트는 비어 있지 않은 AAAA 응답을 받으면 비어 있지 않은 A 응답도 받는지 여부와 관계없이(나중에 살펴보겠지만 거의 항상 받습니다) IPv6를 통한 연결을 우선시합니다. 자세한 내용을 알고 싶은 분을 위해 알려드리자면, 이러한 선호를 유도하는 알고리즘을 Happy Eyeballs라고 합니다.

이제 실제 데이터를 살펴볼 준비가 되었습니다...

첫 번째 단계는 1.1.1.1의 관점에서 클라이언트 IPv6 배포를 측정하고 이를 HTTP 요청의 수치와 비교하여 기준선을 설정하는 것입니다.

클라이언트가 IPv6를 사용하여 1.1.1.1에 연결하는 빈도를 세고 싶은 유혹이 들지만, 몇 가지 이유로 인해 그 결과가 오해의 소지가 있으며, 가장 큰 이유는 눈에 잘 띄지 않는다는 점입니다. 1.1.1.1은 클라이언트가 1.1.1.1 서비스를 통해 DNS 조회를 수행하는 데 사용할 수 있는 IPv4 및 IPv6 주소 집합 중 가장 기억에 남는 주소입니다. 1.1.1.1을 재귀 확인자로 사용하며 IPv6를 사용할 수 있는 클라이언트는 처음 두 개뿐 아니라 다음 네 개의 IP 주소를 모두 구성하는 것이 이상적입니다.

• 1.1.1.1 (IPv4)

• 1.0.0.1 (IPv4)

• 2606:4700:4700::1111 (IPv6)

• 2606:4700:4700::1001 (IPv6)

그러나 수동 구성이 필요한 경우4, 사람들은 IPv6 주소가 IPv4 주소보다 기억하기 어렵고 IPv4 주소로도 충분하다고 생각하여 IPv6 주소를 구성할 가능성이 낮습니다.

관련이 있지만 덜 분명한 혼란 요인은 많은 IPv6 사용 가능 클라이언트가 1.1.1.1의 IPv6 주소가 구성되어 있어도 여전히 IPv4를 통해 DNS 조회를 수행한다는 점입니다. 사용 가능한 주소에 대한 조회 확산이 인기 있는 기본 옵션이기 때문입니다.

DNS 클라이언트 활동에서 IPv6 채택을 평가하는 더 합리적인 접근 방식은 앞서 언급한 대로 IPv6 클라이언트가 항상 두 가지를 모두5 수행한다고 가정하고 A 유형 쿼리 총량에 대한 AAAA 유형 쿼리의 비율을 계산하는 것입니다.

그러면, 1.1.1.1의 관점에서 볼 때 클라이언트 측의 IPv6 채택률은 쿼리 양 기준으로 **30.5%**로 추정됩니다. 이는 같은 기간 동안 HTTP 트래픽에서 관찰한 수치(35.9%)에 약간 못 미치지만, 서로 다른 두 관점 간의 이러한 차이는 예상치 못한 것은 아닙니다.

DNS 응답을 캐시하는 것은 재귀 확인자뿐만 아닙니다. 대부분의 DNS 클라이언트에도 자체 로컬 캐시가 있습니다. 웹 브라우저, 운영 체제, 심지어 가정용 라우터에서도 후속 쿼리 속도를 높이기 위해 답변을 계속 유지합니다.

각 답변이 캐시에 얼마나 오래 남아 있는지는 DNS 레코드와 함께 다시 전송되는 Time To Live(TTL) 필드에 따라 달라집니다. DNS에 익숙한 분은 A 레코드와 AAAA 레코드의 TTL이 비슷한지 궁금할 수 있습니다. 비슷하지 않다면(클라이언트 수준에서 더 오래 캐시되기 때문에) 이 두 가지 유형 중 하나에 대한 쿼리가 더 적게 발생하여 결과 채택 수치가 편향될 수 있습니다.

이 원 그래프는 A 및 AAAA 쿼리에 대한 응답으로 1.1.1.1에서 다시 전송된 최소 TTL을 세분화한 것입니다6. 두 유형 간에는 약간의 차이가 있지만 그 차이는 매우 작습니다.

다음 그래프는 A 및 AAAA 유형의 쿼리가 비어 있지 않은 응답을 받는 빈도를 보여주므로 서버 측 IPv6 채택을 파악하고 우리가 원하는 답변에 더 가까이 다가가는 데 도움이 됩니다.

서버의 IPv6 채택률은 쿼리량 기준으로 **43.3%**로 추정되며, 이는 클라이언트 측에서 관찰된 것보다 눈에 띄게 높은 수치입니다.

1.1.1.1에서 처리된 IP 주소 조회의 30.5%가 의도한 대상에 연결하기 위해 IPv6 주소를 사용할 수 있지만, 그 중 43.3%만이 비어 있지 않은 응답을 받는다면, 클라이언트와 서버 간에 IPv6 연결이 얼마나 자주 이루어지는지(대략 13.2%)를 알 수 있는 좋은 근거가 될 수 있습니다.

Radar의 상위 100대 도메인에 대한 쿼리량으로 측정한 IPv6 서버 측 채택률은 60.8%입니다. 전체 계산에서 이들 도메인을 제외하면 앞서 언급한 13.2%라는 수치는 8%로 떨어집니다. 상위 100대 도메인이 1.1.1.1에 대한 전체 A 및 AAAA 쿼리의 55% 이상을 차지하므로 이는 상당한 차이이지만, 예상치 못한 것은 아닙니다.

현재 인기가 높은 도메인 중 몇 개만 더 IPv6를 배포해도 관찰된 채택률이 눈에 띄게 증가할 것이며, 이에 따라 IPv6 사용 가능 클라이언트가 IPv6를 사용하여 연결을 설정할 가능성도 높아질 것입니다.

인터넷 전반에서 IPv6 채택 정도를 관찰하는 것은 다양한 의미가 있을 수 있습니다.

• IPv6 사용 가능 인터넷 액세스 권한을 가진 사용자 수 계산.

• IPv6 사용 가능 장치 또는 해당 장치의 소프트웨어(클라이언트 및/또는 서버) 계산.

• IPv6 연결을 통해 흐르는 트래픽의 양을 바이트 단위로 계산.

• IPv6를 통한 연결(또는 개별 요청)의 비율을 계산.

이 연습에서는 연결과 요청을 살펴보기로 했습니다. 여러 가지 관점을 고려해야만 근본적인 현실을 제대로 이해할 수 있다는 점을 고려하면서, 각기 다른 IPv6 채택 수치 세 가지를 살펴봤습니다.

• 35.9%(클라이언트 측)(Cloudflare의 CDN으로부터 제공되는 HTTP 요청을 계산할 때).

• 30.5%(클라이언트 측 )(1.1.1.1에서 처리되는 A 및 AAAA 유형 DNS 쿼리를 계산할 때 ).

• 43.3%(서버 측)(역시 1.1.1.1로부터의 AAAA 유형 DNS 쿼리에 대해 긍정적인 응답을 보인 비율).

DNS 관점에서 _클라이언트 측_과 서버 측 수치를 결합하여 타사 서버에 대한 연결이 IPv4가 아닌 IPv6를 통해 설정될 가능성이 있는 빈도를 추정해본 결과, **13.2%**에 불과했습니다.

이러한 수치를 개선하려면 인터넷 서비스 공급자, 클라우드 및 호스팅 공급자, 기업 모두 네트워크 내 장치에서 IPv6를 사용할 수 있도록 하는 비율을 높여야 합니다. 그러나 대형 웹 사이트와 콘텐츠 소스도 IPv6 사용 가능 클라이언트가 IPv6를 더 자주 사용할 수 있도록 하는 데 중요한 역할을 합니다. 그 이유는 Radar 상위 100대 도메인에 대한 쿼리의 39.2%(1.1.1.1에 대한 전체 A 및 AAAA 쿼리의 절반 이상)가 여전히 IPv4 전용 응답으로 제한되어 있기 때문입니다.

인터넷은 아직 완전한 IPv6 채택을 향해 나아가지 못하고 있습니다. 그러나 관련된 모든 사람들이 계속 노력한다면 계속 발전할 수 있고, 더 나아가 진전을 가속화할 수도 있습니다.

서버 측면에서 Cloudflare에서는 여러 해에 걸쳐 모든 도메인에 대해 무료 IPv6 지원을 제공함으로써 이러한 전 세계적인 노력에 힘을 보태고 있습니다. 클라이언트 측에서는 인터넷 서비스 공급자가 IPv6를 지원하지 않더라도 1.1.1.1 앱이 자동으로 장치에서 IPv6를 사용하도록 설정합니다. 또한 IPv6 전용 네트워크를 관리하는 경우 1.1.1.1의 DNS64 지원도 유용합니다.

***

¹Cloudflare의 공개 DNS 확인자(1.1.1.1)는 APNIC과 협력하여 운영됩니다. 이에 대한 자세한 내용은 원래 발표 블로그 게시물과 1.1.1.1의 개인정보 처리방침에서확인할 수 있습니다..

²DNS의 작동 방식에 대한 자세한 내용은 웹 사이트의 "DNS란?" 섹션에서 확인할 수 있습니다. 실습을 통해 직접 배우고 싶다면 Julia Evans의 "mess with dns"를 살펴보는 것을 권장합니다.

³모든 재귀 확인자는 13개의 루트 서버의 IP 주소를 미리 알고 있을 것입니다. 또한 Cloudflare에서는 E 및 F-루트 인스턴스에 Anycast 서비스를 제공하여 DNS의 최상위 레벨에 참여하므로 1.1.1.1은 첫 번째 조회 단계를 위해 멀리 갈 필요가 없습니다.41.1.1.1 앱을 사용하는 경우

⁴개의 IP 주소가 모두 자동으로 구성됩니다.

⁵단순화를 위해 IPv6 전용 클라이언트의 수는 여전히 무시할 수 있을 정도로 적다고 가정합니다. 이는 일반적으로 합리적인 가정이며, 우리가 이용할 수 있는 다른 데이터 세트에서도 이를 확인할 수 있습니다.

⁶1.1.1.1은 다른 재귀 확인자와 마찬가지로 조정된 TTL(레코드의 원래 Time To Live에서 레코드가 마지막으로 캐시된 후의 시간(초)을 뺀 값)을 반환합니다. 빈 A 및 AAAA 응답은 RFC 2308에 지정된 대로 도메인의 권한 시작(SOA) 레코드에 정의된 시간 동안 캐시됩니다.