IPv6 Transition Mechanisms Reference

1. 전환 메커니즘이 존재하는 이유

IPv4 주소 고갈은 2011년 2월에 IANA 수준에 도달했습니다. RIR 여유 풀 고갈이 이어졌습니다(APNIC 2011, RIPE NCC 2012, ARIN 2015, LACNIC 2014, AFRINIC 2021). ISP는 이제 캐리어급 NAT(CGN)를 사용하여 여러 고객 간에 단일 IPv4 주소를 공유하지만 운영 복잡성, 포트 할당 오버헤드 및 종단 간 연결 가능성 손실이 발생합니다.

장기적인 솔루션은 기본입니다듀얼 스택또는 IPv6 전용 네트워킹. 전환 메커니즘은 마이그레이션이 진행되는 동안 IPv6 네트워크가 IPv4 콘텐츠에 도달할 수 있게 하거나 IPv4 인프라를 통해 IPv6 서비스가 배포될 수 있도록 하는 브리지입니다.

2. IPv6-over-IPv4 터널 메커니즘

6위 — IPv6 신속한 배포(RFC 5969)

무국적 배포됨

ISP는 /32 이하의 IPv6 접두사를 할당하고 각 고객의 IPv4 주소를 하위 비트에 포함하여 /56 또는 /60 고객 접두사를 파생시킵니다. CPE(6rd CE)는 ISP의 6번째 BR(Border Relay)로 주소가 지정된 IPv4(proto 41)에 IPv6 패킷을 캡슐화합니다. 반환 트래픽은 BR에서 캡슐화 해제됩니다.

• 사용 사례:IPv6 연결을 신속하게 배포하는 IPv4 액세스 네트워크를 갖춘 ISP입니다. Free(프랑스)는 RFC가 게시되기 전인 2007년에 이를 대규모로 배포했습니다.
• 주요 제한사항:액세스 계층에서는 여전히 IPv4를 사용합니다. 패킷당 최대 20바이트의 오버헤드가 발생합니다.

6in4 수동 터널(RFC 4213)

무국적

두 개의 고정 끝점 사이에 수동으로 구성된 지점 간 IPv6-in-IPv4 터널(프로토콜 번호 41). 여전히 엔터프라이즈 연구실 연결 및 Hurricane Electric의 TunnelBroker 서비스에 사용됩니다.

3. NAT64 + DNS64

상태 저장 널리 배포됨

NAT64 (RFC 6146)는 IPv6와 IPv4 간을 변환하는 게이트웨이입니다. IPv6 전용 클라이언트는 대상 IPv4 주소가 포함된 합성 IPv6 주소(NAT64 접두사, 일반적으로 64:ff9b::/96)로 패킷을 보냅니다. NAT64 게이트웨이는 헤더를 변환하고 상태 저장 세션 테이블을 유지 관리합니다.

DNS64 (RFC 6147)은 NAT64와 함께 작동합니다. IPv6 전용 클라이언트가 DNS에 A 레코드(IPv4)만 있는 이름을 쿼리하면 DNS64는 NAT64 접두사에 IPv4 주소를 삽입하여 AAAA 레코드를 합성합니다. 클라이언트는 합성된 주소에 연결한 다음 NAT64로 변환합니다.

4. 464XLAT

상태 저장(PLAT) 무국적(CLAT) 모바일/셀룰러 표준

464XLAT(RFC 6877)은 DNS64/DNSSEC 문제를 해결하고 IPv4 리터럴을 포함하는 앱도 처리합니다. 여기에는 두 가지 구성 요소가 있습니다.

• 클랏(고객측 번역기): 디바이스(휴대폰, 라우터)에서 실행됩니다. 프라이빗 IPv4 주소 공간을 합성하고, OS에서 IPv4 트래픽을 가로채고, NAT64 접두사를 대상으로 사용하여 이를 IPv6으로 변환합니다. 번역은 상태 비저장입니다(RFC 6145/RFC 7915 IVI 매핑).
• 작은 지면(공급자 측 변환기): ISP의 NAT64 게이트웨이입니다. CLAT에서 변환된 IPv6 패킷을 수신하고 다시 IPv4로 변환하여 실제 IPv4 인터넷에 연결합니다.

결과적으로 기기에서 실행되는 앱은 실제 IPv4 인터페이스를 볼 수 있습니다. IPv4 리터럴 연결이 작동합니다. DNSSEC가 작동합니다. IPv6 전용 LTE/5G 모바일 네트워크(T-Mobile US, 다수 EU 사업자)의 표준 모델입니다.

CLAT는 DNS를 통해 NAT64 접두사를 검색합니다(RFC 7050: ipv4only.arpa 쿼리) 또는 RA 옵션(RFC 8781PREF64 옵션).

5. DS-Lite — 듀얼 스택 라이트

상태 저장(AFTR) 광대역에서 일반적

