IPv6 입문: 콜론으로 줄줄이 이어진 그 주소의 정체

IPv6 입문: 콜론으로 줄줄이 이어진 그 주소의 정체

브라우저 주소창이나 서버 로그에서 2001:db8::1 같은 알 수 없는 주소를 본 적 있으신가요? 점(.) 대신 콜론(:)이 줄줄이 박혀 있는 모양인데요. 이게 바로 IPv6 주소입니다.

IPv4 주소 공간이 거의 바닥났다는 이야기는 이제 익숙하실 거예요. 그 문제에 대한 단기 처방이 사설 IP와 NAT였다면, 진짜 해법으로 마련된 게 IPv6입니다. 이번 포스팅에서는 IPv6가 어떤 주소 체계를 가지는지, 그 낯선 표기법을 어떻게 읽어야 하는지, IPv4와 비교해 무엇이 달라졌는지를 차근차근 살펴보겠습니다.

왜 IPv6가 필요했나

IPv4의 32비트 주소 공간은 이론상 약 43억 개를 담을 수 있습니다. 80년대에는 충분하다고 봤지만, 인터넷에 연결되는 기기가 PC를 넘어 휴대폰, 가전제품, 자동차까지 확장되면서 빠르게 모자라기 시작했죠. 사설 IP와 NAT라는 우회로가 시간을 벌어주긴 했지만, 모든 기기가 진짜로 인터넷에 직접 노출될 수는 없게 만든 부작용이 있었어요.

IPv6는 이 문제를 근본부터 다시 푸는 시도입니다. 주소 길이를 128비트로 늘려서, 표현할 수 있는 주소 수를 2^128 개로 키워버린 거죠. 숫자로 적으면 약 340 간(澗, undecillion) 개인데요. 지구 전체 표면을 1mm² 단위로 쪼개고 그 위에 다시 우주에 가까운 양의 별을 얹어도 남는 규모라, 사실상 “고갈” 자체를 걱정할 필요가 없게 설계됐습니다.

IPv6 주소 표기법

IPv6 주소는 16비트씩 8개 그룹으로 나누고, 각 그룹을 4자리 16진수로 표기합니다. 구분자는 콜론(:)이에요.

IPv6 주소의 풀(full) 표기
2001:0db8:0000:0000:0000:ff00:0042:8329

이걸 그대로 쓰면 너무 길어서, IPv6에는 두 가지 단축 규칙이 있습니다.

첫째, 각 그룹의 앞쪽 0은 생략할 수 있습니다. 0db8db8로, 004242로 줄여 쓸 수 있어요.

2001:db8:0:0:0:ff00:42:8329

둘째, 연속된 0 그룹은 ::로 한 번만 압축할 수 있습니다. 한 주소에 ::는 딱 한 번만 등장할 수 있어요. 두 군데에 쓰면 어디까지가 0인지 모호해지거든요.

2001:db8::ff00:42:8329

이 두 규칙을 적용하면 처음의 32자리 주소가 단정한 한 줄로 줄어듭니다. 잘 알려진 루프백 주소도 마찬가지예요. 풀 표기로는 0000:0000:0000:0000:0000:0000:0000:0001인데 압축하면 그냥 ::1이 됩니다.

IPv4와 비교한 변화점

IPv6는 단순히 주소만 길어진 게 아니라 설계 곳곳을 손봤습니다.

가장 눈에 띄는 변화는 NAT가 (이론상) 필요 없어진다는 점입니다. 주소가 넉넉하니까 모든 기기에 공인 IPv6 주소를 직접 줄 수 있거든요. 홈 네트워크의 토스터까지 전 세계에서 직접 접근 가능한 주소를 가질 수 있는 셈인데, 이건 P2P나 IoT 통신에서는 큰 장점이지만 보안 관점에서는 다시 방화벽으로 막아야 할 거리가 늘었다는 뜻이기도 해요.

다음은 자동 주소 설정입니다. IPv4에서는 DHCP 서버가 주소를 나눠줘야 했는데, IPv6는 SLAAC(Stateless Address Autoconfiguration)라는 메커니즘으로 기기가 라우터의 광고(Router Advertisement)를 듣고 스스로 주소를 만들 수 있습니다. DHCP 서버 없이도 네트워크에 끼면 알아서 주소가 잡히는 거죠.

헤더 구조도 단순해졌습니다. IPv4 헤더는 옵션 필드들이 가변 길이로 붙어 있어서 라우터가 매번 길이를 계산해야 했는데, IPv6는 기본 헤더를 40바이트 고정 크기로 맞췄습니다. 부가 옵션은 확장 헤더(extension header)로 따로 떼어내, 보통 트래픽에서는 라우터가 헤더 처리를 더 빨리 끝낼 수 있게 됐어요.

체크섬도 빠졌습니다. IPv4 헤더에는 자체 체크섬이 있어서 라우터가 매 hop마다 다시 계산해야 했지만, IPv6는 그 책임을 TCP/UDP 같은 상위 계층에 맡기고 자기 헤더에서는 빼버렸습니다. 어차피 이더넷 프레임도 자체 체크섬을 가지고 있으니 중복이라는 판단이었죠.

