正文共：12345 字 5 圖，預估閱讀時間：6 分鐘
RFC6296：IPv6-to-IPv6 Network Prefix Translation，June 2011
摘要
本文檔描述瞭一種無狀態、傳輸不可知的IPv6到IPv6網絡前綴轉換（IPv6-to-IPv6 Network Prefix Translation，NPTv6）功能，該功能提供瞭與IPv4到IPv4 NAT（IPv4-to-IPv4 NAT，NAPT44）相關的地址獨立性優勢，並在“內部”和“外部”前綴中的地址之間提供瞭1:1的關系，從而在網絡層保持端到端可達性。
關於備忘錄
本文件不是互聯網標準跟蹤規范；它被發佈用於檢查、實驗實施和評估。
本文件定義瞭互聯網社區的實驗協議。本文檔是互聯網工程任務組（IETF）的產品。它代表瞭IETF社區的共識。它已接受公眾審查，並已由互聯網工程指導小組（IESG）批準出版。並非IESG批準的所有文件都適用於任何級別的互聯網標準；參見RFC 5741的第2節。
有關本文件當前狀態、任何勘誤表以及如何提供反饋的信息，請訪問http://www.rfc-editor.org/info/rfc6296.
版權聲明
版權所有（c）2011 IETF Trust和文件作者。保留所有權利。
本文件受BCP 78和IETF信托基金有關IETF文件的法律規定的約束(http://trustee.ietf.org/license-info)自本文件發佈之日起生效。請仔細閱讀這些文件，因為它們描述瞭您對本文件的權利和限制。從本文檔中提取的代碼組件必須包含《信托法律條款》第4.e節中所述的簡化BSD許可文本，並且不提供簡化BSD協議中所述擔保。
1、 引言
本文檔描述瞭一種無狀態的IPv6到IPv6網絡前綴轉換（NPTv6）功能，旨在為邊緣網絡提供地址獨立性。對於不校驗IP報文頭的傳輸（如SCTP）以及使用TCP/UDP/DCCP（Datagram Congestion Control Protocol，數據包擁塞控制協議）偽報文頭和校驗和[RFC1071]的傳輸，它是不可知的。
由於[RFC2993]和第5節中討論的原因，IETF不建議為IPv6使用網絡地址轉換技術。然而，在實現轉換的情況下，本規范提供瞭一種機制，該機制比僅在IPv6環境中實現傳統的有狀態網絡地址轉換器具有更少的架構問題。它還提供瞭一個有用的替代方案，以解決使用提供商獨立尋址的多歸屬所帶來的復雜性和成本，以及重疊ISP地址空間的路由和網絡管理問題。然而，仍然存在一些問題。讀者應考慮[RFC4864]中建議的備選方案和[RFC5902]中的考慮因素，以改進方法。
本文檔中描述的無狀態方法有幾個影響：
*NAPT44可能提供的任何安全優勢在NPTv6中都不存在，如果需要，需要使用防火墻來獲得這些優勢。[RFC6092]中描述瞭這種防火墻的示例。
*盡管在邊緣網絡內部使用的地址與在邊緣網絡外部使用的地址不同，但端到端的可達性仍得以保留。這對應用程序轉介和互聯網層地址的其他使用有影響。
*如果兩個網絡之間有多個相同配置的前綴轉換器，則它們不需要交換動態狀態，因為不存在動態狀態——算法轉換在每個網絡上都是相同的。因此，網絡可以在它們之間進行非對稱路由、負載分擔和故障轉移，而不會出現問題。
*由於網絡層的轉換是1:1，因此無需修改端口號或其他傳輸參數。
*使用TCP驗證選項[RFC5925]驗證對等方的TCP會話無法轉換其地址，因為這些地址用於計算消息驗證代碼。這一考慮一般適用於任何非雙邊自地址修復（UNilateral Self-Address Fixing，UNSAF）[RFC3424]協議，IAB建議不要在改變互聯網地址的環境中部署該協議。
*至少在理論上，使用因特網密鑰交換協議版本2（Internet Key Exchange Protocol Version 2，IKEv2）[RFC5996]的應用程序應該檢測轉換器的存在；雖然不需要NAT穿越解決方案，[RFC5996]將要求此類會話使用UDP。
1.1、 什麼是地址獨立？
在本文檔中，IPv6地址獨立性由以下一組屬性組成：
從邊緣網絡的角度來看：
*如果分配給邊緣網絡使用的全局前綴發生更改，則本地網絡內部使用的IPv6地址（用於接口、訪問列表和日志）無需重新編號。
*當站點添加、刪除或更改上遊網絡時，邊緣網絡（用於接口、訪問列表和日志）或其他上遊網絡（如多宿主網絡）中使用的IPv6地址無需重新編號。
*管理部門不必說服上遊網絡路由其內部IPv6前綴，也不必向其通告從其他上遊網絡派生的前綴。
*除非它希望在多歸屬過程中優化多個上遊網絡之間的路由，否則不需要與上遊網絡進行BGP交換。
從上遊網絡的角度來看：
*邊緣網絡使用的IPv6地址保證具有提供商分配的前綴，消除瞭對BCP 38[RFC2827]入口過濾和客戶特定前綴通告的需要和擔憂。
因此，地址獨立性對邊緣網絡、其直接連接的網絡（尤其是其上遊網絡）以及整個互聯網都有影響。對地址獨立性的渴望一直是中大型企業網絡中IPv4 NAT部署的主要驅動因素，包括在擁有大量IPv4提供商獨立地址空間（來自IPv4“沼澤空間”）的企業中部署NAT。它也是邊緣網絡成為區域互聯網註冊（Regional Internet Registry，RIR）社區成員的一個驅動因素，尋求獲得BGP自治系統編號和獨立於提供商的前綴，因此也是IPv4路由表爆炸的驅動因素之一。服務提供商表示，由於其網絡中預期的客戶路由的影響，缺乏與客戶的地址獨立性一直是部署的負面誘因。
本地網絡保護[RFC4864]文件討論瞭一個稱為“地址自治”的相關概念，這是NAPT44的一個優點。[RFC4866]指出，地址自治可以通過在站點內需要外部連接的所有節點上同時使用全局地址和所有內部通信的唯一本地地址（Unique Local Addresses，ULA）[RFC4193]來實現。但是，此解決方案無法滿足地址獨立性的要求，因為如果發生ISP重新編號事件，則在完全恢復全局連接之前，需要對所有主機、路由器、DHCP服務器、訪問控制列表（Access Control Lists，ACL）、防火墻和其他配置有ISP全局地址的內部系統進行重新編號。
還建議使用IPv6提供商無關（provider-independent，PI）地址作為滿足地址獨立性要求的手段。然而，此解決方案要求企業有資格接收PI分配，並說服其ISP為企業的PI地址安裝特定路由。這種方法存在許多實際問題，特別是如果希望路由到多個地理和地形不同的站點，這有時可能涉及與多個ISP協調以路由單個PI前綴的部分。這些問題導致許多擁有大量IPv4沼澤空間的企業選擇將IPv4 NAT用於部分或基本上全部內部網絡，而不是使用獨立於提供商的地址空間。
1.2、 NPTv6適用性
NPTv6為滿足IPv6中的地址獨立性要求提供瞭一個簡單而令人信服的解決方案。地址獨立性的好處直接來自網絡前綴轉換器的轉換功能。為瞭避免盡可能多的與NAPT44相關的問題，NPTv6被定義為包括雙向、校驗和中立、算法轉換功能，而不包括其他功能。
NPTv6不映射端口並且是校驗和中性的這一事實避免瞭NPTv6轉換器重寫傳輸層報文頭的需要。這使得在不升級NPTv6轉換器的情況下部署新的或改進的傳輸層協議成為可能。類似地，由於NPTv6不重寫傳輸層報文頭，因此在許多情況下，NPTv6不會幹擾完整IP有效負載的加密。
默認的NPTv6地址映射機制是純算法的，因此NPTv6轉換器不需要維護每個節點或每個連接狀態，從而允許部署比使用NAPT44部署的更健壯和自適應的網絡。由於默認NPTv6映射可以在任一方向執行，因此不會幹擾入站連接的建立，從而允許內部節點參與直接對等應用，而無需在許多IPv4對等應用中發現的應用層開銷。
盡管NPTv6在幾個方面優於NAPT44，但它並沒有消除與IPv4 NAT相關的所有架構問題，如[RFC2993]中所述。NPTv6涉及修改傳輸中的IP報文頭，因此它與為IP報文頭提供完整性保護的安全機制（如IPsec認證報文頭）不兼容。NPTv6可能幹擾在IP數據包的應用特定部分中傳輸IP地址的應用協議的使用。這些應用程序當前需要應用層網關（Application Layer Gateways，ALG）通過NAPT44設備正確工作，這些應用程序可能需要類似的ALG才能通過NPTv6轉換器工作。由於內部節點希望使用內部地址與其他內部節點通信，而外部節點需要獲得外部地址才能與相同節點通信，因此使用單獨的內部和外部前綴會給DNS部署帶來復雜性。這經常導致部署“拆分DNS”，這可能會增加網絡配置的復雜性。
邊緣網絡內的地址選擇需要考慮。可以使用ULA，它最大化瞭地址獨立性。這也可以被認為是對《統一規則》的濫用；如果期望ULA阻止從ULA的范圍之外訪問系統，則NPTv6將覆蓋這一點。另一方面，政府知道自己已經做出瞭選擇，如果願意，可以出於隱私目的部署第二個ULA；將被轉換的唯一前綴是具有被配置為向其轉換或從其轉換的NPTv6轉換器的前綴。此外，使用任何其他全局作用域地址格式都會使您獲得PI前綴或由分配該前綴的機構支配。
任何前綴轉換機制（包括NPTv6）的部署都會產生重大的技術影響，我們強烈鼓勵正在考慮實施或部署NPTv6的任何人閱讀[RFC4864]和[RFC5902]，並仔細考慮該文檔中描述的替代方案，其中一些方案可能比NPTv6引起的問題更少。
1.3、 要求術語
本文件中的關鍵詞“必須”、“不得”、“必需”、“應”、“不應該”、“應當”、“不宜”、“建議”、“可能”和“可選”應按照RFC 2119[RFC2119]中的描述進行解釋。
2、 NPTv6概述
NPTv6可以在IPv6路由器中實現，以在每個IPv6數據包通過路由器時將一個IPv6地址前綴映射到另一個IPv6前綴。實現NPTv6前綴轉換功能的路由器稱為NPTv6轉換器。
2.1、 NPTv6：最簡單的情況
在其最簡單的形式中，NPTv6轉換器互連兩個網絡鏈路，其中一個是連接到單個管理域內的葉網絡的“內部”網絡鏈路，另一個是與全球互聯網連接的“外部”網絡。內部網絡上的所有主機將使用來自單個本地路由前綴的地址，當IP數據包通過NPTv6轉換器時，這些地址將被轉換為全局可路由前綴中的地址。這兩個前綴的長度在功能上是相同的；如果兩者不同，兩者中的較長者將限制在較短時間內使用子網的能力。
圖1：一個簡單的轉換器
圖1顯示瞭連接到兩個網絡的NPTv6轉換器。在此示例中，內部網絡使用IPv6唯一本地地址（ULA）[RFC4193]表示內部IPv6節點，外部網絡使用全局可路由IPv6地址表示相同節點。
當NPTv6轉換器在“出站”方向上從內部網絡向外部網絡轉發數據包時，NPTv6將用相應的外部前綴覆蓋IPv6源前綴（在IPv6報文頭中）。當數據包以“入站”方向從外部網絡轉發到內部網絡時，IPv6目的前綴將被相應的內部前綴覆蓋。使用上圖所示的前綴，當IP數據包在出站方向上通過NPTv6轉換器時，源前綴（FD01:0203:0045:/48）將被外部前綴（2001:0DB8:0001:/48）覆蓋。在入站數據包中，目的前綴（2001:0DB8:0001:/48）將被內部前綴（FD01:0203:0045:/48）覆蓋。在這兩種情況下，都是本地IPv6前綴被覆蓋；遠程IPv6前綴保持不變。內部網絡上的節點被稱為“在NPTv6轉換器後方”。
2.2、 對等網絡之間的NPTv6
NPTv6也可以在兩個專用網絡之間使用。在這些情況下，兩個網絡都可以使用ULA前綴，一個網絡中的每個子網映射到另一個網絡的相應子網，反之亦然。或者，每個網絡可以使用ULA前綴用於其他網絡上的內部尋址和全局單播地址。
圖2：轉換中的信息流
2.3、 NPTv6冗餘和負載分擔
在某些情況下，多個NPTv6轉換器可能連接到網絡，如圖3所示。在這種情況下，NPTv6轉換器配置有相同的內部和外部前綴。由於隻有一個轉換，即使有多個轉換器，它們也隻能將一個外部地址（前綴和接口標識符（Interface Identifier，IID））映射到內部地址。
圖3：並行轉換器
2.4、 NPTv6多宿主
圖4：具有不同上遊網絡的並行轉換器
當多宿主時，NPTv6轉換器連接到內部網絡，如圖4所示，但連接到不同的外部網絡。在這種情況下，NPTv6轉換器配置有相同的內部前綴，但外部前綴不同。由於有多個轉換，它們將多個外部地址（前綴和IID）映射到公共內部地址。邊緣網絡內的系統除瞭NAT會話遍歷實用程序（Session Traversal Utilities for NAT，STUN）[RFC5389]等服務之外，無法確定其正在使用哪個外部地址。
從這個意義上說，與具有獨立於提供商的地址的多宿主相比，多宿主有一個負面特征：當NPTv6轉換器之間的路由發生變化時，由於上遊網絡發生變化，轉換後的前綴可能會發生變化。這會導致依賴它的會話和轉換失敗。然而，在路由通常穩定的網絡中，這預計不會成為主要問題。
2.5、 無逐流狀態映射
當按照本文檔中的描述使用NPTv6時，NPTv6轉換器中不維護每個節點或每個流的狀態。入站和出站數據包都是通過算法轉換的，隻使用IPv6報文頭中的信息。由於這一特性，NPTv6的雙向算法地址映射可以支持出站和入站連接建立，而無需維護映射狀態或狀態啟動或會合機制。這是對NAPT44設備的重大改進，但也具有重大的安全影響，如第7節所述。
2.6、 校驗和中性映射
當對IPv6偽報文頭校驗和中的一個IP報文頭字段（例如一個IP地址）進行更改時，傳輸層報文頭中的校驗和字段可能無效。幸運的是，互聯網標準校驗和[RFC1071]所覆蓋區域的增量更改將導致校驗和值[RFC1624]的明確更改。因此，通過修改由校驗和覆蓋的部分區域而導致的校驗和變化可以通過對由相同校驗和所覆蓋的不同16位字段進行補充變化來校正。
本文檔中描述的NPTv6映射機制是校驗和中立的，這意味著當使用標準互聯網校驗和算法[RFC1071]計算校驗和時，它們會生成生成相同IPv6偽報文頭校驗和的IP報文頭。在轉換IPv6前綴期間所做的任何更改都會被對IPv6地址其他部分的更改抵消。這導致使用互聯網校驗和（如TCP和UDP）的傳輸層為同一數據包的內部和外部形式計算相同的IPv6偽報文頭校驗和，這避免瞭NPTv6轉換器修改這些傳輸層報文頭以更正校驗和值的需要。
通過更改源地址的16位部分（不用於外部網絡中的路由）來實現輸出校驗和校正。由於校驗和算法的性質，當對入站數據包的目的地址的相同位應用相應的校正時，目的地址（Destination Address，DA）返回到正確的內部值。
如第4.2節所述，此映射導致使用/48外部前綴的邊緣網絡無法使用子網0xFFFF。
3、 NPTv6算法規范
為瞭清晰起見，圖5復制瞭[RFC4291]的IPv6地址結構。
圖5:IPv6地址的枚舉[RFC4291]
3.1、 NPTv6配置計算
配置NPTv6轉換功能時，它配置為
*一個或多個“內部”接口及其“內部”路由域前綴，以及
*一個或多個“外部”接口及其“外部”路由域前綴。
在簡單的例子中，每個都有一個。如果單個路由器在多個域之間提供NPTv6轉換服務（多宿主時可能是這樣），則從本規范的角度來看，必須將每個內部/外部對視為單獨的NPTv6轉換器。
配置NPTv6轉換器時，轉換函數首先確保內部前綴和外部前綴的長度相同，必要時用零擴展兩者中的較短前綴。這兩個前綴將用於第3.2和3.3節所述的前綴轉換功能。
然後，為瞭計算的目的，它們被零擴展到/64。轉換函數計算/64外部前綴和/64內部前綴的16位字的1的補碼和。然後計算這些值之間的差值：內部減去外部。這個值被稱為“adjustment/調整”，在NPTv6轉換器配置的生命周期內實際上是恒定的，用於每個數據包處理。
3.2、 NPTv6轉換，內部網絡到外部網絡
當數據包從內部網絡通過NPTv6轉換器傳遞到外部網絡時，其IPv6源地址以兩種方式更改或導致數據包被丟棄：
*如果內部子網號沒有映射，例如0xFFFF或隻是沒有映射，則丟棄數據包。這將導致ICMP目的無法訪問。
*內部前綴被外部前綴覆蓋，實際上是從偽報文頭的校驗和中減去兩個校驗和之間的差值（調整），以及
*地址的16位字使用補碼算法進行調整。如果結果為0xFFFF，則覆蓋為零。字的選擇如第3.4節或第3.5節所述。
3.3、 NPTv6轉換，外部網絡到內部網絡
當數據包從外部到內部網絡通過NPTv6轉換器時，其IPv6目的地址會以兩種方式更改：
*外部前綴被內部前綴覆蓋，實際上是將兩個校驗和之間的差異（調整）添加到偽報文頭的校驗和，以及
*地址的16位字使用補碼算法從中減去調整（按位反轉並相加）。如果結果為0xFFFF，則覆蓋為零。詞語的選擇如第3.4節或第3.5節所述。
3.4、 具有/48或更短前綴的NPTv6
當NPTv6轉換器配置有長度為48位（a/48）或更短的內部和外部前綴時，必須將調整添加到地址的48到63位或從中減去。
該映射不會導致接口標識符（IID）的修改，IID保存在IPv6地址的下半部分，因此不會幹擾可能使用唯一IID進行節點標識的未來協議。
NPTv6轉換器實現必須實現/48映射。
3.5、 具有/49或更長前綴的NPTv6
當NPTv6轉換器配置有長度大於48位的內部和外部前綴（如a/52、/56或/60）時，必須將調整添加到地址的64到79位、80到95位、96到111位或112到127位中的一個字或從中減去調整。雖然位的選擇隻要一致就無關緊要，但為瞭一致性，必須按照該順序檢查這些位，並檢查最初未選擇0xFFFF的第一個位。
NPTv6轉換器實現應實現較長前綴的映射。
3.6、 /48前綴映射示例
對於圖1所示的網絡，內部前綴為FD01:0203:00405:/48，外部前綴為2001:0DB8:0001:/48。
如果內部地址為FD01:0203:00405:0001::1234的節點通過NPTv6轉換器發送出站數據包，則生成的外部地址將為2001:0DB8:0001:D550::1234。生成的地址通過計算內部和外部48位前綴的校驗和來獲得，使用補碼算法從外部前綴中減去內部前綴以計算“調整”，並將調整添加到16位子網字段（在本例中為0x0001）。
工作過程：
FD01:0203:0405的補碼校驗和是0xFCF5。2001:0DB8:0001的補碼檢驗和是0xD245。使用補碼算術，0xD245-0xFCF5=0xD54F。原始數據包中的子網是0x0001。使用補碼算法，0x0001+0xD54F=0xD550。既然0xD550!=0xFFFF，那就不更改為0x0000。
因此，值0xD550被寫入16位子網區域，導致映射的外部地址為2001:0DB8:0001:D550::1234。
當接收到響應數據包時，它將包含目的地址2001:0DB8:0001:D550::0001，該地址將使用逆映射算法映射回FD01:0203:0045:001::1234。
在這種情況下，兩個前綴之間的差異將按如下方式計算：
使用補碼算法，0xFCF5-0xD245=0x2AB0。原始數據包中的子網=0xD550。使用補碼算術，0xD550+0x2AB0=0x0001。既然0x0001!=0xFFFF，那就不更改為0x0000。
因此，值0x0001被寫入子網字段，子網字段的內部值被正確恢復。
3.7、 較長前綴的地址映射
如果映射的前綴長於48位，則算法稍微復雜一些。常見的情況是內部前綴和外部前綴的長度不同。在這種情況下，為瞭覆蓋前綴，如第3.1節所述，較短前綴的長度被零擴展為較長前綴的長度。然後，它們都被零擴展到64位，以便於補碼運算。使用這些64位前綴計算“調整”。
例如，如果內部前綴是/48 ULA，而外部前綴是/56提供者分配的前綴，則ULA變為/56，第48到55位為零。為瞭進行補碼運算，它們都被零擴展到64位。這樣做的副作用是，較短前綴中可能的子網子集是不可轉換的。雖然這一點的安全價值值得商榷，但政府可能會選擇將其用於不需要外部訪問的子網。
然後，我們在IID中找到第一個不具有0xFFFF值的字，嘗試64到79位，然後80到95位，96到111位，最後112到127位。我們執行與第3.6節相同的計算（使用相同的正確性證明），但將其應用於該字。
盡管IPv6 IID的任何16位部分可能包含0xFFFF，但所有1的IID都是保留的選播標識符，不應在網絡上使用[RFC2526]。如果NPTv6轉換器在執行地址映射時發現IID為全零的數據包，則必須丟棄該數據包，並且應生成ICMPv6參數問題錯誤[RFC4443]。
註：該機制確實涉及IID的修改；它可能與使用唯一IID進行節點標識的未來機制不兼容。
4、 網絡地址轉換器行為要求的含義
4.1、 前綴配置和生成
NPTv6轉換器必須支持手動配置內部和外部前綴，並且不得對這些前綴設置任何限制，除非它們是[RFC4291]中描述的有效IPv6單播前綴。它們還可以支持根據命令隨機生成ULA地址。由於預計實現NPTv6轉換器最常見的地方是客戶前置設備（Customer Premises Equipment，CPE）路由器，因此敦促讀者考慮[RFC6204]的要求。
4.2、 子網編號
出於附錄B中詳細說明的原因，使用NPTv6轉換和/48外部前綴的網絡不得使用值0xFFFF來指定期望轉換的子網。
4.3、 NAT行為要求
根據UDP文件[RFC4787]的NAT行為要求，NPTv6轉換器必須支持發卡行為。這意味著當NPTv6轉換器在內部接口上接收到具有與站點外部前綴匹配的目的地址的數據包時，它將轉換數據包並在內部轉發。這允許內部節點在必要時使用其外部全局地址到達其他內部節點。
從概念上講，數據包離開域（如第3.2節所述進行轉換）並返回（如第3.3節所述再次進行轉換）。因此，在會話的生存期內，數據包交換將在兩個方向上通過NPTv6轉換器。另一種方法是要求NPTv6轉換器丟棄數據包，迫使發送方為其對等方使用正確的內部前綴。僅執行從外部到內部的轉換將導致數據包從源的未轉換的內部地址發送到其對等方的轉換的內部，從而使會話能夠繞過NPTv6轉換器以用於將來的數據包。這也意味著原始發件人在收到回復時不太可能認出它。
由於NPTv6不執行端口映射，並且使用一對一可逆映射算法，因此其他NAT行為要求都不適用於NPTv6。
5、 對應用的影響
NPTv6轉換不會產生[RFC2993]中討論的其他類型NAT已知存在的幾個問題。特別是，NPTv6 Translation是無狀態的，因此NPTv6 Translator的“重置”或短暫中斷不會中斷遍歷轉換功能的連接，並且如果在相同的兩個網絡之間存在多個NPTv6 Translator，則負載可以在它們之間轉移或動態負載分擔。此外，NPTv6轉換器不會在較少數量的外部地址後聚合多個主機/接口的流量，因此NPTv6轉換器不存在阻止來自外部主機的新入站流的固有期望，並且與域中的一個前綴相關聯的篩選器或黑名單不會影響另一個前綴。當然，防火墻可以與NPTv6轉換器結合使用；這將允許網絡管理員比傳統NAT更靈活地指定安全策略。
然而，NPTv6轉換確實給某些類型的應用程序帶來瞭困難。一些示例包括：
*在NPTv6轉換器後面的應用程序實例將看到其連接的地址與其在NPTv6轉換器之外的對等程序不同。
*NPTv6轉換器外部的應用程序實例將看到與NPTv6轉換器內部的任何對等程序不同的連接地址。
*希望與NPTv6轉換器“後面”的對等方建立通信的應用程序實例可能需要使用不同的地址來到達該對等方，這取決於該實例是在同一NPTv6轉換器後面還是在其外部。由於NPTv6轉換器實現瞭hairping（第4.3節），所以應用程序始終使用其外部地址就足夠瞭。然而，這在本地網絡中造成瞭效率低下，並且還可能使NPTv6轉換器的實現復雜化。[RFC3484]在這種情況下也會傾向於使用專用地址，以減少這些低效率。
*一個應用程序實例從NPTv6轉換器“後面”的領域移動到網絡“外面”的領域，反之亦然，可能會發現它不再能夠在以前能夠使用的相同地址上到達其對等端。
*與從NPTv6轉換器後面移動到其“外部”的對等方（反之亦然）間歇性通信的應用程序實例可能會發現，它再也無法在以前使用的相同地址到達該對等方。
許多（但不是所有）受到NPTv6轉換負面影響的應用程序都是那些執行“轉介”的應用程序，即應用程序實例將自己的地址和/或其對等方的地址傳遞給其他對等方。（有些人認為轉介本身就不可取；有些人認為在某些情況下轉介是必要的。對轉介的優點或不足的討論超出瞭本文件的范圍。）
在某種程度上，這些困難的發生率可以通過DNS黑客來降低，這些黑客試圖僅將NPTv6轉換器後面的地址暴露給同樣位於NPTv6轉換器之後的主機，並且可能還將NPTv6轉換程序後面的主機的“內部”地址暴露給相同NPTv6轉換器背後的其他主機。然而，這並不是一個完整的解決方案。對這些問題的全面討論超出瞭本文件的范圍，但簡要地說：（A）依靠DNS來解決這個問題取決於主機總是從與其所在領域相同的DNS服務器進行查詢（或依靠DNS攔截代理，這會產生自己的問題），以及移動終端/應用程序不緩存這些結果；（b） 依靠DNS來解決這個問題取決於使用這些應用程序的所有網絡上的網絡管理員，以可靠和準確地維護使用這些應用的每個主機的當前DNS條目；以及（c）依賴DNS來解決這個問題取決於始終使用DNS名稱的應用程序，即使它們通常必須在DNS名稱無法為每個主機可靠維護的環境中運行。其他問題是，主機通常沒有單獨的可分辨名稱，主機也沒有可靠的方法來確定哪些DNS名稱與之相關，哪些名稱適合在哪些上下文中使用。
5.1、 考慮使用NPTv6轉換的網絡規劃人員建議
鑒於上述情況，考慮使用NPTv6轉換的網絡規劃人員應仔細考慮他們將來需要運行的應用程序類型，並確定地址穩定性和提供商獨立性是否符合他們的應用程序要求。
5.2、 對應用程序編寫者的建議
幾種機制（例如，STUN[RFC5389]、使用NAT周圍的中繼（Traversal Using Relays around NAT，TURN）[RFC5766]和交互式連接建立（Interactive Connectivity Establishment，ICE）[RFC5245]）已與傳統IPv4 NAT一起使用，以規避此類設備的一些限制。類似的機制也可以用於規避NPTv6轉換器的一些問題。然而，所有這些都需要外部服務器的幫助，或者與轉換器位於同一位置的功能，該功能可以告訴“內部”主機其“外部”地址是什麼。
5.3、 未來工作建議
可能需要定義一種通用機制，允許轉換域內的主機確定其外部地址和/或請求允許入站流量。如果要定義這樣的機制，理想情況下它將足夠通用，以適應IPV6應用程序可能遇到的其他類型的NAT，特別是IPv4/IPV6轉換[RFC6144][RFC6147][RFC6145][RFC6146][RFC6052]。出於這個原因和其他原因，這種機制超出瞭本文件的范圍。
6、 關於端口映射的註釋
除瞭在轉發數據包時覆蓋IP地址之外，NAPT44設備還覆蓋出站流量中的源端口號和入站流量中目的端口號。這種機制稱為“端口映射”。
端口映射的主要好處是它允許多臺計算機共享一個IPv4地址。大量內部IPv4地址（通常來自[RFC1918]私有地址空間之一）可以映射到單個外部、全局可路由的IPv4地址，本地端口號用於標識哪個內部節點應該接收每個入站數據包。這種地址放大特性在此時通常不被認為是必要的。
由於端口映射需要重寫傳輸層報文頭的一部分，因此需要NAPT44設備知道它們轉發的所有傳輸協議，從而抑制瞭新的和改進的傳輸協議的開發，並阻止瞭IPsec加密的使用。修改傳輸層報文頭與加密完整IP有效載荷的安全機制不兼容，並將NAPT44限制為轉發傳輸層，這些傳輸層使用容易在路由器中重新計算的弱校驗和算法。
由於修改傳輸層報文頭會造成嚴重的損害，並且在IPv6中使用端口映射的好處非常小（如果有的話），因此符合本規范的NPTv6轉換器不得執行端口映射。
7、 安全註意事項
當使用本文中定義的雙向算法映射部署NPTv6時，它允許到內部節點的直接入站連接。雖然這可以被視為NPTv6與NAPT44相比的優勢，但它確實為NAPT44網絡中更困難的攻擊打開瞭內部節點。從安全角度來看，盡管這種情況並不比在沒有NAT的情況下運行IPv6嚴重得多，但一些企業可能會假設NPTv6轉換器將提供與NAPT44設備類似的保護。
NAPT44實現中的端口映射機制要求在兩個方向上創建狀態。這導致瞭業界普遍認為NAT功能與有狀態防火墻相同。事實並非如此，NAT的轉換功能隻在一個方向上創建動態狀態，沒有策略。因此，建議NPTv6轉換器也實現[RFC6092]中所述的防火墻功能，並提供適當的配置選項，包括打開或關閉。
當[RFC4864]談到隨機化子網標識符時，其目的是讓蠕蟲更難猜測通告網絡前綴處的有效子網標識符。這不應被解釋為認可在諸如NPTv6的轉換器的混淆功能之後隱藏子網標識符。[RFC4864]專門討論瞭如何在不使用轉換器的情況下獲得所需的隱藏屬性。在應用層消息傳遞協議（如DNS、SIP、SMTP等）中拓撲可見的環境中，使用NAT時的拓撲隱藏通常無效。如果信息無法通過應用層獲得，[RFC2993]將無效。
由於與IKEv2/IPSecNAT穿越的潛在交互，測試NPTv6與當前IKEv2/IPsecNAT穿越的各個方面的交互將是有價值的。
8、 致謝
本文中描述的校驗和中性算法地址映射基於Iljtsch van Beijnum編寫的電子郵件。
以下人員提供瞭大大改進瞭本文件的建議或評論：Allison Mankin、Christian Huitema、Dave Thaler、Ed Jankiewicz、Eric Kline、Iljtsch van Beijnum、Jari Arkko、Keith Moore、Mark Townsley、Merike Kaeo、Ralph Droms、Remi Despres、Steve Blake和Tony Hain。
9、 參考文獻
9.1、 規范性引用文件
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
9.2、 參考資料
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture for IPv6", Work in Progress, February 1997.[NIST] NIST, "Draft NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0", September 2009.[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988.[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994.[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
附錄A：為什麼選擇GSE？
出於本次討論的目的，讓我們通過區分兩大類網絡來過度簡化互聯網的結構：中轉網絡和邊緣網絡。在本文中，“中轉網絡”是指向其他網絡提供連接服務的網絡。其自治系統（Autonomous System，AS）編號可能在BGP AS路徑中顯示為非最終位置，或者在移動和住宅寬帶網絡的情況下，其可能向無法證明RIR成員資格的較小網絡提供網絡服務。相比之下，“邊緣網絡”是指任何不是中轉網絡的網絡；它是最終的客戶，雖然它提供內部連接供自己使用，但在其他方面，它是公交服務的消費者。在路由方面，中轉域中的網絡通常需要某種方式來選擇如何路由到其他網絡；邊緣網絡通常對簡單的默認路由非常滿意。
[GSE]提案提案（在大多數方面與GSE相似，並受其啟發）直接回應瞭RIR社區當前的擔憂。邊緣網絡被用於IPv4環境，其中它們的地址與其上遊傳輸網絡的地址不相交；它要麼是獨立於提供商的，要麼是網絡前綴轉換器使其外部地址與內部地址不同，他們喜歡這種區別。在IPv6中，有一個口頭禪，即邊緣網絡地址應該從其上遊派生，如果它們有多個上遊，則邊緣網絡應該設計其網絡以等效地使用所有這些前綴。他們認為這是不必要的和不必要的操作復雜性，因此，在RIR社區中非常努力地尋求獨立於提供商的解決方案。
廣泛使用獨立於提供商的尋址有一個自然的、可能不可避免的副作用，從長遠來看，這可能是非常昂貴的。對於廣泛的PI尋址，路由表將枚舉中轉域邊緣的網絡，即邊緣網絡，而不是枚舉中轉域。根據2010年12月17日的BGP更新報告，目前有36000多個自治系統在BGP中進行通告宣傳，其中15000多個系統隻宣傳一個前綴。大約有5000個AS出現在AS路徑中的非最終位置，可能還有5000個網絡的AS編號在多個AS路徑中是終端。換言之，我們現在在路由表中有大約36000個公交和邊緣網絡的前綴，其中許多可以說隻需要一個自治系統號碼來實現多宿主。擁有多址所需工具的絕大多數網絡（2/3）並沒有明顯做到這一點，任何解決方案都可以為其提供地址獨立性，而無需RIR成員身份和BGP路由的開銷。
目前的增長估計表明，我們很容易看到，在15年內，這一數字將達到1000萬。路由表中的數萬個條目非常具有生存能力；雖然我們的協議和計算機可能會在數千萬條路由上表現得很好，但這些路由器產生的熱量和消耗的功率，以及對這些路由器成本的不可避免的影響，並不是一個好結果。為瞭避免有一個龐大且不可擴展的路線表，我們需要找到一種政治上可以接受的方法，讓我們回到列舉過境領域，而不是邊緣。
有許多建議。如上所述，Shim6將復雜性移到瞭邊緣，而邊緣正在反叛。地理尋址本質上迫使ISP從路由的角度“擁有”地理區域，否則地址中就不知道數據包應該發送到哪個網絡才能到達它。大都會尋址可能意味著監管機構，即使它是使用互聯網交換聯盟實施的，也會訪問直接服務於邊緣的交通網絡上的大量復雜性。最可能被接受的方案是任何能夠使邊緣網絡在運營上獨立於其上遊的方案，在添加、刪除或更改ISP時無需重新編號，並且不會因此給ISP或邊緣網絡帶來額外負擔。從應用角度來看，智能電網路線圖（NIST）中的另一個操作要求是
“……網絡應提供使特定域中的應用程序能夠通過信息網絡與任何其他域中應用程序進行通信的能力，並對應用程序可以相互連接的人員和位置進行適當的管理控制。”
換句話說，網絡的結構應允許並實現適當的訪問控制，但網絡的結構不應固有地限制訪問。
GSE模型通過在邊緣網絡與其上遊交通網絡之間無狀態地轉換前綴，以最少的麻煩和麻煩實現瞭這一點。用最簡單的術語來說，它使邊緣網絡能夠表現得好像從多歸屬和重新編號的角度來看，它具有獨立於提供商的前綴，而無需RIR成員資格的開銷或BGP連接的維護，並且它使中轉網絡能夠積極地聚合從其角度來看，提供商分配的客戶前綴，以維護合理大小的路由表。
附錄B：驗證代碼
本非規范性附錄作為概念證明；它在任何意義上都不是優化的。例如，一個人的補碼運算是在可移植的子程序中實現的，其中操作實現可以通過pragma使用一個人的補碼運算指令；這樣的實現可能需要顯式地將0xFFFF強制為0x0000，因為指令不會這樣做。該代碼的最初目的是驗證是否有必要通過零覆蓋來抑制0xFFFF，以及預測的子網編號問題是否真實。
重點是：
*證明如果在更新校驗和的字中沒有使用一個或另一個零表示，則程序以數學上1:1的方式映射內部和外部地址（每個內部地址映射到唯一的外部地址，並且外部地址映射回完全相同的內部地址），以及
*給出關於抑制0xFFFF校驗和的指導。
簡而言之，在補碼運算中，x-x=0，但將取零的負表示。如果按照[RFC1071]中的建議，將0xFFFF結果強制為值0x0000，則調整校驗和的位最初不能為0xFFFF，因為在返回時它將被強制為0。如果按照[RFC 1071]中建議，未將0xFFF結果強制為0x0000，那麼調整校驗和時的位最初無法為0，因為返回時它會被計算為0+（~0）=0xFFFF。我們選擇遵循[RFC1071]的建議，這意味著要求在具有/48外部前綴的網絡中不使用0xFFFF作為子網編號。
/**版權所有（c）2011 IETF Trust和代碼作者。保留所有權利。**在滿足以下條件的情況下，允許以源代碼和二進制形式重新分發和使用，無論是否進行修改：**-源代碼的重新分發必須保留上述版權聲明、本條件列表和以下免責聲明。*-二進制形式的再發行必須在隨發行提供的文檔和/或其他材料中復制上述版權聲明、本條件列表和以下免責聲明。*-未經特定事先書面許可，不得使用互聯網協會、IETF或IETF信托的名稱或特定貢獻者的名稱來認可或推廣本軟件衍生的產品。**本軟件由版權持有人和貢獻者“按原樣”提供，不承擔任何明示或暗示的保證，包括但不限於適銷性和特定用途適用性的暗示保證。在任何情況下，版權所有人或貢獻者均不對任何直接、間接、附帶、特殊、示范性或後果性損害（包括但不限於替代商品或服務的采購；使用、數據或利潤的損失；或業務中斷）承擔責任，無論是在合同、嚴格責任、，或因使用本軟件而以任何方式產生的侵權行為（包括疏忽或其他），即使已告知此類損害的可能性。*/#include "stdio.h"#include "assert.h"/**驗證NPTv6算法的程序**參數：*執行負零抑制：佈爾值**方法：*我們指定一個內部前綴和一個外部前綴。前綴長度被假定為兩者的共同長度，因此，為a/48。我們執行指定的三種算法。*“datagram”地址實際上是源地址內部->外部和目的地址外部->內部。*/unsignedshortinner_init[]={0xFD01,0x0203,0x0405,1,2,3,4,5};unsignedshortouter_init[]={0x2001,0x0db8,0x0001,1,2,3,4,5};unsigned short inner[8];unsigned short datagram[8];unsigned char checksum[65536] = {0};unsigned short outer[8];unsigned short adjustment;unsigned short suppress;/** One's complement sum.* return number1 + number2*/unsigned shortadd1(number1, number2)unsigned short number1;unsigned short number2;{ unsigned int result; result = number1; result += number2; if (suppress) { while (0xFFFF <= result) { result = result + 1 - 0x10000; } } else { while (0xFFFF < result) { result = result + 1 - 0x10000; } }return result;}/** One's complement difference* return number1 - number2*/unsigned shortsub1(number1, number2)unsigned short number1;unsigned short number2;{ return add1(number1, ~number2);}/** return one's complement sum of an array of numbers*/unsigned shortsum1(numbers, count)unsigned short *numbers;int count;{ unsigned int result; result = *numbers++; while (--count > 0) { result += *numbers++; } if (suppress) { while (0xFFFF <= result) { result = result + 1 - 0x10000; } } else { while (0xFFFF < result) { result = result + 1 - 0x10000; } }return result;}/**NPTv6初始化：第3.1節假設第3.4節**創建/48、內部格式的源地址和外部格式的源代碼。如果一個/48被另一個覆蓋，則計算調整。*/voidnptv6_initialization(subnet)unsigned short subnet;{ int i; unsigned short inner48; unsigned short outer48;/*Initializetheinternalandexternalprefixes.*/ for (i = 0; i < 8; i++) { inner[i] = inner_init[i]; outer[i] = outer_init[i]; } inner[3] = subnet; outer[3] = subnet;/* Calculate the checksum adjustment. */ inner48 = sum1(inner, 3); outer48 = sum1(outer, 3); adjustment = sub1(inner48, outer48);}/** NPTv6 datagram from edge to transit: Section 3.2 assuming* Section 3.4** Overwrite the prefix in the source address with the outer prefix and adjust the checksum.*/voidnptv6_inner_to_outer(){ int i;/* Let's get the source address into the datagram. */ for (i = 0; i < 8; i++) { datagram[i] = inner[i]; }/* Overwrite the prefix with the outer prefix. */ for (i = 0; i < 3; i++) { datagram[i] = outer[i]; }/* Adjust the checksum. */datagram[3] = add1(datagram[3], adjustment);}/** NPTv6 datagram from transit to edge: Section 3.3 assuming* Section 3.4** Overwrite the prefix in the destination address with the inner prefix and adjust the checksum.*/voidnptv6_outer_to_inner(){ int i;/* Overwrite the prefix with the outer prefix. */ for (i = 0; i < 3; i++) { datagram[i] = inner[i]; }/* Adjust the checksum. */ datagram[3] = sub1(datagram[3], adjustment);}/** Main program*/main(argc, argv)int argc;char **argv;{ unsigned subnet; int i; if (argc < 2) { fprintf(stderr, "usage: nptv6 supressionn"); assert(0); } suppress = atoi(argv[1]); assert(suppress <= 1); for (subnet = 0; subnet < 0x10000; subnet++) {/* Section 3.1: initialize the system */ nptv6_initialization(subnet);/* Section 3.2: take a datagram from inside to outside */ nptv6_inner_to_outer();/* The resulting checksum value should be unique. */ if (checksum[subnet]) { printf("inner->outer duplicated checksum: " "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) " "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)n", inner[0], inner[1], inner[2], inner[3], inner[4], inner[5], inner[6], inner[7], sum1(inner, 8), datagram[0], datagram[1], datagram[2], datagram[3], datagram[4], datagram[5], datagram[6], datagram[7], sum1(datagram, 8)); } checksum[subnet] = 1;/** The resulting checksum should be the same as the inner address's checksum.*/ if (sum1(datagram, 8) != sum1(inner, 8)) { printf("inner->outer incorrect: " "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) " "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)n", inner[0], inner[1], inner[2], inner[3], inner[4], inner[5], inner[6], inner[7], sum1(inner, 8), datagram[0], datagram[1], datagram[2], datagram[3], datagram[4], datagram[5], datagram[6], datagram[7], sum1(datagram, 8)); }/* Section 3.3: take a datagram from outside to inside */ nptv6_outer_to_inner();/** The returning datagram should have the same checksum it left with.*/ if (sum1(datagram, 8) != sum1(inner, 8)) { printf("outer->inner checksum incorrect: " "calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x) " "inner: %x:%x:%x:%x:%x:%x:%x:%x(%x)n", datagram[0], datagram[1], datagram[2], datagram[3], datagram[4], datagram[5], datagram[6], datagram[7], sum1(datagram, 8), inner[0], inner[1], inner[2], inner[3], inner[4], inner[5], inner[6], inner[7], sum1(inner, 8)); }/** And every octet should calculate back to the same inner value.*/ for (i = 0; i < 8; i++) { if (inner[i] != datagram[i]) { printf("outer->inner different: " "calculated: %x:%x:%x:%x:%x:%x:%x:%x " "inner: %x:%x:%x:%x:%x:%x:%x:%xn", datagram[0], datagram[1], datagram[2], datagram[3], datagram[4], datagram[5], datagram[6], datagram[7], inner[0], inner[1], inner[2], inner[3], inner[4], inner[5], inner[6], inner[7]); break; } } }}
長按二維碼關註我們吧
iptables命令簡介
Wireguard配置文件詳解
配置Wireguard的幾個進階玩法
strongSwan之ipsec.secrets配置手冊
某國產化臺式機產品介紹及維護（上）
某國產化臺式機產品介紹及維護（下）
HCLHub有所改善，但是還有進步空間
聽說你想收集HCL的設備版本？好吧，成全你！
Ubuntu 18.04開啟遠程桌面連接
以Ubuntu 18.04為例，介紹如何通過GUI安裝Vmware Tools
SD-WAN設備的串接透明部署怎麼實現？
如何用SD-WAN路由器實現串接透明部署？
