IPv6 이행 메커니즘

IPv6 transition mechanism
IPv6 이행 메커니즘
표준 트랙
실험적인
정보
초안
권장되지 않음

IPv6 이행 메카니즘은, 1983년부터 사용되고 있는 Internet Protocol Version 4(IPv4) 인프라스트럭처로부터 Internet Protocol Version 6(IPv6)의 후계 어드레싱 및 라우팅 시스템으로의 인터넷 이행을 용이하게 하는 테크놀로지입니다.IPv4 네트워크와 IPv6 네트워크는 직접 상호 운용할 수 없기 때문에, 이행 테크놀로지는 어느 네트워크 타입의 호스트가 다른 호스트와 통신할 수 있도록 설계되어 있습니다.

기술적인 기준을 만족시키려면 , IPv6 는 현재의 IPv4 [1]로부터의 간단한 이행 계획을 가지고 있을 필요가 있습니다.Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)는 IETF Internet Drafts 및 Request for Comments 프로세스를 통해 작업 그룹과 논의를 실시하여 이러한 목표를 위한 이행 기술을 개발합니다.기본적인 IPv6 이행 메카니즘의 일부는, RFC 4213 에 정의되어 있습니다.

스테이트리스 IP/ICMP 변환

스테이트리스 IP/ICMP 변환(SIIT)은, IPv6 와 IPv4 [2]의 패킷 헤더 포맷을 변환합니다.SIIT 방식에서는, IPv4 [3]변환 주소라고 불리는 IPv6 주소의 클래스를 정의합니다.프리픽스 ::fff:0:0:0/96 이며, ::fff:0:a.b.c.d 로 쓸 수 있습니다.여기서 IPv4 형식의 주소 a.b.c.d 는 IPv6 대응 노드를 나타냅니다.전송 프로토콜 헤더 [4]체크섬이 변경되지 않도록 하기 위해 0 값 체크섬을 생성하도록 접두사가 선택되었습니다.이 알고리즘은, 영속적으로 할당된 IPv4 주소가 없는 IPv6 호스트가 IPv4 전용 호스트와 통신할 수 있도록 하는 솔루션에서 사용할 수 있습니다.주소 할당 및 라우팅 세부 정보는 사양에 따라 처리되지 않습니다.SIIT는 스테이트리스 네트워크주소 변환의 특수한 케이스로 간주할 수 있습니다.

이 사양은 NGTRANS IETF 작업 그룹의 산물이며, E에 의해 2000년 2월에 초안되었습니다.Sun Microsystems의 [5]Nordmark.2011년에 [6]개정되어 2016년에 개정판이 [4]발행되었습니다.

터널 브로커

터널 브로커는 IPv4 인터넷 중계 링크에 IPv6 트래픽을 캡슐화하여 IPv6 연결을 제공합니다(일반적으로 6in4 사용).이것에 의해, IPv4 인터넷내에 IPv6 터널이 확립됩니다.터널은 Tunnel Setup Protocol(TSP)[7] 또는 [8]AYYA를 사용하여 관리할 수 있습니다.

여섯 번째

주요 기사: IPv6의 신속한 도입

6번째는 Internet Service Provider(ISP; 인터넷서비스 프로바이더)의 IPv4 인프라스트럭처에 IPv6 서비스를 신속히 도입하기 위한 메커니즘입니다.IPv4 주소와 IPv6 주소 간의 스테이트리스 주소 매핑을 사용하고, IPv4 패킷과 같이 고객 노드 간에 최적화된 경로를 따르는 자동 터널을 통해 IPv6 패킷을 전송합니다.

2007년(RFC 5569[9])에 네이티브주소를 가지는 IPv6 서비스의 조기 대규모 전개에 사용되었습니다.이 프로토콜의 표준 트랙 사양은 RFC 5969에 [10]있습니다.

트랜스포트 릴레이 변환

RFC 3142에서는 Transport Relay Translation(TRT; 트랜스포트 릴레이 변환) 방식이 정의되어 있습니다.TRT는 AAAA와 DNS-ALG로 알려진A 레코드 간의 DNS 변환을 RFC 2694에 정의되어 있습니다.

NAT64

주요 기사: NAT64
NAT64 및 DNS64.

