IPv6 封包结构

作者：
一个IPv6封包包含一个IPv6 header、 零到多个Extension Headers（扩充表头）以及一个upper-layer protocol data unit（上层通讯协议数据单元）。 请注意： IPv6封包的payload（承载数据）是由 Extension Headers及Upper-Layer Protocol Data Unit组成。最大长度为65,535 bytes。





 n   IPv6 Header  永远存在且固定长度40 bytes。
n   Extension Header  零到多个扩展表头，并且长度是可变动的。IPv6表头中的Next Header字段表示下一个扩展表头的类型。在每个扩展表头中还有另一个Next Header字段，用来表示下一个扩展表头的类型。最后一个扩展表头的Next Header字段表示上层通讯协议类型或为No next header(59)（当上层数据不存在时）。
n   Upper-Layer Protocol Data Unit  上层数据，例如ICMPv6、UDP或TCP。


IPv6 Header

IPv6是IPv4 更有效率的版本。它删除了IPv4所有不必要的字段，并且把IPv4表头不常使用的字段移到扩展表头。因为精简了需要处理的字段，router能更有效率地处理IPv6 Header并转送封包，进而支持更佳的real-time服务。






Version  4-bit长度，版本编号，固定设为6。
Traffic Class  字段大小为8 bits。用来识别IPv6封包的类别或优先等级。
Flow Label  20-bit长度，指定此封包属于来源和目的之间的一组特定的封包。 要求中间IPv6 router进行特殊处理。Flow Label的详细应用请参考RFC 3697 “IPv6 Flow Label Specification”。
Payload Length  指定IP payload (即扩展表头以及上层数据) 长度。该字段大小为16 bits，最大可代表65,535的承载长度。
Next Header  8-bit长度，指定紧接在IP header后头的header类型，即IPv6 Extension Header或上层PDU（如 TCP、UDP 或 ICMPv6）。
Hop Limit  指定在丢弃IPv6封包前可传送的最大连结数。 该字段大小为8 bits。Hop Limit 与IPv4 TTL字段相似。每经过一个router就会将Hop Limit域值减1，当Hop Limit等于0时，封包将被router丢弃。
Source Address  来源地址，即发送IPv6封包的node地址。 该字段大小为128 bits。
Destination address  目的地址，即接收IPv6封包的node地址。该字段大小为128 bits。
Next Header域值

Value（Decimal）
Header
0
Hop-by-Hop Options header
6
TCP
17
UDP
41
Encapsulated IPv6 header
43
Routing header
44
Fragment header
50
Encapsulating Security Payload header
51
Authentication header
58
ICMPv6
59
No next header
60
Destination Options header
135
Mobility header (RFC 6275)
值得注意的是： No next header并未被指定为零，反而Hop-by-Hop Options header被指定为零。主要原因是router除了处理IPv6 header以外，第一个可能需要额外处理的Extension Headers为Hop-by-Hop Options header。 因此，当Hop-by-Hop Options header出现时，它必须摆在第一个扩展表头。 Router必须检查IPv6 header的Next Header域值是否为Hop-by-Hop Options header再决定是否对extension header做进一步处理，否则直接转送封包。对硬件而言，检测数字0要比检测其它非零数字快速。此细微的设计考虑是为了尽可能降低router的处理时间，提供更好的real-time traffic。

注
以下是目前造成IPv4传送封包延迟的主因：
u  传送距离的延迟  距离长度带来的延迟，这是物理特性，不可改变。电子流以及电子波都是以光速来传送。最远距离为地球2分之一的圆周长度，故传送距离的最大延迟时间为：(40000/2) / 300000 x 1000 = 66.6666 ms。
u  传送数据的延迟  如果以100 M bits为整个传送路径的每个路段的平均传送带宽，平均每秒传送2M bits数据量来计算，其延迟时间为：2 / 100 x 1000 = 20 ms。当平均传送带宽达到1G bits，其平均延迟可以降到2 ms。假设整个传送路径经过N个路段，则传送数据的延迟为2 x N ms。
u  Router的转送延迟  很明显地，目前IPv4封包的传送延迟最大的主因是routers转送封包时造成的。保守估计，其平均延迟时间可能超过10 ms 乘以“整个路径转送的router数”。
造成router转送延迟的主因有二：
l   其一是IPv4主干router的路由表往往超过70000笔,造成router在寻找next-hop的沉重负。然而IPv6的多层的阶层式路由架构除了大大降低路由表数,且可以保障最短路径。
l   其二是IPv4 header中许多字段造成router额外处理时间。譬如 ： checksum，optional fields等。IPv6已经将这些不必要的字段删除或者移至扩展表头。




















