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到不在同一个link的server， relay agent将负责中继client和server之间传递的DHCP messages。 对client而言， relay agent是透明不可见的。（很明显地，router最适合扮演relay agent角色。）











u  在某些情况下，server会在响应的messages携带server的unicast地址， client可以将后续的请求messages直接发送到server的unicast地址。

Client-Server信息交换  -  4个messages

为了请求1个或多个IP地址以及其它参数，首先client发送Solicit message到All_DHCP_Relay_Agents_and_Servers address来寻找可用的DHCP servers。任何server只要能符合client的请求，会将配置的IP地址以及其它参数透过Advertise message来回应client。
Client从收到的Advertise messages中选择最符合自己需求的配置，并将配置到的IP地址透过发送Request message要求server的确认。 Server透过Reply  message将确认配置的IP地址以及其它参数响应client。此时即完成Client-Server之间的信息交换， client可以开始使用配置到的IP地址以及其它参数。（获取到的IP地址必须经过DAD检测才可使用。）















Server分配给client的每个IP地址皆指定其preferred lifetime以及valid lifetime。为了能持续使用分配到的的IP地址， client可以在lifetime到期之前发送Renew message来要求延长lifetime。Server将新的lifetime透过Reply message响应client，允许client继续使用该IP地址而不会被中断。











Client-Server信息交换  -  2个messages

当client不需要server为其分配IP地址时，client可以使用2个messages的信息交换方式来获取其它的配置参数，例如：DNS、NTP server的IP地址。首先，client发送Information-Request message到All_DHCP_Relay_Agents_and_Servers multicast address，server将配置给client的参数值透过Reply message响应client。









此外，client也可以使用2个messages即Sloicit-Reply的交换方式来同时获取IP地址以及其它配置参数。在此情况下，client会在Solicit message中使用Rapid Commit option表明希望直接收到server实时分配且确认的Reply message。此种做法可加速client获取IP地址以及其它参數。

DHCPv6相关的术语

appropriate to the link  当1个地址与server依据网络拓扑、prefix分配以及地址分配政策一致时，称此地址为“appropriate to the link”。
binding  1个binding（或称为client binding）是server对每个client绑定的1组数据记录，包含已经宣告配置给client的IA值或者配置讯息。1个binding包含的IA值由元素组合 <DUID, IA-type, IAID> 索引，其中IA-type是指IA地址的类型（例如：temporary，non-temporary。）。1个binding包含的配置讯息由 <DUID> 索引。
configuration parameter  设置在server的配置元素， 使用DHCP传递给client。Nodes利用这些参数来配置network subsystem相关的设定值。
DHCP client （或简称client）  发起DHCP请求messages的node，从1个或多个DHCP server获取配置参数。
DHCP domain  一组由DHCP管理的links，并且由管理的实体负责操作。
DHCP realm  一个名称用来识别DHCP管理域，并且从中选取DHCP秘钥。
DHCP relay agent （或简称relay agent）  与client在同一link的node，负责递送client和server之间的messages。
DHCP server （或简称server）  回应client请求messages的node。 与client可在同一link上， 也可能不在同一个link。 （不在同一link时，必须透过relay agent来递送client和server之间的messages。）
DUID  每个DHCP的参与者都有个DHCP Unique Identifier（唯一标识符）。
Identity association (IA)  分配给client的address的集合。每个IA有个结合的IAID，用来识别IA。一个client可以分配到1到多个IA。每个IA持有1种特定的类型的address： 例如IA for temporary address（简称IA_TA）持有temporary addresses。
Identity association identifier (IAID)  IA的标识符，由client自行生成。每个IA都有个IAID，由同一个client所生成的IAID必须是唯一的。
Identity association for non-temporary addresses (IA_NA)  一个IA，其承载的address不是临时地址。
Identity association for temporary addresses (IA_TA)  一个IA，其承载的address为临时地址。
message  透过UDP传送的数据单元，client、server以及relay agent之间发送的信息。
Reconfigure key  由server提供给client的密钥，用于reconfigure message的安全保障。
relaying  relay agent转送DHCP参与者之间的messages。
transaction ID  一个不透明数值，用于回应匹配由client或server发起的请求messages。

