CNS 15097-2007 IPv6 over PPP《经由PPP之IPV6协定》.pdf

上传人:proposalcash356 文档编号:635023 上传时间:2018-12-22 格式:PDF 页数:10 大小:314.46KB
下载 相关 举报
CNS 15097-2007 IPv6 over PPP《经由PPP之IPV6协定》.pdf_第1页
第1页 / 共10页
CNS 15097-2007 IPv6 over PPP《经由PPP之IPV6协定》.pdf_第2页
第2页 / 共10页
CNS 15097-2007 IPv6 over PPP《经由PPP之IPV6协定》.pdf_第3页
第3页 / 共10页
CNS 15097-2007 IPv6 over PPP《经由PPP之IPV6协定》.pdf_第4页
第4页 / 共10页
CNS 15097-2007 IPv6 over PPP《经由PPP之IPV6协定》.pdf_第5页
第5页 / 共10页
点击查看更多>>
资源描述

1、1 印月968月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.100.30 X127315097經濟部標準檢驗局印 公布日期 修訂公布日期 968月21日 月日 (共10頁)經由 PPP 之 IPv6 協定 IPv6 over PPP 1. 適用範圍 點對點協定(point-to-point protocol, PPP)提供經由點對點鏈路囊封網路層協定資訊的標準方法。PPP亦定義可延伸的鏈路控制協定(link control protocol, LCP),並提出一族系的網路控制協定(network control protocol, NCP)用以建立及設定不同網

2、路層協定。 本標準定義IPv6封包經由PPP鏈路之傳輸方法,以及建立及組態設定經由PPP之IPv6的NCP。本標準亦規定於PPP鏈路上形成IPv6本地鏈路位址之方法。 PPP由三個主要成份組成 (1) 在串列鏈路上囊封資料包之方法。 (2) 為建立、組態設定及測試資料鏈路連接而定的鏈路控制協定。 (3) 為建立及組態設定不同網路層協定而定的一族系網路控制協定。 為在點對點鏈路上建立通訊,每個PPP鏈路端點必須首先傳送LCP封包以設定及測試資料鏈路,而當該鏈路已建立且LCP所需的選項設施亦已協商後,PPP必須傳送NCP封包以選擇及設定一或數個網路層協定。一旦每個選定之網路層協定已被設定,則每個網

3、路層協定之資料包始能在鏈路上傳送。 該為建立及設定IPv6在PPP上傳輸之NCP,在本標準中則被參照為IPv6控制協定(IPv6 control protocol,IPV6CP)。 此鏈路通訊將會維持該設定,直至外顯的LCP或NCP封包關閉此鏈路,或至某些外部事件發生(例如另端點電力失效、載波落失等)。 本標準中關鍵用語如:“必須“、“不得“、“需要“、“應“、“不應“、“宜“、“不宜“、“建議“、“可“及 “選項的“等係參照參考文獻7之用語釋義。 2. 發送IPv6資料包 在任何IPv6封包可通訊前,PPP必須達到網路層協定階段,且IPv6控制協定必須達到已開啟(opened)之狀態。 一個

4、IPv6封包恰好被囊封於PPP資料鏈路層訊框的資訊欄位中,該處協定欄位指示型式為十六進制0057(網際網路協定第6版,internet protocol version 6,IPv6)。 在PPP鏈路上,傳輸IPv6封包之最大長度與PPP資料鏈路層訊框之資訊欄位的最大長度相同。支援IPv6之PPP鏈路必須允許其資訊欄位至少與IPv6所需的最小鏈路最大傳輸單位(maximum transmission unit,MTU)尺寸同樣2。 3. IPv6之PPP網路控制協定 IPv6控制協定(IPV6CP)負責對點對點鏈路之二端點,組態設定、致能及去能該IPv62 CNS 15097, X 1273

5、協定模組,IPV6CP使用如同鏈路控制協定(LCP)之封包交換機制。直至PPP達到網路層協定階段IPV6CP封包始可進行交換。而在此階段達到之前接收到的IPV6CP封包宜默默地丟棄。 除下述的例外,IPv6控制協定完全與鏈路控制協定相同1: 資料鏈路層協定欄位 一個IPV6CP封包恰好被囊封於PPP資料鏈路層訊框的資訊欄位中,該處協定欄位指示型式為十六進制8057 (IPv6控制協定)。 編碼欄位 僅有編碼1至7(組態設定請求configure-request、組態設定確認configure- ack、組態設定未確認configure-nak、組態設定拒絕configure-reject、終止

6、請求terminate-request、終止確認terminate-ack與碼拒絕code-reject)被使用,其他編碼宜視為無法辨識且宜得到碼拒絕之結果。 逾時 直至PPP達到網路層協定階段IPV6CP封包始可進行交換。實作宜準備等待鑑別及鏈路品質決定(authentication and link quality determination)在組態設定確認Configure-Ack或其他回應等待逾時之前完成。建議實作僅在使用者介入或歷經一段設定的時間後放棄。 組態選項型式 IPV6CP具有一組不同的組態選項。 4. IPV6CP組態選項 IPV6CP組態選項允許協商期望的IPv6參數,I

