본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
이 문서에서는 NAT(Network Address Translation)를 이해하고 구성하는 방법에 대해 설명합니다.
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
NAT64는 IPv4-IPv6 전환 및 IPv4-IPv6 동시 사용을 위한 메커니즘입니다. DNS64와 함께 NAT64의 주요 목적은 IPv6 전용 클라이언트가 IPv4 전용 서버와의 통신을 시작하도록 허용하는 것입니다. NAT64는 고정 또는 수동 바인딩을 사용하여 IPv6 전용 서버와의 통신을 시작하는 IPv4 전용 클라이언트에도 사용할 수 있습니다. 이 문서에서는 두 가지 시나리오에 대해 설명합니다.
IPv6는 IPv4와 역호환이 되지 않으므로 3가지 클래스 중 하나에 속하는 전환 메커니즘이 필요합니다.
다른 전환 방법#Like 변환은 장기적인 전략이 아니며 궁극적인 목표는 네이티브 IPv6가 될 수 있습니다. 그러나 변환은 터널링에 비해 두 가지 주요 장점을 제공합니다.
스테이트리스 NAT64에서는 상태가 보존되지 않으므로 모든 IPv6 사용자에게 전용 IPv4 주소가 필요합니다. 현재 IPv4 depletion 단계이므로 NAT64 모드를 채택하는 것은 매우 어렵습니다. IPv6 주소 수가 적은 경우 스테이트리스 NAT64를 사용할 때의 유일한 장점(NAT46).
스테이트풀 NAT64에서는 상태가 유지됩니다. 단일 IP 주소는 포트 번호가 다른 모든 개인 사용자에게 사용됩니다. 이전 다이어그램에서 단일 IPv4 주소는 공용 IPv4 서버에 액세스하기 위해 해당 LAN에 있는 모든 IPv6 사용자에 대해 서로 다른 포트 번호와 함께 사용됩니다.
상태 저장 NAT64 변환과 상태 비저장 NAT64 변환의 차이에 대한 자세한 내용은 다음과 같습니다.
스테이트리스 NAT64 |
상태 저장 NAT64 |
1:1 번역 |
1:N 번역 |
IPv4 주소 보존 안 함 |
IPv4 주소 보존 |
엔드 투 엔드 주소 투명성 및 확장성 보장 |
주소 오버로드를 사용하므로 엔드 투 엔드 주소 투명성이 결여됨 |
변환에 상태 또는 바인딩이 생성되지 않았습니다. |
모든 고유 변환에 상태 또는 바인딩이 생성됩니다. |
IPv4 변환 가능 IPv6 주소 할당 필요(필수 요건) |
IPv6 주소 할당 특성에 대한 요구 사항 없음 |
IPv6 호스트에 대해 수동 또는 DHCPv6 기반 주소 할당 필요 |
IPv6 주소 할당의 모든 모드를 선택할 수 있습니다. 수동, DHCPv6, SLAAC |
NAT64에는 세 가지 주요 구성 요소가 있습니다.
1. 이전 그림에서 IPv6 네트워크에 있는 호스트가 IPv4 전용 서버인 웹 서버 www.example.com(10.1.113.2)와 통신하려고 한다고 가정합니다.
2. 이 통신을 가능하게 하려면 ipv4 요청에 대한 DNS를 이해하고 확인할 수 있는 DNS64 서버가 IPv6 네트워크에 설치되어 있어야 합니다.
3. DNS64 서버는 IPv6 AAAA 레코드에 대한 일반 DNS 서버로 작동하지만, AAAA 레코드를 사용할 수 없을 때 IPv4 A 레코드를 찾으려고 시도할 수도 있습니다. A 레코드가 있는 경우 DNS64는 NAT64 접두사를 사용하여 IPv4 A 레코드를 IPv6 AAAA 레코드로 변환합니다. 이는 IPv6 전용 호스트가 IPv6를 사용하여 서버와 통신할 수 있다는 인상을 줍니다.
4. 이제 www.example.com에 대한 DNS 확인 요청이 DNS64 서버로 전송됩니다. 먼저 IPv6 AAAA 레코드 테이블에서 조회하지만 이 웹 사이트 서버가 Ipv4 주소에 속하므로 IPv6 AAAA 레코드를 찾지 못합니다. 그런 다음 IPv4 데이터베이스를 검색하고 이 웹 사이트와 일치하는 IPv4 주소를 찾습니다. 이제 DNS64 서버는 이 IPv4 주소를 16진수로 변환하고 NAT64 접두사를 추가하여 이 IPv4 주소를 IPv6 주소로 변환할 수 있습니다. 이렇게 하면 IPv6 전용 호스트에서 IPv6를 사용하여 웹 서버와 통신할 수 있다는 인상을 줄 수 있습니다.
5. 패킷은 IPv4 주소의 16진수 값 앞에 추가된 NAT64 접두사를 사용하여 NAT64를 수행하는 디바이스로 IPv6 전용 네트워크에서 라우팅됩니다.
6. NAT64 라우터는 IPv6 전용 및 IPv4 전용 네트워크 간 변환을 수행할 때 NAT64 접두사를 IPv6 전용 네트워크에 광고합니다.
7. 패킷이 NAT64 변환을 수행하는 디바이스에 도달하면 패킷을 Nat64에 대해 구성한 ACL과 일치시킬 수 있습니다. 패킷이 이 ACL과 일치하면 NAT64를 더 사용하여 패킷을 변환할 수 있습니다. 패킷이 구성된 ACL과 일치하지 않으면 일반 IPv6 라우팅을 사용하여 목적지로 라우팅될 수 있습니다.
8. 스테이트풀 NAT64는 구성된 ACL(Access Control List) 및 접두사 목록을 사용하여 NAT64 상태를 생성할 수 있는 IPv6에서 시작된 트래픽 흐름을 필터링합니다. IPv6 패킷들의 필터링은 IPv6-to-IPv4 방향으로 행해지는데, 이는 IPv6 호스트와 IPv4 주소 사이의 매핑의 동적 할당이 이 이 방향에서만 행해질 수 있기 때문이다. 스테이트풀 NAT64는 PAT 컨피그레이션을 통해 IPv4-IPv6 패킷 흐름에 대한 엔드포인트 종속 필터링을 지원합니다.
9. 상태 기반 NAT64 PAT 컨피그레이션의 경우 패킷 흐름이 IPv6 영역에서 시작되고 NAT64 상태 테이블에 상태 정보를 생성해야 합니다. IPv4 측에서 이전에 생성한 상태가 없는 패킷은 삭제됩니다. 고정 NAT(Network Address Translation) 및 비 PAT 컨피그레이션에서는 엔드포인트에 독립적인 필터링이 지원됩니다.
첫 번째 IPv6 패킷은 스테이트풀 접두사에 대해 구성된 자동 라우팅 설정에 따라 NAT NVI(Virtual Interface)로 라우팅됩니다. 스테이트풀 NAT64는 일련의 조회를 수행하여 ACL(Access Control List) 조회를 기반으로 IPv6 패킷이 구성된 매핑과 일치하는지 여부를 확인합니다. 매핑을 기반으로 IPv4 주소(및 포트)는 IPv6 목적지 주소와 연결됩니다.
IPv6 패킷은 변환되고 IPv4 패킷은 다음 방법을 사용하여 구성됩니다.
10. 새 NAT64 변환이 세션 데이터베이스와 바인드 데이터베이스에 생성됩니다. 풀 및 포트 데이터베이스는 구성에 따라 업데이트됩니다.
11.IPv6 패킷 흐름의 반환 트래픽 및 후속 트래픽은 변환에 이 세션 데이터베이스 항목을 사용할 수 있습니다.
1단계. 호스트 A는 www.example.com 서버와 통신하려는 IPv6 전용 호스트입니다. 그러면 DNS 쿼리(AAAA: www.example.com)가 DNS64 서버로 트리거됩니다. DNS64는 이 프로세스의 핵심 구성 요소입니다. DNS64 서버는 IPv6 및 IPv4용 DNS 서버입니다. IPv6 주소를 사용하여 IPv4 서버에 연결할 수 있다는 착각이 클라이언트에 생깁니다.
호스트 A는 DNS 쿼리(AAAA: www.example.com)를 DNS64 서버로 전송합니다. 호스트 A에 관한 한, 이는 IPv6 서버에 대한 일반적인 DNS AAAA 쿼리입니다.
2단계. DNS64 서버는 호스트 A로부터 DNS AAAA 쿼리를 수신합니다. 도메인 이름을 확인하기 위해 DNS64 서버는 DNS AAAA 권한 서버에 www.example.com에 대한 쿼리를 전송합니다.
3단계. IPv6 DNS AAAA 권한 있는 서버는 www.example.com에 대한 AAAA 리소스 레코드가 없음을 나타내는 응답을 반환합니다.
4단계. AAAA 쿼리에 대한 빈 응답(이름 오류) 응답을 받으면 DNS64 서버가 IPv4 DNS A 권한 서버에 A 쿼리(A: www.example.com)를 보내도록 트리거됩니다.
5단계. IPv4 DNS A 권한 있는 서버에는 www.example.com에 대한 A 리소스 레코드가 있으며 서버의 IPv4 주소가 포함된 응답(A: www.example.com 10.1.113.2)을 반환합니다.
6단계. DNS64 서버는 DNS A 권한 있는 서버로부터 IPv4 주소를 수신하고 NAT64 접두사 2800:1503:2000:1:1::/96을 접두사로 붙여 AAAA 레코드를 합성하고 IPv4 주소를 16진수 0a01:7102로 변환합니다. 이 주소는 호스트 A에서 www.example.com 서버 도달을 위한 대상 IPv6 주소로 사용될 수 있습니다.
7단계. 합성된 AAAA 레코드는 호스트 A에 대해 완전히 투명합니다. 호스트 A에는 IPv6 네트워크 및 인터넷을 통해 www.example.com에 연결할 수 있는 것처럼 표시됩니다. 이제 호스트 A에 IPv6 패킷을 www.example.com으로 전송하는 데 필요한 주소 지정 정보가 있습니다.
8단계. NAT64 라우터는 NAT64 지원 인터페이스에서 호스트 A가 전송한 IPv6 패킷을 수신합니다. 수신 패킷을 구성된 ACL과 일치시킵니다. 일치가 발견되지 않으면 패킷이 일반 IPv6 라우팅을 사용하여 변환되지 않고 전달됩니다. 일치가 발견되면 패킷은 다음과 같이 변환됩니다.
9단계. NAT64 변환 후에는 변환된 IPv4 패킷이 일반 IPv4 경로 조회 프로세스를 사용하여 전달됩니다. 이 시나리오에서는 IPv4 목적지 주소 10.1.113.2를 사용하여 패킷을 전달합니다.
10단계. www.example.com 서버는 10.1.113.2에 응답하며, 이는 궁극적으로 NAT64 라우터에 의해 수신됩니다.
11단계. NAT64 라우터는 NAT64 지원 인터페이스 중 하나에서 www.example.com 서버로부터 IPv4 패킷을 수신합니다. 라우터는 IPv4 패킷을 검사하여 IPv4 수신 주소에 대한 NAT64 변환 상태가 존재하는지 확인합니다. 변환 상태가 존재하지 않으면 패킷이 폐기됩니다. IPv4 수신 주소에 대한 변환 상태가 존재하는 경우 NAT64 라우터는 다음 작업을 수행합니다.
12단계. 변환 후 IPv6 패킷은 일반 IPv6 경로 조회 프로세스를 사용하여 전달됩니다.
1. IPv6 연결 인터페이스:
2. IPv4 페이싱 인터페이스:
3. ipv6 트래픽과 일치하는 ACL을 생성합니다.
4. NAT64 IPv6-IPv4 주소 매핑을 활성화합니다.
#nat64 접두사 상태 저장 2800:1503:2000:1:1::/96 ---------------> 서버 IP는 이 ipv6 ip 주소로 매핑될 수 있습니다. 여기서 모든 ipv6 네트워크 주소를 구성할 수 있지만 이 ipv6 네트워크 주소는 ipv6 네트워크에서 연결할 수 있습니다. 또한 DNS64 서버는 이 ipv6 네트워크 주소를 서버 ipv4 주소에 매핑해야 합니다.
#ping 2800:1503:2000:1:1::0a01:7102
#show nat64 변환
#show nat64 통계
1단계. 첫 번째 단계는 IPv4 주소 10.1.113.2에서 IPv6 서버 2001:DB8:3001::9/64에 대한 액세스를 제공하도록 NAT46 라우터에서 IPv6-IPv4 고정 매핑을 구성하는 것입니다. 또한 IPv4 주소 10.50.50.50을 DNS 서버의 www.examplev6.com에 대한 DNS 리소스 레코드로 등록해야 합니다. 고정 NAT64 매핑은 다음 명령을 사용하여 생성됩니다.
NAT64-Router(config)# nat64 v6v4 static 2001:DB8:3001::9 10.50.50.50
2단계. PC A는 www.examplev6.com 서버와 통신하려는 IPv4 전용 호스트입니다. 그러면 IPv4 DNS 권한 있는 서버에 대한 DNS 쿼리(A: www.examplev6.com)가 트리거됩니다.
3단계. DNS 서버는 www.examplev6.com에 대한 A 리소스 레코드, 10.50.50.50으로 응답합니다.
4단계. 이제 호스트 A에 IPv4 패킷을 www.examplev6.com으로 전송하는 데 필요한 주소 지정 정보가 있습니다
5단계. NAT64 라우터는 NAT64 지원 인터페이스에서 IPv4 패킷을 수신하고 다음 작업을 수행합니다.
6단계. 변환 후 IPv6 패킷은 일반 IPv6 라우팅 프로세스를 사용하여 라우팅됩니다. 패킷은 최종적으로 2001:DB8:3001::9의 www.examplev6.com 서버로 라우팅됩니다.
7단계. 서버 www.examplev6.com에서 호스트 A가 목적지인 패킷으로 응답합니다.
8단계. NAT64 라우터는 NAT64 지원 인터페이스에서 IPv6 서버가 전송한 IPv6 패킷을 수신하고 다음 작업을 수행합니다.
9단계. 변환 후 NAT64 라우터는 일반 IPv4 라우팅 프로세스를 사용하여 패킷을 10.1.113.2로 전달합니다.
컨피그레이션이 성공하면 IPv4 호스트에서 ping 10.50.50.50을 수행합니다.
#ping 10.50.50.50
NAT 확인46
#show nat64 변환
#show nat46 통계
IPv6/IPv4 변환 시나리오 |
적용 가능성 |
예 |
시나리오 1: IPv4 인터넷에 대한 IPv6 네트워크 |
· IPv6 및 기존 IPv4 콘텐츠에 투명하게 액세스하려는 IPv6 전용 네트워크 · IPv6 호스트 및 네트워크에서 시작 |
· ISP는 IPv6 전용 스마트폰(3세대[3G], LTE[Long-Term Evolution] 등)을 위한 새로운 서비스와 네트워크를 출시합니다. · IPv6 전용 네트워크를 구축하는 기업 |
시나리오 2: IPv6 네트워크에 대한 IPv4 인터넷 |
· IPv4 및 IPv6 사용자 모두를 투명하게 서비스하려는 IPv6 전용 네트워크의 서버 · IPv4 호스트 및 네트워크에서 시작 |
IPv6 전용 환경에서 서비스를 배포하는 향후 또는 기존 콘텐츠 공급자 |
시나리오 3: IPv4 네트워크에 대한 IPv6 인터넷 |
· 기존 IPv4 전용 네트워크의 서버는 IPV6 인터넷 사용자를 지원하고자 합니다. · IPv6 호스트 및 네트워크에서 시작 |
IPv6로 마이그레이션하는 기존 콘텐츠 제공업체이므로 공존 전략의 일환으로 IPv6 인터넷 사용자에게 서비스를 제공하고자 합니다. |
시나리오 4: IPv6 인터넷에 대한 IPv4 네트워크 |
가까운 장래에 실현 가능한 경우는 없습니다. 이러한 시나리오는 IPv6/IPv4 전환의 초기 단계 이후에 발생할 수 있습니다. |
없음 |
시나리오 5: IPv6 네트워크에서 IPv4 네트워크로 |
IPv4 네트워크와 IPv6 네트워크 모두 동일한 조직 내에 있습니다. |
시나리오 1과 비슷하게 인터넷 대신 인트라넷에 음식을 제공합니다. |
시나리오 6: IPv4 네트워크와 IPv6 네트워크 |
IPv4 네트워크와 IPv6 네트워크 모두 동일한 조직 내에 있습니다. |
시나리오 2와 비슷하게 인터넷 대신 인트라넷에 음식을 제공합니다. |
시나리오 7: IPv6 인터넷과 IPv4 인터넷 |
낮은 처리량으로 인해 어려움을 겪을 수 있습니다. |
없음 |
시나리오 8: IPv4 인터넷과 IPv6 인터넷 |
무제한 IPv6 주소 변환을 처리하는 실행 가능한 변환 기술이 없습니다. |
없음 |
#show 플랫폼 하드웨어 qfp 활성 통계 삭제(NAT64 삭제는 없는지 확인)
#show 실행 구성 | nat64 포함(Cisco IOS®에서 모든 것이 구성되었는지 확인)
#show 플랫폼 하드웨어 qfp 활성 기능 nat64 데이터 경로 통계(삭제 카운터 이유 확인)
#show 플랫폼 하드웨어 qfp 활성 기능 nat64 데이터 경로 풀(풀이 올바르게 구성되었는지 확인)
#show 플랫폼 하드웨어 qfp 활성 기능 nat64 데이터 경로 맵(풀을 확인하고 컨피그레이션에 매핑이 올바르게 수행되었는지 확인)
#show platform software object-manager F0 pending-ack-update(보류 중인 개체가 있는지 확인)
개정 | 게시 날짜 | 의견 |
---|---|---|
2.0 |
02-Nov-2023 |
PII를 제거했습니다.
대체 텍스트를 추가했습니다.
업데이트된 제목, 소개, 브랜딩, 기사 설명, 스타일 요구 사항, 기계 번역 및 서식. |
1.0 |
23-Jun-2021 |
최초 릴리스 |