DS-라이트(RFC 6333)은 여전히 ​​고객에게 IPv4를 제공해야 하는 IPv6 액세스 네트워크를 갖춘 ISP를 위해 설계되었습니다. CPE는 기본 IPv6 주소를 가져오지만 공용 IPv4는 가져오지 않습니다. 고객 LAN의 IPv4 트래픽은 IPv6(CPE의 B4 요소)에 캡슐화되어 ISP의 AFTR(Address Family Transition Router)로 전송됩니다.

AFTR은 공유 IPv4 풀에서 CGN(캐리어급 NAT)을 캡슐화 해제하고 수행합니다. IPv4 세션은 AFTR에서 추적됩니다. 액세스 루프에 IPv4가 없기 때문에 ISP는 IPv4 주소를 저장합니다. 액세스 네트워크는 기본 IPv6이므로 IPv6 트래픽은 변환 없이 빠른 경로를 사용합니다.

• 사용 사례:유럽 ​​케이블/DSL 운영업체(KPN, Swisscom 등).
• 주요 제한사항:IPv4 성능은 AFTR 용량에 따라 달라집니다. 가입자당 포트 할당은 최대 동시 연결을 제한합니다.

6. MAP-E와 MAP-T

무국적 배포 증가

MAP(주소 및 포트 매핑)는 IPv6 접두사에서 각 고객의 IPv4 주소와 포트 범위를 수학적으로 도출하여 CGN 세션 테이블을 제거하는 상태 비저장 변환/캡슐화 프레임워크입니다. Border Relay에는 세션별 상태가 없습니다. 간단한 라우터일 수도 있고 라인 카드 기능일 수도 있습니다.

• MAP-E (RFC 7597): IPv6에서 IPv4를 캡슐화합니다. CPE(MAP-E CE)는 IPv4 패킷을 IPv6에 캡슐화합니다. BR은 캡슐화를 해제합니다. 무국적.
• MAP-T (RFC 7599): 주소+포트 매핑 규칙을 사용하여 IPv4를 IPv6로(및 그 반대로) 변환합니다. 캡슐화 오버헤드가 없습니다. 헤더가 제자리에서 변환됩니다.

MAP는 제로 상태 BR이 확장에 매력적인 DOCSIS 3.1 및 PON 배포에서 점점 인기를 얻고 있습니다. 신중한 포트 범위 계획이 필요합니다. 각 CE는 IPv6 /56 접두사에서 파생된 제한된 포트 범위(예: 총 65536개 포트 중 1024~2047)를 가져옵니다.

7. 더 이상 사용되지 않는 메커니즘 — 사용하지 마세요

• 6to4 (RFC 3056, 더 이상 사용되지 않음RFC 7526): 애니캐스트 릴레이 접두사 192.88.99.0/24를 사용했습니다. 일관되지 않은 애니캐스트 릴레이 작동으로 인해 신뢰할 수 없고, NAT 뒤에 끊어지고, 주요 OS 공급업체에서 포기했습니다.
• 테레도 (RFC 4380): NAT 통과를 위한 UDP 기반 IPv6 터널링입니다. Vista SP1 및 Server 2008 이후 Windows에서는 기본적으로 비활성화되어 있습니다. 더 이상 권장되지 않습니다. 보안 문제(터널링된 트래픽은 Teredo를 검사하지 않는 IPv6 방화벽을 우회함)

8. 비교표

참고자료

• RFC 6555— Happy Eyeballs: 듀얼 스택 호스트를 통한 성공
• RFC 4213— IPv6 호스트 및 라우터(6in4)에 대한 기본 전환 메커니즘
• RFC 5969— IPv4 인프라에 IPv6 신속한 배포(6차)
• RFC 6146— 상태 저장 NAT64: IPv6 클라이언트에서 IPv4 서버로의 네트워크 주소 및 프로토콜 변환
• RFC 6147— DNS64: IPv6 클라이언트에서 IPv4 서버로의 네트워크 주소 변환을 위한 DNS 확장
• RFC 6333— IPv4 고갈 이후 듀얼 스택 라이트 광대역 배포
• RFC 6877— 464XLAT: 상태 저장 번역과 상태 비저장 번역의 결합
• RFC 7050— IPv6 주소 합성에 사용되는 IPv6 접두사 검색(ipv4only.arpa를 통한 NAT64 접두사 검색)
• RFC 7526— 6to4 릴레이 라우터에 대한 Anycast 접두사 지원 중단
• RFC 7597— 캡슐화를 통한 주소 및 포트 매핑(MAP-E)
• RFC 7599— 변환을 사용한 주소 및 포트 매핑(MAP-T)
• RFC 8781— 라우터 광고에서 PREF64 발견
• RFC 8585— IPv4-as-a-Service를 지원하기 위한 IPv6 고객 에지 라우터에 대한 요구 사항