junyeokk
Blog
Network·2025. 06. 13

IPv6

IPv6가 필요했던 이유

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.16.19.png
  • IPv4 주소 고갈
    • 32비트 주소 체계, 약 43억개 주소 제공
    • PC, 스마트폰, IoT 기기 등 장치 수 폭증
    • 결과적으로 부족해짐
    • 제일 큰 이유
  • 헤더 처리의 속도 개선
    • IPv4는 가변 길이 헤더를 가지고 있어 처리 속도에 부담이 있음
    • IPv6는 40바이트 고정 길이 헤더 사용
      • 라우터가 헤더를 해석하고 처리하는 데 더 빠름
      • ex, 체크섬 제거 → 라우터에서 계산할 필요 없음
  • 플로우 기반 트래픽 제어 기능
    • IPv6 헤더는 flow label이라는 필드가 있음
      • flow는 아직 명확한 개념은 아니지만, QoS를 향상시키는 기반 기능으로 설계됨
    • 특정 플로우에 맞춘 네트워크 처리 가능
    • IPv4의 한계를 기술적으로 커버하지만 아직 완전히 대체하진 못함
      • 터널링, 이중 스택, NAT64와 같은 기술이 함께 사용됨
%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.35.21.png
  • 크게 두 부분으로 나뉨
    • Header(헤더): 고정 40바이트
    • Payload(페이로드): 전송할 실제 데이터
  • IPv6 헤더 필드 구성
    • 전체적으로 구성이 간결해짐
    • ver IP 버전
    • pri 우선순위 - 같은 플로우 내 여러 패킷 중 우선 처리할 것 표시
    • flow label 플로우 식별자 - 같은 흐름에 속한 패킷들을 구분 (QoS 가능)
    • payload len 페이로드(데이터) 길이
    • next header 다음 계층 프로토콜 (ex, TCP, UDP, ICMPv6)
    • hop limit TTL과 동일, 라우터 지날 때마다 감소, 0되면 폐기
    • source address 출발지 IPv6 주소 (128비트)
    • destination address 목적지 IPv6 주소 (128비트)
  • IPv4에는 있지만 IPv6에서 빠진 것들
    • checksum 라우터에서 계산할 필요 없게 해 속도 향상
    • fragmentation 출발지에서만 fragmentation(단편화) 허용하게 해 라우터 부담 줄임
    • option extension header로 분리해 필요할 때만 사용
  • flow label
    • 같은 스트림 (ex, 영상 스트리밍, 화상 통화 등) 패킷을 식별하기 위해 사용
    • 하지만 아직까지는 실제 네트워크에서 거의 사용되지 않음
    • 표준은 있지만 사용 예가 적어서 not well defined 라고 표현

IPv6로의 전환

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.46.17.png
  • 한 번에 모두 IPv6로 변경하는 것은 불가능, 이를 no flag day라 표현
    • 즉 IPv4와 IPv6는 동시에 동작해야 함
    • 그러면 IPv6만 이해하는 장비와 IPv4만 사용하는 네트워크 구간이 있을 때, IPv6 패킷이 IPv4만 가능한 구간을 지나가야 한다면?
  • 해법 중 하나가 tunneling(터널링)
    • 하나의 프로토콜 데이터를 다른 프로토콜의 페이로드로 감싸서 전송하는 것
      • 여기에서는 IPv6 네트워크 구간 간 통신을 IPv4 기반 네트워크를 통해 이어줌
    • 이 과정을 캡슐화라고도 함
    • IPv6 헤더 + 데이터 전체를 IPv4의 데이터 부분에 넣고, IPv4 라우터들은 일반 IPv4 패킷으로 취급

터널링과 캡슐화

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.57.31.png
  • 일반적인 연결 시나리오 (IPv6 ↔ IPv6 직접)
    • A와 B는 IPv6 라우터
    • E와 F는 물리적으로 연결된 링크 계층 (Ethernet 등)
    • 이 경우는 별다른 이슈 없이 IPv6 패킷을 그대로 Ethernet 프레임에 담아 전달 가능
    • Encapsulation은 IPv6 → Ethernet 수준에서만 발생
