이제 HTTPS가 거의 모든 곳에 적용되었는데, IPv6는 어떨까요?
Let's Encrypt는 2016년 4월 12일에 출시되었으며, 모든 곳에서 HTTPS를 활성화하도록 사이트를 지원하고 장려하기 위한 목적으로 시작되었습니다(웹에서 선호하는 프로토콜로 TLS가 점차 늘어나고 있지만 SSL Everywhere라고도 함). 2017년 2월 말 현재, EFF(이 노력을 시작한 곳)는 웹의 절반이 현재 암호화되어 있다고 추정합니다 . 물론 이 모든 것이 EFF와 Let's Encrypt 덕분이라고 할 수는 없습니다. 사실, 저는 그 날짜보다 훨씬 이전의 데이터를 가지고 있는데, 그에 따르면 F5 고객 대다수가 70% 범위에서 클라이언트 대면 서비스에서 HTTPS를 활성화했습니다. 따라서 EFF가 노력을 시작하기도 전에 사람들이 HTTPS를 지원하고 있었던 것은 분명하지만, EFF가 발급한 인증서*의 수가 상당히 많다는 점을 고려하면 이러한 노력은 눈에 띄는 성공을 거두지 못한 것은 아닙니다.
2006년 9월 11일, ICANN은 "인터넷 할당 번호 기관(IANA)에 의한 IPv6 주소 할당에 대한 글로벌 정책을 비준"했습니다. 표준 자체는 수년(10년 정도) 전에 비준되었지만, 해당 주소 할당을 관리하는 정책이 없었다면 그다지 의미가 없었을 것입니다. 하지만 2006년부터 우리는 IPv6로의 전환을 진지하게 고려하기 시작했습니다. 결국, 웹은 성장하고, 모바일은 폭발적으로 증가했으며, 사용 가능한 IPv4 주소는 점점 줄어들어 아무것도 없게 되었습니다.
보안을 강화하기 위한 것이 아니더라도 수십억 개의 연결된 장치와 사물을 지원할 수 있는 확장된 주소 공간을 위해 IPv6가 필요했습니다 .
그러나 채택률은 너무나 형편없습니다. "클라우드"는 IPv6가 사용 가능했던 시대에 탄생했다는 점을 고려하세요. 그런데도 Amazon AWS 와 Microsoft Azure가 컴퓨팅 인스턴스에 대한 클라우드 서비스에서 IPv6를 활성화하는 데는 2016년 후반이 걸렸습니다.
이로 인해 일부에서는 짧은 시간 안에 거의 모든 곳에서 HTTPS를 사용할 수 있게 되었는가 하면, 왜 아직도 IPv6를 지원하는 사이트가 그렇게 적은 걸까 하고 한탄하기도 합니다. Google은 사용자의 16.06%가 IPv6를 사용하고 있다고 추정합니다 ( World IPv6 Launch에서 추적한 서비스 제공업체 지원과 비교하면 흥미로운 사실입니다). 하지만 W3C Techs에 따르면 이를 지원하는 웹사이트는 10%에 불과합니다.
공평하게 말해서 HTTPS는 새로운 것이 아니었습니다. EFF는 단지 사람들이 이미 가지고 있는 것을 활용하도록 격려하고 힘을 실어주었을 뿐입니다. HTTPS는 잘 지원되고, 잘 이해되며, 완벽하게 구축되었습니다. 그러니 이전 표준과 호환되지 않는 HTTP/2와 같은 단점이 있는 새로운 표준과 비교하는 것이 더 공평할 수도 있습니다.
2015년 5월에 확고한 웹 표준의 새 버전이 비준되었습니다. HTTP/2 프로토콜을 지원 합니다. IPv6와 마찬가지로 이전 버전과 호환되지 않습니다. "SSL Everywhere"와 달리 IPv6 또는 HTTP/2를 지원하는 것은 단순히 인증서를 취득하고 웹 서버나 인프라에서 HTTPS를 활성화하는 것이 아닙니다. HTTP에서 HTTPS로 전환하면 중단이 발생할 수 있고 네트워크 인프라에 영향을 미칠 수 있다는 것은 사실이지만, IPv6나 HTTP/2로 인해 발생하는 중단 수준과 같지는 않습니다.
새로운 기반 프로토콜로 전환하려면 전환적 접근 방식이 필요합니다. 즉, 미래의 어느 시점까지 기존 프로토콜과 새 프로토콜을 동시에 지원해야 합니다. 이는 트래픽이 흐를 수 있는 모든 장치에 대해 "듀얼 스택"을 의미합니다. 어떤 조직에게는 이는 엄청난 노력이고, 다른 조직에게는 건축상의 악몽이 될 수도 있습니다. 소프트웨어가 기술적 부채를 발생시키는 것처럼 네트워크도 아키텍처 부채를 발생시키며, 이러한 아키텍처 부채에 대한 "이자 지불"로 인해 IPv6 도입에 대한 타당한 사례를 구축하기 어려울 가능성이 높습니다. 사실, 그것은 필수사항도 아니고 그런 것도 아니잖아요. IPv6를 지원하지 않아도 사업은 계속됩니다.
아니면 그럴까?
원래 HTTP/2에는 TLS/SSL이 필요하다는 점을 기억하세요. 불평이 있긴 했지만 결국 선택 사항이 되었습니다. 브라우저 개발자들은 이를 가볍게 여기고 TLS/SSL을 통한 HTTP/2만 지원하면서 사실상 모든 사람에게 이 요구 사항을 강요했습니다. 2015년 후반부터 Google은 검색 순위에서 HTTPS 지원 사이트를 우선시하기 시작했습니다. 그리고 2016년에 Apple은 모든 네이티브 앱이 App Transport Security를 사용하도록 요구하는 유사한 조치를 취했고, 다시 한번 HTTPS로의 전환을 강제했습니다.
기본적으로 HTTPS는 클라이언트 측에서 지원하도록 강제되었습니다.
현재 IPv6의 경우 이와 유사한 요구 사항은 없습니다. 우리는 IPv4 주소가 사라지는 것을 지켜보았지만 그 영향은 상대적으로 적거나 전혀 없었습니다. 그래서 (아직까지는) 잠재적으로 파괴적이고 비용이 많이 드는 움직임을 취할 실질적인 동기를 느낀 사람은 없습니다. 하지만 더 많은 제품이 등장함에 따라 결국 IPv6만 지원하는 제품이 나올 가능성이 매우 큽니다. 사물은 작은 폼 팩터를 가지고 있으며 처리 능력도 제한적입니다. 사물인터넷에서는 적을수록 더 좋습니다. 이것이 많은 IoT 기기가 HTTP 대신 MQTT를 선택하는 이유 중 하나입니다. MQTT는 더 무거운 웹 기반 프로토콜보다 작고, 빠르고, 효율적이기 때문입니다. IPv4와 IPv6를 모두 지원하는 것은 비슷합니다. 두 가지가 호환되지 않기 때문에 대부분의 기기는 둘 중 하나만 지원합니다. 그리고 결국 그들은 하나를 선택하게 되고, 모두가 그것을 지지하기 위해 힘쓰게 될 것입니다.
그렇지 않더라도 현재 사용 가능한 IPv4 주소로는 2020년까지 사용될 것으로 예상되는 200억 대의 기기 중 20%에도 못 미칩니다(가트너). IPv6는 시스코가 예측한 500억 대의 기기보다 훨씬 더 많은 기기를 지원합니다. 그리고 이건 단지 사물인터넷에 대한 이야기일 뿐입니다.
클라우드 역시 늘어나는 고객 기반을 지원할 만큼 충분한 IPv4 주소를 구매할 수 없다는 점에서 문제가 있습니다. 예상대로 IaaS가 성장하려면 클라우드 제공업체는 IPv6로 전환 해야 합니다 . Amazon과 Microsoft가 이런 움직임을 보이는 데에는 의심의 여지가 없습니다.
이 모든 것이 의미하는 바는 결국 IPv6 지원이 필요한 강제 기능이 등장할 것이라는 것입니다. 사물인터넷일 수도 있고, 클라우드 자체일 수도 있습니다. 이 둘이 합쳐져 여러분의 사업에 폭발적인 파괴력을 미칠 수도 있습니다. 어느 쪽이든 언젠가는 전환을 해야 할 텐데, 서두르지 않는 게 항상 가장 좋습니다. 우리는 IPv6의 문제점을 해결하기 위해 오랫동안 노력해 왔으며, 현재 시장에는 전환을 시작하기 위한 듀얼 스택 방식을 지원하는 충분한 솔루션이 있습니다. 그러니 아직 IPv6를 활성화하지 않았다면, 기업의 지속적인 성장에 필요한 것들 때문에 강제로 활성화해야 하기 전에, 지금이 IPv6를 활성화하는 것을 진지하게 고려해야 할 때입니다.
* 그렇습니다. 겉보기에 사기성 증명서 의 숫자에 대해 자세히 알아볼 수 있고, 그것을 사탕처럼 맹목적으로 나눠주는 데는 위험이 따른다는 사실도 알 수 있지만, 이는 다른 날에 이야기해야 할 또 다른 문제입니다.