DHCP使用的常数

Multicast Addresses

DHCP使用以下multicast addresses：
-      All_DHCP_Relay_Agents_and_Servers (FF02::1:2)  client利用此link-scoped multicast address发送messages给link上的邻居：server或者relay agent。Server和relay agent是此multicast group的成员。
-      All_DHCP_Servers (FF05::1:3)  relay agent利用此site-scoped multicast address发送messages给servers。 Site内的所有servers都是此multicast group的成员。

UPD ports

Clients使用UDP port 546，relay agent和server使用UDP port 547。

DHCP Messages种类

DHCP定义了以下的messages种类：

代码
名称
描述
1
Solicit
client发送Solicit message来定位server。
2
Advertise
Server发送Avdertise message来响应client发送的Solicit message， 表示server能提供配置给client。
3
Reguest
Client发送Request message要求server提供配置参数。
4
Confirm
Client发送Confirm message要求server确认目前的配置参数值是否适用于现在连接的link。
5
Renew
Client发送Renew message给server，要求延长目前使用的IP地址的lifetime，同时重新配置其它的配置参数。
6
Rebind
当client发送Renew message却没收到任何server的回应时， 会发送Rebind message给server，要求延长目前使用的IP地址的lifetime，同时重新配置其它的配置参数。
7
Reply
Server将配置的IP地址和其它配置参数透过Reply message来响应Solicit/Request/Renew/Rebind messages。不包含IP地址的配置参数则透过Reply message来响应Information-Request message。Server也使用Reply message来确认或否认client所发送的Confirm message。 Server也使用Reply来响应client所发送的Release或Decline message。
8
Release
Client发送Release message，用来告知server某些已经配置给client的IP地址不再被client使用。
9
Decline
Client发送Decline message，用来告知server某些配置给client的IP地址已经被其它node使用。
10
Reconfigure
当server有新的配置参数或配置参数值有了更新，此时server会发送Reconfigure message要求client重新要求配置参数。 Client会发送Renew或Information-Request来要求配置参数。
11
Information-Request
当client仅需要其它的配置参数而不需要配置IP地址时，会使用Information-Request里要求配置参数。
12
Relay-Forw
Relay agent将转送的DHCP message （无论是直接从client或者其它relay agent转送来的message）透过Relay-Forward message转送到server或下一个relay-agent。转送的DHCP messages都是封装在Relay-Forward的option内再转送。
13
Relay-Reply
Server将回应client的message封装在Relay-Reply message的option里，并发送Relay-Reply message到relay agent。Relay agent从Relay-Reply的option提取message再转送到client。

Status Codes

Status code用在标示回应请求messages的成功或失败的状态值（不携带status code时，默认为成功），并且提供其它的讯息指明失败的原因。
Name
Code
Description
Success
0
Success。
UnspecFail
1
Failure, reason unspecified; this status code is sent by either a client or a server to indicate a failure not explicitly specified in this document.
NoAddrsAvail
2
Server has no addresses available to assign to the IA(s).
NoBinding
3
Client record (binding) unavailable.
NotOnLink
4
The prefix for the address is not appropriate for the link to which the client is attached.
UseMulticast
5
Sent by a server to a client to force the client to send messages to the server. using the All_DHCP_Relay_Agents_and_Servers address.

Transmission and Retransmision Parameters

