引言
在Internet上搜尋到RFC 7668–IPv6 over BLUETOOTH Low Energy，搭配Yahoo字典、和Google翻譯等工具，我嘗試著將文章的片段翻譯成繁體中文版，希望大家對於藍芽低能耗上面的6LoWPAN擁有些許認識。摘要
Bluetooth Smart是Bluetooth Special Interest Group定義的藍芽規範中藍芽低能耗功能的品牌名稱。標準藍芽無線電已廣泛實施，可用於行動電話、筆記型電腦、耳麥和許多其他裝置。藍芽的低功耗版本是一種規範，可以將感測器、智慧電錶、和電器等裝置在這種空氣介面上結合。藍芽的低功耗版本自藍芽規範的4.0版本開始已經標準化，儘管IPv6需要4.1或更高的版本。本文描述如何使用6LoWPAN(IPv6 over Low-power Wireless Personal Area Network)技術來讓IPv6透過藍芽低能耗進行傳輸。本文
1. 簡介
Bluetooth Smart是Bluetooth Special Interest Group定義的藍芽規範[BTCorev4.1]中藍芽低功耗特性(以下稱為"藍芽LE")的品牌名稱。藍芽LE是一種無線電技術，適用於使用極低容量(例如鈕扣電池)電池或簡約電源工作的裝置，這意味著低功耗是必不可少的。藍芽LE是一種對於健康監視器、環境感應、接近應用等物聯網應用特別有吸引力的技術。考慮到感測器和網際網路連接裝置數量呈指數增長的可能性，IPv6是一種理想的協定，用於與這些裝置進行通訊，因為它提供了大的位址空間。 此外，IPv6還提供了無狀態位址自動配置(stateless address autoconfiguration)工具，尤其適用於處理能力非常有限、或是缺乏完整作業系統或用戶界面的感測器網路應用和節點上。
本文描述如何使用6LoWPAN技術透過藍芽LE連接傳輸IPv6。4944 [RFC4944]、6282 [RFC6282]、和6775 [RFC6775]等是為了6LoWPAN開發的RFC，其指定通過IEEE 802.15.4 [IEEE802.15.4]傳輸IPv6。藍芽LE鏈路在許多方面具有與IEEE 802.15.4類似的特性，並且通過IEEE 802.15.4為IPv6定義的許多機制可以應用於藍芽LE鏈路上的IPv6傳輸。本文說明了通過藍芽LE鏈路進行IPv6傳輸的詳細訊息。
2. 藍芽低能耗
藍芽LE設計用於以適度的資料速率不頻繁地傳輸少量資料，每比特的能量消耗非常小。Bluetooth Special Interest Group推出了兩個商標：藍芽smart用於單模裝置(一種僅支持藍芽LE的裝置)和藍芽Smart Ready用於雙模裝置(支援藍芽和藍芽LE的裝置；注意 藍芽和藍芽LE是不同的、非互操作的無線電技術)。本文的其餘部分中，無論單模或雙模裝置是否支持此技術都使用術語"藍芽LE"。藍芽LE在藍芽4.0中引入，在藍芽4.1 [BTCorev4.1]中得到了增強，並且在後續版本中進一步發展。Bluetooth Special Interest Group還發布了Internet協定支持配置profile(即IPSP)，其中包括Internet協定支援服務(IPSS)。 IPSP允許發現啟用IP的裝置並建立用於傳輸IPv6封包的鏈路層連接。藍芽LE上的IPv6依賴於藍芽4.1和IPSP 1.0或更新版本的任一規範來提供必要的功能。
舉凡行動電話、筆記型電腦、平板電腦、智慧手錶、和其他包含實現藍芽4.1或更高版本的晶片組的手持計算裝置的裝置也將具有藍芽的低能量功能。藍芽LE還有望包含在許多不同類型的配件中，這些配件可與手機、平板電腦、和筆記型電腦等移動裝置配合使用。用於藍芽LE配件的用例的範例是心率監視器，其通過移動電話或智慧手錶將資料發送到網際網路上的服務器，抑或直接將資料發送到裝置。
2.1. 藍芽低能耗堆疊
藍芽LE堆疊的下層包括物理層(PHY)、鏈路層(LL)、和稱為直接測試模式(DTM)的測試介面。物理層發送和接收實際封包。鏈路層負責提供介質存取、連接建立、錯誤控制、和流量控制。直接測試模式僅用於測試目的。上層包括邏輯鏈路控制和適配協定(L2CAP)、屬性協定(ATT)、安全管理器(SM)、通用屬性profile(GATT)、和通用存取profile (GAP)，如圖1所示。主機控制介面(HCI)將通常在藍芽控制器中實現的較低層與較高層(通常在主機堆疊中實現)分離。GATT和藍芽LE profile共同支持以標準化方式創建應用程序、而無需使用IP。L2CAP通過多工來自上述層級的資料頻道來提供多工能力。L2CAP還為大型資料封包提供分段和重組。安全管理器為藍芽LE裝置定義配對/密鑰分發、和安全工具箱等協定和機制。
如3.1節所示，IPv6 over Bluetooth LE需要在藍芽LE L2CAP之上運行的改進的6LoWPAN層。
2.2. 鏈路層的角色與拓撲
藍芽LE定義了兩個與此相關的GAP角色：藍芽LE中心角色和藍芽LE週邊角色。處於核心角色的裝置(從現在開始稱為"中心")傳統上能夠與週邊角色中的多個裝置(從現在開始稱為"週邊")管理多個同時連接。週邊裝置通常連接到單個中心裝置，但從4.1開始的藍芽版本，它也可以同時連接到多個中心裝置。在本文中，對於IPv6組網的目的，藍芽LE網路(即藍芽LE微微網)遵循圖2中所示的星形拓撲，其中路由器通常實現藍芽LE中心角色，其餘節點實現藍芽LE週邊角色。將來，可以通過藍芽LE為IPv6定義一次到多個中心的網狀網路和/或併行連接。
在藍芽LE中，直接無線通訊僅在中心和週邊之間進行。這意味著藍芽LE星(star)本身就代表了一個hub-and-spokes鏈路模型。然而，根據該規範，兩個週邊裝置可以通過使用IP路由功能通過中心進行通訊。
2.3. 藍芽LE裝置定址
每個藍芽LE裝置都由48位元裝置位址標識。藍芽規範[BTCorev4.1]描述了藍芽LE裝置的裝置位址，如下所示："使用裝置位址識別裝置。裝置位址可以是公共裝置位址或隨機裝置位址"。公共裝置位址基於IEEE 802標準。隨機裝置位址和藍芽LE隱私特性分別在的藍芽通用存取profile [BTCorev4.1]第10.8節和第10.7節中描述。有兩種類型的隨機裝置位址：靜態和私有位址。私有位址進一步分為兩個子類型：可解析或不可解析的位址，在參考的藍芽規範中對其進行了深入的解釋。一旦靜態位址被初始化，它就不會改變，直到裝置重新插電。靜態位址可以在每個電源循環後初始化為新值，但這不是強制性的。隨機化新的專用位址的推薦時間間隔是15分鐘，由藍芽通用存取profile [BTCorev4.1]的表17.1中的定時器T_GAP(private_addr_int)決定。選擇使用哪種裝置位址類型受限於實作和部署。在隨機位址中，前46位是隨機的，後2位表示隨機位址類型。藍芽LE不支持避免或檢測裝置位址衝突。但是，這些48位元隨機裝置位址在典型部署中發生衝突的可能性非常小。2.4. 藍芽LE封包尺寸和MTU
通過藍芽LE為L2CAP固定頻道定義的最佳MTU是27個位元組，包括4個位元組的L2CAP標頭。因此，藍芽LE的預設MTU定義為27個位元組。因此，排除4個位元組的L2CAP標頭，23個位元組的協定資料單元(PDU)大小可用於上層。為了能夠傳輸1280個位元組或更大的IPv6封包，L2CAP層提供了鏈路層分段和重組解決方案。IPSP定義了用於協商鏈路層連接的裝置，該連接為IPv6層[IPSP]提供1280個位元組或更高的MTU。鏈路層MTU針對每個方向單獨協商。需要兩個方向的相同鏈路層MTU的實現應該使用可能的、不同的MTU值中最小的一個。3. 藍芽低能耗IPv6規範
藍芽LE技術對低功耗設定了嚴格的要求，因此限制了允許的協定開銷。6LoWPAN標準RFC6775和RFC6282提供了有用的功能，可以減少開銷，適用於藍芽LE。此功能由鏈路本地IPv6位址和無狀態IPv6位址自動配置(參見第3.2.2節)、鄰居發現(參見第3.2.3節)、和標頭壓縮(參見第3.2.4節)組成。由於藍芽LE的鏈路層支援分段，未使用6LoWPAN標準的分段功能(參見第2.4節)。一個IEEE 802.15.4和藍芽LE之間的顯著差異，在於前者支持星形和網狀拓(並且需要路由協定)、而藍芽LE當前不支持在鏈路層形成多跳網路。但是，通過使用每個規範的IP路由功能，可以實現通過中心的來達成週邊與週邊的通訊。
在藍芽LE中，假設中心節點比週邊節點具有更少的資源約束。因此，在主要部署方案中，中心和週邊裝置將分別充當6LoWPAN邊界路由器(6LBR)和6LoWPAN節點(6LN)。
在通過藍芽LE進行任何IP層通訊之前，藍芽LE啟用的節點(例如6LN和6LBR)必須找到彼此並建立合適的鏈路層連接。Bluetooth Special Interest Group在IPSP規範[IPSP]中記錄了發現和藍芽LE連接建立過程。
在藍芽LE隨機裝置位址衝突的罕見情況下，6LBR可以檢測具有相同藍芽LE裝置位址的多個6LN、以及具有與6LBR相同的藍芽LE位址的6LN。6LBR必須忽略具有6LBR所具有的相同裝置位址的6LN，並且6LBR在任一時刻必須具有至多一個用於給定藍芽LE裝置位址的連接。這將避免藍芽LE網路內的衝突。
3.1. 協定堆疊
圖3說明了IPv6堆疊如何與藍芽LE L2CAP層之上的GATT堆疊並行工作。這裡需要GATT堆疊用於發現支持網際網路協定支持服務的節點。提供UDP和TCP作為傳輸協定的示例，但是堆疊可以由能夠在IPv6上運行的任何其他上層協定使用。
3.2. 鏈接模型
需要區隔IPv6鏈路(第3層)和物理鏈路(PHY和MAC媒體訪問控制的組合)的不同概念，並且必須很充份地理解它們之間的關係，以便指定用於藍芽LE鏈路上來傳輸IPv6的定址形式的封包。RFC 4861 [RFC4861]將鏈路定義為"節點可以在鏈路層進行通訊的通訊設施或介質，亦即緊鄰IP的層"。在藍芽LE的情況下，6LoWPAN層適於支持通過藍芽LE傳輸IPv6封包。IPSP定義了設置6LoWPAN可以在其上運行的藍芽LE連接所需的所有步驟[IPSP]，包括處理藍芽LE上所需的鏈路層分段，如第2.4節所述。即使可以支持大於1280個位元組的MTU，建議使用1280個位元組的MTU，以避免需要路徑MTU發現過程。
雖然藍芽LE協定(如L2CAP)使用小端位元組次序(little-endian)，但IPv6封包必須以大端big-endian位元組次序(網路位元組順序)傳輸。
根據此規範，必須使用RFC 6282 [RFC6282]中指定的IPv6標頭壓縮格式。可以從L2CAP標頭長度導出IPv6有效負載長度，並且可以從藍芽LE連接建立時使用的鏈路層位址、連接期間的HCI連接控制、壓縮上下文(如果有的話)重構可能省略的IPv6位址和位址註冊訊息(參見第3.2.3節)。
用於構建星型拓撲的藍芽LE連接本質上是點對點的，因為藍芽廣播功能不用於藍芽LE上的IPv6(除了發現支持IPSS的節點)。在週邊裝置和中心裝置連接到藍芽LE級別後，可以認為鏈路已啟動，並且可以開始IPv6位址配置和傳輸。
3.2.1. IPv6子網模型和Internet連接
在藍芽LE微微網模型(參見第2.2節)中，每個週邊裝置都有一個到中心的獨立鏈路，而中心則充當IPv6路由器而不是鏈路層交換器。如[RFC4903]中所討論的，IPv6的傳統使用預期IPv6子網跨越鏈路層的單個鏈路。由於藍芽LE上的IPv6旨在用於受約束的節點，並且針對於物聯網使用案例和環境，在每個週邊中心鏈路上實現單獨子網以及在子網之間路由的複雜性似乎過高。在藍芽LE的情況下，將中心鏈路和其連接的週邊裝置之間的點對點鏈路集合視為單個多鏈路子網(single multilink subnet)、而不是多個單獨的子網(multiplicity of separate subnets)的好處被認為超過了如[RFC4903]多鏈路模型的缺點。因此選擇了如圖4中進一步所示的多鏈路模型。鏈路本地群播(multicast)通訊僅在單個藍芽LE連接內發生；因此，使用鏈路本地位址的6LN到6LN通訊是不可能的。連接到同一6LBR的6LN必須使用子網上使用的共享前綴相互通訊。6LBR確保不會發生位址衝突(參見第3.2.3節)，並將一個6LN發送的封包轉發給另一個。
在典型情況下，藍芽LE網路連接到Internet，如圖4所示。在此方案中，藍芽LE星被部署為一個子網，使用一個/64 IPv6前綴，每個spoke代表一個單獨的鏈路。 6LBR充當路由器，在6LN之間、以及Internet之間轉發封包。
在某些情況下，藍芽LE網路可能暫時或永久成為隔離網路，如圖5所示。在這種情況下，整個星形由一個具有多個鏈路的子網組成，其中6LBR位於中心，在6LN之間路由封包。在最簡單的情況下，隔離網路有一個6LBR和一個6LN。
3.2.2. 無狀態位址自動配置
在網路介面初始化時，6LN和6LBR都應根據用於建立基礎藍芽LE的48位元藍芽裝置位址(參見第2.3節)生成並分配給藍芽LE網路介面IPv6鏈路本地位址[RFC4862]連接。建議使用6LN和6LBR來使用專用藍芽裝置位址。6LN應該為每個帶有6LBR的藍芽LE連接選擇不同的藍芽裝置位址、而6LBR應定期更改其隨機藍芽裝置位址。在[RFC7136]的指導下，透過插入兩個位元組，在48位元藍芽裝置位址的中間，使用十六進制值0xFF和0xFE，從48位元藍芽裝置位址形成64位元介面標識編號(IID)。如圖6所示。在圖中，字母"b"表示藍芽裝置位址中的一個位元，照著原樣複製，不對任何位進行任何更改。這意味著IID中的任何位元都不表示底層藍芽裝置是公共的或是隨機的位址。
然後，該IID用前綴FE80:: / 64，如在RFC 4291 [RFC4291]中描述的且如圖7所示，應當使用藍芽L2CAP LE頻道的生存期相同的鏈路本地位址。(在建立藍芽LE邏輯鏈路之後，在HCI中使用連接控制引用它。因此，可能更改裝置位址不會影響現有L2CAP頻道內的資料流。因此，無需更改IPv6鏈路本地位址 ，即使裝置在L2CAP頻道生命週期內改變其隨機裝置位址)。
6LN必須加入全節點群播位址(all-nodes multicast address)。6LN不需要加入請求節點群播位址(solicited-node multicast address)，因為6LBR將知道所有連接的6LN的裝置位址和鏈路本地位址。6LBR將確保不會同時連接具有相同藍芽LE裝置位址的兩個裝置。重複鏈路本地位址的檢測由6LBR上的過程執行，該過程負責發現啟用IP的藍芽LE節點並啟動藍芽LE連接建立過程。這種方法增加了6LBR的複雜性，但通過減少強制封包傳輸的數量，在鏈路建立階段降低了6LN和6LBR的功耗。
在鏈路本地位址配置之後，6LN發送路由器請求消息，如[RFC4861]第6.3.7節中所述。
對於非鏈路本地位址，6LN不應配置為預設情況下將藍芽裝置位址嵌入IID中。預設情況下應該使用替代方案，如密碼生成位址(CGA) [RFC3972]、隱私擴展[RFC4941]、基於雜湊的位址(HBA) [RFC5535]、DHCPv6 [RFC3315]、或靜態語義不透明位址[RFC7217]。在已知藍芽裝置位址是私有裝置位址和/或在IID中嵌入裝置位址的標頭壓縮優點需要支持部署約束的情況下，6LN可以通過利用48位元的藍芽裝置位址形成64位元IID。6LN生成的非鏈路本地位址必須按照第3.2.3節中的描述在6LBR中註冊。
用於6LBR獲取用於編號藍芽LE網路的IPv6前綴的工具超出了本文的範圍，但可以通過DHCPv6前綴委派(Prefix Delegation) [RFC3633]或使用唯一本地IPv6單播位址(ULA)來實現[RFC4193]。由於藍芽LE的鏈路模型(參見第3.2.1節)，6LBR必須在鄰居發現消息[RFC4861]的前綴訊息選項中將"on-link"標誌(L)設置為零(參見第3.2.3節。這將導致6LN總是將封包發送到6LBR，包括目的地是使用相同前綴的另一個6LN的情況。
3.2.3. 鄰居發現
"基於6LoWPAN的鄰居發現優化" [RFC6775]描述了適用於若干6LoWPAN拓撲的鄰居發現方法，包括網狀拓撲。藍芽LE不支持網狀網路；因此，僅考慮適用於星形拓撲的那些方面。鄰居發現優化的以下方面[RFC6775]適用於藍芽LE 6LN：
1. 藍芽LE 6LN絕不能註冊其鏈路本地位址。藍芽LE 6LN必須通過發送帶有位址註冊選項(ARO)的鄰居請求(NS)消息來註冊其非鏈路本地位址和6LBR，並相應地處理鄰居通告(NA)。無論用於生成IID的方法如何，都必須發送帶有ARO選項的NS。如果6LN在同一壓縮上下文中註冊多個非基於藍芽裝置位址的位址，則標頭壓縮效率將降低(參見第3.2.4節)。
2. 對於發送路由器請求和處理路由器通告，藍芽LE 6LN必須分別遵循[RFC6775]的第5.3和5.4節。
3.2.4. 標頭壓縮
RFC 6282 [RFC6282]中定義的標頭壓縮，在IEEE 802.15.4之上指定IPv6資料封包的壓縮格式，需要作為藍芽LE之上的IPv6標頭壓縮的基礎。所有標頭必須根據RFC 6282 [RFC6282]中描述的編碼格式進行壓縮。可以利用藍芽LE的星形拓撲結構和ARO來提供位址壓縮機制。以下文字描述了藍芽LE之上的IPv6位址壓縮原理。
ARO選項需要使用64位元擴展唯一標識編號(EUI-64) [RFC6775]。在藍芽LE的情況下，該欄位應填充由藍芽LE節點所使用的48位元裝置位址所轉換成的64位元的修改過的EUI-64格式[RFC4291]。
為了實現有效的標頭壓縮，當6LBR發送路由器通告時，它必須包括6LoWPAN上下文選項(6CO)[RFC6775]，匹配通過前綴訊息選項(PIO)[RFC4861]通告的每個位址前綴，用於無狀態位址自動配置。
當6LN正在向6LBR發送封包時，如果它是鏈路本地位址，它必須完全忽略來源位址。對於帶有非鏈路本地來源位址的6LBR的其他封包，6LN已向ARO註冊到指示前綴的6LBR，如果是6LN註冊的最新位址，則必須完全省略來源位址。對於指示的前綴。如果來源非鏈路本地位址不是最新註冊的，那麼IID的64位元應完全在線承載(SAM = 01)，或者如果IID的前48位元與最新註冊的位址匹配，那麼IID的最後16位應該在線攜帶(SAM = 10)。也就是說，如果SAC = 0且SAM = 11，則6LN必須使用從藍芽LE裝置位址派生的鏈路本地IPv6位址，如果SAC = 1且SAM = 11，則6LN必須已註冊來源IPv6位址使用與壓縮上下文相關的前綴，6LN必須引用與壓縮上下文相關的最新註冊位址。只有在6LBR向其狀態欄位設置為成功的ARO發送了Neighbor Advertisement之後，才能認為IPv6位址是註冊完畢的。如果目的位址是基於6LBR藍芽裝置位址(DAC = 0，DAM = 11)的6LBR鏈路本地位址，則必須完全省略目的IPv6位址。
如果已為目的位址設置了上下文，則必須完全或部分省略目的IPv6位址，例如，當目的前綴為鏈路本地時，DAC = 0且DAM = 01，如果壓縮上下文已配置為使用的目的前綴，則DAC = 1，DAM = 01。
當6LBR正在向6LN發送封包時，如果來源IPv6位址是基於6LBR的藍芽裝置位址(SAC = 0，SAM = 11)的鏈路本地位址，它必須完全忽略來源IID，並且它必須忽略如果已設置與IPv6來源位址相關的壓縮上下文，則為來源前綴或位址。如果6LBR是基於6LN的藍芽裝置位址(DAC = 0，DAM = 11)的鏈路本地位址，或者如果目的地位址是6LN最新註冊的ARO，則6LBR也必須完全忽略目的IPv6位址指示的上下文(DAC = 1，DAM = 11)。如果目的位址是非鏈接本地位址而不是最新註冊的，則6LN必須完全包含IID部分(DAM = 01)，或者如果IID的前48位元與最新匹配註冊位址，然後忽略那些48位元(DAM = 10)。
3.2.4.1. 遠端目的示例
當6LN使用全局單播IPv6位址將IPv6封包發送到遠端目的時，如果為6LN的全局IPv6位址定義了上下文，則6LN必須根據第3.1節在壓縮IPv6標頭的相應來源欄位中指示此上下文。RFC 6282 [RFC6282]並且必須刪除先前在ARO註冊的完整IPv6來源位址(如果使用最新註冊的位址；否則，部分或全部IID可能必須在線傳輸)。為此，6LN必須在IPv6壓縮標頭中使用以下設置：SAC = 1且SAM = 11。CID可以設置為0或1，具體取決於使用的上下文。在這種情況下，6LBR可以推斷出省略的IPv6來源位址，因為 1) 6LBR先前已經為6LN分配了前綴； 2) LBR維護一個鄰居快取，該快取與裝置位址和裝置向ARO註冊的IID相關。如果為IPv6目的位址定義了上下文，則6LN還必須在壓縮IPv6標頭的相應目的欄位中指示此上下文，並且忽略前綴或完整目的IPv6位址。為此，6LN必須將壓縮IPv6標頭的DAM欄位設置為DAM = 01(如果上下文覆蓋64位元前綴)或DAM = 11(如果上下文覆蓋完整的128位位址)。 DAC必須設置為1。請注意，當為IPv6目的位址定義上下文時，6LBR可以使用上下文推斷省略的目的前綴。當6LBR收到藍芽LE網路外部的遠端節點發送的IPv6封包、並且封包的目的地是6LN時，如果為6LN的全局IPv6位址的前綴定義了上下文，則6LBR必須指示此上下文在壓縮的IPv6標頭的相應目的欄位中。如果IPv6目的位址可由6LN驅動，則6LBR必須在轉發之前忽略封包的IPv6目的位址。為此，6LBR將IPv6壓縮標頭的DAM欄位設置為DAM = 11(如果位址是最新已註冊的6LN)。 DAC需要設置為1。如果為IPv6來源位址定義了上下文，則6LBR需要在壓縮IPv6標頭的來源欄位中指示此上下文、並且也要刪除該前綴。為此，6LBR需要將IPv6壓縮標頭的SAM欄位設置為SAM = 01(如果上下文覆蓋64位元前綴)或SAM = 11(如果上下文覆蓋完整的128位位址)。SAC應設置為1。
3.2.4.2. 多個位址的註冊示例
如上所述，6LN可以註冊映射到相同壓縮上下文的多個非鏈路本地位址。從註冊的多個位址，只能完全省略最新位址(SAM = 11，DAM = 11)，並且先前註冊的位址的IID必須完全在線傳輸(SAM = 01，DAM = 01)，或者，在最好的情況下，可以部分省略(SAM = 10，DAM = 10)。這在以下示例中說明：1. 6LN註冊第一個位址2001:db8::1111:2222:3333:4444到6LBR。此時，可以使用SAC = 1 / SAM = 11或DAC = 1 / DAM = 11完全省略位址。
2. 6LN將第二個位址2001:db8::1111:2222:3333:5555註冊到6LBR。由於第二個位址現在是最新註冊的，因此可以使用SAC = 1 / SAM = 11或DAC = 1 / DAM = 11完全省略。現在可以使用SAC = 1 / SAM = 10或DAC = 1 / DAM = 10來部分省略第一位址，因為位址的前112位在第一和第二寄存位址之間是相同的。
3. 第一個或第二個位址的註冊時間逾期對壓縮沒有影響。因此，即使最近註冊的位址到期，也只能部分省略第一位址(SAC = 1 / SAM = 10，DAC = 1 / DAM = 10)。 6LN可以註冊新位址，或重新註冊過期位址，以便能夠再次完全忽略位址。
3.2.5. 單播和群播位址映射
藍芽LE鏈路層不支持群播。因此，兩個藍芽LE節點之間的流量始終是單播(unicast)的。即使在6LBR連接到多個6LN的情況下，6LBR也不能對所有連接的6LN進行群播。如果6LBR需要向其所有6LN發送群播封包，則必須複製封包並在每個鏈路上單播。然而，這可能不是節能的，並且如果中心是電池供電則必須特別小心。為了進一步節省功耗，6LBR必須以藍芽LE鏈路級粒度(不是子網粒度)追蹤群播偵聽器，並且它絕不能將群播封包轉發到尚未註冊為封包所屬群播組的偵聽器的6LN。在相反的方向上，6LN總是必須向6LBR發送封包或通過6LBR發送封包。因此，當6LN需要發送IPv6群播封包時，6LN將相應的藍芽LE封包單播到6LBR。4. 安全考量
通過藍芽LE鏈路傳輸IPv6和通過IEEE 802.15.4傳輸IPv6具有類似的要求和安全性問題。 IPSP [IPSP]涵蓋藍芽LE鏈路層的安全注意事項。藍芽LE鏈路層通過使用具有CBC-MAC(CCM)機制的計數器[RFC3610]和128位AES封包密碼來支持加密和認證。上層安全機制可以在可用時利用此功能。(注意：CCM不會消耗每個封包最大L2CAP資料大小的位元組，因為鏈路層資料單元在使用時會有一個特定的欄位。)
藍芽LE中的密鑰管理由安全管理器協定(SMP)提供，如[BTCorev4.1]中所定義。
直接測試模式提供兩種設置選擇：有無可訪問的HCI。在具有可訪問HCI的設計中，所謂的上層測試器通過HCI(可由透過非同步收發器UART、通用序列匯流排USB、和Secure Digital傳輸支援)進行通訊，具有物理層和鏈路層。正在測試的藍芽LE裝置。在沒有可訪問HCI的設計中，上層測試器通過雙線的UART介面與被測裝置通訊。在任何一種情況下，藍芽規範[BTCorev4.1]都沒有為上層測試器、和被測裝置之間的通訊提供安全機制。然而，攻擊者需要將裝置(通過其中一種有線HCI類型)物理連接到被測裝置，以便能夠與後者進行互動。
第3.2.2節中描述的IPv6鏈路本地位址配置僅顯示6LBR已經從鏈路層連接已經知道的6LBR的6LN訊息。這意味著使用藍芽隱私功能的裝置在其IPv6鏈路本地位址中顯示與其裝置位址相同的訊息。在藍芽級別不使用隱私的裝置也不會在IPv6鏈路本地位址處擁有隱私。對於非鏈路本地位址，建議實現預設情況下不將藍芽裝置位址嵌入IID，而是支持如[RFC3315]、[RFC3972]、[RFC4941]、[RFC5535]、或[RFC7217]。
惡意6LN可能試圖在藍芽LE網路上執行拒絕服務攻擊，例如，通過泛洪封包。這種攻擊通過以下事實得以緩解：鏈路本地群播未在藍芽LE鏈路之間橋接，並且6LBR能夠聰明地使用藍芽LE L2CAP基於信用(credit-based)的流量控制來對每個6LN發送的封包進行速率限制機制。
沒有留言:
張貼留言