특별한 IPv6 주소들

IPv4에 사설 IP, 루프백, 링크 로컬 같은 특수 대역이 있었듯 IPv6도 비슷한 구분이 있습니다.

::1은 IPv6의 루프백 주소입니다. IPv4의 127.0.0.1에 정확히 대응하는데요. localhost를 IPv6로 풀면 보통 ::1이 됩니다.

fe80::/10은 링크 로컬 주소입니다. 같은 네트워크 세그먼트 안에서만 쓰이고 라우터를 넘어가지 못하는 주소예요. IPv4의 169.254.0.0/16에 해당합니다. IPv6 기기는 켜지자마자 자기 MAC 주소 같은 정보를 바탕으로 이 대역에서 주소를 하나 만들어 갖고 시작합니다.

fc00::/7은 ULA(Unique Local Address)입니다. RFC 1918의 사설 IP에 대응하는 IPv6 영역인데요. 조직 내부에서만 쓰는 용도로 만들어졌고, 인터넷 라우터는 이 대역을 라우팅하지 않습니다.

ff00::/8은 멀티캐스트 대역입니다. IPv6는 IPv4의 브로드캐스트 개념을 없애고 그 자리를 멀티캐스트로 통일했어요. “같은 링크의 모든 노드에게”를 표현할 때도 멀티캐스트 주소(ff02::1)를 씁니다.

2000::/3은 현재 인터넷에서 실제 사용되는 글로벌 유니캐스트 주소 대역입니다. 대부분의 IPv6 공인 주소가 이 안에 있어요.

URL에서의 IPv6 표기

IPv6 주소를 URL에 적을 때는 한 가지 함정이 있습니다. 주소에 콜론(:)이 잔뜩 들어 있는데, URL에서는 콜론이 호스트와 포트를 구분하는 용도로도 쓰이거든요. 그래서 그냥 적으면 어디까지가 주소이고 어디서부터가 포트인지 모호해집니다.

이 충돌을 피하기 위해 URL에서는 IPv6 주소를 대괄호 [ ]로 감쌉니다.

IPv6 URL 예시
http://[2001:db8::1]:8080/path
https://[::1]:3000/health

대괄호 안이 IPv6 주소 부분이고, 바깥쪽 콜론 다음에 오는 숫자가 포트 번호라는 약속입니다. 서버를 IPv6로 띄울 때 이 표기법은 자주 마주치니까 익숙해지면 좋아요.

듀얼 스택과 전환의 현실

IPv6가 1998년에 RFC 2460으로 표준이 됐는데도 인터넷은 여전히 IPv4 위에서 많이 돌아갑니다. 바로 전환하기엔 기존 인프라와 장비, 소프트웨어가 너무 많아서, 두 프로토콜을 동시에 운용하는 듀얼 스택(dual stack) 방식이 현실적인 절충안이 됐어요.

서버는 IPv4와 IPv6 양쪽으로 응답할 수 있도록 설정되고, 클라이언트는 가능하면 IPv6로 먼저 시도하다가 안 되면 IPv4로 폴백합니다. DNS에서도 IPv4용 A 레코드와 IPv6용 AAAA 레코드를 함께 게시하는 방식으로 양쪽을 지원하죠.

실제로 우리 컴퓨터에서 ping6 google.com이나 dig AAAA google.com을 해보면 IPv6 주소가 잡힙니다. 주요 클라우드 사업자, 대형 사이트 대부분이 이미 IPv6로 응답할 준비가 되어 있는데, 막상 우리가 평소 보는 도메인은 여전히 IPv4 주소로 접속하는 경우가 많은 게 사실이에요. 가정용 인터넷의 IPv6 지원이 나라와 통신사마다 들쭉날쭉하기 때문이기도 하고, 운영자 입장에서 IPv6 전용 서비스를 운영할 동기가 아직 충분하지 않기 때문이기도 합니다.

마치며

IPv6는 단순히 IPv4의 더 큰 버전이 아니라, 주소 부족 외에도 자동 설정, 헤더 단순화, NAT 의존도 감소처럼 여러 부분을 새로 다듬은 프로토콜입니다. 콜론 표기와 압축 규칙만 익혀두면 로그에서 ::1이나 2001:db8::ff00을 마주쳐도 더 이상 당황하지 않게 될 거예요.

당장 모든 환경이 IPv6로 옮겨가지는 않더라도, 클라우드 콘솔이나 컨테이너 네트워크에서 IPv6 주소를 다뤄야 할 일은 점점 늘고 있습니다. 듀얼 스택 환경이 한동안 표준일 테니, IPv4와 IPv6의 차이를 함께 이해해 두면 트러블슈팅이 한결 수월해질 겁니다.

더 깊이 들여다보고 싶다면 RFC 8200이 IPv6의 현행 명세를 담고 있으니 참고해 보세요.

This work is licensed under CC BY 4.0 CC BY

개발자를 위한 뉴스레터

달레가 정리한 AI 개발 트렌드와 직접 만든 콘텐츠를 전해드립니다.

Discord