NAT64 는, IPv6 호스트와 IPv4 서버와의 통신을 가능하게 하는 메카니즘입니다.NAT64 서버는, 32 비트의 IPv4 주소 및 IPv6 네트워크 세그먼트(64:ff9b::/96 [3]등)의 엔드 포인트입니다.IPv6 클라이언트는, 이러한 비트를 사용해 통신하는 IPv4 주소를 짜넣고, 그 패킷을 그 결과 주소로 송신합니다.NAT64 서버는, IPv6 주소와 IPv4 주소 사이에 NAT 매핑을 작성해, [11]통신을 가능하게 합니다.

DNS64

DNS64는 도메인의 AAAA 레코드를 요구받았을 때 A 레코드만 찾으면 A 레코드로부터 AAAA 레코드를 합성하는 DNS 서버를 기술합니다.합성된 IPv6 주소의 첫 번째 부분은 IPv6/IPv4 변환기를 가리키고 두 번째 부분은 A 레코드에서 IPv4 주소를 포함합니다.문제의 트랜슬레이터는 보통 NAT64 서버입니다.DNS64의 표준 트랙 사양은 RFC 6147에 [12]기재되어 있습니다.

이 이행 메커니즘에는 다음 두 가지 중요한 문제가 있습니다.

  • 이 기능은, DNS 를 사용해 리모트호스트 주소를 검색하는 경우에만 기능합니다.IPv4 리터럴을 사용하는 경우, DNS64 서버는 관여하지 않습니다.
  • DNS64 서버는 도메인 소유자가 지정하지 않은 레코드를 반환해야 하므로 변환을 수행하는 DNS 서버가 도메인 소유자의 서버가 아닌 경우 루트에 대한 DNSSEC 검증이 실패합니다.
# DNS 리졸바 2606:4700:4700:64는 다음 AAAA 레코드를 합성합니다. # ipv6test.google.com에서 NAT64 주소로: 64::ff9b::<original-timeout4> nslookup ipv6test.google.com 2606:4700:4700:64  비권위적인 답변: ipv6test.google.com 표준 이름 = ipv6test.l.google.com. 이름.:ipv6test.l.google.com 주소.: 64:ff9b::8efa:c3e4

ISATAP

주요 기사: ISATAP

ISATAP(Intra-Site Automatic Tunnel Addressing Protocol)는 IPv4 네트워크 상의 듀얼 스택노드 간에 IPv6 패킷을 송신하는 것을 목적으로 하는 IPv6 이행 메커니즘입니다.

6over4(IPv4 멀티 캐스트를 사용하는 오래된 유사 프로토콜)와는 달리, ISATAP 는 IPv4 를 가상 Nonbroadcast Multiple-Access Network(NBMA; 비브로드캐스트멀티 액세스 네트워크) 데이터 링크 레이어로서 사용합니다.따라서, 멀티 캐스트를 서포트하기 위해서, 기반이 되는 IPv4 네트워크인프라스트럭처가 필요 없습니다.

464XLAT

464XLAT(RFC 6877)를 사용하면,[13][14] IPv6 전용 네트워크의 클라이언트는 Skype 와 같은 IPv4 전용의 인터넷 서비스에 액세스 할 수 있습니다.

클라이언트는 SIIT 트랜슬레이터를 사용하여 패킷을 IPv4에서IPv6로 변환합니다.그런 다음 NAT64 트랜슬레이터로 전송되고, NAT64 트랜슬레이터는 IPv6에서 IPv4로 변환되어 IPv4 전용 서버로 변환됩니다.클라이언트 트랜슬레이터는 클라이언트 자체 또는 중간 디바이스에 실장할 수 있으며 CLAT(고객측 트랜슬레이터)라고 불립니다.LATor). NAT64 변환기(PLAT)(CLAT를 통해) 서버와 클라이언트 모두에 도달할 수 있어야 합니다.NAT64 를 사용하면, 접속이 UDP, TCP, 및 ICMP 를 사용하는 클라이언트 서버 모델로 제한됩니다.