7、PV6CP使用相同於LCP所定義之組態選項格式1,但用分別的選項組。如果IPV6CP組態選項不含於組態設定請求configure-request封包中,則假設組態選項使用預設值。 IPV6CP選項型式欄位之更新值規定於最新的“所指定號碼“(“assigned numbers“)標準中4。現行值指定如下: 1 介面識別符(interface-identifier) 2 IPv6壓縮協定(IPv6-compression-protocol) 本標準所定義的IPV6CP選項僅為介面識別符與IPv6壓縮協定。任何其他能被定義的IPV6CP組態選項將另行於其他標準中定義。 4.1 介面識別符 描述 本組

8、態選項提供協商唯一64位元介面識別符之方法以用於在鏈路之本地端點(參照本標準下一節)的位址自動組態設定3,組態設定請求Configure-Request必須正確地包含一個介面識別符選項之實例1。此介面識別符必須在此PPP鏈路中為唯一,意即在完成協商時,為PPP鏈路之端點而選擇互不同的介面識別符值,此介面識別符可在較為廣泛之範圍內亦為唯一。 在此組態選項被請求前,實作選擇其暫時的介面識別符。此暫時的介面識別符宜選為非0之值,因此此值對鏈路,與對可能有的IPV6CP有限狀態機(即管理3 CNS 15097, X 1273 關閉與重新開啟、重新啟動等)之持續地再製的初始化而言,皆為唯一。對完全隨機的

9、介面識別符性質而言,採用此種持續地再製唯一介面識別符方式的合理解釋是對全域範圍之位址提供穩定性,而該位址可從介面識別符形成。 假設介面識別符之位元是以由小而大從0至63予以編號,並以最高有效位元編為位元號碼0,位元號碼6即為“u“位元(IEEE EUI-64術語中5之廣用/本地位元)用以指示出介面識別符是基於全域唯一IEEE識別符(EUI-48或 EUI-64 5)(參照下列案例1)與否,如使用全域唯一IEEE識別符來導出介面之識別符則設為1,若為其他則設為0。 下述為照優先次序選擇暫時的介面識別符之方法: (1) 如在此節點任何地方IEEE全域識別符皆為可用,則因為其具有唯一性的性質,故宜使

10、用其以建構暫時的介面識別符。然當從此節點其它裝置中抽取IEEE全域識別符時,宜注意抽取出的IEEE全域識別符應以由小至大的次序出現。 從EUI-64識別符僅有的轉換即為反轉該“u“位元(IEEE EUI-64術語中之廣用/本地位元)。例如,全域唯一EUI-64識別符為下述形式: 最高有效位元 最低有效位元 | 0 1|1 3|3 4|4 6| | 0 5|6 1|2 7|8 3| cccccc0gcccccccc cccccccceeeeeeee eeeeeeeeeeeeeeee eeeeeeeeeeeeeeee 其中,“c“為所指定company_id之位元 “0“為廣用/本地位元值以指示全

11、域範圍 “g“為群組/個別位元 “e“為延伸識別符之位元 則IPv6介面識別符將為下述形式: 最高有效位元 最低有效位元 | 0 1|1 3|3 4|4 6| | 0 5|6 1|2 7|8 3| cccccc1gcccccccc cccccccceeeeeeee eeeeeeeeeeeeeeee eeeeeeeeeeeeeeee 僅有的改變為反轉該廣用/本地位元之值。 在EUI-48識別符情況時,首先藉由插入十六進制值0xFF與0xFE等2個位元組於48位元媒介存取控制(Media Access Control,MAC)中間(在EUI-48值company_id與延伸識別符兩部分之間)以轉成

12、EUI-64之格式,例如,全域唯一48位元EUI-48識別符為下述形式: 4 CNS 15097, X 1273 最高有效位元 最低有效位元 |0 1|1 3|3 4| |0 5|6 1|2 7| cccccc0gcccccccc cccccccceeeeeeee eeeeeeeeeeeeeeee其中,“c“為指定company_id之位元 “0“為廣用/本地位元值以指示全域範圍 “g“為群組/個別位元 “e“為延伸識別符之位元 則IPv6介面識別符將為下述形式: 最高有效位元 最低有效位元 |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| cccccc1gccccccc