IPv6 Extension Headers（扩展表头）

在IPv6中，属于选项的internet-layer讯息依据其功能分别定义在不同的表头。这些表头被称为IPv6 扩展表头， 并且被放置在IPv6表头及上层数据表头之间。
RFC 2460定义所有IPv6 nodes必须支持以下IPv6扩展表头：
-              Hop-by-Hop Option Header
-              Destination Options Header
-              Routing Header
-              Fragment Header
-              Authentication Header
-              Encapsulating Security Payload Header
一般的IPv6数据封包中，不包含扩展表头。除非有特别需要router或者destination进行处理的讯息，封包发送端才会加入一个或多个扩展表头。
每个扩展表头必须以 64 bits (8 bytes) 为界。扩展表头大小不等，它包含一个 Header Extension Length 字段，需要时必须使用padding，以确保扩展表头的大小为 8 bytes的整倍数。
IPv6 header以及所有的扩展表头都包含 Next Header字段，Next Header指明下一个相邻的扩展表头的类型，直到连结到上层通讯协议（TCP，UDP，ICMPv6）为止。
IPv6 Header
Next Header = TCP (6)
TCP Header
Data

IPv6 Header
Next Header = Routing (43)
Routing Header
Next Header = TCP (6)
TCP Header
Data

IPv6 Header
Next Header = Routing (43)
Routing Header
Next Header = Fragment (44)
Fragment Header
Next Header = TCP (6)
TCP Header
Data

IPv6 Header
Next Header = Routing (43)
Routing Header
Next Header = AH (5)
Authentication Header
Next Header = TCP (6)
TCP Header
Data
Hop-by- Hop Options header是整个封包传送路径中routers必须检测且处理的数据，其它的扩展表头则属于封包最终接收端需要处理的讯息，跟router无关。为了避免浪费router不必要的处理时间，当Hop-by- Hop Options header出现时，它必须放在IPv6 Header的后面第一个扩展表头位置。
IPv6 Header
Next Header = Hop-by-Hop (0)
Hop-by-Hop Header
Next Header = ….
…………………………..


扩展表头顺序

扩展表头是依照排列顺序依序处理，且每个扩展表头的内容决定是否继续处理下一个Header。因此，IPv6封包的扩展表头必须遵循一定的次序排列才能被有效地处理。除了Hop-by-Hop Header出现时必须放在第一个位置，当1个以上的扩展表头同时存在一个IPv6封包时，RFC 2460建议其顺序如下：

IPv6 header
Hop-by-Hop Options header
Destination Options header
Routing header
Fragment header
Authentication header
Encapsulating Security Payload header
Destination Options header
upper-layer header

注
u  Destination Options Header用于目的节点需要额外处理的封包选项讯息，目的node可能是中间目的主机（即routers）或者最终目的主机。因此Destination Options header可能出现2次，第一个乃router需要额外处理的讯息，第二个为最终目的主机需要处理的讯息。
u  Routing header可能被routers或最终目的主机参考，故摆在Fragment header的前端。
u  Authentication header用来保障整个IP封包的完整性，防止被破坏篡改。
u  ESP header除了可加密最终目的主机需要处理的信息，亦可用来保障整个IP封包的完整性。
u  最后4项扩展表头皆属于最终目的主机处理的信息，与router无关，故摆在Fragment header的后头。对于利用AH或者ESP header加密保护的封包，发送端加完密后发现封包过长才将此封包切段后再发送，而接收端必须将这些切段后的片段封包重组后才做解密动作。因此Fragment header必须摆在AH以及ESP header的前端。
当其他新的扩展表头被定义时，它们相对于上面列出的扩展表头的顺序及限制必须被明确指定。


Options（选项）

