財團法人台灣網路資訊中心因公出國人員報告書
九十七年十二月八日
|
報告人 姓 名 |
高境輿 楊禎葆 |
服務單位及職稱 |
工程師 工程師 |
|
出國期間 |
九十七年十一月十六日至 九十七年十一月二十三日 |
出國地點 |
美國 明尼亞波里斯 |
|
出國事由 |
參加第七十三次 IETF明尼亞波里斯會議 報告書內容應包含： 一、出國目的 二、考察、訪問過程 三、考察、訪問心得 四、建議意見 五、其他相關事項或資料 （內容超出一頁時，可由下頁寫起） |
||
|
授
權 聲 明 欄 |
本出國報告書同意貴中心有權重製發行供相關研發目的之公開利用。 授權人：
（簽章） |
||
附一、請以「A4」大小紙張，橫式編排。出國人員有數人者，依會議類別或考察項目，彙整提出報告。
註二、請於授權聲明欄簽章，授權本中心重製發行公開利用。
一、出國目的
第七十三次IETF會議於九十七年十一月十六日至九十七年十一月二十三日在美國明尼亞波里斯舉行。此次會議為期六天，而中心參加之主要目的為參加 EAI WG (Working Group) 標準討論EAI (Email Address Internationalization )，及參加 DNS 相關之 WG 會議 (DNSOP、DNSEXT、IDNbis、)，及 IPv6 相關之工作群組。因此次議程中日韓台各 NIC 亦皆有與會，故同時利用本次 IETF 會期共同討論了 IDNAbis 中句號 (Full Stop) 之看法與想法。
二、考察、訪問過程
此次會議雖期程共五天，行程安排，我們僅參加三天的會議，重點參加必要之 WG，所以共參加了三個 WG分別為IDNAbis、EAI、DNSEXT、DNSOP、v6ops
(IPv6 Operation) working group、網際網路領域中的
三、考察、訪問心得
IDNAbis 台日韓會前會
參加人員:
TWNIC 楊禎葆 abelyang
JPRS Yoshiro、Fujiwara
NIDA jaeyounkim、Kim
此會議主要目前的 IDNA 標準中，關於英文使用的句點 DOT ‘.’ 及 CJK中之慣用輸入法之處理句號 (。) 之問題，在原來的 IDNA2003 中，將滿語中全形的句號，空心的及實心的及偏上偏下的都視為同 DOT ‘.’，但在新的 IDNAbis 中，因考慮到不同地區之輸入法或慣用習慣可能不同，故將此一標準改成了 optional，在這種情況下，將會影響各 NIC 目前的註冊及使用習慣。在此衝擊下，經過討論後，大家決議將在 IDNAbis WG 的會議中說明目前中日韓台對本案的看法及日後四國將發表一篇 draft，以呼應中日韓台在 IDNAbis 中對 Full Stop的具體標準作法。
DNSOP/DNSEXT WG (Domain Name Service Operation)
這是兩個 Working Group 的會議，但是討論的內容是相近的， DNSEXT主要負表 DNS 相關技術標準的發展，而 DNSOP 則是 DNS 的在這些標準基礎皂維運。這兩個 WG 參加的人都差不多，而會議的主題則在於 DNSSEC及以 DNSSEC 在 IPv4/IPv6 上轉換對應之問題。
會議首先討論的是 RFC2929 的更新版，RFC2929 主要介紹的是 DNS Protocol 在 IANA 的註冊政策，例如，每個欄位的值，Rcode、Opcode (這些都是DNS在處理查詢時的的一些控制代碼)值應為多少，代表什麼意義。依此進行一個清楚而完整的規範。2929bis的更新版本主要根據最近五六年來 DNS 的發展所產生的新東西都加進去，同時在一些章節的安排上進行了一些調整。
主席也對目前 WGLC 的狀況做了介紹，目前兩個 Last Call 的 Draft 在 DNS 來說都是很重要的元件，一個是 DNAME Record 的改版，一個則是 DNSSEC 中的 NSEC 改版為 NSEC3 記錄。
DNAME 因 ICANN 的需求而進行改版，而 NSEC 則因 Domain Walking ( 可得知所有的 domain) 而進行調整，這兩個 Draft 可預件日後將會是相當重要的 RFC。
本屆 IETF 會議中 DNS 這個領域大家所最為看重的問題即是 DNSSEC 64 的 Draft，它指出了目前 DNSSEC 在 IPv4/IPv6 轉換過程中的不足，因為不足，故存在許多問題或不同的意見。由於本篇目前僅止於初稿狀況。問題存在於 IPv6/IPv4 NAT 在轉換時的對應，其結構會形成 IPv6::IPv4 之對應，由 NAT64 來進行 mapping 對照，可是 DNS 記錄中並沒有這個格式的類別 (TYPE)，而且這個格式來進入 IPv4 網路路要去除 IPv6，或回來時要變成 IPv6，所以在 DNSSEC中要考慮到這些問題的話就有許多記錄要產生，且整個架構的模式目前尚未定案，會議上持不同意見的人各有不同的看法，因時間問題，故最後主席裁示把問題留到 mailing list 上討論，以便大家陳述不同的意見。
EAI WG (Email Address Internationalization Working Group)
這個 WG 是中心目前參加 IETF 會議中的重點項目，主要在討論 Email Local-Part 中使用 UTF8 編碼的一些方法，尤於影響層面蠻廣的，但在上次會議後，巳有三篇 Draft 通過了 IESG 的審核，成為了 RFC 5335 (UTF8HEADER):、RFC5336
(utf8smtp)、RFC5337 (DSN)，所以在本次會議中主要的議題即在 Downgrade 上，原本 Downgrade巳經進入了 Last Call 階段，不過在 Application Director 審核後提供了許多意見及看法，這些看法對此 Draft 是很重要的，許多有不得不改的地方，所以會後本篇又進入了一般的 Draft
Life Cycle 中，主要的問題在於
1. Downgraded 中的 Downgraded-Mail-From/Downgraded-Rcpt-To 因為 Email 的傳送過程中包含了兩個位址資訊的欄位，一個是 SMTP 協議過程中的 Mail-From/Rcpt-To，及郵件表頭中的寄件人( From: )，收件人( To: ) ，因為考慮到現實中可能會有不一樣的情況，但原來 Draft 對此未有規範，經過會議討論後決議使用 From/To 來做此兩欄位的值，而這兩個欄位可能會有 Display Name ，故需去掉 Display Name。
2. RFC 2047 Encoding 問題，原來 Draft 僅提到在某些條件下需使用 RFC 2047 Encoding，但未考慮到欄位名稱的結構，故決議請作者適當修改並舉例，以完善這段的描述。
3. ORCPT 的 downgraded 欄位的過程描述不足，AD 請作者在多加補充。(PS: ORCPT 是 DSN 所使用的一個位址參數)
4.
Downgraded-* 問題，這個原來的含義指的是在 Downgraded 時，在原來的表頭名稱上改為 Downgraded-xyz,，例如 From: 則改為 Downgraded-From:，但是這樣 wildcard 的描述在 IANA 上是過不去的，IANA 規定需有明確的欄位內容，但是若依此，則違反了 IANA 的慣例，但因此篇不可能列舉所有的欄位內容，也不知道以後會出現什麼欄位名稱，故主席裁示交由 IESG 討論定奪或是請作者調整 Draft 內容。
會議上同時也討論了 POP/IM AP，不過如同過往經驗，大家的意見較少，最後討論了日後 Working Group 的方向，如何讓目前的 RFC 朝 Standard Track 的方向前進，擬定了幾個要點:
1. 加快目前 Draft 的改版，儘速成為 RFC。
2. 針對現有的 EAI RFC 進行開發及測試報告，說明標準的影響及如何實作等議題
3. 加強 IESG 上的工作
4. 可能需要一年的時間，需要大家參與合作
IDNAbis Working Group
本次 IDNAbis的第三次 WG 會議，此 WG在 mailing list上的討論相當活躍，而且怎體而言討論的東西都用 Unicode 有關，且主要的與會人員皆是資深的 IETFer，他們對問題的看法皆很深，其中的想法都讓人有不少的啟發。此次的 WG 會議共分兩個 session，在兩天分別舉行。兩天的會議是連貫的，主要因為主席 Vin Cerf 預計原來二小時的議程可能因為意見而有所不足。
會議的最大的重點在於英文與多國語言中關於句號的處理，這個處理在原來 idna 的 Draft 講的是一視同仁的，也就是不管你什麼語言，只要是 (. 。。ㆍｏ) 之類的，在 IDN 的域名使用或申請都視為是一樣的，例如: www.台網中心.tw = www。台網中心。Tw，可是後來 Draft 更新的版本將 Full Stop (句號)改成 Optional 選項，也就是不同的註冊政策或語言的使用習慣可能會有所不同，這個不同由各自的 Registry 來處理或管理，不同的 Registry 可以根據自己的狀況發表 Draft 以規範軟體的實作，而這個看法上，中國，台灣，日本，韓國的使用習慣是類似的，這些國家通常以 CJK字表來做為一體的說法，所以在本次會議後，四國將就大家統一的需求，發表一篇 CJK 的 Draft/guild line 來說明。
會議上亦討論到 BIDI 如阿拉伯文等由右至左的文字的處理或是印度不同語言的對照關係，不過因為會上並無這類的人，故沒有人知道他們的意見如何，而大家就決定他們的作法如何是不恰當的，應該由這些國家自己發表像繁簡對照表之類的字表，只要用到這些文字的註冊再參考這些字表即可。因為本次會議仍存在許多不同竟見，故原本主席預計會後將進入 Last Call 的 Draft 也延後，待大家有許共識後再進入 Last Call。
V6OPS Working Group
本屆 V6ops 主要的報告重點在主要在兩部份， IPv6/IPv4 的 NAT 解決方案 (Draft)及目前 .SE 和 Google 的 IPv6 使用統計，這堶 NAT 解決方案受到許多囑目，因為他是過去以來，一直在講的 IPv4 -> IPv6 的過渡方案中，一個接受度較高的方案。
draft-thaler-v6ops-teredo-extensions-01.txt 主要介紹以不同的 NAT model 來解決 IPv6 位址過渡的問題，其詳列了五種 NAT model，來解決不同的問題，類如 v6/v4 轉換及內外溝通等。
1. Symmetric (對稱) NAT Support Extension，以新的 port 為 NAT 溝通的手段，所有的 Connection 皆會使用到這個 port pool。
2. UPnP-Enabled Symmetric NAT Extension，以即插即用的概念來設計 NAT，所以上線的設備在發起連線時，先向 NAT 取得要用的 ip/port，Client 以此資訊來發送資料，而 Server 端則回應至 NAT，由 NAT 取得內部對應後，導入內部的 Client。
3. Port-Preserving Symmetric NAT Extension，以保護 Port 的方式的 NAT，即是現行的 NAT 模式，在 session 未結束前，NAT 上的這個 port 皆不能再被使用，並自動以這個 port 去對應內部主機。
4. Hairpinning Extension，原路返迴的 NAT，因為封包在傳送過程中，每次或每個封包的路徑可能有所不同，而此 model 在確保這個路由可以保證去回皆相同，唯有相同的情況，NAT 才能發揮對應的功能及了解連線狀況。
5. Server Load Reduction Extension，以 Server 的角度來思考，直接記錄每個訊息，所有的連線直接以 End to End 的方式來進行。
.SE 及 GOOGLE 的報告則體現了目前 IPv6 利用率不高，兩者的報告皆指出目前 IPv6 在 Internet 上的用量皆不足 0.5%，而這用戶中使用 MAC 的人比例是最高的，而這些人堶情A使用 Tunnel 方案的人又超過了八成，所以，可以了解到，即使 IPv4再兩年就用完了，但目前的 IPv6 在 Internet 上的使用及應用仍嚴重不足。
四、建議意見
1. EAI WG 的實作各NIC 皆未涉及 DSN/POP/IMAP，中心的 test-bed 可考慮此部份之實作。
2. IDNAbis CJK draft 可儘早連絡各 NIC 以利發展進程。
3. DNSOP/DNSEXT 的議程及討論來看，DNSSEC是未來WG的工作重點，也是未來 DNS 相關領域的人需多加研究的課題。
4. V6ops 中的 NAT 方案可請 IP 組及 IPv6 計劃相關人員多加研究及參與討論，並請 ISP 亦進行了解，提供建言。
五、其他相關事項或資料
有關第七十三次IETF會議議程及相關會議資料請參考(Agenda/ Session/ Presentations)：
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=73