支持IPv6地址聚合和重編號的DNS擴展

本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協議的標準化程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright (C) The Internet Society (2000).

摘要
本文檔定義了對域名系統的修改以支持可重編號和可聚合IPv6尋址。這些修改包括用一種加速網絡重編號和修改已有查詢類型定義的方式以一種新的資源記錄類型來存儲IPv6地址，這些已有的查詢類型返回Internet地址作為部分附加開銷。
對于側重于IPv6地址的查找（常稱為反向查找），本文檔定義了一種新的區域結構，允許使用一種區域，它無需修改地址空間的相同拷貝（對多宿主供應商和站點而言）并能穿越網絡重編號事件。

目錄
1. 引言 2
2. 概述 3
2.1 域名到地址的查找 3
2.2 反向查找的根本機制 3
3. 特性 4
3.1 A6記錄類型 4
3.1.1 格式 4
3.1.2 處理 5
3.1.3 語義表示 5
3.1.4 域名解析過程 5
3.2 反向查找的區域結構 5
4. 已有查詢類型的修改 6
5. 使用說明 6
5.1 A6記錄鏈 6
5.1.1 實驗數據 7
5.1.2 粘合 7
5.1.3 變更 8
5.2 反向映射區域 9
5.2.2 ISP級別 9
5.2.3站點級別 10
5.3 查找 10
5.4 操作注意 11
6. RFC1886的過渡和配置注意 11
6.1 向AAAA過渡并與A記錄共存 11
6.2 從半位元標記向二進制標記過渡 12
7. 安全性考慮 12
8. IANA考慮 12
9. 鳴謝 12
10. 參考 13
11. 作者地址 14
12. 版權說明 14
致謝 15

1. 引言
維護DNS地址信息是阻礙節點和供應商在IPv4中進行重編號的難題之一?；诒３址€定的路由系統或其它目的，關于網絡重編號重要性的觀點可以參閱[RENUM1, RENUM2, RENUM3]。為了支持對不能阻止重編號的IPv6地址的存儲，我們定義了下面的擴展。
一種新的資源記錄類型，“A6”，定義為域名到IPv6地址的映射，并規定了間接的最主要的前綴位。
執行定位IPv4地址額外處理功能的現有查詢被重新定義為既處理IPv4地址，又處理IPv6地址。
一種新域，IP.ARPA，定義為支持基于IPv6地址的查找。
定義了一種新的前綴授權方法，它依賴于新的DNS特性[BITLBL, DNAME]。
這些變化都設計成與現有應用編程接口兼容，保留了對IPv4地址的支持。DNS中IPv4和IPv6地址共存相關的轉換問題在[TRANS]中討論。
本文檔提出了一種與目前實現相違背的方案并取代RFC1886中的規范。這些變化使網絡重編號和多宿主操作更加方便。與IPv6地址對應的A6記錄配置的域將自動產生的AAAA記錄插入到區域文件中，以簡化轉換。相信假以時日，RFC1886有望成為歷史。
本文檔將分為三個主要部分對本規范的定義與配置工具、規范內容和規范的應用案例進行描述。
本文檔中的關鍵字“必須”，“必須不”，“要求的”，“應該”，“不應該”，“會”，“不會”，“建議”，“或許”，“可選的”在[KWORD]中解釋。關鍵字“推薦”表示介于或許和應該之間，通常認為多數情況下遵從“推薦”會帶來切實的好處。