DHCPv6 messages使用UDP来传送。UDP并非reliable transport layer，不保证将上层数据送达目的地。因此DHCPv6的请求messagess必须透过重送机制来保证送达接收端。有关DHCPv6的重送机制细节，请参考RFC3315相关的章节。
Parameter
Default
Description
SOL_MAX_DELAY
1
sec
Max delay of first Solicit
SOL_TIMEOUT
1
sec
Initial Solicit timeout
SOL_MAX_RT
120
secs
Max Solicit timeout value
REQ_TIMEOUT
1
sec
Initial Request timeout
REQ_MAX_RT
30
sec
Max Request timeout value
REQ_MAX_RC
10

Max Request retry attempts
CNF_MAX_DELAY
1
sec
Max delay of first Confirm
CNF_TIMEOUT
1
sec
Initial Confirm timeout
CNF_MAX_RT
4
secs
Max Confirm timeout
CNF_MAX_RD
10
secs
Max Confirm duration
REN_TIMEOUT
10
secs
Initial Renew timeout
REN_MAX_RT
600
secs
Max Renew timeout value
REB_TIMEOUT
10
secs
Initial Rebind timeout
REB_MAX_RT
600
secs
Max Rebind timeout value
INF_MAX_DELAY
1
sec
Max delay of first Information-request
INF_TIMEOUT
1
sec
Initial Information-request timeout
INF_MAX_RT
120
secs
Max Information-request timeout value
REL_TIMEOUT
1
sec
Initial Release timeout
REL_MAX_RC
5

MAX Release attempts
DEC_TIMEOUT
1
sec
Initial Decline timeout
DEC_MAX_RC
5

Max Decline attempts
REC_TIMEOUT
2
secs
Initial Reconfigure timeout
REC_MAX_RC
8

Max Reconfigure attempts
HOP_COUNT_LIMIT
32

Max hop count in a Relay-forward message


Client-Server Messages格式

所有的client与server之间交换的messages格式皆相同。共享固定表头格式和可变格式的options。所有的域值皆遵循network byte order。
Option依序存放在option字段，option之间不需要padding。






msg-type  用来识别DHCP messages的种类。
transaction-id  messages交换时的transaction ID。由发出请求messages者自行设置，响应者复制请求message里的transaction-id值到回应的transaction-id字段。
options  变动长度的options字段。每个DHCP messages有各自适用的options。

Relay Agent–Server Messages格式

-      当client和server不在同一link时，由relay agent递送client和server之间的messages交换。所有的域值皆遵循network byte order。
-      Option依序存放在option字段，option之间不需要padding。
-      Relay agent messages有2种：Relay-forw以及Relay-repl。
共享相同的格式如下：










Relay-Forward message
msg-type  Relay-Forw（12）
hop-count  经由relay agent转送的次数。
link-address  1个global或site-local地址， relay agent利用它来识别client落在哪个link。
peer-address  被转送的message的client或relay agent的IP地址。
options  必须包含“Relay Message option”。可能包含其它的options。
Relay-reply message
msg-type  Relay-repl（13）
hop-count  从Relay-Forw message里复制
link-address  从Relay-Forw message里复制。
peer-address  从Relay-Forw message里复制。
options  必须包含“Relay Message option”。可能包含其它的options。

DHCP Unique Identifier（DUID）

每个client和server都具有DUID。Server使用UDID来确定client配置的参数和IAs与client的关联。Client中使用UDID来指明哪个server是client所欲交换messages的对象。
Client和server必须视DUID为不透明的数据， 并且只比较DUID值是否为相同， 不对DUID值做其它的诠释。Client和server不可限制目前已定义的类型，新的DUID类型可以在将来定义。
由于DUID是可变长度而且不一定都存在于每个DHCP messages中，所以DUID是包含在option中。DUID被设计为必须是独一无二而且尽可能不做变更。例如：一个设备即使更换网卡也不应改变其DUID值。
DUID具有多种类型的原因是因为DUID必须是全局唯一而且必须容易生成。每个设备可以选择最适合自己的DUID类型来生成DUID值。
DUID是由前面的2个bytes的类型代码，以及后跟着可变长度的字节构成实际的识别符。DUID有以下类型:
-      Link-layer address plus time
-      Vendor-assigned unique ID based on Enterprise Number
-      Link-layer address

