適應詳細注冊地址信息查詢的ＲＰＳＬ擴展

摘 要：提出了一種層次化的、支持本地語言的、互通的詳細IP注冊地址數據交換模型及其查詢機制，并對RPSL語言進行了相應擴展，解決了現有機制的一些不足之處。

關鍵詞：路由策略規范語言； Whois查詢； IP注冊地址

中圖分類號：TP393 文獻標志碼：A

文章編號：1001-3695(2008)07-2132-03



Extension of RPSL for searching detailed and 

registered IP address information



ZHANG Xin-chang1，2， LI Xiao-dong1，3， WANG Feng1，3， YAN Bao-ping1

（1.Computer Network Information Center， Chinese Academy of Sciences， Beijing 100080， China; 2.Graduate School， Chinese Academy of Sciences， Beijing 100049， China; 3.China Internet Network Information Center， Beijing 100080， China）

Abstract:This paper proposed a hierarchical model of interchanging registered address data and mechanism of searching the IP address information， which made it easy for people to obtain the information described by local language， and to search the information in any registry’s platform. For supporting the model and mechanism， a new class and some modified attributes are added in RPSL Language.

Key words：RPSL（routing policy specification） language; Whois search; IP registered address



0 引言

路由策略規范語言(routing policy specification language， RPSL)^[1]是Internet策略規范語言（如RIPE-181或RFC1786）的替代語言，它彌補了原有規范語言的不足，成為一種更通用的策略語言。RPSL語言具有可擴展的特性，新的類和屬性可以容易地引入。

目前，IP注冊地址查詢可通過Whois查詢^[2]來實現。Whois數據庫采用RPSL語言描述路由策略和地址分配信息，所涉及到的RPSL對象是mntner、inetnum、inet6num、person和role對象。各個對象描述了所需信息，并以其作為數據交換格式。Whois數據庫主要由大的互聯網注冊機構建立并維護，并對外提供查詢服務。目前的IP注冊地址信息主要是一個較大的地址段信息。詳細的IP注冊地址分配信息（單個IP地址信息或范圍很小的IP地址段）可以方便地互連網絡管理和維護，為提高網絡安全性提供了有效途徑。另外，對于IP地址敏感的互聯網業務提供也將起到重要作用。例如在P2P應用中，確認IP地址與網絡實體的對應關系對改善P2P應用的性能也有著巨大的積極作用，特別是對于我國下一代互聯網中IPv6地址資源的有效管理，也是必不可少的一部分。

本文分析了目前IP注冊地址信息查詢機制的不足，提出了一種新的適應詳細IP注冊地址數據交換模型及其查詢機制，并針對該模型對RPSL進行了擴展。該模型是層次化的，既適合本地查詢，又能解決跨越不同注冊機構查詢時所帶來的無法查詢問題；同時該模型具有較大的靈活性，可以在不同范圍內建立，便于管理和維護。

1 現有IP注冊地址查詢機制

1．1 地址注冊機構

IP注冊地址信息主要通過一些互聯網注冊機構的Whois查詢實現。互聯網注冊機構的關系如圖1所示，逐層分配IP地址。目前提供地址查詢的機構主要是圖1中的上三級機構。其中，RIR是互聯網注冊機構，包括AFRINIC、APNIC、ARIN、LACNIC和RIPE NCC。NIR是國家互聯網注冊機構，LIR是本地互聯網注冊機構，通常就是ISP。

1．2 現有查詢機制特點

如上文所述，IP注冊地址信息查詢基于RPSL數據交換。在當前的RPSL語言中， 各對象中的屬性（字段）用英文描述，并轉換為原始ASCII碼。在圖1中， 某地址注冊機構一般僅對其所分配的IP地址信息作記錄并提供查詢服務。例如從APNIC的Whois數據庫中查詢159.226.6.235信息，將得到地址段159.226.0.0/16的注冊信息，但在RIPE NCC、 AFRINIC的Whois數據庫中查詢將報查詢范圍出錯。

