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越多，则占用整个internet的带宽越巨。如何有效地管理这些multicast封包为routers首一要务。为了兼顾multicast封包流的管理以及满足客户端的实时服务需求，MLD乃基于以下2个基本原则而设计：
1.       实时处理第一个listener  当连接的link上任何multicast address出现第一个listener时，routers应该实时与邻近的routers交换信息， 尽可能迅速将listener欲接收的multicast封包流引导到此listener链接的link上。
2.        尽量减少带宽不必要的浪费  当有listener停止接收某个multicast封包时， router应该实时探测该listener链结的link上是否还有其它listener欲接收此multicast封包。 如果没有其他listeners存在，则应该实时与邻近的routers交换信息，尽速阻断此mutilcast封包流到该link，减少不必要的带宽浪费。


MLD Packet Structure

MLD是ICMPv6的子协议，也就是说，MLD是整个ICMPv6信息的子集合。MLD message封包由IPv6表头、Hop-by-Hop Options扩充表头及MLD message组成如下：




注
《注意》 MLD messages的目的地地址都是使用multicast地址来完成信息交换，因此包含Hop-by-Hop Options扩充表头是必要的。Hop-by-Hop Options扩充表头用来告知router必须对封包做进一步处理。Router Alert Option值为0的Hop-by-Hop Options扩充表头告知router其为MLD message，藉此可跟一般的multicast封包流区隔。一般的multicast封包流不包含Hop-by-Hop Options扩充表头，router只依据multicast列表负责转送，不做其它处理。

由于MLD message的交换仅限于同一个link的范围，RFC 2710规定所有的MLD封包的IPv6来源地址必须为发送端的link-local地址，并且IPv6表头的Hop Limit字段必须设为1。 MLD的接收者尤其是router必须检查这2个域值，不符合的封包则丢弃不处理。如此可防止MLD messages流窜到别的links，造成整个MLD机制大乱。

MLD Messages

MLD message共有3种类型：
Multicast Listener Query（ICMPv6 Type 130）
Multicast Listener Report（ICMPv6 Type 131）
Multicast Listener Done（ICMPv6 Type 132）

这3种类型的message structure格式完全相同如下：









Code 域值固定设为0，接收端忽略其内容。
Checksum  ICMPv6的标准checksum值。
Maximum Response Delay  此字段只对Query message有意义。它指定listeners回报Report message的最大延迟时间，单位为毫秒。其它类型的MLD messages将此字段设为0，且接收封包者忽略此字段。变换此域值可让routers调谐“leave latence（离开延迟）”，即 -- 当有个listener通知停止聆听某个multicast封包流时，router侦测此multicast封包流不存在其它listener所需要的时间（请参考章节“List of timers and default values”Last Listener Query Interval）。此字段亦可用来调谐突发性的MLD流量（请参考“List of timers and default values”Query Response Interval）。
Reserved  域值固定设为0，接收端忽略其内容。
Multicast Address  在General Query messages中，此字段设为0。在Multicast-Address-Specific Query messages中，此字段设成routers欲查询的multicast address。在Report或Done messages中，listener利用Multicast Address字段来指明哪个Multicast Address需要聆听或者停止聆听。
其它字段  MLD信息的长度计算方法为：IPv6表头的Payload Length域值减去MLD信息前端的所有其它IPv6 extension headers长度。如果MLD信息的长度大于24 octets ，表示还有其它字段存在于MLD信息的后端 ，这可能被MLD的未来向后兼容的新版本所定义使用。仅实现MLD版本的node发送的MLD信息长度绝不可超过24 octets，对于收到的MLD信息超过24 octets的部分也必须忽略。在所有情况下，checksum域值的计算必须涵盖整个MLD信息，而非仅仅24 octets。

Multicast Listener Query（Type 130）

Multicast Listener Query message细分2种类型：
-   General Query  Querier定期发送General Query来查询link上哪些multicast地址有listener。
-   Multicast-Address-Specific Query  当Querier接收到Done message时，立即发送Multicast-Address-Specific Query来查询link上是否还有nodes聆听同一个multicast地址。
这2种类型是藉由Multicast Address域值来区分：General Query设为0，Multicast-Address-Specific Query则设为欲查询的multicast address。
在IPv6表头中，来源地址设为发送端的link-local地址，Hop Limit字段固定设为1。 General Query须向link上所有的nodes查询，其目的地址设为link-scope all- nodes address（即FF02::1）。 Multicast-Address-specific Query只需向此multicast address的listener查询，其目的地址设为欲查询的multicast address。

Multicast Listener Report（Type 131）

Listeners发送Report message的时机如下：
²  当接收到General Query时， 将所有聆听的multicast addresses利用Report message个别回报给routers。
²  当接收到Multicast-Address-Specific Query messages时，listener只回报指定的multicast address。
²  当有应用程序要求接收某个multicast address时，会立即发送Report message。
Multicast Address字段设为要回报的multicast address。
IPv6的目的地址设为要报告的multicast address，来源地址设为发送端的link-local地址，Hop Limit字段固定设为1。

Multicast Listener Done（Type 132）

