以下為 TWNIC ISP IP 位址申請書之填寫說明。
請確實於各欄位中填寫相關資料，否則將造成處理程序以及位址發放時間的延誤。
ISP TECHNICAL TEMPLATE
部分必須提供詳實之資訊，且不得以安全為理由，略過此部分之資料。
若有安全上之疑義，請聯絡 hostmaster@twnic.net.tw
NETWORK and PERSON templates 部分提供之資訊，將被置放在 whois.twnic.net，
並開放於 Internet 上作為 WHOIS 查詢之用。
這些資訊將被用於 Internet 診斷、偵錯、解析等工作之用，藉以維持
Internet 通訊之正常運作。
未經 TWNIC Pty Ltd. 之許可，任何超出前述內容之用途，均嚴格禁止。
本申請表將交由電腦判讀，因此請以「純文字」(ASCII) 格式編寫，
切勿使用 MIME 編碼格式，除非該 MIME
格式之內容不需經由任何形式之解碼程序即可判讀。
特別注意，請勿以 BASE64 編碼格式對申請書加以編碼。
此外，請勿修改申請書之式樣，例如，請勿修正任何欄位名稱之文字，或者於
template 區段中插入任何額外
的空行等等。因判讀申請文件之電腦設備，無法處理此類錯誤格式，若這些違反這些限制，將造成電腦判讀時
的語法錯誤，並將您的申請文件退回。文末提供有一完整正確填表範例以供參照。
同樣的，若您對於本申請文件有任何疑義，請隨時與hostmaster@twnic.net.tw聯絡。
2. ISP Internet Address Request Network Template 細節說明
NETNAME:
請提供該網路之簡短且具意義的名稱。
NETNAME 是用來作為 Internet 管理之用，諸如 IR ( Internet Registration )
組織之例行之查核工作等。
網路名稱應為 25 字元以內不含空白僅由英文或數字所組成之單字。
NETNAME 之內容應與申請位址之該組織名稱相關。請勿使用網域名稱
(Domain Name) 作為 NETNAME，
例如：FOO.COM，此處之 NETNAME 名稱與網域名稱系統無關。
每一 NETWORK template 都應有一個正確的 NETNAME 。
範例：
netname: TANet
DESCR:
此處請填寫申請組織之簡短說明，且應包含足夠之區域資訊，
使之與其他存在於 TWNIC 資料庫之組織名稱有所區別，亦即，僅填寫"descr:
Computer Center"是不夠的。
請勿加入任何廣告文字於您的組織敘述中，例如："The best internet
provider in Foo"等。
本敘述限制於5行內。
所有的 NETWORK templates 中均必須填寫此欄位。
範例：
descr: Terabit Labs Inc.
descr: Network Bugs Feeding Facility
descr: Northtown
COUNTRY:
請填入申請組織所在地之符合 ISO 3166
所規範長度為兩碼之國家識別碼。
請勿填入國家名稱或是三碼之 ISO 3166 國碼。
如果您不知道貴國之ISO 3166 國碼，詳見 APNIC 之 ISO 3166
國家識別碼列表：
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
我們知道依照國家列表來區隔一個跨國的網路容易造成混淆，因此您應該依照該網路管理中心之所在地來決定
國碼。所有的 NETWORK templates 中均必須填寫此欄位，且僅允許一個
COUNTRY 欄位值。
範例：( 台灣為 TW )
country: TW
ADMIN-C:
此處請提供網路管理者之 TWNIC NIC handle (暫不接受由其他註冊組織所提供之
NIC handles)。
若您尚未取得 TWNIC NIC handle，請參照以下「取得 TWNIC NIC handle」一節之說明。
此處之網路管理者，必須實際任職於該網路組織。
所有的 NETWORK templates 中均必須填寫此欄位，且至少要有一個 ADMIN-C
欄位值。
範例：
admin-c: JD1-TW
TECH-C:
此處請提供技術聯絡人之 TWNIC NIC handle (暫不接受由其他註冊組織所提供之
NIC handles)。
若您尚未取得 TWNIC NIC handle，請參照以下「取得 TWNIC NIC handle」一節之說明。
此處之技術聯絡人，不必任職於該網路組織，但該技術聯絡人之責任應為維護該網路之日常運作。
所有的 NETWORK templates 中均必須填寫此欄位，且至少要有一個 TECH-C
欄位值。
範例：
tech-c: MS4-TW
REMARKS:
此處請填寫無法列於其他欄位之相關資訊註解。這裡允許填入多行文字，但應限於少量之其他相關資訊。
範例：
remarks: will be returned to NIC 19950101
CHANGED:
請填入 template 編修者的電子郵件位址，緊接著為編修日期，
日期之格式為YYYYMMDD (其中YYYY為四位數之西元年份，MM為月份，DD為日期，不足之位數請補0)。
您應該為新申請之網路區塊的每個 NETWORK template 提供一個正確的
CHANGED 欄位值。
範例：
changed: johndoe@terabit.na 19950225
SOURCE:
資料來源。若為 TWNIC 之各式表單，其來源必為 TWNIC。
此為資料庫中必要之欄位，且通常已經填寫於表單之中。
範例：
source: TWNIC
3. ISP Internet Address Request Person Template 細節說明
PERSON:
請填寫申請人之全名。請勿使用'`Dr'、'`Prof.'或'`Sir'等抬頭，並勿使用縮寫。
此處的姓名應為信件收件人之全名(例如，'姓氏＋名字'或者'名字＋姓氏'，依貴國信件格式之習慣用法而定)。
每個 PERSON template 僅能有一個 PERSON 欄位。
範例：
person: John E Doe
ADDRESS:
請填寫可供國際郵件投遞之完整住址(雖然收件國別可由以下之
COUNTRY 欄位得知，但仍建議您提供完整之住
址資料)。如下所示，請分行填寫地址之各部份。
範例：
address: Terabit Labs Inc.
address: Industrial Estate North
address: North Perpendicular Road 12
address: NL-1234 Northtown
COUNTRY:
請填入申請組織所在地之符合 ISO 3166
所規範長度為兩碼之國家識別碼。
請勿填入國家名稱或是三碼之 ISO 3166 國碼。
如果您不知道貴國之ISO 3166 國碼，詳見 APNIC 之 ISO 3166
國家識別碼列表：
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
我們知道依照國家列表來區隔一個跨國的網路容易造成混淆，因此您應該依照該網路管理中心之所在地來決定國碼。
所有的 NETWORK templates 中均必須填寫此欄位，且僅允許一個 COUNTRY
欄位值。
範例：( 台灣為 TW )
country: TW
PHONE:
請填入申請人工作地點之聯絡電話，包含您所在地之國碼以及區碼。(不含國際冠碼)。
請勿填入區域號碼之冠碼'0'，除非在國際撥接時，該'0'碼為必要。
聯絡電話格式如下：
+<國碼>-<區碼>-<交換局碼>-<用戶號碼>
若該電話必須續撥分機，請附加 "ext <分機號碼>"。請勿以'x'或其他縮寫來代表"Extension"(分機號碼)。
您可填寫一個以上的聯絡電話，但請分行，並依照可聯絡到申請人之最適當順序填寫。
範例：
phone: +886-2-1234-5678
phone: +886-2-1234-5678 ext 1111
FAX-NO:
請填寫國際傳真電話號碼(不含國際冠碼)。請勿填入區域號碼之冠碼'0'，除非在國際撥接時，該'0'碼為必要。
傳真電話格式如下：
+<國碼>-<區碼>-<交換局碼>-<用戶號碼>
您可填寫一個以上的聯絡電話，但請分行，並依照可聯絡到申請人之最適當順序填寫。
若無傳真電話，本欄請勿填寫。
範例：
fax-no: +886-2-1234-5678
E-MAIL:
請提供申請人之電子郵件位址。該電子郵件位址應符合 RFC-822
之規定，並包含完整領域名稱(FQDN)。
若您尚無電子郵件信箱，本欄請勿填寫。
您可填寫一個以上的電子郵件位址，但請分行，並依照可聯絡到申請人之最適當順序填寫。
範例：
e-mail: johndoe@terabit.com.tw
NIC-HDL:
NIC Handle 是 Internet 資料庫中每位登記人獨一無二的識別碼。
NIC handles 必須經過註冊 --
若您尚未取得，請勿自行編造，您可以依照稍後"取得 TWNIC NIC
Handle"一節的說明填寫。
若您已註冊卻忘記了 TWNIC NIC handle，本欄位請空白，並於本申請表的
ADDITIONAL COMMENTS 一節填寫
註記。若您擁有其他註冊單位所核發之 NIC handle，例如：InterNIC，請提供完整的
person template，
且依稍後所述之「自動產生」的方式填寫本欄位 --
各區域註冊組織已著手研究此類資訊之共通性，但目前仍無解決方案。
範例：
nic-hdl: JD401-TW
REMARKS:
您可將該申請人相關之無法填寫於其他欄位的註解資訊填寫於此處。
這裡允許填入多行文字，但應限於少量之相關資訊。
範例：
remarks: pager can be accessed by <e-mail>-pager
CHANGED:
請填入 template 編修者的電子郵件位址，緊接著為編修日期，
日期之格式為YYYYMMDD (其中YYYY為四位數之西元年份，MM為月份，DD為日期，不足之位數請補0)。
您應該為新申請之網路區塊的每個 NETWORK template 提供一個正確的
CHANGED 欄位值。
範例：
changed: johndoe@terabit.com.tw 19950225
SOURCE:
資料來源。
若為 APNIC 之各式表單，其來源必為 APNIC。
此為資料庫中必要之欄位，且通常已經填寫於表單之中。
範例：
source: TWNIC
4. ISP Internet Address Request Technical 細節說明
CONNECTIVITY:
請說明您的網路和 Internet 的連接方式。
此欄位值應為 PEERING-POINT，SERVICE-PROVIDER，或 OTHER。
PEERING-POINT 代表該網路透過連接有三個以上之 ISP
之網路交換中心，來連接 Internet。
PEERING-POINT 的例子有：台灣的 TWIX, 美國的 MAE-West，香港的 HKIX，等等。
SERVICE-PROVIDER 代表透過 ISP 連接 Internet。
SERVICE-PROVIDER 的例子有：MCI，UUNet 等。
OTHER 代表以除了 peering point 及 service provider 之外的方式來連接 Internet。
若以 OTHER 方式連接者，請於 ADDITIONAL COMMENTS 一節說明連接方式。
若您的網路連接方式不只一種，請分行列出所有的連接方式。
範例：
connectivity: PEERING-POINT
CONN-PROVIDER:
請提供您 ISP 之名稱。
連接方式若為 PEERING-POINT，您應該以多個 CONN-PROVIDER
欄位，提供您所連接之所有的 PEERING-POINT
單位。
若為 SERVICE-PROVIDER，您應以多個 CONN-PROVIDER 欄位列示所有之 ISP。
若為 OTHER，請提供最符合您的網路之連接機制的資訊。
範例：
conn-provider: TWIX
ALL-0S-SUBNETS:
若您的網路設備支援子網路位元全為"0"之網路位址，請填入
YES，否則，請填入 NO。
若您填入 NO，請於申請書最後 "Additional Comments"
一節加以解釋說明。
注意，所有主要路由器廠商所生產之路由器均支援子網路位元全為0
之網路位址，或至少可藉更新出廠設定值來達成。
範例：
all-0s-subnets: YES
ALL-1S-SUBNETS:
若您的網路設備支援子網路位元全為"1"之網路位址，請填入
YES，否則，請填入 NO。
若您填入 NO，請於申請書最後 "Additional Comments"
一節加以解釋說明。
注意，所有主要路由器廠商所生產之路由器均支援子網路位元全為1
之網路位址，或至少可藉更新出廠設定值來達成。
範例：
all-1s-subnets: YES
SUPERNETS:
若您的網路設備支援不分級之網路位址，可構成 supernetting，請填入
YES，
這表示您可將鄰近連續之網路區塊，加以聚集，成為 supernet，構成單一路由記錄
( routing prefix )。
否則，請填入 NO。若您填入 NO，請於申請書最後 "Additional
Comments" 一節加以解釋說明。
範例：
supernets: YES
SUBNETS:
若您的網路設備可將網路切分為子網路，亦即您可將數條路由簡化為單一路由，請填入
YES。
否則，請填入 NO。若您填入 NO，請於申請書最後 "Additional
Comments" 一節加以解釋說明。
請注意：TWNIC 假設所有 ISP 會使用子網路 prefix
來為其客戶之位址設定路由。
若 ISP
不能達到此項要求，未來在申請網路位址時將必須提出合理解釋，否則不予核發。
範例：
subnets: YES
PORTABLE:
若您允許客戶即使更換 ISP 後仍可保有相同之 IP
位址，亦即您所分配予客戶之位址在 ISP 之間具可攜性，
請在此欄中填入 YES。若否，請填入 NO。
由 Internet 路由管理的經驗得知，可攜的 IP
位址，在目前的網路環境中仍有許多限制，
甚至可能造成路由運作不正常，我們強烈地建議您不要使用此方式。
假設您未向客戶聲明於連線契約終止時，客戶必須歸還 IP
位址，則您已經配發了可攜的 IP 位址。
請詳見輔助說明。
範例：
portable: NO
CUST-NETWORK:
請於 CUST-NETWORK 欄位提供您過去發放 IP 位址給予客戶之摘要紀錄。
若您過去未曾代理發放 IP 位址，本欄請留空白。
若您曾發放 IP
位址給予客戶，您必須提供經重新配發之網路位址的相關資訊：
cust-network: netname address mask hinit/h6mo/h1yr sinit/s6mo/s1yr date
其中：
netname - 您所配發之網路區段在 TWNIC 資料庫中的名稱。
(請注意：此名稱為您所指定，但應與該位址所配發之組織有關)
address - 該配發網路區段之起始 IP 位址。
mask - 該配發網路區段之子網路遮罩。
例如：255.255.248.0
hinit - 該配發網路區段之初始網路設備數量。
h6mo - 該配發網路區段六個月後之網路設備數量。
h1yr - 該配發網路區段一年後之網路設備數量。
sinit - 該配發網路區段之初始子網路數目。
s6mo - 該配發網路區段六個月後之子網路數目。
s1yr - 該配發網路區段一年後之子網路數目。
date - 該網路區段配發日期。請以 YYYYMMDD (西元年月日)之格式填寫。
本欄位之請務必填寫正確，TWNIC將依照您過去代理發放位址的紀錄來決定未來對您網路位址的配發。
CUST-NETWORK 欄位的資訊，將提供 TWNIC
建立您代理發放網路位址的相關紀錄。
請務必於重新配發位址時，提供與 TWNIC 資料庫相符之正確 NETNAME
資料。
否則，將造成 TWNIC 將該網路區段位址視為「未經重新發放」。
請視需要，填寫數個 CUST-NETWORK 欄位，來表示您已經將 TWNIC
所配發之網路位址，代為發放給予您的客戶。
若您以「非-CIDR」之形式(亦即，該發放之子網路位址，無法以單一子網路遮罩予以表示)分配網路位址給予客戶，
請填寫多個 CUST-NETWORK 欄位，以 CIDR
之形式來表示該網路之位址，並視需要使用相同的網路名稱(NETNAME)。
*注意* CUST-NETWORK 以及 INFRASTRUCTURE (如下)
所示之位址總和，將被視為您網路位址使用量之總數。
範例：
cust-network: FOO-TW 202.12.28.0 255.255.255.128 10/15/80 1/1/2 19960501
cust-network: BAR-TW 202.12.28.128 255.255.255.128 60/70/100 2/3/4 19960515
INFRASTRUCTURE:
請於 INFRASTRUCTURE 欄位提供您本身基礎網路所使用的 IP 位址總數，
亦即您未發放予客戶且未列於上述 CUST-NETWORK 欄位之 IP 位址數量。
INFRASTRUCTURE 欄位之格式如下：
infrastructure: address mask connect max hinit/h6mo/h1yr remark
其中：
address - 該網路區段之起始 IP 位址。
例如：202.12.28.192
mask - 網路遮罩。
例如：255.255.255.240
connect - 若此網路未連接 Internet，請填入'NO'。
若此網路有時連接 Internet(例如：以撥號連線連接 Internet)，請填入'PART'。
此外，請填入'YES'(例如：可隨時 ping 到，全時連接 Internet 的網路)。
max -
最大可供使用之主機位址數目。請您確定已扣除兩個無法使用的位址，
一為主機位元全為'0'之網路位址，另一為主機位元全為'1'之廣播位址。
hinit - 最初規劃或現有之網路設備數目。
h6mo - 六個月後規劃之網路設備數目。
h1yr - 一年後規劃之網路設備數目。
remark - 註解資訊。
您可以視需要使用多個 INFRASTRUCTURE 欄位來表示內部基礎網路。
但請勿使用 INFRASTRUCTURE 欄位來表示您尚未使用之網路位址。
若您的內部基礎網路以「非-CIDR」之方式切分網路位址
(亦即，該發放之子網路位址，無法以單一子網路遮罩予以表示)，
請填寫多個 INFRASTRUCTURE 欄位，以 CIDR
之形式來表示該網路之所有位址
(包括以子網路遮罩 255.255.255.255，來表示單一主機位址之方式)。
在您計算位址數目時，請確定所有之網路設備，包含個人電腦、伺服器、網路印表機、路由器等，
均配置獨有之 IP 位址。
請以確實之網路位址以及相關之網路遮罩來表示您的網路位址的分配，
勿潦草、簡單地交代每個網路區段之資訊。
盡可能地將每個網路區段位址展開，並敘述每個 IP 位址之資訊。
*注意* CUST-NETWORK 以及 INFRASTRUCTURE (如下)
所示之位址總和，將被視為您網路位址使用量之總數。
範例：
infrastructure: 202.12.28.0 255.255.255.192 YES 62 12/24/48 servers
infrastructure: 202.12.28.64 255.255.255.192 PART 62 30/40/50 dialup ports
infrastructure: 202.12.28.128 255.255.255.128 NO 126 60/100/110 admin
NETWORK-PLAN:
您應於此欄位提供未來一年內您對 TWNIC 所配發之 IP 位址的用途。
NETWORK-PLAN 欄位的格式如下：
network-plan: address mask connect max hinit/h6mo/h1yr remark
其中：
address - 子網路之起始位址。
例如：0.0.1.0 mask 255.255.255.0
表示此網路為第二個 /24 (Class C)的子網路。
(第一個 /24 為 0.0.0.0 mask 255.255.255.0)
mask - 子網路遮罩。
例如：255.255.255.240
connect - 若此網路未連接 Internet，請填入'NO'。
若此網路有時連接 Internet(例如：以撥號連線連接 Internet)，請填入'PART'。
此外，請填入'YES'(例如：可隨時 ping 到，全時連接 Internet 的網路)。
max -
最大可供使用之主機位址數目。請您確定已扣除兩個無法使用的位址，
一為主機位元全為'0'之網路位址，另一為主機位元全為'1'之廣播位址。
hinit - 最初規劃或現有之網路設備數目。
h6mo - 六個月後規劃之網路設備數目。
h1yr - 一年後規劃之網路設備數目。
remark - 註解資訊。
您應該視需要使用多個 NETWORK-PLAN 欄位來表示未來的網路規劃。
NETWORK-PLAN
欄位是用來將您本身基礎網路以及客戶網路之額外位址空間需求文件化。
(其效力超越上述之 INFRASTRUCTURE 欄位)
在您計算位址數目時，請確定所有之網路設備，包含個人電腦、伺服器、網路印表機、路由器等，
均配置獨有之 IP 位址。
請以確實之網路位址以及相關之網路遮罩來表示您的網路位址的分配，
勿潦草、簡單地交代每個網路區段之資訊。
關於客戶網路部分，可能會有部分(甚至全部)配發給您的位址，
會包含於指定給您的客戶之網路位址區塊中。
此類情形，則不需詳細指明哪些位址是將要指定給客戶使用。
*注意* NETWORK-PLAN 欄位是用來決定配發給您網路位址的數量。
精確地說明位址的用途將可避免誤解的發生。
範例：
network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 support group
network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 customer svc
Explanation why you cannot obtain addresses from your service provider:
若您非屬 TWNIC 之代理發放 IP 位址之單位,
請於此詳述您無法由代理發放 IP 位址單位取得 IP 位址的
原因。若您無法說明其原因，您的申請將不被受理而被退回。
TWNIC 強烈地建議需要 IP 位址的組織團體，盡量由其 ISP 處取得位址。
請詳見輔助說明。
ADDITIONAL COMMENTS:
請務必於此輔助說明您對 IP 位址的需求,
若您無法清楚說明，您的申請將不被受理而被退回。
尤其，若您提供圖表說明您的網路拓樸，或是詳細說明您網路位址的用途，以及網路的劃分，
將可幫助 TWNIC
瞭解您對網路位址的需求，而加速處理您的申請程序。
5. ISP IP Address Request Form 輔助說明
本文件是用來提供您的此次申請之相關必要資訊，以供 TWNIC
評估之用。
尤其是 ISP TECHNICAL TEMPLATE，為 TWNIC
評估您目前以及未來規劃之位址空間使用情形。
ISP TECHNICAL TEMPLATE 需要以下的資訊：
- 您如何連接 Internet
(CONNNECTIVITY 和 CONN-PROVIDER)
- 您的網路之路由特性
(ALL-0S-SUBNETS, ALL-1S-SUBNETS, SUPERNETS, SUBNETS, PORTABLE)
- 您過去網路位址之使用情形
(CUST-NETWORK, INFRASTRUCTURE)
- 您未來對所配發之網路位址的使用計畫
(NETWORK-PLAN)
要提醒您的是，本申請文件所提供之資訊僅為整個評估作業的開始。
TWNIC
將可能要求您提供過去以及未來您的網路位址分配進一步的詳細資料。
於 "ADDITIONAL COMMENTS" 欄位提供額外的資訊，將可幫助 TWNIC
瞭解您的需求，
進而加速申請程序的處理及位址的配發。
5.1 以 ISP 為基礎的定址
目前 Internet 不斷地成長，IP 位址必須分級配發。
如此才能簡化全球定址所需之資訊量。
(電話系統即為分級定址的一個例子。譬如位於義大利的電話總機並不需要知道如何接通某個位於日本的用戶
電話號碼，它唯一所必須知道的事情是，如何當撥接的電話號碼不是直接連接於本地埠時，要如何接上交換機。
而交換機則知道如何在國際電話線路骨幹上，接通位於其他國家的交換機等等。)
要做到分級定址，位址的分配必須與網路架構密切配合。
在 Internet 中，ISP 定義了網路的架構而組成 Internet，
因此，位址必需經由 ISP 來發放。
在這種方式下，全球的路由系統只需要知道如何到達某個 ISP 即可。
今日，全球的路由系統已連接超過 50,000 個網路。
在這個情形之下，Internet 面臨(而且曾經發生)中斷的邊緣。
這些徵兆包括路由器的記憶體用盡(造成當機、重新啟動、恢復運作、記憶體再次用盡、當機……)
或是為了要計算出如何到達 50,000 多個節點的其中之一或全部(每當有一個網路連接或中斷，
路由都必須重新計算，尤其在記憶體用盡的情形下，狀況更加惡化)，耗盡了
CPU 資源。 最後的結果，造成了 Internet
的某部分連線中斷，無法到達。
因此，若有某個節點以 ISP 網路位址區塊範圍以外的 IP 的連上Internet，
代表了其位址必須加入全球的路由表中。
為了要保護其客戶的權益並維護其網路的運作(例如：有些單位對於
Internet 本身並不感興趣， 但利用虛擬私人網路的方式，透過 Internet
來連接其各地的分支單位)， 某些 ISP 開始採取忽略 ISP
網路區塊以外之位址路由宣告(尤其是美國的一些大型 ISP)。
簡言之，若某路由資訊所能定址的主機數量越少，則越容易被忽略。
網路的路由資訊被忽略的狀況，隨時隨處都有可能發生，而您將無法到達忽略您路由資訊的網路(反之亦然)。
為了對抗路由表過大的問題，Internet
註冊組織強烈建議需要網路位址空間的單位， 應由其 ISP
處取得網路位址。一般而言，ISP 之位址區塊均足夠大，
而使得其路由不致被其他 ISP 所忽略。
若某個客戶單位更換 ISP，該單位應該更換其所有的 IP 位址到其新的
ISP 所在之位址範圍之下。
現在，因為各種動態定址技術的發展，諸如 DHCP、BOOTP等，更換 IP
位址已不再被認為是繁瑣的程序。
因這些技術所帶來的便利，重新定址的工作已簡化至只需更動 DHCP
伺服器、DNS， 以及路由器之 IP 位址即可達成。
IETF 的 PIER (Procedures for Internet/Enterprise Renumbering) Working
Group
資料庫，提供了許多重新定址的技術。請參照以下的位址進行搜尋：
http://www.rfc-editor.org/rfc.html
您可以用 "Renumbering"
關鍵字加以搜尋，將會得到許多由該組織所編寫之 RFC 技術文件。
正因維持 Internet 的正常運作是 Internet 使用者所最關心的議題，
Internet 的註冊組織強烈地建議，無論是 ISP 或非 ISP，盡量由其 ISP
處取得位址， 並在更換 ISP 之時，歸還該組位址。
因此，若各個註冊組織毫無限制的發放網路位址，勢將絕對無法保障
Internet 正常運作。
再者，TWNIC 強烈建議 ISP 應將客戶於合約終止時，有歸還 IP
位址之義務的條款， 明文訂立於契約之中。如果該項條款未列於 ISP
之客戶合約中， TWNIC
即認為該客戶有對分配之位址有處置的權利，比如：在該客戶更換
ISP 時，
可將該組位址保留並繼續使用。諸如此類的作法，將對全球路由表產生極大的衝擊，
應該設法避免。
因為有了這些措施，Internet
得以維持目前的成長速率，並在使用者的期望下繼續運作。
5.2 TWNIC 分配網路位址之程序
當某個 ISP 第一次與 TWNIC 接洽，我們將分配一個位址區塊，
以供該 ISP 之基礎網路以及其初期的客戶使用。
一般來說，即使這個初次申請的 ISP 的位址需求並未達 /20(16個Class C)，
但TWNIC仍會分配一個 /20 的位址區塊給初次申請之 ISP。 若 /20
的位址仍不敷該 ISP 本身之基礎網路使用，TWNIC 會要求該 ISP
提供有關於其網路架構更詳盡的
資料。亦有極少數例外的情形，但均必須提供足夠之說明。 若該 ISP
將初次配發之 IP 位址用盡，可依需要申請額外的位址空間，
唯該位址空間與原有之位址，可能不為連續之區塊。
TWNIC 於 Internet 上提供了 TWNIC
註冊資料庫，目的在於輔助網路問題之偵錯和解析。
為了使這個資料庫發揮功效，必需經常更新其資料。 因此，ISP
除了發放 IP 位址給予其客戶外，亦必須更新 TWNIC
資料庫中的相關資料。 在配發位址給予客戶後，請盡快更新 TWNIC
資料庫中之相關資料。 除了提供 ISP 客戶之最新資料外，TWNIC
也藉這些資料以及其更新之頻率， 來衡量 ISP 成長的速度。因此，若
ISP 對於資料庫中的相關資料不予更新， 則 TWNIC 將無從衡量此 ISP
之成長速率。
若 ISP 已耗用了 TWNIC 最初分配之 80% 的位址時，應向 TWNIC 提出 IP
位址申請。 若有一客戶必須使用超過 ISP 所能提供之 IP
位址數量時，ISP 亦應向 TWNIC 提出位址申請。 (ISP
不能引導客戶直接向 TWNIC 提出申請，因為 TWNIC 將會指示該客戶向 ISP
提出位址需求) ISP 應確定新申請書之 CUST-NETWORK
欄位，確實反映出該客戶之需求。 TWNIC 會再行審核 CUST-NETWORK
欄位中的資料，是否與 TWNIC 資料庫內容相符，以核發位址。
核發的位址數量取決於過去位址之分配及使用率，以及是否適時且正確地更新
TWNIC 資料庫。
若申請書中所提供的資料，以及 TWNIC
資料庫中的相關資訊，均符合 TWNIC 之審核標準， TWNIC 將核發位址
TWNIC 最終的目的，不外乎提供 ISP 足夠之 IP
位址，使其在未來的三到六個月之內，
足以滿足客戶之需求。 在這種情形下，實際配發的 IP 數量，將視 ISP
的位址消耗速度動態調整。
這種核發的機制，被公認為容易造成在最初幾次的申請中，實際核發之位址數將少於需求數。
也就是說，ISP 初期與 TWNIC 接觸的頻率將會相當頻繁，
這種作法，具有避免造成日益減少之 IP 位址的濫用， 同時，亦可使
ISP 本身(終會)達到 IP 位址自給自足的合理水準。
6. 取得 TWNIC NIC Handle
若您正填寫 person template 或是在其他 TWNIC
註冊資料庫中的相關項目引用某位人員， 您應該使用 TWNIC NIC handle
('nic-hdl:')。NIC handles 可提供每位人員一個獨一無二的識別碼，
以避免不同人員卻同名同姓的情形下所造成之混淆。欲取得 TWNIC NIC
handle ，您可以下列方式填寫
NIC-HDL 欄位：
nic-hdl: AUTO-1
(此處為數字"1", 而非英文字母"l")
如此將使資料庫軟體依照您的姓和名的第一個字母，產生一個 TWNIC
handle。
例如：若您送出下列個人資料(僅供參考)：
person: David Conrad
address: Taiwan Network Information Center
address: No.33 Park Road
address: P. O. Box 2131
address: Taiwan, R.O.C.
country: TW
[...]
nic-hdl: AUTO-1
[...]
資料庫軟體將產生一個如下列形式之 NIC handle
DC###-TW
其中 ### 為下一個可用之數字，以確保這個以 DC 啟始之 TWNIC NIC
handle 為唯一。
您可以於文件中相關位置使用相同的 handle (AUTO-1)。
資料庫軟體將會以自動產生之新的 NIC handles 來取代這些欄位。
您也可以使用其他數字 (例如： AUTO-2)，因此您將可以在同一文件中，
為數個聯絡人，自動產生新的 NIC handle。例如：
[...]
admin-c: AUTO-1
tech-c: AUTO-2
[...]
person: David Conrad
[...]
nic-hdl: AUTO-1
[...]
person: Yoshiko Chong
[...]
nic-hdl: AUTO-2
[...]
將會產生兩個新的 handle，一個是 DC###-AP，將填入 ADMIN-C 和 David
Conrad 的 NIC-HDL 欄位。
另一個則是 YC###-AP，將填入 TECH-C 和 Yoshiko Chong 的 NIC-HDL 欄位。
7. 申請表範例
#[NETWORK TEMPLATE V:4.0]#
netname: EXAMPLE-TW
descr: An example of a completed ISP application form
descr: Please don't send this verbatim to APNIC
country: TW
admin-c: DC1-TW
tech-c: YF1-TW
changed: davidc@twnic.net 19960501
source: TWNIC
#[PERSON TEMPLATE V:4.0]#
person: David R Conrad
address: Taiwan Network Information Center
address: No.33 Park Road
address: P. O. Box 2131
address: Taiwan, R.O.C.
country: TW
phone: +886-2-2341-3300
fax-no: +886-2-2396-8832
e-mail: davidc@twnic.net.tw
nic-hdl: DC1-TW
changed: davidc@twnic.net.tw 19960401
source: TWNIC
#[PERSON TEMPLATE V:4.0]#
person: Paul Feng
address: Taiwan Network Information Center
address: No.33 Park Road
address: P. O. Box 2131
address: Taiwan, R.O.C.
country: TW
phone: +886-2-2341-3300
fax-no: +886-2-2396-8832
e-mail: davidc@twnic.net.tw
nic-hdl: PF1-TW
changed: davidc@twnic.net.tw 19960401
source: TWNIC
#[ISP TECHNICAL TEMPLATE V:3.0]#
connectivity: PEERING-POINT
conn-provider: TWIX
all-0s-subnets: YES
all-1s-subnets: YES
supernets: YES
subnets: YES
portable: NO
cust-network: FOO-NET-TW 202.12.28.0 255.255.255.128 10/45/110 1/1/2 19960301
cust-network: BAR-NET-TW 202.12.28.128 255.255.255.128 60/70/100 2/3/4 19960315
infrastructure: 202.12.29.0 255.255.255.192 YES 62 12/24/48 servers
infrastructure: 202.12.29.64 255.255.255.192 PART 62 30/40/50 dialup ports
infrastructure: 202.12.29.128 255.255.255.128 NO 126 60/100/110 admin
network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 support group
network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 customer svc
network-plan: 0.0.0.32 255.255.255.240 YES 14 10/10/10 int. dial up
network-plan: 0.0.0.48 255.255.255.240 NO 14 2/10/12 admin
network-plan: 0.0.0.64 255.255.255.224 YES 30 10/20/30 servers
network-plan: 0.0.0.96 255.255.255.252 YES 2 2/2/2 branch x -> HQ
network-plan: 0.0.0.100 255.255.255.252 YES 2 2/2/2 branch y -> HQ
network-plan: 0.0.0.104 255.255.255.252 YES 2 2/2/2 branch z -> HQ
network-plan: 0.0.0.108 255.255.255.252 YES 2 2/2/2 R&D -> HQ
network-plan: 0.0.0.112 255.255.255.252 YES 2 2/2/2 emp. a -> HQ
network-plan: 0.0.0.116 255.255.255.252 YES 2 2/2/2 emp. b -> HQ
network-plan: 0.0.0.120 255.255.255.252 YES 2 2/2/2 emp. c -> HQ
network-plan: 0.0.0.124 255.255.255.252 YES 2 2/2/2 emp. d -> HQ
network-plan: 0.0.0.128 255.255.255.128 YES 126 1/64/126 Blech City POP
network-plan: 0.0.1.0 255.255.255.0 YES 254 0/128/254 Blahville POP
#[TEMPLATES END]#
Explanation why you cannot obtain addresses from your service provider:
We will be multi-homed as we are connecting to a connection point,
peering with a variety of service providers and defaulting to none.
Additional Comments:
The following is the EXAMPLE network topology.
---
+-----+ +----------+ / \
| DNS |--------+-------| Router 1 |-----+ F |---> Terminal Server
+-----+ | +----------+ | D |
| | | D |---> Router
+----------+ | | | I |
| 10 port | | V | |---> Router
| Internal |---+ (ISDN Backup) | D |
| Terminal | | | M |---> Router
| Server | | +----------+ | Z |
+----------+ |-------| Router 2 |-----+ |
| +----------+ \ /
+------+ | | ---
| FS 1 |-------+ |
+------+ | V
+------+ | (OC48 to connection point)
| FS 2 |-------+
+------+ |
|
+---------+--------+--------+
| | | |
+------+ +------+ +------+ +------+
| WS 1 | | WS 2 | | WS 3 | | WS 4 |
+------+ +------+ +------+ +------+
We will be using BFR routers running BGP-4 to peer with service
providers at the MAE-West connection point. We will also be using
OSPF to manage our internal infrastructure and static routing to our
customers where possible.
8. 相關文件
RFC 1466 E. Gerich, "Guidelines for Management of IP Address Space",
5/26/93, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1466.txt
RFC 1517 R. Hinden, "Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR), 9/24/93, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1517.txt
RFC 1518 Y. Rehkter, T. Li, "An Architecture for IP Address Allocation
with CIDR", 9/24/93, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1518.txt
RFC 1519 V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy",
9/24/93, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1519.txt
RFC 1744 G. Huston, "Observations on the Management of the Internet
Address Space", 12/23/94, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1744.txt
RFC 1814 E. Gerich, "Unique Addresses are Good", 6/22/95, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1814.txt
RFC 1817 Y. Rehkter, "CIDR and classfull Routing", 8/4/95, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1817.txt
RFC 1879 B. Manning, "Class A Subnet Experiment Results and
Recommendations", 1/15/96, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1879.txt
RFC 1878 T. Pummill, B. Manning, "Variable Length Subnet Table For IPv4",
12/26/95, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1878.txt
RFC 1900 B. Carpenter, Y. Rehkter, "Renumbering Needs Work", 2/28/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc1900.txt
RFC 1916 H. Berkowitz, P. Ferguson, W. Leland, P. Nesser, "Enterprise
Renumbering: Experience and Information Solicitation", 2/28/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc1916.txt
RFC 1917 P. Nesser, "An Appeal to the Internet Community to Return Unused IP
Networks (Prefixes) to the IANA", 2/29/96, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1917.txt
RFC 1918 Y. Rehkter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
"Address Allocation for Private Internets", 2/29/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc1918.txt
RFC 2008 Y. Rehkter, T. Li, "Implications of Various Address Allocation
Policies for Internet Routing", 10/14/96, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc2008.txt
RFC 2036 G. Huston, "Observations on the use of Components of the
Class A Address Space within the Internet, 10/30/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc2036.txt
RFC 2050 K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel,
"Internet Registry IP Allocation Guidelines", 11/6/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc2050.txt
end-user-address-request APNIC Staff, "End User Internet Address Request
Form",
7/25/98 URL: ftp://ftp.apnic.net/apnic/docs/end-user-address-request
confed-address-request APNIC Staff, "Confederation Internet Address Request
Form", 7/25/98 URL: ftp://ftp.apnic.net/apnic/docs/
confed-address-request
以上文件均可由該文件所提及之連結位址，於 APNIC
文件資料庫中取得。
APNIC 文件資料庫可以下列方式存取：
1. 經由匿名 anonymous FTP 連線至 ftp.apnic.net
以 FTP 軟體匿名連線至 ftp.apnic.net，並以您的電子郵件位址作為登入密碼。
欲取得 RFCs，請以 "change directory" 指令 (一般為 'cd')變更目錄至
'/ietf/rfc'。
欲取得 APNIC 文件，請 'cd' 變更目錄至 '/apnic/docs'。接下來，您可使用
"get" 指令
(一般為 'get')來下載文件。
2. 經由電子郵件將 FTP 指令傳送至 APNIC FTP Email 閘道器
您可將標準 Unix 'ftp' 指令書寫於電子郵件中，寄到'ftpmail@postoffice.apnic.net'。
透過 APNIC FTP Email 閘道器來執行 FTP 指令，並將檔案以 Email
形式傳回。
欲取得進一步的說明，請發送一封內容為'help'之電子郵件至'ftpmail@postoffice.apnic.net'，
結果將以 Email 回覆給您。
欲取得上述文件但尚未連接 Internet 之組織，可聯絡 APNIC
或該區域或國家之註冊組織，或是 ISP，以郵遞方式索取，但您可能必須負擔相關郵遞以及文件印製費用。
9. 聲明
本文件內容大多取材自 European Registry, RIPE-NCC <ncc@ripe.net>.sed，特此聲明。
|
Second Opinion Request Form(APNIC-073)