現有的IP注冊地址信息查詢機制尚存在不足之處，主要表現為：a）在RPSL語言中，許多類包含聯系人名稱、地址及其他描述等與本地語言環境密切相關的信息。這些信息用英文描述有時是不準確的，如中文姓名“Zhang Ming”，可以表示“張明”“張名”“張鳴”等若干同音異形姓名。這種問題在非英語語言中大量存在。另外，原始的ASCII碼對本地語言的描述能力是有限的，具體信息參見文獻[3]。b）用英文來描述對象所帶來的另一個顯然的問題是對本地用戶不友好。c）現有的一個大的注冊機構在建立詳細的特別是包含其他注冊機構IP注冊地址信息時，勢必造成查詢效率的下降。特別是當需要記錄絕大多數主機的IP注冊地址信息時，查詢效率將大大下降。d）詳細的IP注冊地址分配數據庫以一個國家為單位建立和維護最為適合，可以根據具體國家需求建立。e）當從一個Whois查詢平臺中查詢其他不屬于該機構管理的IP注冊地址信息時，多數情況下將得不到正確信息，如上文所述。

2 詳細IP注冊地址查詢機制

本章將提出一種層次化的、支持本國語言的、可供全球和本國查詢的詳細IP注冊地址數據交換模型及其查詢機制。從圖1中可看出，地址注冊機構的關系是層次化的，但其查詢是非層次化的，即從某Whois查詢平臺中查詢到的是該機構數據庫中的信息，或作其他非層次化處理。

2．1 IP注冊地址數據交換模型

IP注冊地址數據交換機制的模型如圖2所示。其中，RD（redirection database）是可選的，表示重定向數據庫，由它統一對本國的IP地址信息查詢進行定向。RD可以由NIR建立，特別是在一個國家的IP地址都由其分配的情況下更適合如此處理；RD還可以由其他國家權威機構建立。RD記錄了某國的IP注冊地址范圍所屬下級機構的數據庫地址（為簡化說明，數據庫地址即指負責提供IP地址信息查詢主機IP地址，本文在后文中將作類似處理，不再進一步說明）。RD由國家在內部建立，容易協調，可選本地語言，并且有利于跨越直接在RIR注冊的機構進行信息查詢。

LIR_AD和NIR_AD分別記錄了下級地址分配機構（如ISP）的地址范圍與其數據庫地址。ISP_AD一般情況下記錄直接在ISP注冊的主機地址（范圍）信息。如果需要，ISP_AD可以繼續向下擴展，此時ISP_AD記錄了兩類IP注冊地址信息，分別為直接在ISP注冊的主機地址（范圍）或下級ISP的地址范圍與其數據庫地址。RIP_AD與LIR_AD類似，不再詳述。在本文模型下，也有IANA_AD概念，但本文主要關注RIR以下的模型，亦不再詳述。

各數據庫除了記錄上述信息外，同時記錄上級機構的數據庫地址（IANA_AD除外）。另外，在國家范圍內的數據庫用本地語言描述，以便對用戶提供準確、詳細和友好的信息。

2．2 IP注冊地址信息查詢原理

本文中的IP注冊地址信息查詢有兩個過程，即數據庫地址定位和信息查詢。數據庫地址定位即確定所查IP地址信息所處的數據庫地址，該數據庫記錄了該IP最詳細和最準確的信息。為了進行地址定位，需要各數據庫所在主機附加一個定位模塊，此模塊用于處理下文的定位消息和查詢本機數據庫，并作出相應處理，本文不進一步討論此細節。當確定了某IP地址所處的數據庫地址后，進行信息查詢過程，此過程即一般的數據庫查詢過程。因此，本文主要說明數據庫地址定位過程。

在任意數據庫查詢平臺上（也可擴展到一般主機）登錄查詢某IP地址，后者按照最大匹配索引該地址。如果該地址由數據庫所對應的地址注冊機構所分配，則索引結果不為空。非空的索引結果有兩種情況：該地址的最大匹配對應某詳細信息，則該信息即為查詢結果；否則，對應一個（組）IP地址，表示應向該地址發出定位請求消息，因為該地址記錄了更加詳細的信息。當索引結果為空時，表示該IP地址不由所對應的地址分配機構所分配，則向上級機構的查詢模塊發出定位請求消息。某定位模塊無論得到上述哪種定位消息，都進行同樣的定位過程。按照上述過程將最終找到相應的數據庫地址。

另外，在一個數據庫定位模塊定位過程中，可以加入一些地址段的定位記錄（僅保存一定時間），以加快以后查詢的定位過程。即使以后IP注冊信息改變，新加入的定位記錄也不會導致錯誤，因為每個定位模塊都有完整的定位功能。但是，加入的定位記錄對應的地址段應該是高聚合的，以保證查詢效率。

2．3 IP注冊地址查詢實例