当前已定义的Extension headers中，Hop-by-Hop Options header和Destination Options Header的名称里面皆包含“options”字眼，意味着这2种Extension headers都会携带1到多个options。
每个option均使用 Type-Length-Value (TLV) 格式进行编码。
Option type  8-bit长度，用来识别该option的类型。
Option Data Length  8-bit长度，指定了该option data的长度。
Option Data  变动长度字段，与该option有关的数据。
在Option Type字段中，最高序位的2 bits用来表示如何处理无法识别的option type。（当node不支持某些options，或者有新的options发布时，此2 bits的功用就派上用场了！）
Value(binary)
Action Taken
00
略过这个option，继续处理这个封包的其它字段。
01
不做任何动作，仅将封包丢弃。
10
丢弃封包，并且当这封包的IPv6 header的Destination Address域值是unicast or multicast地址时，发送一个ICMPv6 Parameter Problem message给此封包的发送者。
11
丢弃封包，并且当这封包的IPv6 header的Destination Address域值不是multicast地址时，发送一个ICMPv6 Parameter Problem message给此封包的发送者。
Option Type字段中的第3高位表示： 在到达目的地的路径中，这个option数据内容可被更改（=1）或者不可被更改（=0）。
每个option可能有特定的对齐要求，以确保该option的option data字段落在特定的边界。对齐的表示法为 xn+y，这意味着该option type字段必须落在x bytes的整倍数加上y。例如：
2n代表option必须落在2 bytes的整倍数边界。
8n+2代表option必须落在8 bytes的整倍数加2的边界。
这种对齐要求主要是因为大多数的处理器在做算数或逻辑运算时有个限制： 当执行N bytes（N可能是2，4 或8）的运算时，运算的数据必须落在N的整倍数边界，否则处理器将发生异常。
由于option type及option data length字段共占了2 bytes，当 xn+y 的x大于2时，y值大都是等于x-2。
RFC 2460特别定义了Pad1 option及PadN option，用来调整需要对齐的option位移。
RFC 2460、2675 和 2711 定义以下options：
Pad1 option


 对齐要求：无
Option Type 为 0，用于填满单一字节。
PadN option



 对齐要求：无
Option Type为 1，用于填满 2 个或更多bytes。

Jumbo Payload option


   对齐要求：4n+2
Option Type 为 194，用于指定大于 65,535 bytes的 payload 的大小。使用 Jumbo Payload option，必须把IPv6 header的Payload Length字段设为0（即： 当IPv6 header的Payload Length字段为0时，表示存在Jumbo Payload option），可使用 32 bytes Jumbo Payload Length 字段指定最多 4,294,967,295 bytes的 payload 大小。 Payload 大于 65,535 bytes的 IPv6 封包称为 jumbogram，此乃为了未来的link MTU有可能大于 65,575而定义的option（65535 + IPv6 header长度 40 bytes = 65575）。
Jumbo Payload option仅适用于Hop-by-Hop options扩展表头。 带有此option的封包不可做分段处理（不可包含Fragment扩展表头）。

Router Alert option
  对齐要求：2n+0
Option Type 为 5，它告知router封包的内容还需要进一步处理。Router Alert Option用于 Multicast Listener Discovery 和 Resource ReServation Protocol (RSVP)。
RFC 2711定义了 Router Alert option的Data字段的内容如下：
0                  Datagram contains a Multicast Listener Discovery message
1                 Datagram contains RSVP message
2                  Datagram contains an Active Networks message
3-65535      Reserved to IANA for future use
Router Alert option仅适用于Hop-by-Hop options扩展表头，且仅被router检查处理，hosts忽略此option。

Hop-by-Hop Options Header

Hop-by-Hop Options header用于指定传送参数到目的地路径上每个router，它告知router必须对封包的内容做进一步处理。在IPv6 标头 Next Header 字段中的值设为 0 来识别。





 Next Header  8-bit长度，用来识别下一个表头的类型。
Header Extension Length  8-bit长度。Hop-by-Hop Options表头中8字节区块的数量，不包括第1个8字节。 因此，长度为8字节 Hop-by-Hop Options 表头，Header Extension Length 字段的值为 0。填满选项用于确保 8 字节边界。
Options  可能引用的options： Pad1，PadN，Router Alert和Jumbo Payload options。

Destination Options Header

