RFC4326中文文檔

當你在凝視深淵時，深淵也在凝視你。

---

VERSION : 2018/10/23 9:23:24
AUTHOR : [email protected]
NOTE : 此文檔爲依照RFC4326文檔翻譯而來。文檔中若有任何錯誤希望可以通過郵箱告知。

---

---

0 MPE 和 ULE

目前，在將 IP 數據封裝成 SNDU(Sub Network Encapsulation) 時普遍使用 MPE 方式實現。但是 MPE 在設計最初並非針對 IP 數據。在封裝和解封裝時只用到了 MPE 12字節頭部信息中的部分字段，降低了傳輸效率。同時 MPE 不支持 IPv6 協議。依次爲背景，ULE 作爲新的封裝方式在2005年被IETF提出，於同年12月成爲RFC。

1 Introduction

2 Conventions Used in This Document

3 Description

4 SNDU Format

採用 ULE 方式封裝 PDUs 得到的 SNDU(每個 SNDU 都是一個 MPEG-2 有效載荷單元 ) 格式如下：

< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* |           PDU         | CRC-32 |
+-+-------------------------------------------------------+--------+

ULE 中所有的多字節值都以網絡序傳輸，每個字節的最高有效位放置在8-bit字段的最左側。

4.1 Destination Address Abent (D) Field

D 字段， 1-bit。指示是否存在 Dest Address 字段。值爲 0 - 存在，值爲 1 - 不存在。
End Indicator 必選以 D = 1 發送。其他 SNDUs 可以以 D = 1/0 發送。默認方式以 D = 0 發送。

4.2 Length Field

長度字段， 15-bit。指示從Type後到CRC（包括）的字節數。

4.3 End Indicator

當 SNDU 後面緊隨的兩個字節爲 0XFFFF， 標識這是一個 End Indicato（即，D=1，Length=0X7FFFF）。這就向接收者指明後續沒有其他 SNDUs 出現。也沒有 Dest Address 字段。 0XFFFF 在 MPEG-2 中有特殊的語義，用於表示填充。

4.4 Type Field

類型字段，16-bit。類型字段標識 SNDU 中負載的類型，或存在 Next-Header。可以分配給該字段的值分爲兩部分，類似於以太網的分配。

EtherType 最初由 Xerox 根據Ethernet v2 Specification [DIX] 定義。 在規範 IEEE 802.3 [IEEE-802.3,ISO-8802-2] 之後，小於 1536 的 EtherTypes 充當了長度指示器的角色。以太網接收者通過這個特性來區別 LLC 幀。

當接收者接收到帶有兩個長度字段的 PDU 時，可以能會出現模棱兩可的情況，接受者需要驗證實際長度和長度字段，並確保不傳輸錯誤的值。ULE 原本只有一個長度值，避免了這樣的情況，但 LLC 幀的橋接重新引入了這樣的情況。

ULE 本身不需要識別以太網 LLC的模式，並且 ULE 總是帶有顯示的長度位，因此做了如下修改：

第一種 ULE 類型集合包含小於1536的值，這些類型字段值由 IANA 指定，並標識存在 Next-Header。

第二種 ULE 類型集合包含大於或等於1536的值，在ULE中，這個值與IANA EtherType註冊表中IEEE/DIX類型賦值所指定的對應類型代碼相同。

4.4.1 Type 1：Next-Header Type Fields

第一種 ULE 集合對應0到1535的值。這些值可用於標識特定的鏈路層協議，並且/或者指明存在攜帶附加可選協議字段的拓展頭。這些值的使用由IANA協調。本文件定義了以下類型：
 0X0000 ： Test SNDU
 0X0001 ： Bridged Frame
 0X0100 ： Extension-Padding

4.4.2 Type 2：EtherType Compatible Type Fields

第二種 ULE 集合對應 0X600(1536) 到 0XFFFF。這組值的分配遵循 DIX/IEEE 的分配（但不包括使用使用該字段作爲長度指示器）。這個集合中值的分配必須使用 IANA EtherType 定義的值。以下爲兩個例子：
 0X0800 ： IPv4 Payload
 0X86DD : IPv6 Payload

4.5 SNDU Destination Address Field

SNDU Destination Address 字段爲可選字段。當 IP 數據包使用共享鏈路路由（即，同一鏈路對應多個接收者）時，必須攜帶該字段。攜帶有結合 PID 值可以解釋爲鏈路層級地址的標識字段字段（如IPv4/IPv6de的目標地址，或橋接 MAC 地址）的 IP 單播/多播數據包可以忽略該字段。