以圖2為例說明IP注冊地址查詢過程。為簡化說明，負責建立ISP_AD1的ISP記為ISP1，其他類似。查詢過程可分為以下幾種情況：

a）在ISP_AD1登錄查詢該ISP分配的某IP地址。由于ISP1分配了這個地址，假定其記錄了該地址的詳細信息(不失一般性，圖2中ISP都作類似假定)，其直接返回該地址的詳細信息。

b）在ISP_AD1登錄查詢ISP_AD3分配的一個地址。所要查詢的地址不由ISP1或其下級機構分配，故在ISP_AD1中得到的索引結果為空。因此，ISP_AD1的定位模塊向其上級即LIR_AD1發出定位請求消息，后者進行同樣的過程。以此進行，最后定位到ISP_AD3，并由其向查詢者返回查詢結果。需要注意的是，由于加入了RD1，該次查詢僅在國內運行。

c）在ISP_AD1登錄查詢ISP_AD4分配的一個地址，定位和查詢過程與上述類似。此處說明跨國查詢的細節，即對國外用戶而言，提供本地語言無論從理解還是其他因素角度出發，都是不現實的。在本文機制中，國家的頂級地址分配機構在與RIR交換相應數據時，指定一對外的數據庫地址即可解決上述問題，并且對外數據庫也可根據實際情況向下作類似擴展。

3 RPSL擴展

3．1 Address-info類

Address-info類用于本文所提IP注冊地址數據交換機制中的所有相鄰數據庫間的數據交換，以便確定層次結構，提供查詢。Address-info類屬性如表1所示。其中省略了每個類必有的changed和source屬性。

Range屬性定義了一特定地址段（包括具體地址），其值類型為address-prefix-range。例如30.0.0.0/8^24-32 指明地址范圍30.0.0.0/8中長度為24~28的地址段，如30.9.9.96/28。Range屬性是類關鍵字，以便檢索。關于值類型address-prefix-range更多的信息，可參見文獻[1]。

Info-hosts屬性表示負責range的數據庫主機IP地址，為保證可靠性可能有多個這樣的IP地址（即該庫有備份）。其中值為ipv4-address的info-hosts是必需的，值為ipv6-address的info-hosts-IPv6是可選的。這種安排在IPv6最終實現后可作簡單調整。

Descr和remarks的值類型最終將轉換為ASCII碼，但在描述時可能是英文（free-form，主要用于國際交換），也可能是本地語言轉換的punycode碼^[4]（主要用于國內數據交換）。例如“中關村南4街”的punycode碼為“xn-4-kq6as8hlrct75bl47b”，其中該碼指明了屬于中文。在這樣處理之后對本國用戶提供了良好的語言界面。

Country屬性用于描述國家名，其值類型為country-name。其他的屬性參見文獻[1]。

3．2 其他類的擴展

除address-info類外，注冊地址交換數據要用到五個類，分別是mntner、inet6num、inetnum、person和role。為使信息對本地用戶使用本地語言，對所有涉及語言描述的屬性進行上述擴展，即將〈free-form〉擴展為〈free-form〉/punycode。

4 結束語

本文所提模型和查詢機制主要有以下特點：a） 解決了本地信息描述不準確性問題。b） 在本地可以使用本地語言，從而為本地用戶提供了良好的語言界面。c） 適合建立詳細的IP注冊地址信息庫。詳細信息可由底端的IP地址分配機構建立，操作、使用和管理簡單有效。d）能進行統一的信息查詢，即在任意Whois可以查詢任意注冊的IP地址信息。e）該機制具有良好的擴展性。層次化結構使得擴展簡單，對原有體系沒有負面影響，并且分擔了數據量。f） 該機制也可以在國家內部較容易地按照實際情況部署和實施，只要不向外部注冊機構交換address-info對象即可對外屏蔽。

參考文獻：

［1］ALAETTINOGLU C， VILLAMIZAR C， GERICH E，et al. IETF RFC 2622，Routing policy specification language (RPSL)[S].1999.

[2]DAIGLE L. IETF RFC 3912，Whois protocol specification[S].2004.

[3]KONISHI K，HUANG K，QIAN H，et al. IETF RFC 3743， Joint engineering team (JET) guidelines for internationalized domain names (IDN) registration and administration for Chinese，Japanese， and Korean[S]. 2004.

[4]COSTELLO. IETF RFC 3492， Punycode:a bootstring encoding of unicode for internationalized domain names in applications (IDNA)[S]. 2003.

注：“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。”