Destination Options Header用于目的节点需要额外处理的封包选项讯息，目的节点可能是中间目的主机（即routers）或者最后目的主机。可在上一个表头的 Next Header 字段中将值设为60来识别此表头。
Destination Options 表头中字段的定义与 Hop-by-Hop Options 表头相同。
可能引用的options： Pad1，PadN和Home Address option。
Destination Options 表头有两种使用方式：
1.       如果存在 Routing 表头，则指定每个中间目主机需要额外处理的选项讯息。
2.       也指定最终目的主机额外处理的选项讯息。
注
1.       目前Destination Option header没有针对router的的实际应用。
2.       Mobile IPv6定义Home Address option，是针对封包最后目的主机的选项讯息的实际应用。在Mobile IPv6章节中会有详细描述。


Routing Header


与 IPv4 支持的Loose Source and Record Route option相似，IPv6 封包发送端可以使用 Routing 扩充表头指定路由，它列出封包通往目的地的路径上必须 “拜访”的中间目的主机的列表。可在上一个表头的Next Header字段中将值设为43来识别 Routing 表头。



Next Header  定义方法与 Hop-by-Hop Options 扩充表头相同。
Header Extension Length  定义方法与 Hop-by-Hop Options 扩充表头相同。
Routing Type  用来识别routing的类型。
Segments Left  “路段”的剩余数（Routing Header的路由列表中，中间主机到下一个中间主机之间的路径称为1个“路段”）。也就是说，封包到达目的地前还没经过的路段数。
Routing Type-Specific Data  变动长度的字段。此字段的路由格式由Routing Type字段来决定。
注
由于Routing type 0已经被RFC 5095封杀，目前Routing Header没有针对router的应用。
Mobile IPv6 定义一个新型的routing header，称为type 2 routing header，是IPv6对最终目的主机的实际应用。在Mobile IPv6章节中会有详细描述。

RFC 2460中定义了Type为 0的Routing header。虽然基于网络安全理由，Routing type 0已经被RFC 5095封杀，笔者还是认为有必要了解其设计技巧。

Type 0 Routing header的格式如下：











Routing Type-Specific Data列着一系列中间目的地址，这个列表指定封包送达最终目的地前必须依序访问到的中间目的主机（其实就是router），同时封包发送者会先将封包传送到列表里的第一个中间目的主机。 当IPv6 封包到达中间目的主机时，Routing 表头会经过处理。中间目的主机根据 Segments Left 域值找到下一个中间目的主机在Routing Type-Specific Data中对应的字段位置，并将下一个中间目的主机的地址填入IPv6 标头中的目的地址，再把自己的地址填入Routing Type-Specific Data，然后把Segments Left 字段减1，接着继续转送封包。此时封包的IPv6 标头中的目的地址已经改成下一个中间目的主机，封包肯定如预期的转送到下一个中间目的主机。除了指定的中间目的主机以外，整个路径会经过哪些其它的routers就不在考虑范围内。
《Routing type 0的应用例子》
假设： 来源node S欲发送封包给目的node D，并且利用Routing type为0的Routing Header，指定封包送达目的地D前必须依序访问的中间目的主机分别为I1，I2及I3。在传送封包的每个路段时的设定值将如下：
路段 S à I1:
IP Header
Routing Header
Source Address = S
Destination Address = I1
Hdr Ext Len = 6
Segments Left = 3
Address[1] = I2
Address[2] = I3
Address[3] = D
路段 I1 à I2:
IP Header
Routing Header
Source Address = S
Destination Address = I2
Hdr Ext Len = 6
Segments Left = 2
Address[1] = I1
Address[2] = I3
Address[3] = D
路段 I2 à I3:
IP Header
Routing Header
Source Address = S
Destination Address = I3
Hdr Ext Len = 6
Segments Left = 1
Address[1] = I1
Address[2] = I2
Address[3] = D
路段 I3 à D:
IP Header
Routing Header
Source Address = S
Destination Address = D
Hdr Ext Len = 6
Segments Left = 0
Address[1] = I1
Address[2] = I2
Address[3] = I3


Fragment Header

在IPv6中，只有来源node可对payload 进行分段。 当发送的封包大于path MTU时，则必须用Fragment Header对封包做分段处理后，再一个个发送分段好的片段封包。最后由目的node将所有片段封包重组成原始封包。可在上一个Header的 Next Header 字段中将值设为 44 来识别此Header。
   Next Header  用来识别下一个表头的类型。
