[Geoff Huston ‘IP Addresses through 2025’ 메모 + v4/v6 연결 지연 실측]
: IPv4 거래가는 떨어지는데, Public IPv4 비용은 오른다.
이 글은 Geoff Huston의 ‘IP Addresses through 2025’를 읽고,
IPv4를 “고갈”이라는 기술 키워드 하나로 설명하기 어려워진 흐름(시장/운영/아키텍처)을 개인적으로 정리한 글이다.
그리고 그 연장선에서 v4/v6 연결 지연을 아주 작게나마 직접 측정해봤다.
- 원문(리포트): https://www.potaroo.net/ispcol/2026-01/addr2025.html
- APNIC 블로그 요약: https://blog.apnic.net/2026/01/20/ip-addresses-through-2025/
- GeekNews 요약: https://news.hada.io/topic?id=26252
ISP Column - January 2026
It's time for another annual roundup from the world of IP addresses. Let’s see what has changed in the past 12 months in addressing the Internet and look at how IP address allocation information can inform us of the changing nature of the network itself.
www.potaroo.net
왜 이게 '클라우드 비용 이슈'로 이어지는가
리포트에서 흥미로웠던 지점은 IPv4를 더 이상 “주소가 없어서”만으로 설명할 수 없다는 점이다.
IPv4는 거래 시장이 이미 형성되어 있고, 가격은 수급/매물/정책 같은 운영 요인에 강하게 반응한다.
2025년에 가격 하락이 이어졌고, /14 거래에서 $9 per address까지 내려갔다. 또한 2026-01-10 기준 최근 40일 평균은 $22 per address로 언급된다. 다만 지역별 차이(예: APNIC 지역은 여전히 $0.60 이상)가 있어 전체 시장으로 일반화하기 어렵다. (“IPv4는 고갈이니 계속 오른다” 같은 단순 서사로 끝나지 않는다.)"
그런데 동시에 클라우드에서는 Public IPv4가 청구서 항목이 됐다.
AWS: 2024-02-01부터 Public IPv4에 시간당 $0.005/IP 과금 (attached 여부 상관없이 적용, Free Tier 예외 있음) https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/
GCP: 2024-02-01부터 VM에 할당된 in-use external IPv4 단가 인상(예: Standard VM 기준 $0.005/hr) https://cloud.google.com/vpc/pricing-announce-external-ips
거래 시장 가격이 내려가든 올라가든,
클라우드 운영 관점에서는 “Public IPv4를 아껴 쓰게 만드는 압력”이 들어가는 구조로 보인다.
그래서 NAT Gateway, IPv6-only, 프록시/로드밸런서 뒤로 숨기기 같은 설계가 비용/운영 이슈와 바로 연결된다.
VM에서 사용하는 외부 IPv4 주소에 대한 가격 책정 변경사항 공지 | Virtual Private Cloud | Google Cl
의견 보내기 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. VM에서 사용하는 외부 IPv4 주소의 가격 변경사항 공지 이 페이지에서는 2024년 2월 1일부터 적용되
cloud.google.com
New – AWS Public IPv4 Address Charge + Public IP Insights | Amazon Web Services
We are introducing a new charge for public IPv4 addresses. Effective February 1, 2024 there will be a charge of $0.005 per IP per hour for all public IPv4 addresses, whether attached to a service or not (there is already a charge for public IPv4 addresses
aws.amazon.com
실측 목표: v4/v6를 분리해서 “tail”을 본다
듀얼스택 환경에서는 클라이언트가 v4/v6를 섞어서 시도(지연이 있으면 우회)하기 때문에 사용자 체감만으로는 프로토콜 차이를 잡기 어렵다. 그래서 이번에는 curl의 `-4/-6` 옵션으로 프로토콜을 고정해서 경로/품질 차이가 어떤 형태(특히 tail: 느린 케이스)로 드러나는지 확인했다.
측정 조건
- 대상: https://www.google.com
- 횟수: v4 30회 + v6 30회
- 기록(curl --write-out): time_namelookup, time_connect, time_appconnect, time_starttransfer, time_total
중요한 주의점:
curl의 time_* 값은 “구간별”이 아니라 시작 시점부터의 누적 시간이다.
(예를 들어 `time_appconnect`는 “TLS만”이 아니라 (DNS + TCP + TLS 완료까지) 누적- 구간별로 보려면 차이를 계산해야 함)
- tcp_seg = time_connect - time_namelookup
- tls_seg = time_appconnect - time_connect
- ttfb_seg = time_starttransfer - time_appconnect
[(1) 결과 1: DNS A/AAAA 확인]
dig +short A www.google.com | head -n 5
dig +short AAAA www.google.com | head -n 5[(2) CSV 샘플]
CSV는 `ver,dns,tcp,tls,ttfb,total,exit` 컬럼으로 저장
-> dns/tcp/tls/ttfb는 각각 “그 구간만”이 아니라 해당 지점까지의 누적 시간
[(3) total 기준 느린 케이스(top 5)]
total 기준으로 느린 케이스를 뽑으면 v6가 상단에 잡힘
-> v6가 항상 느리다 X, 일부 시도에서 0.8~1초대 tail(99th percentile latency)이 나타나고,
이는 사용자 경험을 좌우하는 운영 관점에서 더 중요할 수 있음. (예: 웹 서비스에서 tail latency가 전체 성능 지표에 큰 영향을 줌)
[(4) time_appconnect 기준 느린 케이스(top 5)]
time_appconnect(TLS 완료 시점까지 누적) 기준으로 느린 상위 샘플이다.
`time_appconnect`가 크다고 해서 곧바로 “TLS 핸드셰이크가 원인”이라고 단정할 수는 없다.
`time_appconnect` 자체가 누적값이기 때문에 구간 분해(차이 계산) 없이 결론을 내리면 쉽게 틀어진다.
또한 가장 느린 샘플을 보면 `time_starttransfer`(첫 바이트까지)가 크게 잡힌 케이스도 있다.
즉 tail은 DNS/TCP/TLS 중 하나로 단정되기보다, 어느 구간이 커졌는지를 분해해서 봐야 함.
느린 샘플에서 time_appconnect / time_total 비율을 찍어봤다.
이 비율은 "TLS만"이 아니라 DNS+TCP+TLS 완료까지가 total에서 차지하는 비중이다.
[(5) DNS+TCP+TLS 완료) / total 비중]
느린 샘플에서 `time_appconnect / time_total` 비중을 계산했다.
이 비율은 “TLS만”이 아니라 DNS+TCP+TLS 완료까지가 total에서 차지하는 비중이다.
이번 샘플에서는 대략 31%~68% 정도 범위로 나타났다.
- IPv4는 계속 “고갈”이라 불리지만, 실무에서는 NAT가 부족분을 메우며 버틴다.
- 클라우드 사업자는 Public IPv4에 가격 신호를 걸어 설계를 바꾸게 만든다.
- 클라이언트는 v4/v6 품질 차이를 사용자에게 덜 보이게 처리한다.
- IPv6 전환은 “기술적으로 더 좋아서”가 아니라 비용/운영/품질의 합으로 결정된다.
[요약]
IPv4 시장 가격 하락에도 클라우드 과금 압력으로 IPv6 전환이 가속화될 수 있음.
지연 측정에서 v6의 tail latency가 운영 이슈.
그래서 개인적으로는 평균 지연(평균/중앙값)만 비교하기보다 tail(느린 케이스)이 어떤 형태로 나타나는지, 그리고 그 tail이 어느 구간(DNS/TCP/TLS/TTFB)에서 생겼는지 분해해서 보는 게 더 실무적이라 생각함.
[한계 / 다음에 해볼 것]
한계:
- 대상이 google.com 하나, 환경도 하나라 일반화 불가 (다른 사이트나 네트워크 환경 테스트 필요)
- 같은 도메인이라도 시도마다 다른 서버/경로로 갈 수 있음
- curl 타이밍은 클라이언트 관측치라 원인을 서버/네트워크/경로 중 어디로 특정하기 어려움 (traceroute나 패킷 캡처로 보완 가능)
다음:
- remote_ip까지 기록해서 “어느 IP/경로에서 tail이 났는지” 묶어보기
- 네트워크 환경(집/학교/테더링) 바꿔 재현성 확인
- tail이 뜨는 순간 traceroute / 패킷 캡처로 단서 추가
재현 커맨드
# DNS A/AAAA 확인
dig +short A www.google.com | head -n 5
dig +short AAAA www.google.com | head -n 5
# v4/v6 강제 (간단)
curl -o /dev/null -s -w "v4 total=%{time_total}\n" -4 https://www.google.com
curl -o /dev/null -s -w "v6 total=%{time_total}\n" -6 https://www.google.com
# 상세 타이밍 (주의: 누적 시간임)
curl -o /dev/null -s -4 \
-w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
https://www.google.com
curl -o /dev/null -s -6 \
-w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
https://www.google.com
# 누적 → 구간 분해(차이)
# tcp_seg = time_connect - time_namelookup
# tls_seg = time_appconnect - time_connect
# ttfb_seg = time_starttransfer - time_appconnect
참고
- IP Addresses through 2025 (Geoff Huston): https://www.potaroo.net/ispcol/2026-01/addr2025.html
- GeekNews 요약: https://news.hada.io/topic?id=26252
- AWS Public IPv4 Address Charge: https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/
- GCP External IPv4 pricing: https://cloud.google.com/vpc/pricing-announce-external-ips
- Happy Eyeballs v2 (RFC 8305): https://datatracker.ietf.org/doc/html/rfc8305
- curl write-out 변수: https://everything.curl.dev/usingcurl/verbose/writeout.htm
'tech issue' 카테고리의 다른 글
| 텍스트에서 지식 그래프 추출하기 - Extracting Knowledge Graphs From Text With GPT4o (0) | 2026.02.05 |
|---|