當 SNDU 報頭指示存在 SNDU Destination Address 字段（即，D=0）時，在 ULE 頭第4字節之後存在一個 Network Point of Attachment(NPA) 字段。NPA爲6字節，通常以十六進制表示，用於在應該處理接收到的SNDU的MPEG-2傳輸網絡中識別接收方。值 0X00:00:00:00:00:00 不能用作SNDU中的目標地址。對於多播幀，地址的第一個字節的最低有效位被設置爲1，其餘字節指定鏈路層多播地址。值 0xFF:FF:FF:FF:FF:FF 是鏈接廣播地址，表示這個SNDU將被髮送到所有接收器。

攜帶IPv4子網絡廣播地址的IPv4數據包需要發送到具有相同網絡前綴的所有系統。當出現SNDU目標地址(D=0)時，該值必須設置爲NPA鏈路廣播地址(0xFF:FF:FF:FF:FF:FF)

當 PDU 是 IP 多播包且存在 SNDU 目標地址(D=0)時，多播包的 IP 組目標地址必須映射到多播 SNDU 目標地址(按照在以太網中生成目標 MAC 地址的方法)。映射 IPv4 多播地址的方法在 [RFC1112] 中指定。映射 IPv6 多播地址的方法在 [RFC2464] 中指定。

4.6 SNDU Tariller CRC

每個 SNDU 必須在 SNDU 的最後四個字節中攜帶一個32位 CRC 字段。這個位置簡化了用硬件計算 CRC 的過程。將使用 CRC-32 多項式。使用該多項式的例子還包括以太網、DSM-CC 節語法 [ISO-DSMCC] 和 AAL5 [ITU-3563]。這是一個32位的值，根據用十六進制表示的生成器多項式 0x104C11DB7 計算得到:

x^32+x26+x^23+x22+x^16+x12+x^11+x10+x^8+x7+x^5+x4+x^2+x1+x^0

封裝器將 CRC-32 累加寄存器初始化爲值 0xFFFF FFFF。然後，它爲 CRC-32 累積一個傳輸值，該值包含從 SNDU 報頭開始到 SNDU 結束的所有字節(不包括包含 CRC-32 的32爲校驗字段)，並將其放在 CRC 字段中。在 ULE 中，字節按照在 SNDU 中的位置遞增的順序進行處理;處理位的順序不會顛倒。這種用法類似於 SCTP [RFC3309]，但不同於 SCTP [RFC3309]。

接收器通過獨立計算相同的 CRC 值並將其與 SNDU 校驗字段中的傳輸值進行比較來執行完整性檢查。沒有有效 CRC 的 SNDU 被丟棄，導致接收器進入空閒狀態。

4.7 Description of SNDU Formats

SNDU 的格式由 (D) 和 SNDU 類型字段的組合決定。最簡單的封裝將 PDU 直接放入 SNDU 有效負載中。某些 Type-1 封裝可能需要額外的標頭字段。它們插入到 SNDU 中，位於 NPA 目標地址之後，並直接位於 PDU 之前。

這裏定義了以下 SNDU 格式：
 End Indicator：接收者應當進入空閒模式
 IPv4 SNDU：有效負載是 IPv4 數據報
 IPv5 SNDU：有效負載是 IPv6 數據報
 Test SNDU：有效負載將被丟棄
 Bridged SNDU：有效負載攜帶一個橋接 MAC 幀

其他格式由 IEEE 和 IANA 的相關分配定義。

4.7.1 End Indicator

格式如下，這種格式必須標識 D=1。

 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|           0x7FFF            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|															    |
=   A sequence of zero or more bytes with a value 0xFF filling  =
|           the remainder of the TS Packet Payload              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.7.2 IPv4 SNDU Encapsulate

IPv4 數據報直接使用兩個標準 SNDU 結構之一進行傳輸，其中 PDU 直接放置在 SNDU 有效負載中。這兩個封裝如下。(請注意，IP數據報的有效負載是可變大小的，後面是CRC-32)。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|        Length (15b)         |         Type = 0x0800         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Receiver Destination NPA Address (6B)              |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
=                         IPv4 datagram                         =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            (CRC-32)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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|        Length (15b)         |          Type = 0x0800        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
=                           IPv4 datagram                       =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             (CRC-32)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.7.3 IPv6 SNDU Encapsulate

IPv6數據報使用兩個標準SNDU結構之一直接傳輸，其中PDU直接放置在SNDU有效負載中。如下圖所示。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|        Length (15b)         |         Type = 0x86DD         | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Receiver Destination NPA Address (6B)              |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
=                           IPv6 datagram                       =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             (CRC-32)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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|        Length (15b)         |         Type = 0x86DD         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
=                           IPv6 datagram                       =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              (CRC-32)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5 ExtenSion headers