Fragment Offset  长度13 bits，8 bytes为单位。片段位移：相对于分段前的原始封包的可分段部分的开始位置。
More Fragments  值为1代表此分段后还有分段。值为0代表此分段为最后一个分段。
Identification  32-bit长度，当有大封包需要做分段处理时，发送端会对每个需要分段的原始封包产生不同的识别值，并且把这个识别值填入每个分段好后的片段封包的Identification字段。Identification字段主要是便于目的节点区别并重组不同的片段封包成为原始封包，然后再做进一步的处理。

IPv6 Fragmentation Process 封包切割处理

在将 IPv6 封包分段前，先将它分成不可分段部分和可分段部分：
l  不可分段部分  由于此分段部分为每个router必须处理的部分，即使做了分段，每个分段后的封包必须重复包含此部分。它包含IPv6表头、Hop-by-Hop Options表头、中间目的的 Destination Options表头以及 Routing表头组成。
l  可分段部分  此分段部分包含仅被最终目的节点处理的扩展表头及上层 PDU。
分段后的片段封包由以下部分组成：
（1）  不可分段部分  IPv6表头的Payload Length域值须设为此片段封包的承载长度。由于分段后加入了Fragment扩展表头，不可分段部分的最后一个扩展表头的Next Header字段须设为Fragment扩展表头的识别值44。请注意，由于做分段时不可分段部分的最后一个扩展表头的Next Header字段已经被更改，所以重组片段成原始封包时必须回复这个域值。
（2）  Fragment Header  它的内容如下：
-     Next Header字段设为原始封包的可分段部分的第一个扩展表头的识别值。当目的节点将片段封包重组成原始封包时，此字段用来回复不可分段部分的最后一个扩展表头的Next Header的原始设定值。
-     Fragment Offset字段设为位移值（8 bytes为单位）: 相对于原始封包的可分段部分的开始位置。
-     如果此片段为最后一个，则M flag字段设为0。其它片段则设M flag字段为1。
-     设定Identification字段。

（3）       原始封包可分段部分被分段后的部分










范例：原始封包切分成2个片段封包。
原始封包
IPv6 Header
Next Header = TCP (6)
TCP Header
Data
分段后的封包
IPv6 Header
Next Header = Fragment (44)
Fragment Header
Next Header = TCP (6)
TCP Header
Data 分段1

IPv6 Header
Next Header = Fragment (44)
Fragment Header
Next Header = TCP (6)
TCP Header
Data 分段2

IPv6 Reassembly Process 封包重组处理
-       目的节点利用相同的来源地址、目的地址和Fragment Header的Identification的片段封包重组成原始封包。
-       用第1个片段的Fragment Header的Next Header域值来回复原始封包的不可分段部分的最后一个扩展表头的Next Header的原始设定值。
-       利用不可分段部分的长度，及最后1个片段的长度和Fragment Offset，可以计算出原始封包的承载长度。计算公式如下：
原始封包的承载长度 = PL.first - FL.first - 8 + (8 * FO.last) + FL.last
PL.first：第1个片段的承载长度
FL.first：第1个片段的分段长度。即Fragment Header后的所有数据长度。
FO.last：最后1个片段的Fragment Header的Fragment Offset域值。

FL.last：最后1个片段的分段长度。














参考文献

RFC 2460  IPv6 Specification
RFC 2675  IPv6 Jumbograms
RFC 2711  IPv6 Router Alert Option
RFC 4302  IP Authentication Header
RFC 4303  IP Encapsulating Security Payload (ESP)
RFC 1981  Path MTU Discovery for IPv6

评论

发表评论

此博客中的热门博文

DHCPv6 简介