실장
  • Android, Android CLAT에 대한 CLAT 구현이 있습니다.T-Mobile USA는 NAT64에 T-Mobile의 IPv6 전용 [15][unreliable source?]서비스를 제공합니다.
  • Orange 폴란드는 2013년 [16]9월에 IPv6 전용(CLAT/NAT64/DNS) 서비스를 시작했습니다.
  • Android는 2013년 출시된 젤리빈 4.3 이후 CLAT를 네이티브로 구현하고 있습니다.
  • Windows Phone은 2014년에 WP 8.1과 [17]함께 네이티브 CLAT 구현을 도입했습니다.
  • Windows 10에는 네이티브 464X가 탑재되어 있습니다.2017년 Creators Update 이후 데스크톱 및 모바일용 LAT 구현.Mobile Operator 가 [18][19]네트워크상에서 464XLAT 를 유효하게 하고 있는 경우, WWAN 인터페이스에 대해서 유효하게 됩니다.
  • iOS는 2018년에 [20]출시된 버전 12.0 이후 기본 CLAT를 구현했습니다.또한 Apple은 App Store에 제출된 모든 앱이 IPv6 네트워크에서 [21]작동하도록 요구합니다.
  • clatd는 Linux용 CLAT 구현입니다.
  • FreeBSD는 11.3 및 12.[22]1 이후 CLAT를 구현하고 있습니다.

듀얼 스택 라이트(DS-Lite)

"DS-Lite"는 여기서 리다이렉트 됩니다.2006년 비디오 게임 시스템은 닌텐도 DS Lite를 참조하십시오.
DS-Lite

듀얼 스택 라이트테크놀로지에서는, 인터넷 액세스를 제공하기 [23]위해서, IPv4 주소를 Customer-Premises Equipment(CPE; 고객 전용 기기)에 할당할 필요가 없습니다.CPE 는, LAN 클라이언트의 프라이빗 IPv4 주소를, 로컬 에리어 네트워크의 네트워크 요건에 따라서 배포합니다.CPE 는, IPv6 패킷내에 IPv4 패킷을 캡슐화합니다.CPE 는, 글로벌 IPv6 접속을 사용하고, 글로벌 IPv4 주소를 가지는 ISP 의 Carrier-Grade NAT(CGN; 캐리어 그레이드 NAT) 에 패킷을 전달합니다.원래의 IPv4 패킷이 회복되어 IPv4 패킷에 대해서 NAT 가 실행되어 퍼블릭 IPv4 인터넷에 라우팅 됩니다.CGN은 CPE 퍼블릭 IPv6 주소, 프라이빗 IPv4 주소 및 TCP 또는 UDP 포트 번호를 세션으로 기록함으로써 트래픽플로우를 일의로 식별합니다.

Lightweight 4 over6에서는 NAT 기능을 ISP 측에서 CPE로 이동함으로써 DS-Lite를 확장하므로 캐리어 그레이드 [24]NAT을 구현할 필요가 없습니다.이것은, 공유 IPv4 주소의 포토 범위를 각 CPE 에 할당하는 것으로 실현됩니다.NAT 기능을 CPE로 이동하면 ISP는 각 서브스크라이버에 대해 추적되는 스테이트의 양을 줄일 수 있기 때문에 변환 인프라스트럭처의 scalability가 향상됩니다.

V4-v6 라우팅

V4-via-v6 라우팅은 IPv4 주소가 엔드호스트에만 할당되고 중간 라우터에는 IPv6 주소만 할당되는 기술입니다.IPv4 루트는 통상대로 전파되며 패킷 변환이나 캡슐화는 사용되지 않지만 IPv6 넥스트홉을 사용합니다.코어 네트워크에는 IPv6 주소만 할당하면 되지만 코어 네트워크는 IPv4 패킷을 전송할 수 있어야 하므로 V4-v6는 필요한 관리량을 줄입니다.

V4-via-v6는 BGP([25]Border Gateway Protocol) 및 Babel 라우팅 [26]프로토콜용으로 정의됩니다.Bird Internet 라우팅[27] 데몬 및 [28]babeld에 구현되어 있습니다.

제안서 초안

다음 메커니즘은 IETF에 의해 아직 논의 중이거나 포기되었습니다.

넷째

IPv4 잔존 전개(4rd)는, IPv6 네트워크 전체에 IPv4 서비스를 잔존 전개하기 위한 실험적인[29] 메카니즘입니다.6번째와 마찬가지로 IPv6과 IPv4 간에 상태 비저장 주소 매핑을 사용합니다.트랜스포트 레이어 포토에 근거하는 IPv4 어드레싱의 확장을 서포트합니다.이것은 A+P 모델의 스테이트리스 바리안트입니다.

맵

Mapping of Address and Port(MAP)는 A+P 포트 주소 변환과 ISP 프로바이더의 내부 IPv6 [30]네트워크상의 IPv4 패킷의 터널링을 조합한 Cisco IPv6 이행 제안입니다.2015년 7월 현재, MAP-T와[31] MAP-E는[32] 제안된 표준이다.