DUID Based on Link-layer Address Plus Time [DUID-LLT]

这种类型的UDID包含2个bytes的类型值为1，2个bytes的硬件类型码，4个bytes的时间值，随后跟着UDID生成时此interface的link层地址。时间值是UDID生成时的秒数（自2000年1月1日的午夜（UTC）算起）。硬件类型必须是RFC862中IANA所分配的有效硬件类型。







使用这种类型DUID必须储存于稳定的存储器，而且必须持续使用即使当初生成此DUID的界面卡已经被拔除。没有稳定存储器的node不可使用此类型的DUID。

DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]

这种格式的UDID是由供货商分配给设备。它包括供货商的注册民营企业号码，后跟着供货商分配的唯一的识别符。








Identifier值留给供货商自行定义，但是每个identifier值必须是唯一的，并且在制造设备时必须将identifier值储存在non-volatile存储器。所生成的DUID应该被记录在不可清除的存储器。

DUID Based on Link-layer Address [DUID-LL]








Identity Association（IA）

u  “Identity Association”（IA）是一个结构，client和server可以透过它来识别、分组和管理一组相关的IPv6地址。每个IA包括1个IAID和相关的配置讯息。
u  Client在每个interface至少指定1个不同IA来向server要求分配IPv6地址。Client利用指定给每个interface的IAs向server获取每个interface的配置参数。每个IA必须只与1个interface相关联。
u  IAID由client指定，用来识别IA而且在client端必须是独一无二。即使client重新启动，已经被client指定使用的IA必须保持一致。Client的实现必须维持IA的一致性。
u  IA的配置讯息包括1到多个IP地址以及时间T1和T2。IA里的每个IP地址有其对应的preferred lifetime和valid lifetime。

Selecting Addresses for Assignment to an IA

根据以下的讯息的组合以及server端管理者的政策，server选择IP地址并分配给IA：
-      Client所连接的link，server决定其client的link位置如下：
*     如果server是直接从client收到message，并且该messages的IP表头的来源地址是link-local地址，则代表client和server连接在相同的link。
*     如果server是从relay agent收到的Relay-forw message，则代表client连接的link落在Relay-forw信息的link-addres字段里所指的relay agent的interface所连接的link。
*     如果server是直接从client收到message，并且该message的IP表头的来源地址不是link-local地址，则代表client连接的link时落在IP表头的来源地址所标示的link。（这种情况主要是因为server允许client直接发送unicast地址的message封包到server。）
-      Client提供的DUID
-      Client提供的其它信息
-      由relay agent在options中提供的其它信息

DHCP Messages验证

除了每个message类型有个别的验证项目以外，以下是验证DHCP messages的基本原则：
²  如果DHCP messages里包括了不该存在的option，client和server应该丢弃此封包。例如：Information-Request message就不该包含IA option。
²  如果Solicit/Confirm/Rebind/Information-Request messages的IP表头的目的地址为unicast address，Server必须丢弃此封包。
²  如果收到的message里包括了不该存在的option、掉失应该有的option或者包括不合法的option，server会发送Reply message且携带Status code，其值为UnSpecFail。

Transaction IDs的用法

“Transaction ID” 由client保存，并且server回应message时用来同步client的请求message。Client应该利用随机数来生成不容易猜测或预测的Transaction ID。请注意，如果client生成的Transaction ID容易被预测，它可能变得更容易被某些种类的攻击。Client在做重传message时必须保持Transaction ID不变。

Messages验证