作者：
Dynamic Host Configuration Protocol for IPv6 （简称 DHCPv6 ）可以使 DHCPv6 server 传递配置参数（例如 IPv6 地址）给 IPv6 nodes 。 DHCPv6 提供了可重复使用 IPv6 地址和附加参数自动配置的灵活性能力。相对于“ IPv6 Stateless Address Autoconfiguration ” (RFC 2462) ， DHCPv6 是一种 stateful address autoconfiguration 。两者各自独立运作，也可以同时使用来自动配置参数。 透过 DHCPv6 server ， DHCPv6 可以提供 nodes 自动分配 IP 地址以及其它参数，每个配置参数都是利用 option 方式来传递。 DHCP 可以透过新定义的 option 来扩展配置新的参数。 DHCPv6 概述 协议操作以及使用的地址 u   DHCPv6 属于应用层（ Application Layer ）通讯协议，使用 UDP （ Transport Layer ）来交换 messages 。需要透过 DHCPv6 protocol 来获取 IP 地址或其它参数的 node 会以 client 的角色来向 DHCPv6 server 发出请求，而 DHCPv6 server 会依据 client 的相关讯息以及 server 自定的相关决策来配置 client 适当的参数值。 Client 使用 link-local 地址或其它地址来收送 DHCP messages 。 Server 使用保留的 link-scope multicast addres 即 All_DHCP_Relay_Agents_and_Servers  multicast address (ff02::1:2) 来接收 clients 发送的 messages ， client 几乎都是使用此 multicast address 来发送 messages ， 所以不需要另外配置 server 的 IP 地址。 u   为了能允许 client 发送 DHCP messages 到不在同一个 li...
阅读全文

IPv6 簡介以及地址介紹

作者：
IPv6 简介 I Pv6 （ IP 版本 6 ）是互联网通讯协议（ Internet Protocol ，简称 IP ）的新版本，它被设计来取代 IPv4 ，并且针对当初设计 IPv4 时没有考虑到的问题做了以下改进： n   扩展地址空间   IPv6 将 IP 地址长度从 32 bits 扩展到 128 bits ，如此庞大的地址空间，除了确保 IP 地址不再有耗尽之虑，其主要目的是支持更多层的阶层式的路由架构，并且提供更简单的自动组态配置。在 multicast address 中新增“ scope ”字段来提升 multicast routing 的可扩展性。定义一个新的地址类型称为“ anycast address ”，用来发送封包到一个接收群组中路由最近的一个 node 。 n   简化 IP 表头格式   IPv6 删除了 IPv4 表头中不必要的字段，并且将选项字段移到扩展表头，降低 router 转送 IP 封包的处理时间。 n   支持更佳的扩充性   更改 IP 表头的某些选项， 使得 router 转送封包更有效率，并且提供未来更大的灵活度来引入新的选项或新的扩展表头。 n   提供更好的 QoS   在 IP 表头添加新的标签字段称为“ Flow Label ”，让封包发送者能要求特殊的流量处理，譬如 real-time 服务。 n   认证和保密功能   支持认证、数据完整性及保密性。 须知， IPv6 除了将完全取代 IPv4 以外，由于 IP 层版本的替换过程相当冗长艰巨，其设计者更希望 IPv6 是 IP 层的终极版本，未来不用再面临更换 IP 层版本的难题。至于 IPv6 是否能经得起考验，成为 IP 层的终极版本，只能有赖时间来证明。 专有术语 Address  地址，用来标示一个或一组 interfaces 。 Host （本机） 非 router 的 nodes 皆称为 host 。 Immediate Router  封包送达目的地所经过的 routers 。 Interface  node 连接到 link 的...
阅读全文

Neighbor Discovery 简介

作者：
IPv6 Neighbor Discovery （简称 ND ）提供机制来解决邻近 nodes 之间相互作用的下列问题： Router Discovery   Hosts 如何查寻到连接在 link 上的 router ？ Prefix Discovery   Hosts 如何得知哪些 prefix 是属于 link 上可直接传送的地址？（ Nodes 利用 prefix 是否为 on-link 来决定直接传送封包或透过 router 传送封包到目的地。） Parameter Discovery   Nodes 如何得悉 link 的相关参数（例如： link MTU ）或者 internet 参数（例如： Hop Limit 值）。 Address Autoconfiguration   提供机制来允许 hosts 对每个 interface 自动配置参数。例如： IPv6 地址、 on-link prefix 和 link MTU 等。 Address resolution   如何从邻近 nodes 的 IPv6 地址解析到其 link 层地址。 Next-hop determination   如何将欲传送的封包的目的地对应到 next-hop 地址？   对于非邻近（ off-link ）目的地址， Next-hop 地址是 router 的地址。对于邻近的（ on-link ）目的地址， next-hop 地址就是目的地址本身。 Neighbor Unreachability Detection   如何侦测邻近的 nodes 的可达性？对于不可达的 nodes ，可尝试用地址解析机制来确认是否还可达。此外，如果 link 上有 2 个以上的 routers ，还可以透过更换 default router 来解决邻近 router 不可达问题。 Duplicate Address Detection   node 如何确定它欲使用的地址是否已经被邻近的其它 node 使用了？ ( 可避免地址冲突 ) Redirect （重新导向 ）   当...
阅读全文