%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_5.59.03.png
  • IPv6 ↔ IPv6 간 중간에 IPv4 네트워크가 있는 시나리오
    • A와 B는 IPv6 라우터이지만, 둘 사이에 IPv4밖에 없는 네트워크 구간이 있음
    • 이럴 경우 A는 IPv6 패킷을 IPv4 패킷으로 감싸서 전송해야 함
      • IPv6 전체를 IPv4 데이터(payload)에 넣음
      • 목적지 B에서 다시 IPv6를 꺼내서(디캡슐화) 사용

터널링 동작에 대한 물리적 관점

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_7.28.14.png
  • A ~ F 모두 IPv6 주소를 갖는 노드
    • A-to-B IPv6 패킷 생성, src: A, dest: F, IPv6만 사용해 그대로 전달 가능
    • E-to-F 터널 끝 지점을 알고 IPv4 header 제거, 내부 IPv6 패킷을 꺼내 F로 보냄
  • B ~ E 사이 구간은 IPv4 네트워크만 제공됨
    • B-to-C 중간이 IPv4-only임을 알고 IPv6 패킷을 IPv4로 감싸서 보냄. src: B, dest: E (터널 입구와 출구 주소)
    • C-to-D, D-to-E src: B, dest: E, 내부에 숨겨진 IPv6는 변하지 않음
  • 그래서 그 사이에서는 IPv6 패킷을 IPv4로 감싸서 보내야 함 (터널)
    • 전체 흐름은 IPv6 플로우처럼 보이지만, 중간은 IPv4 터널을 통한 전달이 포함됨
  • 실제로는 패킷이 B → C → D → E를 지나가며 IPv4 패킷으로 전송됨
    • 이 구간에서는 IPv6 패킷이 IPv4 패킷의 payload로 들어가 있음

IPv6 도입

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_7.37.21.png %E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-08_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_7.39.09.png
  • Google 통계 기준, 약 30%의 클라이언트가 IPv6를 통해 구글 서비스에 접속하고 있음
  • 미국 정부(NIST) 기준, 미국 정부 도메인의 약 1/3이 IPv6를 지원
  • 왜 도입 속도가 느린가?
    • IPv4 장비는 대부분 IPv6를 지원하지 않음 (펌웨어/하드웨어 업그레이드 필요)
    • NAT, DHCP 등을 통해 IPv4 주소를 재활용해 연명 중
    • IPv4와 IPv6 둘 다 지원하려면 시스템 복잡도 증가

IPv4와 IPv6의 공존

현재 인터넷은 IPv4와 IPv6가 공존하는 이중 스택(Dual Stack) 시대다. 대부분의 현대 운영체제와 네트워크 장비는 두 프로토콜을 모두 지원한다.

IPv6 전용 네트워크에서 IPv4 전용 서버에 접근해야 할 때는 NAT64가 사용된다. NAT64는 IPv6 주소를 IPv4 주소로 변환해서 통신을 중개한다. 반대로 DNS64는 IPv4 전용 서버의 A 레코드를 합성된 AAAA 레코드로 변환해서 IPv6 클라이언트가 접근할 수 있게 한다.

모바일 네트워크에서는 IPv6 도입이 더 빠르게 진행되고 있다. 새로 구축되는 LTE, 5G 네트워크는 처음부터 IPv6를 기본으로 설계하는 경우가 많다. IPv4 주소 부족 문제가 모바일에서 특히 심각하기 때문이다.

미래 전망

IPv6로의 완전한 전환은 수십 년이 걸릴 것으로 예상된다. IPv4 인프라에 대한 투자가 너무 크고, "작동하는 것을 굳이 바꿀 필요가 있는가"라는 관성이 있기 때문이다.

하지만 IoT 기기의 폭발적 증가, 5G/6G 네트워크 확산, 클라우드 네이티브 인프라의 성장으로 IPv6의 필요성은 계속 커지고 있다. 새로운 서비스와 인프라는 점점 더 IPv6를 기본으로 설계되고 있으며, IPv4는 레거시 호환성을 위해 유지되는 방향으로 진화할 것이다.