本節描述ULE封裝的擴展格式。在ULE中，小於1536 的類型字段值表示擴展標頭。這些值是從爲 ULE 定義的獨立 IANA 註冊表中分配的。

使用單個 Type/Next-Haeder 字段簡化了處理，並消除了維護多個 IANA 註冊中心的需要。代價是每個擴展頭至少需要2個字節。當沒有擴展出現時基於簡單的處理並維護一個簡單的輕量級頭是非常合理的。

ULE 擴展標頭由 16-bit的 Type 字段標識。該字段被組織爲5-bit零前綴、3-bit H-LEN字段和8-bit H-Type 字段，如下所示:

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN|    H-Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

H-LEN賦值描述如下:

• 0   - 標識強制拓展頭
• 1   - 標識可選的 2B 拓展頭（Type only）
• 2   - 標識可選的 4B 拓展頭（Type + 2B）
• 3   - 標識可選的 6B 拓展頭（Type + 4B）
• 4   - 標識可選的 8B 拓展頭（Type + 6B）
• 5   - 標識可選的 10B 拓展頭（Type + 8B）
• >= 6 組合的H-LEN和H-TYPE值表示直接跟隨這個類型字段的PDU的EtherType。

H-LEN 字段的值標識可選拓展頭的總字節數（包含 2B Type 字段）。

H-LEN 值爲0表示強制擴展標頭。每個強制擴展標頭都有一個預定義的長度，在H-LEN字段中沒有標識。對於強制擴展標頭的最大長度沒有附加限制。強制擴展頭可以修改所包含的PDU的格式或編碼(例如，執行加密和/或壓縮)。

H-Type 類型是一個1字節字段，它是256個強制標頭擴展或256個可選標頭擴展之一。這兩種類型的擴展頭的當前允許值集由IANA註冊中心定義(第15節)。可選擴展的註冊表值以H=1(即十進制 256-511)，但可與範圍1-5的H-Length值一起使用。（這句話我看的不是很明白，看懂的麻煩幫我解釋下。。。）

擴展頭的兩個示例是 Test SNDU 和使用 Extension-Padding。Test SNDU 強制擴展標頭會導致整個PDU被丟棄。Extension-Padding 可選拓展頭會導致隨後(如果有的話)選項標頭被忽略(例如:，共H-LEN 16-bit 字)。

帶有擴展頭的 SNDU 的一般格式是:

< --------------------------   SNDU   ------------------------- >
+---+--------------------------------------------------+--------+
|D=0| Length | T1 | NPA Address | H1 | T2 |    PDU     | CRC-32 |
+---+--------------------------------------------------+--------+
< ULE base header >             < ext 1 >
攜帶一個拓展頭的 SNDU 封裝格式（D=0）

其中：

• D ： ULE D_bit(在本例中D=0; 在使用擴展標題時，NPA地址也可以省略)。
• T1： 基本頭 Type 字段。在本示例中，標識 Next-Header。
• H1： 是爲頭 Type T1 定義的字段集。對於特定的 ULE 擴展頭，可能有0或更多字節的信息.
• T2： 是 Next-Header 的 Type 字段，或是 PDU 攜帶的值大於1536的EtherType。

< --------------------------    SNDU   ------------------------- >
+---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 |      PDU        | CRC-32 |
+---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 >
攜帶兩個拓展頭的 SNDU 封裝格式（D=1）

使用這種方法，可以將多個擴展頭串聯起來。上圖顯示了包含兩個擴展頭的 SNDU。在本例中， T1 和 T2 的值都小於 1536 小數。每個都表示存在擴展標頭，而不是直接跟隨 PDU。T3 的值> 1535指 示所攜帶的 PDU 的醚型。雖然 SNDU 可能包含任意數量的連續擴展標頭，但 SNDU 通常不會攜帶大量擴展。

5.1 Test SNDU

Test SNDU 是 Type-1 的一種強制擴展頭。這個報頭必須是 SNDU 報頭鏈中指定的最終(或唯一)擴展報頭。這個 SNDU 的數據部分的結構不是由這個文檔定義的。接收方可以在日誌文件中記錄接收情況，但必須丟棄所有 Test SNDU。D-bit 可以在 Test SNDU 中設置。

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|        Length (15b)         |         Type = 0x0000         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
=              Data (not forwarded by a Receiver)               =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            (CRC-32)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2 Bridged Frame SNDU Encapsulate

橋接 SNDU 是 Type-1 的一種強制拓展頭。這個報頭必須是 SNDU 報頭鏈中指定的最終(或唯一)擴展報頭。有效負載包括 MAC 地址和 EtherType [DIX] 或 LLC Length [ISO-8802-2] 字段以及橋接 MAC 幀的內容。