13、c cccccccc11111111 11111110eeeeeeee eeeeeeeeeeeeeeee (2) 如果IEEE全域識別符為不可用,則宜使用其他能具唯一性的來源,建議具唯一性的來源包含鏈路層位址、機器序號等。 在此狀況下,介面識別符中之“u“位元必須設為0。 (3) 如果找不到好的具唯一性來源,則建議產生隨機號碼。在此狀況下,介面識別符中之“u“位元亦必須設為0。 為使介面識別符協商成功,具唯一性的或具隨機性的好來源 1是需要的。如果既不能產生唯一號碼或隨機號碼,則建議在組態設定請求Configure-Request所傳輸的介面識別符使用0值。在於此狀況下,PPP同層可提供有效非

14、0值之介面識別符為之回應如後述。注意:如果PPP同層中最少有一個能為其自身與其同層產生分別的非0號碼,則識別符協商會成功。 當接收到具有介面識別符組態選項的組態設定請求Configure-Request且接收同層實作此選項時,已接收之介面識別符與上次發送組態設定請求Configure-Request至同層之介面識別符加以比對,依據比對之結果,實作必須以下述方法之一回應: 如果此2個介面識別符不同但已接收之介面識別符為0,遠端同層發送具有建議使用非0之介面識別符值的組態設定未確認Configure-Nak。但此建議之介面識別符必須與上次發送組態設定請求Configure-Request至同層之介

15、面識別符不同。規定此建議值為IPV6CP有限狀態機(即管理關閉與重新開啟、重新啟動等)之持續地再製的初始化值。建議的識別符中其“u“位元(廣用/本地位元)不論其來源必須設為0,除非是由遠端同層提供且為互斥使用之全域唯一導出的EUI-48或 EUI-64識別符。 如果此2個介面識別符不同但已接收之介面識別符不為0,此介面識別符必須被確認。意即,具有已請求介面識別符之組態設定確認Configure-Ack被發送,5 CNS 15097, X 1273 亦謂回應同層同意已請求之介面識別符。 如果此2個介面識別符相同且皆非為0,遠端同層必須發送具有建議使用規定不同非0之介面識別符值的組態設定未確認Co

16、nfigure-Nak。規定此建議值為IPV6CP有限狀態機(即管理關閉與重新開啟、重新啟動等)之持續地再製的初始化值。建議的識別符中其“u“位元(廣用/本地位元)不論其來源必須設為0,除非是由遠端同層提供且為互斥使用之全域唯一導出的EUI-48或 EUI-64識別符。 如果此二個介面識別符相同且皆為0,此介面識別符藉由傳輸具介面識別符值設為0之組態設定拒絕Configure-Reject,而協商必須終止,因為在此種狀況時,協商不出唯一之介面識別符。 如果接收到具有介面識別符組態選項之組態設定請求Configure-Request,但接收同層並不實作此選項,發送組態設定拒絕Configure-

17、Reject。 直到正常處理將使其能被發送時,新的組態設定請求Configure-Request始宜發送(意即,直到組態設定未確認Configure-Nak已接收或再啟動計時器計時終了)。 如果接收到有效的介面識別符組態設定拒絕Configure-Reject,則新的組態設定請求Configure-Request不得包含介面識別符選項。 收到具有建議之介面識別符組態設定未確認Configure-Nak其與上次發送組態組態設定未確認Configure-Nak至同層不同將指示一個唯一介面識別符。在此狀況下,必須發送新的具有從同層上次組態設定未確認Configure-Nak時的識別符建議值組態設定請

18、求Configure-Request。但是如果收到的介面識別符與上次組態設定未確認Configure-Nak相同,則必須選擇新的介面識別符。在此狀況下,宜發送具有新的暫時的介面識別符之新的組態設定請求Configure-Request。此種依序的發送(傳輸設定請求Configure-Request、接收組態設定請求Configure-Request、傳輸組態設定未確認Configure-Nak、接收組態設組態定未確認Configure-Nak)也許發生數次,但極不可能不斷地發生,可能的是,在各端點選擇之介面識別符將快速地分送而終止此發送序列。 如果需要協商介面識別符,且同層在其組態設定請求Co

19、nfigure-Request中並不提供此選項,則該選項宜附接(appended)於組態設定未確認Configure-Nak上。給予的介面識別符其暫時值必須如同遠端介面識別符般接受。意即,其宜與為PPP鏈路之本地端而選定之識別符值不同。從同層而來之下次組態設定請求Configure-Request可包含此選項。如果下次組態設定請求Configure-Request並未包含此選項,則同層不得發送另外包含有此此選項之組態設定未確認Configure-Nak,宜假設同層之實作不支援此選項。 根據預設值,實作宜試圖為其PPP連接之端點協商出介面識別符。 介面識別符組態選項格式彙總列於下,該欄位係由左至