폐지된 메커니즘

다음 메커니즘은 IETF에 의해 폐지되었습니다.

NAT-PT

Network Address Translation/Protocol Translation(NAT-PT; 네트워크주소 변환/프로토콜 변환)은 RFC 2766에 정의되어 있지만, 많은 문제로 인해 RFC 4966에 의해 폐지되어 이력 상태로 대체되고 있습니다.일반적으로 DNS Application-Level Gateway(DNS-ALG; 응용 프로그램레벨 게이트웨이) 구현과 함께 사용됩니다.

NAPT-PT

Network Address Port Translation + Protocol Translation 은 NAT-PT 와 거의 동일하지만, RFC 2766 에도 기술되어 있습니다.또, 포토와 주소의 변환을 추가합니다.이는 주로 메커니즘 한쪽의 2개의 호스트가 메커니즘 반대쪽의 동일한 노출 포트를 사용하지 않도록 하기 위한 것으로, 이로 인해 애플리케이션의 불안정성과 보안 결함이 발생할 수 있습니다.이 메커니즘은 RFC 4966에 의해 폐지되었습니다.

실장

  • Windows 및 Unix 기반 시스템용 포트 트랜슬레이터.
  • Faithd, KAME 프로젝트에 의한 BSD 기반의 정적 TRT 구현
  • CLATD, Linux용 CLAT/SIIT-DC 엣지 릴레이 구현
  • 리눅스용 NAT64 구현인 WrapSix
  • 리눅스용 상태 비저장 NAT64 구현인 TAYGA
  • Jool, 리눅스용 스테이트풀 NAT64 구현
  • naptd, 사용자 레벨 NAT-PT
  • NAT64 게이트웨이인 Ecdysis에는 DNS64가 포함되어 있습니다.
  • Address Family Transition Router(AFTR; 어드레스 패밀리 전환 라우터), DS-Lite 구현
  • IPv6 네트워크를 통해 IPv4 유니캐스트 트래픽을 전송할 수 있는 niit Linux 커널 디바이스
  • Linux 커널(2.6 한정) 패치로서의 IVI IPv4/IPv6 패킷 변환 실장
  • DNS64 및 NAT64를 구현하는 리버스 프록시 및 VPN 솔루션인 Microsoft Forefront Unified Access Gateway
  • 버클리 인터넷 이름 도메인 DNS 서버인 BIND는 버전 9.8 이후 DNS64를 구현합니다.
  • 버전 5.1 이후의 IP 버전 변환을 지원하는 OpenBSD 패킷필터인 PF(방화벽)는 NAT64를 포함합니다.

「 」를 참조해 주세요.