名称
验证原则
Solicit
²   Client必须丢弃任何收到的Solicit message。
²   当以下任何情形发生时，Server必须丢弃Solicit message：
-      没包含Client Identifier option
-      包含 Server Identifier option
Advertise
²   当以下任何情形发生时，client必须丢弃Advertise message：
-      没包含Server Identifier option
-      没包含Client Identifier option
-      Client Identifier option与client的DUID不匹配
-      Transaction ID域值与client发送的Solicit message不匹配
²   Server和relay agent必须丢弃任何收到的Advertise message
Request
²   Client必须丢弃任何接收到的Request message。
²   当以下任何情形发生时，Server必须丢弃Request message：
-      没包含Server Identifier option
-      Server Identifier option值不匹配server的DUID
-      没包含Client Identifier option
Confirm
²   Client必须丢弃任何接收到的Confirm message。
²   如果server接收到的Confirm message不包含Server Identifier option或Client Identifier option，则必须丢弃封包。
Renew
²   Client必须丢弃任何接收到的Renew message。
²   当以下任何情形发生时，Server必须丢弃Renew message：
-      没包含Server Identifier option
-      Server Identifier option值不匹配server的DUID
-      没包含Client Identifier option
Rebind
²   Client必须丢弃任何接收到的Rebind message。
²   如果server接收到的Rebind message不包含Server Identifier option或Client Identifier option，则必须丢弃封包。
Decline
²   Client必须丢弃任何接收到的Decline message。
²   当以下任何情形发生时，Server必须丢弃Decline message：
-      没包含Server Identifier option
-      Server Identifier option值不匹配server的DUID
-      没包含Client Identifier option
Release
²   Client必须丢弃任何接收到的Release message。
²   当以下任何情形发生时，Server必须丢弃Release message：
-      没包含Server Identifier option
-      Server Identifier option值不匹配server的DUID
-      没包含Client Identifier option
Reply
²   当以下任何情形发生时，Client必须丢弃Reply message：
-      没包含Server Identifier option
-      “transaction id” 域值不匹配请message里的“transaction id”域值
²   如果在client的请求message里包含Client Identifier option，则Reply message必须包含Client Identifier option，且两者必须匹配。
²   如果在client的请求message里包不含Client Identifier option，则Reply message必须不可包含Client Identifier option
²   Server和Relay agent必须丢弃任何接收到的Reply message。
Reconfigure
²   Server和Relay agent必须丢弃任何接收到的Reconfigure message。
²   当以下任何情形发生时，client必须丢弃Reconfigure message：
-      message不是透过unicast地址送到client
-      不包含Server Identifier option
-      不包含Client Identifier option（必须包含client的DUID）
-      不包含Reconfigure Message option，并且其msg-type必须是个有效值
-      包含任何IA option并且Reconfigure Message option的msg-type为Information-request
-      不包含DHCP认证：不包含authentication option或者没通过client的认证。
Information-request
²   Client必须丢弃任何接收到的Information-request message。
²   当以下任何情形发生时，server必须丢弃Information-request message：
-      包含Server Identifier option且其DUID值与server的DUID不匹配
-      包含IA option
Relay-forw
Client必须丢弃任何接收到的Relay-forw message。
Relay-reply
Client和server必须丢弃任何接收到的Relay-reply message。



參考文獻

RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)


评论

发表评论

此博客中的热门博文

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 的实体附件。例如网络卡。 Link  通信介质， node 之间可以透过 link layer 进行通信。即 IP 的下层。例
阅读全文

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 （重新导向 ）   当 link 上有 2 个以上 routers 时， Router 如何告知 host 使用更佳的 next-hop  （即另外的 router ）将封包送达特定的目的地址？
阅读全文

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 ，计算并且保持个别的 interface listening state
阅读全文

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 讯息的检验值。 Message Body   包含 ICMPv6 讯息特有的数据。 ICM
阅读全文

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 Payload （简称 ESP ）   ESP 除了提供与 AH 类似的功能以外，还提供加密的服务。 AH 可单独使用，或者同时与 ESP 一起保护 IP 封包。 ESP 和 AH 提供完整性保护的主要区别在于覆盖的程度： 具体的差异是 ESP 不保护 IP 表头内容。 如
阅读全文