Node用Done message来告知routers停止聆听指定的multicast address。
Multicast Address字段设为要停止聆听的multicast address。
IPv6的目的地址设为link-scope all-routers address（即FF02::2），来源地址设为发送端的link-local地址，Hop Limit字段固定设为1。

MLD协议说明

RFC 2710定义了下列协议行为。当读者细细品味其内容后，将不禁赞叹其设计之巧妙。
n  Router使用MLD Query message来查询每个link上哪些multicast address封包有listener。Router的每个link各自维护一张multicast列表，从接收到的Report messages讯息中的multicast address记录在multicast列表里，同时每个multicast address配置一个定时器（此定时器的用途稍后会做解释）。请注意， router只需要知道link上哪些multicast address有listener，不需要知道listener的身份地址，也不需要知道有多少listener。
n  如果router有多个interfaces链接到同一个link，router会固定选择其中一个interface的link-local地址为发送MLD信息的来源地址，并且将该interface设置为可接收所有的multicast addresses。
n  每个link上的routers分成2种角色：Querier（查询者，负责发送Query message）或Non-Querier（非查询者，不发送Query message）。通常1个link只有1个Querier。 所有的router刚启动时会预设自己为Querier。 如果Querier接收到Query message，而且此message的IPv6来源地址的数值比自己的小，此时必须把自己切换为Non-Querier。 如果在 【Other Querier Present Interval】时间内，Non-Querier没收到任何来源地址的数值比自己小的Query message，则把自己恢复为Querier。Non-Querier会接收到所有的MLD messages，所以它将保持跟Querier同样的状况以及multicast列表。
n  Querier定期每隔【Query Interval】时间发送General Query，请求listener回报Report message。为了能快速有效地查询listener的存在，Querier刚启动时第一次发送的General Query应该以紧密的【Startup Query Interval】间隔时间重复发送，重复次数为【Startup Query count】。
n  当node接收到General Query时，会对每个它所聆听的multicast address分别设置不同的定时器（不包含link-local all nodes、scope 0以及scope 1的multicast addresses），每个定时器的时间都是从 【0， Maximum Response Delay】区间中随机取得且内容不同。当接收到General Query同时某些定时器正在运行中时，如果该定时器的剩余时间大于收到的General Query的Maximum Response Delay域值，则重新随机设置该定时器，否则继续倒数原来的定时器。如果General Query的Maximum Response Delay域值为0，则定时器设为0，立即执行定时器到期后的动作。
n  当接收到Multicast-Address-Specific Query时，如果node是此指定的multicast address listener，与处理General Query方式相同，对此multicast address随机设置定时器值。只要任何的定时器到期，就会个别发送对应的Report message，且其IPv6的目的地址为定时器到期的multicast address。如果node接收到其它node发出的Report（这代表两者希望聆听同一个multicast address），而且与此Report相同的multicast address的定时器在运转，则停止定时器且不发送该Report。如此可避免Routers重复接收到相同的Report。
n  当router从某个link上接收到Report，如果Report的地址不在此link的multicast列表里，则添加Report的address到multicast列表里，并且设定其定时器值为【Multicast Listener Interval】 。如果接收到的Report的address已经存在multicast列表里，则重新定时器值为【Multicast Listener Interval】。如果multicast 列表的address的定时器到期，则表示此address不再有listener，因此将它从列表删除。
n  当node开始聆听某个multicast address，它应该马上发送该multicast address的Report。 此时此node可能是link上该address的第一个listener，而且发送的Report有可能丢失，因此在【Unsolicited Report Interval】时间过后，Report应该重复发送1次或2次。（例如：发出第一次的Report后，同时当做接收到该multicast address的Multicast-Address-Specific Query，并设置适当的定时器值。）
n  当node停止接收某个multicast address时，应该马上发送Done message，其multicast address字段设为欲停止聆听的地址，且IPv6目的地址设为link-scope all-routers address（即FF02::2）。如果此node最近的该multicast address的Report因为接收到其它node发出Report而被抑制没发送，则极可能有其它node仍在聆听此multicast address。此种情况下可以选择不发送Done message。如果这个优化功能被实现，其默认值应该设为打开。
n  当Querier接收到Done message，而且Querier的同一个link上的multicast列表存在这个Done message的multicast address，Querier会发送Multicast-Address-Specific Query， 询问link上是否还存在其它的listener。 在特定的时间内如果没收到此address的Report，则表示此address不再有任何listener，因此该address从列表中删除。
n  处于 Non-Queriery状态的router必须忽略Done信息。
n  当Non-Querier收到Multicast-Address-Specific Query信息，并且它的定时器的设置值大于Query信息中的Maximum Response Delay域值乘上常数【Last Listener Query Count】。此时，Non-Querier须将它的定时器的设置值更改成后者。
参考文獻
RFC 2710  Multicast Listener Discovery for IPv6

评论

发表评论

此博客中的热门博文

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 的下层。例
阅读全文

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 ，
阅读全文

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 ）将封包送达特定的目的地址？
阅读全文

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 表头内容。 如
阅读全文