20、右傳輸。 6 CNS 15097, X 1273 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 型式 長度 介面識別符(最高有效位元組) 介面識別符(續) 介面識別符(最低有效位元組) 型式1 長度10 介面識別符 如果找不到好的唯一性來源,則在鏈路上,該64位元介面識別符非常類同為唯一或為0。 預設值 如果無法成功地協商出有效的介面識別符,則宜假設無預設介面識別符值。在此狀況下,未規定如何復原之程序,一種可行之作法為手動設定該介面之介面識別符。 4.2 IPv6壓縮協定 描述 本組態選項提供方法

21、以協商使用特定IPv6封包壓縮協定。本IPv6壓縮協定組態選項用於指示接收壓縮封包之能力。若期望雙向壓縮,則鏈路之每個端點必須分別地請求此選項。根據預設值,壓縮並未被致能。 具此選項協商之IPv6壓縮對IPv6資料包(datagram)而言為特定,且勿與經由壓縮控制協定(Compression Control Protocol,CCP)協商後之壓縮結果混淆。後者(CCP)則大概影響全部的資料包。 IPv6壓縮協定組態選項格式彙總列於下,該欄位係由左至右傳輸。 0 1 2 3 0 1 2 3 4 5 6 7 89 0 1 2 3 45678901234567 8 9 0 1 型式 長度 IPv6

22、壓縮協定 資料 . 型式2 長度= 4 IPv6壓縮協定 IPv6壓縮協定欄係為2個八位元組且指示期望的壓縮協定,對使用相同壓縮協7 CNS 15097, X 1273 定而言,此欄值永遠與PPP資料鏈路層協定欄值相同。 IPv6壓縮協定欄值現行尚未指定,在定義特定壓縮演算法之標準中將作出該特定指定。 資料 資料欄係為0或數個八位元組且包含由特殊壓縮協定所決定之額外的資料。 預設值 IPv6壓縮協定並未被致能。 5. 不具狀態的自動組態設定與本地鏈路位址 PPP介面之IPv6單播(unicast)位址6的介面識別符宜在PPP連接建立(參照4.1節)之IPV6CP階段中協商。如果無法成功地協商出

23、有效的介面識別符,則未規定在此狀況下如何復原之程序,一種可行之作法為手動設定該介面之介面識別符。 不論介面識別符在PPP連接建立之IPV6CP階段中協商時有多長,其皆需冗餘地履行重複位址之偵測而成為不具狀態的自動組態設定協定3之組成部分;因此,建議為具IPV6CP介面識別符選項的PPP鏈路,致能其自動組態設定變數3 DupAddrDetectTransmits之預設值為0。 PPP介面之本地鏈路位址具有下述之格式: 10個位元 54個位元 64個位元 1111111010 0 介面識別符 位址中之最高有效之10個位元為本地鏈路前綴FE80:,該位址在本地鏈路前綴欄與介面識別符欄之間則填補54個

24、皆為0的位元。 6. 安全性考量 對PPP之IPv6控制協定之延伸可使用所有已定義的PPP鑑別與加密機制。 相對應國際標準:RFC 2472:1998 IPv6 over PPP 8 CNS 15097, X 1273 參考文獻 1 Simpson, W., “The Point-to-Point Protocol“, STD 51, RFC 1661, July 1994. 2 Deering, S., and R. Hinden, Editors, “Internet Protocol, Version 6 (IPv6) Specification“, RFC 2460, December

25、 1998. 3 Thomson, S., and T. Narten, “IPv6 Stateless Address Autoconfiguration“, RFC 2462, December 1998. 4 Reynolds, J., and J. Postel, “Assigned Numbers“, STD 2, RFC 1700, October 1994. See also: http:/www.iana.org/numbers.html 5 IEEE, “Guidelines for 64-bit Global Identifier (EUI-64) Registration

26、 Authority“, http:/standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. 6 Hinden, R., and S. Deering, “IP Version 6 Addressing Architecture“, RFC 2373, July 1998. 7 Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,“ BCP 14, RFC 2119, March 1997. 8 Narten T., and C. Burto

27、n, “A Caution On The Canonical Ordering Of Link-Layer Addresses“, RFC 2469, December 1998. 9 CNS 15097, X 1273 英中名詞對照表 A appended 附接 assigned numbers 所指定號碼 authentication and link quality 鑑別及鏈路品質決定 B C Code-Reject 碼拒絕 compression-protocol 壓縮協定 configure-ack 組態設定確認 configure-nak 組態設定未確認 configure-rej

28、ect 組態設定拒絕 configure-request 組態設定請求 D datagram 資料包 E F G H I interface-identifier 介面識別符 J K L link control protocol, LCP 鏈路控制協定 M Maximum transmission unit,MTU 最大傳輸單位 media access control,MAC 媒介存取控制 10 CNS 15097, X 1273 N network control protocol, NCP 網路控制協定 O opened 已開啟 P point-to-point protocol, PPP 點對點協定 Q R S T terminate-ack 終止確認 terminate-request 終止請求 U unicast 單播

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 标准规范 > 国际标准 > 其他

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1