當指定 NPA 地址(D=0)時，接收方必須丟棄所有攜帶 NPA 目標地址(或廣播/多播地址)不匹配接收方 NPA 地址的 SNDU; SNDU 的負載由隨後的橋接規則處理。沒有 NPA 地址的 SNDU (D=1) 會導致接收端對所有接收到的 SNDU 負載按照橋接規則進行處理。

封裝器還可以使用這種封裝格式直接傳輸需要 LLC 封裝的網絡協議包 [IEEE-802.2, ISO-8802-2]。爲此，它構造了一個 SNDU，它有一個橋接擴展頭，其中包含預期的目標 MAC 地址、封裝器的 MAC 源地址和 LLC-Length。PDU 包括一個 LLC 頭，後面跟着所需的有效載荷。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|        Length (15b)         |         Type = 0x0001         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Receiver Destination NPA Address (6B)              |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                 MAC Destination Address (6B)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     MAC Source Address (6B)                   |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |    EtherType/LLC-Length (2B)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
=                 (Contents of bridged MAC frame)               =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            (CRC-32)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
橋接有效載荷的 SNDU 格式（D=0）

 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|        Length (15b)         |         Type = 0x0001         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   MAC Destination Address (6B)                |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                     MAC Source Address (6B)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   EtherType/LLC-Length (2B)   |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
=                     (Contents of bridged MAC frame)           =
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           (CRC-32)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
橋接有效載荷的 SNDU 格式（D=1）

EtherType/LLC-Length 字段根據 IEEE 802.3 [IEEE-802.2] 定義。

在這種特殊情況下，強制擴展標頭格式可以解釋爲 EtherType [DIX] 或 LLC Length 字段(由IEEE 802 [IEEE-802.3]指定)，而不是 IANA 維護的 ULE Next-Header 註冊表中分配的值。

被橋接的幀中的 MAC 地址應該按照 IEEE 指定的規則進行分配，並表示未知、單播、廣播和多播鏈路地址。這些 MAC 地址表示目標 LAN 中的預期收件人，因此具有與 SNDU 報頭中攜帶的NPA 地址不同的功能。

對於橋接幀，幀的 Type< 1536時引入了 LLC-Length 字段。接收機必須檢查這個長度並丟棄任何長度大於 SNDU 有效載荷大小允許的幀。

在正常操作中，希望在轉發之前刪除附加到以太網幀的任何填充。這要求發送方知道這種以太網填充(例如，[DIX, IEEE-802.3])。

在封裝器上接收的用於在ULE上繼續傳輸的以太網幀攜帶局域網幀檢查序列(LAN-FCS)字段（例如，用於以太網的CRC-32 [DIX, IEEE-802.3]）。

在進一步處理之前，封裝器必須檢查收到的所有幀的 LAN-FCS 值。用無效的 LAN-FCS 接收的幀必須丟棄。檢查後，LAN-FCS 被刪除(即，它不在橋接 SNDU 中轉發)。與其他 ULE 幀一樣，封裝器將 CRC-32 附加到傳輸 SNDU 。在接收端，一個合適的 LAN-FCS 字段將被附加到橋接幀，然後在以太網接口上繼續傳輸。

這種設計可以很容易地使用現有的網絡接口卡實現，並且避免引入由於計算/校驗兩次橋接幀的完整檢驗而增加的效率成本。然而，它也引入了這樣一種可能性，即在封裝器和/或接收器上執行的處理中損壞的幀可能不會被最終的接收者檢測到。這樣的損壞通常不會導致無效的LAN-FCS)。

5.3 Extension-Padding Optional Extension Header

Extension-Padding 可選拓展頭由 IANA 分配的 H-Type = 0X100 標識。與其他可選擴展一樣，擴展的總長度由H-LEN字段表示(用16位字表示)。擴展字段由一組16位字段組成。

對於這個特定的選項，只有最後一個16位的字有指定的值;發送方應該將剩下的值設置 0x0000。最後一個16位字段形成下一個標題 Type 字段。接收器必須解釋類型字段，但必須忽略此擴展標頭的任何其他字段。

6 Processing at the Encapsulation

6.1 SNDU Encapsulation

6.2 Procedure for Padding and Packing

7 Receiver processing

7.1 Idle State

7.1.1 Idle State Payload Pointer Checking

7.2 Processing of a Received SNDU

7.2.1 Reassembly Payload Pointer Check

7.3 Other Error Conditions

8 Summary

9 Acknowledgements

10 Security Considerations

11 IANA Considerations

11.1 IANA Guidelines

12 References

12.1 Normative References

12.2 Informative References

Appendix A SNDU Packing Examples

Appendix B SNDU Encapsulation