제목이 약간 오해를 줄 수 있는 느낌인데, 사실 이 글은 “IPv6 터널을 통해 VPS로 연결해서 IPv4 인터넷에 접속하기”에 더 가깝다는 내용임, 흔히 4in6이라고 부름
어쨌든 흥미로운 방식임
우리 ISP에서 IPv4에 장애가 나면 바로 전체가 다운되어 지원 이슈가 비교적 단순하게 생기는데, IPv6에 장애가 나면 부분적으로 이상 동작하고, 느린 연결이나 간헐적 불통 등 이상하게 나타난다는 경험임
특히 게이트웨이가 IPv6 있다고 착각하면 사용자 입장에서 문제가 더 골치아픈 형태로 몇몇 기능만 작동하지 않는 등으로 보임
최근에 IPv4가 잠시 안 됐을 때 Github가 안 돼서 그제야 알게 되었음
요즘은 대부분의 소비자 웹사이트가 IPv6로는 정상 동작함
다만 라우터가 오직 IPv4 DNS만 제공하는 분들은 완전히 인터넷이 끊어지는 문제가 있었음
Microsoft가 좀 더 신경 썼으면 좋겠다는 생각임
IPv4가 돌아오는지 확인하려면 라우터에 할당한 mDNS 호스트네임을 기억해야 했던 점도 있음
솔직히 IPv4가 끊긴 적이 집에서 있었는데, 아내는 눈치도 못 챘음
Google, Facebook, Apple/iCloud, CloudFlare 기반 서비스 거의 대부분이 IPv6로 잘 동작하는 상황임
내 경험도 비슷함
IPv6 문제는 정말 원인 파악과 재현이 힘들고 “내 컴퓨터에서는 잘 되는데?”만 반복됨
대부분 ISP가 여전히 IPv6를 차단하는 상황인데, 소기업들도 IPv6 시도만 하고 AAAA 레코드 같은 걸 잊어버리는 경우가 많음
그래서 사용자들은 친구네 집이나 카페 등 저가형 ISP 환경에선 뭔가 되는데 자기 집에선 안 되는 상황이 생김
이상하게 들릴 수 있는데, 특별한 좋은 해결책이 있는 것 같진 않고 그냥 IPv4가 사라지길 바라는 게 현실
Happy Eyeballs 같은 기법(동시에 IPv4/IPv6 접속 시도하고 더 빠른 쪽 선택)도 있지만 실제로는 응용 프로그램 단에서 문제가 더 많이 발생하고, 그걸 해결할 일반적인 방법이 부족함
나 같은 경우엔 네트워크에서 IPv6는 활성화하고, 브라우저에선 IPv6 DNS를 끄는 식의 타협책을 쓰는데 만족스럽진 않음
한 가지 주의할 점이 있는데, 스트리밍 서비스를 쓸 때 이 터널을 막는 경우가 많음, 마치 VPN 우회로 인식해서 지역 제한 컨텐츠 차단 때문에 발생함
그래도 RA(라우터 광고) 기능 덕분에 어떤 네트워크 장치도 /64 단위로 IPv6 네트워크를 브로드캐스팅해서, 라우터가 HE 터널을 직접 지원하지 않아도 네트워크 내 여러 기기들이 IPv6 주소 사용 가능함(단, 라우터가 보안상 RA를 필터하지 않을 경우)
집에서 무언가 직접 서비스하려고 할 때 포트포워딩 없이 IPv6만으로 할 수 있어서 매우 편리함
Hurricane Electric 서비스는 좋지만, 이제 ISP가 IPv6를 기본 제공하는 일이 점점 많아지면서 일반 사용자는 터널 서비스에서 이탈 중임
그리고 일부 네트워크 서비스들이 he.net 터널을 남용 또는 악용으로 보고 막아버리는 경우가 많아져서, 결국 내 네트워크에선 대부분 IPv6 사용을 중지해야 했던 상황임
참고할 점, Hurricane Electric 터널은 반드시 공인 IPv4 주소를 ISP로부터 받아야만 동작함
만약 캐리어그레이드 NAT 등 NAT 환경에 있다면, IPv6를 집에 도입하려면 이 방법 대신 다른 솔루션을 찾아야 함
HE의 무료 6in4 터널을 OpenBSD로 5년째 쓰고 있는 “고객” 경험임
/etc/hostname.gif0 파일 등으로 네트워크 설정만으로 꾸준히 잘 동작함
AWS에서 IPv4없이 일부러 구성한 VPS 클러스터와의 통신에도 씀
AWS가 IPv4 주소 비용을 적극적으로 부과해서 이 방법이 비용 절감에 매우 큰 도움이 된다는 생각임
만약 진짜 v6 only 환경에서 v4 접속이 필요하다면, 공개 DNS64+NAT64 Gateway를 쓰면 손쉽게 해결 가능함 nat64.net의 공개 Provider 리스트 참고
평소에는 DNS 서버만 바꿔주면 가능함
DNS64는 AAAA 레코드가 없는 사이트에 대해 NAT64 박스에 연결될 수 있도록 AAAA 레코드를 합성해서 제공함
그러면 NAT64가 트래픽을 받아서 프로토콜 변환 + NAT를 해줌
실습 예시로 dig나 curl 명령어 써서 바로 github 같은 곳에 접속 가능함
Cloudflare WARP를 쓰면 훨씬 빠른 속도를 체감할 수 있음
WARP를 통해 IPv4 주소에 직접 접근도 가능함
가끔 IPv6-only 사용자가 있다는 게 신기함
예전에 반대 상황(IPv4-only 환경에서 IPv6 접속 필요)에서는, 서버에 완전한 제어권이 있다면 아주 빠르게 쓸 수 있는 해결책으로 SOCKS5 프록시(ssh -D 옵션) 사용이 최고였음
브라우저만 socks 프록시로 지정하면 바로 활용 가능함
시스템 전체로 하면 오히려 ssh 연결이 끊길 수도 있어서 그건 걱정되는 부분임
나와 비슷한 상황임
2주 정도 IPv4 장애 관련 티켓이 열려있는데 “곧 기술자가 처리한다”는 답변만 반복됨
IPv6는 정상이라 전체 장애로 보지 않는 듯함
독일에선 이런 경우에 소비자 보상 관련 법규가 있지만, 이번 케이스가 해당되는지 확인할 예정임
블로그 글에서 제안하는 방식의 문제는 데이터센터 IP 대역이 여러 서비스에서 차단되거나 캡차 같은 우회를 요구하거나 VPN 업체 IP처럼 다뤄지는 거라, 피할 방법이 별로 없음
내 경우 집 전체에서 해결해야 해서 라우터에서 Wireguard로 라우팅 및 NAT 규칙을 세팅했는데, Ubiquiti EdgeRouter 같은 오픈형 장비라 다행이었음
만약 FritzBox였다면 이 작업이 훨씬 어려웠을 것 같음
다만, 라우터 성능이 부족해 연결량이 많으면 느려지는 단점 있어서 하드웨어 오프로딩 지원되는 IPSec으로 교체해야 고민 중임
FritzBox도 VPN 연결을 위한 매우 훌륭한 GUI 설정 과정을 제공함
FritzBox to FritzBox가 기본 전제이나, 호환되는 VPN이면 OK임
고정 IPv4/IPv6 라우트 설정도 제공함
가장 큰 문제는 맞은편에서 어떤 IPSec 암호화 설정을 요구하는지 파악하는 것인데, Wireguard는 더 쉽지만, 반대로 하드웨어 가속 문제가 있음
필요하다면 FritzBox 전체 설정을 백업해 직접 편집 후 체크섬만 다시 계산해서 재입력하는 테크닉도 있음
AVM은 사용자에게 노출되지 않는 엄청난 양의 세부설정을 숨겨놓았는데, 의도적임
실수로 라우터를 망가뜨리지 않게 일부러 좀 어렵게 해둔 면이 있음
독일 상황은 잘 모르겠지만, 네덜란드에선 고정+모바일 인터넷 모두 같은 ISP를 쓴다면, 유선망에 장애 났을 때 무료 모바일 데이터를 요청할 수 있음
가능하다면 ISP에 해당 옵션 문의하는 걸 추천함
오랜 시간이 지나도 모든 장비와 가정용 랩을 IPv6로 바꿔야 할 명확한 이유를 못 찾겠음
포트포워딩과 방화벽 설정이 그나마 직관적이고, IPv6로 바꿀 땐 몇 주씩 문제해결, 방화벽, 주소 재설정 등 복잡함이 예상됨
내가 뭘 놓치고 있는지 궁금함
현실적으로는 지금 단계에선 놓치고 있는 것은 거의 없음
앞으로 Google, Cloudflare 등 대기업들이 계속 늘어나는 IPv4 주소 비용을 감당 못 하게 되면 IPv6로 인센티브를 줄 가능성도 있음(예: IPv4 연결은 속도 제한 등)
AWS도 예전에는 미사용 IPv4 Elastic IP만 요금 부과하더니, 이제는 사용중이어도 무조건 요금 부과함
향후 게이트웨이나 라우터를 업그레이드할 때 IPv6를 그냥 켜두는 게 좋을 듯하고, 지금은 IPv4/IPv6 듀얼로 쓰면 기존 장비와 기존 서비스 문제없이 작동함
IPv6 자동주소할당 관련해서는 역사적으로 방식이 뒤죽박죽이었으나 SLAAC로 정착되는 분위기이고, ISP 중심에선 DHCPv6를 상당히 오래 사용할 전망임
사실 그렇게 어렵진 않음
특별히 복잡한 홈네트워크가 아니라면 저녁 잠깐만 투자해도 IPv6 세팅 가능함
Comcast 기준으로 라우터에서 IPv6 옵션 켜면 ISP에서 prefix 받아오고, 이것만으로도 자동으로 네트워크에 광고되어서 원하는 포트만 방화벽 열어주면 끝임
놓치는 부분 없음
엔터프라이즈 환경에서는 IPv6 도입 플러스보다 단점이나 복잡성이 큼
나는 약 3500대 장비, 7개 건물, 2개의 10Gbps, 1개의 4Gbps WAN, 그리고 26개 공인 IPv4 주소 관리
지금까지 IPv6 써야만 하는 이유가 전혀 없음
듀얼스택으로 운영하면 네트워크 불필요한 부하와 복잡성 발생함
오히려 최근에 고정 IPv6 주소블록을 받으려 2번 신청했는데 계속 거절당함
실질적으로 이득은 없고, 심지어 할당받기도 어려운 상황임 ARIN IPv6 최초 신청 가이드 내용을 보면,
→ IPv4 할당 보유
→ IPv6 멀티홈 즉시 예정
→ 1년 내 13개 엔드사이트(오피스 등)
→ 1년 내 2000개 IPv6 주소
→ 1년 내 200개의 /64 서브넷
중 하나라도 충족해야 신청 대상임
Apple App Store 정책 중 모든 앱이 IPv6-only 네트워크에서 동작해야 한다는 요구사항은 정말 높이 평가함
개발자 입장에선 첫 경험에 놀랄 수 있는데, 소비자 입장에선 이런 요구가 매우 반가움
하지만 이 정책이 서버단에서 IPv6 주소 보유를 필수로 요구하진 않음
그러면 앱으로 github가 v6에도 접속 가능한지 궁금함
회사 업무에서 내부 인프라 접근을 위해 IPv6 only VPN을 여러 개 운영 중임
가장 큰 문제는 Windows, macOS 클라이언트가 반드시 v6 DNS 서버가 필요하다는 점임
클라이언트가 v6 지원 네트워크에 있을 수도 있고 아닐 수도 있기에, VPN 내부에서 직접 DNS 서버를 돌린 뒤 이를 클라이언트에 자동 전달해주지만
VPN 연결이 끊어지고도 Wireguard 앱이 원래 DNS로 복구해주지 못해서 다양한 문제가 발생함
나는 ISP의 IPv4 only 네트워크와 macOS 환경에서도 별도의 DNS 없이 IPv6-only를 잘 활용한 적 있음
정확한 방법은 기억 안 나지만, macOS가 v6 주소만 부여해도 문제 없이 동작
ULA 주소를 호스트에 지정하면 되고, 이건 유저가 방법만 알면 쉬운 일임
VPN 앱이 직접 IPv6-only 네트워크에 ULA를 추가해주는 스크립트를 활용할 수 있음
단, 만든 ULA 주소를 무작정 방치하면, 사용자가 다른 v6 네트워크로 이동할 때 문제가 될 수 있음
동일 상황 겪는다면 ssh 프록시(ssh -D 8080 user@hostname)로 손쉽게 socks 프록시 환경 구축 가능함
이 연결 후 브라우저 프록시 주소를 localhost:8080으로 지정하면 됨
나도 똑같이 조언하려고 했음
임시 문제 해결용으로 매우 간단하면서, 필요할 땐 상시툴로 써도 훌륭함
단, sshd_config에서 “AllowTcpForwarding”이 활성화되어야 함
나는 공공 와이파이 쓸 때 항상 이 방법을 씀
VPN 서비스 비용 안 내도 되고, 신뢰할 필요 없이 내 infomaniak 서버에서 socks 프록시로 보내면 됨
개인적으로 IPv4에 대해 불만이 많고, 특히 내 ISP가 강제로 IPv4만 제공해서 더 답답함
IPv6 도입이 이렇게 더딘 것은 기술업계의 큰 실패로 봄
누가 책임져야 할지 고민임
라우터 제조사가 허접한 펌웨어를 만드는 건지, ISP의 IPv4 추진 리더십 문제인지, IPv4 주소 투기꾼 때문인지, 네트워크 엔지니어 및 지원 인력 교육 부족 탓인지 등 원인에 대한 근본 논의가 더 필요하다고 생각함
인터넷이 TLS 1.0에서 비교적 잘 전환된 것처럼, IPv4도 넘어갈 수 있어야 하지 않나 싶음
레거시 코드를 위한 AI 프록시 같은 게 나중엔 해결책이 될 수도 있을듯함
TLS 1.0에서 전환이 더 쉬웠던 이유는 end-to-end principle 덕분임
서버와 클라이언트만 새 프로토콜 지원하면 되는데, 중간 장비(라우터, 스위치 등)는 네트워크 계층(IP)만 보면 됐었고, TLS 신규 버전과 상관없었음
네트워크 레이어 프로토콜(IP)까지 변경하면 중간 네트워크 장비 모두 영향을 받음
참고로 TLS 1.3 도입 때도 middlebox가 end-to-end 원칙을 깨고 트래픽을 감시/변조해, 호환성 때문에 TLS 1.3이 TLS 1.2 재연결처럼 위장하는 꼼수를 써야 했던 황당함도 있었음
그 차이는 TLS는 서버/클라이언트만 지원하면 되고, 중간 네트워크 장비는 TCP 패킷만 보면 됨
IPv6는 서버-클라이언트 사이 모든 중간 장비가 지원해야 하므로, “최소공통분모”에 종속적인 기술임
TLS 업그레이드는 크게 변경되는 부분 없었던 반면, IPv6는 너무 많은 부분을 동시에 바꿨음
지금 돌아보면, IPv6는 단순히 주소를 64비트로만 늘렸으면 차라리 더 보급이 쉬웠으리라는 아쉬움임
현실적으로는 많은 사람들이 교체의 실질적 이점이 너무 적거나 거의 없어서 도입에 소극적인 것임
거대 IPv4 음모론 같은 건 없이, 단지 일과 리스크 대비 효과가 적음
네트워크 업계 농담에 “IPv6는 엔지니어링 문제에 끼워 맞춘 학술적 해결책”이라는 말이 있음
대규모로 IPv4와 호환성까지 유지하면서 실제 현장 도입, 운영, 유지보수까지 생각하면 IPv6가 너무 복잡함
사실상 주소 부족 말고 실질적인 문제도 없는 IPv4가 없어질 리도 없음
그러다 보니 현장에서는 IPv6가 실질적 솔루션이 되지 못하고 있음
Hacker News 의견
제목이 약간 오해를 줄 수 있는 느낌인데, 사실 이 글은 “IPv6 터널을 통해 VPS로 연결해서 IPv4 인터넷에 접속하기”에 더 가깝다는 내용임, 흔히 4in6이라고 부름
어쨌든 흥미로운 방식임
우리 ISP에서 IPv4에 장애가 나면 바로 전체가 다운되어 지원 이슈가 비교적 단순하게 생기는데, IPv6에 장애가 나면 부분적으로 이상 동작하고, 느린 연결이나 간헐적 불통 등 이상하게 나타난다는 경험임
특히 게이트웨이가 IPv6 있다고 착각하면 사용자 입장에서 문제가 더 골치아픈 형태로 몇몇 기능만 작동하지 않는 등으로 보임
최근에 IPv4가 잠시 안 됐을 때 Github가 안 돼서 그제야 알게 되었음
요즘은 대부분의 소비자 웹사이트가 IPv6로는 정상 동작함
다만 라우터가 오직 IPv4 DNS만 제공하는 분들은 완전히 인터넷이 끊어지는 문제가 있었음
Microsoft가 좀 더 신경 썼으면 좋겠다는 생각임
IPv4가 돌아오는지 확인하려면 라우터에 할당한 mDNS 호스트네임을 기억해야 했던 점도 있음
솔직히 IPv4가 끊긴 적이 집에서 있었는데, 아내는 눈치도 못 챘음
Google, Facebook, Apple/iCloud, CloudFlare 기반 서비스 거의 대부분이 IPv6로 잘 동작하는 상황임
내 경험도 비슷함
IPv6 문제는 정말 원인 파악과 재현이 힘들고 “내 컴퓨터에서는 잘 되는데?”만 반복됨
대부분 ISP가 여전히 IPv6를 차단하는 상황인데, 소기업들도 IPv6 시도만 하고 AAAA 레코드 같은 걸 잊어버리는 경우가 많음
그래서 사용자들은 친구네 집이나 카페 등 저가형 ISP 환경에선 뭔가 되는데 자기 집에선 안 되는 상황이 생김
이상하게 들릴 수 있는데, 특별한 좋은 해결책이 있는 것 같진 않고 그냥 IPv4가 사라지길 바라는 게 현실
Happy Eyeballs 같은 기법(동시에 IPv4/IPv6 접속 시도하고 더 빠른 쪽 선택)도 있지만 실제로는 응용 프로그램 단에서 문제가 더 많이 발생하고, 그걸 해결할 일반적인 방법이 부족함
나 같은 경우엔 네트워크에서 IPv6는 활성화하고, 브라우저에선 IPv6 DNS를 끄는 식의 타협책을 쓰는데 만족스럽진 않음
IPv6를 써보고 싶지만 ISP가 제공하지 않는 경우, Hurricane Electric(HE)에서 무료로 터널 서비스를 아주 오래전부터 제공함
관련 정보 링크로는 tunnelbroker.net, ipv6.he.net, Fedora 설정법, Brandon Rozek 블로그, DD-WRT 설정법, Mikrotik 포럼 자동업데이트 스크립트, RockyLinux 가이드 같은 다양한 셋업 방법 있음
한 가지 주의할 점이 있는데, 스트리밍 서비스를 쓸 때 이 터널을 막는 경우가 많음, 마치 VPN 우회로 인식해서 지역 제한 컨텐츠 차단 때문에 발생함
그래도 RA(라우터 광고) 기능 덕분에 어떤 네트워크 장치도 /64 단위로 IPv6 네트워크를 브로드캐스팅해서, 라우터가 HE 터널을 직접 지원하지 않아도 네트워크 내 여러 기기들이 IPv6 주소 사용 가능함(단, 라우터가 보안상 RA를 필터하지 않을 경우)
집에서 무언가 직접 서비스하려고 할 때 포트포워딩 없이 IPv6만으로 할 수 있어서 매우 편리함
Hurricane Electric 서비스는 좋지만, 이제 ISP가 IPv6를 기본 제공하는 일이 점점 많아지면서 일반 사용자는 터널 서비스에서 이탈 중임
그리고 일부 네트워크 서비스들이 he.net 터널을 남용 또는 악용으로 보고 막아버리는 경우가 많아져서, 결국 내 네트워크에선 대부분 IPv6 사용을 중지해야 했던 상황임
참고할 점, Hurricane Electric 터널은 반드시 공인 IPv4 주소를 ISP로부터 받아야만 동작함
만약 캐리어그레이드 NAT 등 NAT 환경에 있다면, IPv6를 집에 도입하려면 이 방법 대신 다른 솔루션을 찾아야 함
HE의 무료 6in4 터널을 OpenBSD로 5년째 쓰고 있는 “고객” 경험임
/etc/hostname.gif0 파일 등으로 네트워크 설정만으로 꾸준히 잘 동작함
AWS에서 IPv4없이 일부러 구성한 VPS 클러스터와의 통신에도 씀
AWS가 IPv4 주소 비용을 적극적으로 부과해서 이 방법이 비용 절감에 매우 큰 도움이 된다는 생각임
만약 진짜 v6 only 환경에서 v4 접속이 필요하다면, 공개 DNS64+NAT64 Gateway를 쓰면 손쉽게 해결 가능함
nat64.net의 공개 Provider 리스트 참고
평소에는 DNS 서버만 바꿔주면 가능함
DNS64는 AAAA 레코드가 없는 사이트에 대해 NAT64 박스에 연결될 수 있도록 AAAA 레코드를 합성해서 제공함
그러면 NAT64가 트래픽을 받아서 프로토콜 변환 + NAT를 해줌
실습 예시로 dig나 curl 명령어 써서 바로 github 같은 곳에 접속 가능함
유럽에선 nat64.net을 직접 써도 꽤 쾌적하게 동작함
실제로 좋은 경험만 있었음
Cloudflare WARP를 쓰면 훨씬 빠른 속도를 체감할 수 있음
WARP를 통해 IPv4 주소에 직접 접근도 가능함
가끔 IPv6-only 사용자가 있다는 게 신기함
예전에 반대 상황(IPv4-only 환경에서 IPv6 접속 필요)에서는, 서버에 완전한 제어권이 있다면 아주 빠르게 쓸 수 있는 해결책으로 SOCKS5 프록시(ssh -D 옵션) 사용이 최고였음
브라우저만 socks 프록시로 지정하면 바로 활용 가능함
시스템 전체로 하면 오히려 ssh 연결이 끊길 수도 있어서 그건 걱정되는 부분임
나와 비슷한 상황임
2주 정도 IPv4 장애 관련 티켓이 열려있는데 “곧 기술자가 처리한다”는 답변만 반복됨
IPv6는 정상이라 전체 장애로 보지 않는 듯함
독일에선 이런 경우에 소비자 보상 관련 법규가 있지만, 이번 케이스가 해당되는지 확인할 예정임
블로그 글에서 제안하는 방식의 문제는 데이터센터 IP 대역이 여러 서비스에서 차단되거나 캡차 같은 우회를 요구하거나 VPN 업체 IP처럼 다뤄지는 거라, 피할 방법이 별로 없음
내 경우 집 전체에서 해결해야 해서 라우터에서 Wireguard로 라우팅 및 NAT 규칙을 세팅했는데, Ubiquiti EdgeRouter 같은 오픈형 장비라 다행이었음
만약 FritzBox였다면 이 작업이 훨씬 어려웠을 것 같음
다만, 라우터 성능이 부족해 연결량이 많으면 느려지는 단점 있어서 하드웨어 오프로딩 지원되는 IPSec으로 교체해야 고민 중임
FritzBox도 VPN 연결을 위한 매우 훌륭한 GUI 설정 과정을 제공함
FritzBox to FritzBox가 기본 전제이나, 호환되는 VPN이면 OK임
고정 IPv4/IPv6 라우트 설정도 제공함
가장 큰 문제는 맞은편에서 어떤 IPSec 암호화 설정을 요구하는지 파악하는 것인데, Wireguard는 더 쉽지만, 반대로 하드웨어 가속 문제가 있음
필요하다면 FritzBox 전체 설정을 백업해 직접 편집 후 체크섬만 다시 계산해서 재입력하는 테크닉도 있음
AVM은 사용자에게 노출되지 않는 엄청난 양의 세부설정을 숨겨놓았는데, 의도적임
실수로 라우터를 망가뜨리지 않게 일부러 좀 어렵게 해둔 면이 있음
독일 상황은 잘 모르겠지만, 네덜란드에선 고정+모바일 인터넷 모두 같은 ISP를 쓴다면, 유선망에 장애 났을 때 무료 모바일 데이터를 요청할 수 있음
가능하다면 ISP에 해당 옵션 문의하는 걸 추천함
오랜 시간이 지나도 모든 장비와 가정용 랩을 IPv6로 바꿔야 할 명확한 이유를 못 찾겠음
포트포워딩과 방화벽 설정이 그나마 직관적이고, IPv6로 바꿀 땐 몇 주씩 문제해결, 방화벽, 주소 재설정 등 복잡함이 예상됨
내가 뭘 놓치고 있는지 궁금함
현실적으로는 지금 단계에선 놓치고 있는 것은 거의 없음
앞으로 Google, Cloudflare 등 대기업들이 계속 늘어나는 IPv4 주소 비용을 감당 못 하게 되면 IPv6로 인센티브를 줄 가능성도 있음(예: IPv4 연결은 속도 제한 등)
AWS도 예전에는 미사용 IPv4 Elastic IP만 요금 부과하더니, 이제는 사용중이어도 무조건 요금 부과함
향후 게이트웨이나 라우터를 업그레이드할 때 IPv6를 그냥 켜두는 게 좋을 듯하고, 지금은 IPv4/IPv6 듀얼로 쓰면 기존 장비와 기존 서비스 문제없이 작동함
IPv6 자동주소할당 관련해서는 역사적으로 방식이 뒤죽박죽이었으나 SLAAC로 정착되는 분위기이고, ISP 중심에선 DHCPv6를 상당히 오래 사용할 전망임
사실 그렇게 어렵진 않음
특별히 복잡한 홈네트워크가 아니라면 저녁 잠깐만 투자해도 IPv6 세팅 가능함
Comcast 기준으로 라우터에서 IPv6 옵션 켜면 ISP에서 prefix 받아오고, 이것만으로도 자동으로 네트워크에 광고되어서 원하는 포트만 방화벽 열어주면 끝임
놓치는 부분 없음
엔터프라이즈 환경에서는 IPv6 도입 플러스보다 단점이나 복잡성이 큼
나는 약 3500대 장비, 7개 건물, 2개의 10Gbps, 1개의 4Gbps WAN, 그리고 26개 공인 IPv4 주소 관리
지금까지 IPv6 써야만 하는 이유가 전혀 없음
듀얼스택으로 운영하면 네트워크 불필요한 부하와 복잡성 발생함
오히려 최근에 고정 IPv6 주소블록을 받으려 2번 신청했는데 계속 거절당함
실질적으로 이득은 없고, 심지어 할당받기도 어려운 상황임
ARIN IPv6 최초 신청 가이드 내용을 보면,
→ IPv4 할당 보유
→ IPv6 멀티홈 즉시 예정
→ 1년 내 13개 엔드사이트(오피스 등)
→ 1년 내 2000개 IPv6 주소
→ 1년 내 200개의 /64 서브넷
중 하나라도 충족해야 신청 대상임
Apple App Store 정책 중 모든 앱이 IPv6-only 네트워크에서 동작해야 한다는 요구사항은 정말 높이 평가함
개발자 입장에선 첫 경험에 놀랄 수 있는데, 소비자 입장에선 이런 요구가 매우 반가움
하지만 이 정책이 서버단에서 IPv6 주소 보유를 필수로 요구하진 않음
그러면 앱으로 github가 v6에도 접속 가능한지 궁금함
회사 업무에서 내부 인프라 접근을 위해 IPv6 only VPN을 여러 개 운영 중임
가장 큰 문제는 Windows, macOS 클라이언트가 반드시 v6 DNS 서버가 필요하다는 점임
클라이언트가 v6 지원 네트워크에 있을 수도 있고 아닐 수도 있기에, VPN 내부에서 직접 DNS 서버를 돌린 뒤 이를 클라이언트에 자동 전달해주지만
VPN 연결이 끊어지고도 Wireguard 앱이 원래 DNS로 복구해주지 못해서 다양한 문제가 발생함
정확한 방법은 기억 안 나지만, macOS가 v6 주소만 부여해도 문제 없이 동작
ULA 주소를 호스트에 지정하면 되고, 이건 유저가 방법만 알면 쉬운 일임
VPN 앱이 직접 IPv6-only 네트워크에 ULA를 추가해주는 스크립트를 활용할 수 있음
단, 만든 ULA 주소를 무작정 방치하면, 사용자가 다른 v6 네트워크로 이동할 때 문제가 될 수 있음
동일 상황 겪는다면 ssh 프록시(ssh -D 8080 user@hostname)로 손쉽게 socks 프록시 환경 구축 가능함
이 연결 후 브라우저 프록시 주소를 localhost:8080으로 지정하면 됨
나도 똑같이 조언하려고 했음
임시 문제 해결용으로 매우 간단하면서, 필요할 땐 상시툴로 써도 훌륭함
단, sshd_config에서 “AllowTcpForwarding”이 활성화되어야 함
나는 공공 와이파이 쓸 때 항상 이 방법을 씀
VPN 서비스 비용 안 내도 되고, 신뢰할 필요 없이 내 infomaniak 서버에서 socks 프록시로 보내면 됨
개인적으로 IPv4에 대해 불만이 많고, 특히 내 ISP가 강제로 IPv4만 제공해서 더 답답함
IPv6 도입이 이렇게 더딘 것은 기술업계의 큰 실패로 봄
누가 책임져야 할지 고민임
라우터 제조사가 허접한 펌웨어를 만드는 건지, ISP의 IPv4 추진 리더십 문제인지, IPv4 주소 투기꾼 때문인지, 네트워크 엔지니어 및 지원 인력 교육 부족 탓인지 등 원인에 대한 근본 논의가 더 필요하다고 생각함
인터넷이 TLS 1.0에서 비교적 잘 전환된 것처럼, IPv4도 넘어갈 수 있어야 하지 않나 싶음
레거시 코드를 위한 AI 프록시 같은 게 나중엔 해결책이 될 수도 있을듯함
TLS 1.0에서 전환이 더 쉬웠던 이유는 end-to-end principle 덕분임
서버와 클라이언트만 새 프로토콜 지원하면 되는데, 중간 장비(라우터, 스위치 등)는 네트워크 계층(IP)만 보면 됐었고, TLS 신규 버전과 상관없었음
네트워크 레이어 프로토콜(IP)까지 변경하면 중간 네트워크 장비 모두 영향을 받음
참고로 TLS 1.3 도입 때도 middlebox가 end-to-end 원칙을 깨고 트래픽을 감시/변조해, 호환성 때문에 TLS 1.3이 TLS 1.2 재연결처럼 위장하는 꼼수를 써야 했던 황당함도 있었음
그 차이는 TLS는 서버/클라이언트만 지원하면 되고, 중간 네트워크 장비는 TCP 패킷만 보면 됨
IPv6는 서버-클라이언트 사이 모든 중간 장비가 지원해야 하므로, “최소공통분모”에 종속적인 기술임
TLS 업그레이드는 크게 변경되는 부분 없었던 반면, IPv6는 너무 많은 부분을 동시에 바꿨음
지금 돌아보면, IPv6는 단순히 주소를 64비트로만 늘렸으면 차라리 더 보급이 쉬웠으리라는 아쉬움임
현실적으로는 많은 사람들이 교체의 실질적 이점이 너무 적거나 거의 없어서 도입에 소극적인 것임
거대 IPv4 음모론 같은 건 없이, 단지 일과 리스크 대비 효과가 적음
네트워크 업계 농담에 “IPv6는 엔지니어링 문제에 끼워 맞춘 학술적 해결책”이라는 말이 있음
대규모로 IPv4와 호환성까지 유지하면서 실제 현장 도입, 운영, 유지보수까지 생각하면 IPv6가 너무 복잡함
사실상 주소 부족 말고 실질적인 문제도 없는 IPv4가 없어질 리도 없음
그러다 보니 현장에서는 IPv6가 실질적 솔루션이 되지 못하고 있음