레퍼런스

  • IPv6 실무, Benedikt Stockebrand(2006), ISBN3-540-24524-3
  • RFC 2767, Bump-in-the-Stack
  • RFC 3338, Bump-in-the-API
  • RFC 3089, 삭스 기반 게이트웨이
  • RFC 6219, IPv4/IPv6의 공존과 이행을 위한 중국 교육 및 연구 네트워크(CERNET) IVI 번역 설계 및 배치
  1. ^ Partridge, C.; Kastenholz, F. (December 1994). Technical Criteria for Choosing IP The Next Generation (IPng). doi:10.17487/RFC1726. RFC 1726.
  2. ^ F. Baker; X. Li; C. Bao; K. Yin (April 2011). Framework for IPv4/IPv6 Translation. Internet Engineering Task Force (IETF). doi:10.17487/RFC6144. ISSN 2070-1721. RFC 6144.
  3. ^ a b C. Bao; C. Huitema; M. Bagnulo; M. Boucadair; X. Li (October 2010). IPv6 Addressing of IPv4/IPv6 Translators. IETF. doi:10.17487/RFC6052. ISSN 2070-1721. RFC 6052. RFC 4291을 갱신합니다.
  4. ^ a b C. Bao; X. Li; F. Baker; T. Anderson; F. Gont (June 2016). Stateless IP/ICMP Translation Algorithm. doi:10.17487/RFC7915. RFC 7915.
  5. ^ E. Nordmark (February 2000). Stateless IP/ICMP Translation Algorithm (SIIT). Network Working Group. doi:10.17487/RFC2765. RFC 2765. RFC 6145에 의해 폐지되었습니다.
  6. ^ X. Li; C. Bao; F. Baker (April 2011). IP/ICMP Translation Algorithm. Internet Engineering Task Force (IETF). doi:10.17487/RFC6145. ISSN 2070-1721. RFC 6145. RFC 7915에 의해 폐지되었습니다.RFC 6791 및 7757에 의해 갱신되었습니다.
  7. ^ M. Blanchet; F. Parent (February 2010). IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). doi:10.17487/RFC5572. ISSN 2070-1721. RFC 5572.
  8. ^ A. Durand; P. Fasano; I. Guardini; D. Lento (January 2001). IPv6 Tunnel Broker. Network Working Group. doi:10.17487/RFC3053. RFC 3053.
  9. ^ Despres, R. (January 2010). IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). doi:10.17487/RFC5569. RFC 5569.
  10. ^ Troan, O. (August 2010). IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification. doi:10.17487/RFC5969. RFC 5969.
  11. ^ M. Bagnulo; P. Matthews; I. van Beijnum (April 2011). Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. Internet Engineering Task Force (IETF). doi:10.17487/RFC6146. ISSN 2070-1721. RFC 6146.
  12. ^ Bagnulo, M.; Sullivan, A.; Matthews, P.; van Beijnum, I. (April 2011). DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. doi:10.17487/RFC6147. RFC 6147.
  13. ^ "Video: 464XLAT Live Demo at World IPv6 Congress in Paris". Internet Society. 3 April 2013.
  14. ^ "464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network". T-Mobile USA. Retrieved 5 August 2013.
  15. ^ "T-Mobile IPv6 is Here and Now". T-Mobile USA. Retrieved 5 August 2013.
  16. ^ Orange Polska # 모바일 네트워크
  17. ^ "Windows Phone Hardware Development".
  18. ^ "Core Network Stack Features in the Creators Update for Windows 10". Retrieved 26 July 2017.
  19. ^ "Win10 update CLAT". Retrieved 9 August 2017.
  20. ^ "[v6ops] iOS12 IPv6-only". Retrieved 5 November 2018.
  21. ^ van Beijnum, Iljitsch (2015-06-16). "Apple to iOS devs: IPv6-only cell service is coming soon, get your apps ready". Ars Technica. Retrieved 2 July 2016.
  22. ^ "D19561 NAT64 update". FreeBSD phabricator.
  23. ^ A. Durand; R. Droms; J. Woodyatt; Y. Lee (August 2011). Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion. Internet Engineering Task Force (IETF). doi:10.17487/RFC6333. ISSN 2070-1721. RFC 6333.
  24. ^ Y. Cui; Q. Sun; M. Boucadair; T. Tsou; Y. Lee; I. Farrer (July 2015). Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture. Internet Engineering Task Force (IETF). doi:10.17487/RFC7596. ISSN 2070-1721. RFC 7596.
  25. ^ Le Faucheur, François; Rosen, Eric (May 2009). Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop. doi:10.17487/RFC5549. RFC 5549.
  26. ^ Chroboczek, Juliusz (May 2022). Pv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol. doi:10.17487/RFC9229. RFC 9229.
  27. ^ https://bird.network.cz/pipermail/bird-users/2020-December/015082.html
  28. ^ https://alioth-lists.debian.net/pipermail/babel-users/2022-May/003963.html
  29. ^ R. Despres; R. Penno; Y. Lee; G. Chen; M. Chen (July 2015). S. Jiang (ed.). IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd). Internet Engineering Task Force (IETF). doi:10.17487/RFC7600. ISSN 2070-1721. RFC 7600.
  30. ^ Mark Townsley (September 24, 2012). "Mapping Address + Port" (PDF). Cisco. Retrieved 2012-09-25.
  31. ^ X. Li; C. Bao; O. Troan; S. Matsushima; T. Murakami (July 2015). W. Dec (ed.). Mapping of Address and Port using Translation (MAP-T). Internet Engineering Task Force (IETF). doi:10.17487/RFC7599. ISSN 2070-1721. RFC 7599.
  32. ^ W. Dec; X. Li; C. Bao; S. Matsushima; T. Murakami (July 2015). O. Troan; T. Taylor (eds.). Mapping of Address and Port with Encapsulation (MAP-E). Internet Engineering Task Force (IETF). doi:10.17487/RFC7597. ISSN 2070-1721. RFC 7597.

외부 링크