.. title: Tham khảo cơ chế chuyển tiếp IPv6
.. sên: cơ chế chuyển tiếp ipv6
.. ngày: 2026-04-07 12:00:00 UTC
.. tags: ipv6, nat64, 464xlat, ds-lite, map-e, thứ 6, chuyển đổi, mạng
.. chuyên mục: Bài viết
.. liên kết:
.. mô tả: Hướng dẫn so sánh và ra quyết định cho các cơ chế chuyển đổi IPv6 — thứ 6, DS-Lite, NAT64/DNS64, 464XLAT, MAP-E, MAP-T và 6to4/Teredo không được dùng nữa — với các tham chiếu RFC.
.. loại: văn bản
<style>
.calc-container { max-width: 860px; margin: 20px auto; padding: 20px; }
.calc-header { margin-bottom: 30px; padding: 25px; background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); border-radius: 12px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); color: white; }
.calc-header h2 { margin-top: 0; color: white; font-size: 28px; margin-bottom: 10px; }
.calc-header p  { margin: 10px 0; opacity: 0.95; font-size: 15px; }
.result-section { background: white; border: 1px solid #e0e0e0; border-radius: 8px; margin-top: 20px; overflow: hidden; box-shadow: 0 2px 4px rgba(0,0,0,0.05); }
.section-content { padding: 20px; background: #fafafa; }
@media (max-width: 768px) { .calc-header h2 { font-size: 22px; } .calc-container { padding: 10px; } }
.article-body { padding: 24px; background: white; line-height: 1.8; font-size: 15px; color: #333; }
.article-body h3 { color: #2d6a2d; border-bottom: 2px solid #4CAF50; padding-bottom: 6px; }
.article-body a { color: #2d6a2d; }
.article-body a:hover { color: #4CAF50; }
.callout { background: #e8f5e9; border-left: 4px solid #4CAF50; padding: 12px 16px; border-radius: 6px; margin: 16px 0; font-size: 14px; }
.callout.warn { background: #fff8e0; border-color: #f0a500; }
.callout.danger { background: #fde8e8; border-color: #f87171; }
pre, .code-block { background: #1e1e2e; color: #cdd6f4; padding: 14px 18px; border-radius: 8px; font-family: 'Courier New', monospace; font-size: 13px; overflow-x: auto; line-height: 1.5; margin: 12px 0; white-space: pre; }
table { width: 100%; border-collapse: collapse; margin: 16px 0; font-size: 14px; }
th { background: #2d6a2d; color: white; padding: 10px 12px; text-align: left; }
td { padding: 8px 12px; border-bottom: 1px solid #e0e0e0; vertical-align: top; }
tr:nth-child(even) td { background: #f5f5f5; }
.tag { display: inline-block; padding: 2px 8px; border-radius: 4px; font-size: 12px; font-weight: 600; margin-right: 4px; }
.tag-good { background: #d1fae5; color: #065f46; }
.tag-deprecated { background: #fee2e2; color: #991b1b; }
.tag-stateful { background: #dbeafe; color: #1e40af; }
.tag-stateless { background: #fef3c7; color: #92400e; }
</style>
<div class="calc-container">
<div class="calc-header">
<h2>Tham khảo cơ chế chuyển đổi IPv6</h2>
<p>Hướng dẫn so sánh và quyết định dành cho cơ chế thứ 6, DS-Lite, NAT64/DNS64, 464XLAT, MAP-E, MAP-T và các cơ chế không được dùng nữa — với tham chiếu RFC và bối cảnh triển khai.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="why">1. Tại sao tồn tại cơ chế chuyển tiếp</h3>
<p>Sự cạn kiệt địa chỉ IPv4 đã đạt đến mức IANA vào tháng 2 năm 2011; Tiếp theo là sự cạn kiệt của nhóm tự do RIR (APNIC 2011, RIPE NCC 2012, ARIN 2015, LACNIC 2014, AFRINIC 2021). Các ISP hiện dựa vào NAT cấp nhà cung cấp dịch vụ (CGN) để chia sẻ một địa chỉ IPv4 duy nhất cho nhiều khách hàng — với chi phí vận hành phức tạp, chi phí phân bổ cổng và mất khả năng tiếp cận từ đầu đến cuối.</p>
<p>Giải pháp lâu dài là bản địa<strong>ngăn xếp kép</strong>hoặc mạng chỉ có IPv6. Cơ chế chuyển đổi là cầu nối cho phép mạng IPv6 tiếp cận nội dung IPv4 hoặc cho phép các dịch vụ IPv6 được triển khai trên cơ sở hạ tầng IPv4 trong khi quá trình di chuyển tiếp tục.</p>
<div class="callout">
<strong>Tùy chọn tốt nhất khi có sẵn:</strong>Ngăn xếp kép gốc - máy chủ có cả địa chỉ IPv4 có thể định tuyến toàn cầu và địa chỉ IPv6 có thể định tuyến toàn cầu và ứng dụng sử dụng bất kỳ địa chỉ nào có sẵn (<a href="https://www.rfc-editor.org/rfc/rfc6555" target="_blank">RFC 6555</a>Nhãn cầu hạnh phúc). Không đóng gói, không NAT, không phần cứng đặc biệt. Nếu ISP của bạn cung cấp tính năng này, hãy ưu tiên nó hơn tất cả các cơ chế chuyển đổi.</div>
<h3 id="tunnels">2. Cơ chế đường hầm IPv6 qua IPv4</h3>
<h4>Thứ 6 - Triển khai nhanh chóng IPv6 (<a href="https://www.rfc-editor.org/rfc/rfc5969" target="_blank">RFC 5969</a>)</h4>
<p><span class="tag tag-stateless">Không quốc tịch</span> <span class="tag tag-good">Đã triển khai</span></p>
<p>ISP phân bổ tiền tố IPv6 /32 hoặc ngắn hơn và nhúng địa chỉ IPv4 của từng khách hàng vào các bit thấp hơn để lấy tiền tố khách hàng /56 hoặc /60. CPE (CE thứ 6) đóng gói các gói IPv6 trong IPv4 (proto 41) được gửi tới BR thứ 6 (Border Relay) của ISP. Lưu lượng quay trở lại được giải mã tại BR.</p>
<ul>
<li><strong>Trường hợp sử dụng:</strong>ISP có mạng truy nhập IPv4 triển khai kết nối IPv6 nhanh chóng. Free (Pháp) đã triển khai quy mô này vào năm 2007 trước khi RFC được xuất bản.</li>
<li><strong>Hạn chế chính:</strong>Vẫn sử dụng IPv4 ở lớp truy cập; giới thiệu chi phí ~ 20 byte cho mỗi gói.</li>
</ul>
<h4>Đường hầm thủ công 6in4 (<a href="https://www.rfc-editor.org/rfc/rfc4213" target="_blank">RFC 4213</a>)</h4>
<p><span class="tag tag-stateless">Không quốc tịch</span></p>
<p>Đường hầm IPv6-trong-IPv4 điểm-điểm được cấu hình thủ công (số giao thức 41) giữa hai điểm cuối cố định. Vẫn được sử dụng để kết nối phòng thí nghiệm doanh nghiệp và dịch vụ TunnelBroker của Hurricane Electric.</p>
<h3 id="nat64-dns64">3. NAT64 + DNS64</h3>
<p><span class="tag tag-stateful">có trạng thái</span> <span class="tag tag-good">Triển khai rộng rãi</span></p>
<p><strong>NAT64</strong> (<a href="https://www.rfc-editor.org/rfc/rfc6146" target="_blank">RFC 6146</a>) là cổng dịch chuyển giữa IPv6 và IPv4. Máy khách chỉ sử dụng IPv6 gửi gói đến địa chỉ IPv6 tổng hợp (trong tiền tố NAT64, thường là 64:ff9b::/96) nhúng địa chỉ IPv4 đích. Cổng NAT64 dịch các tiêu đề và duy trì bảng phiên trạng thái.</p>
<p><strong>DNS64</strong> (<a href="https://www.rfc-editor.org/rfc/rfc6147" target="_blank">RFC 6147</a>) hoạt động cùng với NAT64: khi máy khách chỉ có IPv6 truy vấn DNS để tìm tên chỉ có bản ghi A (IPv4), DNS64 sẽ tổng hợp bản ghi AAAA bằng cách nhúng địa chỉ IPv4 vào tiền tố NAT64. Máy khách kết nối với địa chỉ tổng hợp, sau đó được NAT64 dịch.</p>
<div class="callout warn">
<strong>DNS64 không hoạt động với xác thực DNSSEC trên máy khách.</strong>Bản ghi AAAA tổng hợp không thể có chữ ký DNSSEC hợp lệ. Các ứng dụng thực hiện phân giải DNS riêng (ví dụ: Android có DNS riêng, hầu hết các máy khách VPN) bỏ qua DNS64 và sẽ không truy cập được các máy chủ chỉ có IPv4 từ mạng chỉ có IPv6 mà không có 464XLAT.</div>
<h3 id="464xlat">4. 464XLAT</h3>
<p><span class="tag tag-stateful">Trạng thái (PLAT)</span> <span class="tag tag-stateless">Không quốc tịch (CLAT)</span> <span class="tag tag-good">Tiêu chuẩn cho thiết bị di động/di động</span></p>
<p>464XLAT (<a href="https://www.rfc-editor.org/rfc/rfc6877" target="_blank">RFC 6877</a>) giải quyết vấn đề DNS64/DNSSEC và cũng xử lý các ứng dụng nhúng các ký tự IPv4. Nó có hai thành phần:</p>
<ul>
<li><strong>CLAT</strong>(Trình dịch phía khách hàng): Chạy trên thiết bị (điện thoại, bộ định tuyến). Tổng hợp không gian địa chỉ IPv4 riêng tư, chặn lưu lượng IPv4 từ HĐH và chuyển nó sang IPv6 bằng cách sử dụng tiền tố NAT64 làm đích. Bản dịch không có trạng thái (ánh xạ RFC 6145/RFC 7915 IVI).</li>
<li><strong>PLAT</strong>(Trình dịch phía nhà cung cấp): Cổng NAT64 của ISP. Nhận các gói IPv6 đã dịch từ CLAT và dịch ngược lại sang IPv4 để tiếp cận Internet IPv4 thực.</li>
</ul>
<p>Kết quả cuối cùng: các ứng dụng chạy trên thiết bị sẽ thấy giao diện IPv4 thực sự. Kết nối theo nghĩa đen của IPv4 hoạt động. DNSSEC hoạt động. Đây là mô hình tiêu chuẩn cho mạng di động LTE/5G chỉ có IPv6 (T-Mobile US, nhiều nhà khai thác EU).</p>
<p>CLAT phát hiện tiền tố NAT64 thông qua DNS (<a href="https://www.rfc-editor.org/rfc/rfc7050" target="_blank">RFC 7050</a>: truy vấn ipv4only.arpa) hoặc thông qua tùy chọn RA (<a href="https://www.rfc-editor.org/rfc/rfc8781" target="_blank">RFC 8781</a>tùy chọn PREF64).</p>
<h3 id="ds-lite">5. DS-Lite — Ngăn xếp kép Lite</h3>
<p><span class="tag tag-stateful">Trạng thái (AFTR)</span> <span class="tag tag-good">Phổ biến ở băng thông rộng</span></p>
<p>DS-Lite (<a href="https://www.rfc-editor.org/rfc/rfc6333" target="_blank">RFC 6333</a>) được thiết kế dành cho các ISP có mạng truy cập IPv6 vẫn cần phục vụ IPv4 cho khách hàng. CPE nhận được địa chỉ IPv6 gốc nhưng không có IPv4 công cộng. Lưu lượng IPv4 từ mạng LAN của khách hàng được gói gọn trong IPv6 (phần tử B4 trong CPE) và được gửi đến Bộ định tuyến chuyển đổi dòng địa chỉ (AFTR) của ISP.</p>
<p>AFTR giải mã và thực hiện CGN (NAT cấp nhà cung cấp dịch vụ) từ nhóm IPv4 dùng chung. Các phiên IPv4 được theo dõi tại AFTR. Vì không có IPv4 trên vòng truy cập nên ISP lưu địa chỉ IPv4; vì mạng truy cập là IPv6 gốc nên lưu lượng IPv6 đi theo đường dẫn nhanh mà không cần dịch.</p>
<ul>
<li><strong>Trường hợp sử dụng:</strong>Các nhà khai thác cáp/DSL châu Âu (KPN, Swisscom, các nhà khai thác khác).</li>
<li><strong>Hạn chế chính:</strong>Hiệu suất của IPv4 phụ thuộc vào dung lượng AFTR; Việc phân bổ cổng cho mỗi người đăng ký giới hạn các kết nối đồng thời tối đa.</li>
</ul>
<h3 id="map">6. MAP-E và MAP-T</h3>
<p><span class="tag tag-stateless">Không quốc tịch</span> <span class="tag tag-good">Triển khai ngày càng tăng</span></p>
<p>Ánh xạ địa chỉ và cổng (MAP) là một khung dịch thuật/đóng gói không trạng thái giúp loại bỏ bảng phiên CGN bằng cách lấy toán học địa chỉ IPv4 và phạm vi cổng của từng khách hàng từ tiền tố IPv6 của họ. Không có trạng thái mỗi phiên ở Border Relay — nó có thể là một bộ định tuyến đơn giản hoặc thậm chí là một chức năng thẻ đường truyền.</p>
<ul>
<li><strong>BẢN ĐỒ-E</strong> (<a href="https://www.rfc-editor.org/rfc/rfc7597" target="_blank">RFC 7597</a>): Đóng gói IPv4 trong IPv6. CPE (MAP-E CE) đóng gói các gói IPv4 trong IPv6; BR giải mã. Không quốc tịch.</li>
<li><strong>BẢN ĐỒ-T</strong> (<a href="https://www.rfc-editor.org/rfc/rfc7599" target="_blank">RFC 7599</a>): Dịch IPv4 sang IPv6 (và ngược lại) bằng cách sử dụng quy tắc ánh xạ địa chỉ+cổng. Không có chi phí đóng gói - các tiêu đề được dịch tại chỗ.</li>
</ul>
<p>MAP ngày càng phổ biến trong việc triển khai DOCSIS 3.1 và PON, nơi các BR trạng thái 0 rất hấp dẫn để mở rộng quy mô. Yêu cầu lập kế hoạch phạm vi cổng cẩn thận: mỗi CE có một phạm vi cổng hạn chế (ví dụ: 1024–2047 trên tổng số 65536 cổng) bắt nguồn từ tiền tố IPv6 /56 của nó.</p>
<h3 id="deprecated">7. Cơ chế không được dùng nữa - Không sử dụng</h3>
<div class="callout danger">
<strong>6to4 và Teredo chính thức không được dùng nữa. Không triển khai hoặc kích hoạt chúng.</strong>
</div>
<ul>
<li><strong>6to4</strong> (<a href="https://www.rfc-editor.org/rfc/rfc3056" target="_blank">RFC 3056</a>, không được chấp nhận bởi<a href="https://www.rfc-editor.org/rfc/rfc7526" target="_blank">RFC 7526</a>): Đã sử dụng tiền tố chuyển tiếp Anycast 192.88.99.0/24. Không đáng tin cậy do hoạt động chuyển tiếp Anycast không nhất quán, bị lỗi sau NAT và bị các nhà cung cấp hệ điều hành lớn bỏ rơi.</li>
<li><strong>Teredo</strong> (<a href="https://www.rfc-editor.org/rfc/rfc4380" target="_blank">RFC 4380</a>): Đường hầm IPv6 dựa trên UDP để truyền tải NAT. Bị tắt theo mặc định trong Windows kể từ Vista SP1 và Server 2008; không còn được khuyến khích nữa. Các mối lo ngại về bảo mật (lưu lượng truy cập qua đường hầm vượt qua tường lửa IPv6 không kiểm tra Teredo).</li>
</ul>
<h3 id="comparison">8. Bảng so sánh</h3>
<table>
<tr><th>Cơ chế</th><th>Mạng truy cập</th><th>IPv4 cho khách hàng?</th><th>Có trạng thái?</th><th>Trên không</th><th>Tốt nhất cho</th></tr>
<tr><td>Ngăn xếp kép</td><td>IPv4 + IPv6</td><td>Có (bản địa)</td><td>KHÔNG</td><td>Không có</td><td>Được ưa thích ở mọi nơi</td></tr>
<tr><td>thứ 6</td><td>IPv4</td><td>Không (IPv6 qua đường hầm)</td><td>KHÔNG</td><td>20B/gói</td><td>ISP triển khai IPv6 qua truy cập IPv4</td></tr>
<tr><td>DS-Lite</td><td>IPv6</td><td>Có (AFTR CGN)</td><td>Có (AFTR)</td><td>40B/gói</td><td>Băng thông rộng; ISP muốn truy cập IPv6 + dịch vụ IPv4</td></tr>
<tr><td>NAT64 + DNS64</td><td>Chỉ IPv6</td><td>Qua bản dịch</td><td>Có (NAT64)</td><td>Không có</td><td>Mạng chỉ có IPv6 tiếp cận Internet IPv4</td></tr>
<tr><td>464XLAT</td><td>Chỉ IPv6</td><td>Có (CLAT trên thiết bị)</td><td>Có (PLAT/NAT64)</td><td>Không có</td><td>Chỉ dành cho IPv6 di động/di động; ứng dụng cần ổ cắm IPv4</td></tr>
<tr><td>BẢN ĐỒ-E</td><td>IPv6</td><td>Có (không quốc tịch)</td><td>KHÔNG</td><td>40B/gói</td><td>Triển khai CPE quy mô; BR trạng thái không</td></tr>
<tr><td>BẢN ĐỒ-T</td><td>IPv6</td><td>Có (không quốc tịch)</td><td>KHÔNG</td><td>Không có (dịch)</td><td>Tương tự như MAP-E nhưng không có chi phí đóng gói</td></tr>
<tr><td>6to4</td><td>IPv4</td><td>KHÔNG</td><td>KHÔNG</td><td>20B/gói</td><td><strong>Không dùng nữa - không sử dụng</strong></td></tr>
<tr><td>Teredo</td><td>IPv4 (đứng sau NAT)</td><td>KHÔNG</td><td>KHÔNG</td><td>UDP 8B/gói</td><td><strong>Không dùng nữa - không sử dụng</strong></td></tr>
</table>
<h3 id="references">Tài liệu tham khảo</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6555" target="_blank">RFC 6555</a>— Happy Eyeballs: Thành công với máy chủ ngăn xếp kép</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc4213" target="_blank">RFC 4213</a>— Cơ chế chuyển tiếp cơ bản cho máy chủ và bộ định tuyến IPv6 (6in4)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc5969" target="_blank">RFC 5969</a>— Triển khai nhanh IPv6 trên cơ sở hạ tầng IPv4 (thứ 6)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6146" target="_blank">RFC 6146</a>— Stateful NAT64: Dịch địa chỉ mạng và giao thức từ máy khách IPv6 sang máy chủ IPv4</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6147" target="_blank">RFC 6147</a>— DNS64: Tiện ích mở rộng DNS để dịch địa chỉ mạng từ máy khách IPv6 sang máy chủ IPv4</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6333" target="_blank">RFC 6333</a>— Triển khai băng thông rộng Dual-Stack Lite sau khi cạn kiệt IPv4</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6877" target="_blank">RFC 6877</a>— 464XLAT: Sự kết hợp giữa dịch có trạng thái và không có trạng thái</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc7050" target="_blank">RFC 7050</a>— Khám phá tiền tố IPv6 được sử dụng để tổng hợp địa chỉ IPv6 (Khám phá tiền tố NAT64 qua ipv4only.arpa)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc7526" target="_blank">RFC 7526</a>— Ngừng sử dụng Tiền tố Anycast cho Bộ định tuyến chuyển tiếp 6to4</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc7597" target="_blank">RFC 7597</a>— Ánh xạ địa chỉ và cổng với tính năng đóng gói (MAP-E)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc7599" target="_blank">RFC 7599</a>— Ánh xạ địa chỉ và cổng bằng cách sử dụng bản dịch (MAP-T)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8781" target="_blank">RFC 8781</a>— Khám phá PREF64 trong Quảng cáo bộ định tuyến</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8585" target="_blank">RFC 8585</a>— Yêu cầu đối với Bộ định tuyến biên khách hàng IPv6 để hỗ trợ dịch vụ IPv4</li>
</ul>
</div>
</div>
</div>