Multicast Listener Discovery (MLD) 简介

作者：
Multicast Listener Discovery （简称 MLD ）是从 IGMPv2 （ Internet Group Management Protocol version 2 ）衍生而来，目的是让 IPv6 router 有能力发现每个连接的 link 上的 multicast listener （聆听者），并且具体知道这些 listener 感兴趣的是哪些 multicast 地址，同时在每个 link 上建立个别的 multicast 列表。只要 multicast 列表发生变化， router 就会透过 Multicast Routing Protocol 与其它邻近的 routers 交换这些讯息，以确保 multicast 封包能适当地传送（或阻断）到 multicast listeners 连接的 link 。（ Multicast Routing Protocol 不在本书的讨论范围内。） 《请注意》 Router 只需要知道 link 上哪些 multicast address 有 listener ，不需要知道 listener 的身份地址，也不需要知道有多少 listeners 。 MLD 是一个非对称的协议，它分别指定 multicast router 及 multicast listeners 个别的行为。 当 router 也扮演 listener 角色时， router 会同时执行协议的两个部分，包括自己两个角色间的讯息交换。 如果一个 router 有多个 interfaces 连接到同一个 link ，则只需要其中一个 interface 扮演 MLD 的 router 角色。另一方面，如果 listener 有多个 interfaces 连接到同一个 link ，则每个 interface 都必须扮演 MLD 的 listener 角色。 注 《须知》 每个 listener 可能落在 internet 上任何位置， multicast 封包的 listeners 越...
阅读全文

MLDv2 简介

作者：
MLDv2 乃从 IGMPv3 衍生而来，可兼容 MLDv1 。 MLDv2 涵盖 MLDv1 既有功能，除了指定欲聆听的 multicast 地址以外，并且增加 source list （来源地址列表）以及 filter mode 可过滤 multicast 封包的来源地址。 Filter mode 可设为 INCLUDE 或 EXCLUDE ，分别与 source list 组合形成白名单或者黑名单。白名单只接收 source list 中所指定的来源封包，其它都不接收。黑名单则除了不接收 source list 中所指定的来源封包，其它都接收。 MLDv2 协议概述 MLDv2 使 router 能够查询每个 link 上有哪些 multicast 封包和来源地址有 listener ，并且保持每个 multicast address 的 Listening state 。再透过 Multicast Routing Protocol ，与邻近的其它 routers 交换这些讯息，以确保 multicast 封包能适当地传送（或实时阻断）到所有 multicast listeners 连接的网段。 本章节不赘述 MLDv2 与 MLDv1 相同的部分。主要着重于如何建立及处理 Multicast Address Listening state ： u   Listeners 如何建立 Listening state u   Querier 和 Listeners 如何交换 MLDv2 讯息 u   Routers 如何处理 Listener 发送的 report 以及建立 Listener state Listeners 如何建立 Listening State n   Listeners 系统中运行的应用程序透过特定的 service calls ，要求 IP 层接收或者停止接收指定的 multicast 封包。随着应用程序呼叫 service call ，会产生并且保持个别的 socket Listening state 。同时， Listener 必须依据每个 interface 的所有 socket Listening state ，计算并且保持个别的 interf...
阅读全文

Mobile IPv6 简介