2. 概述
本節簡述了存儲IPv6地址和基于IPv6地址查找的DNS工具，包括本文檔或其它文檔定義的工具。
2.1 域名到地址的查找
IPv6地址被保存為一條或多條A6資源記錄。單個A6記錄或許包括一個完整IPv6地址，或者一個地址的鄰近部分和產生一個以上地址前綴的信息。前綴信息包括一個前綴長度和一個域名，這個域名反過來又是一條或多條定義地址前綴的A6記錄的所有者，這些地址前綴需要形成一個或多個完整IPv6地址。若前綴長度為0，則沒有域名并且所有主要的地址位都是有意義的?；蛟S存在多級間接查找，任何一級存在多個A6記錄都會增加其形成的IPv6地址數量。
查找一個IPv6地址的應用程序通常讓DNS解析器訪問多條A6記錄，即使要查找的域名只對應一條A6記錄，也可能返回多個IPv6地址。DNS安全[DNSSEC]并不直接認證返回地址的合法性。如果作了標記，自然可以認證返回地址的A6記錄。
實現必須限制解析器對應一個客戶請求所需的工作量。這個原則必須擴展到限制DNS請求的產生，這些DNS請求對應域名到地址（或地址到域名）查找。
2.2 反向查找的根本機制
本部分描述本文檔使用的DNS新特性。本部分是概述，不是這些特性的詳述。更詳細的細節讀者可以參考對應的參考文檔。
2.2.1 專用邊界的授權
這種反向查找新機制取決于一種被稱為“位串標記”[BITLBL]的新DNS標記類型。這種標記簡潔地表示一種專用位串，這些位被當作一種分層次有序的單個位域標記。因此，資源記錄能存儲為專用位邊界。
第五部分的例子將配置后文描述的位串標記，它是[BITLBL]中定義的語法的子集?！癨[“ and ”]”間包括了十六進制的基本表示“x”和有序的十六進制位。這些用數字表示的位對應了一個有序的重要性遞減的單個位域標記。（如果一次只列出一位，這是它們出現的反序，但它似乎是更方便的符號。）這種位串后面有一個斜線“/”和一個十進制數。若省略十進制數部分，表明十進制位數是十六進制位數的四倍。
連續的位串標記和單個位串標記一樣（就位數字段大小限制而言）都包含了一定次序的所有連續的標記位。例如，下面的域名可以用一個“QCLASS=IN, QTYPE=PT”的查詢來查找IPv6地址為3ffe:7c0:40:9:a00:20ff:fe81:2b32節點的域名。
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
\[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
2.2.2 可重用區域
DNS地址空間授權不是通過區域分割和NS記錄來實現，而是通過一種類似于CNAME的記錄，稱為DNAME資源記錄[DNAME]。DNAME記錄為域名空間的整個子樹而不是為單個節點提供替代命名。這導致用DNAME記錄的RDATA中的名字來取代一些要查詢域名的后綴。
例如，當一個提供遞歸查詢的域名解析器或服務器查找一個a.b.c.d.e.f的QNAME時，可能會得到一條將其指向a.b.c.w.xy的DNAME記錄：
d.e.f. DNAME w.xy.
3. 特性
3.1 A6記錄類型
A6記錄類型是指IN（互聯網）類型和類型編號為38（十進制）的類型。
3.1.1 格式
A6記錄的RDATA部分包括兩個或三個字段。
+-----------+------------------+-------------------+
| 前綴長度 | 地址后綴 | 名字前綴 |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
前綴長度，用取值范圍為0-128的8位無符號整數編碼。
IPv6地址后綴，按網絡序號（前面的高位字節）編碼。這個字段必須有足夠的字節數可設置128位的前綴長度，包括0-7位填充位以使這個字段具有完整的字節數。如果出現填充位，當裝載區域文件時必須置位為0，并且接收時不予處理（SIG[DNSSEC]認證除外）。
名字前綴，編碼成域名。根據[DNSIS]規則，這個名字不能被壓縮。
如果前綴長度為0，域名部分將不會出現。如果前綴長度為128，名字后綴部分將不會出現。
建議把要用作其它A6記錄前綴的A6記錄地址后綴中所有可以忽略的末位都設為0。
3.1.2 處理
一個QTYPE為A6的查詢產生對名字前綴的A6類型和NS類型附加處理開銷，如果產生的話，這些名字前綴在結果部分A6記錄的RDATA字段中。這個處理過程應該將A6記錄名字前綴作為附加數據進行遞歸處理。如果應答包的大小有限制，A6記錄的附加部分具有比NS記錄更高的優先級。
一個前綴長度L1>0的A6記錄如果查找一個具有前綴長度L2>L1的A6記錄的域名，會出現錯誤。如果解析器遇到這種情況，必須忽略這個具有不合法前綴長度的A6記錄。如果還能從有效的A6記錄得到地址，解析器的健壯性將不讓這個錯誤出現，但建議區域維護經常檢查其區域有關的所有A6記錄。
3.1.3 語義表示
區域文件中A6資源記錄RDATA部分的語義表示包括兩個或三個由空格隔開的字段。
前綴長度，表示為一個范圍在0-128的十進制數。
[AARCH]中定義的IPv6地址的語義表示（盡管一些首位和末位可能無關緊要）。
域名，如果前綴長度不為0。
如果前綴長度為0，域名必須為空。如果前綴長度為128，IPv6地址可能為空。就象3.1.1節描述的那樣，地址前面部分等于前綴長度的位數應該隱式地（通過：：符號）或顯式地設為0。
3.1.4 域名解析過程
為了得到IPv6地址或對應給定域名的地址，DNS客戶端必須得到一個或多個完整的A6記錄鏈，每個鏈以給定域名的記錄開始，并包括那個記錄中前綴名字對應的記錄等，遞歸地以前綴長度為0的A6記錄結束。
如果前綴長度為0，域名必須為空。如果前綴長度為128，IPv6地址可能為空。就象3.1.1節描述的那樣，地址前面部分等于前綴長度的位數應該隱式地（通過：：符號）或顯式地設為0。通過從鏈中最初的A6記錄得到每個位的具體位置，一個鏈能形成一個IPv6地址，這個鏈就象前綴長度描述的那樣包括位的有效位置。給定域名的所有IPv6地址包括該域名開頭的所有完全A6記錄得到的地址，丟棄在3.1.2節定義的有無效前綴長度的記錄。
如果一些A6查詢失敗并且其它查詢成功，客戶端可以為一個主機得到一個非空但不完全的IPv6地址。很多情況下，這也是可以接受的。A6 記錄集的完整性可以總是通過檢查來確定。
3.2 反向查找的區域結構
事實上新方案的數據很少會在IP6.ARPA的情況下出現；僅僅第一級授權需要在那個域下出現。如果最高級授權是通過NS記錄而不是DNAME記錄實現，更多授權級別能夠置于IP6.ARPA下，但將在TLAs[AGGR]級別重編號時產生一些開銷。因此，這里認為所有地址空間授權應該通過DNAME機制而非NS機制來實現。
此外，由于統一配置將簡化地址授權的維護，建議地址和前綴信息直接以DNS標記“IP6”保存。換而言之，遵從這個建議意味著“IP6”是支持IPv6反向查找的DNAME記錄中RDATA字段中第一個標記。
當授權邊界與任何保留或必須為0的位相鄰時，高級別的實體必須將那些位由自己控制，并只授權給低級別實體能授權的那些位。
為了給已知IPv6地址的節點查找域名，DNS客戶端必須按名字執行一個QCLASS=IN，QTYPE=PTR的查詢，這個名字是由作為一個或多個位串標記[BITLBL]的128位地址形成的，在兩個標準的“IP6.ARPA”標記后。如果不能從服務器得到遞歸式服務，并且不能返回要得到的PTR記錄，解析器必須反復地處理返回的在[DNAME]中描述的DNAME記錄和[DNSCF]中描述的NS記錄。
4. 已有查詢類型的修改
所有現有執行A類附加處理的查詢類型如名字服務器（NS）、郵件交換（MX）、郵箱查詢類型（MB）和實驗性AFS數據庫（AFSDB）以及路由直通類型，必須重新定義成能執行A、A6和AAAA類附加處理，并且A類包括最高優先級，AAAA類優先級別最低。這個重定義就是說，當處理任何上述查詢時，名字服務器可以增加任何有關的附加響應部分本地可用的IPv4和IPv6地址信息。A6記錄的遞歸式包括是可選的，這些記錄被包含在附加處理部分中的A6記錄所引用。
5. 使用說明
本節舉例說明前面定義的機制的使用。這里提到的所以地址和域名都是假設的，僅僅用于描述目的。為了描述的可讀性，授權的例子只用4位邊界。這個規范與位的排列無關。
假設例子中用的都是IPv6可聚類地址格式[AGGR]。
5.1 A6記錄鏈
讓我們看一個到兩個中間服務商A和B的多宿主節點的例子。服務商A本身多宿主到兩個"傳輸"服務提供商C和D。服務商B從單個服務商E得到其傳輸服務。為了簡單，假定C、D和E都屬于相同的頂級聚合以"2345"為標識（包括格式前綴），并且ALPHA-TLA.ORG的TLA授權分別分配C、D和E下級聚合（NLA）前綴2345:00C0::/28， 2345:00D0::/28和2345:000E::/32。
C為A分配NLA前綴2345:00C1:CA00::/40，D為A分配前綴2345:00D2:DA00::/40，E為B分配前綴2345:000E:EB00::/40。
A為X分配訂閱標識“11”，B為X分配訂閱標識“22”。因此，節點X繼承地得到了三個地址前綴：
2345:00C1:CA11::/48來自A，給通過C的路由。
2345:00D2:DA11::/48來自A，給通過D的路由。
2345:000E:EB22::/48來自B，給通過E的路由。
假設N是站點X的一個節點，并在該站點分配子網號1，使用接口標識1234:5678:9ABC:DEF0。在配置中，該節點將擁有三個地址：
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
2345:000E:EB22:0001:1234:5678:9ABC:DEF0
5.1.1 實驗數據
假設DNS中域名X.EXAMPLE標識站點X，而A、B、C、D和E分別用A.NET、B.NET、C.NET、D.NET和E.NET表示。在每個域中，假設子域IP6帶有相應的前綴。節點N由N.X.EXAMPLE唯一標識。下面的記錄將出現在站點X的DNS中。
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
其它的地方將會出現：
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.

SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.

A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.

B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.

C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
5.1.2 粘合
通常，當X.EXAMPLE有些或所有DNS服務器都在X.EXAMPLE自己的區域內，頂級區域EXAMPLE必須帶有足夠的“粘合”信息使DNS客戶端能訪問那些名字服務器。這在IPv4和IPv6中都是正確的。但是，A6記錄給DNS管理員更多的選擇。粘合劑可以是下面的任何一種：
從X.EXAMPLE區域復制的最少的A6記錄集，
能破壞那個最小記錄集結構的（可能更少的）記錄，
或者服務器中所有全局地址前綴長度為0的記錄集。
折中處理能很好地維護健壯性。通過實現第一或第二和第三種情況，最好的和最差的都可以融合在一起。為了描述粘合劑選項，假設兩個名字服務器NS1.X.EXAMPLE和NS2.X.EXAMPLE都為X.EXAMPLE服務，并在子網1和子網2分別有接口標識::1:11:111:1111和::2:22:222:2222。這樣，頂級區域EXAMPLE就可以包含下面一個或多個A6記錄作為 粘合劑。
$ORIGIN EXAMPLE. ; first option
X NS NS1.X
NS NS2.X
NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.

$ORIGIN EXAMPLE. ; second option
X NS NS1.X
NS NS2.X
NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET
NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.

$ORIGIN EXAMPLE. ; third option
X NS NS1.X
NS NS2.X
NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
A6 0 2345:00D2:DA11:1:1:11:111:1111
A6 0 2345:000E:EB22:1:1:11:111:1111
NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
A6 0 2345:00D2:DA11:2:2:22:222:2222
A6 0 2345:000E:EB22:2:2:22:222:2222
與服務商A.NET和B.NET的X.EXAMPLE的前綴重編號相比，第一和第二種粘合劑選項具有健壯性，但如果服務商的DNS不可訪問，粘合劑選項將失效。除了EXAMPLE和X.EXAMPLE區域本身，與DNS失效相比第三種選項具有健壯性，但當站點X的地址空間重編號時，必須作相應的修改。
如果EXAMPLE區域包括多余的粘合，例如第一種和第三種A6記錄選項的融合，那么正常情況下，DNS客戶端將給出復制的IPv6地址。但是如果服務商的DNS失效，仍能從前綴長度為0的記錄得到地址。如果EXAMPLE區域在X.EXAMPLE重編號后邊，DNS客戶端得到的一半地址需要更新。
當然，實際上將自動產生并且/或者檢查前綴長度為0的粘合劑記錄。
5.1.3 變更
在上述結構中或多或少反映了幾個專用假設。根據某些有用的概念和雙方的協定，需要區別所有下面選擇。
首先，站點X選擇將子網信息存入單個A6記錄，而不是將其并入每個節點的A6記錄。
第二，服務商A和B都將站點X當成“訂閱者-X”。
第三，站點X通過IP6.X.EXAMPLE中有可忽略位的A6記錄選擇間接的服務商信息。另一種選擇是給每個服務商復制每條子網記錄。
第四，B和E之間與A、C和D間用的前綴命名約定稍微有些不同。每層網絡實體之間必須協商命名。
第五，以上的前綴鏈置于ALPHA-TLA.ORG之上?？赡軙辛硗獾募墑e來分配TLA的值并且保存包括那些位的A6記錄。
最后，上述結構反映了一個假設，由給定實體分配的地址字段僅僅記錄在那個實體保存的A6記錄中。那些位能夠存入更低級別實體區域的A6記錄，因此：
IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
等等。

或者高級別實體既能夠保存A6記錄（具有不同DNS所有者名字），又能允許低級實體選擇A6鏈的一種模式。但避免數據復制的一般規則建議，分配的值總是適合存儲在給定那些值的實體。
對區域維護而言，有可能但不是必須推薦優先考慮由A6記錄提供的重編號支持，并且記錄一個區域文件內的所有IPv6地址。
5.2 反向映射區域
假設在TLAs中分配的有前綴（001）和識別號0345、0678和09AB的地址空間，在ALPHA-TLA.ORG、BRAVO-TLA.ORG和CHARLIE-TLA.XY區域中維護，那么IP6.ARPA區域將包括：
$ORIGIN IP6.ARPA.
\[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
\[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
\[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
每個TLA識別號包含的末尾8個0位表示當前可聚合全球單播地址格式[AGGR]中的8個保留位。
下面的反向數據表示了給網絡服務商C、D和E的ALPHA-TLA地址分配。
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
\[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
\[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
5.2.2 ISP級別
服務商A通過在其區域文件中傳送下面的授權信息。
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
\[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
\[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
\[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
注意有些域名會在多個DNAME記錄的RDATA中出現。這樣，一個區域就用來映射多個前綴。
5.2.3站點級別
就拿用IP6.X.EXAMPLE作地址到域名轉換的用戶X.EXAMPLE來說。這個域由兩個不同的DNAME記錄所引用，這兩個記錄由兩個不同服務商維護。
$ORIGIN IP6.X.EXAMPLE.
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
等等。
子網1并不需要用DNAME記錄來命名；子網位可以和接口識別號聯系在一起。但如果按同樣的方式在A6記錄和反向區域處理子網，將可能要維護區域中的每個前綴的前向和反向定義的數據。
5.3 查找
根據前面的描述，一個為地址2345:00C1:CA11:0001:1234:5678:9ABC:DEF0查找主機名的DNS解析器將得到確定的DNAME記錄，并形成新的查詢。假設從已知服務器IP6.ARPA開始處理，但沒有服務器能提供遞歸處理，并且沒有服務器有其它附加的信息緩沖，這里是查找的名字順序和響應結果（都有QCLASS=IN, QTYPE=PTR）。
對IP6.ARPA服務器：
QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
結果：
\[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.

對IP6.ALPHA-TLA.ORG服務器：
QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
結果：
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.

對IP6.C.NET.服務器：
QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
結果：
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.

對IP6.A.NET.服務器：
QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
結果：
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.

對IP6.X.EXAMPLE.服務器：
QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
結果：
\[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
\[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
所以這樣得到的DNAME（和NS）記錄都存入緩沖，以加快邏輯上接近該地址的地址解析速度。如果要在最末的PTR記錄TTL中解析N.X.EXAMPLE的另一個全球地址，那個記錄不能再次得到。
5.4 操作注意
在5.1節描述的層次相鄰實體中，比如網絡服務商和客戶，必須就擁有授權前綴定義的DNS名字達成一致。一個簡單的約定就是使用位串標記來準確表示那些有高級實體分配給低級實體的位。例如，用“[x11/8]”取代“訂閱者-X”。這把定義授權前綴的A6記錄放在DNS樹中與授權有關的DNAME記錄同樣的位置。這些簡化的代價就是低級區域重編號時，必須修改其上面指出的A6記錄。實際上這些代價是可以接受的。
6. RFC1886的過渡和配置注意
如果前綴已經用A6記錄“向上授權”，DNS資源記錄數目要求有由于非細節因素產生單個IPv6地址增長。典型地，那些記錄并不一定來自不同的DNS區域（會因為一般原因而單獨失效）。當得到多個IPv6地址時，RR數的增加將按比例減少－并且DNS應答總數甚至會減少－如果地址邏輯上是聚合的。但是，記錄仍能輕易超出DNS響應中的可用空間，例如，這些響應會返回很大的RR集[DNSCLAR]給MX、NS或SRV查詢。特別地，當那些授權指向其它區域的記錄時，性能和DNS查找可靠性全面下降的可能性很大，并且隨著授權前綴數目的增多而增大。
DNS安全[DNSSEC]在于緩沖數據的可信賴性，這也是DNS本身固有的問題，但將其應用到IPv6地址的代價會以一個系數而線性增大。如果不同簽名鏈必須由不同A6記錄驗證，這個系數可能會大于有關授權前綴的數目。如果使用了受信賴的集中式緩沖服務器（例如在[TSIG]）,代價可用分割為可接受的級別。有可能出現一種新的情況，IPv6地址可能由安全和不安全區域中的A6記錄產生。
建議授權前綴限制在一個或兩個級別，直到從A6記錄得到更多的配置經驗。一種可行的調整機制就是從沒有授權前綴（所以A6記錄前綴長度為0）開始，再到在單個區域使用單個級別的授權。（如果A6記錄的前綴TTL能維持在一個適當的范圍，快速重編號的能力不會失效。）實驗中會為子網中的主機引入更多非常靈活的授權。
6.1 向AAAA過渡并與A記錄共存
包括A6記錄區域的管理員能容易地調整那些能處理AAAA記錄但不能處理A記錄的解析器。通過一個模擬主機名到IPv6地址解析的處理過程，管理員能給所有具有A6記錄的區域名自動產生AAAA記錄（參見3.1.4節）。必須注意到，分配給AAAA記錄的TTL必須小于在那個記錄中形成IPv6地址的A6記錄TTLs的最小值。為了全面的健壯性，應該監控不同區域中的A6記錄變化（TTL或RDATA中），即使那些產生AAAA記錄的區域沒有任何變化。如果區域是安全的[DNSSEC]，產生的AAAA記錄必須與其余區域數據一起作標記。
特定啟發式區域可以用于避免為記錄前綴的A6記錄產生AAAA記錄，盡管過多的記錄相當少見也沒有害處。這些啟發式實例包括刪除前綴長度小于區域文件中最大值的A6記錄，或者地址后綴末尾有一些位數為0的記錄。
在客戶端執行查找時，A6和AAAA查詢可能設置成其中的一個次序：A6到AAAA；AAAA到A6；僅僅A6；或者兩者并行。缺省的次序（如不可配置，則是唯一次序）必須首先是A6，然后是AAAA。如果AAAA不可用，新的配置將改變缺省配置。
[TRANS]描述了IPv4和IPv6地址間的優先級指南和選擇。以后文檔中所有涉及的AAAA記錄都按上段描述次序的A6和/或AAAA記錄處理。
6.2 從半位元標記向二進制標記過渡
遵照RFC1886進行反向查找的實現如下：
通過一序列點分帶“.IP6.INT”后綴的半位元，IPv6地址表示成IP6.INT域中的一個名字。半位元序列安反向順序編碼，如首先編碼低序半位元，然后編碼高序低序半位元。每個半位元用十六進制數位表示。例如，5.3節例子中地址為2345:00C1:CA11:0001:1234:5678:9ABC:DEF0的名字按DNS名為“0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int.”查找。
遵照本規范的實現將在IP6.ARPA進行二進制標記查找,如3.2節所述。建議過渡期間首先在IP6.ARPA進行二進制標記查找，如果查找失敗再在IP6.INT按“半位元”查找。
7. 安全性考慮
為那些確定IPv6地址的A6記錄的簽名認證[DNSSEC]分布在多個實體中，反映了地址占有地址空間的授權路徑。DNS安全性完全可用于位串標記和DNAME記錄。就象在IPv4中一樣，名字到地址映射認證邏輯上獨立于地址到名字映射的認證。
不管有沒有DNSSEC，DNS查找的選擇性干擾會產生3.1.4節所述的不完整但非空的地址。在某種情況下，如果它比DNS完全失效更有害，這種情況可以通過在客戶端拒絕響應不完整的地址，或者通過在服務器端列出前綴長度為0的A6記錄的所有地址得到緩解。
8. IANA考慮
A6資源記錄被分配類型值38。

9. 鳴謝
作者非常感謝下列人員的有價值的討論和意見：Mark Andrews, Rob Austein, Jim Bound, Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden, Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
10. 參考
[AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6, RFC1886, December 1995.

[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.

[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format", RFC2374, July
1998.

[BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
RFC2673, August 1999.

[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.

[DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC2181, July 1997.

[DNSIS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC1035, November 1987.

[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
Security Extensions", RFC2535, March 1999.

[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.

[RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.

[RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering
Overview: Why would I want it and what is it anyway?", RFC
2071, January 1997.

[RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC2101, February 1997.

[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC1933, April 1996.

[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC2845, May 2000.
11. 作者地址
Matt Crawford
Fermilab
MS 368
PO Box 500
Batavia, IL 60510
USA

Phone: +1 630 840-3461
EMail: crawdad@fnal.gov

Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

EMail: huitema@microsoft.com
12. 版權說明
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its suclearcase/" target="_blank" >ccessors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
致謝
Funding for the RFCEditor function is currently provided by the Internet Society.