作者：
《前言》 应用层以及 TCP （ Transmission Control Protocol ）在建立联机后，必须始终使用原有的 IP 来源地址才可以保持既有的联机。只要 node 的 IP 地址发生变更，则必须重新建立联机。由于行动装置具有自由移动的特性，导致其 IP 地址在移动中可能跟着发生变化。为了让移动装置即使其 IP 发生变化，也能够保持既有的联机， RFC 6275 “ Mobility Support in IPv6 ”定义新的通信协议以及一些新的 options 来达到此目标。凡支援 Mobile IPv6 的 node 称为 Mobile Node 。 Mobile IPv6 protocol 允许 Mobile Node （简称 MN ）在 internet 上移动时仍保持既有的通信联机以及 MN 的可达性（ MN 可随时与其它 node 建立新联机，反之亦然。）。 不论 MN 因移动而切换连接到其它任何 link ， MN 总是以它的 home address 为识别的 unicast 地址。当 MN 远离 home link 时，新连接的 link 所配置到的 IPv6 地址称为 care-of address （转交地址）。藉由 care-of address 来转交封包， MN 能始终以 home address 的身份维持通信。当 MN 从 home link 切换到别的 link 或从别的 link 切换到另一个 link 时， 就会将目前连接的 link 所配置到的 care-of address 以及其 home address 向 home agent 登记，此登记动作称为 home registration 。此时， Home agent 将代理 MN 的 home address 角色，同时与 MN 登记的 care-of address 互相建立 tunnel 。此后，任何目的地址为 MN 的 home address 的封包将被 home agent 拦截，且透过 tunneling 机制转送到 MN 的 care-of address 。同样地，透过 tunneling 机制， MN 发送的封包皆藉由 home agent 来转送。当 MN 从别的 link 切换到 home link 时，也会向 h...
阅读全文

ICMPv6

作者：
IPv6 使用 Internet Control Message Protocol （简称 ICMP ），稍作一些改变，称为 ICMPv6 。 IPv6 nodes 利用 ICMPv6 来报告处理封包时遇到的错误，也可执行其它 internet 层功能，如诊断功能“ ping ”。 ICMPv6 属于 IPv6 的一部分，每个 IPv6 node 必须支持 ICMPv6 。 ICMPv6 message 有 2 种类型： l    Error messages （错误讯息）   用于报告目的 node 或中间 router 传送封包时遇到的错误。 ICMPv6 错误讯息包括 Destination Unreachable 、 Packet Too Big 、 Time Exceed 和 Parameter Problem 。 l    Informational messages （信息讯息）   用于提供诊断功能以及其它功能 （例如 MLD 、 MLDv2 及 Neighbor Discovery ）。诊断功能包括 Echo Request 和 Echo Reply 。 注 ICMP 是为了弥补 IP 层某些功能上的不足而特别添增的重要信息和机制，因此必须尽可能保障 ICMPv6 信息可安全的送达目的地的。由于 link 的 MTU 值不得低于 1280 bytes ， ICMPv6 messages 被限制不得超过 1280 bytes ，可确保不会因为 ICMPv6 封包过大而无法送达目的地。 当未来发现 IP 层一些功能上的不足时， ICMPv6 可能会跟着更改或者新增某些功能，并且不需要更动 IPv6 。 ICMPv6 讯息格式 Type  表示 ICMPv6 讯息的类型。此字段内容决定其它字段的格式。 Code   其内容取决于 Type 域值。 Checksum   ICMP 讯息的检验值...
阅读全文

IP Security 簡介

作者：
IP Security 简称 IPsec ，主要提供两种功能： u   Authentication （认证功能）   是指封包接收端确认发送端的身份，以确保双方传送的数据未受他人破坏或窜改。 u   Confidentiality （保密功能）   将通讯内容予以加密，防止网络上的第三者读取通讯内容。 IPsec 的运作必须经过以下步骤： （1）   双方建立 Security Association （安全连结，简称 SA ）   透过协商机制来决定 IPsec 的使用方式。例如：选择何种安全功能（ AH or ESP ），加密的算法，使用密钥的原则等。 （2）   密钥交换     利用非对称性加密法，让双方拥有共同的秘钥。 （3）   以安全的管道传送讯息    透过建立好的 SA 以及共有的秘钥，双方以安全的管道传送数据。 IPsec 提供以下 2 种安全传送模式： -        Transport mode （传输模式）   建立联机的 Host-A 与 Host-B 皆具有 IPsec 能力时，可使用 Transport mode 来建立联机。 -        Tunnel mode （隧道模式）   建立联机的 Host-A 以及 Host-B 不需要具有 IPsec 能力，透过两端的 routers 来建立 IPsec 安全联机。 IPsec 使用的安全功能有 2 种如下： u   Authentication Header （简称 AH ）   AH 除了提供 IP 承载的数据数据的认证以外，也尽可能保护 IP 表头内容。然而，有些 IP 表头的域值在经过 router 转送封包时会被改变（例如 Hop Limit 字段），这些会改变的字段是不可保护的。因此， AH 对 IP 表头的保护是零碎非完整的。 u   Encapsulating Security P...
阅读全文